流式 TTS：首包延迟为什么是最该盯的指标

2026-08-24

首包延迟（TTFB）指的是从发出合成请求，到收到第一块可以播放的音频，这中间的时间。在流式语音合成里，它比”合成完整段话要多久”更能决定用户的实际体验。

这不是一个理论偏好，而是由播放这件事的性质决定的：语音是随时间线性展开的，用户不需要一次拿到全部音频，只需要在他想听的那一刻，下一块音频已经准备好。

总耗时为什么是个误导性指标

设想两个系统合成同一段三十秒的播报。

系统 A 用了五秒把整段音频生成完，一次性返回。用户点下按钮，干等五秒，然后听到三十秒语音。

系统 B 用了八秒才把全部音频生成完——总耗时明显更差——但它在开始后很快就吐出了第一块，之后边生成边送。用户点下按钮，几乎立刻听到声音，然后连续听完三十秒。

系统 B 的总耗时比 A 差，但用户体验好得多。 用户感知到的等待，只有”点击到出声”这一段；至于最后一秒的音频是什么时候生成的，只要它在被播放到之前就绪，用户永远察觉不到。

所以在流式场景下，总耗时这个指标唯一还有意义的地方是成本核算（占用了多少算力），而不是体验评估。

把首包拆开看，通常包含这几段：

这六段里，能优化的和不能优化的要分清楚。 网络开销靠连接复用，排队靠扩容和调度，剩下四段才是模型与管道层面的事。

首包快只是入场券。真正让流式播放能持续下去的条件是：

音频的生成速率，必须持续快于播放速率。

播放速率是固定的——一秒音频就要播一秒。如果生成一秒音频需要的时间超过一秒，那么播放器迟早会追上生成进度，然后卡住等待。这种卡顿出现在句子中间，比一开始多等一会儿要难受得多。

危险的地方在于，这个问题在短文本测试时不会暴露。合成一句话，缓冲区攒的那点余量足够撑到结束；换成一段长播报，缓冲区被一点点吃空，卡顿就出现在后半段。

所以流式 TTS 的健康标准是两条，缺一不可：首包够快，且生成速率有稳定余量。

一、让前端不必等完整文本。 如果上游是大模型逐字生成的回复，而 TTS 要等整段文本才开工，那前面所有的流式优化都白费。做法是按句子边界切分，第一个句子一到就开始合成。这也意味着切分策略直接影响首包——第一句越短，首包越快。

二、分块生成而不是整段生成。 声学模型和声码器都支持按块输出时，第一块的生成量就与文本总长度解耦了。

三、控制迭代步数。 迭代式的生成路线，步数是质量与延迟之间最直接的旋钮。这个取舍没有通用答案，要按你的场景试。

四、选对音频格式。 优先选能边收边播、不依赖文件头的格式，比如裸 PCM。WAV 的头部需要知道总长度才能写完整，天然对流式不友好；有损编码则要考虑编码器本身的延迟。这部分展开见 TTS 音频格式和码率怎么选。

五、别做无谓的高保真。 如果音频最终要进 8 kHz 的电话信道，合成 48 kHz 再降采样就是纯粹浪费算力，而这份算力本可以用来让首包更快。

另外，固定话术走缓存是绕开首包问题最彻底的办法——欢迎语、菜单提示这类内容根本不必实时合成。哪些内容值得缓存，见 TTS 缓存策略：哪些句子值得缓存。

不必等到有专业工具才开始测，自己就能做，关键是测对：

问：首包延迟应该控制在多少毫秒以内？

这个数字取决于场景，而且随模型、硬件、网络变化很大，给一个具体值没有意义。可参考的原则是：实时对话对首包最敏感，因为它叠加在整条对话链路的延迟预算里；有声书这类离线生成场景，首包几乎不重要。先量出你自己系统的分布，再决定优化到什么程度。

问：为什么我的首包很快，用户还是说卡？

多半是生成速率不足，卡顿出现在播放中段。用上面的方法单独测一下每块音频的到达节奏就能确认。另一种可能是网络抖动导致音频块到达不均匀，这时候需要在客户端做适当的缓冲。

问：客户端该缓冲多久再开始播？

缓冲越多越抗抖动，但首包体验越差，这是一对直接的矛盾。常见做法是缓冲一小段就起播，同时监控缓冲区水位，接近耗尽时再做处理。具体多少要结合你的网络状况实测。

问：非流式接口能改造成流式吗？

如果服务端只提供整段返回，客户端做不出真正的流式。可行的折中是在应用层把长文本切成多个请求依次发出，先到先播——本质上是把切分逻辑从服务端搬到了自己这边，代价是拼接处的韵律连贯性要自己处理。