Turn Detector v1.0- 语义轮次检测VAD

语音智能体最容易暴露“机器感”的地方，往往不是大模型回答得不够聪明，而是它不知道什么时候该接话。用户在句中稍作停顿，机器人便抢先开口；用户已经明确说完，机器人却仍然等待。前者破坏表达，后者制造尴尬的空白。

2026 年 6 月，LiveKit 发布 Turn Detector v1.0，将轮次结束检测从“读取转写文本”推进到“直接聆听语音”。新模型把语义理解与声学、韵律信号融合起来，并同步开放 eot-bench 基准与 14 种语言的真实人机对话评测数据。按照 LiveKit 公布的结果，完整版 v1 在其评测的模型中给出了最优的延迟—误截断前沿。

LiveKit 对这次发布的定位十分激进：对于基于 LiveKit 构建的智能体，他们认为端到端轮次检测已经成为一个“基本解决”的问题。不过，这一结论目前主要来自 LiveKit 自己设计并公开的基准，仍值得第三方在不同领域、口音和噪声条件下独立复现。

一、背景：停顿不等于说完

传统语音系统通常依靠 VAD（Voice Activity Detection，语音活动检测）判断音频中有没有人声，再设置一个静音计时器：静音达到若干毫秒，就认为用户已经说完。这种方法能够发现“停顿”，却无法理解“停顿的含义”。

例如用户说：“我要一个大号披萨……”并在“披萨”后停顿。此时他可能已经结束点单，也可能准备继续说“……再来一份蒜香面包”。在停顿发生的瞬间，两种情况的转写文本完全相同。文本模型无论多强，都无法从相同的文字中恢复已经丢失的语调、音高和节奏。

  • 只靠 VAD：知道用户停了，却不知道用户是否准备继续。
  • VAD 加文本语义模型：能理解句子是否完整，但受 STT 错误和转写延迟限制。
  • 音频语义与声学融合：同时理解“说了什么”与“怎么说”，这是 v1.0 的路线。

文本路线的三重上限

  1. 判断上限受 STT 质量约束：漏字、错字、断句方式和数字格式都会改变语义判断。
  2. 必须等待转写结果：模型不能在最终文本到达前完成判断，STT 尾部延迟会直接叠加到智能体响应时间。
  3. 副语言信息永久丢失：尾音上扬、音高下降、重音、语速和节奏无法从纯文本中可靠恢复。

这也是 LiveKit 从上一代文本模型转向 v1 音频模型的核心原因：要继续提高轮次判断质量，就必须“停止阅读，开始聆听”。

二、LiveKit Turn Detector 的三代演进

阶段输入与架构关键机制主要特征
初代（2024）转写文本 + Transformer根据对话文本预测用户是否结束表达把纯静音计时升级为语义判断
v0.4.x（Hugging Face 公开模型）Qwen2.5-0.5B-Instruct 文本模型预测下一个 token 是否为 <|im_end|>；按语言使用不同阈值由 7B teacher 蒸馏，INT8 ONNX，可在 CPU 运行
v1 / v1-mini（2026）原始音频 + 语义分支 + 声学分支 + Fusion直接融合语义、语调、音高、节奏和时序信息不依赖转写，只需当前用户轮次；v1 为云端完整版，v1-mini 为 CPU 优化开放权重版

重要版本说明：用户常见的 Hugging Face 仓库 livekit/turn-detector 当前模型卡主要描述 v0.4.x 文本路线，而不是本文重点讨论的 v1 音频双分支模型。模型卡中的 Qwen2.5-0.5B、最多 6 轮上下文、128 token、INT8 ONNX 和按语言阈值等参数，不应直接套用到 v1 或 v1-mini。

上一代文本模型如何判断轮次结束

v0.4.x 会把最近的对话按 Qwen Chat Template 格式化，但故意不在最后一条用户消息后添加 <|im_end|>。模型随后计算这个结束 token 成为下一个 token 的概率：

\(P_{\mathrm{EOT}} = P\!\left(y_s = \texttt{<|im\_end|>} \mid y_{<s}, x\right) = \mathrm{Trfm}(y_{<s},x)_{\texttt{<|im\_end|>}}\)

如果该概率超过对应语言的阈值，系统便倾向于认为用户已经说完。这个方案比单纯 VAD 更懂句意，但它仍要先经过 STT，也无法使用语调和韵律。

