Hy-SimulMT 與 Hy-SimulMT-30B-A3B：一個名稱、六個檔案、兩種輸出

輸入 Hy-SimulMT 到 Hugging Face，你不會找到叫這個名稱的儲存庫。你會找到六個，而且每一個都叫 Hy-SimulMT-30B-A3B，後面再接一個後綴。這就是整個比較，一句話就講完了。Hy-SimulMT 是騰訊混元在 2026 年 10 月 26 日公告中使用的名稱——即時中英口譯器，媒體報導形容它比講者慢約三秒。Hy-SimulMT-30B-A3B 則是你實際能下載的成品上的名稱。短名稱之下沒有更小的兄弟型號，沒有稠密變體，也沒有躲在背後的純「base」模型。短名稱是一個專案；長名稱是六個檔案組成的一個系列。接下來要談的，是比較頁面通常會藏起來的決定：這六個之中該執行哪一個，以及為什麼答案會因字幕疊加和只需要音訊輸出的會議串流而不同。

騰訊發布了什麼，以及它決定如何稱呼它

Tencent 自家的儲存庫將 Hy-SimulMT 視為專案名稱：「由 Tencent Hunyuan 開發的即時同聲傳譯模型」。模型卡將其歸在同一簡短標籤下。該集合標題為「Hy 同聲傳譯模型」。在該資料中，完全沒有定義家族及其成員的層級——沒有 Hy-SimulMT-Small，沒有 Hy-SimulMT-Mini，也沒有供沒有 80 GB 加速卡的人使用的稠密檢查點。每個已發布的權重都是相同的 30B 級混合專家架構。

所以，這個系列中的六個項目在任何有意義的層面上都不是六個模型。它們是同一個模型的六種包裝：

• Hy-SimulMT-30B-A3B — 僅翻譯輸出，全精度，safetensors。

• Hy-SimulMT-30B-A3B-Interleave — 來源轉錄稿加翻譯，全精度，safetensors。

• Hy-SimulMT-30B-A3B-FP8 與 Hy-SimulMT-30B-A3B-Interleave-FP8 — 同樣的兩種輸出形態，採用八位元浮點版本，專為單一 GPU 服務而設計。

• Hy-SimulMT-30B-A3B-GGUF與Hy-SimulMT-30B-A3B-Interleave-GGUF——同樣的兩種輸出形式，已為 llama.cpp 量化，提供 Q4_K_M 與 Q8_0。

底層架構是一個 304 億參數的稀疏模型，每個 token 約有 30 億參數啟用：48 層、128 個專家，每個 token 有 8 個專家被路由、1 個共享；還有一個 24 層音訊編碼器，以 30 秒視窗接收 16 kHz 音訊。值得注意的部分是那個編碼器設計。此模型設計成在音訊仍在傳入時就處理音訊，而不是接收已完成的檔案——這就是為什麼延遲主張與基準測試主張衡量的是不同事物，也是為什麼兩者都無法告訴你六個檔案中哪一個產生了這個數字。

授權條款是 Apache-2.0，且不設任何閘門，這是本次發布中最有力的一項事實。沒有申請表單、沒有可接受使用條款的審核、也沒有非商業條款。商業使用、修改與再散布皆被允許，而騰訊也在推論伺服器之外一併發布了訓練工具包，讓持續訓練成為一項被認可的預期用途，而非缺乏支援的用法。

真正重要的選擇在於輸出形態

在兩個全精度檢查點之間，差異不在於品質，而在於模型被允許輸出什麼。Base 檢查點只輸出譯文，別無其他。Interleave 檢查點則會先輸出辨識出的來源文字，再輸出譯文，並像音訊串流那樣交錯呈現。

那聽起來像是表面功夫，直到你看到這些系統實際部署在哪裡。驅動文字轉語音的即時會議資料流需要基礎檢查點：轉錄稿是累贅，會消耗輸出 token、增加每個區塊的延遲，並把來源語言洩漏到唯一消費者是人聲的管線中。字幕覆蓋層、合規擷取、雙語轉錄稿，或任何人必須核對翻譯與實際發言是否相符的工作流程，則需要 Interleave 檢查點，因為替代做法是在翻譯器旁另跑一個語音辨識器，並指望兩者以相同方式切分音訊。它們不會。

Tencent 自家的一鍵部署範例預設採用 Interleave 變體：

• bash deploy.sh --install-server --model tencent/Hy-SimulMT-30B-A3B-Interleave

對示範來說，這是合理的預設做法，因為顯示來源文字能證明系統正在聆聽。對純語音產品而言，這卻是錯誤的預設，而這正是大多數關於此次發布的報導所忽略的細節。如果你正以 token 成本或端到端延遲來評估這個模型，那麼你載入哪個檢查點，所測量的其實就是不同的系統。

