实时语音

你跟一个语音 AI 说完话,它停顿了一下,才开口回答。 那一下"停顿",就是它不像人的地方。 人类对话的轮次间隔(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——是预算里最大的两笔开销,也是最值得花力气的地方。 一份现实的延迟预算 环节 它在做什么 典型耗时 轮次判定(VAD + 端点) 判断"用户真的说完了" 50–250 ms ASR(语音转文字) 把语音转成文字 ~0–150 ms* LLM 首 token(TTFT) 想出第一个字 250–500 ms TTS 首包 合成出第一段音频 75–200 ms 网络往返 客户端 ↔ 服务端 30–80 ms 合计(可感知) 约 500–900 ms * ASR 与用户说话并行进行,大部分转写在用户说完之前就做完了,所以它对预算的增量很小——前提是你用的是流式 ASR。 ...

约五分之一的语音通话里,用户会在 AI 还没说完时开口插话。 这个数字来自 PolyAI 对生产环境通话的统计,我自己看线上日志,感受也差不多。更值得注意的是后半句:会打断的用户,往往是意图最强的那批人。 他们听够了想直接说事,或者发现 AI 理解错了要赶紧纠正。换句话说,打断处理得烂的那一小撮通话,直接决定了你整个产品体验的天花板——因为最在乎、最着急的用户,恰好都撞在这里。 所以"能被打断"不是锦上添花的功能。它和延迟一样,是语音 Agent 的及格线。但和延迟不同,打断的难点不在毫秒,在于它是一个并发控制问题:一个事件要同时掐断好几条正在跑的流,还不能掐错。 为什么打断比想象中难 很多人第一次做打断,以为就是"检测到用户说话,调一下 audioPlayer.stop()"。上线一周就会发现到处是坑。 难在三个地方。 第一,打断是个分布式的取消操作。用户开口的那一刻,你的系统里可能同时有:扬声器在播第 3 句的音频、TTS 服务还在合成第 5 句、LLM 还在流式生成第 8 句的 token。这三样东西跑在不同进程甚至不同机器上。你要在几十毫秒内把它们一起叫停,任何一个漏网,AI 就会出现"我已经打断它了,它怎么还在自说自话"的灵异现象。 第二,判断"这算不算打断"本身就难。背景里有人说话、电视开着、用户自己"嗯"“对啊"地随口附和——这些都会让一个朴素的 VAD 兴奋地触发打断。误打断比"打断慢了"更伤体验:AI 说到一半被一声咳嗽打断,僵在那里,用户一脸问号。 第三,打断之后,对话状态是脏的。AI 那句话只说了一半就被掐了,LLM 的上下文里到底该记成"我说了整句"还是"我只说了半句”?记错了,下一轮 AI 要么重复已经说过的内容,要么基于"它以为自己说了但其实没说出口"的信息往下接。 这三件事,后面一件件拆。 怎么知道用户在打断 打断检测的第一关,是 VAD(语音活动检测)。它干一件很窄的事:判断这一小段音频里有没有人声。现代 VAD(比如 Silero)能在几十毫秒内给出"有声/无声"的概率,这一层基本算解决了。 但 VAD 只够回答"有没有声音",回答不了"这声音算不算一次真正的打断"。2026 年成熟的做法,是在 VAD 上面叠一层判断,通常叫语义化的轮次检测。 这里要分清两个相关但不同的问题: 端点检测(turn detection):用户这一轮说完了没?——决定 AI 什么时候开口。 打断检测(barge-in):AI 正在说话时,用户这声插话,要不要让 AI 闭嘴?——决定 AI 什么时候停下。 它们共用 VAD 这个底座,但上层逻辑不一样。打断检测要额外回答的问题是:这声音是"我要说话了你停下",还是"嗯哼,我在听"。 主流框架的处理方式,可以摆在一起看: 方案 核心信号 特点 朴素 VAD 音频能量 / 人声概率 最快,但把附和、噪音全当打断 转写流启发式 VAD + ASR 部分转写文本 看用户说出的字是不是"有内容" 模型化打断判定 专门小模型读音频+文本 区分真打断 / 附和 / 噪音,准但有计算开销 LiveKit 在 2026 年走的是模型路线:它的自适应打断(adaptive interruption)用真实对话音频训练了一个小模型,AI 说话期间检测到人声,不会无脑停,而是让模型先判断"这次该不该让出话权"。Pipecat 的 Smart Turn、Deepgram 的 Flux、VideoSDK 开源的 Namo,思路都类似——从"听到声音就停"升级到"听懂这是不是打断再停"。 ...

先说一个反直觉的事实:2026 年了,真正跑在生产环境、扛着电话客服流量的语音 Agent,大多数还不是端到端语音 API 做的。 端到端听起来无可挑剔——语音直接进、语音直接出,中间不落文字,延迟低、情感保留好。OpenAI 的 gpt-realtime、Google 的 Gemini Live、豆包的端到端实时语音大模型,demo 都惊艳。但真把它塞进一个要上线的产品里,你会在第二周撞上几堵墙:它说错话你没法在中间拦一道、合规团队要审通话记录而你只有一段音频、客户要换个特定音色而 API 只给你 8 个预设。 所以选型这件事,不能只看 demo 的"哇"。这篇把实时语音 API 的关键维度摊开,再把 OpenAI、Gemini 和国内几家的真实定位讲清楚,最后按场景给建议。 先把"关键维度"对齐 挑实时语音 API,大家张口就是"延迟低不低"。延迟当然重要,但它只是八个维度里的一个。我把这八个维度列出来,你拿任何一个 API 去套都不会漏: 维度 它在问什么 容易被忽略的点 延迟 用户说完到 AI 出声多久 看的是首包,不是整句生成完 打断 能不能被插话、插得干不干净 误打断(噪音触发)比慢更恼人 音色 有多少声音、能不能定制/克隆 预设音色撑不起品牌化产品 语言 支持哪些语种、能否中途混说 方言、中英混说是国内刚需 价格 每分钟多少钱、缓存能省多少 端到端按音频 token 计费,贵 是否端到端 一个模型还是 ASR+LLM+TTS 决定了下面两项 可控性 能不能拦、能不能调试、能不能换 端到端是黑盒,这点最痛 合规 有没有文字记录可审计、数据落哪 金融/政务直接卡死非合规方案 后面三项——是否端到端、可控性、合规——是连在一起的一条逻辑链,也是真正决定选型的地方。延迟和音色反而是"达标就行"的项。 OpenAI Realtime:能力最强,也最贵 OpenAI 的 Realtime API 用的是 gpt-realtime 这个 speech-to-speech 模型,语音直接进出,一个模型一个接口搞定。它的强项是指令遵循和工具调用——你给它一段复杂的 system prompt、挂十个函数,它能稳稳地按规矩走、该调哪个调哪个。这一点上,目前没有对手。 ...

Voice Agent 是什么 一句话：能听会说的AI助手。 graph LR A[用户说话] --> B[ASR语音识别] B --> C[LLM理解+生成] C --> D[TTS语音合成] D --> E[播放给用户] 看起来简单，但要做好有三个核心挑战： 延迟 - 用户说完到AI回复，要控制在1-2秒内 打断 - 用户随时可以打断AI说话 自然度 - 不能像机器人一样僵硬 核心架构 方案一：串行流水线 1 用户说话 → [等说完] → ASR → LLM → TTS → 播放 优点：实现简单 缺点：延迟高（3-5秒） 适合：对延迟不敏感的场景（如语音留言） 方案二：流式处理 1 用户说话 → [边说边识别] → [边生成边合成] → [边合成边播放] 优点：延迟低（1-2秒） 缺点：实现复杂，需要处理中间状态 适合：实时对话场景 关键组件 1. ASR（语音识别） 方案 延迟 准确率 成本 Whisper API 1-2s 95%+ 按时长计费 Deepgram 200ms 90%+ 按时长计费 本地Whisper 500ms-2s 95%+ 需要GPU 实时识别关键： ...