Hugging Face开源约2GB模型，等你把印度语动词说完再开口

抢话的根源

语音代理打断人，不是因为它急躁。它听到的是沉默，听不到意思。

传统做法靠语音活动检测（VAD）：一段静默超过阈值，就判定这句话说完了。英语的动词不在句尾，这招勉强能用。

印度语言把动词放在句末。“aapko kal phone…”（明天给你打电话），phone 之后有一个自然停顿。VAD 听到的是沉默，机器人就在“kar dunga”落地之前开口。句子最关键的动词还没到，意思才刚起步。

新发布的模型针对的就是这一点。

一个读文字的打分器

发布者在 Hugging Face 开源了一个 EOU 检测模型，也就是轮次结束检测。它基于 Qwen2.5-0.5B 微调。

它不判断声音，只给实时转录出来的文本打分，预测呼叫者这句到底讲完没有。纯文本模型，得搭配自己的语音转文本（STT）用——它本身不听声音。

语言覆盖英语、Hinglish，以及印地语、泰卢固语、泰米尔语、马拉地语、孟加拉语、古吉拉特语、旁遮普语。合起来是英语加 8 种印度语言。

效果数字

留出的验证集上，真阳性率 91.3%，阈值校准到对未完成轮次约 10% 的假切断。AUC 0.967。

LiveKit 官方的真实语音测试集是印地语。相同预算下，检测率 85.3%。

模型已经在 LiveKit Cloud 上跑过真实流量。请求中途的停顿能扛住，等整句讲完再提交。

空白也明显。英语和 Hinglish 的真实语音效果，没有单独给数。训练数据的来源和规模，没有提。各种口音、语速覆盖到什么程度，不清楚。10% 的假切断落到真实通话里是什么体验，同样缺一手数据。

部署门槛

模型约 2GB（fp32），跑在 CPU-only 的 ONNX Runtime 上。完全本地推理，不把语音送到云端。对网络差、或者不希望通话录音离开设备的场景，这两点都实惠。低端 CPU 上能不能撑住实时，没有公开数据。

已经在用 LiveKit Agents 搭语音代理的话，可以直接替换它原有的文本轮次检测器。接口一致，不用改代码。其他语音代理框架是否兼容，没有说明。

模型和插件都挂在 Hugging Face 上，Apache-2.0 许可，商用免费。

不只是印度语言

评论区有人提到，这个问题不限于少数语言。他不太愿意跟语音代理讲话，总感觉自己被催着赶紧说完，而自然对话不是这样。还有人在评论里问项目投入了多少，没有看到回答。

判断依据从“有没有听到沉默”，换成“意思有没有讲完整”。这个思路对别的语言也成立。当前版本覆盖的，还是英语加那 8 种印度语言。