Ming-3.0-asr-tiny 對比 Granite Speech 5.0 470M TurboCTC：參數量多 19 倍，吞吐量卻毫無優勢

把Ming-3.0-asr-tiny與Granite Speech 5.0 470M TurboCTC放在同一頁上，第一個跳出來的數字是參數比例：88.7 億對 4.7 億，約十九比一。第二個是小模型才是為速度而打造、而且幅度極大的一方，第三個則是這並不矛盾。Granite Speech 5.0 470M TurboCTC 沒有解碼器要跑——它是輸出字元就停止的編碼器。Ming-3.0-asr-tiny 則有一個 24 層混合專家解碼器，一次寫一個 token，而且可以事先告知它接下來會說出哪些名字。一個是針對英語音訊的吞吐機器。另一個是針對中文音訊的上下文機器。IBM 於 2026 年 8 月 25 日發布 Granite Speech 5.0 470M TurboCTC，附上一篇部落格文章、一份技術報告與一筆 Open ASR 排行榜條目；inclusionAI 於 2026 年 10 月 14 日把 Ming-3.0-asr-tiny 的權重放上 Hugging Face，完全沒有任何公告。本文使用的每一項 Granite 數據都來自Granite Speech 5.0 470M TurboCTC 模型卡，其中包含 Open ASR 表格、雜訊掃描與單一語言聲明。像這類發布背後的已記錄 AI 失敗與 AI 代理事件，都彙整在OrcaRouter AI Incident Archive中，每一條記錄都附有自己的來源、嚴重程度、信心等級與爭議標記。

兩個模型都不在 OrcaRouter 的目錄中，也沒有出現在彼此的評估裡，因此沒有廠商之間的直接對比可供引用。以下所有內容均取自各模型自身公布的配置與圖表，並已按此標註來源。

架構上的分岔，直白說明

Granite Speech 5.0 470M TurboCTC 是純編碼器模型，IBM 表示這是刻意與自身過去切割。先前的 Granite Speech 模型由聲學編碼器、投影器和搭載 LoRA 適配器的 Granite 語言模型組成——也就是說，它們是戴著麥克風的語言模型。5.0 世代完全捨棄語言模型，並在 16,384 單元的 BPE 頭上優化 CTC 目標。16 個 Conformer 區塊、1,024 維隱藏維度、八個注意力頭、涵蓋 128 幀的區塊注意力、第八個區塊的自條件化，以及寬度為 7 的卷積核。

次取樣正是帶來速度的部分。音訊以 log-mel 加上差值特徵的形式送達，每秒 100 幀、320 維。三個 2 倍縮減階段——先是將連續幀堆疊起來的 reshape，接著是前兩個 Conformer 區塊內部的步幅卷積——把輸出降到每秒 12.5 個 token。IBM 的部落格明確指出，這正是相較於其較早編碼器的改變：那些編碼器每秒輸出 50 個字元，也就是每秒钟音訊的輸出步數少了四倍，而且沒有自迴歸迴圈來逐一決定每個輸出。

Ming-3.0-asr-tiny 在每個這裡重要的面向上都反其道而行。它的解碼器是 24 層的混合專家模型，具有 128 個專家、每個 token 路由八個、一個共享專家與一個稠密第一層，並以三層 Kimi Delta Attention 與一層 Gated MLA 交替排列。它以自迴歸方式產生 token。它還搭載一個 32 層、1,280 維、Whisper 形狀的編碼器——也就是 Whisper large-v3 的形狀，而儲存庫隨附 modeling_whisper_encoder.py，以及另一個檔案中的 OpenAI MIT 聲明。Ming 保留了語言模型，並使它成為成本高昂的部分。

這些數字究竟從何而來

這一節決定了兩個模型的說法各自值得多少重視，而這兩個發布版本在性質上無法相提並論。

