TL;DR
又是一年一度的 GTC，今年恰逢 CUDA 問世 20 週年。Jensen 在整場主題演講中回顧了 CUDA 生態系統，接著談到推論時代的來臨，並預測推論市場將持續成長。隨後進入最激動人心的硬體發布環節，推出了 Groq 3 LPU 以及整個 Rubin 系列家族，帶來了一些新變化。接著發布了 OpenClaw 以及 Nvidia 自家的 NemoClaw。最後探討了實體 AI（Physical AI）與機器人技術。接下來我們將分章節詳細回顧整場主題演講。影片回放可造訪 《GTC 2026 Keynote》[1]。
1. CUDA 20 年
今年正值 CUDA 發布 20 週年。
老黃從 2001 年可編程 Pixel Shader 的經歷開始回憶，對這段歷史不熟悉的讀者，可以參考我先前整理的《GPU 架構演化史》專題。
接著介紹一些 CUDA 相關的生態系統。第一個例子是 RTX 相關的 DLSS 5 展示，DLSS 5 引入了即時神經渲染模型，能為像素注入逼真的光照與材質效果。DLSS 5 彌合了渲染與現實之間的鴻溝，讓遊戲開發者能打造出前所未有的逼真電腦圖形，達到好萊塢等級的視覺特效。
然後繼續介紹用於處理結構化數據的 CuDF。
以及用於處理非結構化數據的 cuVS（向量搜尋）。
並透過 GCP、AWS、Azure、Oracle、CoreWeave 及其客戶的案例，展示整個軟體堆疊。好夥伴們必須雨露均霑嘛……以下是各家雲端服務商及其典型客戶。
接著介紹一些與 Dell 合作的內部部署（On-prem）方案：
接下來，老黃介紹了多個行業的應用，並有趣地詳細說明了量化交易（Quant）如何從傳統的特徵工程，轉變為由 AI 模型自動發現特徵因子。不過在介紹電信業（Telco）時似乎有點卡住，難道與 AI RAN 進展不太順利有關？
然後老黃繼續介紹他的朋友們，一系列 AI Native 公司。有趣的是，中國模型公司上了三家：DeepSeek、Kimi、Qwen。為什麼已經上市的智譜 AI 和 MiniMax 這兩家沒上榜呢？
2. 推論時代
老黃回顧了過去兩三年的幾個代表性時刻：ChatGPT 帶來的 LLM 時代、o1 帶來的 LRM 時代，以及 Claude Code 帶來的 Agentic 時代。推論拐點（Inference Inflection）也相當有意思。未來是否還有 100 倍的成長空間？
這等於宣告整個推論時代已完全到來。接著老黃談到 2026 年的訂單情況，股價隨即直線拉升，但很快又回落，看來高頻程式化交易的影響還是很劇烈。
並預測了整個市場將持續成長。
接著強調 NVL72 和 nvfp4 這些從 Blackwell 帶來的變革，以及針對推論的優化：功耗降低、效能增長，以及推論成本快速下降。
在推論速度方面，下圖似乎有點問題？模型用了 Kimi K2.5，但排名卻在最後幾名……這有什麼含意？難道是在證明先進的顯示卡真的沒有出口到中國？
然後再次強調 AI Factory 的概念。
3. 硬體
老黃用一段影片從最早的 DGX 開始介紹，回顧過去十年的發展：Volta、Ampere、Hopper、Blackwell，以此作為本節開場。接著 Rubin 這一代的全貌也終於揭曉，而 Groq 3 LPU 成為這次發布的重點。
接著老黃展示了 Groq 3 LPU 運算托盤（Compute Tray）、NVL6 交換機托盤（Switch Tray）、Rubin 運算托盤。
關於 Groq 3 LPU 稍後會詳細介紹。接下來是 CX9+Vera 構成的 BF4 儲存伺服器、Vera CPU 托盤、CPO 交換機。
先來談談伺服器。原本宣傳的是 CX9 與 Grace 合封構成一顆 DPU，但實物展示的卻是 CX9 與獨立的 Grace 晶片。最近由於儲存密度需求，以及 Grace PCIe Lane 不足，改用 CX9 與 Vera CPU 搭配構建。其實這種情境與使用一般 x86 CPU + CX9 有什麼不同呢？而且 Nvidia 在儲存領域的積累還是太少，對於 DPU 如何支撐好儲存應用，還有很多地方沒搞明白。
然後是用於 Agentic 工作負載的 Vera Compute Tray。單個 Vera Compute Tray 整合了 8 顆 Vera 處理器，每顆處理器 88 核心，同時支援 8 通道 LPDDR5x 記憶體，單 Socket 支援 1.2TB/s 的記憶體頻寬。Compute Tray 上整合了 2 塊 BF4-DPU。
關於 CPO Switch 的話題，我們稍後分析。
另一個有趣的話題是，老黃認為基於 CableTray 和液冷的這套 Orben 機櫃結構對快速部署很有幫助，因此又提供了一個 Ethernet 256 版本。猜測是將 Switch Tray 換成乙太網路交換機，整個機櫃支援 32 個 Vera Compute Tray，並支援 256 顆 CPU 連接到整個 Rack 上。技術上估計仍使用 BF4 DPU，然後透過 CableTray 連接，可能使用了 CX8/CX9 引入的多平面技術，即一個 CX9 800Gbps 連接埠拆分為 8 個 112G 連接埠，連接到 8 個 Switch Tray 上。透過相對成熟的 Orben 機櫃結構（前後的圖還是不一致，這時老黃展示的機櫃只有 2 個 Switch Tray，但後面的 Roadmap 頁面展示的是 8 個），避免複雜的光纖連線，也能降低光模組帶來的功耗。
注意，這個 ETH256 只是標準乙太網路透過 CableTray 連接的前端網路。
下圖左側是支援 Vera CPU 的 Orben ETH256 機櫃結構，上下各 16 個 Vera Compute Tray。右側是 BF4 儲存的 Orben 機櫃，應該沒有背板的 CableTray，至少在儲存伺服器上沒看到背板有連接器，只有供電介面。
接著繼續發布 Rubin Ultra 和 Kyber Rack 的 Midplane。
但看到 Rubin Ultra 的 Die Size 似乎與宣傳的不一致。兩塊板都屬於一個展示版本，可以看到 Compute Tray 上有 4 顆 Rubin Ultra 和 2 顆 Vera CPU，以及 4 顆 CX9 和一塊 BF4 的 DPU，並配置了 4 塊 NVMe 硬碟插槽。
Compute Tray 是豎直放置，並連接到 Kyber 的中背板。仔細看了一下，可以放置 18 個 Compute Tray。
最後是交換背板，它也是垂直放置，並沒有出現正交的無中背板架構。
主要原因是在這一代上，考量到原本的 CableTray 布線距離太長，因此採用中背板結構構建 Shuffle 線路，將前面板 18 個 Compute Tray 的 Serdes 分組連接到後面板的不同插槽內。
然後是 Rubin NVL72 帶來的效能增長，以及從電力約束下帶來的營收增長，繼續為 Rubin 帶貨。
接著從功耗降低以及推論速度的需求，推導出 Groq 的收購，以及基於 Groq 3 LPX 帶來的營收增長。可以看到同樣的功耗下，Vera-Rubin + Groq 3 LPX 還可以相對 Rubin 提升 1 倍的能效。
然後是關於 Rubin Prefill、Groq 3 Decode 的方案。單顆 Groq 3 LPU 的 SRAM 增加到了 500MB，同時頻寬增加到了 150TB/s。
Groq 的詳細架構分析可以參考《談談那個被 NV 看上值 20B 的 Groq》。詳細分析 Prefill 和 Decode 的負載：Prefill 是計算密集型（Compute Bound）和記憶體容量密集型（Memory Capacity Bound），而 Decode 是記憶體頻寬密集型（Memory Bandwidth Bound）的應用。因此某種程度上需要對 Decode 的記憶體頻寬進一步加大。單個 Groq 3 LPU SRAM 容量增加到了 500MB（第一代為 220MB），頻寬也從第一代的 80TB/s 增加到了 150TB/s。但這一代僅支援 FP8。接下來 NV 會推出一款 Groq L35 來支援 nvfp4。
然後老黃對比了 Rubin GPU 和 8 顆 Groq 3 LPU 構成的 Compute Tray，可以明顯看到這種趨勢。在 Prefill 節點支援更高的算力和更多的記憶體容量，而在 Decode 節點則更多是提升記憶體頻寬。
另外我們注意到原本的 Rubin CPX 方案似乎被取消了，猜測大概是 DDR 的價格漲得太恐怖，而且 Rubin CPX 方案 1:1 配比本來就有不少問題。具體分析可以參考《詳細分析一下 Nvidia Rubin CPX》。其實我們可以詳細分析一下 Agentic LLM 的負載，由於 Context 通常超過 200K，未來進一步還會到 1M，對於 KVCache 的搬運需要更大的頻寬，基於 PCIe 的 Rubin CPX 可能有些力不從心。
比較有趣的是，針對 PD 分離的同時，如何使用 Groq，老黃這裡畫出的是 AFD。繼續用 Rubin 做 Attention，而 Groq 3 LPU 只做 FFN。其實這裡有幾個問題經不起推敲。首先它把 EP 的流量跨機櫃傳輸，用的是什麼網路？如果是 ScaleOut，但在 LPX 的 Compute Tray 上只有一顆 BF4。另一個問題是 Groq 確定性執行如何支援 MoE？如果 Rubin Attn 節點算好 MoE Gate Index 後，將 index 寫入資料包只發送一份到整個 LPX 機櫃，然後在機櫃內部做 dispatch 和 combine，跨機櫃互連的頻寬就小了。或者在 Groq 內部做一些 mask 處理不參與計算的 Expert？另一方面從 Rubin 上 dispatch，然後逐個 token 直接送入到對應的 LPU 做 FFN，透過 LPU 的對外 I/O 的 buffer 緩存一部分未計算的 token，算完後再 Combine。這樣對於兩個機櫃的互連頻寬要求更高，似乎又沒有互連的 ScaleUP，畢竟兩者是不同的協議（LPU C2C 和 NVLink）。
還有一個問題是對於一些超過 1T 的模型，單個 LPX 機櫃 256 顆 LPU 累計的 SRAM 容量僅 128GB，似乎也放不下這些專家的參數（目前 Groq 3 僅支援 FP8），所以整個 AFD 的方案實際上是經不起推敲的。不知道 NV 是如何解決這些問題的。
Groq 3 LPX 的 Compute Tray 結構如下，可以看到它還是延續了原來的 LPU C2C 介面，並沒有採用 NVLink，也沒有相應的交換晶片，可能未來會有向 NVLink 轉換的一個過程。
最後再次展示了一下全家福，並透露 Rubin 已經點亮並交付給微軟在測試了。
然後老黃再一次強調了儲存的重要性，從傳統人類使用 CuDF/CuVS 轉換到 AI 使用儲存，並包括新的 KVCache 需求。AI 對於這些處理的速度要求會更高，因此對於儲存的需求也會更強烈。
接下來談論了一些 Roadmap。
在 Rubin 這一代，會很快配合 Rubin Ultra 推出支援 NVFP4 的 Groq 3.5 (LP35)。然後 CX9 上還是在誤導，明明是一顆 800Gbps 的 ASIC 非要寫成 1.6Tbps。比較大的一個變化是，老黃還是念念不忘他的 NVL576，在 Oberon 機框上會將 8 個機櫃並聯支援。不過這樣就需要 NVLink 支援光互連了，可靠性的問題是如何解決的？整個故障域加大後整機的 MTBF 下降是如何處理的？實際上在工程上還有很多挑戰。然後關於支援 ETH256 的互連，再次強調一下，它只是利用 CableTray 來連接 Vera CPU 的，此時是一個標準的 800Gbps Ethernet，並不是國內常見的 ETH-ScaleUP。
同樣在 Kyber 這一代 ScaleUP 上，也會支援 8 並櫃的互連，也挺值得期待他們是如何解決光的可靠性問題的，難道是華為 UB 幾千卡的 ScaleUP 壓力也傳導給老黃了？
然後是關於 Feynman 這一代，明確了 Feynman 採用 3D 堆疊，但並不是堆疊 Groq LPU，而更大程度是在堆疊客製化的 HBM。然後這一代的 LPU 會從 LPU C2C 切換到 NVLink，同時值得一提的是這一代會全面支援 CPO 光互連的 ScaleUP 和 ScaleOut。然後 CX10 和 BF5 也被排到了 2028 年。
關於 CPO 的判斷和我前面的詳細分析基本一致，具體可以參考《談談光互連的一些問題》。
最後針對地球電力不夠，也在說正在研究太空中的抗輻射 Vera Rubin 架構。
4. Agentic Computing
接著老黃也開始談論龍蝦，以養龍蝦開場。
然後開始介紹 Agentic Computing，它和 Linux、HTTP、HTML 一樣帶來了大量的變革。這一點也聽獻濤（JVS Claw 負責人，阿里雲終端智能計算事業部總裁）講述過，他作為一個做了二十多年 Linux 內核的技術老兵，對 OpenClaw 的判斷非常準確。並且從 OpenClaw 發布時他就關注龍蝦的安全執行和做原生的交互體驗。並且最近發布了 JVS Claw 《想安全簡潔的養蝦嗎？選擇 JVS Claw 吧》。而我們注意到老黃的判斷和 NemoClaw 的整個思路和 JVS Claw 基本是一致的，同樣強調安全和易部署的能力，並且以 Agent 為中心構建整個生態。
接著老黃宣告了整個企業 IT 從 SaaS 到 Agent-as-a-Service 的轉變，是不是要給 SaaS 判死刑了？
然後開始介紹了一些 Nvidia 的開源模型和相應的合作夥伴等。
5. Robotics & Physical AI
自動駕駛方面，BYD、吉利、現代、尼桑等廠家加入 RoboTaxi，並且和 Uber 合作。然後機器人方面 KUKA、FANUC、ABB 等廠商，還有很多機器人/無人機平台等。然後就是與之配套的整個軟硬體平台，包括模擬/模擬等。再一次強調了 GB300 進行訓練，RTX6000 進行模擬，Thor 在終端執行的硬體堆疊。
最後的彩蛋是結尾那個總結 MV，歌寫得很好聽，歌詞也很有趣，值得去聽一下。
參考資料
[1] GTC 2026 Keynote: https://www.youtube.com/watch?v=jw_o0xr8MWU&t=4438s