Hy-SimulMT-30B-A3B 對決 Helsinki-NLP OPUS-MT：即時口譯器迎戰一資料夾的專家模型

想像同一場會議演講以兩種方式處理。在第一種方式中，麥克風將音訊送入自動語音辨識器，辨識出的句子送進翻譯模型，譯文再送進語音合成器，聽眾在講者說完華語幾秒後就聽到英語——而每一個名稱、數字和縮寫都挺過了三次可能被弄壞的關卡。在第二種方式中，單一模型聆聽音訊，並在句子展開的同時輸出譯文。Hy-SimulMT-30B-A3B由 Tencent 於 2026 年 10 月 22 日以權重形式發布，正是為第二種方式而打造。Helsinki-NLP OPUS-MT是全世界部署最廣泛的開放翻譯系統，專為第一種方式中較狹窄的版本而打造：它一次翻譯一句文字，每個檢查點僅對應一個語言方向，而且因為它能在 CPU 上免費完成這項工作，已被下載數十萬次。

這兩者並非一般意義上的競爭對手。一個是需要加速器的 304 億參數語音模型；另一個則是由一千多個雙語檢查點組成的集合，每個檢查點約有 7,000 萬到 8,000 萬個參數，多數約 300 MB，能在筆記型電腦上輕鬆運行。真正有用的比較，不是哪一個翻譯得更好，而是翻譯元件與翻譯系統之間的界線落在何處，以及你希望自己掌控這條界線到什麼程度。

每一個實際上是什麼

OPUS-MT 由赫爾辛基大學的 NLP 團隊維護，建構於 MarianMT 編碼器-解碼器架構之上。它不是單一模型，而是一個目錄：針對中英、英中、英德等數百個其他方向，各有獨立的檢查點；每個檢查點都以 OPUS 集合中的平行語料訓練，且皆可單獨下載。光是中英檢查點就已下載近五十萬次；反向方向則約達 73,000 次。也有多語變體，將許多來源語言整合到單一英語目標模型中，但常見情況是只專精單一工作的窄域專家。

這套架構說明了它的優勢，也說明了它的上限。一個僅以平行語料訓練、擁有 7,700 萬參數的編碼器-解碼器模型，沒有容納世界知識的空間、沒有指令介面，也沒有串流機制。餵它一句話，它就回傳一句話。餵它一段文字，它會把整段當成一連串句子來翻譯，彼此沒有共享上下文；而已發表的工程筆記指出，它在處理長輸入時傾向於無聲無息地丟棄內容。你無法要求它保留詞彙表中的術語、保留 JSON 鍵，或符合正式語體——這些都得靠前處理與後編輯來處理，或者在你願意自行建置的前提下，用受限解碼來處理。

Hy-SimulMT-30B-A3B 屬於截然不同的物件類型。其配置描述了一個 48 層的稀疏混合專家模型，內含 128 個專家，每個 token 有八個路由專家加一個共享專家，並由一個 24 層音訊編碼器饋入 2,048 寬的主幹。模型卡中並未展開名稱裡的「A3B」，但依配置推算，約有 30 億個啟用參數，總參數則為 304 億。它接收以三十秒視窗切分的 16 kHz 音訊並產生譯文；Interleave 變體還會輸出來源轉錄。文字轉語音與聲音複製由部署工具組所連接的獨立服務處理，這意味著「語音轉語音」產品是一套組裝而成的系統，而非單一檔案。

延遲論證其實是誤差傳播論證。

延遲是最明顯的差異，也是最不有趣的一點。串接式架構可以調校得很快；一套良好的串流 ASR 搭配部分假設，再加上小型 MT 模型，可以在講者之後遠低於一秒內產出可用的字幕串流。同步模型之所以存在，是因為串接式架構的速度是靠讓每個階段取得較少上下文換來的，而每個階段接著會犯下下一階段看不見的錯誤。辨識器聽錯專有名詞，翻譯器無從知道那是個名字，合成器則自信地把錯誤唸出來。聽者無從判斷是哪個階段出錯。

一個在整個任務上端到端訓練的單一模型，原則上可以把決策延後到音訊消除歧義為止；若啟用語音複製，它也能保留講者的聲音。Tencent 的說法正是在講這個取捨：在長篇 RealSI 音訊上約三秒的 StreamLAAL，被描述為比較系統中最低者，其 GEMBA 品質分數高於其表格中的開源模型，以及五個商業 API 中的四個。三秒是否理想完全取決於情境——在談判中是很長的時間，在講座中則是很短的時間——但它是串流任務上的測量結果，而這正是 OPUS-MT 若沒有圍繞它建構的串接流程就無法嘗試的任務。

覆蓋率，誠實計算

這正是資料夾決定性勝出的地方，也是多數比較刻意模糊掉的部分。OPUS-MT 的一千多個檢查點涵蓋約一百種語言、橫跨各種翻譯方向，包括從未有大型多語言模型見過的低資源語言對。Hy-SimulMT 記載了中英雙向語音翻譯。該儲存庫的中繼資料標記了 36 種語言——其中包括法語、阿拉伯語、高棉語、藏語、哈薩克語和維吾爾語——但文字敘述只描述中英這一對，而模型卡中沒有任何內容解釋這個落差。最可能的解讀是，這些標籤描述的是承自騰訊 Hy-MT2 系列的文字主幹，而非語音能力，但這是一種詮釋，並非已公布的事實。

