Grok Voice Transcribe 2.0 對比 Granite Speech 5.0 470M TurboCTC：12,600× 即時速度遇上半秒

Granite Speech 5.0 470M TurboCTC 在單張 H200 上每秒可轉錄約 3.5 小時的音訊，而 Grok Voice Transcribe 2.0 則在你停止說話後 0.49 秒回傳第一份部分轉錄結果。這兩個數字在比較貼文中被並列擺在一起，彷彿它們是同一種量測，但它們完全不是同一種量測——一個是未附帶延遲的批次資料中心吞吐量數據，另一個則是某個模型的延遲數據，而該模型的吞吐量從未有人公布。IBM 於 2026 年 8 月 25 日以 Apache 2.0 釋出 Granite Speech 5.0 470M TurboCTC，完全捨棄語言模型解碼器，並以單一非自迴歸 CTC 前向傳遞來解碼。SpaceXAI 於 2026 年 9 月 18 日推出 Grok Voice Transcribe 2.0，作為託管 API，批次每音訊小時 0.10 美元，串流每小時 0.20 美元。兩者都是出色的轉錄模型，各自解決同一個問題的相反一半；一旦你不再直接比較這些數字，要在兩者之間做選擇就會容易得多。

12,600 倍即時，以及修飾它的那些詞語

Granite 的數字是在單張 NVIDIA H200 上以批次推論測得的 12,600 RTFx——這是 IBM 的數字，於發布時公布，之後未曾被獨立重現。RTFx 是音訊時長與處理時間的比值，因此 12,600 意味著每實際經過一秒約可處理 3.5 小時的音訊。IBM 自己的說法是，這比先前的 Granite Speech 版本吞吐量高出 20 倍以上，而這才是這裡真正重要的主張：加速來自減少工作量，而非增加硬體。

它不是延遲數字。一項每秒能完成 3.5 小時音訊的批次化作業，仍可能需要很久才會回傳任一單一檔案的第一個 token，這取決於批次如何組成，以及你在它開始前餵給它多少音訊。IBM 完全沒有公布 TurboCTC 的任何延遲數據。在遠場排行榜上，這兩個檢查點是最快的兩個項目，但該處的吞吐量是在單張 NVIDIA L4 上測得的，而那是接近資料中心等級的加速器，並非手機。

這件事之所以重要，是因為該模型被明確定位於筆電、手機和邊緣裝置——這是 IBM 自己的說法——卻沒有人發表過其中任何一種裝置上的單流效能。在有人做到之前，請把「12,600×」視為一種關於你能多便宜地在租用 GPU 上處理回填工作的陳述——這是一項真正有價值且有充分證據的主張——而不是關於單一使用者多快能取回一句話的陳述。

IBM 移除了什麼，以及這讓你付出什麼代價

TurboCTC 是僅有編碼器的設計：一個以 CTC 訓練的 16 層 Conformer 聲學編碼器，以單次非自迴歸傳遞進行貪婪解碼，並具有 16,384 個單元的子詞輸出層。整個流程中沒有語言模型。速度正是源於此，能力上的削減也源於此，而且這些削減並不小。與較早的 Granite Speech 模型相比，TurboCTC 移除了語音翻譯、移除了關鍵詞偏置，且不隨附時間戳記或標點工具。

把這一點與受管模式按其定價所包含的內容對照來看，這筆交易的輪廓就變得具體了：

• 關鍵詞偏置 — Granite Speech 5.0 470M TurboCTC 不支援，而 Grok Voice Transcribe 2.0 每次請求最多支援 100 個關鍵詞

• 詞級時間戳記 — 未隨 TurboCTC 提供，相對地則隨信心分數一併附上

• 語音翻譯 — 曾見於較早期的 Granite Speech 模型，在此已移除，而非兩種情況皆未提供

• 語言涵蓋範圍 — 僅限英文 vs. 可自動偵測廣泛的多語言輸入集，並支援 25 種語言的格式設定

• 語者分離 — 由你自己解決的獨立問題，對比包含在請求價格中

