North Small Translate 1.0 与 NLLB-200：50 种语言对比 200 种

较新的那款模型覆盖的语言只有它的四分之一。North Small Translate 1.0，Cohere 在 2026 年 9 月 9 日的发布说明中记录了它，可在英语与另外 49 种语言之间互译。NLLB-200则是 Meta 于 2022 年 7 月发布的 No Language Left Behind 系列，覆盖 200 种语言。如果语言数量就是全部的比较维度，这篇文章本该很短，但事实并非如此：这两个模型是为不同任务打造的两台不同机器，而它们之间四年的差距，体现在许多与列表上出现多少种语言毫无关系的地方。接下来要讲的是：各自真正擅长什么、运行成本是多少，以及许可条款会把你引向哪里。

说实话，覆盖率数字

200 对 50 是真实存在的，也是把 NLLB-200 留在技术栈中的最常被提及的理由。Meta 用超过 180 亿个句对训练了它，并明确侧重低资源语言；它能在任意语言对之间直接翻译，而不是经由英语中转——这一设计选择对于比如孟加拉语到泰米尔语来说至关重要，因为以英语为中转的系统会损失两次质量。

这个数字所掩盖的是，两份列表之间的重叠部分才是具有商业价值的部分。North Small Translate 1.0 的五十种语言包括德语、法语、西班牙语、葡萄牙语、意大利语、荷兰语、波兰语、捷克语、日语、韩语、简体中文和繁体中文、阿拉伯语、希伯来语、印地语、孟加拉语、泰米尔语、泰卢固语、泰语、土耳其语、越南语、印尼语、马来语、俄语和乌克兰语——这些语言占据了企业本地化工作量的绝大多数。NLLB-200 也覆盖了所有这些语言，并额外覆盖约 150 种 North Small Translate 1.0 完全未涉及的语言。因此，问题不在于哪份列表更长，而在于你的流量中是否包含只有两者之一支持的语言。

两台不同的机器

架构上的差距才是决定你能构建什么的部分。NLLB-200 已发布的最大检查点是一个约 545 亿参数的稀疏门控专家混合模型，而它的稠密同类则分别为 33 亿、13 亿，直至蒸馏后的 6 亿参数。它们全都是 M2M-100 一脉的编码器-解码器序列到序列模型：你把源语言片段交给分词器，它返回一个翻译好的片段。这里没有聊天模板，没有系统提示词，没有多轮结构，而且已发布的检查点都是围绕片段级翻译构建的：Meta 自己的模型卡说明，该模型训练时的输入长度不超过 512 个 token，并警告更长的序列会导致效果下降。分词器对源语言和目标语言的总预算为 1,024 个 token。NLLB-200 的模型卡还将其描述为研究模型，未面向生产部署发布，并指出它并非用于文档翻译——正是这一区别，使它和 Cohere 所构建的东西拉开了最鲜明的距离。

North Small Translate 1.0 的形态则相反。它是一个仅解码器的稀疏 MoE，总参数量为 2180 亿，每个 token 激活 250 亿参数，拥有 128 个专家，其中八个激活，另有共享专家；其注意力机制在滑动窗口层（窗口 4,096，RoPE）与不携带位置嵌入的全局注意力层之间交替。它运行在一个带有默认系统指令的聊天模板之下，其窗口为 16K 输入 token 和 16K 输出 token。这个输出预算正是关键所在：这是一个为接收一份文档并要求返回一份文档而构建的模型，而不是为接收一句话而构建的模型。

• 总参数量 — North Small Translate 1.0：218B MoE（激活 25B）对比 NLLB-200：54.5B MoE 旗舰，600M–3.3B 稠密

• 架构 — 仅解码器因果 MoE 搭配聊天模板，对比无聊天模板的编码器-解码器 seq2seq

• 上下文 — 输入 16K、输出 16K，对比段级，分词器预算合计 1,024 个 token

• 语言 — 50（英语 + 49）对比 200

• 直接配对 — 以英语为中心的分层 vs 不依赖英语作为枢轴的任意到任意

• 许可证 — CC BY-NC 4.0 vs CC BY-NC 4.0

• 最小占用空间 — 54B 模型在 W4A16 下仅需 1×B200，FP8 下需 2×B200，而 4 位量化需约 37GB 显存；600M 则随处可运行

• 已发布 — 2026年9月9日（权重自8月14日起在 Hugging Face 上受限开放）对比2022年7月

NLLB-200仍拥有什么

