由淺入深了解NVIDIA全系列產品（二）: NVIDIA 的五種晶片：每一顆都在解決不同的問題

這個系列的 overview 文章說過，現代 AI 伺服器裡住著五種晶片。

很多人記住的是 GPU。但 GPU 算得再快，如果其他環節跟不上，整個系統還是會卡。這篇文章就是要把這五顆晶片一個一個拆開來看——它們各自在解決什麼問題、NVIDIA 為什麼要自己做、做出來之後差在哪裡。

---

CPU（Vera）：AI 的手，不是 AI 的腦

大部分人談 NVIDIA 的晶片，直接跳到 GPU。CPU 是配角，是「那個管雜事的」。

但 Jensen 在 GTC 說了一件讓很多人意外的事：Vera CPU 已經是 NVIDIA 的 multi-billion dollar standalone 業務。

「我們從來沒想過會賣獨立的 CPU。」

這句話值得停下來想一下。

AI 越強，CPU 反而越重要

直覺上，AI 越來越強，GPU 的地位越來越重要，CPU 應該被邊緣化才對。

但現在的 AI 不是只會回答問題——它開始使用工具。

一個 AI agent 要完成任務，可能要查資料庫、執行程式碼、呼叫 API、操作瀏覽器。每一個工具呼叫都要有一個環境去執行，而這個環境跑在 CPU 上。問題在於，AI 等待工具的方式和人不一樣。人等網頁載入三秒，沒感覺。AI 在等的時候什麼都做不了——工具的速度直接影響整個 agent 的效率。一個資料中心可能有幾千個 agent 同時在跑。

所以 CPU 的需求沒有消失，而是換了形狀：從通用計算，變成 agentic AI 的執行基礎設施。

為什麼不繼續用別人的核心

之前 NVIDIA 用的是 Grace CPU——72 個 ARM Neoverse V2 核心。Neoverse V2 是 ARM 授權出去的現成設計，Amazon、Google、Microsoft 也都在用。Grace 是個好 CPU，但它的設計目標是「和 GPU 一起跑 HPC 和 AI 訓練」，不是「讓 agent 工具呼叫飛快」。

Vera 是從零設計的。核心架構換成 NVIDIA 完全自研的 Olympus 核心，88 個，保持 ARMv9.2-A 指令集相容（軟體生態不用重寫），但內部全部重來。

自研的動機有三層：

第一，工作負載太特殊，現成的核心對不上。 Agentic AI 需要的是極強的單核心效能——編譯程式碼、跑腳本、排程工具呼叫，這些都是序列任務，沒辦法平行分散到幾千個核心上。Olympus 有 10-wide 的指令解碼前端加上神經分支預測器，專門為這類高 I/O、對延遲敏感的工作最佳化。

第二，要消除效能的不可預測性。 傳統 SMT（同步多執行緒）讓多個執行緒輪流共享核心資源，切換時會互相干擾，效能會抖動。Vera 用的是 NVIDIA 自創的 Spatial Multithreading（空間多執行緒）——把核心內的執行單元、快取、暫存器直接在實體上分割，兩個執行緒各拿各的，真正並行。對需要同時跑幾千個 agent 的資料中心來說，效能的可預測性和穩定性跟峰值效能一樣重要。

第三，財務和護城河。 授權別人設計好的核心，權利金比只拿 ISA 授權貴很多。自研之後，NVIDIA 可以把 Vera CPU 單獨賣——這是以前用現成核心做不到的事，因為沒有差異化。

規格上的差距

幾個關鍵數字，看 Grace 到 Vera 的跳幅：

	Grace	Vera
核心數	72（Neoverse V2）	88（Olympus）
執行緒	72	176（Spatial SMT）
記憶體頻寬	512 GB/s	1.2 TB/s
最大記憶體	480 GB	1.5 TB
L2 快取（每核）	1 MB	2 MB
L3 快取	114 MB	162 MB
NVLink-C2C 頻寬	900 GB/s	1.8 TB/s
PCIe 版本	Gen 5	Gen 6 + CXL 3.1

記憶體頻寬翻倍以上，這是 Vera 最核心的升級。記憶體用的是 LPDDR5X——這是手機等行動裝置常用的低功耗高頻寬規格，NVIDIA 把它搬進資料中心，主要目的是拿到更高能效比，而不是追求最大容量。

