HN讨论 · 身份未知
实时语音 TTS 的延迟痛点与 34ms p95 TTFA 开源优化方案
实时语音应用依赖极低的 time-to-first-audio（TTFA）；vLLM-Omni、SGLang-Omni 等开源实现生产环境往往太慢，强行压低延迟还可能出现实时播放问题。作者团队优化开源 TTS 模型 qwen3-tts，在 1×H100 上达到 10 req/s 时 p95 TTFA 34ms，并开源实现与基准。
查看原始信号hn:49389952
目标用户
构建实时语音交互、语音对话或实时配音等应用的开发团队，尤其是需要低首帧延迟开源 TTS 方案的工程师。
潜在需求
需要能稳定支撑生产环境、具备极低首帧延迟（亚 50ms 级）的 TTS 推理方案，并希望有可复现的优化方法与基准，而不是只能用于演示的模型。
发生场景
在实时语音应用中，从输入文本到听到首个音频的耗时（TTFA）是关键体验指标。开发者在选用开源 TTS 推理方案时，vLLM-Omni、SGLang-Omni 等实现往往无法满足生产环境的延迟要求，若强行压低延迟又会出现实时播放不稳的问题。
来源证据
作者称 TTFA 对实时语音应用至关重要，vLLM-Omni、SGLang-Omni 等开源实现生产环境往往太慢，强行压低延迟会引发实时播放问题；其团队已把 qwen3-tts 优化到 1×H100 上 10 req/s 时 p95 TTFA 34ms 并开源。
time-to-first-audio (TTFA) is critical for realtime voice applications. open source implementations (e.g. vLLM-Omni, SGLang-Omni) are often too slow for production and can have issues with realtime playback if you push for lower latency. we wanted to fix that. we optimized qwen3-tts, a popular OSS TTS model, to achieve 34 ms p95 TTFA at 10 requests per second on 1 x H100. we open source the implementation and benchmark, as well as a breakdown of how it was done. github:https://news.ycombinator.com/item?id=49389952
为什么值得留意
这个信号不是泛泛的性能宣传，而是针对开源 TTS 方案在生产环境中延迟不足的具体阻碍，给出了明确指标（34ms p95 TTFA）和开源实现；对预算有限的独立开发者，低延迟实时语音链路的搭建与验证通常是高成本难点，这类可复用经验值得跟进。
已有方案
- vLLM-Omni
- SGLang-Omni
- qwen3-tts（被优化的开源 TTS 模型）
未满足部分
- 现有开源实现生产环境延迟不足，压低延迟时实时播放易出问题
可能延伸 · 模型推测
- 推测：将类似优化经验应用到其他 TTS 或多模态模型
- 推测：在非 H100 或更低算力设备上复现该延迟基准
- 推测：把延迟优化与流式播放客户端集成，形成可部署的实时语音链路
目前未知
- 信号来自项目作者本人，非独立用户报告
- 延迟数据仅在 1×H100 上测试，未覆盖其他硬件
- 未提供与 vLLM-Omni、SGLang-Omni 的详细对比方法
- 缺少真实网络和客户端播放链路的端到端验证
继续核实
- 其他开发者使用 vLLM-Omni 或 SGLang-Omni 时是否遇到类似的 TTFA 生产瓶颈？
- 34ms p95 TTFA 在不同硬件、并发和模型版本下表现如何？
- 该开源优化是否有实际部署案例或真实用户反馈？
- 现有开源实现的延迟问题是否普遍存在，还是仅在这一场景下突出？
主题词
time-to-first-audioreal time voice applicationtext-to-speech latencyinference optimizationopen source tts