Granite Speech 5.0 2B 對比 Whisper large-v3-turbo：IBM 在基準測試中勝出，Whisper 則在 99 種語言上勝出

就大多數人最先查看的兩項數字而言，Granite Speech 5.0 2B 勝過 Whisper large-v3-turbo，而且差距並不小。IBM 的模型在 Open ASR Leaderboard 的九個英語短音訊測試集上，以 570 RTFx 達到平均 5.06% 的詞錯誤率；OpenAI 的 turbo 檢查點在同一榜單上以 200 RTFx 平均達到 7.83%。在同一基準上更快且更準確，發布日期卻相差約兩年。如果你的音訊是英語，而且音訊乾淨，這就是全部的比較，你可以不用再讀下去。像這類發布背後有記錄的 AI 故障與代理事件，都收錄在OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

這個頁面仍然需要存在的理由，在於第三個數字：99。Whisper large-v3-turbo 涵蓋九十九種語言；Granite Speech 5.0 2B 則涵蓋六種語言進行轉錄，並可再翻譯成另外兩種語言。如果音訊是越南語，那麼在英文上 2.8 個百分點的 WER 優勢就毫無價值。所以真正的問題不是哪個模型更好——而是你的語言組合是否落在六種語言的框架內，以及若是如此，遷移成本是多少。

Whisper large-v3-turbo 究竟是什麼

這裡值得說得精確一點，因為這個名稱常被套用到不是它的東西上。Whisper large-v3-turbo 是 OpenAI 對 large-v3 的剪枝版本：編碼器不變，但解碼器只有 4 層，而不是 32 層。僅此一項改動就讓模型從 1,550M 參數降到 809M，吞吐量約提升至三倍，同時犧牲的準確率相對較小——這就是為何它在 2024 年 10 月發布後的幾個月內，成為整個生態系中預設的快速 ASR 檢查點。

該設計衍生出三項特性，而它們對這項比較都很重要：

• 它是一個恰好被剪枝的翻譯模型，因此繼承了 99 種語言的轉錄與語言識別能力——但 turbo 變體並未針對翻譯進行訓練。與 large-v3 不同，它會轉錄並識別語言；它不會把一種語言的語音呈現為另一種語言的文字。團隊經常在基於它建構之後才發現這一點。

• 解碼器是自迴歸的。它一次寫入 4 層的 token，因此其吞吐量停留在 200 RTFx，而非達到數千。Whisper 的速度來自移除層數，而非改變解碼範式。

• 它採用 MIT 授權，實務上比 Apache 2.0 更寬鬆，而這一點恰好是某些法務團隊在意的：不必分析專利授權條款，也不用隨附署名檔案。

Whisper 真正的優勢從來就不是基準測試，而是兩年累積下來的工具生態——faster-whisper、whisper.cpp、各家雲端的託管端點、量化配方、詞級時間戳函式庫，以及建構於其上的說話者分離堆疊。那個生態系是實實在在的轉換成本，而這番比較必須誠實地把它納入考量。

哪些落差是真實存在的，哪些又是測試框架造成的假象

5.06% 對 7.83% 的比較出自同一份排行榜，這讓它比大多數跨廠商數字更具正當性——但這並非在同條件下進行的測試，而且箇中細節有利也有弊。

• Granite 的數字來自 IBM 自己提交到排行榜的評估執行結果，公告部落格將其描述為「非官方，截至 2026 年 10 月 15 日」。模型卡則稱同樣結果自 10 月 20 日起為「官方」。你愛挑哪個形容詞都行；IBM 以外沒有人重現過它。

• Whisper 的數值是排行榜針對該檢查點所公布的結果，由排行榜自家的測試框架執行，與 IBM 的流程不同。

• 這兩個數字都是九個公開測試集上的平均值，其中大多為來自 LibriSpeech、Gigaspeech、SPGISpeech、Earnings-22、AMI 和 VoxPopuli 的英文朗讀語音。Whisper 在這個排行榜上的弱點已有充分記載，而且是結構性的：它是在 680,000 小時弱監督網路音訊上訓練而成，這換來了廣度，代價則是精確的格式處理。

• 在遠場與雜訊音訊上，這個排序依然成立。FFASR 評測板——將近場、高 SNR、中 SNR 與低 SNR 平均——顯示 whisper-large-v3 為 18.02%，Granite Speech 5.0 2B 為 14.80%。請注意，那是 large-v3，不是 turbo；turbo 在困難音訊上通常會比其母模型稍差，因為它的解碼器層數較少，較難從錯誤的聲學猜測中恢復。