• Granite Speech 5.0 470M TurboCTC — 截至 2026 年 8 月 25 日，在 Open ASR 排行榜的公開英語短格式資料集上，整體 WER 為 5.00%，其中 LibriSpeech test-clean 為 1.93%，test-other 為 3.59%。其非商業性同系列模型得分為 4.85%。在單一 H200 上以批次推論執行時，吞吐量超過 12,600 RTFx。arXiv 上有技術報告，Hugging Face 也有部落格文章，且結果已提交至公開排行榜並列於其上。

• Ming-3.0-asr-tiny — 在中文公開資料集上平均 CER 為 3.55，在英文公開資料集上平均 WER 為 3.99，在十五個方言資料集上為 8.42，在五個內部領域上為 1.67，在上下文 ASR 彙總上為 4.36。這些全都以 PNG 圖像形式存在於模型卡上。儲存庫中沒有技術報告、沒有排行榜提交，也沒有評估腳本。

那篇部落格文章值得打開，理由和模型卡一樣：它是 Ming 沒有的線索。IBM 發表了一篇註明日期的文章、一份技術報告和一筆排行榜紀錄，而文章中的吞吐量主張可以對照它描述的批次配置來查核。

這種不對稱並不是在貶低 Ming 的數字；它說明的是你能查核什麼。任何人都能在一個下午內，用公開資料重新跑出 Granite 的 Open ASR 數據。若要重新跑出 Ming 的數據，則必須重建其測試集，其中包括五個內部領域，而其組成並未公開。

還有一個不對稱，而且方向正好相反：這兩個模型並未共用同一套評估集。Granite 的圖表僅涵蓋英語，範圍包括 LibriSpeech、AMI、Earnings-22、GigaSpeech、SPGISpeech、TED-LIUM 與 VoxPopuli。Ming 的英語平均則採用 LibriSpeech、Multilingual LibriSpeech、FLEURS English、Common Voice 15 English 與 VoxPopuli——五個中有兩個重疊，且彙總方式不同。想得知「哪一個在英語上更準確」的讀者，無法從任一供應商得到答案，因為兩邊都沒有提出這個問題。

「Speed」在這裡有兩種不同的意思。

IBM 的 12,600 RTFx 是批次處理的吞吐量數字：音訊以批次方式送進 GPU，每運算一秒可處理超過三個半小時的語音。這個數字適合用來轉錄館藏檔案，但對即時麥克風而言幾乎毫無意義。IBM 確實有推出串流功能——瀏覽器中的 WebGPU 示範、分塊注意力（chunkwise attention），以及針對 Apple Silicon 的 MLX 路徑——但這個指標性數字描述的是批次處理的情況。

Ming 完全沒有公布任何 RTFx。它公布的是規模：17.7 GB 的 BF16 權重，以及一個擁有 128 個專家的自迴歸解碼器。逐 token 的迴圈就是成本模型。每多一秒音訊，就意味著更多解碼步數，而每一個解碼步驟都會涉及橫跨 128 個專家的路由決策。這正是為什麼小 19 倍的純編碼器模型才是那個能提出吞吐量宣稱的模型，而這件事不需要基準測試就已經成立。

實務上的結果是，兩者並非在爭奪同一個部署目標。Granite Speech 5.0 470M TurboCTC 的設計是能跑在筆記型電腦、手機上，或由單張 H200 消化整個 Podcast 檔案庫。Ming-3.0-asr-tiny 則需要 CUDA GPU、PyTorch 2.11.0、torchaudio 2.11.0、Transformers 5.12.1、fla-core 0.5.2 和 trust_remote_code=True，而且如果你想把它當服務提供，還需要一個鎖定在特定 commit 的獨立 SGLang 轉接器。其中一者是一份可以直接放進產品的依賴清單。

Granite 為了達到目標而放棄的能力

僅編碼器設計換來速度與體積優勢，而 IBM 對其代價直言不諱。其部落格指出，5.0 模型捨棄了搭載 LM 的版本曾具備的能力，並點名語音翻譯與關鍵字偏置。第二項才是有趣之處，因為關鍵字偏置正是 Ming 稱為 Context ASR 並視為招牌功能的能力。

