你问语音助手一句话，它明明已经“想好”答案，却停顿半秒才开口。单看数字，这点等待不长；放进连续对话里，却足以让人觉得它卡住了。nari-labs 开源的一套 Qwen3-TTS 1.7B 高性能实现，瞄准的正是这段沉默：让语音 Agent 更快发出第一小段声音，同时接住更多人的请求。
项目标题给出了 34 ms 的 Time to First Audio（TTFA）——从提交文字到听见第一小段音频的时间。不过，现有材料没有说明 34 ms 是最快一次、平均值还是某个百分位。正文里更明确、也更值得参考的成绩，是单张 H100 GPU 在每秒处理 10 个请求时，p95 TTFA 低于 50 ms。以下数据均来自同一篇 Reddit 帖文及其指向的 nari-labs 项目，尚无独立交叉验证。
快，不只是某一次跑得快
这里要分清两个容易混在一起的指标。
RPS（Requests Per Second）表示系统每秒能处理多少个请求，衡量多人同时使用时的吞吐能力。TTFA 则衡量单个请求要等多久才能听到第一段声音。每秒处理 10 个请求，不等于每个请求都能在 34 ms 内开口。
nari-labs 声称，在一张 H100 上，这套实现达到 10 RPS 时，p95 TTFA 低于 50 ms。p95 的意思是：把请求按等待时间排序，95% 的请求都没有超过这个数。它不像“最快一次”那么亮眼，却更接近大多数用户实际遇到的等待上限。项目同时称，此时系统还能维持实时播放，但没有给出更具体的量化指标。
继续增加负载后，吞吐量可以扩展到 20 RPS，p95 TTFA 仍低于 100 ms。换句话说，它展示的不只是抢跑出一个很低的延迟数字，而是在并发上升时，首段音频仍能较快送出。
消费级显卡也被纳入了测试
H100 是面向数据中心 AI 计算的 GPU，价格和使用场景都不同于个人电脑里的显卡。项目方还称，通过调整设置，RTX 4090 可以做到约 50 ms 的 p95 TTFA。RTX 4090 属于消费级高端显卡，这让本地部署更有想象空间。
但这两个结果不能直接横向比较。材料没有披露输入文字长度、输出音频时长、并发方式、batch（一次合并处理的请求数量）、数值精度、量化方式、采样参数，以及完整的软硬件环境。TTFA 从哪个时刻开始、到哪个时刻结束，也没有明确说明。因此，“4090 约 50 ms”更适合作为项目方展示的工程成绩，而不是任何场景下都能复现的保证。
为什么这份实现值得看
语音 Agent 的体验，很大程度上取决于它什么时候开始说，而不只是整段音频多久生成完。就像人与人交谈时，对方先自然地接一句，再继续组织后文，通常比沉默许久后一次说完更顺畅。TTFA 正是在测量这个“先开口”的速度。
更重要的是，nari-labs 不只公布了一项性能宣称，还开源了 Qwen3-TTS 1.7B 的实现与 benchmark（用于统一测量性能的测试程序或流程）。这给后来者留下了一个可以运行、检查和继续比较的工程样本。
本刊 8 月 6 日曾报道 Qwen3-TTS 语音克隆进入 llama.cpp 主线。当时的重点是本地接入更省事，性能仍待独立比较。本次则把视线转向另一条路线：用专门的推理服务，压低首段音频等待，并提高并发处理量。对低延迟语音 Agent 来说，这比单纯宣布模型“能说话”又向前走了一步。
项目方还称，这套实现相比 vLLM-Omni 和 SGLang-Omni 有“显著加速”。但材料没有提供具体倍数，也没有展示相同条件下的完整对照，因此目前只能把它视为项目方的判断，不能据此排出性能名次。
局限与未知
- 标题中的 34 ms 没有明确统计口径，与正文重点披露的“10 RPS 下 p95 低于 50 ms”并非同一个指标，不能写成普遍延迟。
- H100 与 RTX 4090 的测试缺少关键配置和输入、输出条件，外部团队能否得到相近结果仍待验证。
- “实时播放”和相对其他引擎的加速都缺少完整量化对照。现阶段，这是一份值得复核的开源工程样本，还不是已经被多方确认的性能结论。