因此，準確率差距在方向上可能是真實存在的，而且在公平較量下可能小於 2.8 個百分點。毋庸置疑的是它的來源：Whisper 的解碼器被要求用四層同時完成語言辨識、轉錄、標點、大小寫與時間戳對齊，而 Granite 的架構則把聲學工作（帶有字元與 BPE 頭的 CTC 編碼器）與文字生成（一個 1B 語言模型）分開。

語言框，量化

決策就是在這裡做出的，所以它值得的不只是條列中的一個數字。

• Granite Speech 5.0 2B 可轉錄英語、法語、德語、西班牙語、葡萄牙語和日語，並可在這六種語言與英語之間互譯，此外還能將英語翻譯成義大利語，以及將英語翻譯成華語。

• Whisper large-v3-turbo 能轉錄九十九種語言，並辨識出它聽到的是哪一種語言。它不會進行翻譯。

• Granite 的七語言手足模型 Granite Speech 5.0 470M TurboCTC，在轉錄語言陣容中加入了義大利文——因此這個系列涵蓋七種歐洲語言與日語，而非六種。

九十九對七就是 Whisper 的整個論據，而且這是有力的論據。但實際涵蓋範圍比數量更重要。如果你的音訊是英語、法語、德語、西班牙語、葡萄牙語、日語和義大利語，Granite 都能涵蓋。如果你需要印地語、阿拉伯語、韓語、土耳其語、波蘭語、越南語、印尼語、荷蘭語、瑞典語，或其他九十幾種語言中的任何一種，Whisper 是這兩者中唯一可行的——而英文上再大的 WER 優勢也改變不了這一點。

中間這種情況，才是大多數團隊實際所處的狀態：一個以英文為主的產品，帶著一條很長的語言長尾，而這些語言只佔百分之幾的流量。兩個模型、每個層級各一個，是正常且正確的答案——而且它比聽起來更便宜，因為長尾正是流量低的地方。

長音訊、時間戳，以及規模化時會出問題的種種

Whisper 的部署歷程已在許多方面臻於成熟，而這些並未反映在任何基準測試上。詞級時間戳記、語音活動偵測、說話者分離、搭配分塊解碼的串流——這些全都存在，全都經過實戰驗證，而且其中許多都假設了 Whisper 的 30 秒視窗及其時間戳記 token。

Granite Speech 5.0 2B 則採取不同的形態。IBM 建議每段長度最多約兩分鐘，較長的錄音則以 VAD 切分；語言模型會在 16k YaRN 擴展的上下文中看到 10 Hz 的嵌入向量。基礎 2B 檢查點上並沒有詞級時間戳頭——4.1 世代曾推出獨立的「-plus」變體，用於說話者歸屬 ASR 與詞級時間戳，但目前尚無對應的 5.0 變體。

如果你正在製作字幕、帶有講者標籤的會議逐字稿，或任何需要跳到特定語句的功能，這確實是個明顯的缺口。5.0 部落格確實有描述時間戳記的改善，但那些改善屬於更新後的 granite-speech-4.1-2b-plus，而不是 5.0 2B。

• 需要字詞層級的時間戳記——目前可用 Whisper large-v3-turbo；若你想要 Granite 系列，且能接受較舊的聲學模型，則可選用 Granite 4.1-2b-plus。

• 需要說話者歸屬——答案相同；5.0 2B 做不到。

• 需要在超過幾分鐘後仍維持長篇的準確度——Granite 兩分鐘分段的指引是一項實際限制，而 Whisper 以 30 秒為單位切塊、並以先前文字作為條件的做法，也有其眾所皆知的失效模式（在靜音處出現重複迴圈）。兩者都沒有明顯較好；兩者都需要在前面加上 VAD。

Granite 擁有而 Whisper turbo 沒有的兩項功能

關鍵詞偏置。Granite Speech 5.0 2B 在每個提示中可接受最多 2,000 個詞彙的關鍵詞清單，並且在涵蓋歐洲與日語語系的 23,600 小時關鍵詞偏置音訊上接受訓練。Whisper 沒有對應的介面——最接近的做法是一段提示字串，用來微調風格與詞彙，但其背後沒有任何訓練。對於需要轉錄產品名稱、藥品名稱、工單編號或客戶自有詞彙表的部署場景而言，這是兩個模型之間最有用的一項差異，而且它不會反映在任何 WER 平均值中。

