那一下"停顿",就是它不像人的地方。

人类对话的轮次间隔(turn-taking gap)中位数只有约 200ms,熟悉的人之间还经常"抢话"——下一句在上一句结束前就接上了。一旦 AI 的回应超过 500ms,你会明显感觉到"它在想";超过 800ms,对话就开始别扭,你会忍不住重复自己,或者以为它没听见。

所以做语音 Agent,延迟不是"优化项",是及格线。这篇把从【用户说完最后一个字】到【AI 喇叭里出第一个音】之间发生的事,拆到毫秒。

这条流水线长什么样

flowchart LR
  A[用户说话] --> B[轮次判定
VAD + 端点]
  B --> C[ASR
语音转文字]
  C --> D[LLM
首 token]
  D --> E[TTS
首包音频]
  E --> F[AI 出声]
  style B fill:#fde7c2,stroke:#e8b23c
  style D fill:#fde7c2,stroke:#e8b23c

橙色的两块——轮次判定和 LLM 首 token——是预算里最大的两笔开销,也是最值得花力气的地方。

一份现实的延迟预算

* ASR 与用户说话并行进行,大部分转写在用户说完之前就做完了,所以它对预算的增量很小——前提是你用的是流式 ASR。

逐段拆开

轮次判定:延迟里的隐形大头

最容易被忽略、又最肥的一块。

很多系统用一个固定的"静音超时"来判断用户说完了——比如静音持续 700ms 就认为该 AI 说话了。问题是:这 700ms 是凭空加在每一句话上的延迟,而且用户说话中间正常的停顿(想词、换气)还会触发误判。

2026 年更好的做法是语义端点检测(semantic turn detection):用一个很小的模型实时判断"这句话在语义上说完了没"。“我想订一张去——“显然没说完,哪怕这里静音了 800ms;“我想订一张去北京的机票"说完了,300ms 就可以接。把固定静音超时换成语义判定,这一段常常能从 250ms 砍到 100ms 以内。

ASR:让它和说话并行,就几乎不要钱

ASR 唯一的纪律是:必须流式。流式 ASR 一边听一边转写,用户说完时文字基本也就好了,只剩最后一个分块的尾巴。如果你用的是非流式(“等录音结束再整段识别”),那等于把整段语音时长又加回了预算——一句 3 秒的话就白白多 3 秒。这是新手最常见的坑。

LLM 首 token:最大的一块,也最难压

LLM 拿走了预算里最大的份额,因为它最难在不牺牲回答质量的前提下压缩。

关键认知:你要的是 TTFT(首 token 延迟)低,不是"整段生成快”。用户只需要尽快听到第一个字,后面的边生成边说。能压 TTFT 的手段:

• 缩短 system prompt——每一个 token 都要参与首次前向计算
• prompt caching——把固定的前缀缓存住,省掉重复的 prefill
• 小模型兜首句——用一个快模型先回"嗯"“好的,我看一下”,大模型在背后接管
• 投机解码 / 更近的推理节点——把网络和排队的尾巴削掉

TTS 首包:同样只看"第一段”

和 LLM 一个道理——要流式 TTS,**首包(time-to-first-audio)**出来就播,别等整句合成完。再把 LLM 的输出按标点/句子切块,边出边喂给 TTS。现代流式 TTS 的首包能做到 75–200ms。

流式的魔法:感知延迟 ≠ 真实延迟

这是整套设计的核心。

一次完整回答的真实总耗时可能有 1.5 秒甚至更长。但用户感受到的延迟,只是到第一个音的那段时间——因为 LLM 还在生成后半句时,前半句已经在用户耳朵里播了。

flowchart LR
  L1[LLM: 生成第1句] --> L2[LLM: 生成第2句] --> L3[LLM: 生成第3句]
  L1 -.切块.-> T1[TTS+播放 第1句]
  L2 -.切块.-> T2[TTS+播放 第2句]
  L3 -.切块.-> T3[TTS+播放 第3句]

所以工程上的铁律:这条链路上任何一环都不能"攒齐再传”。VAD、ASR、LLM、TTS,全部流式串起来,一环阻塞,整条链路的"感知延迟"就塌回成"真实延迟"。

打断(barge-in):不只是"停 TTS"

人会打断。语音 Agent 必须能被打断,而且打断要干净。

用户插话时,要做的不止是停掉正在播的音频,而是四件事一起:

