Qwen3-TTS 低延迟部署：单卡 H100 实现亚 50 毫秒响应
团队发布 Qwen3-TTS 1.7B 定制语音流式服务方案，单卡 H100 实现 10 RPS、p95 TTFA 低于…
近日，有团队针对 Qwen3-TTS 1.7B CustomVoice 模型发布了一套低延迟流式推理方案，在单张 NVIDIA H100 SXM 上实现了 10 RPS、p95 TTFA 低于 50 ms 的性能指标，同时保证播放不出现 underrun。该团队将完整实现与 benchmark 全部开源。
与现有引擎的横向对比
文章选取了五套实现进行对比：自家方案、vLLM-Omni、SGLang-Omni、VoxServe 以及 M*。所有测试均在单卡 H100 SXM 上，使用 Poisson 开放循环流量跑满 5 分钟，模拟真实负载。
默认配置下，几个引擎表现差距明显：
- vLLM-Omni：p95 audible TTFA 约 278 ms，100% 请求出现 underrun
- SGLang-Omni：p95 TTFA 约 1141 ms，无 underrun
- VoxServe：p95 TTFA 约 315 ms，无 underrun
- M*：p95 TTFA 约 1160 ms，无 underrun
团队对每个引擎分别做了调优，包括「去除 leading silence」与「frame accumulation 调整」。前一项可把 TTFA 缩短约 80 ms，后一项通过「先小 chunk、后大 chunk」的策略在低延迟与播放安全之间取得平衡。
调优后，在 6 RPS 下，只有 VoxServe 与自家方案能压到 p95 100 ms 附近，其余三家已退化至 179 ms 以上。
统一调度器设计
Qwen3-TTS 由 Talker、Code Predictor、Codec 三个模块组成，分别负责多码本预测与波形解码。多数现有方案把前两者合并跑、Codec 单独跑，这种两阶段流水线虽然能让 token 生成与波形解码重叠，但中间边界会让合并后的单元变成不可抢占的大块工作，阻塞更紧急的 Codec 任务。
团队的方案把这三个模块都暴露为独立可调度的任务，全部纳入同一调度器管理。调度器可以决定推进哪个模块、优先处理接近播放截止时间的 Codec 任务、批量合并等待同一模块的请求，从而按紧急程度重新排列工作，而非遵循固定执行顺序。
性能与成本
最终方案在单卡 H100 上达到了以下关键指标：
- p95 TTFA < 50 ms，覆盖至 10 RPS
- 20 RPS 时 p95 TTFA 仍 < 100 ms
- 10 RPS 下吞吐量约 630 字符/秒
按云端 1× H100 SXM $4.29/小时计，满载折合约 $2 / 1M 字符。作为对比，ElevenLabs V3 报价 $100 / 1M 字符，Cartesia Sonic 3.5 报价 $49 / 1M 字符，且 TTFA 更高。这意味着在价格敏感场景下，自部署开源 TTS 的成本可压到商用 API 的 1/25 至 1/50 量级。
团队已将上述实现与 benchmark 方法论一并开源，开发者可直接基于此搭建自己的低延迟 TTS 服务。