語言 ID 提示。你可以告訴 Granite 音訊使用的是哪種語言，並指示它進行轉錄而非翻譯。Whisper 會自動偵測語言，而在 turbo 版本中僅進行轉錄。對於混合語言的語料庫，若你已從中繼資料得知語言，強制指定語言便能消除一整類錯誤——Whisper 偶爾會誤判短音訊的語言，然後自信地以錯誤的語言進行轉錄。

真正可行的遷移步驟

如果語言問題釐清後，轉換起來就沒有生態系差距所暗示的那麼痛苦，因為大多數以 Whisper 為基礎的管線早已具備你所需要的接縫。

1. 保留你的 VAD。兩個模型要的都是音訊片段，而不是整個檔案。你用來為 Whisper 切分音訊的方式，同樣適用於 Granite，只是每個片段最長可達兩分鐘，而非三十秒。

2. 替換解碼呼叫，而不是替換底層管線。Granite 可透過 transformers>=4.52.1 中的 AutoModelForSpeechSeq2Seq 與 AutoProcessor 載入，或透過 vLLM、以 Q8_0 執行的 llama.cpp，或在 Apple Silicon 上透過 mlx-audio 載入。如果你的服務是透過外部程式呼叫 faster-whisper，那只是把一個本機模型呼叫換成另一個而已。

3. 改寫提示詞。Granite 是指令驅動的，而提示詞會選擇模式：原始逐字稿、加上標點的逐字稿、關鍵字偏置、鎖定語言 ID。這是團隊常跳過的步驟，然後他們就得出模型較差的結論，因為他們餵給它的是 Whisper 的預設行為。

4. 要用你自己的音訊重新建立 WER 基準，而不是用 LibriSpeech。這不是形式上的要求。Whisper 在排行榜上的弱點在於格式處理與長音訊漂移；如果你的音訊是 30 秒的乾淨英文片段，而且下游步驟是會修正格式的語言模型，那麼你測到的差距可能接近零——或者，如果你的音訊帶有口音且是遠場收音，差距可能大於 2.8 分。

5. 保留後備路徑。Granite Speech 5.0 2B 的非英語涵蓋範圍是一道硬性邊界，而在多語言產品中，模型前端的語言偵測器並非可有可無。任何落在這七種語言之外的內容都會路由到 Whisper。

路由層在哪裡證明其價值

第五步是這次遷移中會演變成架構的部分。在兩個語音模型前面加一層語言與品質分派，再加上之後負責清理逐字稿的語言模型，等於每個檔案要呼叫模型三次；而三套各自獨立的供應商整合，正是讓簡單管線變成維護問題的原因。

OrcaRouter 是一個與 OpenAI 相容的端點，涵蓋 200 多個模型，價格為供應商定價，不額外加價，因此後處理階段——清理、摘要、欄位擷取——可以在不更動語音程式碼的情況下替換或進行 A/B 測試，而供應商中斷時會故障轉移，而不是讓工作失敗。路由 DSL 可以承載派送規則本身：偵測語言，將七種支援的語言送往自託管的 Granite 檢查點，其餘全部送往 Whisper，並將逐字稿交給任務所需的任一清理模型。最後這一跳是我們目前實際能提供的；Granite Speech 5.0 2B 和 Whisper large-v3-turbo 都不在我們的目錄中，因此語音模型仍留在你自己的硬體上，而路由從下游一步開始，仍能省去大部分的整合工作。

誰應該切換，誰不應該

若你的音訊是英文加上六種 Granite 語言、準確度比生態系熟悉度更重要、你需要關鍵詞偏置或強制指定語言，而且目前可以接受沒有字詞級時間戳記，那就改用這個。5.06% 對上 7.83% 是在關鍵方向上的實質差距，而 570 RTFx 對上 200 RTFx 意味著改用後很可能同時降低你的 GPU 支出。

請不要切換，若你需要以下任何一項：其他九十二種語言、詞級時間戳記、說話者歸屬或受管端點——截至本文撰寫時，Granite Speech 5.0 2B 尚未由任何推論供應商部署，目前自行託管是取得它的唯一途徑。Whisper large-v3-turbo 隨處可用，包括不允許你執行自家 GPU 的地方。

兩者都執行，如果你有長尾語言分佈。分派成本低廉，長尾依定義本就是低流量，而且這能消除 Whisper 僅存的唯一論據。