NVIDIA 宣稱 Vera Rubin NVL72 每瓦可帶來高達 30 倍的 agentic 工作量

NVIDIA 表示,Vera Rubin NVL72 相較於 GB300,每百萬瓦可提供高達 30 倍的 agentic 推論吞吐量,但仍待獨立基準審查。

AI News

NVIDIA 表示,即將推出的 Vera Rubin NVL72 平台,每百萬瓦可帶來比該公司 GB300 NVL72 系統高達 30 倍的 agentic AI 吞吐量。這項說法來自 SemiAnalysis AgentX 的預覽結果;該基準的設計目的,是重現生產環境風格的程式碼代理人會話,而非固定長度的聊天機器人提示詞。

這項結果之所以重要,是因為 AI 代理消耗的推論容量遠高於一般聊天。NVIDIA 的來源引用 OpenRouter 資料指出,單一 agentic 請求使用的 token 數量大約是簡單聊天請求的 15 倍,因為代理會反覆推理、呼叫工具、把工作委派給子代理,並在任務過程中攜帶不斷擴大的上下文。

Vera Rubin 的比較目前還不是經過獨立驗證的結果。NVIDIA 使用 SemiAnalysis AgentX 工作負載測得這些數字,並表示結果仍待 SemiAnalysis 審查。這代表這項公告只是供應商回報的早期效能訊號,而不是已確認的產業基準。

以代理工作負載為核心建立的基準

AgentX 是 SemiAnalysis 的 InferenceX 基準套件的一部分。根據 NVIDIA Developer Blog,它透過 AIPerf 用戶端重播預錄的 Claude Code 會話,保留原始軌跡中記錄的模型呼叫順序、推理間隔、工具使用、上下文增長與工具呼叫延遲。

這種設計試圖解決傳統推論測試的一個弱點。靜態測試常使用預先設定好的輸入與輸出長度,例如一個 8,000 token 的提示詞接著 1,000 token 的回應。真實的程式碼代理會產生不均勻的流量:一項任務可能在模型推理、檔案操作、搜尋、編譯器輸出與後續模型呼叫之間交替,而累積的上下文也會隨時間變得大得多。

AgentX 會測量每百萬瓦的 token 數,同時也包含使用者體驗指標,例如首個 token 時間、端到端延遲與互動性。NVIDIA 的 Vera Rubin 主要結果是在 AgentX DeepSeek V4 Pro 工作負載上,以每位使用者每秒 160 token 測得。該公司表示,在那個操作點上,Vera Rubin NVL72 的每百萬瓦 AI 工廠吞吐量最高可達 GB300 NVL72 的 30 倍。

該基準也顯示目前 Blackwell 世代有顯著提升。NVIDIA 表示,GB300 NVL72 在 DeepSeek V4 Pro 1.6T 上,每百萬瓦吞吐量最高可達 H200 NVL8 的 15 倍,而在 Kimi K3 2.8T 上則最高可達 80 倍。這些數據同樣是透過 NVIDIA 對 AgentX 結果的報告所呈現,因此也應如此看待。

這項說法背後的基礎架構

NVIDIA 將預期的效率提升歸因於硬體規模與軟體最佳化的結合,而不只是 Rubin GPU 本身。NVL72 設計將 72 顆 GPU 連接在一個 scale-up domain 中,使工作負載能分散模型專家,並透過高頻寬互連在整個系統中維持上下文。

這對長時間運作的代理很重要,因為先前處理過的上下文常常可以重複使用,而不必重新計算。NVIDIA 描述了一種服務設計,將 prefill(系統處理輸入上下文)與 decode(產生輸出)分開。這些階段之間的速率匹配,目的是避免一邊閒置,而另一邊成為瓶頸。

該公司也指出分散式 key-value 快取、KV-aware 請求路由,以及將快取卸載到主機記憶體或儲存裝置。這些技術的設計目的是,讓成長中的代理會話中相關部分能跨多個請求保持可用。NVIDIA 表示,第六代 NVLink 與 NVLink Switch 技術在這種 scale-up 通訊上,提供比傳統 Ethernet 替代方案更高的封包速率與更低延遲。

