Nemotron 3.5 Super 對決 Claude Opus 5.5：120 億活躍參數對上計量標準

決定這場比較的關鍵數字就在這裡，而它並不在任何一張基準測試表上。NVIDIA Nemotron 3.5 Super——由 NVIDIA 以更完整的名稱 NVIDIA Nemotron 3.5 Super VL發布，並在 Ollama 函式庫中列名為 nemotron-3.5-super/——每生成一個 token，就會啟動其 1,200 億個參數中約 120 億個。Claude Opus 5.5則完全不公布參數數量，並對每百萬輸入 token 收取 4 美元、每百萬輸出 token 收取 20 美元。因此，這兩款模型之中，其中一款的每 token 邊際成本是電力的函數，另一款的每 token 邊際成本則是一筆列帳項目。這兩個數字都是真實的。但兩者都無法告訴你哪一款模型的營運成本更低，因為它們是以不同的貨幣計價。

現在值得寫這件事的原因：NVIDIA 的權重在 2026 年 10 月 12 日悄悄上傳到 Hugging Face，放在一個名為 NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-BF16 的儲存庫裡；三天之後，NVIDIA 自家新聞室在 10 月 15 日的貼文才使其正式化。在該公告之前，Nemotron 3.5 Super 作為可執行之物存在的唯一公開確認，是一組註冊表產物——以及那些產物上的某些規格與廠商模型卡上的規格不符這件事。從該儲存庫能得知的確實不少：位元組數、量化格式、版本閘門、授權條款。但從任何儲存庫都無法得知的是，它在你的工作負載上相對於代管的前沿模型表現如何。這個落差正是本頁要談的。

首先，這個儲存庫實際上包含什麼

三個可用的檢查點在10月12日相隔六十秒內接連發布：BF16 參考權重、一個 Base 變體，以及一個 NVFP4 建置版本。一個獨立的 LiLiCorr 草稿模型儲存庫早一天、於10月11日上線，這是該層級最早的公開足跡。該卡片描述了一個混合 Mamba-2 與 Transformer 的專家混合模型，每個 MoE 層有 512 個路由專家、一個 C-RADIO 視覺編碼器與一個視覺語言連接器，總參數達 1,200 億、活躍參數為 120 億，上下文最多可達 100 萬個 token，支援文字、圖像與影片輸入、文字輸出，並透過多 Token 預測頭實現原生推測解碼。授權條款為 OpenMDW-1.1，允許商業使用。部署規格指定為 BF16 使用四張 H100 或兩張 GB200。

Ollama 清單是大多數人會最先遇到的版本，而規格正是從這裡開始出現偏差。它公開了九個標籤。其中四個——:latest/、:120b/、:120b-a12b/ 和 :120b-a12b-q4_K_M/——都指向同一個 q4_K_M 層，因此預設拉取的內容是 4 位元量化，「120b」這個名稱並非你實際取得的檔案。每個標籤，包括最小的那個，都帶有 1.6 GiB 的視覺投影器，因為影像路徑並非可選。出廠預設取樣是 temperature 1.0 搭配 top_p 0.95，這是模型卡的文字建議——模型卡的視覺設定是 temperature 0.6。而且執行階段閘門會強制執行：設定檔宣告requires: 0.40.5/，因此在較舊的 Ollama 上，拉取完全無法運作。

那些都不是缺陷。那只是廠商發行說明與社群重新打包版本之間常見的落差，也正是必須兩份文件都讀、而不是只讀一份的理由。

12B 活躍參數的誠實算術

稀疏激活是這個模型全部的商業論據，值得精確說明它究竟能帶來什麼、又不能帶來什麼。

它換來的是：在推論時，一個 token 只會觸及網路的約十分之一。因此，在固定硬體上，其吞吐量會遠比 120B 模型更接近 12B 稠密模型，而記憶體佔用量是完整 1,200 億參數唯一會顯現的地方。N​VIDIA 自家的卡宣稱吞吐量最高可達同級產品的 5 倍，且在該廠商的 Dynamo 堆疊上提供服務時，同時使用者數最高可達 8 倍，延遲降低 85%。這些是廠商在自家硬體上產生的廠商數據，它們是規格，不是稽核——但這項宣稱的方向正是該架構的直接結果，而這至少是個前後連貫的說法。

