Granite Speech 5.0 2B 與 Granite Speech 5.0 470M TurboCTC：以 0.45 個 WER 百分點換取 35 倍吞吐量

IBM 在相隔不到一天的時間內发布了兩個 Granite Speech 5.0 檢查點，而它們有趣的地方並不是其中一個比較大，而是Granite Speech 5.0 2B在 Open ASR Leaderboard 上以 570 RTFx 達到平均英文 WER 5.06%，而Granite Speech 5.0 470M TurboCTC則以 19,870 RTFx 達到 5.51%——吞吐量約為三十五倍，代價卻遠低於半個百分點的準確率。如果你以為參數量能換來等比例的回報，事實並非如此。它換來的是翻譯、關鍵詞偏置、語言 ID 控制，以及一個能遵循提示的語言模型。速度並不在這份清單上。像這次發布背後那些有文獻記載的 AI 失效與代理事件，都收錄在the OrcaRouter AI Incident Archive，其中每一筆條目都附有各自的來源、嚴重程度、信心等級與爭議標記。

這兩個數字都是 IBM 自家的數據，是在同一個排行榜上測得，且日期相差不到一週，這使它成為目前少見、相對乾淨的同系列比較之一——但同時你也仍應假設這是廠商自行執行的評測，而非經過稽核的評測。這兩個模型都沒有獨立重現，而且截至撰寫本文時，我找不到任何推論服務供應商有提供它們，包括我們自家的型錄。

同一週，兩則不同的發布故事

這兩個模型並不是大小不同的雙胞胎。它們的發布方式不同，建構方式也不同，而發布歷程解釋了為什麼它們的模型卡讀起來如此不同。

• Granite Speech 5.0 2B — 儲存庫於 2026 年 10 月 7 日建立，權重於當晚提交，模型卡公開編輯了兩週，發布日期標記為 10 月 20 日，公告部落格於 10 月 21 日。新模型，低調開場，響亮收尾。

• Granite Speech 5.0 470M TurboCTC — 於 2026 年 8 月 25 日首次推出，當時是僅支援英文的模型，並宣稱達到 12,600 RTFx。10 月 21 日的版本是一項更新，而非新模型：架構相同，但採用全新的 16,384 詞元多語言 BPE 輸出頭、新增六種語言，並原生支援標點符號與大小寫。

當你解讀這些數字時，這個差異很重要。2B 的 5.06% 是對新檢查點的全新評估。470M 的 5.51% 則是對八月公布的 5.78% 數值的改善，而 IBM 的部落格將其表述為「儘管新增六種語言，英文 WER 反而更好」，這正是正確的解讀方式——多語言更新並未犧牲英文準確度，反而有所提升。

兩種架構，一個後果

Granite Speech 5.0 2B 是一款語音語言模型。16 個區塊的 Conformer CTC 編碼器會饋入兩層視窗查詢 Transformer 投影器，該投影器會以 10× 降採樣至 10 Hz 的聲學嵌入，這些嵌入會進入 granite-4.0-1b-base 的中間檢查點，並使用 YaRN 擴展至 16k 位置。監督式微調是對投影器與語言模型共同套用 LoRA。生成採自迴歸方式：語言模型會逐個 token 寫出轉錄稿。

Granite Speech 5.0 470M TurboCTC 是一個編碼器。十六個 Conformer 區塊、CTC 目標、16,384 單元的多語言 BPE 分類頭、以 8 倍進行時間子取樣以將 100 Hz 幀降至 12.5 Hz、貪婪非自迴歸解碼。沒有投影器、沒有語言模型、沒有生成迴圈。輸出之所以帶有標點與大小寫，是因為模型被訓練成在 token 串流中輸出標點，而不是因為有第二個模型事後補上。

其結果正是整個比較的關鍵。一個會生成 token 的 2B 模型，其每個 token 的延遲有一個下限，無論怎麼做批次處理都無法完全消除；非自迴歸編碼器則在一次前向傳遞中輸出全部結果，因此吞吐量幾乎只隨批次大小擴展，其他因素影響甚微。這就是為什麼一個參數量只有四分之一的模型，最終快了三十五倍，而不是四倍。

