简介：本文围绕全模态语音模型的推理流程展开，系统拆解 Audio Encoding、Understanding、Speech Synthesis 与 Audio Decoding 四阶段流水线。文章重点分析两类代表性架构：Dual AR 推理与 Thinker-Talker 推理，并在此基础上推导推理框架抽象的边界——哪些计算模式应当统一，哪些能力必须保留差异化设计，为相关系统设计与重构提供参考。
Omni 模型，可以理解为一类以语音为主要交互界面的全模态生成模型。它的核心任务可以概括为一句话：听懂语音输入，生成语音回复。
从技术视角看，Omni 模型并不是一个孤立的神经网络，而是一套由多个模块协作组成的推理系统。它需要同时处理两类信息：连续语音信号的编码与理解，以及离散语音语义单元的生成与还原。一个完整的 Omni 推理流程通常包含四个阶段：
从业务视角看，Omni 模型的价值在于将“语音识别—语义理解—文本生成—语音合成”这一传统上需要多个独立模型串联的链路，压缩到统一框架内完成。这种统一带来的收益至少体现在三点：端到端延迟更低、跨模态信息损失更少、部署与调度逻辑更简单。
从使用视角看，开发者面对 Omni 模型时，真正需要关心的是：一个请求从进入推理服务到返回音频结果，中间经过了哪些计算阶段，哪些阶段可以并行，哪些阶段存在严格依赖，以及不同模型在这些阶段上的实现差异如何影响底层抽象设计。
在传统语音系统中，语音识别、大语言模型推理、语音合成通常是三个独立服务。每个服务有自己的队列、批处理策略、超时机制和资源规格。这种方式虽然模块边界清晰，但也带来了明显的问题：
Omni 模型的出现，本质上是在回应这些痛点。它将原本分散在多服务之间的计算流程收敛到单一模型体系内，使得推理框架有机会对整条链路进行统一调度、统一批处理和统一资源管理。
但“统一”并不意味着“同一化”。不同 Omni 模型在架构选型上存在显著分野，这种分野直接决定了推理框架的抽象边界应该划在哪里。如果在没有理解这些差异之前就贸然进行系统抽象，容易走向两个极端：要么抽象层级过深，一层套一层，维护成本极高；要么抽象过粗，导致某些模型的特殊计算模式无法被高效表达。
在深入两类代表性架构之前，需要先建立一组通用概念。这组概念是后续所有讨论的语言基础。
原始音频波形每秒包含数万个采样点，直接送入 Transformer 计算量不可接受。因此，几乎所有的现代语音生成模型都会先将音频转换为某种离散标记序列。这个转换过程由音频编解码器完成，它所产出的离散单元通常被称为 Codec Token。
Codec 的核心思想是：用有限数量的离散符号来近似表示连续的音频信号。一个训练良好的 Codec 能够在保持可懂度和自然度的前提下，将一秒音频压缩为几十到几百个离散标记。这样，语音生成问题就被转化为了一个离散序列生成问题，可以复用大量成熟的序列建模技术。
单个 Codec 层的表达能力有限，难以同时捕捉语音的语义内容和音色细节。因此，主流方案通常采用残差向量量化结构，也就是将音频信号在多个量化层级上进行递进式编码。
第一层 RVQ 捕获语音的主干信息，如音素序列和大致的韵律轮廓；第二层在第一层的残差上继续编码，补充更精细的频谱细节；后续层级继续递进。推理时，生成器需要逐层生成这些 RVQ 标记，层与层之间存在条件依赖关系。这种多层结构显著增加了推理的序列长度和调度复杂度，但也正是高质量语音合成的基础。
四个阶段之间存在明确的拓扑顺序：
但在这个总体顺序之下，存在一个重要的设计自由度：Speech Synthesis 是否依赖 Audio Encoding 的中间信息。这个自由度正是区分不同 Omni 模型架构的关键变量之一。
具体来说，Speech Synthesis 的输入可以有以下几种选择：
这一自由度直接影响推理框架的数据搬运设计和显存管理策略。如果框架假设 Talker 只接收语义输入，那么在实现需要音频特征注入的模型时，就必须引入额外的跨阶段数据通路；反之亦然。
第一类值得深入分析的架构可以概括为 Dual AR 模式。这类模型的核心特征是将语音生成任务拆解为两条自回归生成路径：一条负责生成语义层面的离散标记，另一条负责生成声学层面的细节标记。
在 Dual AR 架构中，模型通常用两个不同粒度的标记序列来表示一段语音：
推理时，这两条路径并非完全独立。实践中常见的做法是：先生成语义标记序列，然后在语义标记的指导下逐层生成声学标记。这种层级递进关系既保证了语义的正确性，又兼顾了声学细节的丰富性。
以一个典型的 Dual AR 推理过程为例，其执行顺序大致如下：
这个流程中的关键特征在于：Speech Synthesis 阶段的序列长度被 RVQ 层数成倍放大。假设语义序列长度为 N，RVQ 层数为 K，则声学标记的总长度为 N×K。这直接决定了该阶段是整个推理流程中的计算热点。
Dual AR 架构对推理框架提出了几项明确需求：
第一，需要支持多序列条件生成。 声学标记的生成必须能够以语义标记序列为条件，这意味着推理引擎的注意力机制和 KV 缓存管理必须支持跨序列的上下文关联。
第二，需要高效的逐层生成调度。 RVQ 多层生成之间存在严格依赖：第 i 层完成后才能开始第 i+1 层。但层内不同时间步的生成可以充分利用自回归的增量特性。框架需要能够在这两种依赖关系之间高效调度计算资源。
第三，需要考虑多层 KV 缓存的合并与复用。 由于各 RVQ 层共享一部分语义条件信息，某些模型的实现会允许跨层共享部分 KV 状态。推理框架如果能够识别并利用这种共享机会，可以显著降低显存占用。
第四，CUDA Graph 优化需要针对 Dual AR 模式做专门设计。 自回归推理的执行图结构高度重复，适合用 CUDA Graph 来减少启动开销。但在 Dual AR 场景下，不同 RVQ 层、不同生成阶段的计算图形态可能不同，需要更灵活的多图管理策略。
与 Dual AR 相对的另一类代表性架构是 Thinker-Talker 模式。这类模型的命名直观地反映了其设计哲学：将“思考”和“说话”分配给两个相对独立的模块。
Thinker 承担的是理解和推理职责。它读入音频特征，进行跨模态理解，产出语义表示。这个语义表示可以是文本标记，也可以是连续的语义向量，取决于具体实现。
Talker 承担的是语音合成职责。它接收 Thinker 的语义输出，生成能够驱动声码器的离散语音单元。
Thinker-Talker 与 Dual AR 最本质的差异不在于“是否拆分模块”，而在于拆分发生在哪个层级。Dual AR 的拆分发生在语音生成内部——语义生成与声学生成仍然是同一条语音合成链路上的两个阶段。而 Thinker-Talker 的拆分发生在理解与合成之间，二者之间的接口是抽象的语义表示，而不是具体的音频表征。
Thinker-Talker 的推理流程大致如下：
从表面看，这个流程与 Dual AR 相似。差异主要体现在阶段 2 和阶段 3 的内部结构和数据依赖上。
差异一：语义表示的形态不同。 在 Dual AR 中，语义标记是离散化的语音表示，与声学标记共享同一个离散序列建模框架。而在 Thinker-Talker 中，Thinker 输出的语义表示可以是连续向量，也可以是与语音 Codec 无关的文本标记。这意味着 Talker 的输入接口与 Audio Encoding 的声学特征之间不存在直接对应关系。
差异二：Speech Synthesis 对音频特征的依赖程度不同。 某些 Thinker-Talker 实现允许 Talker 完全不接触原始音频特征，只依赖 Thinker 的语义输出和可选的说话人条件向量。这种设计将 Talker 变成了一种“语义到语音”的条件生成器，其输入完全来自理解阶段。
差异三：计算热点的分布不同。 在 Thinker-Talker 中，Talker 是否需要生成多层 RVQ 取决于具体模型配置。有些实现使用较少的 RVQ 层数，将更多表达能力放在 Thinker 的连续语义表示中；另一些实现则使用较深的 RVQ 结构，此时 Talker 成为计算瓶颈。框架不能预设某种固定的计算分布。
差异四：模块间接口的抽象层次不同。 Thinker 和 Talker 之间的接口是“语义表示”，这是一个比 Dual AR 中“语义标记序列”更抽象的概念。它可以是离散的，也可以是连续的，甚至可以是多粒度的。这一抽象层次的选择对框架的接口设计影响深远。
理解了 Dual AR 与 Thinker-Talker 的差异之后，可以回到最核心的问题：推理框架的抽象应该统一到什么程度，差异化保留到哪里？
以下能力是两类架构都需要的，应当作为框架的通用基础能力来设计：
四阶段 Pipeline 的编排能力。 无论具体模型是 Dual AR 还是 Thinker-Talker，其推理流程都遵循 Audio Encoding → Understanding → Speech Synthesis → Audio Decoding 的总体顺序。框架可以提供一套通用的 Pipeline 描述机制，允许模型实现者声明各阶段的执行顺序和依赖关系。
自回归序列生成的基础设施。 位置编码、注意力机制、采样策略、停止条件管理、KV 缓存管理等，是两类架构共同依赖的基础组件。这些组件与模型的具体架构选择关系不大，适合在框架层统一实现。
离散标记的批处理与填充策略。 无论语义标记还是声学标记，都是变长序列。动态批处理、左填充、序列打包等技术对于两类架构同样适用。
CUDA Graph 的统一优化框架。 虽然不同模型的计算图形态不同，但“识别重复计算模式并用 Graph 加速”这一方法论本身是通用的。框架可以提供多图注册、图选择、图捕获与回放的基础设施，由模型适配层决定哪些模式需要注册为独立的 Graph。
以下能力的实现方式因架构而异，不应在框架层强求统一：
Speech Synthesis 的输入接口。 Dual AR 的语义生成是 Speech Synthesis 的前置步骤，其输出直接作为声学生成的条件；而 Thinker-Talker 的 Talker 接口可能完全不需要音频特征。框架应允许不同模型适配层自定义阶段间的数据传递格式。
RVQ 层级之间的依赖模式。 不同模型可能采用不同的 RVQ 生成策略：逐层独立生成、跨层联合生成、部分层并行生成等。框架不应预设某一种固定的多层生成模式。
KV 缓存的组织结构。 Dual AR 可能需要维护语义序列和声学序列的联合 KV 缓存，而 Thinker-Talker 中 Thinker 和 Talker 的 KV 缓存可能完全独立。框架的缓存管理层需要提供足够的灵活性。
计算热点的优化策略。 如果某个模型的瓶颈在 Understanding 阶段，那么框架应优先优化该阶段的长序列注意力计算；如果瓶颈在 Speech Synthesis 的多层生成，则优化重心应转向多层调度和显存复用。框架的资源分配策略需要是可配置的。
基于以上分析，一个合理的推理框架抽象应当遵循以下原则：
第一，阶段级抽象优于模块级抽象。 框架在 Pipeline 层面提供统一编排，但不深入约束每个阶段内部的具体实现。这既保证了整体流程的可管理性，又保留了模型适配层的自由度。
第二，数据流接口采用适配器模式。 阶段之间的数据传递格式不应被框架写死。框架定义通用的数据容器和依赖声明机制，由模型适配层实现具体的转换逻辑。
第三，计算优化策略与模型特性解耦。 CUDA Graph 管理、批处理策略、KV 缓存管理等优化机制，应以“可插拔策略”的方式提供，而不是以硬编码逻辑的形式嵌入框架核心。这样当新模型引入新模式时，无需修改框架本体。
第四，先理解架构再定义接口。 这是一个工程方法论层面的教训：在尚未充分理解目标模型的架构差异之前，不要急于构建复杂的抽象体系。过度抽象和欠抽象同样有害，而判断“度在哪里”的前提是对具体模型计算流程的深入理解。
Omni 模型及其推理框架主要适用于以下场景：
在这些场景中，推理框架的调度效率、显存管理能力和批处理吞吐量直接决定了系统的可服务规模与响应质量。
架构选型前先明确延迟与质量之间的权衡。 不同架构在推理延迟、语音质量和计算资源消耗之间存在不同的平衡点。Dual AR 在处理复杂韵律和音色细节时可能更有优势，但多层生成会带来更高的计算开销；Thinker-Talker 的模块解耦可能更利于独立优化理解与合成阶段，但语义接口的设计对最终语音质量有重要影响。
关注 Audio Encoding 阶段的实时性约束。 在流式语音场景中，Audio Encoding 需要支持增量处理，不能等待完整音频输入后再开始编码。推理框架需要支持分段编码和状态续传。
显存规划需要考虑多层 RVQ 的峰值占用。 多层 RVQ 生成过程中，同时活跃的序列长度可能达到语义序列的数倍。显存不足时需要通过显存回收策略和层间 Offload 来应对峰值压力。
避免在框架层过早固化模型假设。 Omni 模型仍在快速演进，新架构可能引入当前尚未预见的数据依赖模式或生成策略。框架设计应为未知的模型形态预留扩展空间，避免每新增一类架构就需要推倒重来。
Omni 模型的推理流程可以从一个统一的四阶段视角来理解：Audio Encoding 完成从波形到特征的转换，Understanding 完成从特征到语义的抽象，Speech Synthesis 完成从语义到离散语音单元的映射，Audio Decoding 完成从离散单元到波形的还原。这一流程本身是稳定的，但在具体实现层面，不同模型的架构取向差异显著。
Dual AR 架构将语音生成拆分为语义标记生成与声学标记生成两条紧密耦合的自回归路径，其挑战在于多层 RVQ 的高效调度和跨序列条件生成；Thinker-Talker 架构则在理解与合成之间划出清晰边界，其挑战在于语义表示接口的设计以及模块间数据依赖的灵活管理。
对于一个面向 Omni 模型的推理框架而言，合理的抽象边界是：在 Pipeline 编排、自回归基础设施和通用优化机制层面提供统一能力，在阶段间数据流格式、RVQ 生成模式、KV 缓存组织和计算热点策略层面保留充分的差异化空间。抽象的价值不在于消除差异，而在于让差异被限制在合适的边界内，使得系统在保持灵活性的同时，不至陷入过度设计的复杂性之中。