网易有道开源子曰Live双模型：R2T2延迟200到600毫秒，T3PO登顶HF翻译榜

5 hours ago AI笔记

两款模型一起开源，主攻边说边出结果

网易有道把子曰 Live 系列的两款实时交互模型放到了开源社区，Confucius4-R2T2 做流式语音识别，Confucius4-T3PO 做流式同传翻译。两款模型双双登顶 Hugging Face 的 ASR 与 Translation Trending 榜。

和 Qwen-Audio-3.1 这种一次发五款的打包式发布不同，有道这次只发两个，但都压在实时这条线上。

R2T2 的落子无悔是怎么回事

R2T2 全称 Real Real-Time Transcription，基于 Qwen3-ASR 构建，采用 append-only 机制，已经上屏的文本不回改。传统流式识别常出现字幕闪烁，前面出的字被后面进来的音频推翻，R2T2 用这个机制把这类抖动直接回避掉。

延迟方面官方口径平均 200 到 600 毫秒，支持 80 毫秒到 2 秒的可调分块，流式精度接近离线识别。另外支持热词和上下文先验，生僻词命中率可以靠提示词拉一拉。语言上中英做了优化，同时保留法德意日韩俄西阿等跨语言能力。

训练时先学会判断哪些前缀够稳

实现 append-only 的关键在训练侧。有道用 stable-prefix、强制时间对齐、token 级音频切分这几种数据构造方式，让模型学会判断哪些前缀已经稳定到可以外发。

解码走 Commit/Wait 两步。每来一小段音频，先评估当前稳定前缀，够稳就 commit 成不可改文本，不够稳就 wait 继续缓存。后续预测只以稳定前缀作为条件，既给足语义约束，也保证历史输出不被后面的音频翻盘。

部署后端给了 vLLM、Transformers、llama.cpp/GGUF，也能直接起 WebSocket 服务。仓库在 github.com/netease-youdao/Confucius4-R2T2。

T3PO 用 READ/WRITE 决定什么时候开译

T3PO 全称 simultaneous Translation via pareTo Policy Optimization。它把同传建模成增量决策过程，每步观察已听到的源语前缀和已生成的译文前缀，然后决定 READ 继续等，还是 WRITE 生成下一个目标词。

翻译质量和响应延迟被分开度量，在 Pareto 前沿上选操作点，同一个模型可以按需求偏向低延迟或高保真。训练侧用 Pareto DPO 这类偏好优化方法，让策略更倾向同等延迟下质量更高、同等质量下延迟更低的读写动作。对说话人改口、财报数字、英文口头禅这些真实口语场景做了专门处理。

推理时 WRITE 会自回归产出目标 token，READ 则消费更多源语上下文，源前缀语义足够后才触发输出，降低半句话误译的概率。

两款串起来就是边说边听边译

T3PO 本体偏文本到文本同传，前端接上 R2T2 之后，识别端每吐一段稳定文本，翻译端立刻做 READ/WRITE 判断，形成完整的语音同传链路。

开源后社区跟进很快，已经有 ZeroGPU Demo、audio.cpp、GGUF 量化，以及 llama.cpp 和 Ollama 适配。想本地跑一套实时翻译，不用再依赖 Gemini 3.5 Live Translate 这类托管服务，也不用像 混元 Hy-MT2-1.8B 那样只做离线整句翻译。

和 Gemini 3.5 Live Translate 的差异

维度 R2T2 + T3PO Gemini 3.5 Live Translate
定位 开源可组装的同传链路 谷歌托管的成品实时语音翻译
部署方式 权重开放，本地或私有化 API 调用
识别延迟 R2T2 平均 200 到 600 毫秒 译文只比原声慢几秒
可定制性 分块、热词、读写策略均可调 参数基本不可调
语言覆盖 中英优化，兼顾多语种 70 多种语言互译
适合谁 要数据不出内网、要改策略 要开箱即用、语种要多

小结

有道这次开源的思路很清晰，把一条同传链路拆成识别和翻译两个可替换的模块，各自给足参数和后端，让使用者按场景拼。对做实时字幕、会议同传、语音输入这类产品的团队，这比一个封装好的黑盒 API 更有改造空间。

相关阅读

延伸阅读

AI 自学笔记 每天更新 AI 前沿动态，订阅 RSS，或按 Ctrl/⌘+D 收藏本站，明天见。

Related News