三、v1.0 模型设计：语义与声学双分支融合

Turn Detector v1 的输入是当前用户轮次的音频，而不是转写文本。模型内部并行处理两类信号，最后输出用户已经结束当前轮次的概率。

模块公开结构职责
语义分支音频编码器 → 可学习适配器 → 微调语言模型理解音频表达的内容，即“说了什么”
声学分支独立音频编码器 → 循环层捕捉时序、语调、音高走势、节奏与停顿形态，即“怎么说”
融合模块Fusion合并两路表征，输出单一的端到端轮次结束概率

可以用下面的概念公式表达官方公开的架构关系。该公式是对模块连接方式的抽象，不代表 LiveKit 已公开的精确网络层数或参数配置：

\( h_{\mathrm{sem}}(t)=\mathrm{LLM}\!\left(A\!\left(E_{\mathrm{sem}}(x_{1:t})\right)\right) \) \( h_{\mathrm{ac}}(t)=\mathrm{RNN}\!\left(E_{\mathrm{ac}}(x_{1:t})\right) \) \( p_{\mathrm{EOT}}(t)=\sigma\!\left(W_f\,[h_{\mathrm{sem}}(t);h_{\mathrm{ac}}(t)]+b_f\right) \)

其中，x₁:ₜ 表示截至时刻 t 可见的因果音频；E_sem 和 E_ac 分别表示语义、声学编码器；A 是把音频表征投影到语言模型 embedding 空间的可学习适配器；σ 将融合结果映射为轮次结束概率。

LiveKit Turn Detector model architecture: parallel semantic and acoustic branches combined in a fusion module

这套设计带来的两个直接收益

  • 取消等待最终转写的成本：推理可以直接沿音频流进行，STT 尾部延迟不再是轮次检测的必要组成部分。
  • 缩短上下文：声学分支对当前轮次提供了很强的结束信号，v1 不再像文本版本那样依赖此前多轮对话，只观察当前用户轮次即可完成判断。

需要注意，“没有转写延迟”不等于“响应延迟为零”。系统仍需在避免抢话和快速接话之间选择工作点；模型推理速度与端点策略等待时间也是两个不同概念。

四、eot-bench：把“听起来更自然”变成可复现指标

过去，各家轮次检测厂商通常在私有数据上使用自己的方法评测，结果很难横向比较。LiveKit 因此同步开源 eot-bench，并提供真实人类与语音智能体对话的数据集。数据覆盖阿拉伯语、中文、荷兰语、英语、法语、德语、印地语、印度尼西亚语、意大利语、日语、韩语、葡萄牙语、西班牙语和土耳其语，共 14 种语言。

这里还有一个容易忽略的版本差异：eot-bench 的 14 语种包含阿拉伯语、不包含俄语；上一代 Hugging Face 文本模型的 14 语种则包含俄语、不包含阿拉伯语。讨论“支持 14 种语言”时，应明确是在说哪个版本和哪套评测数据。

评测对象不是孤立音频片段，而是每一次真实停顿

每条数据是一段完整的用户轮次，标注其中所有不少于 100ms 的静音区间。最后一个静音区间标为 eot，代表真正的轮次结束；此前的静音全部标为 hold，代表用户只是犹豫或换气，系统应该继续听。

  • 在 hold 停顿中提前触发，计为 false cutoff，即误截断或抢话。
  • 在真实 eot 后等待过久，会增加用户可感知的 conversational dead air。
  • 评测严格采用因果输入：时刻 t 的模型只能看到时刻 t 之前已经出现的音频与上下文。

完整端点策略的三个旋钮

  1. threshold：结束概率必须超过的置信度阈值。
  2. action_delay：系统允许根据模型分数采取行动前，至少需要经历的静音时长。
  3. timeout：即使模型一直没有触发，系统也必须结束等待的最大静音时长。

若把阈值写作 τ、最小行动延迟写作 d、超时写作 T，则一次停顿中的实际触发时刻可以概括为：

\( t_{\mathrm{fire}}=\min\!\left(T,\;\max\!\left(d,\inf\{t:p_{\mathrm{EOT}}(t)>\tau\}\right)\right) \)

设第 i 个句中停顿的实际长度为 Dᵢ，那么 eot-bench 策略扫描中的误截断率可写成：

