一、听、译、说三件套，一次全开源
九月底，网易有道把子曰 Live 系列实时交互模型推上了开源货架。这个系列少见的地方在于完整：三个仓库分别对应实时语音链路的三个环节，听、译、说，而且三仓 LICENSE 原文均为标准 Apache License 2.0 全文（已逐字核验），商用门槛在主流宽松许可证里属于最低的一档。
三个仓库的分工一句话说清：
听 Confucius4-R2T2 真流式语音识别（ASR）
译 Confucius4-T3PO 14B 参数流式同传（text-to-text）
说 Confucius4-TTS 零样本语音合成（TTS）按官方新闻稿口径（经机器之心转述），R2T2 与 T3PO 双双登顶 Hugging Face ASR 与 Translation Trending 榜。截至 2026-09-29 的 GitHub API 快照，三仓 star 数分别为 680、110 与 821：热度最高的不是负责听的 ASR，而是负责说的 TTS。
做实时语音产品的人对三道坎都不陌生。第一道是流式识别里最烦人的「回改」：很多标榜流式的 ASR 实际是切片伪流式，后面的音频可能把前面已经吐出的文字整句推翻，字幕和下游逻辑跟着一起抖。第二道是翻译的延迟悖论：等句号，质量好但慢得没法用；不等，译文又容易翻错方向。第三道是声音的定制：想要一个固定音色，要么录音棚级采样，要么把数据交给云端。子曰 Live 这次把三道坎的解法一并放了出来，这就是一站式实时语音栈的含义。
本篇是开源项目拆解：先把 R2T2 的稳定前缀机制与 append-only 输出讲透，这是它对实时字幕与 Agent 语音管线真正的价值所在；再看 T3PO 如何用 Pareto 强化学习把质量与延迟绑在一起优化；最后看三仓的工程适配，并把本文与站内同传、翻译类文章的分工边界划清楚。
二、R2T2：真流式的含金量在 append-only
仓库全名 netease-youdao/Confucius4-R2T2，Python 编写，2026-09-29 快照下 680 星，最近推送 2026-09-24。名字里的 R2T2 是 Real Real-Time Transcription，两个 Real 不是笔误，而是刻意强调真流式：平均延迟 200-600ms，解码 chunk 可在 80ms 到 2s 之间配置。
真与伪的分歧点不在延迟数字，而在输出纪律。R2T2 的输出是 append-only：已经吐出的文本永久提交，绝不回改。这句话听起来朴素，落到工程上分量很重。实时字幕场景里，append-only 意味着字幕一旦上屏就定格，观众不会看到已读文字被整句刷新；Agent 语音管线里，识别结果要立即喂给下游大模型处理，如果文本持续回改，下游要么反复重建上下文，要么自建一套文本修订 diff 机制。append-only 把这两类成本直接归零，这也是它对实时字幕与 Agent 管线真正关键的原因。
支撑这套纪律的是训练侧的稳定前缀机制。R2T2 基于 Qwen3-ASR 构建，训练数据使用稳定前缀（stable-prefix）构造、强制时间对齐数据与 token 级音频切分，配合 LSP（Longest Stable Prefix，最长稳定前缀）学习范式，技术报告将发布。直觉上可以这么理解：模型在训练阶段就被反复要求尽早敲定已听音频对应的文字，而不是把一切留给后段全局优化，于是推理时才有底气做出 append-only 的承诺。
效果口径要标清楚。README 官方自报开源模型中延迟与识别质量双 SOTA，与闭源系统有竞争力；评测图包含英文 WER 表与中文 CER 表，对比对象覆盖 Qwen3-ASR、X-ASR、WhisperRT、Nemotron、Voxtral、AssemblyAI 及商用系统。以 160ms chunk 口径为例，英文 LS-clean 2.13 WER、LS-other 4.88；中文表结构与英文一致，这里只做结构性概括，不引单点数字。必须提醒：这套表格里的竞品分数同样是 R2T2 官方评测口径，各家测试环境不同，跨仓库直接横比准确率并不可靠。
工程侧 R2T2 给得相当全：后端同时支持 vLLM（高吞吐服务）、HuggingFace transformers 与 llama.cpp（本地轻量），自带 WebSocket Server，前端可以直接连流式识别服务；支持 context 与 hotword 提示，垂直行业的专有名词可以通过热词表兜底；中英双语优化，同时支持多语言。举个具体画面：会议室里一台内网机器跑 vLLM 起服务，笔记本浏览器用 WebSocket 直连，场外嘉宾名单提前塞进热词表，人名和产品名就不会在字幕里被写成同音的错字。识别、部署、纠错三件事，在仓库里都有现成的着力点。
三、T3PO：用 Pareto 强化学习把质量和延迟拴在一起
第二个仓库 netease-youdao/Confucius4-T3PO，110 星，最近推送 2026-09-21。全名 simulTaneous Translation via pareTo Policy Optimization，14B 参数的 text-to-text 同传模型。注意定语：它是纯文本进、文本出，不支持语音输入，要做语音到文本的同传，官方推荐的组合是与 R2T2 级联，由 R2T2 先把音频流转成文字流，T3PO 接力做流式翻译。
T3PO 的训练管线分三阶段：段对齐数据构造，流式冷启动，Pareto 感知强化学习。前两阶段解决会不会边听边译，第三阶段解决翻得好和翻得快之间的取舍。同传的天然矛盾在于：模型多读几个词再下笔，译文质量更高，但延迟随之上涨；急着输出，延迟低了，翻错方向的风险又变大。传统做法往往先定一个延迟目标再优化质量，而 T3PO 用 Pareto 感知强化学习做质量与延迟的联合优化，让模型在权衡曲线上给出多个可选项，再通过延迟档位可调暴露给使用者，多档质量与延迟切换，业务方按场景挑点。
推理协议也值得拆。T3PO 以逐字符、词级的细粒度 chunk 接收输入流，动态决定继续读还是立即写增量译文，已提交的译文同样 append-only 不回改；interleaved history 协议支持 KV-cache 复用，长会话下的推理成本得以摊薄。另外它保留了 Qwen 基座的通用指令跟随能力，可以在翻译之上叠加术语约束之类的指令。
诚实边界必须写：对未训练的日译中方向，README 自述有一定流式泛化，但官方同时承认中英之外方向的质量未做严格评估。也就是说，把 T3PO 用于中英同传有训练与评测双重背书，其他语向属于能跑、但自负其责。评测侧，官方对比了开源的 InfiniSST、EAST 与两大商用同传系统，图表以 COMET 与 word-CW 两个维度呈现，具体分数本篇不引，需要者可查仓库原图。想在线体验可访问 t3po.youdao.com 的 demo。
四、TTS：三仓里星最高的，为什么是它
第三个仓库 netease-youdao/Confucius4-TTS，2026-09-29 快照下 821 星，是三仓里热度最高的，最近推送 2026-09-03，配套论文 arXiv 2608.11650。它是 LLM-based TTS：speech encoder 加 LLM 架构，支持 14 个语种，覆盖中、英、日、韩、德、法、西、印尼、意、泰、葡、俄、马来、越南。
它的三个卖点都对着上面说的第三道坎：零样本克隆，且无参考转录即可克隆，也就是不需要目标说话人的文字稿就能复刻音色；跨语言声色保持，用中文文本驱动克隆音色说英文不会跑调走形；情感迁移，合成语音可以携带参考音频的情绪。对想做固定形象音色、多语种播报的开发者，这三点组合起来的实用性不难想象。TTS 本身的客观分数本篇事实清单未收录，合成质量建议自行试听判断。
顺带交代权重渠道：三仓均提供 Hugging Face 与 ModelScope 双渠道下载，国内环境拉权重不至于卡在第一步。
五、生态适配与站内分工
把三仓拼起来看，社区适配的版图已经比较完整。识别侧 R2T2 有 vLLM、transformers、llama.cpp 三条后端路线与自带 WebSocket Server，分别对应高并发服务、快速原型与低配机器三种现实；翻译侧 T3PO 提供在线 demo 与开放权重；合成侧 TTS 走标准推理栈。R2T2 与 T3PO 的级联是官方推荐组合，再接上 TTS，就能把语音合成环节也留在本地，整条实时语音链路权重全部 Apache-2.0，数据不出内网，这对客服、会议、直播字幕等场景是实打实的选项。
分工边界划清楚。本文聚焦有道三仓的开源深拆；Kyutai 同传模型 Hibiki 拆解讲的是另一个流式同传样本，只支持法语到英语、走语音到语音路线；通义千问实时翻译热点覆盖 Qwen 阵营的实时翻译模型动态；翻译工具横向评测比的是云端翻译服务，不涉及自托管权重；语音到语音资源梳理是语音到语音路线的全景索引；部署形态拿不定主意的，可以读本地与云端语音人工智能评测。几篇互为内链，各管一段，不重复劳动。
六、冷思考：快照、口径与边界
第一，star 数只是热度参照，且有明确的时间戳：本文全部 star 数为 2026-09-29 GitHub API 快照。821 星的 TTS、680 星的 ASR、110 星的同传，梯度反映的是社区注意力的分布：TTS 受众最广，同传最垂直。这个结构和 Hibiki 等同传开源项目面临的情况一致。
第二，性能结论要看口径。R2T2 的双 SOTA 说法是 README 官方自报，评测 harness 自建，竞品分数也在同一口径之下；T3PO 的对比图同理。这类表格用来判断大致量级没有问题，用来精确排名就越界了。
第三，语言边界要认。R2T2 中英优化、多语言支持；T3PO 只有中英方向有严格评估，日译中泛化属自述；TTS 的 14 语种覆盖面宽，但克隆质量在语种之间的差异不在本篇事实范围内。选型前按自己的语向实测，比读任何表格都可靠。
第四，许可证是这次最干净的部分。三仓 LICENSE 原文均为标准 Apache License 2.0 全文，可写 Apache-2.0（LICENSE 原文核验）。宽松、无传染、带专利授权条款，商用部署的合规负担低，这是三仓相对许多研究用途开源语音项目的实质性差别。
结论不复杂：子曰 Live 三仓的价值不在单项指标登顶，而在把听、译、说三段实时链路以统一许可证整体开源，且关键机制，append-only 输出、LSP 稳定前缀、Pareto 联合优化，都有明确的技术交代。对要自建实时语音管线的开发者，这是 2026 年少见的一套完整起点。
常见问题
Q1： 三个仓库必须一起用吗，能不能单独取用？
A1：可以完全单独使用。R2T2 是独立的流式识别服务，自带 WebSocket Server；T3PO 是纯 text-to-text 模型，单独就能做流式翻译；TTS 同样独立成仓。只有做语音输入的同传时，才需要 R2T2 与 T3PO 级联成 S2T 管线。
Q2： append-only 输出为什么这么重要？
A2：因为它直接决定下游系统的架构复杂度。实时字幕上屏即定格，不会出现已读文字被整句刷新；Agent 管线中识别结果可以直接喂给大模型，不必自建文本修订与上下文重建机制。回改式流式省下的是模型侧功夫，代价转嫁给了所有下游。
Q3： T3PO 支持语音输入吗？
A3：不支持。T3PO 是纯 text-to-text 模型，输入输出都是文本流。要做语音到文本的同传，官方推荐与 R2T2 级联：R2T2 负责把音频流转成文字流，T3PO 接力做流式翻译，组成 S2T 管线。
Q4： 三仓的许可证商用上要注意什么？
A4：三仓 LICENSE 原文均为标准 Apache License 2.0 全文，属主流宽松许可证，附带专利授权条款，商用部署门槛低，按惯例保留许可证与版权声明即可。相比之下某些开源语音项目采用自定义许可，商用前须自行审阅条款，三仓在这一点上干净得多。
Q5： 文中 star 数与性能数字的口径是什么？
A5：star 数为 2026-09-29 GitHub API 快照。R2T2 的延迟与 WER 数字来自 README 官方口径，评测表中的竞品分数同为该表口径；T3PO 的对比图只描述维度、不引具体分数；中文 CER 表只做结构性概括。所有数字均标注来源，未混用不同 harness 的结果。