Hy-SimulMT 与 NLLB-200：流式口译器并非 200 语种翻译器

这两个基准名称只差一个字母，而那个字母正是整篇文章的关键。Hy-SimulMT是腾讯混元于2026年10月26日发布的中英双向实时口译模型，它在名为FLEURS的基准上公布了90.3的分数。NLLB-200是Meta AI于2022年7月推出的200语种文本翻译模型，评估用的是名为FLORES-200的基准。二者有关联——FLEURS由FLORES的句子朗读而成——但它们并不是同一个测试，评分方式也不同，而且从来没有人让这两个模型正面对决过。搜索这一对决，只会得到其中一个模型的发布报道和另一个模型的文档，中间什么都没有。这种缺失才是诚实的起点：它们不是竞争对手，真正有用的问题是它们各自究竟适用于哪项任务。

一封信，两项基准

FLORES-200 是一个文本基准。Meta 在 No Language Left Behind 项目中构建了它：包含 200 种语言的专业翻译句子，用于衡量翻译系统将书面文本从一种语言转换到另一种语言的效果。主要指标是 spBLEU，这是一种 BLEU 变体，在固定的、语言平衡的分词器上计算，以便使用不同文字系统的语言之间的分数具有可比性。NLLB 论文还报告了 chrF++ 和一种名为 XSTS 的人工评估。

FLEURS 是它的语音版姊妹数据集。它采用 FLORES 句子集，由母语者朗读这些句子，并评估语音翻译——输入音频，输出文本。它覆盖 102 种语言，而非 200 种。当腾讯为 Hy-SimulMT 报告 FLEURS 上的 90.3 分时，这个数字涵盖整个流程：听到音频、识别词语并翻译它们。当 Meta 为 NLLB-200 报告 FLORES-200 上的 spBLEU 时，文本已经正确且完成分词，唯一被衡量的只是翻译步骤。

把这两个数字并排放在一起，你并没有比较两个模型。你比较的是一个端到端语音系统和一个文本翻译器，它们使用的是不同的数据、不同的指标、不同的语言。这正是单个字母的相似性所招致的错误，值得在本文的任何其他比较之前先点明。

四年过去，NLLB-200 到底是什么

NLLB-200 于 2022 年 7 月发布，此后一直没有修订过。你今天下载的检查点，就是 2022 年的检查点。这并不是批评——而是在说明这究竟是一件什么样的产物：一次研究发布，它定义了一个基准和一个数据集，然后就止步于此了。

该系列涵盖五种尺寸，而这种跨度正是关键所在：

• NLLB-200-distilled-600M — 最小的可用检查点，小到足以在笔记本电脑级 GPU 上运行。

• NLLB-200-distilled-1.3B 和 NLLB-200-1.3B——中端组合，一个为速度而蒸馏，一个直接训练。

• NLLB-200-3.3B——稠密模型中的主力，也是大多数人实际部署的规模。

• NLLB-200-54.5B——旗舰稀疏模型：包含 128 个专家并采用 top-2 门控，每第四个 Transformer 块中设有一个专家混合层，且每个 token 的计算量大致与 3.3B 稠密模型相当。它是同代最大的开源翻译模型，至今仍是该系列被引用的原因。

训练集大约包含 180 亿个平行句对，而论文最引人注目的结论是：在超过 40,000 个翻译方向上测得，相比此前的最先进水平，BLEU 提升了 44%。该架构是一个专为单句翻译构建的编码器-解码器 Transformer。它没有流式模式，没有音频输入，也没有“部分输出”的概念——输入一句话，返回一句话。

许可证是 CC-BY-NC 4.0，模型卡对意图说得很直白：未发布用于生产部署，也不适用于特定领域、文档长度、长输入或认证翻译。围绕权重的代码采用 MIT 许可，但权重本身不是，这正是四年来伴随这次发布的混淆所在。

截至本周，Hy-SimulMT 实际上是什么

Hy-SimulMT 在几乎所有维度上都是一种形态相反的人工产物。它是一个语音模型：音频以 16 kHz 的采样率、按 30 秒窗口流入，模型会在说话人仍在讲话时输出译文。其架构是一个拥有 304 亿参数的稀疏专家混合模型，每个词元约有 30 亿参数处于激活状态，并围绕一个 24 层音频编码器构建。文档记载的语言对是中文和英文，支持双向互译。

它的核心主张是延迟，而非覆盖范围。腾讯报告称，在长格式 RealSI 音频上，StreamLAAL 约为三秒，并将其描述为在其所比较的系统中最底。这与 NLLB 论文中的任何主张都不同；NLLB 论文完全没有延迟测量，因为没有什么可测量的：批处理文本翻译器不存在落后于说话者的滞后。