Ming 接受一份熱詞清單或前一輪對話，作為轉錄提示的一部分；供應商自己的範例很有啟發性：在一段音訊片段中，電影片名「同囚」在一般路徑下會輸出成「同球」，但一旦提供主題與熱詞清單，就會正確輸出。這張說明卡謹慎指出，熱詞只是提示而非保證，這是誠實的表述——偏置會改變機率，並不會強制輸出。

Granite Speech 5.0 470M TurboCTC 沒有對應方案。沒有提示詞、沒有上下文欄位，也沒有可提供的名稱清單，因為沒有可作為條件的語言模型。如果你的音訊中充滿產品名稱、藥品名稱或客戶資料庫中的姓氏，這個模型只有一個工具：它在訓練中學到的東西。IBM 對這類問題的解法是提供一個 Notebook，讓你在自己的資料上進行微調；這是另一種工作流程，成本也不同。

語言涵蓋範圍的運作方式也相同。Granite 是英文，並聲明為唯一支援的語言，在八張 H100 上以十天時間、約 60,000 小時的英文音訊訓練而成。Ming 支援中文和英文，包含十五個中文地區方言測試集，涵蓋粵語、閩南語和上海話，方言平均分為 8.42，其自家圖表將其排在所列出的每一個開放基準之前。

在它們之間做選擇

如果你的音訊是英文，而你的問題在於處理量——通話錄音、檔案庫、會議逐字稿，任何每小時成本比最後一點準確度更重要的情境——Granite Speech 5.0 470M TurboCTC 都是更合理的起點；而且它能以量化形式透過原生 C++ 執行環境運行、無需 Python，這項部署優勢，再多的中文方言涵蓋範圍也抵銷不了。

如果你的音訊是普通話或某種地方方言，或者準確度問題是你可以事先列出的專有名詞，那麼 Ming-3.0-asr-tiny 是兩者中唯一能處理這個問題的，而且它是用專為此打造的架構來做到，而不是外掛上去的微調。它也才推出五天、下載次數 35 次，這意味著你會是最早發現它如何出錯的人之一。

還有第三種值得特別提出的情況：你兩者都要，而且想知道在自己的流量上哪一個勝出。這正是 OrcaRouter 為之打造的路由問題。這兩個模型都沒有託管在那裡——Ming-3.0-asr-tiny 和 Granite Speech 5.0 470M TurboCTC 都是自託管的開放權重——但同一個端點既能作為你託管模型的前端，也能作為候選 ASR 路徑的前端，並具備自動容錯移轉，讓失敗的請求退回現行方案，而不是讓使用者看到；而且一組金鑰就能通用於 200 多個模型，因此比較時不需要再簽第二份合約。

兩家廠商都沒讓你看見的事

兩個模型都尚未經任何獨立第三方評分。至少 Granite 的數據位於其他團隊也會提交的公開排行榜上，這意味著這些數據可以被討論、質疑；Ming 的數據則存在於四張 PNG 裡，而這些 PNG 在發布當天下午還在校訂中。兩者的模型卡都未記載字詞級時間戳記或語者分離，因此任何需要時間資訊的流程都不適用於兩者——Granite 的模型卡描述的是純轉錄輸出，而 Ming 的使用說明則明確指出，輸出是轉錄文字，不含字詞級時間戳記或語者分離。

真正能一勞永逸解決這個問題的比較，兩家廠商都做不出來。它需要同一份語料、同一組語言對、同一套評分腳本，以及兩個模型跑在同一張 GPU 上。在有人發表這樣的結果之前，唯一站得住腳的說法，就是這些架構本身已經道出的那句話：一個大上十九倍的自迴歸混合專家模型，在吞吐量上並不是在跟一個純編碼器的 CTC 模型競爭；而一個純編碼器的 CTC 模型，也沒辦法事先被告知該期待哪些詞。