把這些核心黏在一起的是第二代 SCF（Scalable Coherency Fabric），一套內部網格網路，提供 3.4 TB/s 的對分頻寬。它的設計目標是：不管幾顆核心同時在跑，每顆核心存取記憶體的延遲都一樣低、頻寬都一樣高。消除 x86 多晶片架構常見的 NUMA 瓶頸，讓效能可以線性擴展。整體 performance per watt 比同類 x86 高出 2 倍。

Vera CPU Rack

訓練 AI 靠 GPU，推論靠 GPU 和 LPU，那為甚麼NVIDIA要開始賣獨立的 CPU rack，用來做什麼？

答案藏在強化學習的工作流程裡。

用強化學習訓練 AI 寫程式，流程大概是這樣：GPU 生成一段程式碼 → 必須有人實際把這段程式碼編譯、執行、測試、回傳結果給 AI，告訴它「對或不對」→ GPU 根據結果更新模型。

這個「編譯、執行、測試」的環節跑在 CPU 上，叫做 sandbox（沙盒）。GPU 生成的速度越快，需要的 sandbox 就越多——不然 GPU 算完了，結果還在排隊等 CPU 測試，整條流水線卡住。

一個 Vera CPU Rack 可以同時跑超過 22,500 個獨立的 sandbox 環境。GPU Rack 裡只有 36 顆 Vera CPU，負責協調工作，不夠用來跑這麼大量的沙盒。所以要獨立部署 CPU Rack，和 GPU Rack 並排放，才能讓整座 AI 工廠維持滿載。

---

GPU（Rubin）：AI 工廠真正的引擎

GPU 是整個系統的核心。所有其他晶片——CPU、DPU、CPX、LPU——都在圍繞著它服務。

但「GPU」這個詞已經說不清楚差距了。從 2022 年的 Hopper 到即將到來的 Rubin Ultra，同樣叫 GPU，算力差了將近 450 倍。要理解這個數字，得從幾個維度拆開來看。

四年的路線圖，每代都在重新定義上限

	Hopper (H100)	Blackwell (GB300)	Rubin (VR200)	Rubin Ultra (VR300)
量產時間	2022–2023	2024–2025	2026	2027
製程	4N	4NP	N3P	N3P
GPU Die 配置	1 顆完整 Die	2 顆 Reticle 大小	2 顆 + 2 顆 I/O chiplet	4 顆 + 2 顆 I/O chiplet
FP4 算力（每顆封裝）	4 PFLOPs*	15 PFLOPs	50 PFLOPs	100 PFLOPs
HBM 記憶體	80GB HBM3	288GB HBM3E	288GB HBM4	1,024GB HBM4E
HBM 頻寬	3.35 TB/s	8 TB/s	13 TB/s	32 TB/s
GPU TDP	700W	1,400W	1,800W	3,600W
封裝	CoWoS-S	CoWoS-L	CoWoS-L	CoWoS-L

Hopper 本身不支援 FP4，此為換算數字

幾個值得注意的趨勢：

算力在加速成長。 H100 到 GB300 是 3.75 倍，GB300 到 VR200 是 3.3 倍，VR200 到 VR300 又是 2 倍。每一代的跳幅都沒有放緩，而且 Rubin Ultra 只比 Rubin 晚一年——NVIDIA 把發布節奏從兩年壓到一年。

記憶體頻寬是另一條核心曲線。 算力再強，讀不到資料就是白搭。HBM 頻寬從 H100 的 3.35 TB/s 到 VR300 的 32 TB/s，漲了近 10 倍。這不是錦上添花，是維持算力利用率的必要條件。

功耗直線上升，但這是刻意的設計選擇。 H100 是 700W，VR300 是 3,600W，五倍。雲端業者願意為此買單，因為算力成長更快——同樣一瓦能產出的 token 比以前多了很多倍。這就是為什麼資料中心的電力需求在過去兩年幾乎翻倍：不是浪費，是在用更多電賺更多錢。

系統規模：從一顆 GPU 到一整座工廠

單顆 GPU 只是起點。真正有意思的是系統規模的數字：

	Blackwell NVL72	Rubin NVL144	Rubin Ultra NVL576
GPU 封裝數	72	72	144
GPU Die 數	144	144	576
整體 FP4 算力	1,100 PFLOPs	3,600 PFLOPs	14,400 PFLOPs
HBM 總容量	20 TB	20 TB	147 TB
HBM 總頻寬	576 TB/s	936 TB/s	4,608 TB/s

從 Blackwell NVL72 到 Rubin Ultra NVL576，整體算力從 1,100 到 14,400 PFLOPs，漲了 13 倍。這個數字放在兩到三年的時間跨度裡，就是老黃在 GTC 說的「token factory 的生產力在快速提升」的具體意義。

