看直播时你大概率见过这种字幕：前半句刚显示出来，两秒后被整段替换，标点重排、用词全变，观众盯着字幕来回跳字。这不是字幕组的锅，而是伪流式语音识别的老毛病——把音频切片整段转写，每来一片就重算一遍，前面吐出的字随时可能被推翻。真流式的答案只有一个词：append-only，已输出的文本永久提交、绝不回改。9 月底有道开源的 Confucius4-R2T2 登顶 Hugging Face ASR Trending 榜（官方新闻稿口径，经机器之心转述），把真流式重新推上台面。先交代背景：语音识别这条线，过去几年的主流是"先录完、再转写"的批处理模式，Whisper 一战成名靠的就是这个打法。但实时字幕、会议纪要、Agent 语音前端这些场景，等不起整段录完——音频像水一样流进来，字要像水一样流出去，这就是流式 ASR。而流式又分两派：一派每来一段就重算，另一派说出的话永不反悔。这个差别，比准确率差半个点重要得多。本文把 R2T2、faster-whisper、FunASR、moonshine、Kyutai delayed-streams-modeling 五款开源方案摆上同一张桌，沿五条主轴横评：流式真伪、延迟量级、部署门槛、中英支持、许可证与商用风险。
一、口径边界：先说清能比什么、不能比什么
横评最容易翻车的地方，是把不同评测框架（harness）测出的准确率摆在一起排座次。本文明确不做这种事，三条纪律先立好：
- 准确率数字不横比。 各家的评测集、音频切分方式、后处理流程都不同，分数之间没有可比性，拿数字排座次毫无意义。
- 引用 R2T2 的 WER/CER 一律标注口径。 文中出现的具体分数均为「R2T2 官方评测口径（README）」，且该表中竞品分数也是在同一口径下测得的，不是第三方独立复测。例如官方 160ms chunk 口径下，英文 LibriSpeech-clean 为 2.13 WER、test-other 为 4.88。本文不自行跑分。
- 本文比的是流式识别与转写，也就是听写、实时字幕、Agent 语音前端这类把话变成字的场景。翻译与同传是另一条赛道：站内 AI 翻译工具横评 比的是云翻译服务，Qwen3-8-LiveTranslate 热点解读 讲的是端到端实时翻译模型，Hibiki 资源页 则是 Kyutai 同传模型的专文。四篇互为内链，分工不重叠。
文中全部 star 数为 2026-09-29 GitHub API 快照；许可证以仓库 LICENSE 原文为准。
二、五方阵容：一张表建立全局
| 方案 | 星数（2026-09-29 快照） | 许可证 | 流式方式 | 延迟口径 | 中英支持 | 部署门槛 | 商用风险 |
|---|---|---|---|---|---|---|---|
| Confucius4-R2T2（有道） | 680 | Apache-2.0（LICENSE 原文核验） | 真流式，append-only 不回改 | 官方自报平均 200-600ms，chunk 可配 80ms 至 2s | 中英优化，多语言 | vLLM / transformers / llama.cpp，自带 WebSocket Server | 低 |
| faster-whisper（SYSTRAN） | 25,617 | MIT | 非真流式，伪流式靠切片 | 无官方流式延迟口径 | 依托 Whisper 多语言底子 | CTranslate2 推理引擎 | 低 |
| FunASR（阿里达摩院） | 20,536 | MIT | 以 Paraformer 系列分段转写见长 | 未见统一官方流式延迟口径 | 中文生态最深 | Python 工具链，ModelScope 生态 | 低 |
| moonshine（usefulsensors） | 11,154 | 自定义许可（NOASSERTION） | 端侧轻量路线 | 未见统一官方流式延迟口径 | 未核到官方口径 | 面向资源受限设备 | 须审阅自定义条款 |
| delayed-streams-modeling（Kyutai） | 3,032 | Apache-2.0 | 真流式（延迟流建模） | 延迟流建模设计，本文未引官方数字 | 未核到官方口径 | 偏研究向接入 | 低 |
一句话画像：
- Confucius4-R2T2：有道新开源的真流式 ASR，主打 append-only 不回改，基于 Qwen3-ASR 构建。
- faster-whisper：SYSTRAN 出品的 Whisper 改进推理引擎（CTranslate2），社区事实标准，但 Whisper 本体是分段式非真流式。
- FunASR：阿里达摩院开源，中文生态最深，2026-09-28 仍在推送更新。
- moonshine：usefulsensors 的端侧轻量路线。
- delayed-streams-modeling：Kyutai 的真流式路线，延迟流建模。
三、主轴一：真流式还是伪流式，看它敢不敢落子无悔
真流式与伪流式的分水岭只有一条：已输出的文本是否回改。
R2T2 把 append-only 做成了训练目标。它不只是推理时忍住不回改，训练阶段就用稳定前缀数据（stable-prefix）、强制时间对齐数据与 token 级音频切分，配合 LSP（Longest Stable Prefix）学习范式，教会模型说出的话算数（技术报告将发布）。落到体验上：字幕一旦上屏就定格，下游做逐字上屏动画、日志存档、Agent 意图解析，都不用处理历史被改写的脏状态。
faster-whisper 是另一番景象。它把 Whisper 的推理优化做到位（CTranslate2 引擎），是大量转写场景的默认选择，但 Whisper 本体是分段式非真流式——工程上常用滚动切片加首尾重叠来模拟流式，本质是每来一段就重算一遍，前文随时可能变化。对离线转写这无所谓，对实时字幕就是那个跳字的来源。
Kyutai 的 delayed-streams-modeling 走第三条路：延迟流建模。模型在训练阶段就学会了等多久再输出的节奏，输出天然是真流式。FunASR 与 moonshine 的流式定位本文不替官方下结论：FunASR 以 Paraformer 系列的分段转写生态见长，moonshine 主打端侧轻量，是否满足你不回改的要求，建议按自家音频实测后再定。
四、主轴二：延迟量级，只认有出处的数字
延迟这一栏，本文只写有出处的数字：R2T2 官方自报平均延迟 200-600ms，解码 chunk 可配 80ms 至 2s，是五款里唯一给出明确区间与可配置范围的。这个区间的价值在于两端都能用：200ms 量级接近边说边出字的体感底线，拉到 2s 的 chunk 则换取更稳的识别质量，产品可以按场景权衡。
其余四款，本文未核到统一口径的官方流式延迟数字，这里不编数。选型时请警惕宣传页上的毫秒级话术：先问清是首字延迟还是稳定输出延迟、在什么硬件什么音频路数下测的，再决定要不要接进你的管线。
延迟敏感度也分场景。实时字幕对稳定输出延迟最敏感，因为字幕要跟上说话人的节奏，慢半拍观众就感觉对不上口型；会议纪要可以容忍一到两秒的滑窗，换来更低的错误率；Agent 语音前端则卡另一头——从用户说完到 Agent 开始响应，整条链路的预算往往不到一秒，留给 ASR 的部分要按毫秒精打细算。同是流式，这三类产品对"快"的定义并不一样，先想清楚你要的是哪种快。
五、主轴三：部署门槛，从 vLLM 到 CPU 各有走法
R2T2 的后端选择最齐：vLLM 扛高吞吐，HuggingFace transformers 便于魔改，llama.cpp 兜住 CPU 与边缘场景，还自带 WebSocket Server，支持 context 与热词（hotword）提示。对要搭语音前端的团队，这套组合基本覆盖了从开发调试到生产服务的全链路。
faster-whisper 的优势是成熟度：CTranslate2 推理引擎加海量社区方案，集成资料遍地都是，接进既有系统几乎不费力。FunASR 背靠 ModelScope 生态，中文工具链与预训练模型储备最深，国内团队上手成本低。moonshine 定位端侧轻量，方向就是往资源受限的设备上塞。Kyutai 的 delayed-streams-modeling 更偏研究向，适合想复现流式建模范式的团队，而不是拿来即用的生产组件。
本地部署的整体方法论，可以参考站内 本地大模型部署横评 与 Ollama 本地部署 SOP，思路相通：先定硬件预算，再定推理后端，最后才挑模型。
六、主轴四：中文与英文，别信都支持，要信哪门语言被认真调过
R2T2 的官方口径是中英优化、多语言支持，加上热词机制对中文专名场景友好；FunASR 的中文生态最深，Paraformer 系列在中文社区积累多年；faster-whisper 依托 Whisper 的多语言底子。moonshine 与 Kyutai delayed-streams-modeling 的语言覆盖，本文未核到官方口径，不妄断。
一个实用的判断法：看该项目 README 与评测表里，你的目标语言是不是一等公民。R2T2 的 README 给出全套中文 CER 表与英文 WER 表（均为官方评测口径），至少说明中英都进了它的正赛名单；如果你的主力语言只在文档里被一句带过，预期就要打折。
七、主轴五：许可证与商用风险，moonshine 必须单列
好消息是五款里四款商用友好：R2T2 与 Kyutai delayed-streams-modeling 为 Apache-2.0，其中 R2T2 的 LICENSE 原文经核验为标准 Apache License 2.0 全文；faster-whisper 与 FunASR 为 MIT。闭源商用、二次分发、做成产品，这四款常规法务流程即可。
moonshine 必须单列风险提示：其许可证为自定义条款，GitHub API 的许可证字段标注 NOASSERTION。 这意味着它不是通用认可的标准开源许可，条款细节决定你能不能商用、要不要开源自己的代码、要不要署名。如果你的产品想用它，第一步不是写代码，而是把许可原文逐条过一遍法务；审完之前，把它按不可商用对待最安全。
八、选型建议：对号入座
- 要真流式、中英兼顾、后端齐全的生产管线：R2T2。append-only 加 WebSocket Server 加 vLLM 高吞吐，几乎是按语音前端这个需求原生长出来的。
- 已有 Whisper 生态、只想离线转写提速：faster-whisper。但别指望它变成真流式。
- 纯中文深度场景、国内团队：FunASR。生态与工具链最顺。
- 端侧设备、离线优先：moonshine 方向对路，但先过自定义许可这一关。
- 研究流式建模本身：Kyutai delayed-streams-modeling。
- 还在纠结上云还是本地：先读站内 云端与本地语音 AI 横评，把成本与合规账算清再回来选型。
最后提醒一句：680 星的 R2T2 面对两万五千星量级的 faster-whisper，生态厚度不在一个量级，选它等于押注真流式这个产品差异点值多少钱。如果字幕不回改正是你的命门，这一注值得下；如果不是，成熟度优先。
再把镜头拉远一点看整个赛道。Whisper 本体以 109,704 星（MIT，2026-09-29 快照）稳坐开源语音识别的头把交椅，本篇的 faster-whisper 正是围绕它做推理加速；vosk-api 以 15,153 星（Apache-2.0）代表离线轻量的另一条传统路线，不走大模型架构。这两个备查项目本文没有展开横评，但它们提示了一个事实：流式大模型 ASR 仍是这个领域的年轻分支，R2T2 与 Kyutai 的探索更像是在给下一代实时语音产品铺路。今天星数少，不等于方向弱；星数多，也不等于真流式。
常见问题
Q1： 怎么一眼分辨真流式和伪流式？
A：盯住已输出的文本。真流式是 append-only，说出的字永久提交；伪流式靠切片重算，前文会回改。拿一段长音频连续喂三十秒，看前面的话改不改，一试便知。
Q2： R2T2 的 2.13 WER 能直接和 faster-whisper 的分数比吗？
A：不能。这是 R2T2 官方评测口径（README）下的数字，表中竞品分数也在同一口径测得。各家 harness 不同，准确率数字不可横比，要比较只能用同一套测试集与切分方式自行复测。
Q3： moonshine 到底能不能商用？
A：它是自定义许可（GitHub API 标注 NOASSERTION），不是标准开源许可，能否商用取决于条款原文。商用前必须自行逐条审阅条款，必要时过法务；审完之前，按不可商用对待最稳妥。
Q4： 没有 GPU 能跑这几款吗？
A：有得选。R2T2 官方支持 llama.cpp 后端，CPU 与边缘场景有官方路径；moonshine 本身就走端侧轻量路线。faster-whisper 与 FunASR 的 CPU 支持情况，建议查各自文档确认当前版本能力，本文不替官方下结论。规划硬件时还有一个提醒：真流式对推理吞吐的占用是持续性的，与批处理的峰值负载不同，容量评估要按稳态算。
Q5： 中文实时字幕场景首选哪个？
A：优先在 R2T2 与 FunASR 之间切：要真流式不回改、生产后端齐全，选 R2T2（官方口径中英优化，含热词）；要中文生态与工具链深度，选 FunASR。其余三款各有所长，但对中文字幕这个具体场景，本文未核到足以支撑首选的官方口径。
参考来源
- Confucius4-R2T2 仓库与 README（延迟、评测口径、后端）：https://github.com/netease-youdao/Confucius4-R2T2
- faster-whisper 仓库：https://github.com/SYSTRAN/faster-whisper
- FunASR 仓库：https://github.com/modelscope/FunASR
- moonshine 仓库（许可证 NOASSERTION）：https://github.com/usefulsensors/moonshine
- Kyutai delayed-streams-modeling 仓库：https://github.com/kyutai-labs/delayed-streams-modeling
- GitHub API（star 快照 2026-09-29）：https://api.github.com