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 種語言。如果語言數量就是比較的全部，這篇文章會很短，但事實並非如此：這兩個模型是為不同任務打造的不同機器，而它們之間四年的差距，會以一些與清單上出現多少種語言毫無關係的方式顯現出來。接下來要談的是：各自實際上擅長什麼、運行成本是多少，以及授權條款會把你帶往何處。

覆蓋數值，老實說

兩百對比五十是真實存在的，而且這是把 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 個符元，並警告更長的序列會導致品質劣化。分詞器為來源與目標合計提供的預算是 1,024 個符元。NLLB-200 的模型卡也將其描述為研究模型，並未為正式生產部署而發布，同時註明它並非為文件翻譯而設計——這正是它與 Cohere 所打造之物最鮮明的分野。

North Small Translate 1.0 的形態正好相反。它是一個僅含解碼器的稀疏 MoE，總參數達 2,180 億，每個 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）vs 200

• 直接配對 — 以英語為中心的分層 vs 不經英語樞紐的任意對任意

• 授權條款 — CC BY-NC 4.0 vs CC BY-NC 4.0

• 最小佔用空間 — W4A16 時只需 1×B200，FP8 時需 2×B200；相較於 54B 在 4-bit 下需約 37GB VRAM，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 月經同儕審查的《Nature》論文，說明它是如何打造而成的。Cohere 則發布了一份版本資訊。

另一種取捨也同樣具體。NLLB-200 的模型卡將其描述為研究模型，並未發布供正式生產部署，而其旗艦 54B 檢查點是重量級——約 350GB 儲存空間，且未壓縮推論需約 108–120GB VRAM 才能提供服務。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 更好的起跑位置——在 NLLB-200 那邊，想知道結果的代價是租一台 GPU。

同時掌握這兩個事實的實用方式：NLLB-200 是能觸及其他模型都觸及不到的語言的模型，而且它建於 2022 年，用於句子層級的研究翻譯。North Small Translate 1.0 則是能用更少語言做得更好的模型，而且它建於 2026 年，用於文件。在兩者之間做選擇，其實並不是在評斷品質。這是一個關於你實際上要推出哪些語言的問題。