Nemotron 3.5 Transcribe 與 Nemotron 3.5 Transcribe 30B：兩個名稱、同一個檢查點、四個檔案

如果產品目錄、比較網站或你自己的採購表，把 Nemotron 3.5 Transcribe 與 Nemotron 3.5 Transcribe 30B 列成兩筆項目，那其實是把同一個模型列了兩次。官方發布的儲存庫是 NVIDIA-Nemotron-3.5-Transcribe-30B-A4B，NVIDIA 的規格表標示總參數量為 34B、啟用參數量約為 4.3B，而每則標題中那個樸素的名稱，指的正是同一個成品，只是把規模數字省略掉了。並不存在另一個獨立的 30B 模型可供對比，因此這件事與其說是正面對決，不如說是命名問題，而部署決策就藏在其中。

但那個決定確實存在，而這正是這兩個名稱不斷同時出現的原因。一個名稱是你會搜尋的名稱，也是模型目錄或 api 列表可能顯示的名稱。另一個則是你下載的檔案，有四種精度之一、四種記憶體佔用量之一，而那些檔案之間的選擇，是這個模型實際上唯一要求你做的比較。接下來要調和的是：30B 計算的是什麼、為什麼卡片上寫的是 34B，以及哪個檔案適合你手上的 GPU，而不是發表頁面所假設的那張 GPU。

自相矛盾的名字

目前流傳著兩個數字，而且兩者都是官方說法。儲存庫名稱以 30B-A4B 結尾，遵循 NVIDIA 為其混合專家系列所採用的命名慣例：先寫總參數量，再寫啟用參數量。同一頁面上的模型卡則標示總參數量 34B、啟用參數量約 4.3B，並明確包含音訊編碼器。研究頁面也在其標題中重複了 30B-A4B 這個名稱，並在正文中重複了 4.3B 啟用參數量這個數字。

模型卡也列出了各個元件，而算術問題正是從這裡開始變得要緊。語言主幹是 Nemotron 3.5 Lightning 30B-A3B，一個結合 Mamba-2 與 Transformer 的混合式 MoE，具備 3.5B 活躍參數。聯合音訊編碼器——一個 Transformer ASR 編碼器加上一個語者編碼器——約為 800M。把這些加起來，你會得到大約 30.8B，而不是 34B。要嘛是 34B 計入了 NVIDIA 並未逐項列出的某些東西，要嘛是儲存庫名稱裡的 30B 只是個四捨五入的標籤，而這個主幹的實際規模比其名稱所示的還要大。NVIDIA 並未公布對帳說明，而且目前也尚未有針對完整檢查點（checkpoint）的第三方參數量審核。

對買家而言，這代表的意思比聽起來更狹窄。系統是 31B 還是 34B，並不會改變它能裝進哪張卡，因為檔案大小受精度影響的程度，遠大於受最後三十億個參數影響的程度。這確實意味著，任何標示「30B」的規格表與任何標示「34B」的規格表，描述的都是同一個下載檔；而建立在這個差異上的採購比較，比較的不過是四捨五入的慣例。

30B 後綴實際上在計算什麼

後綴所計數的是一個語言模型，而不是一個轉錄器。Nemotron 3.5 Transcribe 是一款語音增強的 LLM：音訊會經過 Transformer 編碼器，一個凍結的 Nemotron 3 Diarization 模型透過 NVIDIA 所謂的平行專家編碼器提供語者表徵，而混合式 MoE 解碼器則負責寫出轉錄稿。30B 這個標籤屬於解碼器及其嵌入層堆疊。語音路徑——編碼器、語者分離器、CTC 時間戳頭——是附加於其上的，並非名稱所標榜的東西。

這就是為什麼此模型會在某些方面表現得像 LLM，而傳統 ASR 系統不會。它能接收提示。它會回答關於音訊的問題。它在同一次推論中進行 31 個語言對與英文的互譯。它具備 65,536 個 token 的上下文，因此一小時的語音無需分段即可容納。這些都不是因為 30B 解碼器規模龐大；而是因為解碼器本身就是通用語言模型，並將語音投射到其輸入空間。

這也解釋了大家一直遍尋不著的缺失。沒有僅有 30B 的兄弟模型，沒有更小的稠密版 Transcribe，也沒有更大的版本。該儲存庫收錄的是單一模型的各種精度版本，而不是一個模型家族。流通中的其他尺寸只有社群產生的量化版本，以及一個真正更小的串流辨識器——Nemotron Speech Streaming EN 0.6B——那是另一個模型，僅涵蓋英文且不支援說話者分離，並不是這個模型的迷你版。

