来源：HN (164pts)
URL: https://nari-labs.com/blog/qwen3-tts-speed-cost-frontier/
精读日期：2026-08-23
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • Nari Labs 的 Qwen3-TTS 1.7B CustomVoice 实现达到 10 requests per second (RPS) 和 sub-50 ms p95 time-to-first-audio (TTFA)，在单张 NVIDIA H100 SXM 上运行。
  • 对比五种实现（Nari Labs、vLLM-Omni、SGLang-Omni、VoxServe、M*），在 Poisson open-loop 流量下测试，Nari Labs 是唯一达到 sub-50 ms p95 TTFA 的实现。
  • 成本优势显著：Nari Labs 方案在 1× H100 SXM 实例上每小时成本约 $2.69，而 ElevenLabs V3 为 $100 / 1M 字符，Cartesia Sonic 3.5 为 $49 / 1M 字符（且延迟更高）。
  • 动态前导静音裁剪可将 TTFA 提升约 80ms，但不会加速模型推理本身。
  • 在 1 RPS 下，VoxServe 达到 sub-50 ms p95 TTFA，但其他三个引擎（vLLM-Omni、SGLang-Omni、M*）均未达到；到约 6 RPS 时，所有引擎的 p95 TTFA 均升至约 100 ms 或更高。
  • 所有基准测试运行 5 分钟，使用 Poisson open-loop 流量模拟真实负载，遵循 Fireworks AI 的 LLM 基准方法；音频质量通过 Deepgram STT 评估。

二、方法/架构拆解

基准与数据集：

  • 每个引擎接收完整文本（单次 HTTP 请求），音频输出流式返回。
  • 检测 audible TTFA（首个可听样本的时间），从接收的 PCM 重建播放，并用 Deepgram STT 评估完整音频质量。
  • 上游/默认结果在 1 RPS 下测试，仅做兼容性修改；随后对每个引擎进行延迟、连续性、质量和容量调优。

Qwen3-TTS 架构：

  • 三部分模型，执行分层多码本生成：
  • Talker：预测每个音频帧的第一个码本 token。
  • Code Predictor：生成剩余 15 个码本 token。
  • Codec（因果模型）：将码本 token 转换为波形样本。
  • 每个模块有独立的计算特征、批处理行为和延迟要求。

Nari Labs 的四项核心优化：

1. 三模块统一调度：

  • 将 Talker、Code Predictor、Codec 作为三个独立可调度任务，放在同一调度面上由单一调度器管理（灵感来自 M*）。
  • 调度器可根据紧急度决定运行哪个模块，并可批处理等待同一模块的请求。
  • 保持模块分离（而非合并 Talker+Code Predictor）可创建更短的工作单元，提供更多交错机会；合并操作会成为不可抢占的阻塞单元。

2. 面向语音流式传输的调度策略：

  • 两种紧急度：首块音频前（每毫秒都增加 TTFA）和播放开始后（只需在播放结束前到达）。
  • 高优先级给未产生首块音频的请求；已建立的流仅在接近播放截止时间时才变紧急。
  • 调度器选择紧急请求作为 anchor，用兼容工作填充批次剩余空间，兼顾延迟和 GPU 效率。

3. 利用 Code Predictor 的固定结构：

  • Code Predictor 每帧固定执行 15 步，预分配 KV cache，将整个帧生成循环捕获为单个 CUDA graph。
  • 使用针对短、有界上下文优化的 Triton attention kernel，用固定 GPU 程序替代 host 驱动序列。

4. 基于缓存状态的 Codec 重建：

  • 朴素实现会重复处理完整帧历史，导致旧音频反复解码。
  • 状态缓存方案：每个请求保留 Transformer 上下文和卷积状态，增量解码只处理新到达的帧。
  • 首帧使用完整解码（避免初始化开销影响 TTFA），之后切换到状态缓存增量解码。
  • 块大小动态变化：初始小块快速启动播放，后续大块提升批处理和 GPU 效率。
  • CUDA graphs 覆盖预定义批大小集合；超出最大捕获批大小时拆分而非回退到 eager 模式。
  • 避免不必要的 CPU-GPU 同步：EOS 被抑制时延迟终止检查，让 CPU 无需等待即可准备后续工作。

三、值得注意的局限/争议

作者承认的局限：

  • 动态前导静音裁剪只改善感知延迟（~80ms），不加速模型推理本身。
  • 块大小配置需要权衡：小块降低 TTFA 但减少播放余量并增加解码频率；大块利于批处理和连续播放但延迟首块输出。
  • 各引擎的调优旋钮不同（vLLM-Omni 暴露特定设置，其他引擎有等效控制），调优过程需要迭代。

AI 判断的局限/争议：

  • 基准测试仅使用 Poisson open-loop 流量，未覆盖 burst 流量或真实用户交互模式（如多用户并发、长文本生成）。
  • 成本对比可能不完整：$2.69/小时仅考虑 GPU 实例成本，未包含工程维护、网络带宽、存储等运营成本。
  • 音频质量仅通过 Deepgram STT 评估，未进行主观听感测试（如 MOS 评分），可能遗漏自然度、韵律等问题。
  • 所有测试在单张 H100 上进行，未验证多 GPU 扩展性或跨节点部署的可行性。
  • 调度策略的复杂性可能增加工程维护成本，且对非 TTS 工作负载的通用性未验证。

四、与 RRLab 研究的关联

Harness 工程：

  • 三模块统一调度思想可借鉴到 RRLab 的模型编排层：将复杂模型拆分为独立可调度单元，用单一调度器管理，按紧急度动态分配资源。
  • CUDA graph 捕获和状态缓存模式适用于 RRLab 的推理优化，特别是对固定结构模型（如固定步数的解码器）可大幅降低延迟。

多模型协同：

  • Talker/Code Predictor/Codec 的分工模式可类比多模型协同场景：不同模型承担不同职责，调度器根据任务阶段和紧急度动态选择执行哪个模型。
  • 首块音频优先 + 后续流截止时间的双优先级策略，可推广到多模型流水线中，确保端到端延迟目标。

模型评测：

  • 使用 audible TTFA（而非首包时间）作为延迟指标更贴近用户体验，RRLab 评测体系可引入类似指标。
  • Poisson open-loop 流量 + 5 分钟压力测试 + STT 质量验证的评测框架，可作为 RRLab 模型评测的标准流程参考。

Agent 落地：

  • sub-50 ms TTFA 对实时交互 Agent（如语音助手）至关重要，RRLab 在 Agent 落地时可参考此延迟优化方案。
  • 零 underrun 的连续性保障是 Agent 语音交互稳定性的关键，调度策略可借鉴到 Agent 的流式输出管理。

AI 原生产品：

  • 成本优势（$2.69/小时 vs 竞品 $49-100/1M 字符）对 AI 原生产品的商业化定价有直接参考价值。
  • 动态块大小和状态缓存的设计理念可应用于其他流式 AI 产品（如视频生成、实时翻译），实现低首包延迟 + 高吞吐的平衡。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://nari-labs.com/blog/qwen3-tts-speed-cost-frontier/