我们基于Qwen3-TTS 1.7B的CustomVoice方案，在单张H100上实现了10 RPS、p95 TTFA低于50毫秒，并保持实时播放。经调优后，这是唯一在10 RPS下p95 TTFA低于50毫秒的方案，20 RPS时仍低于100毫秒。满负载下每百万字符成本约2美元。

好的，这是根据您的要求，对原文主要内容进行的中文重述，已保留关键细节并删减了与主题无关的内容。

标题：突破Qwen3-TTS的速度与成本极限

核心摘要：

我们基于Qwen3-TTS 1.7B模型的自定义语音实现，在单张NVIDIA H100 SXM显卡上，实现了每秒处理10个请求（10 RPS）、p95首次可听音频延迟（TTFA）低于50毫秒，同时保持实时播放。

我们对比了五种实现方案（包括我们的、vLLM-Omni、SGLang-Omni、VoxServe和M*），在泊松开环流量下进行测试。在针对低延迟流式传输进行调优后，我们的方案是唯一实现p95 TTFA低于50毫秒的。我们能在10 RPS的负载下保持这一性能，即使在20 RPS时，p95 TTFA也低于100毫秒。

在10 RPS下，我们的系统每秒可生成约630个字符。以每小时4.29美元的H100实例成本计算，满负荷运行时，每百万字符的成本约为2美元。作为对比，ElevenLabs V3和Cartesia Sonic 3.5的成本分别为每百万字符100美元和49美元，且延迟更高。

我们已将此实现和基准测试代码开源。

定义“实时”TTS

一个实时的TTS服务器需要满足四个条件： 1. 低可听TTFA：从发出请求到听到第一个音频样本的时间要短。 2. 零欠载：播放开始后，客户端缓冲的音频不能耗尽。 3. 高容量：在请求速率（RPS）增加时，前两个条件依然成立。 4. 输出无误：语音必须清晰可懂。

我们选择Qwen3-TTS CustomVoice 1.7B模型，因为它是最受欢迎且许可宽松的TTS模型之一。我们的目标是：在单张H100上，实现低p95可听TTFA、零欠载和高RPS。

所有基准测试均在泊松开环流量下运行五分钟，以模拟真实工作负载。每个引擎通过单个HTTP请求接收完整文本，音频输出则保持流式传输。

其他引擎的表现如何？

在默认配置下，各引擎在1 RPS时的表现如下： - vLLM-Omni: p95 TTFA为277.883毫秒，100%的请求出现欠载。 - SGLang-Omni: p95 TTFA为1140.69毫秒，零欠载。 - VoxServe: p95 TTFA为315.064毫秒，零欠载。 - M*: p95 TTFA为1159.956毫秒，零欠载。

这些默认配置有巨大的改进空间。我们针对每个引擎进行了调优，主要措施包括：

1. 消除前导静音：模型返回的第一个PCM数据可能包含几十毫秒的静音。我们通过动态修剪，检测并移除语音开始前的静音样本，可将TTFA改善约80毫秒。
2. 调整帧累积策略：我们调整了解码和释放音频块前收集的编解码帧数。最佳配置是：初始块较小以降低TTFA，后续块增大以保证播放连续性和GPU效率。

调优后的性能对比

经过消除前导静音和帧累积调优后，各引擎在零欠载情况下的最佳性能如下： - vLLM-Omni: 1 RPS时p95 TTFA为56.815毫秒；6 RPS时为93.451毫秒。 - SGLang-Omni: 1 RPS时为120.879毫秒；6 RPS时为273.700毫秒。 - VoxServe: 1 RPS时为49.3毫秒；6 RPS时为363.2毫秒。 - M*: 1 RPS时为104.035毫秒；6 RPS时为179.501毫秒。

VoxServe在1 RPS时达到了低于50毫秒的p95 TTFA，但到6 RPS时，所有引擎的延迟都显著增加。

我们如何优化Qwen3-TTS

Qwen3-TTS是一个三部分模型：Talker（预测第一个编解码令牌）、Code Predictor（生成剩余15个编解码令牌）和Codec（将令牌转换为波形）。我们的优化核心是统一调度这三个模块。

1. 三模块统一调度：我们将Talker、Code Predictor和Codec作为三个独立可调度的任务，交由一个调度器管理。这允许调度器根据任务的紧急程度（如接近播放截止时间的Codec任务）灵活决定优先运行哪个模块，并可以将等待同一模块的请求进行批处理。将模块分开创建了更短的工作单元，为调度器提供了更多交错处理请求的机会。

2. 围绕语音流式传输需求进行调度：语音流式传输有两种不同的紧迫性。在第一个音频块到达前，每毫秒都增加TTFA，因此需要优先处理。一旦播放开始，目标变为下一个音频块只需在当前音频播放完之前到达即可。因此，我们给予尚未产生第一个音频的请求高优先级，而已建立的流仅在接近播放截止时间时才变得紧急。调度器会选择一个紧急请求作为“锚点”，并用兼容的工作填充批次中的剩余空间，以平衡紧急请求的延迟和批处理效率。