它換不來的是：權重仍然必須完整常駐。BF16 GGUF 這一層是 230.4 GiB。預設的 q4_K_M 則是 82.3 GiB 再加上投影器。這兩個數字都不會縮小，因為每個 token 只有 120 億個參數會觸發。因此，硬體門檻取決於記憶體，而吞吐量則取決於啟用量——這正是為什麼單張 96 GB 的顯示卡能輕鬆容納 4 位元模型，還能以令同等總規模的稠密模型難堪的速率產生 token，也是為什麼同一張卡根本容納不下全精度模型。

現在把 Opus 5.5 放在那旁邊。Anthropic 的模型有 100 萬個 token 的上下文，最大輸出為 128,000 個 token，接受文字、圖像和檔案輸入，定價為 $4/$20，快取讀取為每百萬 $0.20。沒有下載、沒有量化決策、沒有需要修正的取樣預設值，也沒有需要鎖定的版本。它也是一個經過良好審核的模型：它在大多數人用來比較這些東西的第三方面板中位居榜首，遠遠高於這個 Nemotron 層級。

所以，這項比較並不是「哪個更好」。就實測的通用能力而言，託管旗艦勝出，若假裝不是如此，對即將做出購買決定的讀者就是幫倒忙。真正的比較，在於兩條成本曲線交會之處。

1200億參數開源模型在何處證明其價值

三個地方，而且都很具體。

• 固定帳單的用量。自架檢查點會把邊際成本轉換為固定成本。在低流量下，按量計費徹底勝出——四張 H100 每月的成本高於多數團隊花在 token 上的費用。在高流量且穩定的情況下，固定成本會被攤銷，按量計費則不會。交叉點是這裡唯一重要的計算，而它取決於你的 token 用量，而非任一模型的品質。

• 以頁數為成本驅動因素的視覺工作。NVIDIA 的顯示卡在 MMLongBench-Doc 上報出 62.82，在 MathVision 上報出 78.16，在 CharXiv 推理上報出 80.82，在 OCRBench v2 英文上報出 68.12，中文則為 59.15，全部都是廠商自行公布的數據。在 Opus 5.5 上，這些相同輸入是按 token 計費的，而一頁掃描報告就是一大堆 token。如果你每天的工作負載是數千頁文件，成本計算的變動會比任何品質差異都來得快。

• 版本鎖定。由你掌控的磁碟上的檢查點不會在你背後改變。在受監管的管線中，這價值不菲，而且是託管模型無論出價多高都無法提供的特性。

有兩個地方它不值得佔有一席之地，而這兩點都值得公開說出來。第一個是長時程的智能體工作：NVIDIA 的模型卡報告在 Terminal-Bench 2.1 上為 66.70，在 SWE-bench Verified 上為 71.10，在 SWE-bench Pro 上為 51.78 —— 體面、未經重現，且落後於託管前沿。第二個是任何失敗請求代價高昂的情況，因為一個權重已經四天大的模型，背後有四天的全球關注，卻完全沒有營運歷史。

你現在還不該信任的數字，以及原因

Nemotron 3.5 Super 整份已公布的基準測試表都是廠商自家的，是透過 NVIDIA 的 NeMo Gym 測試框架收集而成。GPQA-Diamond 89.52。Humanity's Last Exam 純文字版 31.79。LiveCodeBench v6 88.22。IFBench 70.86。tau2-bench 69.24 零售、76.50 航空、73.19 電信。BrowseComp 78。LMArena v3 代理指標 52.67。這些每一項都是附有可重現方法的廠商宣稱，這比空口宣稱好，但仍不是獨立測量。

獨立評測的畫面要單薄得多，而這本身就是本頁最有用的事實。為這些模型評分的第三方評測面板，將這個檢查點放在智力指數二十幾左右——大約 26——而 Opus 5.5 則約為 58。該面板還記錄到，這次指數運行消耗的輸出 token 異常地高，它將此解讀為冗長，而在任何按 token 付費或按 token 等待的部署中，冗長是一條成本項，而不是腳註。一個獨立數據點不是判決，但它是唯一不是由販賣該模型的公司所產出的數據點。

沒有人公佈過的是：4 位元量化如何改變那些分數。Ollama 的預設標籤是 q4_K_M。所有已公佈的數字都是針對 BF16 或 NVFP4。因此，大多數人實際會體驗到的數字並未被測量，而這正是接下來幾週值得關注的那一個。

今天你可以呼叫什麼、不能呼叫什麼