---

CPX × LPU：NVIDIA 為推論規劃的兩大升級

先釐清一個很多人混淆的概念：training 和 inference 是兩件完全不同的事。

Training 是讓模型「學習」——把海量資料灌進去，反覆調整參數，最終得到一個有能力回答問題的模型。關鍵在於，training 的資料可以完全平行處理：一批一批切開，同時丟給幾千顆 GPU，誰算完誰回報，最後匯總。GPU 最擅長的就是這種「大量獨立計算同時進行」的工作，所以 training 和 GPU 是天作之合。

Inference 是讓模型「使用」——你問它問題，它回答你。問題在於，inference 沒辦法平行。模型要先讀完你說的所有內容，才能開始回答；回答的每一個字，都要等前一個字生成完才能繼續。這種強烈的順序依賴，讓「堆更多 GPU 平行算」這個解法幾乎沒有用。硬體的設計需求因此完全不同。

GPU 在這兩件事上都能跑，但 inference 其實還可以再拆細。你問 AI 一個問題，它要做兩件事：先「讀懂」你給的所有上下文，再「一個字一個字把答案生出來」。

這兩個階段的計算需求天差地遠。

第一階段叫 prefill——把整份合約、整個程式碼庫、一段長影片全部讀進去，理解脈絡。這個階段計算量極大，需要的是暴力算力，跑得越快越好。

第二階段叫 decode——把答案一個 token 一個 token 生出來。這個階段需要的是極低延遲，用戶在等，每多一毫秒都是體驗損失。

問題在於，這兩個需求是互相矛盾的——針對高吞吐量最佳化的硬體，不一定擅長極低延遲；反之亦然。用同一顆晶片同時兼顧兩件事，必然有所妥協。

NVIDIA 的解法是把這條流水線拆開：prefill 交給 CPX，decode 交給 Groq LPU。

CPX 是什麼

CPX 是 Rubin GPU 的推論特化變體，專門為 prefill 階段設計。

最明顯的差異在記憶體：標準 Rubin GPU 用的是 288GB HBM4，CPX 換成了 128GB GDDR7。HBM 頻寬極高但成本貴，prefill 的工作模式不需要那麼高的頻寬，GDDR7 在這個場景下更划算，也讓 CPX 的成本結構比標準 GPU 低。

算力方面，CPX 有 30 petaFLOPs，比完整的 Rubin GPU 少，但針對 prefill 的計算模式最佳化，處理長上下文的效率比標準 GPU 高出 3 倍。

為什麼現在特別重要

context window 越來越長是一個確定性的趨勢。模型要讀的東西越來越多——整份法律文件、整個 codebase、幾小時的會議記錄。prefill 的計算量隨著 context 長度線性成長，這個瓶頸只會越來越明顯。

CPX 的存在讓資料中心可以針對 prefill 獨立擴容，不需要買一堆標準 GPU 然後只用它們跑 prefill——這對算力資源的配置效率影響很大。

LPU（Groq）：decode 的問題 GPU 解不好

CPX 負責 prefill，但 decode 呢？

decode 的挑戰和 prefill 完全不同。prefill 是算力問題——只要夠多的 FLOP 就能解決。decode 是記憶體頻寬問題——每生成一個 token，模型都要把所有參數重新讀一遍。一個千億參數的模型，光是參數本身就要幾百 GB，每一步都要把這些資料從記憶體搬進計算單元。

GPU 的設計是為了最大化 FLOP，不是最大化記憶體頻寬利用率。在 decode 這個場景，GPU 大部分時間在等記憶體，算力閒置，非常浪費。

NVIDIA 的解法是收購 Groq 的團隊和技術。

Groq 做的晶片叫 LPU（Language Processing Unit），設計哲學和 GPU 截然相反：幾乎沒有快取，全部依賴超大容量的 on-chip SRAM。資料直接住在晶片上，不需要等外部記憶體。這讓它在 decode 場景的延遲極低、頻寬利用率極高。

但 LPU 也有明顯的弱點：on-chip SRAM 很貴，每顆 Groq 晶片只有約 500MB。相比之下，一顆 Rubin GPU 有 288GB HBM4。一個千億參數的模型根本塞不進去，LPU 單獨使用根本沒辦法服務主流模型。

這是 Groq 在被收購前始終打不進主流市場的根本原因。

NVIDIA 的解法是 Disaggregated Inference——用軟體（Dynamo）把 prefill 和 decode 拆到不同的硬體上跑：