名字背後的這四個檔案，以及每一個在記憶體中所耗費的成本

這正是這兩個名稱實際上所指的比較。NVIDIA 公佈了三種精度，社群則另外加入第四種交付格式；下方的記憶體數字來自已公佈的檢查點與社群儲存庫，而非單一廠商的表格。

• BF16 — 參考檢查點，磁碟上約 67-68GB，在單張 H100 80GB 上提供服務。已發佈的基準測試數據就是在這個版本上產生的，當你需要重現那些數據時，就該使用這個版本。

• FP8 — {{1}}約 35GB{{/1}}，這使最低門檻下移到 48GB 的顯示卡，例如 L40S。以 NVIDIA 自家的說法，相對 BF16 的精度損失很小，但這終究是 NVIDIA 自己的說法；目前尚未有獨立的 FP8 評測結果發表。

• NVFP4 — 約 21GB，小到足以裝進 32GB 的 RTX 5090 或 RTX PRO 6000。NVIDIA 宣稱在單張 RTX PRO 6000 上搭配 DFlash2 草稿模型時，每秒可處理 2,238 秒音訊；這項備受矚目的吞吐量數據，背後的精度正是 NVFP4。

• GGUF — 四個社群解碼器，大小介於 19.7GB 與 35GB 之間，另加一個必備的 1.67GB F16 編碼器檔案。19.7GB 的 IQ4_NL 版本鎖定 24GB 顯卡、CPU 推理、Metal 與 Vulkan；19.7GB 的 NVFP4 版本則鎖定 Blackwell；Q5 約為 29GB，Q8 約為 35GB。選用的 1.15GB DFlash2 草稿模型可為 CUDA 路徑加入投機解碼。

• MLX — 針對 Apple silicon 的社群 4-bit 至 8-bit 移植版，大小約介於 19GB 到 35GB，其中一位作者回報 4-bit 版本約每秒 154 個 token。適合在 Mac 上進行評估，但不適合作為正式生產服務路徑。

是什麼在執行它們，以及人們會犯的那個執行階段錯誤

GGUF 檔案才是陷阱。副檔名為 .gguf 的檔案並不代表就是 llama.cpp、Ollama 或 LM Studio，而這三者都無法執行此模型：它需要一個已接入音訊編碼器的語音 LLM 執行環境。發佈時可用的路徑，比格式清單所暗示的還要狹窄。

• vLLM 0.32.0 — 主要路徑，也是唯一能完整呈現全部輸出內容的路徑，包括透過 V1 runner 與時間戳中介軟體提供的詞級時間戳。講者歸屬輸出與翻譯功能皆在此提供。

• SGLang-Omni 0.2.0 於 SGLang 0.5.22 —— 透過 OpenAI 相容的音訊端點進行整檔轉錄，不支援字詞時間戳記、講者歸屬、翻譯或推測解碼。

• NeMo Speech — 微調工具包，NVIDIA 表示每項任務在單一 GPU 上需 0.5 至 2.3 GPU 小時。已發布的 LoRA 配方可在單張顯卡上執行。

• NeMo-Speech.cpp 與 speech.cpp — 這是 GGUF 建置工具所針對的 C++ 路徑，也是唯一能載入那些量化檔的路徑。上述的 19.7GB 與 35GB 檔案都是為它而發布，而各儲存庫的 README 才是說明什麼適合放在哪裡的可靠來源。

• Transformers — 從原始碼安裝後於程序內使用，足以應付評估，但不適合追求吞吐量。

錯誤的做法是下載最小的量化版本、把 llama.cpp 指向它，然後得出模型壞掉的結論。它並沒有壞掉；它是一個語音 LLM，帶有文字執行環境根本沒有概念的編碼器。如果該執行環境的支援架構清單中沒有列出 Nemotron 3.5 Transcribe，那麼無論檔案多小，都無法載入。

以淺顯的方式說明每個檔案的定位

從硬體反推，而不是從模型卡正推。模型卡所述的基準——一張 H100 80GB、BF16——是最高保真度的路徑，而不是最低限度的那一個。

• 24GB 顯示卡，RTX 4090 或 L4 等級——19.7GB 的 IQ4_NL GGUF 加上其 1.67GB 的編碼器。要為 KV 快取與音訊緩衝區保留餘裕；24GB 雖然吃緊，但已有紀錄證明可行。

• 32GB 顯卡、RTX 5090 或 RTX PRO 6000——21GB NVFP4 檢查點，這正是 NVIDIA 吞吐量宣稱所描述的配置；若你想要推測解碼，可搭配 DFlash2 草稿模型。