Interleave 有一項二階成本，卡片暗示了這一點，卻沒有量化。串流轉錄內容是可變的。早期輸出可能會隨著更多音訊到來而被修訂，因此顯示部分文字的用戶端必須設計成能接受更正，而不是只能附加行。AlphaSignal 對此次發布的報導直接指出了這一點，而這正是那種會把兩天原型變成三週原型的整合細節。

這些基準測試並沒有說明他們測量的是哪一種變體。

騰訊發布了四項短格式分數與一項長格式延遲數據，而每一列都標示為「Hy-SimulMT」——不是 Hy-SimulMT-30B-A3B，更不用說 base 與 Interleave 的對比。這正是此次發布中誠實的缺口，而它比其中任何單一數字都更重要。

• FLEURS — 90.3。Gemini3.5-LiveTranslate 得分 92.4，因此這並非該類別的勝利。

• CoVoST2 — 75.5，落後於 82.1 的 Qwen3.8-LiveTranslate。這是表格中最明顯的一項落敗，也是新聞標題報導往往略過不提的一項。

• ACL6060 — 81.2。Gemini3.5-LiveTranslate 得分為 82.6。

• RealSI-Sentence — 84.7，比較組中最高。

• RealSI 長文本延遲 — 約三秒的 StreamLAAL，被描述為比較系統中最低者。

所有這些都是由廠商自行執行的。沒有任何一項經過獨立重現，而且模型卡明確指出，StreamLAAL 與首次語音輸出時間並非同一種量測。示範影片是離線重播，因此其播放計時也不是即時延遲讀數。應將這張表視為打造該模型之實驗室所提出的一組主張：這些主張是在其自行選擇的測試框架上取得，且未指明所用變體。

那最後一項遺漏，任何手上有硬體的人都能在一個下午內修正：把兩個檢查點跑在同一段音訊上，並公布差異。在有人這麼做之前，合理的假設是：已公布的數字描述的是純翻譯路徑，因為那是較乾淨的測量——Interleave 變體必須輸出更多 token，而在串流解碼器中，更多 token 就代表更高延遲。但這是假設，不是揭露。

格式是第三個決定，而 GGUF 這條路有個陷阱

全精度檢查點在 BF16 下約為 61 GB。這使得舒適部署的實際門檻落在 80 GB 加速卡上，如果你打算以原樣提供模型服務，這就是該編列的預算數字。FP8 版本的存在，正是為了把這項需求降到單張較小的卡，而 Tencent 也正是這樣定位它。

GGUF 路線看起來仍然更划算，而且檔案大小也很具體。Interleave GGUF 儲存庫列出 Q4_K_M 為 19.7 GB、Q8_0 為 33.3 GB。對一個 300 億參數模型來說，19.7 GB 的量化版本正是「需要資料中心等級顯示卡」與「能裝進工作站」之間的差別，而這也會是大多數人最先嘗試的版本。

問題在於，llama.cpp 對這個架構的支援尚未合併進上游儲存庫。Tencent 提供一個橋接層，它要求一個已在執行且具備音訊能力的 llama.cpp 伺服器，並帶有 MODEL_TYPE 開關——target_only 用於僅翻譯的檢查點，source_target 用於交錯版本——而文件建議等待官方版本釋出。如今執行量化版本，意味著要在一個還不認識這個模型的 llama.cpp 版本上，執行廠商提供的橋接層。用於評估，這是合理的做法。但對產品而言，這是脆弱的基礎，而其失效模式是：這個相依性無法脫離廠商的修補獨立升級。

就 vLLM 路徑而言，需求是 0.31 或更新版本，並具備 HYV3ForCausalLM 支援，外加 simulst 套件。多 GPU 部署可透過張量平行來支援。一鍵安裝程式會在 8080 埠啟動網頁與 API 服務，並在 8800 埠啟動模型伺服器，而且它會在隔離環境中執行——這表示若你把它指向既有的技術堆疊，它可能會重新安裝 SimulInfer 或變更相依套件版本。騰訊正是基於這個理由，才記錄了一步一步的操作路徑。

提供服務所需的條件，以及此版本不包含的內容

語音輸出與聲音複製並非檢查點本身的屬性。模型產生的是文字。要把這些文字轉換成以說話者聲音呈現的語音，需要另行設定 TTS 服務，而這句話的每一個部分都伴隨成本：多一個要運行的服務、延遲預算中多一次網路躍點、多一份要審閱的供應商條款，以及麥克風與聽者之間多一個故障點。模型卡對此說得很清楚，而這是示範與可部署口譯系統之間最大的單一落差。

