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 MB，並可運行於 Apple、Qualcomm 與 MediaTek 的手機晶片上。North Small Translate 1.0則是 Cohere 在 2026 年 9 月 9 日發布說明中所記載的 2180 億參數混合專家模型，其 FP8 權重集規模約 218 GB，且至少需要兩張 B200。兩者之一的儲存需求大約是另一個的五百倍，而耐人尋味的問題並不是哪一個比較好——而是它們各自究竟為了什麼而生，以及哪一種授權能讓你把它出貨。

尺寸差距不等於品質差距

很容易把 218B 與 1.8B 的對比直接解讀成能力排名。但事實並非如此，原因有兩個。第一，North Small Translate 1.0 是稀疏混合專家模型，每個 token 僅有 250 億個參數處於啟用狀態，因此每個 token 的運算量和參數數量根本不在同一個量級。第二，這兩個模型是針對不同目標進行最佳化的：Tencent 的 1.8B 打造得夠小，可以在手機上離線執行；而 Cohere 的模型則是要把整份文件保留在上下文中，並將它當作一個整體來翻譯。

這種差異在上下文視窗中清晰可見。Hy-MT2-1.8B 的配置標稱最多可達 262,144 個位置，但騰訊自家的推論指引將生成上限設在 8,192 個詞元——實際可用的工作視窗就是 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 亦已發布

• 最低硬體需求 — 2×B200 或 4×H100（FP8）對比手機

Tencent 在 1.8B 中實際推出了什麼？

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 次下載和零個讚。

授權才是更明顯的差異。

這才是應該比基準測試表更能決定部署選擇的部分。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 的 English-to-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 模型負責真正重要的文件，而哪個請求該交給誰，是一條路由規則，而不是一次改寫。這兩個模型之間的落差，不是一道有待彌補的鴻溝，而是一個值得善用的光譜。