值得直截了當地說，因為這是這類頁面上最常見的誤解。N​emotron 3.5 Super 並不在 OrcaRouter 上。我們路由兩百多個模型，其中沒有 N​VIDIA N​emotron 條目，所以如果你需要這個特定的檢查點，你的途徑就是廠商自家的建置與發行管道，以及本地執行環境的拉取——不是我們。

相對地，Opus 5.5 是跑在我們自己的金鑰上，以供應商定價原樣轉嫁、不按 token 加價，這意味著廠商一調價，我們這邊當天就生效，而不是等到下次合約續約。這種不對稱性對你眼前這個決定確實很有用：成本最低的第一步，就是把原本要跑在四張 H100 上的工作負載，先拿去跑託管模型，用一組 API，不必走採購流程。如果託管模型能以可接受的價格把事情辦好，你就省下了一整座叢集。如果辦不到——而在大規模情境下誤讀一份密集的技術文件，正是它可能辦不到的一種情況——你手上就有的是實證，而不是一張基準測試表，於是你可以把下載的力氣花在那些通過考驗的案例上。

具體來說，部署配方要付出多少成本？

這張卡自身的 vLLM 配置值得當作一份預算文件來讀。張量平行度為 4、GPU 記憶體使用率 0.85、最多 32 個並行序列、每個提示各一張圖像與一段影片、影片剪枝率為 0.5，以及透過 MTP 頭進行的推測解碼，搭配三個推測權杖。四張 H100 在 0.85 使用率下、並行序列上限為 32，這並不是一項大型服務——而是一套紮實的單節點部署，而這個並行上限告訴你，廠商預期單一複本要能處理多少負載。

那個配方裡有兩個細節，其重要性遠超過表面所見。影片設定每個提示只接受一支影片，並以半速率進行修剪，這強烈暗示了在長輸入時視覺預算都花到哪裡去。nemotron_v3/，而工具呼叫解析器則命名為qwen3_coder/——這家廠商重複使用了一個並非自己發明的工具呼叫格式，對任何已有工具呼叫程式碼的人來說是個好消息，也值得在你撰寫新的解析邏輯之前先知道。

相較之下，託管模型的營運接觸面就只是一組 API 金鑰。「四張 H100 加一套 vLLM 做法」與「一組金鑰加一個計量錶」的比較，在投入心力上根本無法相提並論。只有在成本上才接近，而且還得達到一定用量規模。

還有一件能從儲存庫得知、卻很容易被忽略的事：建議的取樣設定會因模態而異。文字想要 temperature 1.0 搭配 top_p 0.95；視覺則想要 0.6 搭配 0.95。若某個部署全域設定同一組參數，然後處理圖表和掃描頁面，就等於用文字部分的設定來跑視覺模型的視覺部分。如果你對這個模型在文件上的第一印象很差，那就是第一個該檢查的旋鈕——在你對檢查點做出任何結論之前。

所以是哪一個？

如果你的工作是長時程的代理式編碼，或是任何必須在第一次嘗試就達到前沿級推理水準的任務，Claude Opus 5.5 就是答案，而 Nemotron 這個層級無法取而代之。這不是什麼難以取捨的抉擇，而且該廠商自己公布的代理式評測數據也沒提出相反的說法。

如果你的工作是大規模的文件與圖像理解，而成本的主要驅動因素是頁數而非推理的難度，那麼這是今年出現的較有意思的開放檢查點之一：1200 億參數、120 億活躍參數、寬鬆的授權、真正內建而非事後硬加上去的視覺路徑，以及預設 4 位元量化、可放進單張 96 GB 顯示卡。問題在於，大家實際上會跑的那個版本——預設的 q4_K_M——沒有任何地方發表過評測，這個模型才問世四天，而且執行環境所公布的規格與廠商所公布的規格並不完全一致。

這兩者都是試用它的理由，不是信任它的理由。先把工作負載放在託管模型上，弄清楚這個工作負載是不是前沿模型能解決、而中階模型無法解決的那種。接著再決定，那些仍存續的案例是否值得動用一整個叢集、一次下載，或花一整晚做設定。而如果你真的把四天前的檢查點放進請求路徑，就把它路由到備援之後，因為對一個沒有運維歷史的模型來說，最便宜的保險就是在同一個呼叫背後再放一個模型。

數字無法告訴你的是，這一切在實際運作中是否出了問題：針對此類模型有記錄的 AI 事件與代理故障，都收錄在the OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、可信度等級與爭議標記。