实时语音链路怎么搭？级联 ASR→LLM→TTS 和端到端语音模型的取舍？
谁在问：做语音 / 实时交互场景的团队；智能客服、语音助手、面试模拟、陪练类产品的架构面
口语化问法
- 如果让你做一个能实时对话的语音助手，链路你会怎么搭？
- 现在都有端到端语音模型了，延迟比级联低得多，为什么还有人用级联？
- 用户说到一半打断 AI，这个怎么处理？
考察意图
这是一道进阶题，通常出现在真的要做语音产品的团队。面试官在判断：
- 你会不会背厂商博客的延迟数字。 各家给的"端到端 200 毫秒 vs 级联 2 秒"互相矛盾，直接背等于暴露没测过。
- 你能不能给出反向判断。 这是 2026 年这道题的核心——端到端确实自然，但它的代价有五条，每条都很具体。说得出代价的人，才是真选型过的人。
- 你有没有做过打断。 打断是实时语音的分水岭功能，而它的坑不在检测，在会话状态一致性——这个 bug 不上生产遇不到。
参考答案
60 分答案（及格线）
有两种主流做法。
级联是 ASR → LLM → TTS 三段串起来：麦克风采到音频，先转成文字，文字送给大模型生成回复，再用 TTS 合成语音播出去。好处是每一段都可以单独选型、单独优化，中间有文字所以可控性强；缺点是三段延迟叠加，而且语气、情绪这些信息在转文字的时候就丢了。
端到端语音模型（speech-to-speech）是一个多模态模型直接吃音频、吐音频，中间不经过文字。好处是延迟低、自然度高、能保留语气和情绪，也更容易做打断；缺点是可控性差，而且成本更高。
选型上，如果对自然度要求高、场景简单，可以用端到端；如果需要严格控制对话流程、需要接很多工具，级联更合适。打断的话一般用 VAD 检测用户开始说话，检测到就停止当前播放。
为什么只有 60 分：两条路的描述都对，但代价全是定性的（"可控性差""成本更高"），说不出具体差在哪、贵多少。打断只答到检测层，缺了最关键的那一步。而且没有任何工程约束层面的内容。
90 分答案（有生产经验的回答）
我先说一个反直觉的判断：不要默认端到端一定更快。
各家博客给的总延迟互相矛盾——有说级联 2 秒、端到端 200 到 300 毫秒的，也有厂商反过来说"工程良好的级联比部分端到端模型更快"。原因是级联各段在流式下是重叠的，串行加总本来就不成立。可靠的说法是：级联的瓶颈从来在 LLM 那一段，不在 ASR 或 TTS，所以杠杆在模型选型和流式重叠，不在换架构。
作为参照，人类对话轮次间隔约 200 毫秒；但同一份研究里，说一个词的言语产出准备就要 600 毫秒、短句要 1500 毫秒——人类是靠"边听边预测"做到 200 毫秒的。这正是语义 VAD 想模仿的东西。
端到端确定的代价有五条，这才是选型的真正依据：
- 上下文窄一个量级。实时语音模型多在 32K 到 128K，而同期文本模型是 20 万到 100 万。对需要塞长指令、长知识、多轮工具结果的场景，这是硬约束。
- 音频 token 贵得多。截至 2026-08，OpenAI 的音频输入是文本的 8 倍、输出 2.7 倍；国内某家的 omni-realtime 音频输入约 8.2 倍、含音频输出约 5.4 倍。
- 没有精确的文本-音频对齐。这是官方自己写的：打断截断时会同时删掉未播放的音频和它对应的文本。对齐不精确意味着 transcript 不可靠，评测和合规审计都难做。
- 指令跟随会退化。有学术评测量化过语音模型相对其纯文本底座的"遗忘率"，最差的超过 −50%。表现出来就是"工具调用不稳、复杂指令不听"。
- 审核无法前置。级联可以在用户听到之前过滤，端到端做不到——音频已经在扬声器上了。
一个现成的注脚：某家下线半级联模型后，官方论坛出现持续数月的开发者请愿，反馈半级联版本工具调用成功率明显更高，而原生音频版本强制产出音频，纯文本场景被迫白付音频 token。"端到端"不是免费升级。
所以我的选型判据是"有没有中间文本态"，而不是"快不快"。 有就能审核前置、能评测、能审计、能精确控制对话阶段；没有，换来的是自然感和情绪。强合规、强流程控制的场景选级联；追求陪伴感、业务逻辑简单的场景选端到端。混合形态也成立：主链路端到端，关键节点用文本侧状态机注入指令。
打断这件事，答到"用 VAD 检测"只是及格，它其实有三层：
- 检测层：
server_vad靠静音时长做声学切分（可调阈值、静音时长、前置填充）；semantic_vad用分类器读已经说出来的语义判断说完没有。后者才能正确处理"嗯…让我想一下"和"对对对"这类不该抢话的停顿——官方也明说它"更不容易打断用户"。 - 执行层（最关键）：检测到插话之后，取消进行中的响应还不够，客户端必须发一条截断指令，把未播放的那部分从服务端会话历史里删掉。不做这一步，模型以为自己说完了整段而用户只听到一半，此后所有轮次的上下文都是错的。这个 bug 不上生产遇不到。
- 传输层：WebRTC 和 SIP 通道会自动处理这一套；裸 WebSocket 下播放与截断全靠客户端自己管。
最后是一条几乎所有人都会漏的工程约束：浏览器端一定要有一个自建的 AppServer。 两个原因叠加——浏览器原生 WebSocket 设不了 Authorization 头，所以不能拿长期密钥直连；WebRTC 的 SDP 交换受 CORS 限制，浏览器也不能直接 POST 给厂商服务端。三家厂商殊途同归（临时凭证、ephemeral token、AppServer 代理），本质是同一个问题。任何声称"纯前端直连"的方案，一定在某处泄露了长期密钥。
至于为什么用 WebRTC 而不是 WebSocket 传音频：TCP 的队头阻塞会让丢包变成"先静音一段、再一口气爆出积压音频"，而丢一个 20 毫秒的音频帧几乎听不出来，等 200 毫秒重传却非常明显。WebRTC 还自带抖动缓冲与媒体专用拥塞控制。接大厂实时 API 时 STUN/TURN 通常由厂商兜住——只有自建 SFU、多方会议或私有化部署时这笔成本才回到你头上。
追问链
你说级联的瓶颈在 LLM 那一段，具体怎么优化？
期望三条：流式重叠（ASR 边转边送、LLM 边生成边送 TTS，不等整句）→ 首句优化（第一个语义完整的短句出来就开播）→ 降 effort（要重跑轨迹评测）。隐藏大头是跨区网络延迟，亚洲用户打美东光往返就吃掉两三百毫秒，优化模型完全没用信号说得出「流式重叠让串行加总不成立」→ 真做过链路；只说「换更快的模型」→ 没测过分段耗时端到端场景下你怎么做内容审核和质量评测？
期望只能旁路转写（音频异步转文本再审再评），两个缺陷要说清：一是滞后，已经播出去了只能事后处置；二是对齐不准 —— 打断截断会同时删掉未播放音频和它对应的文本，transcript与用户实际听到的对不上。所以高风险场景的解不是给端到端加审核，是切回级联信号指出「旁路转写有对齐问题所以评测不可靠」→ 真踩过；只说「转成文字再审」→ 没意识到对齐这一层网络抖动或者用户网差的时候，语音体验怎么保？
期望WebRTC 胜过 WebSocket 的机制三条：UDP 不做队头阻塞的重传（丢一帧无感，等重传有感）→ 抖动缓冲吸收到达时间波动 → 媒体专用拥塞控制在丢包发生前就从单向延迟变化感知到拥塞。产品侧还要降级：网差降音频码率、提示切文字输入、断线重连后注入「刚才聊到」续接上下文信号说得出「TCP 队头阻塞导致先静音一段、再一口气爆出积压音频」→ 真调过语音链路会话时长有上限，长对话怎么办？
期望截至 2026-08 各家会话上限 15–120 分钟不等（同一模型换个云还不一样），上下文只有 32K–128K，比文本模型窄一个量级。解法是会话接力：接近上限前主动开新会话，搬的是结构化对话状态而不是原始音频历史。加分项 context rot：定期压缩不只为省钱，也为保质量信号说出「搬结构化状态而不是搬音频历史」→ 真设计过长会话；只说「重连一下」→ 会在生产里丢上下文产品要求「浏览器直接跑、不做后端，这样上线最快」，你怎么答？
期望先分清「做不到」和「不建议」：① 浏览器原生 WebSocket 设不了Authorization头，WebRTC 的 SDP 交换受 CORS 限制 → ② 硬做只能把长期密钥打进前端，等于公开发布 API key → ③ 最快的是薄后端 —— 边缘函数代理 SDP、签短时效凭证，几十行两天能上。底线：key 不进 URL query信号把「做不到」和「不建议」分清、给得出两条技术约束 → 真读过文档；只说「这样不安全」拿不出替代 → 说服不了产品
评分要点
- 不背延迟数字，能指出"级联各段在流式下重叠，串行加总不成立"
- 说得出级联的瓶颈在 LLM 段，不在 ASR / TTS
- 端到端的代价能给出至少三条具体的（上下文窄、音频 token 贵、对齐不准、指令跟随退化、审核不能前置）
- 选型判据落在**"有没有中间文本态"**，而不是"快不快"
- 打断答到三层，尤其是"必须把未播放部分从服务端历史里删掉"
- 区分 server VAD 与 semantic VAD，并说得出后者解决什么
- 知道浏览器端必须有自建 AppServer，并说得出两条技术约束
- 知道 WebRTC 优于 WebSocket 的机制原因（队头阻塞、抖动缓冲）
- 压力面下能把"做不到"和"不建议"分清，并给出务实替代