\( \mathrm{FCR}=\frac{1}{N_{\mathrm{hold}}}\sum_{i=1}^{N_{\mathrm{hold}}}\mathbf{1}\!\left(t_{\mathrm{fire},i}<D_i\right) \)

对真实轮次结束样本，端点延迟是模型触发时刻；若模型未触发，则按超时值计算。平均延迟为：

\( \overline{L}=\frac{1}{N_{\mathrm{eot}}}\sum_{j=1}^{N_{\mathrm{eot}}}t_{\mathrm{fire},j} \)

eot-bench 会联合扫描阈值、行动延迟和超时，而不是只比较某个厂商手工挑选的单一阈值。默认策略网格包括 0 至 1、步长 0.01 的阈值；0.2 至 1.0 秒的行动延迟；以及 1.0 至 3.5 秒的超时。真正重要的是延迟与误截断率构成的 Pareto 前沿：越靠近左下角，说明系统越少抢话、接话越快。

五、效果对比：v1 在英语评测中的领先幅度

下面的数据来自 eot-bench 仓库当前提交的可复现实验产物。所有数值都表示完整端点策略的用户体验结果，而不是单纯模型推理耗时；每一列都是越低越好。“—”表示该模型没有任何策略配置能达到相应的延迟预算。

模型300ms 延迟预算下误截断率600ms 延迟预算下误截断率误截断≤5%时平均延迟误截断≤10%时平均延迟
LiveKit Turn Detector v19.9%4.5%543ms295ms
Deepgram Flux12.9%9.9%1151ms548ms
ultraVAD27.7%11.9%899ms663ms
LiveKit Turn Detector v1-mini27.8%12.1%1070ms698ms
SmartTurn v3.235.2%14.8%1051ms739ms
AssemblyAI49.4%14.6%1049ms713ms
Soniox—5.5%647ms512ms
Cartesia Ink 2——1056ms911ms
OpenAI GPT Realtime 2——1143ms824ms
仅 VAD 基线55.6%21.7%1600ms1000ms

如何理解这些数字

  • 300ms 延迟预算：v1 的误截断率为 9.9%，比 Deepgram Flux 的 12.9% 低 3.0 个百分点，相对减少约 23.3%。
  • 600ms 延迟预算：v1 为 4.5%，低于 Soniox 的 5.5%，也不到 Deepgram Flux 9.9% 的一半。
  • 把误截断控制在 5%：v1 平均只需等待 543ms；Flux 需要 1151ms，v1 减少约 608ms 的对话空白。
  • 把误截断控制在 10%：v1 平均延迟为 295ms，比 Flux 的 548ms 少 253ms。

v1-mini 的成绩揭示了明显的压缩代价

v1-mini 与 v1 共享核心架构，但通过权重量化和语言模型主干剪枝来降低体积与 CPU 推理延迟。它保留了大部分模型能力，却没有复制完整版的领先前沿：在 300ms 预算下，v1-mini 的误截断率是 27.8%，明显高于 v1 的 9.9%；在 5% 误截断预算下，其平均延迟为 1070ms，也高于 v1 的 543ms。

因此，v1-mini 的核心卖点不是“和 v1 一样准确”，而是开放权重、本地 CPU 可运行、避免云端推理依赖。对隐私、离线部署或成本高度敏感的应用，这种工程交换可能值得；对追求最佳对话手感的生产系统，官方云端 v1 才是本次发布的主力结果。

六、三个可用版本应该怎么选

版本输入获取与运行方式许可和适用场景
v1 完整版直接音频LiveKit Cloud / LiveKit Inference 优化推理；托管在 LiveKit Cloud 的 agent 可免费使用；各方案本地开发测试每月含 7500 次免费推理请求权重未开放；适合追求最佳效果且可接受云服务的生产应用
v1-mini直接音频Agents SDK 内置；Python livekit-agents ≥1.6.1，TypeScript @livekit/agents ≥1.4.7；量化并剪枝，可在 CPU 运行代码 Apache-2.0，模型文件使用 LiveKit Model License；适合本地、边缘或隐私敏感部署
v0.4.xSTT 转写文本Hugging Face 下载；Qwen2.5-0.5B 学生模型，INT8 ONNX，CPU 推理，官方给出的内存要求低于 500MBLiveKit Model License；生态成熟，但存在 STT 依赖与声学信息缺失