• 聲道 — 每次處理一個串流，對比單次請求最多八個音訊聲道

• 文字正規化 — 無 vs 反向文字正規化，將口語日期、貨幣與電話號碼轉換為書寫形式

• 部署 — 你自行下載並執行的權重，對比 us-east-1 中的受管端點

把那份清單讀成兩種不同產品的描述，而不是一張評分表。移除語者分離、偏置與正規化，正是換來吞吐量的原因。把四萬筆通話錄音批次回填到搜尋索引，不需要時間戳記或發言輪次——它需要的是便宜，而且需要能完成——而對那項工作來說，缺少的功能並不是少了什麼，而是被刪去的負重。

對於任何即時（live）的東西，情況正好相反。如果你正在打造語音代理，關鍵詞清單就是你讓「Kubernetes」、「Granola」和客戶姓名正確拼寫的方式；而一個沒有偏誤機制的轉錄器每次都會把它們弄錯，除了微調之外別無修正方法，而微調是另一個專案、另一筆預算。光是少了這一項功能，就足以讓 TurboCTC 在某些工作負載中出局，而對其他工作負載則無關緊要——這正是為什麼模型比較不如工作負載比較來得有用。

無法乾淨地進行的準確度比較

IBM 回報，在 Open ASR Leaderboard 上，Apache 2.0 檢查點的總體詞錯誤率為 5.00%，非商業版本則為 4.85%，評測範圍為公開英語短音訊資料集。這些是批次推論的數字，而該排行榜的評測涵蓋 AMI、Earnings22 及長篇對話資料集，而且這些數字是廠商自行回報的——雖已跑過排行榜的工具，但尚未納入官方表格，該表格也包含私有測試集。模型卡上公布的分資料集細項值得一讀，因為平均值掩蓋了很多事：LS Clean 1.42%、LS Other 2.66%、SPGISpeech 3.18%、Voxpopuli-Cleaned-AA 4.88%、Earnings22-Cleaned-AA-chunked 6.69%、AMI-Cleaned 7.52%，以及 Gigaspeech-Cleaned 8.67%，平均正好是 5.00%。同一張模型卡也引用了在單一 H200 上測得的平均 RTFx 為 13,042.98——高於 IBM 發布文章中使用的 12,600，而這兩個數字都出自同一家公司、同一週、同一批硬體。

Grok Voice Transcribe 2.0 的最終轉錄稿數字 2.7% 並不是可資比較的測量結果。它來自 Artificial Analysis 的 AA-WER Streaming 排行榜，那是一項加權綜合指標，由 AA-AgentTalk 占 50%、VoxPopuli 占 25% 與 Earnings22 占 25% 組成——大約八小時、以 agent 加權的英語對話音訊，並透過串流介面進行測量。不同的資料集、不同的加權方式、不同的運作模式。把 2.7% 和 5.00% 並列，然後推論這個託管模型的準確度大約是兩倍，是這個比較中最常見的單一錯誤。

能誠實說出口的範圍更窄，但依然有用。兩個模型在各自受測的音訊上都表現強勁。Grok Voice Transcribe 2.0 在一個獨立運作的串流排行榜上領先，其他模型也在同一榜上受測，這使其排名可供查核，即使其確切數值無法直接套用。Granite Speech 5.0 470M TurboCTC 在標準開放 ASR 測試集上有總合 WER，另外還有一項遠場結果：非商業檢查點在準確率上排名第五，Apache 檢查點則排名第九——這些是在吵雜且具殘響的語音上測得，這是該組中最嚴苛的條件，也可說是兩個模型數據中最誠實的一項。

如果您的音訊是乾淨的英語朗讀語音，這兩者之間的準確率差距很可能比排行榜名次所暗示的還要小。如果音訊含有雜訊、帶有口音、屬於電話語音或非英語，那麼這兩個排行榜都無法告訴您太多，唯有您自己的測試集才是唯一能派上用場的工具。

自由重量對比每小時 $1.67

