North Small Translate 1.0 对比 Hy-MT2-1.8B：218GB 的模型对 440MB

其中一个能装进手机里。Hy-MT2-1.8B，腾讯混元的端侧翻译模型，2026年5月21日以 Apache 2.0 协议开源，在 AngelSlim 1.25 比特量化下压缩到 440 兆字节，可在苹果、高通和联发科手机芯片上运行。North Small Translate 1.0，则是 Cohere 在 2026 年 9 月 9 日的发布说明中记录的 2180 亿参数混合专家模型，附带约 218 吉字节的 FP8 权重集，最低要求两块 B200。两者所需的存储量相差约五百倍，而真正有意思的问题不是哪个更好——而是它们各自究竟为何而生，以及哪种许可证允许你把它发布出去。

尺寸差距并非质量差距

人们很容易把 218B 与 1.8B 直接当作一次能力高低的排名来看。但事实并非如此，原因有两点。第一，North Small Translate 1.0 是一个稀疏的专家混合模型，每个 token 只有 250 亿参数处于激活状态，因此其单 token 的计算量与参数规模完全不在一个量级上。第二，这两个模型是针对不同的目标进行优化的：腾讯的 1.8B 模型追求足够小，以便在手机上离线运行；而 Cohere 的模型则追求将整篇文档容纳在上下文中，并作为一个整体进行翻译。

这种差异在上下文窗口上是清晰可见的。Hy-MT2-1.8B 的配置标称支持多达 262,144 个位置，但腾讯自家的推理指南将生成上限控制在 8,192 个 token——实际可用窗口为 8K。North Small Translate 1.0 标称 16K 输入和 16K 输出，这是输入窗口的两倍，更重要的是，还有完整的 16K 输出。如果你的工作单元是服务手册，那么输出预算就是关键特性。如果你的工作单元是一条聊天消息，那就无关紧要了。

• 总参数量 — North Small Translate 1.0：218B MoE，激活 25B，对比 Hy-MT2-1.8B：1.8B 稠密

• 上下文—— 输入 16K、输出 16K，对比 8K 的工作窗口（配置宣称最多支持 262,144 个位置；腾讯的指南称 8,192）

• 语言 — 50（英语 + 49）对比 33 种语言加上 5 种少数民族语言和方言

• 许可 — CC BY-NC 4.0，商用需通过 Model Vault，对比 Apache 2.0，无门禁

• 量化占用 — FP8 约 218GB，NVFP4 W4A16 约 109GB，相比之下 1.25-bit 仅 440MB，FP8 和 GGUF 版本也已发布

• 最低硬件要求 — 与手机相比，FP8 精度下需 2×B200 或 4×H100

腾讯在18亿中实际交付了什么

1.8B 是一个三模型系列中最小的成员——1.8B、7B 以及 30B-A3B MoE 旗舰版——它们与一个名为 IFMTBench 的配套基准一同发布，该基准衡量的是翻译指令遵循能力，而非原始翻译质量。腾讯在基础权重之外还提供了 FP8、GGUF、2-bit 和 1.25-bit 量化版本，其中 1.25-bit 版本正是那个产生 440MB 数字、并宣称相较上一代 Hy-MT1.5 实现 1.5 倍推理加速的版本。服务支持通过 transformers 5.6.0 及更高版本、vLLM、SGLang 和 llama.cpp 提供，其中 GGUF 路径依赖于已合入 llama.cpp 的 STQ 内核。推荐的采样参数为 temperature 0.7、top_p 0.6、top_k 20、重复惩罚 1.05，并且没有默认系统提示词——这与 Cohere 的做法正好相反。

与 North Small Translate 1.0 不同，它也是一款有明显采用迹象的模型。Hugging Face 仓库的下载量已超过 23,000 次，并获得了约 1,200 个赞。本文撰写时，Cohere 的主仓库显示有 26 次下载和 0 个赞。

许可证是更鲜明的差异

这才是比基准测试表更能左右部署决策的部分。Hy-MT2-1.8B 采用 Apache 2.0，没有任何访问限制——商业使用、微调、衍生作品、再分发，全都允许。North Small Translate 1.0 采用 CC BY-NC 4.0：权重可免费用于非商业用途，而商业部署需要通过 Cohere 的 Model Vault 购买许可证，但其价格并未公布。