1. 停止 TTS 音频播放
2. 取消还在合成的 TTS 任务
3. 取消还在生成的 LLM 请求
4. 重置整条流式管道的状态

漏掉任何一步,AI 要么跟你抢着说,要么在你打断之后还要"把上一个念头说完"。

另一个反方向的坑是误打断:背景噪音、旁边人说话、你自己的"嗯哼",都可能被当成插话。解法是带说话人意识的 VAD(personalized VAD),只对"主说话人"的语音触发打断。

级联 vs 端到端:2026 年怎么选

• 级联(ASR → LLM → TTS):三个模块各自独立。可控、可调试、每一环都能单独监控和替换。2026 年它仍然是生产环境的默认选择,尤其是电话客服这种强管控、强合规的场景。
• 端到端语音模型(speech-to-speech):语音直接进、语音直接出,中间不落文字。延迟更低,情感和韵律保留得更好(信息没有在"转成文字再转回来"的过程中丢失)。代价是难调试、难审计、难合规。

我的判断:别把它当成二选一。强管控场景用级联;Web 端的陪伴、互动类产品可以上端到端;成规模的团队最后大概率是两套都跑,按场景路由。

最后:工程优先级别搞反

如果你在做语音 Agent,优化的顺序应该是:

1. 先把流式管道打通——确保没有任何一环在"攒齐再传"。这一步的收益最大,而且不花钱。
2. 再砍轮次判定——把固定静音超时换成语义端点检测。
3. 最后才去抠 LLM——换小模型、上 prompt caching、投机解码。

很多团队一上来就盯着"换个更快的大模型",但如果你的管道根本不是流式的,换什么模型都救不回那种"慢半拍"的感觉。先把链路理顺,再谈毫秒。

这不是魔法,是流式 TTS 的基本盘。差别在于:你是等整句音频生成完再播,还是第一个音频块一出来就往用户耳朵里塞。前者用户等 1.2 秒,后者等 150ms——同一个模型,同样的算力,体验差一个数量级。

我在《实时语音对话的延迟预算》里把整条语音 Agent 链路拆过一遍,TTS 那一段只给了一句话:“要流式,首包出来就播。“这篇把那一句话展开,只讲 TTS。

为什么是"首包”,不是"整句”

先说清楚一个被混淆得很厉害的指标。

很多 TTS 厂商的官网首页挂着"实时率 0.3"或者"合成速度比真人快 3 倍"——这说的是整句合成耗时:一句 5 秒的话,1.5 秒合成完。这个数字对离线场景(把一本书转成有声书)有意义,对实时对话几乎没意义。

实时对话里真正决定体验的是 TTFA(time-to-first-audio,首包音频延迟):从你把文字喂给 TTS,到第一段能播放的音频抵达用户、开始出声,中间隔了多久。

道理和流式 LLM 一样。LLM 看的是首 token 延迟(TTFT),不是整段生成完的时间;TTS 看的是首包,不是整句。因为一旦第一个音节开始播,后面的音频是边合成边播的——只要合成速度比播放速度快(实时率小于 1),用户就永远听不到"卡壳"。整句要 1.5 秒还是 3 秒,用户根本感知不到,他在听前半句的时候,后半句已经悄悄合成好排在缓冲区里了。

所以这篇标题里的"150ms",指的是 TTFA。这是 2026 年一个够格但不极致的数字:对话不会让人觉得"AI 在想",但还没到 Cartesia Sonic-3 那种 40ms 模型延迟的极限。

有个数字陷阱要先点破。厂商宣传的"75ms"或"100ms"通常是纯模型推理时间——在一块独占 GPU 上,喂一段短文本,模型吐出第一块音频要多久。它不含网络往返、不含 API 网关排队、不含音频编码、不含你播放器的缓冲。一个 benchmark 跑 100ms 的模型,部署在共享云上、赶上流量高峰,端到端能轻松飙到 800ms。所以看 TTFA 数字,永远要问一句:这是模型延迟,还是用户真实感知到出声的延迟?这篇说的 150ms,是后者。

首包延迟花在哪

把 TTFA 拆开,大致是这么几块:

看这张表,有两件事值得拎出来说。

第一,播放器缓冲常常是最肥的一块,也最容易被忽略。工程师盯着模型延迟抠了半天,把模型从 120ms 压到 80ms,结果播放器为了抗抖动设了 200ms 缓冲——白忙活。这块后面单独讲。