• 48GB 顯示卡，L40S 或 A6000 — 35GB FP8 檢查點，在保真度與成本之間最不尷尬的折衷方案。

• 80GB 加速器，H100 或 A100 — BF16，這是參考配置，也是唯一能在沒有精度但書的情況下重現已發表 WER 表的配置。

• 完全沒有 GPU —— 這些檔案一個都沒有。編碼器在 C++ 路徑中於 CPU 上執行，但在沒有加速的情況下，用 30B-A3B 解碼器處理一小時的音訊，是以數小時計的批次作業，而非一項服務。

每個精度方案都逃不掉一項限制：輸入必須是 16kHz 單聲道 PCM，且每次請求的音訊上限為一小時。降取樣與聲道選擇都在模型看到任何東西之前就已進行，而除非你自行分離聲道，否則立體聲會議室錄音會被混成單聲道。這是預處理階段的決定，而非檢查點層級的決定；一旦做錯，對轉錄品質的損害會比 BF16 轉 FP8 這一步更大。

當一筆刊登同時顯示兩個名稱時，應執行的檢查項目

由於名稱重複的情形確實存在，而且會在目錄和比較頁面中反覆出現，因此一套簡短的驗證流程，比再多寫一段解釋更有價值。

• 儲存庫 ID — 唯一官方產物是 NVIDIA-Nemotron-3.5-Transcribe-30B。若某一列名為 Nemotron 3.5 Transcribe 30B，但使用不同的儲存庫 ID，則該列要麼是量化版本，要麼完全是另一個模型。

• 授權字串 — 官方發行版為 OpenMDW-1.1，允許商業使用。若某項刊登資訊標示為僅限研究或非商業，那它所描述的是另一回事。

• 上下文與音訊視窗 —— 65,536 個 token、一小時。若標示中引用更長的視窗，即為錯誤，或是在描述不同的檢查點。

• 參數宣稱 — 名稱寫的是 30B-A4B，規格卡上寫的是 34B，兩者實際啟用皆為 4.3B。有份標示為總計 4B 的清單，是把啟用參數量誤當成總參數量，而這也是網路上這個模型最常見的轉抄方式。

• 檔案清單 — 來自 NVIDIA 的 BF16、FP8 與 NVFP4，外加一個 DFlash2 草稿模型。若某個頁面只把「Nemotron 3.5 Transcribe 30B」提供為單一下載檔案，且未標示任何精度，那便是冒用廠商名號的社群量化版本。

實際上獨立的路由問題

一旦檔案選定、執行階段也運作起來，部署問題就結束了，接著又回到一個更早的問題：這些文字後續會如何處理。轉錄稿是摘要、實體擷取、去識別化、搜尋索引和問答的原料，而這些呼叫都屬於一般的文字模型流量，也會碰上一般的文字模型問題——速率限制、上游服務中斷，以及用一個便宜的分類模型就足以處理九成的量。

OrcaRouter 不提供 Nemotron 3.5 Transcribe，其型錄中也没有以這兩個名稱為名目列出的項目；如果你在任何地方看到此模型有兩筆資料列，上述的儲存庫檢查是最快釐清的方式。平台真正提供的是轉錄稿存在之後的那一層：一組與 OpenAI 相容的金鑰，涵蓋 200 多個文字與視覺模型，以供應商定價、0% 加成，跨供應商自動容錯移轉，以及一套路由 DSL，能將多個模型組成一次呼叫，讓便宜的擷取階段與昂貴的判斷階段能位於單一端點之後。GPU 負責轉錄；路由則決定轉錄稿值多少。

後綴是檔案大小的標籤，不是第二個模型

要把這兩個名稱清楚記在腦中，最簡單的方式是：Nemotron 3.5 Transcribe 是產品，Nemotron 3.5 Transcribe 30B 是儲存庫；其中 30B 計算的是解碼器，而模型卡計算的是整個系統。30.8B 與 34B 之間的落差，是 NVIDIA 應釐清但尚未解決的細節；不過這不會改變買家所做的任何決定，因為決策取決於 GB 數與支援的執行環境，而不是參數量的小數第三位。

選擇你的顯示卡能支援的精度，確認執行環境有列出該架構，並把任何將這兩個名稱呈現為兩個獨立模型的清單，視為型錄錯誤，而不是一項選擇。這次發佈中真正的分岔——也就是值得來場真正正面對決的那個——一邊是 0.6B 串流辨識器，另一邊是這個 30B 離線轉錄器。那項比較關乎延遲與涵蓋範圍，值得做。把模型拿來跟自己的檔名相比，則不值得。