所以，誠實的涵蓋範圍說法是：中繼資料宣稱有三十六種語言，語音方面有文件記錄的只有兩種語言，對照之下，文本目錄則有一百多種語言。如果你的需求是在即時會議中進行中文（普通話）到英文的翻譯，Hy-SimulMT 正是為你而設。如果你的需求是在靜態文件上進行波蘭語到芬蘭語的翻譯，OPUS-MT 有對應的檢查點，而 Hy-SimulMT 沒有。

品質證據：一方有獨立數字，另一方有供應商表格

就文字翻譯品質這個狹義問題而言，獨立證據對 OPUS-MT 有利。一篇已發表、關於法薩拉登語翻譯的研究測得某個 OPUS-MT 模型在義大利語到英語上為 55.61 BLEU，相較於 NLLB-200 的 52.93 與 M2M-100 的 44.18；在英語到義大利語上則為 44.35，相較於 40.13 與 32.40。該研究的啟示是，一個僅針對單一翻譯方向訓練的模型，在該方向上仍能勝過規模大得多的多語系統。它對語音毫無著墨，也不涉及 Hy-SimulMT，因為完全沒有獨立實驗室評估過 Hy-SimulMT。

另一方面，騰訊報告 Hy-SimulMT 在 FLEURS 上為 90.3、CoVoST2 為 75.5、ACL6060 為 81.2、RealSI-Sentence 為 84.7，這些全都來自其自家評估。這些是語音翻譯基準，因此不能與上述 BLEU 數值相比，而且沒有第三方確認。唯一值得注意的內部訊號是，該模型在 CoVoST2 上以 6.6 分之差輸給 Qwen3.8-LiveTranslate，卻在開源系統中贏得其餘三欄——這提醒我們，單一數字本會掩蓋一項真實弱點。

成本與部署，並排對照

• 參數 — Hy-SimulMT-30B-A3B：總計 30.4B，約 3B 啟用參數，稀疏 MoE；Helsinki-NLP OPUS-MT：每個檢查點約 70–80M，稠密。

• {{1}}記憶體佔用{{/1}} — Hy-SimulMT：在計入 KV 快取之前，BF16 權重大約 61 GB，因此 80 GB 加速器是實務上的最低需求；FP8 版本已發布。OPUS-MT：每個檢查點約 300 MB，可在 CPU 上執行。

• 延遲模型 — Hy-SimulMT：串流，在長篇音訊上約 3 秒 StreamLAAL。OPUS-MT：一次一句；串流需要一個 ASR 和你自行建立的切分策略。

• 語言 — Hy-SimulMT：中文與英文有語音文件記錄，另有 36 種在中繼資料中標註。OPUS-MT：約一百種語言，涵蓋超過一千個方向性檢查點。

• 授權 — Hy-SimulMT：Tencent 的權重與程式碼採用 Apache-2.0，第三方元件則依其各自條款。OPUS-MT：依各檢查點而異，並不統一——中譯英模型為 CC-BY-4.0，英譯中模型為 Apache-2.0，英譯德為 CC-BY-4.0。出貨前請檢查特定的模型卡。

• 託管 API — Hy-SimulMT：尚未發布。OPUS-MT：無；僅提供權重。

最後那兩個模型對採購至關重要。這兩個模型都不在 OrcaRouter 的型錄中，我們也不託管其中任何一個——你可以自行託管權重，或使用供應商自己的管道。路由真正發揮價值的地方，在於流程的其他環節：圍繞翻譯階段運作的逐字稿摘要器、術語表檢查器、後編輯器和聊天助理，都是普通的模型呼叫，而讓它們透過 單一 API 涵蓋 200+ 模型，以0% 加成套用供應商牌價，可避免與每家供應商分別簽約。翻譯很少是會議產品唯一要做的事。

哪一個屬於你的技術棧？

當輸入已經是文字、翻譯方向固定、量大且預算為零時，選擇 OPUS-MT。法律文件流程、字幕檔、電子商務型錄與離線瀏覽器翻譯，仍更適合由 300 MB 的專用模型來處理，而非 300 億參數模型；而每個檢查點的授權是你唯一需要稽核的東西。當輸入是音訊且聽眾正在等待時，選擇 Hy-SimulMT：現場會議、講座、訪談、廣播口譯，以及任何三秒延遲與保留原聲值得付出加速器和 TTS 服務的場合。

要避免的錯誤，是把這件事當成品質競賽。OPUS-MT 在文字翻譯上並沒有輸給 Hy-SimulMT；它輸在一個自己從未被打造來處理的任務上。而 Hy-SimulMT 並不是用一個聰明的模型取代一千個精心打造的雙語模型——它取代的是一條你原本得自己組裝、調校和除錯的串接流程。那是不同的採購，而且只有其中一種是裝在資料夾裡交付的。