這也是為什麼 470M 捨棄了 2B 擁有的某些東西。沒有提示詞可遵循，因此沒有語言 ID 指令、沒有關鍵字清單，也沒有翻譯——CTC 頭會將聲學特徵對應到 token，無法要求它把德語語音轉成英語文字。

計分板，以及每個數字的來源

• 參數 — Granite Speech 5.0 2B 為 2B；Granite Speech 5.0 470M TurboCTC 為 470M。

• 英文 WER、Open ASR 9 組平均 — 5.06% 對 5.51%。兩次 IBM 評估執行，2026 年 10 月 15–20 日。

• 吞吐量、RTFx — 570 對 19,870。相同的排行榜測試框架，相同的日期範圍。

• 吵雜與混響環境下的 WER，FFASR — 14.80%（在 42 個中排名第 4）對比 17.57%（排名第 12）。2B 模型的穩健性約高出 2.8 個百分點。

• 授權條款 — 兩者皆為 Apache 2.0。TurboCTC 另有一個採用 CC-BY-NC-SA-4.0 的 -NC 版本；發布前請先確認版本庫名稱。

• 語言 — 六種轉錄語言（英、法、德、西、葡、日）外加翻譯，對比七種（增加義大利文）但不提供翻譯。

• 控制功能 — 語言 ID 提示、關鍵字偏置至 2,000 個詞彙，以及 2B 上的語音翻譯；470M 則無。

• 訓練 — 2B 模型：在 8 張 H100 上花費 40 天、共 390,000 小時；470M 模型：在 8 張 H100 上花費 24 天、共 153,000 小時。

穩健性差距是大家常跳過的那一列。三十五倍的速度很吸睛，但在遠場吵雜音訊上 17.57% WER 對比 14.80%，是 19% 的相對錯誤差異，而吵雜音訊正是大多數實際部署會遇到的情況。如果你的音訊來自廚房裡的筆電，小型模型的速度優勢，正被花在你之後還得修正的逐字稿上。

470M 真正在準確度上勝出的唯一地方

日文。TurboCTC 卡片聲稱，在 CSJ eval1、CommonVoice-17 與 FLEURS 全部三個測試集上，其字元錯誤率都優於 2B 模型，並且在卡片文字中明確如此陳述，而不是把它藏在圖表裡。這些數字本身只出現在一張圖中，因此無法引用勝出的幅度，但這個方向是 IBM 對自家兩個模型的主張，這使其比跨廠商比較更具可信度。

這裡有一個合理的機制。2B 透過在字元輸出頭加入一組 92 個字元的片假名音素集，並在訓練中加入 16,500 小時帶關鍵詞偏置的日文 ASR 以及 9,600 小時的 Fineweb-2 TTS 來處理日文，但仍會將結果送入主要以歐洲語言文本訓練的語言模型。470M 則使用單一 16,384 單位的多語言 BPE 詞彙表，從一開始就包含日文，並在 ReazonSpeech 上花費 8,130 小時、在合成日文上花費 1,860 小時。如果你的產品是大規模日文轉錄，這是小型模型既更快又更好的唯一比較情境，而且在因尺寸而預設選用 2B 之前，值得直接測試。

成本，是計算出來的，而非報價得出的

IBM 並未公布這兩款模型的價格。兩者皆為 Apache 2.0 權重，因此執行它們的成本就是硬體的成本，而 RTFx 數值是你用來估算它的唯一槓桿。

以每天 1,000 小時的音訊工作量來說——這是中型客服中心檔案庫的規模。在 570 RTFx 下，2B 模型需要約 6,300 秒的 GPU 時間，略超過 1.7 GPU 小時。在 19,870 RTFx 下，470M 需要約 181 秒，也就是 0.05 GPU 小時。以每小時約 2–3 美元的 H100 來算，這相當於每天幾美元對上幾美分。兩者都是很小的數字，而這正是重點：在這個規模下，兩個模型都不昂貴，決策應該建立在準確度和能力上，而不是運算成本上。

