拆解 Qwen3-TTS：OpenVINO 移植过程中的图分离与调度实践

TTS 并非齐次的单流前向传递。在向 OpenVINO 移植时，如何依据计算形状（Compute Shape）将模型切割为 Talker、Subcode 和 Decoder，并实现非对称流式块调度。

在上一篇中，我们在 Ultra x7 358h 平台上，从底层的内存带宽、量化算子和连续批处理框架入手，打下了推理环境的地基。但当我们将 Qwen3-TTS 的模型本身扔到这个平台上时，灾难依然发生了：如果我们直接将模型导出一个完整的 OpenVINO IR 格式的黑盒模型，不仅在核显上的生成速度极慢，而且在高并发场景下内存会迅速膨胀至 OOM。

经过对 Qwen3-TTS 底层计算拓扑的逆向工程，我发现了一个被掩盖的工程真相：现代神经 TTS 模型的推理过程，根本不是一个齐次（Homogeneous）的单流前向传递。

它实际上是由三种“计算形状（Compute Shape）”和访存模式截然不同的子系统强行拼装而成的弗兰肯斯坦。如果我们不将其进行外科手术式的“图分离（Graph Splitting）”，底层的编译器就无法针对各个阶段的物理特性实施硬件加速。

本文将深度拆解我在 exporter.py 中对 Qwen3-TTS 执行的架构切割手术，以及如何通过非对称块调度解决流式响应的延迟问题。

1. 症结所在：多码本 RVQ 带来的计算冗余

要理解为什么要拆分图，必须先弄懂神经音频 Codec 所采用的**残差矢量量化（Residual Vector Quantization, RVQ）**机制，该机制最早由 Google 的 SoundStream 和 Meta 的 EnCodec 发扬光大。

在传统的 LLM 中，语言是一维的 Token 序列，生成一个词只需要单步自回归计算。但在音频领域，要在低比特率下重建高保真波形，Qwen3-TTS 每生成一帧（12Hz），吐出的并不是一个 Token，而是一摞由 $Q$ 层码本（Codebook）组成的立体向量。这种先粗粒度预测全局语义（Talker），再通过多层网络迭代修补声学细节（Subcode）的设计，深受 Google AudioLM (Borsos et al., 2022) 架构理念的影响。

RVQ 的层级逻辑

承重墙（第一码本 $q_0$ ）：负责捕获最核心的语义和粗粒度的声学结构。生成它，需要模型回看迄今为止所有的音频历史。
精修层（后续码本 $q_1 ... q_{Q-1}$ ）：负责修补上一层量化时丢失的残差信号。

用数学表示其迭代量化过程：

r_i \;=\; x \;-\; \sum_{j<i} q_j

[ Talker: 长上下文自回归网络 ]
  (历史 Paged-KV 缓存) 
         |
         v
  < 全局 Attention >
         |
         v
 [ 帧隐状态向量 H ] --------+
         |                 |
         v                 v
   ( 第一码本 q_0 )        |   [ Subcode: 短循环残差修补 ]
         |                 +-> [ 计算残差 r_1 ]
         |                           |
         |                           v
         |                     ( 第二码本 q_1 )
         |                           |
         |                           v
         |                     [ 计算残差 r_2 ]
         |                           |
         |                           v
         |                     ( 第三码本 q_2 )
         |                           |
         v                           v
===========================================
               [ Decoder ]

O(n^2) 算力灾难

在计算拓扑上，这两者有着天壤之别：

生成 $q_0$ （Talker）的单步时间复杂度是 $O(n^2 \cdot d)$ ，由于涉及全量的历史 KV 读写，这是一个极其吃显存带宽的访存密集型任务。
生成后续的 $Q-1$ 个码本（Subcode）时，它只在当前的隐状态 $H$ 上打转，根本不需要回看历史！这是一个极其轻量的、复杂度为 $O(Q \cdot d)$ 的平移直线。

如果我们把它们硬塞进一张图里导出，编译器别无选择，只能在计算 $Q-1$ 个副码本的死循环中，每次都顺带唤醒庞大的历史 KV 缓存陪跑。这种惊人的冗余访问，会瞬间吸干 Ultra x7 358h 核显的带宽余量。

2. 代码级图分离：面向计算形状的解耦

针对上述病理，我在 qwen3_tts_ov/exporter.py 中下刀，将完整的 Pipeline 物理切断为三张各自为战的图。

2.1 剥离重型 Talker：注入 Paged-KV

将主干自回归网络剥离为 talker_stateful_batch_gqa.xml。如上一篇所述，这张图被抽干了内部的静态缓存结构，取而代之的是暴露给 C++ 运行时的指针接口。我们在编译前注入了 SDPAToPagedAttention Pass。这张图在运行时会被部署在 iGPU 上，独占经过 U8 量化的大规模内存池，心无旁骛地处理 $O(n^2)$ 的长上下文注意力。

2.2 导出极速的 Subcode 缓存图

原本附着在主干上的死循环，被切出为一个极小体积的图：subcode_greedy_cached_batch.xml。它被设计为完全无状态（Stateless），唯一依赖的输入是从 Talker 拿到的单帧隐状态 $H$ 。这意味着无论长文本生成的音频进行到第几分钟，Subcode 这部分的算力开销被锁死在了常数级底线，根本不参与 KV 缓存的带宽消耗。