该发布版本采用 Apache-2.0 许可且无需门禁，包含六个检查点，覆盖两种输出形态——仅译文和原文加译文——每种均提供全精度、FP8 和 GGUF 版本。全精度构建约为 61 GB，GGUF Q4_K_M 构建为 19.7 GB。语音输出和声音克隆需要单独的 TTS 服务；模型本身只生成文本。

和 NLLB-200 一样，它没有托管 API，也没有公布价格。腾讯面向消费者的产品是 Hy Translate 应用，它提供免费套餐。其他所有方式都意味着要自行运行权重。

为什么分数不能共用一列

人们很容易把 Hy-SimulMT 的四个分数与手边最近的 NLLB-200 数字并排比较。要抵制这种诱惑，而且不仅仅是因为 FLEURS/FLORES 的区别。这两个模型被问的是不同的问题。

• 输入模态 — Hy-SimulMT 接收音频，因此其得分包含识别错误。NLLB-200 接收的文本已去除识别错误。同一批句子上的语音模型和文本模型并不在同一起跑线上。

• 指标 — Hy-SimulMT 在语音翻译数据集上报告 BLEU 系列分数；NLLB-200 在 FLORES-200 上报告 spBLEU、chrF++ 和 XSTS。spBLEU 的分词器专门用于确保跨语言比较公平，这意味着即使两者都称为 BLEU，它也不能与普通 BLEU 数值互换。

• 工作单元 — NLLB-200 在对齐文本上逐句评估。Hy-SimulMT 在流式音频上评估，其中值得关注的失败并非某个词被误译，而是句子到达得太晚、已无用处。

• 方向数量 — NLLB-200 的四万余个方向被平均计入其总体指标；Hy-SimulMT 的四个基准仅覆盖中英互译。对长尾取平均与在一个高资源语言对上得分，描述的是不同种类的成就。

在其自己的表格中，Hy-SimulMT 也并非全面领先。它在 CoVoST2 上得 75.5 分，而 Qwen3.8-LiveTranslate 为 82.1 分；并且在 FLEURS（90.3 对 92.4）和 ACL6060（81.2 对 82.6）上落后于 Gemini3.5-LiveTranslate。它最明显的胜项是 RealSI-Sentence，为 84.7。所有这些数字均由厂商运行，是在腾讯选定的测试框架上得出的，且未经独立复现。模型卡也没有说明它们是由其两种输出变体中的哪一种产生的。

延迟是以 NLLB 所不具备的单位来衡量的。

真正决定部署的是这一部分，它与基准测试分数毫无关系。

同声传译员必须做出批处理翻译器永远不会面对的权衡：是等得更久、译得更好，还是更早开口、冒着出错的风险。StreamLAAL 衡量的正是这种权衡——大致是输出平均落后输入多少。Hy-SimulMT 的三秒就是对这种权衡的一项声明。它明确不等同于首次语音输出的时间，腾讯在模型卡上也明确说明了这一点。一旦加入外部 TTS 服务，听众的体验也会包含该服务的延迟，而三秒这个数字并不包含这一点。

NLLB-200 没有对应的数值，因为它没有流式处理路径。你可以给它额外接上一条：把音频分块，运行语音识别，将句子片段喂给 NLLB，并在译文完成时逐条输出。这种架构可行，而且已有团队这样构建过。但分块会破坏句子级翻译器所依赖的上下文，由此得到的质量并不是在 FLORES-200 上用完整、规范的句子测得的那个质量。“NLLB-200 在 FLORES 上得分为 X”与“NLLB-200 在分块式实时流水线中听起来像 Y”之间的差距，才是大部分工程精力实际投入的地方。

这才是真正的不对称之处。Hy-SimulMT 是为流式场景设计的，并为此在语言覆盖范围和 30B 级体量上付出了代价。NLLB-200 是为广度而设计的，并为此在仅支持批处理的接口上付出了代价。两者都不落后。它们针对不同的约束进行了优化。

覆盖率随深度变化

NLLB-200 的持久优势在于长尾。它涵盖两百种语言，包括大多数 2026 年的模型完全无法处理的低资源语言；这一模型家族可从 600M 检查点扩展到 54.5B 的专家混合模型。如果你要处理的文档所用语言只有几百万使用者，且没有商业 API 覆盖，NLLB-200 仍是少数开放选项之一，而且 3.3B 稠密检查点可在单块普通 GPU 上运行。