第二,网络往返是固定成本,且省不掉,只能靠部署位置压。一次上下行加起来 40–160ms,如果你的 TTS 服务在弗吉尼亚,用户在上海,光物理距离就吃掉 200ms 以上。这部分不优化,模型再快也是纸面数字。

怎么把它压下去

按收益从大到小排,六个手段。

1. 流式合成:这是地基,不是优化项

如果你的 TTS 是"等整句文本到齐 → 整段合成 → 整段返回",那前面所有讨论都不成立。流式 TTS 的协议(通常是 WebSocket)允许文字一边到一边合成:LLM 还在生成后半句,前半句的音频已经在合成了。

2026 年主流的实时 TTS 都走这条路。ElevenLabs Flash 官方标的端到端 135ms TTFB;Cartesia Sonic-3 靠 SSM(状态空间模型)架构做到 40ms 首包、90ms 模型延迟;Deepgram 的 Voice Agent TTS 标 sub-200ms。这些数字的前提全是流式——没有流式,谈不上首包。

2. 按句/标点分块,而不是按字数

LLM 吐出来的是 token 流,你不能每来一个 token 就喂给 TTS——那样韵律会碎成渣。你需要在中间攒一个最小可合成单元再发。

分块策略大致三种:

• 固定字符数(比如 150–300 字符):延迟可预测,但会从句子中间切开,韵律遭殃。
• 句子/标点边界:在句号、问号、逗号处切。韵律自然,但延迟不固定——遇上一个长句,首块迟迟攒不齐。
• 动态自适应:首块用最激进的策略(凑够一个短语就发),后续块按标点切。

我的建议很明确:首块和后续块用不同策略。首块只追求"快"——攒到第一个逗号、或者凑够一个能独立成韵的短语(7–10 个字)就立刻发出去,让用户尽快听到声。从第二块开始切回句子边界,保住整体韵律。用户对首块的韵律宽容度其实很高,他在乎的是"AI 开口了没";但要是整段都按短语切,听感就会一顿一顿的。

3. 模型预热:别让第一个用户当小白鼠

冷启动是隐形杀手。一个刚拉起的 TTS 实例,第一次请求往往要额外几百毫秒——CUDA context 初始化、模型权重换入显存、KV cache 分配。

解法是预热:实例就绪后、接真实流量前,先用一段哑文本跑几次完整合成,把所有 lazy 初始化的路径走通。配合发布策略——新实例预热完成才进负载均衡的轮转。否则每次扩容、每次滚动发布,都会有一批倒霉用户撞上冷启动的尾巴。

4. 合成与播放重叠

这是流式 TTS 的核心收益,也是最容易在实现上漏掉的地方。原则一句话:链路上任何一环都不能"攒齐再传"。

flowchart LR
  L[LLM 输出 token 流] -->|按标点切块| C1[文本块1]
  L -->|按标点切块| C2[文本块2]
  L -->|按标点切块| C3[文本块3]
  C1 --> T1[TTS 合成 块1]
  C2 --> T2[TTS 合成 块2]
  C3 --> T3[TTS 合成 块3]
  T1 --> P[播放队列
边收边播]
  T2 --> P
  T3 --> P
  P --> S[用户听到连续语音]

块 1 在播的时候,块 2 在合成,块 3 的文本还在 LLM 里生成。三件事并行。只要合成速度跟得上播放速度,用户听到的就是一条不断的声音。一旦某一环改成"等齐",感知延迟立刻塌回真实延迟。

5. 就近部署

网络往返省不掉,但能缩短。把 TTS 推理节点放在离用户近的区域,40–160ms 的往返能压到几十毫秒。对全球业务,这意味着多区域部署 + 按用户地理位置路由。这条不涉及任何模型技巧,纯靠基建,但收益实打实。

6. 选对音频格式

回传格式直接影响首包能多快"可播"。这里有个反直觉的点:很多 TTS 流式返回的头几个字节根本不是音频,而是容器元数据——WAV 头、Ogg 识别页、MP3 的 ID3 标签。播放器要等这些 + 第一个真实音频帧才能起播。

实时场景优先用裸 PCM(比如 pcm_22050):没有容器头,第一个字节就是可播音频,省掉解析开销。代价是带宽——PCM 不压缩,流量大。带宽敏感就退一步用 Opus,它的帧结构对低延迟友好,别用 MP3。

首包延迟、音质、成本:三角取舍

没有免费的午餐。把首包压到极限,一定在别处付了代价。

我的取舍偏好,按场景分:

实时对话(客服、语音助手):首包延迟优先,音质够用就行。用户在打电话,他不会拿着话筒细品音色,他要的是不卡、不等。这种场景我会接受首块韵律略糙,换 150ms 的 TTFA。

有声内容(播客、有声书、视频配音):音质优先,首包延迟根本不是问题——这是离线批处理,慢就慢。该上最好的模型、最细的韵律控制。

成本敏感的规模化场景:别盲目追 P50。真正影响体验的是 P99——你不能让 1% 的用户等 2 秒。Cartesia 用 SSM 架构主打的卖点就是 P99 比 transformer 稳,因为 SSM 是线性扩展、不像 transformer 那样随序列长度二次膨胀。规模一大,P99 的稳定性比 P50 的漂亮数字值钱得多。

一句话:先明确你在哪个场景,再谈压到多少毫秒。脱离场景比拼 TTFA 数字,是营销,不是工程。

实践中真正会咬人的坑

前面讲的是怎么做对。这一节讲怎么做错——这些坑我和身边的人基本都踩过。

坑一:分块切太碎,韵律断裂。 为了压首包,有人把分块阈值设得很激进,每凑 3–5 个字就发一块。结果 TTS 拿到的全是没头没尾的碎片,它无法预测句子级的语调走向——该升调的地方平了,该停顿的地方连上了,整句听起来像机器人念词卡。根因是流式 TTS 在局部上下文下做韵律预测,缺了句子的全局结构。务实的做法:首块可以碎(用户宽容),但从第二块起一定切回标点/句子边界,把韵律的锅甩给完整的句子。

坑二:首块太短,反而更慢。 听起来矛盾——首块越短不是越快发出去吗?但太短的首块(比如 2 个字)会触发两个问题:一是 TTS 对超短文本的相对开销更高(prefill 的固定成本摊不开);二是它播完只要零点几秒,而第二块还没合成好,中间出现空隙,用户听到"你好……(停顿)……我是客服"。首块不是越短越好,要够短到快、又够长到能撑住后续块的合成时间。经验值是凑够一个完整短语,7–10 个字。

坑三:缓冲欠载(buffer underrun)导致卡顿。 播放器从网络收音频块,凑够一点就开播。如果某一块因为网络抖动或合成慢迟到了,播放队列被掏空——这就是缓冲欠载,用户听到爆音或者卡顿。

缓冲设置是个跷跷板:缓冲小,起播快(TTFA 低),但抗抖动差;缓冲大,起播慢,但播得稳。没有放之四海的数值。数据中心内部、网络稳定,50–100ms 缓冲够了;移动端、网络飘忽,得放到 150–250ms 来吸收抖动。

更关键的是把欠载率当独立指标监控,别只看 TTFA。一个务实的阈值:如果缓冲欠载超过请求总数的 2%,就该调大缓冲——哪怕这意味着 TTFA 涨几十毫秒。卡顿对体验的伤害,远大于首包慢那一点点。慢半拍用户能忍,中间卡一下用户立刻出戏。

坑四:只测了模型,没测端到端。 回到开头那个数字陷阱。你在本地用独占 GPU 测出 80ms 首包,上线后用户反馈"AI 反应慢"。因为真实链路上还叠着网络、网关排队、编码、播放器缓冲。测 TTFA 一定要从用户视角测——从发出请求到扬声器真正出声,端到端打点,而且要测 P99,不是 P50。

落地优先级

如果你正在做 TTS 这一段,顺序是这样:

1. 先确认是流式的,而且整条链路没有任何一环"攒齐再传"。这步收益最大、几乎不花钱。
2. 调分块策略——首块激进、后续块按标点。这步直接决定 TTFA 和韵律的平衡。
3. 加预热,别让扩容和发布把冷启动甩给用户。
4. 测端到端 P99,把播放器缓冲和欠载率纳入监控。
5. 最后才谈就近部署、换更快的模型——这些是基建和钱的问题,放在管道理顺之后。

很多团队一上来就到处比价"哪家 TTS 首包最低"。但如果你的播放器缓冲设了 250ms、链路里还藏着一个"攒齐再传"的环节,换哪家模型都救不回那种慢半拍。先把自己这边的链路理顺,再去谈毫秒。

参考来源:ElevenLabs Latency 文档 · Cartesia Sonic-3 · Gradium: Best Low-Latency TTS APIs 2026 · Deepgram: Streaming TTS Latency Tradeoff · Picovoice: TTS Latency