Nemotron 3.5 Transcribe 對比 Granite Speech 5.0 470M TurboCTC：參數量多 64 倍，速度慢 43 倍

這項比較中最有用的項目，是一個 279 MB 的檔案。那就是Granite Speech 5.0 470M TurboCTC 的 Q4_K_M 量化；它是 IBM 的僅含編碼器語音辨識器，能在筆記型電腦 CPU 上轉錄英文，無需 GPU、無需像樣的 Python 環境，也無需服務合約。Nemotron 3.5 Transcribe 是 NVIDIA 於 2026 年 10 月 28 日以開放權重發布的 300 億參數語音增強語言模型，需要資料中心等級的加速器，以及約六十 GB 的 BF16 權重。NVIDIA 的模型大上六十四倍，而依各廠商公布的吞吐量數據，每 GPU 秒大約慢四十三倍。它也是兩者中唯一能告訴你說話者是誰的模型。

這兩項事實都不是決定性的。它們描述的是兩台不同的機器，只是恰好被放在同一份排行榜上衡量；而整個問題在於，你的工作負載需要的是空間，還是只要文字。

非自迴歸 CTC 模型與生成式語音 LLM 的對比

Granite Speech 5.0 470M TurboCTC 由十六個 Conformer 區塊組成，並搭配一個 16,384 個 BPE 單元的輸出層；它以 CTC 目標進行訓練，並以貪婪方式解碼。它沒有語言模型、沒有投影器，也沒有生成迴圈：音訊輸入後，輸出的是幀同步的標籤序列，並從 100 Hz 降採樣至 12.5 Hz。這樣的設計正是它速度快、體積小的原因，也是它無法執行標籤集未涵蓋之任何功能的原因。它沒有提示的概念、沒有輸出風格、沒有翻譯目標，也沒有說話者欄位。

Nemotron 3.5 Transcribe 是相反的架構，而這項差異並不是世代差距。語音編碼器將輸入饋送至一個凍結的 Nemotron 3 Diarization 模型，其說話者活動訊號透過 Parallel Expert Encoder 注入編碼器，而混合 Mamba–Transformer 的專家混合解碼器則以文字產生轉錄稿，其 300 億個參數中約有 40 億個會針對每個 token 啟用。由於輸出是生成而非分類而來，因此可以對它下指令：逐字或書寫形式、預期實體清單、翻譯目標、具說話者歸屬的輸出，或針對音訊相關問題的口頭回答。

• 參數 — 總量約 30B，每個 token 約有 4B 活躍參數，相較之下純編碼器為 470M。

• 解碼 — 在 30B MoE 上進行自迴歸生成，對比貪婪式非自迴歸 CTC。

• 授權條款 — OpenMDW-1.1 與 Apache-2.0（兩者中較寬鬆者；IBM 另立的 -nc 同類條款為 CC-BY-NC-SA-4.0）。

• 佔用空間 — BF16、NVFP4 與 GGUF 版本約 60GB，相較之下，社群 GGUF 移植版在 Q4_K_M 下為 279MB。

語言 — 在 2026 年 10 月 21 日多語言更新後，40 種已轉錄、31 種已翻譯，相較於更新前的 7 種（英文、法文、德文、西班牙文、葡萄牙文、義大利文、日文）。

• 講者 — 最多 8 位、可標示身分、支援 13 種語言，相較之下則無；語者分離需要另用模型。

• 時間戳記 — 透過解碼後的 CTC 適配器取得詞級時間戳，對比完全不使用；CTC 峰值位置並非詞邊界。

• 串流 — 無；僅有錄製音訊，對比無。

準確度差距比規模差距小，而且平均值並不相符

IBM 針對多語言 TurboCTC 版本回報，在九個公開英語測試集上的平均詞錯誤率為 5.51%，比八月推出時的 5.78% 有所改善。NVIDIA 則在 Hugging Face Open ASR Leaderboard 上回報平均英語 WER 為 5.33%，並在其自家研究頁面上回報九個公開測試集的平均為 4.71%。這兩個數字都是廠商自行回報，而且這兩個平均值並非由相同的測試集混合而成：IBM 的九個測試集與 NVIDIA 在排行榜上採用八個測試集的登錄項目，在組成與正規化方式上都不同；而研究頁面上另行列出的九個測試集數字，又與其自家排行榜的登錄項目不同。不要把它們相減，並把差值稱為品質差距。可以站得住腳的說法比較狹窄——在公開英語短音檔排行榜上，這兩個數字彼此相差在零點二個百分點以內；對一個小 64 倍的模型來說，這是驚人的結果，也警示了排行榜平均值中有多大比例是 LibriSpeech 型態的乾淨朗讀語音。