成本比較是這兩個模型真正容易區分的一個地方，而人們通常引用的數字在兩個方向上都錯了。

• 批次轉錄 — Grok Voice Transcribe 2.0 每音訊小時 $0.10，或每 1,000 分鐘約 $1.67，對比 Granite Speech 5.0 470M TurboCTC 無授權費用，另加 GPU 時間

• 串流 — 每音訊小時 $0.20，每 1,000 分鐘約 $3.33，相較於 IBM 未發布任何託管串流路徑

• 授權 — 不提供權重的商業 API，對比主要檢查點採用 Apache 2.0，以及更準確的非商業版本採用 CC-BY-NC-SA-4.0

「Free」在第一行裡扮演了很重要的角色。一個 470M 的僅編碼器模型小到可以在一般硬體上執行——這正是這項設計的重點，也是 IBM 用八張 H100 在十天內訓練它，並以 `transformers>=5.16.0` 為目標推出、附帶 WebGPU 示範的原因——但還是得有人為 GPU、服務堆疊、自動擴縮、重試與待命輪值買單。在用量小的情況下，託管價格通常比工程時間便宜。在大量且穩定的用量下，租用硬體的路線會勝出，而交叉點取決於你的使用率，而不是你的音訊量：你讓它持續忙碌的 GPU，每小時算起來很便宜；而為了尖峰流量讓它保持預熱的 GPU，則不然。

在任何人據此規劃架構之前，有一個授權細節值得特別指出。兩個檢查點中較準確的那個、也就是 WER 為 4.85% 的那個，是採用 CC-BY-NC-SA-4.0 授權的非商業檢查點。Apache 2.0 檢查點則是 5.00% 的那個，而它才是你可以搭載於產品中出貨的版本。這是以 0.15 個百分點的準確度差距，換取得以使用該模型的權利，而這也意味著：任何引用「Granite Speech 5.0」的 4.85%、隨後又討論商業部署的比較，引用的都是錯誤的檢查點。

決策規則

有三個問題，比任何基準測試表都更快地把這兩個模型區分開來。

轉錄稿是在講者還在說話時即時取用的嗎？如果是，TurboCTC 就不是候選方案——不是因為它慢，而是因為它沒有串流介面，也沒有部分輸出；而部分轉錄稿與快速批次解碼是截然不同的架構承諾。如果否，吞吐量優勢就成為全盤關鍵，而 IBM 的模型在每處理一小時音訊的成本上非常難以擊敗。

這項工作是否需要領域詞彙？如果需要，具備偏置功能的模型預設就會勝出，而 TurboCTC 缺少關鍵詞偏置功能，這不只是不方便，而是會讓它直接出局。如果不需要，你就是在受管端為一項你不會用到的功能付費。

音訊是在還不錯的硬體上取得的英語朗讀語音嗎？如果是，兩者都很強，選擇就取決於操作考量。如果否，這兩塊板子都無法提供有用資訊，只有你自己的評估才重要。

無論最終結果如何，作業層才是讓這個決定變得成本低廉的關鍵。OrcaRouter 把 200 多個模型放在單一 OpenAI 相容金鑰之後，並在供應商之間自動容錯移轉，因此單一區域的託管語音端點下午出包，不再會變成你的服務中斷；而供應商的定價則以 0% 加成原樣傳遞——這代表供應商調價或新的檢查點，當天就會在我們這邊上線。對於正確答案確實不明確的工作負載而言，這消除了選錯的代價：在單一端點後面用你自己的音訊對兩者做基準測試，留下勝出的那一個，並在下一代模型推出時更改模型字串。

簡短版：Granite Speech 5.0 470M TurboCTC 是「以低成本、在我們掌控的硬體上，轉錄我們錄過的一切」更好的答案，而 Grok Voice Transcribe 2.0 則是「即時、準確地轉錄，而且不必由我們運行服務堆疊」更好的答案。12,600× 的頭條數字和 0.49 秒的頭條數字兩者都是真的，而且兩者都不是關於另一方的證據。