• Prefill → Vera Rubin GPU + CPX：算力強、記憶體大，負責讀懂上下文、存 KV cache
• Decode → Groq LPU：on-chip SRAM 超快，負責低延遲 token 生成

兩者透過特殊 Ethernet 模式連接，延遲降低約一半。模型參數放在 GPU 那側，LPU 只需要處理 token 生成的計算，不需要自己存整個模型。

結果是：在最高價值的推論服務場景（需要極低延遲、極高 token 速率的 coding assistant 或 agent），整體吞吐量比純 Vera Rubin 系統高出 35 倍。

Jensen 的建議是：如果工作負載以高吞吐量為主，100% Vera Rubin 就夠。如果需要極低延遲的高品質 token 生成，在資料中心裡加入約 25% 的 Groq LPU rack，和 Vera Rubin 混合部署。

---

DPU（BlueField）：消除基礎設施稅

如果 CPU 是負責邏輯決策的大腦，GPU 是負責矩陣運算的肌肉，那 DPU 是負責物流和安檢的總管。

它的核心任務只有一個：卸載（offload）。

基礎設施稅是什麼

在傳統伺服器裡，資料透過網路卡進來之後，CPU 必須中斷手邊的工作，親自去處理封包解析、路由、加解密、防火牆規則、儲存定址。在高速網路（400G 或 800G）下，光是處理這些協定，就會吃掉 CPU 30 到 50% 的算力——完全沒有在跑應用，純粹是在處理「讓資料進來」這件事。這就叫基礎設施稅。

CPU 花在這裡的每一個時脈，都是在浪費 GPU 等待的時間。

DPU 不是網路卡，是一顆完整的 SoC

BlueField 內部整合了三個部分：

高速網路介面——BlueField-4 支援最高 800G Ethernet 或 InfiniBand，是資料進出伺服器的物理入口。

多核心 ARM CPU——DPU 有自己的 ARM 核心，跑獨立的 Linux 作業系統，完全和主機的 OS 隔離。即使主機端的系統被攻破，攻擊者也無法從那裡控制網路流向。這是零信任安全架構的硬體基礎。

硬體加速引擎——專門處理資料壓縮、IPsec/TLS 加解密、正則表達式比對、儲存虛擬化的專用電路。這些工作在 DPU 上是硬體加速完成，速度比 CPU 用軟體跑快幾個數量級。

在 Vera Rubin 系統裡的位置

Vera Rubin 世代用的是 BlueField-4，搭配 ConnectX-9（CX9）SuperNIC。CX9 負責實體網路傳輸，BlueField-4 攔截所有進出流量，在資料抵達 CPU/GPU 之前先處理完所有基礎設施工作。

Vera CPU Rack 的配置：256 顆 Vera CPU 搭配 74 個 BlueField-4，讓 CPU 把 100% 的算力留給 AI sandbox。

---

五顆晶片，一條流水線

把這五顆晶片放在一起看，會發現它們的存在邏輯其實很清楚：

AI agent 呼叫工具，等待結果，執行下一步——這是 Vera CPU 的地盤。所有工具呼叫、沙盒環境、序列邏輯，全部跑在這裡。

當 agent 需要推論，問題先丟給 CPX。CPX 把整份上下文一次讀完，存好 KV cache，交棒。

如果不需要極低延遲，接下來的 token 生成繼續留在 Rubin GPU 上跑，高吞吐量。

如果需要毫秒級的回應，token 生成交給 Groq LPU，on-chip SRAM 直接拿資料，不等記憶體。

這一切流量的進出——網路封包、儲存定址、加解密——全部讓 BlueField DPU 在資料進入 CPU/GPU 之前就處理完，CPU 不沾手。

任何一個環節拿掉，都會出現瓶頸。這也是為什麼 NVIDIA 要五個都自己做——不是為了多賣幾顆晶片，而是因為如果某個環節不是它的，它就沒辦法保證整個系統的效能。

但現在有一個問題還沒解決：這五顆晶片講的都是單顆晶片的事。真正的 AI 訓練或推論都需要幾千顆 GPU 同時跑，它們怎麼溝通？

如果用一般的方式傳輸資料，GPU 算完等傳輸、傳完等下一顆算完，整個系統大半時間在等。GPU 再快都沒有意義。

這個問題就是 NVLink 要解決的事。下一篇，我們來看 NVIDIA 怎麼把 72 顆 GPU 串成一顆「感覺不到邊界」的超大計算單元——以及這件事為什麼比買更多 GPU 更重要。