直白地说：如果你在做产品，腾讯的模型是今天无需任何沟通就能直接上线的那个，而Cohere的模型是你只能去评估的那个。这种不对称并不意味着Cohere的模型更差，但它改变了操作顺序——你去评估Cohere的模型，而腾讯的模型你可以直接部署。

质量证据是不对称的，而且双方的证据都是由供应商报告的。

这两个模型都没有独立评估作为支撑，因此这里每个数字都应视为其制造商的说法。区别在于制造商愿意公开多少。腾讯发布了一张完整的对比表和一份技术报告：在 FLORES-200 英语到 X 语言的翻译上，Hy-MT2-1.8B 取得 90.00，而 Gemini 3.1 Pro 为 94.42，GPT-5.5 为 94.16——略微落后于前沿模型，但只差几分，而且这是一个能装进手机的模型。在 IFMTBench 的整体指令遵循得分上，1.8B 为 69.36%，远远落后于其自家的 30B-A3B 同门（85.7%）以及 Gemini 3.1 Pro（89.08%），这才是对这一取舍的诚实解读：这个小模型遵循格式和术语指令的可靠性，远不如它的翻译能力。

Cohere 只公布了一个数字——WMT26 得分 83.60，在采用智能体式多轮工作流后升至 84.36——既没有附上指标名称，也没有可供核对的 WMT26 结果页面。这样的比较我们无从做起。一个没有名称的孤立数字，无法与一张列满具名基准的表格相提并论，而假装可以，将是本文所能做出的最具误导性的事。

腾讯的制衡之处在于，其数字来源可供读者查验。Hy-MT2 仓库发布了系列概览、三种模型规模以及各自支持的运行环境，并附上了基准测试表——正因如此，FLORES-200 和 IFMTBench 的数据才具备可核查性，也正因如此，相比之下 Cohere 那个未具名的单一数字才显得格外扎眼。

调用每一个需要多少费用

腾讯的 1.8B 有一个托管的商业 API，于 2026 年 8 月推出，定价约为每百万输入 token 0.044 美元、每百万输出 token 0.177 美元——从绝对数字看很便宜，而且是按 token 计费的。Cohere 的模型运行在 Chat V2 的免费层级上，在达到速率限制之前，试用密钥和生产密钥均可免费使用，因此评估成本为零，但生产成本是一份你必须协商的合同。自托管则彻底颠覆了这笔账：手机上的 440MB 对比两块 B200，这一差异是以数量级而非百分比来衡量的。

在讨论路由平台的文章里，之所以值得点明这一差距，是因为廉价层级与昂贵层级并非竞争对手——它们是级联中的两个位置，而级联正是路由器存在的意义。OrcaRouter 以 0% 加价率透传供应商列表价，因此托管翻译端点的供应商降价当天就会在我们这边生效，无需就转售利差重新谈判；故障转移链让较小的模型承接大部分流量，而较重的模型接管它处理失败的请求。先试便宜的，遇到困难情况再升级，让路由层持有策略，而不是你的应用代码。

你应该选哪一个

如果你的翻译需要在设备上、离线进行，处于按每兆字节计算的存储预算之下，或者存在于一个对许可证谈判毫无兴趣的商业产品中，那么 Hy-MT2-1.8B 就是答案，而 North Small Translate 1.0 则不在考虑之列。如果你的工作单元是 Cohere 支持的五十种语言之一中的一篇长文档，如果你需要单次输出 16K，并且如果你的组织愿意购买商业许可证，那么 Cohere 的模型在所有公开披露的维度上都是更强大的机器——但需注意，其质量仅建立在一个尚未被复现的数字之上。

对大多数团队而言，诚实的答案是两者都要，而且顺序就是这样：440MB 的模型以极低的成本处理日常事务，218B 的模型负责真正重要的文档，而哪个请求交给谁的决策，是一条路由规则，而不是一次重写。这两个模型之间的差距不是一道需要弥合的鸿沟，而是一段可供利用的谱系。