運算需求在另一端就不同了。如果你要在筆電上即時轉錄單一音訊串流，或執行裝置端應用程式，2B 需要 GPU 才能跟上即時速度，而 470M 則還有餘裕——這就是為什麼 IBM 將 TurboCTC 定位於筆電、手機與邊緣裝置，並在文件中說明 mlx-audio 可用於 Apple Silicon。2B 也能在 llama.cpp 與 mlx-audio 上執行，但是在 Q8_0 下，並警告低位元量化在音訊超過約一分鐘後會失去準確度。

依決策實際發生的順序來選擇

不要從基準開始。先從任務的要求出發，因為其中三項差異是硬性要求，而不是取捨。

輸出是否需要與輸入使用不同的語言？那麼答案就是 2B，沒有比較的必要。470M 無法翻譯。光是這一項要求，就足以讓它在字幕處理流程、多語會議記錄，以及任何由非英語音訊建立的英語存檔中被淘汰。

轉錄稿是否需要包含特定詞彙？產品名稱、藥品名稱、工單編號、客戶的 SKU 清單——2B 最多可接受 2,000 個詞彙作為關鍵字清單，且正是為此以 23,600 小時的關鍵字偏置音訊進行訓練。470M 沒有提示介面。無法在小模型上進行詞彙表驅動的部署。

音訊乾淨嗎？如果是，0.45 分的英文差距很小，而 35 倍的速度優勢幾乎等於免費。如果不是——會議、客服中心、遠場麥克風——FFASR 2.8 分的差距就說明，小模型的錯誤代價會高於它速度所省下的成本。

是日文嗎？先測試 470M。IBM 說它在全部三個日文測試集上都勝出。

這是在裝置上執行嗎？ 470M 就是為此而設計的。2B 雖然可以在單一裝置上執行，但並非為此而設計。

老實說，總結是：這不是同一款產品的兩種規模。一個是帶有控制介面的轉錄加翻譯系統；另一個是非常快速、非常便宜、但沒有任何控制項的轉錄引擎。多數自認需要「更好的那一個」的團隊，其實需要先回答翻譯與詞彙表的問題，而這兩個答案就能決定一切。

兩者同時運行，但不押注於任何一方

對測試這個模型系列的團隊來說，合理的生產部署形態是兩者都部署，因為它們的失效模式正好相反。470M 以幾乎趨近於零的成本處理大量乾淨的轉錄；2B 則處理困難的音訊、非英語音訊，以及任何需要詞彙表的情況。一個能將每個傳入檔案分類——偵測語言、估計訊噪比、檢查是否附有詞彙表——並將其送往正確檢查點的路由器，大概只需五十行程式碼，就能降低尾端錯誤率，同時不必為大量資料支付 2B 的成本。

那個分類階段是一次小型模型呼叫，而這正是值得透過單一端點來執行、而不是嵌入第二個廠商 SDK 的部分：OrcaRouter 在 單一 OpenAI 相容 API 背後提供 200+ 個模型，價格為供應商定價且不加價，而其 路由 DSL 能把語言與品質的調度表達成一條規則，而不是應用程式碼。自動容錯移轉在像這次發布後的那一週最為重要：當時檢查點才兩天大、沒有任何東西經過獨立驗證，而嘗試它最安全的方式就是讓第二條路徑保持待命。這些都還無法幫你執行 Granite Speech 本身——目前我們兩個檢查點都沒有提供服務，所以語音模型仍維持自架，而路由層則從下游一步開始。

如果你只部署一個，就部署 2B。它是能完成 470M 所有工作的模型，速度仍比即時快三十五倍，而且在 IBM 公布的每項基準測試上，除了日語之外，準確率都更高。470M 是當成本帳單或延遲特性值得時才加入的專門模型——不是一開始就該採用的預設選擇。