詞錯誤率也掩蓋了真正區分兩者的關鍵。Granite 是分類器：它會輸出最可能的標籤序列，而在聲學特徵含糊不清之處，它會輸出某種看似合理的結果。Nemotron 則是由語言模型支撐來生成文字，這正是為什麼它的情境提示說法——在提示中提供實體清單時，於 ContextASR-Bench 上將命名實體錯誤降低至六分之一——得以成立。在一段充滿產品代碼的銷售通話逐字稿中，小模型沒有任何引入這種偏置的機制，而大模型則有。

吞吐量：19,870 RTFx，相較於 462

Nemotron 3.5 Transcribe 在 Hugging Face 排行榜上的條目顯示 RTFx 為 462.09——也就是說，在排行榜的測試框架下，該模型每消耗一秒運算時間，約可處理 462 秒的音訊。IBM 十月的更新則指出，TurboCTC 在單張 H200 上達到 19,870 RTFx，高於推出時約 12,600 的水準，這是經過單區塊圖重用的最佳化之後的結果。這是四十三倍的差距；而且與 WER 數字不同，這項數據至少是在兩款具競爭力的加速器上測得，而非來自兩組不同的測試混合集。

NVIDIA 自家標題則是另一種數字：在單張 RTX PRO 6000 Blackwell 上，使用 NVFP4 檢查點與 DFlash2 草稿模型，每秒可處理高達 2,238 秒的音訊。這個數字高於排行榜上的 462，因為兩者採用不同的測量方式——正如 NVIDIA 自己的 Hugging Face 貼文所述，那是在高併發下以 30 秒音訊片段測得，並啟用推測解碼，且所用的量化方式在當時仍被描述為即將推出。把這兩者放在一起看，誠實的結論是：Nemotron 的吞吐量會隨配置不同而相差一個數量級，而 TurboCTC 的吞吐量則是其架構本身的特性。沒有自迴歸迴路的模型，不可能像 30B MoE 那樣慢。

4.7 億參數能為你帶來什麼，是 300 億參數做不到的？

第一個答案是部署形態。279MB 的 GGUF 可在 CPU 上執行、在鄰近手機的邊緣裝置上執行、在桌面應用程式內執行，若有耐性，也可在 Raspberry Pi 等級的板子上執行。現在已有社群 GGUF 移植版，以及一個把此模型視為一級引擎的 C++ 執行階段系列。Nemotron 3.5 Transcribe 會在 vLLM 搭配 NeMo Speech 外掛或 SGLang-Omni 下，於 BF16 的 80GB 加速器或 NVFP4 的 Blackwell 顯示卡上執行。那些不是同一光譜上的兩個點；它們是不同的採購類別。

第二個是延遲下限。CTC 模型在一次前向傳遞中就回傳轉錄文字。生成式模型則一次只回傳一個 token，而它在短檔案上的實際耗時主要取決於解碼迴圈，而非音訊。對批次封存來說，這無關緊要。但對任何互動式用途——聽寫框、通話品質監控器，或必須跟得上拖曳時間軸的字幕工具——小模型是兩者之中唯一能在使用者察覺之前完成的那一個。

第三是授權清晰度。Apache-2.0 是法務部門已經核准的授權；OpenMDW-1.1 夠新，部分法務部門會想要審查。如果你的障礙是採購表單而非基準測試，IBM 的模型能更快通過。

300 億參數能帶來什麼，是 4.7 億參數辦不到的？

先從講者說起，而且這一點具有決定性。TurboCTC 完全沒有任何講者表徵。若要取得帶講者歸屬的轉錄稿，就得在它前面接上一個語者分段模型、加入合併步驟，並為合併預留誤差預算——這是標準的串接式流程。Nemotron 3.5 Transcribe 將一個凍結的語者分段模型併入編碼器，並直接輸出講者標籤，最多八個，涵蓋 13 種語言，並透過解碼後的 CTC 適配器提供帶講者歸屬的詞級時間資訊。NVIDIA 報告的語者分段錯誤率為 18.26%，是在 David AI 基準上涵蓋 21 種語言所得的結果，在 14 個系統中最佳，最接近的競爭者是其自家的 Nemotron 3 Diarization 模型，為 18.38%。這些是廠商在其自家測試框架上得到的數字，尚未經獨立重現。它們所暗示的串接式比較——一個模型對上三個——完全不是基準測試的主張，而是對部署方式的描述。