# qwen3_tts_ov/exporter.py 拆图核心实现
class DynamicFusedCacheCodecStepPagedBatchGQASeedWrapper:
    def __init__(self, talker, subcode_export_mode="cached"):
        # 将 Talker 封装为支持 Paged-KV 的 GQA (Grouped-Query Attention) 变体
        self.talker = DynamicStatefulTalkerPagedBatchGQASeedWrapper(talker)
        # 依据策略将 Subcode 的残差循环分离为 Cached 无状态模式
        self.subcode = make_subcode_wrapper(talker, subcode_export_mode)

3. 流式解码挑战：首音延迟（TTFT）与左侧上下文的博弈

算完了码本 Token，还没发出声音。我们必须将这些 Token 喂给解码器（Decoder），转换为 PCM 波形流。然而，在流式服务中，这里潜伏着第二个巨大的冲突。

撕裂的音频与上下文约束

Decoder 本质上是一层层的卷积网络。为了保证每一帧拼接处不会出现破音和杂音撕裂，解码器在翻译当前帧时，必须向左“回看”一段历史波形，这被称为左侧上下文（Left Context）。

在常规配置中，我们需要凑齐一定数量的帧（比如 24 帧音频 + 25 帧历史 Context）才敢进行一次解码计算。 问题来了： 当第一段语音刚刚合成时，我们手里根本没有“25帧历史”！如果我们傻傻地等待模型产出足够的帧去填满这个窗口才开始解码，用户的**首音延迟（TTFT, Time-To-First-Token）**将飙升数百毫秒，对话的自然流媒体体验直接崩溃。

3.1 解决方案：非对称块调度 (Asymmetric Chunk Scheduling)

为了“欺骗”人类的听觉感知，并在延迟与音质之间走钢丝，我们在 build_fastest.py 编译脚本中设计了一种极端工程化的图切片策略。这不是简单的 Python 层 if-else，而是直接将两种不同行为的解码图硬编码导出并物理隔离。

# qwen3_tts_ov/build_fastest.py 参数定义
FASTEST_EXPORT_ARGS_PRODUCTION = (
    "--decoder-tokens", "256",
    "--stream-decoder-chunks", "12,24",
    "--stream-decoder-first-chunks", "8,12", # 第一块的非对称配置
    "--stream-decoder-left-context", "25",
)

激进的第一图（First Chunks）：受参数 --stream-decoder-first-chunks "8,12" 控制。这是一张极其迷你的专用解码图。它只处理前 8 帧音频，并且完全舍弃所有的 Left Context 历史约束。一旦 Talker 吐出 8 帧，系统不管三七二十一，用最快速度通过 NPU 将其转为波形并拍回给声卡。代价是起音瞬间的波形有极轻微的瑕疵。但收益是物理极限的 TTFT。在人类大脑反应过来之前，这 8 帧声音已经滑过了耳朵。
注重音质的稳态图（Steady Chunks）：受参数 --stream-decoder-chunks "12,24" 约束，并严格固化了 25 帧的 left-context。在激进的起音结束后，底层调度器（NativeCodegenRunner）会在纳秒级无缝将数据流切换（Context-Switch）到这张包含历史约束的图上，保证后续数分钟生成的音频平滑、无撕裂。

User           Talker (iGPU)        First_Decoder_Graph (NPU)     Steady_Decoder_Graph (NPU)
 |                  |                           |                             |
 |---文本请求------>|                           |                             |
 |                  | (极速生成前8帧 Token)     |                             |
 |                  |---投递8帧(无上下文)------>|                             |
 |<---首字节语音----|                           |                             |
 |  (极速 TTFT)     |                           |                             |
 |                  |                           |                             |
 |============ [ 持续生成循环 ] ================================================|
 |                  |                           |                             |
 |                  | (稳态生成后续24帧 Token)  |                             |
 |                  |---投递24帧(带25帧历史)--------------------------------->|
 |<---平滑语音------|                           |                             |
 |============================================================================|

4. 落地：C++ 接管调度大权

面对这三套性格完全不同、且执行频率极高的网络图：

iGPU 上的重型 Talker（依赖 Paged-KV）
iGPU 上的无脑超快 Subcode 循环
NPU 上频繁切换环境的 First / Steady Decoder 状态机

如果用 Python 在上层通过循环来调度它们，Python GIL（全局解释器锁）的抖动会瞬间吞噬掉前面所有的优化心血。

最终的答案只能是原生语言。在项目的 native/ 目录下，所有基于 OpenVINO Tensor 的内存指针流转，全部在 C++ 层利用 libqwen3_tts_ov_genai.so 闭环。Python 调度器仅仅负责业务级的准入和超时控制，不再接触繁重的张量调度。

5. 总结

在异构平台上移植和压榨大语言模型的过程，实际上是一场精细的外科手术。

很多研究仅停留在如何导出 ONNX 文件，却忽略了算法内部因为计算拓扑差异导致的性能黑洞。针对不同的瓶颈特征——是带宽受限（Talker）、算力受限（Subcode）、还是延迟敏感（Decoder）——我们在物理上将其拆解为分离的图，并将它们挂载到 Ultra x7 358h 的不同子处理器上。在完成了算子量化、图解耦与异构分发之后，系统的木桶理论来到了最后一块短板：如何精细控制 Paged-KV 在高并发下的准入算法？接下来，我们将把目光转回调度器的“大本营”：无 vLLM 环境下的 Paged-KV 与连续批处理调度。