Hy-SimulMT 與 NLLB-200：串流口譯器並非 200 語言翻譯器

這兩個基準名稱只差一個字母，而那個字母就是整篇文章的關鍵。Hy-SimulMT是 Tencent Hunyuan 於 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 種。當 Tencent 回報 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 億個平行句對，而論文的主要宣稱是：相較於先前的最佳技術，BLEU 提升了 44%，且此結果是橫跨超過 40,000 個翻譯方向測量而得。其架構是專為單句翻譯打造的編碼器-解碼器 Transformer。它沒有串流模式、沒有音訊輸入，也沒有部分輸出的概念——輸入一句，就輸出了一句。

授權是 CC-BY-NC 4.0，而模型卡也直白說明了意圖：並非為正式上線部署而釋出，也不打算用於特定領域、文件長度、長輸入或經認證的翻譯。環繞權重的程式碼是 MIT 授權，但權重本身不是，而這正是此釋出問世四年來始終如影隨形的混淆所在。

截至本週，Hy-SimulMT 實際上究竟是什麼

Hy-SimulMT 幾乎在每個維度上都是形態相反的產物。它是一個語音模型：音訊以 16 kHz、30 秒視窗串流輸入，而模型在說話者仍在說話時就輸出譯文。其架構是擁有 304 億參數的稀疏混合專家模型，每個 token 約有 30 億參數處於啟用狀態，並搭配一個 24 層音訊編碼器。文件記載的語言對是中文與英文，雙向皆可。

其核心主張是延遲，而非涵蓋範圍。Tencent 報告在長篇 RealSI 音訊上的 StreamLAAL 約為三秒，並將其描述為其所比較系統中最低者。這與 NLLB 論文中的任何主張都不同；NLLB 論文完全沒有延遲量測，因為沒有東西可量：批次文字翻譯器並不存在落後於說話者的延遲。

此版本採用 Apache-2.0 授權且無須審核，提供六個檢查點，涵蓋兩種輸出形式——僅翻譯，以及原文加翻譯——每種形式皆提供全精度、FP8 與 GGUF 版本。全精度版本約 61 GB，GGUF Q4_K_M 版本則為 19.7 GB。語音輸出與聲音克隆需要獨立的 TTS 服務；模型本身僅產生文字。

就像 {{1}}NLLB-200{{/1}} 一樣，它沒有代管 API，也沒有公開定價。騰訊面向消費者的產品是 {{2}}Hy Translate{{/2}} 應用程式，設有免費方案。其餘情況都意味著要自行執行權重。

為什麼這些分數不能共用同一欄

誘惑就在於把 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。所有這些數字都是由廠商自行執行、在 Tencent 選定的測試框架上產生，且未經獨立重現。模型卡也沒有說明這些數字是由其兩種輸出變體中的哪一種產生。

延遲是以 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，屬於多 GPU 方案。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 授權，不設門檻，允許商業使用、修改與再散布。Tencent 在推論伺服器之外還隨附訓練工具包，因此持續訓練是預期用途之一。若單就授權在兩者之間做選擇，那根本沒得比。

它們在同一個堆疊中應有的位置

這個組合之所以一直有人搜尋，是因為團隊會在同一個產品裡同時遇到這兩個問題。一家同時有中文與英文業務的公司，既需要會議用的即時口譯，也需要一套文字處理流程，來處理透過電子郵件、合約與支援工單進來的 200 種語言文件流量。這是兩項不同的工作，而務實的架構會採用兩個不同的模型。

NLLB-200 或其現代後繼者負責離線文字路徑：批次翻譯、語言識別、語料庫分流，以及長尾部分。Hy-SimulMT 負責即時的中英語音路徑；在這條路徑上，延遲才是關鍵，涵蓋範圍則不重要，因為現場只有兩種語言。兩者之間的邊界是一項路由決策，值得明確說明，而不是讓應用程式依據檔案類型自行推斷。

這兩個模型都不在 OrcaRouter 的目錄中，因此我們並非通往其中任何一個的路徑。路由器真正提供的是它們周遭的接縫：以 0% 加成，在 200 多個託管模型前方提供單一 API，供應商牌價原樣傳遞、不額外加價，以及 一套決定請求走哪條路徑的路由 DSL。最後這部分看似平凡卻很實用——文字請求會落到託管的通用模型，語音請求則送往你自架的解譯器，而應用程式無須知道哪個是哪個。自動容錯移轉則涵蓋託管的那一段路徑無法使用、但請求仍必須回傳內容的情況。

因為託管段是按供應商牌價計價、未加收任何費用，所以文字端的供應商降價當天就會在我們這邊生效。這看似小事，直到你大量路由文件流量時，而替代方案是每次供應商更改費率表就得重新談合約。

在選擇任一之前要問什麼

問題不在於哪個模型更好。這其實是兩個問題，而它們有不同的答案。

如果輸入的是仍在傳入的音訊，且語言是中文與英文，答案就是 Hy-SimulMT——而部署問題就變成要選它的六個檢查點中的哪一個；這是在決定輸出形式與精確度，而不是品質。如果輸入的是尚未辨識出語言的文字，且涵蓋包含低資源語言的一組語言，NLLB-200 歷經四年仍是合理的開放基線，前提是非商業授權條款適用，且你能接受批次介面。

沒有人發表過的是中間的銜接：讓語音辨識把中文↔英文音訊餵給 NLLB-200，並在與 Hy-SimulMT 相同的串流基準上評估，同時一併報告延遲與品質。那個實驗將能告訴你：一個被包在 2026 年串流框架中的 2022 年文字翻譯器，能否與專為此打造的口譯器競爭。它也會是這兩個模型首次誠實的比較，而這樣的比較目前還不存在。

最後還有一點值得直說，因為這兩個只差一個字母的基準名稱會不斷引發錯誤的比較：一個在 FLEURS 上勝出的模型，只證明了它在特定評測框架下的語音翻譯表現；一個在 FLORES-200 上取得高分的模型，只證明了它在 200 種語言之間的文本翻譯表現。這兩項結果都無法套用到對方的工作上；而哪家廠商能針對同一段音訊，採用相同的指標與相同的延遲計算方式來同時發布這兩項結果，就會是第一家讓這種比較真正有意義的廠商。