此外，也沒有託管 API，也沒有公開定價。騰訊的消費端產品是 Hy Translate 應用程式，在 Android 和 iOS 上提供免費方案——這是聆聽模型效果最便宜的方式，但作為生產環境依賴則毫無用處。其餘一切都需要自行託管，這意味著成本在於加速器、維運時間和 TTS 帳單，而不是可以放進試算表的每 token 費率。

語言涵蓋範圍也值得同等審視。說明文字記載了中英雙向。Hugging Face 的中繼資料將該檢查點標記為 36 種語言。其餘 34 種語言並未公布清單，而該儲存庫自身的範例全都是 en-zh 或 zh-en。在 Tencent 另有說明之前，應將此標籤視為沿用而來的詮釋資料，且不要僅憑一個標籤就規劃 36 種語言的推出。

需要第二個來源佐證的說法

與人類口譯員的比較是本次發佈中最常被引用、卻最缺乏支持的說法。騰訊報告稱，其品質「與專業人類同步口譯員相當，且往往回應更快」，依據是 18 段新錄製、每段約六分鐘的錄音，涵蓋十個領域，並由六名經驗豐富的口譯員評估——其中三名持有 CATTI 一級證書，三名持有二級證書。每個級別均採用三名口譯員中的最高分。

最後那個細節扮演了關鍵角色。拿三次執行中的最佳表現來對比單次模型執行，是一種相當寬鬆的比較設計，而且這份卡片並未公布信賴區間或各領域的細分資料。它也尚未公布語音複製的客觀說話者相似度分數，而這正是最可能決定部署在現場人員眼中是否可接受的功能。卡片自身的限制——該發現受其樣本、參與者和設定所限，並非全面評估——才是正確的解讀。醫療、法律與吵雜的對話音訊，正是口譯員比較會需要各領域數字的地方，而這些數字恰恰缺失。

只要涉及問責、專家審查或高風險決策，專業口譯員仍然是正確的選擇。這是 Tencent 的表述，而非批評者的說法；這一點值得重申，因為這份新聞稿的標題版本並未這麼做。

如果你自行架設它，就在它後面放點東西

這兩個檢查點都不在 OrcaRouter 的目錄中，所以我們不是通往其中任一個的路由，而本文也不會假裝不是如此。這並不代表路由器與自架口譯器無關——而是把它移到邊緣。即時翻譯路徑是一條長鏈：音訊擷取、模型伺服器、可選的 TTS 服務，以及用戶端。每個環節都可能停滯，而會議中的停滯比翻譯稍差還更糟。將託管的文字模型放在同一個端點之後，作為逐字稿路徑的備援——而非音訊路徑——意味著模型伺服器掛掉時，會降級成可讀的逐字稿，而不是一片沉默。

OrcaRouter 是一個 API，站在 200 多個託管模型前方，且零加成，供應商定價原樣傳遞、不額外加價，而路由 DSL 正是表達備援規則的方式，無需第二次整合。自動容錯移轉才是這裡的重點：規則是因上游故障而觸發，而不是等人發現字幕停了。

那麼，是哪個檔案？

一旦你了解這些名稱指的是什麼，這種對比式框架就會消解；剩下的是一個包裝決策，而它有三個誠實的答案。

如果你正在打造語音產品——會議口譯、客服中心疊加層，或任何輸出為音訊的應用——請採用Hy-SimulMT-30B-A3B；若受限於單張 80 GB 顯示卡，則採用其 FP8 版本。你不需要逐字稿，也不想付費生成它，而基礎檢查點是延遲表現更乾淨的路徑。

如果輸出會由人工閱讀，請採用Hy-SimulMT-30B-A3B-Interleave。字幕、雙語會議紀錄、合規擷取與審閱工作流程都需要來源文字，而在翻譯器旁另行執行獨立的辨識器，正是會讓你得到兩份對句子在哪裡結束意見不一致的逐字稿的原因。

如果你是在評估而非部署，請選用Hy-SimulMT-30B-A3B-Interleave-GGUF 的 Q4_K_M 版本，接受 19.7 GB 的檔案與尚未合併的 llama.cpp 相依性，並把它當成在你已擁有的硬體上聆聽這個模型的一種方式。只有在你認定品質值得這張顯示卡之後，才升級到 FP8 vLLM 路徑。

未解的關鍵問題不是哪個檔案比較好，而是已公布的分數是否描述了你所選的那個檔案。Tencent 有硬體能在一天內回答這個問題；在它做到之前，任何引用 90.3 或 84.7 的人，都應該說明他們認為這是六個檢查點中的哪一個所產生的。