简介：本文从模型架构视角系统梳理 Omni 语音模型的通用推理流程，重点解析 Dual AR 与 Thinker-Talker 两类代表路线的计算特征、框架需求及抽象边界。阅读本文可帮助推理框架开发者理解哪些模块应当统一设计，哪些模块必须保持差异化，从而在系统重构时做出更合理的工程决策。
Omni 模型，即全模态语音交互模型，是指能够直接接收音频输入并生成语音输出的端到端神经网络系统。与传统的“语音识别 + 大语言模型 + 语音合成”级联方案不同，Omni 模型将语音理解与语音生成能力整合在一个统一架构中，推理时只需一次前向计算即可完成从语音到语音的完整转换。
Omni 模型推理流程，指的是从原始音频波形输入到最终语音波形输出之间，整个计算图在推理阶段所经历的完整处理链路。理解这一流程的定义与边界，是设计高性能推理框架的前提。推理框架的核心职责在于：在保证模型语义完整性的前提下，尽可能高效地调度计算资源、管理显存、复用计算图、减少冗余开销，从而降低首字延迟与整体吞吐成本。
一个完整的 Omni 推理流程通常包含四个逻辑阶段：
需要明确的是，这四个阶段是逻辑划分，而非工程实现上的固定模块边界。不同模型可能将其中的两个或多个阶段合并到一个 Transformer 中完成，也可能将一个阶段拆分为多个子网络。推理框架的抽象设计，本质上就是要在这种“逻辑统一、实现多样”的现实约束下，找到合适的中间层。
在推理框架的前期开发中，一个常见的问题是抽象层级过度膨胀。请求从 HTTP 入口到达底层张量计算，中间可能穿越 Stage、Worker、Executor、Engine 等多个层级，而这些层级之间的职责往往高度重叠。当系统需要同时支持多种架构差异显著的模型时，这种过度抽象会成为严重的维护负担。
反过来，如果抽象过于粗糙，把所有模型都塞进同一个执行模型中，又会导致灵活性不足。例如，某些模型需要流式解码，某些模型需要非自回归的并行解码；某些模型的编码器与解码器共享权重，某些则完全独立；某些模型在推理过程中需要动态切换计算图，某些则全程复用同一张图。这些差异如果不能在框架层得到正确表达，就会迫使上层业务代码绕过框架直接操作底层接口，最终破坏系统的整体一致性。
因此，在动刀重构之前，必须先回答三个问题：（1）我们要支持哪些模型？（2）它们的架构差异究竟在哪里？（3）哪些计算模式可以统一抽象，哪些必须保留差异化路径？只有把这些问题想清楚，才能设计出既不过度复杂也不过度简化的系统结构。
原始音频波形的采样率通常在 16kHz 至 48kHz 之间，意味着每秒有数万个浮点采样值。直接将这种高密度信号送入 Transformer 是不现实的，一方面序列长度会爆炸，另一方面波形中的冗余信息太多，不利于语义建模。因此几乎所有现代语音模型都会引入一个音频编解码器（Codec），将波形转换为离散的 token 序列。
Codec 本质上是一个自编码器结构：编码器将波形压缩为低维离散表示，解码器再从离散表示重建波形。中间的离散表示被称为声学 token（acoustic token）。经过 Codec 处理后，一秒钟的音频通常被压缩为几十到上百个 token，序列长度降低了两到三个数量级，使得后续的 Transformer 建模成为可能。
单一 Codec 的量化层往往不足以保留高质量的音频细节。为此，主流方案采用残差向量量化（Residual Vector Quantization, RVQ）。RVQ 的核心思想是：第一层量化器对原始特征进行粗粒度量化，得到第一组 token；然后计算量化残差，交给第二层量化器继续量化，得到第二组 token；如此迭代多层。
RVQ 带来两个重要后果。第一，一个音频帧对应多个 token（层数通常为 4 到 32 层不等），这些 token 之间存在层级依赖关系——粗粒度层承载主要的语义和音色信息，细粒度层承载细节纹理。第二，推理框架需要决定如何组织这些多层 token 的计算顺序：是逐层生成，还是并行生成，或者采用某种混合策略。这个决策直接影响解码步数、计算效率和生成质量。
四个逻辑阶段之间存在大量的设计自由度。理解这些自由度，是理解不同模型之间差异的关键。
音频编码阶段的自由度在于：用什么样的编码器？是否与后续的 Thinker 共享权重？输出的是连续特征还是离散 token？如果是离散 token，使用单层还是多层 RVQ？
语义理解阶段的自由度在于：Thinker 是一个独立的 Transformer，还是与 Talker 共享同一个主干网络？Thinker 的输入是音频特征、声学 token 还是文本，输出是文本 token 还是语义 token？解码方式是自回归还是非自回归？
语音合成阶段的自由度在于：Talker 是否独立于 Thinker？它接收的是文本 token 还是语义 token？生成声学 token 时使用几层 RVQ，各层之间是否采用自回归依赖？
音频解码阶段的自由度在于：Vocoder 是基于 GAN、扩散模型还是纯卷积网络？它与前面的声学 token 生成器是一体训练的还是独立训练的？推理时是否支持流式输出？
这些自由度构成了一个多维度的设计空间。不同的模型在这个空间中选择不同的坐标点，形成了各自独特的架构形态。推理框架的任务，就是在这个多维空间中寻找一组正交的基础抽象，使得每个模型的特殊性都能被表达为这些基础抽象的差异化配置，而不是要求框架为每个模型单独写一套执行逻辑。
Dual AR（双自回归）是一种典型的语音生成架构。它的名字暗示了其核心特征：系统中有两条自回归生成路径。一条路径负责生成语义层级的 token，另一条路径负责生成声学层级的 token。
以当前业界常见的实现方式为例，Dual AR 模型通常将语音合成阶段拆分为两个子阶段。第一个子阶段是一个自回归 Transformer，根据上游 Thinker 输出的语义 token 或文本条件，逐帧生成粗粒度的声学 token。第二个子阶段同样是一个自回归 Transformer，根据第一阶段的输出以及可能的上下文信息，逐层生成 RVQ 中的细粒度 token。
这种设计将原本需要一次性生成多层 RVQ 的复杂任务，分解为多个相对简单的自回归序列建模问题。每一层自回归解码都可以复用成熟的 Transformer 推理优化技术，例如 KV Cache、推测解码、CUDA Graph 加速等。
Dual AR 模型对推理框架提出了几个明确的需求。
首先是多阶段序列依赖管理。语音合成的两个子阶段之间存在严格的先后依赖：第二阶段必须等待第一阶段产生完整的或至少足够长的输出后才能启动。框架需要支持这种流水线式的调度，同时避免不必要的同步等待。
其次是可变长度序列的处理。语音段落的长度差异远大于文本段落。一个短促的应答可能只有几十个声学 token，而一段长叙述可能包含数千个 token。框架需要在不预先知道输出长度的前提下，高效地管理显存和计算资源。
第三是 CUDA Graph 的复用问题。在自回归解码中，每一轮迭代的计算图结构是相似的，只是输入张量的内容不同。CUDA Graph 可以将这些迭代的计算图预先录制并复用，显著降低 CPU 侧调度开销。但在 Dual AR 场景中，两个子阶段的计算图并不相同，而且它们在不同的时间点启动、不同的序列位置上运行。如何为这种多阶段自回归模型设计统一的 CUDA Graph 复用策略，是一个具有挑战性的工程问题。
从框架设计者的角度看，Dual AR 路线真正需要的抽象能力可以归纳为三点。
第一，需要一种通用的“自回归阶段”抽象，能够描述一个阶段的输入格式、输出格式、解码策略（贪婪、采样、束搜索）以及 KV Cache 的配置方式。这个抽象不应关心具体的模型是 Thinker 还是 Talker，只要它执行的是逐 token 生成即可。
第二，需要一种阶段间数据流描述机制。框架应当允许开发者声明阶段之间的依赖关系和数据传递格式，然后由调度器自动决定流水线并行策略、预取策略和同步点。
第三，需要计算图录制与回放机制能够感知当前所处的阶段。不同阶段可能有不同的图形状和资源需求，框架不能假设整个推理过程中只有一张图。
Thinker-Talker 架构代表了一条与 Dual AR 显著不同的技术路线。它将 Omni 模型明确划分为两个功能角色：Thinker 负责“思考”，即语义理解；Talker 负责“说话”，即语音生成。这两个角色在架构上是相对独立的网络模块。
Thinker 的输入是音频编码后的特征，输出是文本 token 或高层次的语义 token。Thinker 本质上类似于一个大语言模型，其推理流程与文本 LLM 的推理流程高度相似——逐 token 自回归生成，维护 KV Cache，支持流式输出。
Talker 的输入是 Thinker 的输出 token，输出是声学 token。Talker 在推理时的一个重要特征是非自回归或部分非自回归。与 Dual AR 中 Talker 内部的逐 token 生成不同，Thinker-Talker 路线中的 Talker 往往可以在给定完整语义条件后，并行生成较长的声学序列。
两者最根本的差异不在于“有没有两个模块”，而在于语音合成阶段的计算范式不同。
Dual AR 的语音合成是一个全自回归过程，每一帧声学 token 的生成都依赖于前面已经生成的 token。这意味着语音合成的耗时与语音时长近似线性相关，而且无法通过并行手段从根本上突破这一限制。
Thinker-Talker 路线的语音合成则引入了非自回归的成分。当 Talker 接收到完整的语义 token 序列后，它可以利用双向注意力机制，在显著减少的解码步数内生成全部声学 token。这种设计的优点是语音生成速度更快，适合对响应延迟敏感的场景。缺点是训练难度更大，需要处理非自回归生成中的多模态性问题，以及语义条件与声学输出之间的对齐问题。
从框架抽象的视角看，这个差异意味着：不能将所有模型的语音合成阶段都假设为自回归解码。框架需要同时支持自回归和非自回归两种语音生成模式，并且允许同一个请求在 Thinker 阶段走自回归执行路径，在 Talker 阶段切换为非自回归执行路径。
Thinker-Talker 路线对框架提出了几个与 Dual AR 不同的需求。
首先是混合执行模式的动态切换。一个请求在生命周期内可能经历多次计算范式的转变：音频编码是纯前向的，Thinker 是自回归的，Talker 是非自回归的，Vocoder 又是纯前向的。框架的调度器需要有能力在运行时识别当前阶段并选择正确的执行引擎，而不是在请求到达时就把整个请求绑定到某一种执行模式上。
其次是不同阶段的资源占用特征差异显著。Thinker 阶段的计算强度与文本 LLM 类似，瓶颈通常在显存带宽和 KV Cache 容量。Talker 阶段的计算强度可能更高，因为非自回归生成需要一次处理更长的序列。框架需要支持针对不同阶段设置不同的资源配额和调度优先级。
第三是推理延迟的构成发生变化。在 Dual AR 中，语音生成延迟是逐帧累积的。在 Thinker-Talker 中，Talker 的延迟可能体现为一个大块的等待时间，而非持续的流式输出。这对于流式场景下的首包延迟和播放平滑性都有直接影响，框架需要提供相应的缓冲和调度机制。
基于上述分析，可以尝试推导出 Omni 推理框架抽象的合理边界。
请求生命周期管理应当统一。无论模型采用何种架构，一个请求从进入到完成都要经历初始化、输入预处理、分阶段执行、输出后处理、资源释放等环节。这些环节的状态机设计、错误处理逻辑和资源追踪机制可以做成统一的框架层能力。
张量执行基础设施应当统一。底层的模型加载、权重管理、算子调度、显存池管理、通信原语等能力，对所有模型来说都是相同的基础需求。这些能力应当收敛为一套稳定的内部接口。
自回归解码引擎应当统一。对于所有需要逐 token 生成的阶段，无论它是 Thinker 还是 Dual AR 中的 Talker 子阶段，其核心循环逻辑——采样、KV Cache 管理、停止条件判断、CUDA Graph 复用——都是相同的。统一这一层可以避免重复实现和优化分散。
语音合成阶段的执行范式不能强行统一。自回归与非自回归的语音合成在调度策略、资源预估、延迟特性上存在本质差异，必须保留各自的执行路径。框架应当将语音合成视为一个可插拔的策略接口，不同模型可以注册不同的实现。
阶段间的数据依赖模式不能硬编码。有的模型是严格串行的四阶段流水线，有的模型存在跨阶段的跳跃连接或反馈循环。框架需要提供声明式的方式来描述这些依赖，而非在调度器中写死。
RVQ 的生成策略不能假设唯一。不同模型可能采用不同的 RVQ 层数、不同的层级生成顺序、不同的条件依赖结构。框架层应当将 RVQ 的维度视为模型配置的一部分，而不应将其编码进调度逻辑中。
基于以上分析，一个合理的 Omni 推理框架抽象应当遵循以下原则：将“执行机制”与“模型策略”分离。 执行机制（如何运行自回归循环、如何管理显存、如何调度计算图）可以统一；模型策略（阶段如何划分、依赖如何连接、RVQ 如何生成）必须可配置。
具体而言，框架可以提供一组正交的基础原语：自回归解码器原语、非自回归解码器原语、流式数据管道原语、阶段调度器原语。模型开发者通过组合这些原语来描述自己的推理流程，而框架负责这些原语的高效执行和资源协调。这样既避免了为每个模型单独定制执行引擎的维护成本，也保留了足够的灵活性来适应未来可能出现的新的架构形态。
对于正在为 Omni 模型构建或选择推理框架的团队，以下几点值得关注。
在选型阶段，应重点考察框架对非自回归语音合成的支持成熟度。许多 LLM 推理框架对自回归解码有深度优化，但对非自回归语音生成的调度优化相对薄弱。如果目标模型采用了 Thinker-Talker 类架构，需要确认框架是否能在 Talker 阶段高效执行。
在接入阶段，建议将模型架构描述与执行逻辑解耦。不要把阶段依赖关系写死在业务代码中，而是通过配置或声明式接口来描述。这样可以降低后续模型升级或架构切换时的改动成本。
在性能调优阶段，应分别对 Thinker 阶段和 Talker 阶段进行独立的延迟分析和资源剖析。两个阶段的性能瓶颈通常不同，优化的方向也不同。混合使用统一的优化策略可能导致其中一个阶段成为瓶颈而另一个阶段资源过剩。
在运维层面，需要关注不同阶段的显存峰值和显存碎片情况。非自回归语音合成的长序列计算可能会在短时间内消耗大量显存，需要框架具备有效的显存回收和复用机制。
Omni 模型推理流程的定义，本质上是将“从语音到语音”的端到端计算分解为音频编码、语义理解、语音合成和音频解码四个逻辑阶段。不同模型在这四个阶段中做出了不同的架构选择，其中 Dual AR 与 Thinker-Talker 是两条具有代表性的技术路线。
理解这些路线之间的本质差异——尤其是语音合成阶段的自回归与非自回归范式差异——是设计推理框架抽象的关键前提。合理的抽象应当将执行机制层面的共性统一起来，同时为模型策略层面的差异性保留充分的表达空间。只有在这种“统一机制、分离策略”的原则指导下，推理框架才能在支持多样化 Omni 模型的同时，保持系统的可维护性与执行效率。