语音链路地图：ASR、TTS 与实时对话的延迟账

看似最自然的交互，链路却最长

对用户来说，说话是摩擦最低的交互：不用打字，不用点按钮。但对工程来说，语音对话要串起「听完—听懂—想好—说出」四段，每一段都有自己的延迟，而人类对话里可以容忍的停顿大致只有几百毫秒——超过这个尺度，对话感就断了。语音产品的核心竞争力，很大程度上就是一段延迟工程。本文把整条链路摊开，算一算每个环节的账。

ASR：把声音变成文字，还要「听出」你说完了

ASR（Automatic Speech Recognition，语音识别）把音频流转成文字。技术上有两条脉络：传统混合系统把声学模型、发音词典、语言模型几个组件串起来，各组件单独优化、可解释性强；端到端模型用一个神经网络直接从音频到文字，训练数据吃得更多，错误分布也更整体。两条路线的取舍至今仍在，混合系统并未退场。

实时对话里，比「识别准」更关键的是两件事。一是流式识别：用户还在说，文字就要陆续出来，不能等整句说完再算。二是端点检测，俗称 VAD（Voice Activity Detection，判断音频里有没有人在说话）：要判断用户是说完了，还是只是停顿换气。判早了会打断用户，判晚了要傻等半秒——这个「尾点」的判断直接决定对话节奏，是实时性真正的关键。

LLM：首 token 决定「接话」快慢

识别出的文字交给大语言模型作答。这一环节对延迟敏感的不是总耗时，而是 TTFT（Time To First Token，首 token 延迟）：从请求发出到第一个字吐出来的时间。用户感知的「接话快慢」就取决于首 token；至于之后每秒吐多少字，影响的是听感流畅，而非「有没有在理我」。这也是推理服务的网关指标里 TTFT 被单独拎出来考核的原因——语音场景就是它最严苛的考场。

TTS：不是「念得好」，是「边生成边播」

TTS（Text-To-Speech，语音合成）把文本变成音频。现代神经 TTS 的自然度已经很高，离线场景（配音、有声书）基本过关。但对话系统的刚需是流式合成：语言模型每吐出一个词，TTS 就要立刻开始合成并播放，而不是等整句文本到齐再从头合成。流式合成的工程要求苛刻——音频要按时间轴连续供给，文本却是一段一段不规则到达的，切句、缓冲、韵律衔接都要在毫秒级内处理好。

把账算一遍

全链路的延迟账摊开来看（各环节都是定性量级，随部署而变）：

环节	等待的是什么	典型量级
VAD 判停	确认用户真的说完了	约百毫秒到数百毫秒
ASR 尾点	句尾几个词识别稳定	约百毫秒级
LLM 首 token	第一个回答字出现	约百毫秒到秒级
TTS 首音频	第一个字出声	约百毫秒级

四个环节个个「合格」，累加起来也可能超过一秒，而人类对话的自然停顿大致在几百毫秒量级。这就是语音对话难做的算术底子：每个环节都必须为延迟单独优化——判停阈值、流式识别、TTFT、流式合成——任何一个环节偷懒用「非流式」版本，全链路就垮了。

级联还是端到端

架构上有两条路线：

维度	级联（ASR→LLM→TTS）	端到端语音对话模型
结构	三个独立模块串行	一个模型直接听、直接说
延迟	各环节延迟累加	省去中间转换，天然更短
副语言信息	语气、停顿在转文字时丢失	可保留并回应情绪与节奏
可控性	模块可独立更换、日志分明、易调试	黑盒程度高，出问题难定位
复用	完全复用现有组件与模型	需专门模型与训练数据

级联胜在工程可控：语言模型换代、TTS 升级互不影响，问题可定位。端到端胜在延迟与「听得懂弦外之音」：它没有把语音压扁成文字的过程，讽刺、迟疑、语速这些副语言信息（语气、停顿等超出文字内容的信息）得以保留。当前产品大多以级联为主、逐步吸收端到端组件，两条路线的边界还在演化。

打断：对话不是轮播

真实对话里，用户听到一半不满意就会直接插话，即 barge-in（打断）。系统必须立刻停止播放、回到监听状态，并决定被打断的回答如何衔接。在级联架构里，这涉及 TTS 播放队列的即时清空与 VAD 的重新触发；在边播边听的流式系统里，还要把系统自己发出的声音与用户插话区分开——回声消除是另一个经典音频工程问题。打断处理得好不好，是用户判断「这是对话还是播放器」的分水岭。

小结

语音链路的每一环——VAD 判停、流式 ASR、首 token、流式 TTS、打断处理——单独看都是成熟技术，难点在把四五个百毫秒级环节串进人类对话的停顿预算里。级联与端到端之争，本质是可控性与延迟、自然度的取舍。做语音产品，先列延迟预算表，再谈模型能力：竞争力往往就是延迟工程本身。