有三件事，而且它们并非出于情怀。第一是长尾：如果你需要奥罗莫语、提格里尼亚语，或 North Small Translate 1.0 列表之外的约150种语言中的任何一种，那么决定已经做出了。第二是小尺寸端的占用——蒸馏版 600M 检查点下载量已达140万次，并且能在连 Cohere 权重都加载不了的硬件上运行，这使它成为两者中唯一无需量化技巧就能适配气隙或边缘部署的一个。第三是成熟度：NLLB-200 背后有四年的工具链、量化分支和生产实战经验，还有一篇2024年6月经过同行评审的《自然》论文描述其构建方式。Cohere 则只发布了一份发布说明。

另一条路要做的取舍同样具体。NLLB-200 的模型卡将其描述为一个研究模型，并未面向生产部署发布，而其旗舰级 54B 检查点是个重量级选手——大约 350GB 存储空间，未压缩运行时需要约 108–120GB 显存。Meta 并不出售托管的 NLLB 端点。要大规模运行它，是你自己的问题，而且是个实实在在的问题。

双方的许可陷阱

这一点最出人意料，因为这两个模型采用同一许可证，而且并不是大多数团队所以为的那一个。NLLB-200 和 North Small Translate 1.0 均以 Creative Commons Attribution-NonCommercial 4.0 发布。按发布时的状态，两者都不能用于商业产品。NLLB-200 的非商业限制争议之大，以至于出现了一个名为 Open-NLLB 的社区项目，专门试图做出一个可商用的衍生版本，而这又直接撞上了它所源自的许可证。Cohere 的路径更干净：购买商业许可证并通过 Model Vault 部署，而 FP8 权重在 Hugging Face 上免费提供，仅供非商业用途使用。

有一个不对称之处值得指出。Cohere 在其 Chat V2 API 的免费层级中提供 North Small Translate 1.0，对试用密钥和生产密钥免费，直到达到速率限制——因此你可以零成本进行真实评估，只有当你正式上线时才需要签署协议。NLLB-200 只给你权重，别无其他。

部署其中任意一个

North Small Translate 1.0 以三种检查点形式发布——BF16、FP8 和 NVFP4 W4A16——每种都公布了最低硬件要求：BF16 需要四块 B200 或八块 H100，FP8 需要两块 B200 或四块 H100，而 W4A16 只需一块 B200 或两块 H100。服务通过 vLLM 提供，要求 cohere_melody>=0.9.0，Cohere 推荐使用贪婪解码，这与其生产配置一致。输出会被包裹在 <|START_TEXT|> 和 <|END_TEXT|> 标记中，而这些标记并未注册为特殊 token，因此简单地设置 skip_special_tokens=True 会让它们留在你的输出里。

NLLB-200 可通过标准的 transformers 或 fairseq 路径部署，对小型硬件的容忍度要高得多，因为 600M 和 1.3B 的蒸馏检查点才是大多数人实际运行的版本。54B MoE 则是需要提前规划的那一个。

这场对决实际代表的路径选择问题

North Small Translate 1.0 和 NLLB-200 目前都还不在OrcaRouter 的模型目录中，所以这篇文章并不是要从我们的货架上挑一款。不过，这个问题的形态还是值得说清楚的，因为“一流语种用一个模型、长尾语种用另一个模型”本身就是一种路由策略——而路由策略这类东西，应该放在配置里，而不是应用程序代码里。OrcaRouter 的路由 DSL 正是用 YAML 加 CEL 规则来表达这一点，于是一条语言对规则可以把欧洲语言对交给某个模型，并在某个语言对不受支持时回退到另一个模型；故障转移链则意味着，某个上游开始返回错误时，不会就此变成你的服务中断。这就是一把密钥、一次集成，覆盖 200 多个模型的目录，按供应商标价、0% 加价，而无需为你决定要尝试的每一个翻译模型再签一份供应商合同。

你应该选择哪一个

如果你的内容策略涉及 Cohere 那五十种之外的语言，那就保留 NLLB-200，并把这当作定论——再多的架构现代性也无法弥补一种语言的缺失。如果你正在做面向 Cohere 所列语言的企业级本地化，工作单位是文档而非句子，并且愿意购买商业许可证，那么 North Small Translate 1.0 在文档披露的每一个维度上都是能力更强的模型，但有一个重要前提：其唯一的质量证据只是一个未复现的厂商数据。如果你在原型开发且没有预算，Cohere 的免费层让这种评估几乎零成本，这比 NLLB-200 的起点更好——后者的试错代价是租一块 GPU。

同时把握这两个事实的有用方式是：NLLB-200 是那个能覆盖其他模型都触及不到的语言的模型，它于 2022 年为句子级研究翻译而构建。North Small Translate 1.0 则是把更少语言做得更好的模型，它于 2026 年为文档而构建。在二者之间做选择，其实并不是质量判断，而是一个关于你实际要交付哪些语言的问题。