2026 年 10 月 16 日，NineNineSix 在 Hugging Face 上开源了 TYGER：一个专为全双工语音代理设计的决策模型。它不是另一个语音识别模型，也不是另一个 LLM——它是一个独立的"听 + 决策"模块，让任何 LLM + 任何 TTS 都能变成"说话不机械"的全双工语音代理。
关键能力：每 80 毫秒决策一次
TYGER 做的事可以一句话概括：
同时听用户麦克风和智能体自己的 TTS 输出，每 80 ms 决定一次该做什么——回答、让步、还是插个"嗯哼"。
更具体的 4 个状态（per frame）：
| 状态 | 含义 | 默认触发阈值 | 智能体动作 |
|---|---|---|---|
| Endpoint | 用户说完了 | 0.91 | 准备接话 |
| Barge-in | 用户在插话 | 0.50 | 立即停 TTS |
| Backchannel | 用户继续说但期待反馈 | 0.40 | 插一个"嗯哼" |
| Listen / Hold / Speak | 内部状态机 | — | 调度逻辑 |
阈值由开发者自己调——README 说默认值比评估时更宽松（0.93 / 0.80 评估时），需要按 app 调优。
架构：Nemotron ASR + 14M GRU
TYGER 不是从零训练。它在 NVIDIA Nemotron 3.5 ASR Streaming 0.6B（一个流式 ASR 模型）上加了一个 14M 参数的因果 GRU：
| 模块 | 大小 | 作用 |
|---|---|---|
| Nemotron 3.5 ASR | 638M | 听（语音 → 文本） |
| 因果 GRU（3 层，width 768） | 14M | 决策（基于文本 + 状态机 → 4 个状态） |
| 总参数 | 652M | FP32，2.61 GB |
GRU 拿了 Nemotron 第 15 层（1024 维）的特征，每 80 ms 出一个决策，无 lookahead——这意味着 TYGER 反应延迟理论下限 = 80 ms（实际是 80 + 一次 ASR hop 320 ms ≈ 400 ms 端到端）。
跟传统方案的差异
传统全双工语音代理用 VAD（Voice Activity Detection）+ ASR + LLM + TTS 串联：
用户说话 → VAD 检测"在说话" → ASR 转写 → LLM 推理 → TTS 播放
↑ 这里有 300-500ms 延迟VAD 是基于声学特征（音量、能量、零交叉率）的，反应慢——用户说完了 500ms 后 VAD 还在"检测"。这导致全双工语音听起来"僵硬"：你说完了要等 1 秒它才回话。
TYGER 的关键改变：不需要单独的 VAD。它把"语音转写 + 决策"做成一个模型，直接输出"该说话 / 该让步 / 该嗯哼"——基于语义而不是声学。
| 维度 | 传统 VAD | TYGER |
|---|---|---|
| 检测基础 | 声学特征（能量/频率） | 语义（ASR + GRU 决策） |
| 反应延迟 | 300-500 ms | 80-400 ms |
| 能不能区分"停顿"vs"说完" | 不能（要 1+ 秒静音） | 能（语义级判断） |
| 能不能识别"用户在思考、还没说完" | 不能 | 能（Backchannel 触发） |
几个观察
1. 解决了"语音代理僵硬"的核心问题
过去 2 年，GPT-4o Realtime、Hume EVI、LiveKit 等方案都尝试解决"语音代理对话僵硬"问题，但门槛是 VAD 换不掉——VAD 是声学的，不能理解语义。
TYGER 提出了"语义级轮次控制"这个新方向：
- • 不要"听声音 + 算能量"——要"听懂 + 决定"
- • 每 80 ms 不是输出"音量数字"，而是输出"该不该说话 / 让步 / 嗯哼"
- • 用 ASR + 轻量 GRU 替代整个 VAD + endpointing pipeline
这意味着：全双工语音代理的体验瓶颈，不再是 VAD 算法或 LLM 推理，而是"对轮次控制的语义理解"。
2. 极轻量 + 解耦设计
TYGER 的 GRU 只有 14M 参数——一个轻量级状态机。这让 TYGER 适合部署在边缘设备或独立服务：
- • 不需要 LLM 推理时同步（LLM 可以异步跑）
- • 不需要 GPU（CPU 跑 Nemotron 0.6B 即可，2.61 GB 内存）
- • 不需要 TTS 集成（适配任何 LLM 和 TTS——只要给 TYGER 两路音频流，它就告诉你什么时候说、什么时候停）
"适配任何 LLM 和 TTS" 是 TYGER 的核心卖点——开发者可以用 GPT-4o / Claude / 自家 LLM，配 ElevenLabs / Cartesia / 自家 TTS，不需要重新做语音对话控制。
3. 对中文 / 多语种支持
TYGER 目前只支持英语（README 写"Language: English"）。但它理论上可以扩展到中文 / 日文 / 多语种——只是需要：
- • 换底座 ASR 模型（Nemotron 3.5 ASR 已经有中文版本）
- • 重新训练 GRU 决策头
- • Open Yap 1K 数据集（TYGER 用的训练数据）只有英语对话
中文版 TYGER 大概率会在 2026 年底 / 2027 年初出现——这是中国市场语音代理落地的关键。
4. 不是万能的——TYGER 也有盲区
TYGER 解决了轮次控制这个具体问题，但不能解决：
- • 背景噪声 / 回声：用户麦克风有 TV、空调声，需要 AEC（声学回声消除）单独处理
- • 远场拾音：3-5 米外说话，TYGER 仍需要前端麦克风阵列
- • 多说话人：会议场景下 2-3 人同时说话，TYGER 默认是 1 对 1
TYGER 是全双工语音代理栈里的一环，不是银弹。完整方案是：
[麦克风阵列 + AEC + VAD] → [TYGER 决策] → [LLM 推理] → [TTS 播放]
↑ 这是"耳朵" ↑ 这是"轮次" ↑ 这是"脑子" ↑ 这是"嘴巴"实际使用
最简路径：用 NineNineSix 自家的 tyger-s2s——一个完整的开源语音代理 Docker 镜像，浏览器里直接对话。
嵌入现有项目：TYGER 只做"听 + 决策"，你需要：
- 1. 启动 TYGER 服务（HF 上的模型 + GRU 状态机）
- 2. 接入现有 ASR 流的双路音频（用户 mic + TTS 播放）
- 3. 订阅 TYGER 的 4 个状态输出
- 4. 自己控制 LLM 什么时候发请求、TTS 什么时候启停
详细代码示例见 tyger-s2s/app/plugins/ears/tyger/。
收尾
TYGER 解决了一个被低估但关键的问题：全双工语音代理的"僵硬感"。
过去靠 VAD 做不到的语义级轮次控制，现在用一个 14M GRU 做到了。2.61 GB 内存 + CPU 推理 + 适配任何 LLM/TTS——这是个人人能用的全双工基座。
如果你的产品是实时语音对话——AI 助手 / AI 客服 / 语音 Agent——TYGER 值得立刻评估。它把"对话不机械"这个用户体验问题，从"模型能力"降级到了"集成方式"。
期待 2027 年中文版 + 多语种版。
模型来源：huggingface.co/nineninesix/tyger，Apache 风格 OpenMDW-1.1 协议开源。
发表回复