LiveKit Model License 并非标准 OSI 开源许可证。无论使用 v1-mini 还是 v0.4.x，在商用、再分发或模型衍生场景中，都应先阅读许可证原文，而不能仅凭“开放权重”判断可用范围。

LiveKit Agents 中显式启用 v1

from livekit.agents import AgentSession
from livekit.agents.inference import TurnDetector

session = AgentSession(
    turn_detection=TurnDetector(),
    # STT、LLM、TTS 等其他配置保持不变
)

当 agent 使用 LiveKit Cloud 运行，或者本地开发环境中存在 LiveKit Cloud 凭证时，v1 已成为默认 Turn Detector；显式配置主要用于让依赖关系更清晰。

七、架构层面的意义：轮次检测应该属于谁

Deepgram Flux、Soniox 等 STT 厂商会把端点检测直接嵌入流式识别服务。这样做的优势是识别与端点事件天然协同，接入简单；代价是对话节奏会与 STT 供应商绑定。更换识别服务时，停顿处理、阈值行为和语言覆盖都可能随之改变。

LiveKit 的主张是把轮次检测放在 agent 框架层，使同一套检测逻辑可以与任意 STT、LLM 和 TTS 组合。对多供应商切换、跨语言产品和统一体验治理来说，这种解耦很有价值。不过，这也明显符合 LiveKit 作为 agent 框架与云平台的商业位置，选型时仍应结合系统边界，而不是只接受单一厂商的叙事。

路线优势代价
VAD 静音计时简单、便宜、完全本地不理解语义和韵律，抢话率高
STT 内置端点检测事件与转写深度协同，集成方便行为和语言覆盖绑定供应商
文本语义检测理解句子完整性，本地部署成熟依赖 STT，丢失声学信号
LiveKit v1 音频融合兼顾语义与韵律，可独立于 STT 工作完整版依赖 LiveKit 云服务；本地 mini 版存在明显精度折损

八、如何理性看待“轮次检测已经解决”

  • 值得肯定：LiveKit 不只发布模型，还公开基准、数据结构、适配器、策略扫描方法和实验产物，让厂商声明具备可复现基础。
  • 不能忽略：eot-bench 与 v1 都由 LiveKit 发布，当前结论应准确表述为“在 LiveKit 公开基准上领先”。
  • 数据边界仍然存在：医疗问诊、客服报号、多人会议、强背景噪声、方言、儿童语音、情绪化长停顿等场景可能具有完全不同的分布。
  • 平均值不是全部：上线前应按语言、口音、设备、业务意图和用户群体分别观察尾部延迟与抢话案例。
  • 应评测完整链路：STT、LLM 首 token、TTS 首包、回声消除和打断恢复都会影响最终“对话手感”，Turn Detector 只是其中一环。

对于实际团队，最可靠的做法是把自己的生产对话转换为 eot-bench 的 span 结构，在相同的延迟与误截断预算下复测候选方案。如果采用云端 v1，还应同时评估网络抖动、区域可用性、数据合规和请求成本；如果采用 v1-mini，则要验证压缩后在目标语言和硬件上的真实效果。

结语

LiveKit Turn Detector v1.0 最重要的变化，不只是把某个准确率提高了几个百分点，而是重新定义了轮次检测的输入：系统不再等着读一份丢失韵律的转写稿，而是直接从语音中同时理解内容与表达方式。

完整版 v1 在 eot-bench 上显著领先 Deepgram Flux、Soniox、ultraVAD、SmartTurn 和纯 VAD 基线；v1-mini 则用效果换取开放权重和本地 CPU 部署。再加上公开的真实对话数据、完整策略扫描和 Pareto 前沿，轮次检测终于从“凭感觉调一个静音阈值”，变成了一个可以测量、复现和讨论工程取舍的问题。

它是否真的已经被彻底解决，还需要更多独立数据回答；但至少从这次发布开始，“用户到底说完没有”第一次拥有了一套足够接近生产环境的公开考场。

参考资料

相关文章：

  1. 常见的编解码器模型以及压缩token数
  2. Qwen3-ASR：语音识别大模型
  3. PAL: 探索如何在音频与LLM之间实现高效的语义信息传递
  4. Fun-Audio-Chat：端到端语音交互模型

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注