{{1}}語言與轉譯其次。{{/1}}TurboCTC 在十月更新後涵蓋七種語言；Nemotron 則涵蓋四十種語言用於轉錄，以及三十一種語言用於與英文互譯。{{2}}若你的佇列是歐洲語言且為單一語言，七種便已足夠。{{/2}}若不是，比較到此為止。

第三，微調。NVIDIA 報告指出，在單一 GPU 上進行調適，每項任務需 0.5 至 2.3 GPU 小時，並舉出一個醫療語音範例：微調在 3,619 個片段上將字詞錯誤率從 30.8% 降至 11.8%，而未參與訓練的說話者則從 22.44% 改善至 12.17%。IBM 的 TurboCTC 也可微調——其授權為 Apache-2.0——但你會是在小得多的模型上微調 CTC head，而且額外上下文能帶來的效益上限較低，因為沒有語言模型可以發揮作用。

決定它的成本模型

TurboCTC 的經濟效益幾乎平淡到令人乏味。一台 H200 以 19,870 RTFx 提供服務，就能讓一個極大的佇列達到飽和；在一般商用 CPU 上運行量化後、279MB 的版本，每音訊小時的成本幾乎為零，而電費才是真正的支出項目。整個技術堆疊中，沒有任何按分鐘計量的機制。

Nemotron 的經濟結構形狀相同，只是規模不同：沒有按分鐘計量，但加速器大得多，吞吐量上限卻小得多。單張 Blackwell 顯示卡每秒可處理 2,238 秒的音訊，在高併發情況下不到三分鐘就能處理完 100 小時的音訊，而面對有重疊的一小時會議時，所需時間更少得多。

• 每月 20 小時的佇列——在 CPU 上執行 TurboCTC 實際上等於免費；Nemotron 則需要租用或自有的加速器，而該加速器每個月大部分時間都將閒置。

• 每月 2,000 小時、沒有講者要求的檔案庫——在單一 GPU 上執行 TurboCTC，或使用一小組 CPU，都是成本更低、速度更快的配置，而且領先幅度很大。

• 每月 2,000 小時的六人會議存檔——TurboCTC 加上說話者分段標記器再加一個合併層，在單張卡上與 Nemotron 對比評測。這是唯一能讓大型模型價格站得住腳的配置，而即便在此，串接方案在硬體成本上仍更便宜。

• 任何因保密限制而禁止上傳音訊的情況——兩者皆可自行託管，因此無論選哪一個都符合該限制，決定便取決於講者與語言。

管線的後處理部分，正是路由層無論你選哪個辨識器都能證明其價值的地方。轉錄稿會被摘要、標記並路由，而OrcaRouter 將 200 多個文字與多模態模型放在同一把金鑰之後，並以 0% 加價原樣傳遞供應商牌價，自動容錯切換，以及一套路由 DSL，能將某一類轉錄稿送往便宜的摘要器、另一類送往更強大的模型，而無需第二次整合。Nemotron 3.5 Transcribe 與 Granite Speech 5.0 470M TurboCTC 皆未在該目錄中提供——我們不提供語音轉文字託管服務——因此語音選擇仍是一份獨立合約，只有其上層變得可攜。

依工作的形態來挑選，而非看排行榜

如果任務是「把大量乾淨、以英文為主的音訊，盡可能便宜又快速地轉成文字」，那麼 Granite Speech 5.0 470M TurboCTC 勝出，而且勝負毫不接近——它是個 279MB、Apache 授權的模型，速度超過 30B 系統四十倍以上，而在公開英文平均成績上幾乎毫無退讓。你為講者所搭建的串接流程，就是這份效率的代價；而如果你從不需要講者，你就永遠不必付出這個代價。

如果任務是「從一段棘手的錄音，以四十種語言之一，產出一份標明說話者歸屬、附時間碼、結構化的逐字稿」，那麼在兩者之中，只有 Nemotron 3.5 Transcribe 嘗試做到這件事；而廠商提供的說話者分離（diarization）數據——尚未經過獨立重現——顯示它的表現優於它所取代的串接式（cascade）方案。吞吐量成本確實存在，硬體成本也確實存在，但對以會議為主的工作負載而言，這兩者都不至於高到無法承受。

要避免的錯誤，是把這當成一場世代之爭。470M CTC 模型並不是 30B 語音 LLM 的過時版本；它是另一種工具，只是恰好在一個主要由乾淨朗讀語音構成的基準測試上取得相近分數。下一次發布並不會讓它過時。你自己最糟的那段錄音，會告訴你當初需要的是哪一個。