軟體層包括 NVIDIA TensorRT-LLM、NVIDIA Dynamo,以及針對 mixture-of-experts 模型最佳化的 CUDA kernels。面向開發者的說明也提到 SGLang 與 vLLM 作為較大最佳化堆疊中使用的 serving runtimes,另有 DeepGEMM kernels 與 MXFP4、MXFP8 這類較低精度格式。NVIDIA 表示,Rubin 上的 NVFP4 量化旨在減少記憶體使用並提高吞吐量,同時保留輸出品質,但所提供的證據並未提供獨立的品質評估。

NVIDIA 進一步表示,其 DSX MaxLPS 技術可在 GPU、機櫃與工作負載層級管理電力,並可能在相同百萬瓦預算內容納高達 40% 更多 GPU。這是 NVIDIA 的容量規劃主張,而不是僅由 AgentX 數據就能證明的結果。

為何建置者與 AI 營運者應該關注

對於打造程式碼助理、研究代理或客服自動化的團隊來說,相關指標已不再只是單一提示詞多快能產生答案。一個生產環境中的代理可能同時保持多個模型呼叫活躍、保留龐大上下文,並在外部工具回傳資料時暫停。因此,在短而孤立的請求上表現良好的基礎架構,到了真實工作流程中,可能會浪費電力或失去回應速度。

Vera Rubin 的公告把電力效率同時界定為部署限制與定價問題。NVIDIA 表示,在所引用的工作負載上,Vera Rubin NVL72 相較於 GB300 NVL72,每百萬 token 的成本最高可降低 35 倍。其 developer blog 另外指出,GB300 相較於 H200 NVL8,單一 token 成本最高可低 10 倍。這些計算取決於基準設定、能源假設與使用率,因此企業買家需要以自身模型與服務模式進行測試。

這項結果對於服務大型 mixture-of-experts 模型,或 session 特別長的代理營運者,可能尤其相關。在這些環境中,記憶體搬移、快取重用與互連行為的重要性,可能與加速器的原始運算能力不相上下。不過,如果小型團隊使用的是短上下文模型、低併發,或是會隱藏底層硬體的託管 API,則未必能看到相同的經濟效益。

此外還有可靠性問題。更積極的快取、解耦式服務與工具編排可以提升利用率,但也增加排程與狀態管理的複雜度。建置者需要評估故障復原、快取失效、尾端延遲與工作負載隔離,而不能只依賴峰值每秒 token 數字。

接下來要觀察什麼

第一個訊號將會是 SemiAnalysis 對 Vera Rubin AgentX 結果的審查。若能獨立公布測試配置、功耗測量、模型設定與互動性目標,就能判斷 30x 的說法在不同系統之間有多可比。

買家也應關注包含 Vera CPU 在工具呼叫中角色的結果。NVIDIA 明確表示,早期數字尚未反映 Vera CPU 在該工作流程部分的表現。由於代理會花時間在模型生成之外,因此端到端測量可能與單純加速器吞吐量不同。

其他有用的後續資訊包括 Vera Rubin NVL72 的供應與定價、在 DeepSeek V4 Pro 以外模型上的表現,以及來自執行自身 traces 而非預錄會話的營運者結果。NVIDIA 軟體堆疊的變化也可能影響比較,因為該公司表示 Rubin 與 GB300 的效能都會透過持續最佳化而提升。

Creati.ai 觀點

NVIDIA 的公告之所以重要,不在於它建立了最終的 30x 產業標準,而在於它凸顯了推論效能定義正在改變。代理工作負載會暴露固定提示詞測試可能忽略的瓶頸:上下文重用、工具呼叫間隙、快取容量、併發與電力供應。

對 AI 建置者來說,實際的教訓是在投入基礎架構之前,先對完整的代理軌跡做基準測試。NVIDIA 的早期結果顯示,高度整合的硬體與服務軟體,可能實質改變長時間運作代理的經濟性;但在底層 AgentX 測量經過獨立審查與重現之前,這種優勢的幅度仍未被證實。

廣告