英偉達Vera Rubin的Agent吞吐暴漲最高提升30倍,卻不只靠GPU | Hot Chips 2026
在Agent推理上,英偉達又把性能往前推了一大步。Hot Chips 2026期間,英偉達披露了Vera Rubin NVL72最新Agent工作負載測試結果:在DeepSeek V4-Pro、單用戶每秒160 Token的測試條件下,相比GB300 NVL72,每兆瓦吞吐最高提升30倍。但比30倍更值得關注的是,英偉達這次提升Agent推理效率,已經不再只依賴一顆更快的GPU。
面對長上下文、低延遲Token生成、工具調用和數據交互同時出現的Agent工作負載,英偉達正在把一次推理拆成不同類型的計算任務:Vera Rubin NVL72承擔大規模模型計算,Groq 3 LPX專攻低延遲Token生成,Vera CPU處理工具編排、代碼執行和數據處理,Spectrum-X則負責把這些計算、數據和存儲資源連接起來。換句話說,Agent工作負載讓性能問題不再停留在一次模型計算內部,而是沿著上下文、生成、工具執行和基礎設施訪問繼續向外擴展。
從GPU、CPU到專用推理芯片和網絡,英偉達在Hot Chips展示的已經不只是一代芯片的性能提升,而是一套針對Agent工作負載重新劃分計算邊界的系統架構。超長上下文實測,Rubin把Agent推理拉進真實長任務這次Hot Chips上,英偉達給出了一組更貼近Agent工作流的Rubin實測數據。英偉達此次測試採用SemiAnalysis AgentX工作負載。AgentX基於真實Agent編程會話的流量軌跡,在去除原始 prompt、代碼、工具參數和結果後,保留請求長度、上下文增長、工具暫停、子任務依賴和時序等負載特徵。此次測試的中位輸入上下文超過 14 萬 Token。
按照英偉達測得、目前仍待SemiAnalysis審核的結果,在DeepSeek V4-Pro工作負載、單用戶每秒160 Token的交互速度下,Vera Rubin NVL72相較GB300 NVL72最高實現30倍的每兆瓦吞吐。Vera Rubin 在 160 交互性下,每兆瓦的吞吐量提高了 30 倍。(圖源:英偉達技術博客)英偉達HPC與AI超大規模基礎設施解決方案高級總監Dion Harris指出,傳統推理基準通常圍繞“單一、可預測的請求”設計:輸入和輸出相對確定,因此可以比較Token生成速度、吞吐量等指標。但Agent任務會跨越多輪操作,而且每一步的工作負載都可能變化。
Harris續指,傳統推理負載可以使用8K甚至32K的輸入序列進行測試,但到了遞歸式、多輪Agent任務中,Prefill需要處理的上下文會隨著每一次迭代持續增長,因此平臺評估需要開始考慮數十萬Token級別的輸入。原因在於,Agent完成一項任務時,模型可能不斷讀取文件、調用工具、執行代碼,再把新的結果寫回上下文,進入下一輪推理。AgentX 測的是推理服務基礎設施面對 Agent 流量形態時的表現,不是測 Agent 任務完成質量。這也是此次Rubin測試採用超過14萬Token上下文的意義。
換言之,14萬Token的意義並不只是“輸入更長”,而是測試對象開始從靜態prompt轉向動態任務軌跡。它試圖回答的不再只是“一次模型推理能夠跑多快”,而是在更接近Agent實際運行軌跡的長鏈路負載下,系統還能維持怎樣的性能。與此同時,英偉達把兩個指標放在了同一張性能曲線上:橫軸是單個用戶每秒獲得的Token數量,即交互速度;縱軸則是固定電力預算下整套系統能夠處理的Token數量,即每兆瓦吞吐。在多輪代理會話中,每輪對話所包含的上下文信息穩步增加。
(圖源:英偉達技術博客)這兩個指標對應著Agent推理中兩個不同的性能目標:一邊是提高單個用戶在 Token 生成階段的交互速度,另一邊則是在有限電力條件下承載更多推理負載。因此,這組數據更值得關注的是,當Agent進入硬件實測之後,長上下文、總體吞吐和交互速度開始被放到同一個性能問題中討論。而當同一套推理系統需要同時優化這些目標時,下一個問題也隨之出現:這些任務,是否仍然適合全部交給同一種處理器完成?加入LPX,GPU不再是AI推理環節的最佳架構?這種性能目標的分化,正在直接反映到推理芯片的架構上。英偉達透露,Groq 3 LPX已經進入全面生產。
按照Artificial Analysis的測試,在Gemma 4 31B、10萬Token上下文這一特定負載下,Groq 3 LPX輸出速度達到每秒3400個Token,英偉達稱其響應速度達到最接近替代方案的4倍。LPX瞄準的並不是“大模型推理”這個籠統的問題,而是其中一個更具體的瓶頸:低延遲Token生成。Prefill需要並行處理大量輸入Token,通常更偏計算密集型;Decode則需要一個Token接一個Token生成,並持續讀取模型權重和KV Cache,因此通常更受內存帶寬和單步延遲限制。
英偉達也把Agentic AI面對的計算挑戰拆成了兩個方向:一邊是高效處理越來越大的上下文,另一邊是以極低延遲生成Token。Groq 3 LPX針對的是後一個方向,但需要注意,這並不意味著英偉達正在用LPX替代GPU。GPU與LPX之間並不存在一種固定的任務切分方式。
在最直接的 Prefill-Decode 拆分中,Vera Rubin NVL72 處理輸入上下文並生成 KV Cache,LPX 則參與後續 Decode 階段的低延遲生成;另一種方案則把Decode內部繼續拆開,由Rubin負責Attention計算並持有KV Cache,LPX負責FFN計算;此外,還可以讓LPX運行一個較小的draft model提前生成候選Token,再由Rubin上的大模型進行驗證,即推測解碼。這三種方案的數據流和計算分工不同,但背後的邏輯是一致的:並不是先決定一次推理應該由GPU還是LPU完成,而是把推理內部進一步拆成性質不同的計算任務,再交給更適合的處理器執行。
英偉達稱,Groq 3 LPX 擴展了 Vera Rubin 平臺的功能,使其能夠支持具有高交互性的智能體 AI 工作負載。(圖源:英偉達技術博客)這也產生了一個問題,將Groq 3 LPX加入Vera Rubin,是否意味著GPU已經不再是所有AI推理環節的最佳架構?Harris給出的解釋是,“為工作負載的不同部分選擇合適的處理器”。他認為,Rubin GPU仍然提供最靈活的吞吐和交互能力,覆蓋更廣泛的工作負載;LPX則進一步把系統推向對極低延遲要求更高的場景。
因此,LPX真正值得關注的並不是英偉達又多了一顆芯片,它反映的是,在Vera Rubin這套系統裡,原本由通用GPU統一承接的不同性能目標正在被進一步拆開:GPU繼續承擔覆蓋範圍更廣的模型計算,而專用加速器則圍繞Token生成延遲等具體瓶頸補位。這也解釋了為什麼Agent工作負載下更細的異構分工,並不意味著GPU的重要性下降。恰恰相反,GPU仍然位於計算中心,只是圍繞它,不同處理器的任務邊界正在變得更加明確。從GPU到CPU和網絡,英偉達開始優化整條Agent鏈路如果說GPU與LPX的分工仍然發生在模型推理內部,那麼Agent帶來的下一層變化,是性能瓶頸繼續延伸到模型調用之外。
傳統大模型服務中,一次模型輸出往往就是任務的終點。Agent並不是這樣。模型完成一輪推理後,還可能繼續調用搜索、數據庫或其他軟件工具,執行代碼、處理返回結果,再把新的信息送回模型,進入下一輪推理。這意味著,決定一次Agent任務速度的,已經不只是GPU完成模型計算需要多少時間。Harris提到,Agent正在增加模型調用之間的CPU負載:工具編排、代碼執行、數據處理和模擬,都需要CPU參與。這也是英偉達此次強調Vera CPU的原因。Vera在這裡承擔的並不是模型計算本身,而是兩次模型調用之間那些仍然需要CPU完成的任務。
類似的變化也發生在網絡層,當Agent不斷訪問工具、數據和存儲時,網絡面對的不再只有GPU之間的數據交換。用戶、Agent、應用、數據源和存儲服務需要持續發生交互,計算系統與這些基礎設施之間的連接同樣可能進入任務的關鍵路徑。在這樣的背景下,這英偉達此次提出了Scale-In。與通過NVLink連接機架內GPU的Scale-Up,以及通過Spectrum-X連接更大規模GPU集群的Scale-Out不同,Scale-In針對的是傳統數據中心中的南北向基礎設施流量,由BlueField-4和DOCA承擔網絡、存儲訪問、安全、控制平面和可觀測等任務,再通過Spectrum-X接入整套計算基礎設施。
與 Scale-In 處理模型調用之外的基礎設施訪問不同,Spectrum-X Multiplane 解決的是另一類更普遍的問題:隨著 GPU 集群規模擴大,網絡本身的擴展能力和故障恢復開始直接影響計算資源能否持續被利用。Spectrum-X Multiplane通過多個獨立網絡平面擴大兩層網絡的規模,並在單一路徑出現故障時進行硬件級重新路由。按照英偉達給出的數據,該架構最高可擴展至51.2萬張GPU;在八平面拓撲中,一個平面失效後仍可維持約90%的總帶寬,故障恢復速度較軟件方案提高11倍。Scale-In和Spectrum-X Multiplane解決的並不是同一個網絡問題。
Scale-In處理計算系統與數據、存儲和基礎設施服務之間的連接與管理需求;Multiplane則解決更大規模GPU集群的網絡擴展和故障恢復問題。但放回完整的Agent任務鏈中,兩者指向同一個變化:決定任務效率的環節正在從一次模型計算不斷向外延伸。GPU可以更快地完成模型計算,LPX可以進一步壓低Token生成延遲;但如果Agent隨後卡在工具執行、數據讀取或者通信上,前面獲得的計算性能仍然會被等待時間消耗掉。Agent改變的不只是推理芯片內部的分工,也在擴大AI基礎設施需要優化的範圍。這並非意味著未來每一個Agent系統都會配置LPX、Vera這樣的CPU和如此大規模的網絡基礎設施。
英偉達此次展示的明顯是面向高併發、長上下文和大規模部署的上限設計,它最終能夠形成多大的實際市場,仍然取決於Agent應用能夠產生怎樣的真實負載,以及更復雜的異構系統能否換來足夠的性能收益。從Hot Chips此次英偉達展示出的架構邏輯來看,一個趨勢已經比較清楚:GPU仍然是AI計算的核心。只是當一次Agent任務橫跨上下文處理、Token生成、工具執行和數據通信,下一代推理基礎設施要優化的對象,已經不再是一顆芯片,而是整條任務鏈。【封面圖片來源:網站名英偉達官網,所有者:英偉達】
Related
相關文章
Google 開源 Harness²:遞迴代理程式框架,無需新模型也能提升效能
Google Cloud AI Research 開源了 Harness²,這是一個遞迴代理程式框架,透過改良凍結模型周圍的程式碼與檔案來增強效能。對開發者而言,重點很簡單:你的代理程式無需更強大的模型也能進步。重點摘要:規模為框架而非模型,訓練參數為0,包含8個可編輯的框架元件,版本0.1.0。執行環境為Linux、Python 3.12或3.13搭配uv,模型呼叫則透過Vertex AI。GPU需求未公開。效能方面:一次改良步驟即可在3個基準測試中,提升所有4個模型與框架組合的表現。最佳成果:GLM-5搭配OpenCode在WorkBuddy-Bench上從64.2提升至75.7(+11.5點);最差表現:GLM-5搭配Codex在JobBench上僅提升1.2點(23.6至24.8)。什麼是Harness²?它是Google研究推出的即插即用框架。
如何利用NVIDIA結構化資料模型進行零訓練表格預測
In this tutorial, we implement Structured Data Models, NVIDIA’s new library that puts several pretrained foundation models for tables behind one PyTorch interface, and use it to make predictions without training.
認識 Kyutai REKI:2.4B VLA 模型為機器人操控帶來高效記憶
Kyutai 與 Inria 及 École des Ponts 合作,推出了 REKI——一個用於機器人操控的 2.4B 參數視覺-語言-動作模型(VLA)。該模型僅使用公開數據進行預訓練,並配備了輕量級的近期記憶功能。在三個分佈外基準測試中,僅有規模約為其兩倍的模型能超越它。所有模型權重已於今日在 Hugging Face 上公開。核心資訊:規模:2.4B 參數(2.2B Qwen3.5-2B VLM + 0.2B 流匹配動作專家)。記憶涵蓋最近 3 幀,間隔 1 秒。運行環境:在 1 張 NVIDIA H100 上進行基準測試。從兩個 256×256 攝像頭輸入,編譯後每個動作區塊耗時 21.8 毫秒。權重以 BF16 格式提供,暫無量化版本。性能:在 LIBERO-Plus 和 RoboTwin Clean2Rand 基準測試中,為公開數據預訓練的 VLA 模型中最優;在 LIBERO-Plus 上達到 90.4% 的最高分。
DeepSeek 發布 V4.1-Flash-1017,DeepSWE 得分 77.0,並開放搜尋 API
DeepSeek 剛發布 DeepSeek-V4.1-Flash-1017,這是其 V4.1-Flash 模型的新檢查點,現已在 DeepSeek 網站、應用程式及 API 上線。DeepSeek 宣稱該版本在性能、任務完成速度與輸出簡潔度上均優於 9 月發布的 V4.1-Flash,並稱之為性能與成本的帕累託改進。同時,DeepSeek 也向所有開發者開放了搜尋與擷取 API。對代理建構者而言,這意味著更便宜的編碼模型加上單一 API 金鑰即可使用的第一方網路層。重點摘要:骨架參數 552B,另加 196B 的 Engram 參數;預填充階段每 token 啟用 8B 參數,解碼階段啟用 16B 參數;上下文長度達 1M tokens,最大輸出 384K tokens。運行於 DeepSeek API 的 deepseek-flash 模型。9 月版的 V4.1-Flash 權重(763B 參數,FP8)採 MIT 授權。
2026年20款Jev替代方案:挑戰TypeSafe的決策模型
TypeSafe於2026年9月15日推出Jev,這是一款決策模型而非聊天機器人。使用者可定義允許的答案,Jev將回傳標籤、分數或是否的機率。約4週內,至少20款Jev替代方案相繼問世,來自Cloudflare、OpenAI、Perplexity、Liquid AI、AWS的Strands Labs及獨立開發者。本指南比較各方案在規模、授權、硬體、價格、Jev API相容性及已發布基準測試的表現。重點摘要:規模範圍從287M(GLiNER2.5-multi-Decide)到35B-A3B(Mapika Decider),Jev規模未公開。執行環境:Von和Laya等編碼器可在CPU上運行,4B適配器適用24 GB GPU或32 GB Mac。效能:多數開源模型在困難推理上落後Jev,但在狹窄分類任務上數款與之匹敵或超越。最佳表現:Cloudflare Clef在BANKING7取得94.20分。
長鑫科技市值兩月內跌去1萬億;阿里加碼AI硬件品牌,天貓、速賣通聯動;國行版蘋果AI有望12月上線,百度、阿里參與合作丨雷峰早報
要聞提示1.長鑫科技市值兩月內跌去1萬億2.年內已至少18次故障!DeepSeek發放宕機補償,有人拿到3000元3.阿里加碼AI硬件品牌,天貓、速賣通聯動4.國行版蘋果AI有望12月上線,百度、阿里參與合作5.可靈AI新一代模型Kling 4.