3. 利用Code Predictor的固定结构：Code Predictor每帧固定执行15步。我们利用这一特性，预分配其KV缓存，并将整个帧生成循环捕获为单个CUDA图，同时使用针对其短上下文优化的Triton注意力内核，从而降低延迟。

4. 基于缓存状态重建Codec：为避免每次生成新音频块时都重新处理全部历史帧，我们采用了基于状态缓存的Codec。每个请求保留其Transformer上下文和卷积状态，增量解码时只处理新到达的帧。对于第一个音频块，我们使用完整解码以避免初始化开销，之后切换到状态缓存的增量解码以实现高效的持续播放。

5. 其他优化：为预定义的批次大小捕获CUDA图，避免不必要的CPU-GPU同步，并支持输入流式传输，以便上游LLM生成令牌时，TTS模型可以立即开始合成语音。

未来展望

Qwen3-TTS只是我们多模态推理工作的开始。我们计划将范围扩展到图像、视频和世界模型。我们的最终愿景是通过实时多模态推理，1:1地模拟世界。

根据评论内容，主要观点和论据如下：

1. 低延迟TTFA的重要性与优化成果 - 评论1（作者toebee）强调，对于实时语音应用，首次音频时间（TTFA）至关重要。开源实现（如vLLM-Omni、SGLang-Omni）在生产环境中往往太慢，且低延迟时可能出现实时播放问题。他们优化了Qwen3-TTS模型，在1×H100上实现了34毫秒p95 TTFA（每秒10次请求），并开源了实现和基准测试。 - 关键引用："time-to-first-audio (TTFA) is critical for realtime voice applications"；"we optimized qwen3-tts... to achieve 34 ms p95 TTFA at 10 requests per second on 1 x H100"

2. 现有语音模型的延迟与质量问题 - 评论2（作者dominotw）指出，ChatGPT响应很快，但会使用“嗯…”等填充词，随后才延迟回复。 - 评论4（作者nowittyusername）分享，经过一年构建本地语音代理，尝试多种模型后，从未实现低于200毫秒的TTFA，原因是质量权衡。许多TTS模型在音质、节奏、表达等方面仍有巨大改进空间，低延迟但低质量的折衷不值得。 - 关键引用："chatgpt responds super fast but says filler words like 'hmm..' 'let me think' and responds later with delay"；"I find that there is a lot of room for improvement in many tts models... quality of voice, cadence, expression... matters a lot"

3. 对GPT-Realtime-2的批评 - 评论3（作者bellowsgulch）认为GPT-Realtime-2表现奇怪，由于双向性，它会在尴尬时机过早用填充词回应，显得过于急切。作者更倾向于像本文这样的延迟工程优化。 - 关键引用："GPT‑Realtime‑2 is really weird... responds too soon with filler at awkward times"；"I feel like there was plenty of opportunity to just work on latency engineering like this effort"

4. 设备端运行与移动端部署的挑战 - 评论5（作者armcat）强调，真正的胜利在于设备端运行，且成本低廉（如手机），而非依赖H100。他提到Pocket TTS、Chatterbox等模型速度很快，但希望将高质量语音模型推向移动端。 - 关键引用："the real win is when this is on-device... being very inexpensive to run on a phone, and not H100"；"The quality is amazing, but can we take this to the next level and make it run on mobile?"

5. 延迟与人类感知的平衡 - 评论8（作者TZubiri）指出，速度虽好，但若不加人工延迟（或用于质量检查、护栏等），模型会显得诡异，对话尴尬。人类听觉处理延迟约200毫秒，若响应过快（如100毫秒），会被误解为打断。例如，在“我认为谋杀是坏的，但是…”中过早打断会改变语义。 - 关键引用："if you don't add an artificial latency... the model will come off as creepy"；"Humans have a roughly 200ms auditive processing latency... if someone responds in 100ms, we interpret that we interrupted them"

6. 对演示和部署的期待 - 评论7（作者MaxikCZ）询问是否有视频演示。 - 评论9（作者jmesmith）询问是否有计划在Cloudflare AI Workers等平台部署，表示很想尝试。 - 关键引用："no video demonstration?"；"any plans to make this available on cloudflare ai workers (or similar)?"

7. 理想延迟目标与端到端集成 - 评论6（作者zuzululu）认为，对于代理场景，除非LLM直接集成语音令牌，否则延迟会浪费在推理上，这正是OpenAI语音模型的优势。理想延迟在150毫秒以下，50毫秒的端到端延迟（含TTS-STT）是梦想，能达到“AI代理与人类无异”的效果。 - 关键引用："for agent scenarios unless an LLM bakes in the speech tokens directly, the latency is lost to inference"；"sweet spot is under 150ms... a 50ms turnaround including tts-stt would ofc be the dream"