Hy-SimulMT 根本做不了这项工作。它记录的是中文和英文。其 Hugging Face 元数据带有 36 种语言的标签，但其余 34 种语言的列表并未公布，而且仓库中的每个示例都使用 en-zh 或 zh-en。仅凭那个标签就规划多语言推广将是一个错误。

硬件算力的账则要反过来算。NLLB-200 的 3.3B 稠密模型在 FP16 下只有几个 GB，可以轻松装进 16–24 GB 的显卡。其 54.5B 旗舰模型在 FP16 下约 108 GB——需要多卡并行。Hy-SimulMT 在 BF16 下约 61 GB，按原样部署需要 80 GB 加速卡；若走 GGUF 路径、采用 Q4_K_M 量化则为 19.7 GB，而该路径的 llama.cpp 支持尚未进入上游。因此，在小规模一端 NLLB-200 更便宜，在顶端两者相当；Hy-SimulMT 的成本集中在中段，而它换来的是流式处理能力。

这些许可证指向相反的方向

这不是比较的主干——模态才是——但这是最快判定其中一方不适合商业产品的方法。

NLLB-200 的权重采用 CC-BY-NC 4.0 许可。仅限非商业用途。周边代码采用 MIT 许可，混淆正是由此而来，但你实际要提供服务的对象是权重，而 Meta 的模型卡明确说明，这些模型并未发布用于生产部署。商业部署需要换用其他模型，或作出许可安排。

Hy-SimulMT 采用 Apache-2.0 许可，无需申请即可获取，允许商业使用、修改和再分发。腾讯在推理服务器之外还提供了训练工具包，因此持续训练是一种预期用途。如果仅从许可角度在两者之间做选择，那根本没有可比性。

它们在同一个堆栈中的位置

这组对比之所以持续被搜索，是因为团队会在同一款产品中同时遇到这两个问题。一家同时开展中英文业务的公司，既需要用于会议的实时口译，也需要一条文本处理流水线，来处理通过邮件、合同和支持工单涌入的200种语言文档流量。这是两项不同的工作，而诚实的架构会使用两种不同的模型。

NLLB-200 或现代后继模型负责离线文本路径：批量翻译、语言识别、语料筛选和长尾场景。Hy-SimulMT 负责实时中文↔英语语音路径；在这条路径上，延迟占主导，而覆盖范围无关紧要，因为房间里只有两种语言。二者之间的边界是一个路由决策，值得明确说明，而不是让应用从文件类型推断出来。

这两个模型都不在 OrcaRouter 的目录中，因此我们并不是通往其中任何一个的路由。路由器真正提供的，是围绕它们的那道接缝：一个 API 位于 200 多个托管模型之前，且零加价，供应商标价原样透传、不额外加收任何费用，以及一个路由 DSL，用来决定请求走哪条路径。最后这部分平淡却实用——文本请求会落到某个托管的通用模型，语音请求会交给你的自托管解释器，而应用无需知道哪个是哪个。自动故障转移则覆盖了托管这一路不可用、而请求仍然必须返回内容的情况。

由于托管部分按提供商目录价定价、没有任何加价，文本侧供应商一旦降价，我们这边当天就会生效。这看似是小事，直到你要大规模路由文档流量，而另一种选择是每次提供商调整费率卡都要重新谈合同。

在做出任一选择之前该问什么

问题不在于哪个模型更好。这是两个问题，而它们的答案不同。

如果输入是仍在到达的音频，且语言为中文和英文，答案是 Hy-SimulMT——此时部署问题就变成在其六个检查点中选择哪一个，而这是关于输出形态和精度的决策，而非质量。如果输入是尚未识别语言的文本，且涵盖包括低资源语言在内的一组语言，那么四年之后，NLLB-200 仍然是一个合理的开放基线，前提是非商业许可证适用，并且你接受批处理接口。

尚未有人发表的是二者之间的桥梁：让语音识别为中英双向音频上的 NLLB-200 提供输入，在与 Hy-SimulMT 相同的流式基准上评估，并同时报告延迟和质量。这个实验会告诉你，一个封装在 2026 年流式框架中的 2022 年文本翻译器，能否与专门构建的口译系统竞争。它也将是这两个模型的首次诚实比较，而它目前尚不存在。

最后一点值得直说：正因为 FLEURS 与 FLORES 的基准名称只差一个字母，这种相似性会不断催生糟糕的对比。一个模型在 FLEURS 上胜出，只能说明它在特定测试框架下的语音翻译表现；一个模型在 FLORES-200 上得分高，只能说明它在 200 种语言上的文本翻译表现。这两种结果都无法迁移到对方所承担的任务上；只有那个在同一批音频上同时公布这两项结果、采用相同指标和相同延迟核算方式的厂商，才会第一个让这种比较真正有意义。