英偉達最強GPU：B200詳解解讀

公眾號記得加星標??，第一時間看推送不會錯過。

自GPU成為主流以來，英偉達一直主導著GPU計算領域。該公司推出的Blackwell B200 GPU有望成為新一代的頂級計算GPU。與前幾代產品不同，Blackwell無法像以往那樣依靠制程節點的改進。臺積電的4NP制程可能比上一代Hopper所使用的4N制程有所提升，但不太可能像之前的全節點縮小那樣帶來顯著的性能提升。

因此，Blackwell放棄了英偉達久經考驗的單芯片設計，轉而采用兩個光罩大小的芯片。這兩個芯片在軟件層面被視為一個獨立的GPU，這使得B200成為英偉達首款芯片級GPU。每個B200芯片物理上包含80個流式多處理器（SM），類似于CPU的核心。B200每個芯片支持74個SM，因此整個GPU共有148個SM。時鐘頻率與 H100 的高功率 SXM5 版本相似。

我在上表中列出了 H100 SXM5 的規格，但除非另有說明，下文中的數據將來自 H100 PCIe 版本。

緩存和內存訪問

B200 的緩存層級結構與 H100 和 A100 非常相似。L1 緩存和共享內存均從同一個 SM 私有池中分配。L1 緩存/共享內存的容量與 H100 相同，仍為 256 KB。L1 緩存/共享內存的分配比例也未改變。共享內存類似于 AMD 的本地數據共享 (LDS) 或 Intel 的共享本地內存 (SLM)，它為一組線程提供軟件管理的片上本地存儲。開發者可以通過 Nvidia 的 CUDA API 來設置 L1 緩存的分配比例，例如：分配更大的 L1 緩存、分配相等的 L1 緩存或分配更多的共享內存。這些選項分別對應 216 KB、112 KB 和 16 KB 的 L1 緩存容量。

在其他 API 中，共享內存和 L1 緩存的分配完全取決于 Nvidia 的驅動程序。OpenCL 獲得了最大的 216 KB 數據緩存分配，而其內核未使用共享內存，這相當合理。Vulkan 獲得的 L1 緩存分配略小，為 180 KB。經測試，OpenCL 中數組索引的 L1 緩存延遲僅為 19.6 納秒，即 39 個時鐘周期。

與 A100 和 H100 一樣，B200 也采用了分區式 L2 緩存。然而，其容量大幅提升，總容量達到 126 MB。作為對比，H100 的 L2 緩存容量為 50 MB，A100 為 40 MB。直接連接到同一 L2 分區的延遲與前幾代產品類似，約為 150 納秒。當測試數據超出分區范圍時，延遲會顯著增加。B200 的跨分區延遲比其前代產品略高，但提升幅度不大。B200 上的 L2 分區幾乎可以肯定對應于其兩個芯片。如果是這樣，跨芯片的延遲增加很小，而且單個 L2 分區的容量就超過了 H100 的整個 L2 緩存容量，因此可以忽略不計。

從單線程的角度來看，B200 的表現就像采用了三級緩存架構。L2 緩存的分區特性可以通過將指針追蹤數組分段，并讓不同的線程遍歷每個段來體現。奇怪的是，我需要大量的線程才能訪問大部分 126 MB 的容量而不產生跨分區性能損失。或許 Nvidia 的調度器會先嘗試填充一個分區的 SM（流式多處理器），然后再訪問另一個分區。

AMD 的 Radeon Instinct MI300X 采用真正的三級緩存架構，與 B200 系列顯卡不相上下。Nvidia 的 L1 緩存容量更大、速度更快。AMD 的 L2 緩存犧牲了部分容量，換取了比 Nvidia 更低的延遲。最后，AMD 的 256 MB 末級緩存實現了低延遲和高容量的完美結合，其延遲甚至低于 Nvidia 的“遠端”L2 分區。

一個有趣的現象是，當多個線程訪問分段指針追蹤數組時，MI300X 和 B200 在末級緩存 (TLB) 上的延遲都更加均勻。然而，造成延遲增加的原因卻不盡相同。AMD 平臺上超過 64MB 后的延遲增加似乎是由 TLB 未命中引起的，因為使用 4KB 步長進行測試時，在同一位置也出現了延遲增加。啟動更多線程會增加 TLB 實例的參與度，從而減輕地址轉換的懲罰。消除 TLB 未命中懲罰也降低了 MI300X 的 VRAM 延遲。而對于 B200 來說，拆分數組并沒有降低 VRAM 延遲，這表明 TLB 未命中要么在單線程情況下并非主要因素，要么增加線程數并沒有減少 TLB 未命中。因此，B200 的 VRAM 延遲似乎高于 MI300X 以及更早的 H100 和 A100。與 L2 跨分區懲罰一樣，與 H100/A100 相比，延遲回歸的程度并不嚴重，這表明英偉達的多芯片設計運行良好。

OpenCL 的本地內存空間由英偉達的共享內存 (Shared Memory)、AMD 的 LDS 或英特爾的 SLM 提供支持。使用陣列訪問測試本地內存延遲表明，B200 延續了其在共享內存延遲方面的出色表現。其訪問速度比我迄今為止測試過的任何 AMD GPU 都要快，包括 RDNA 系列的高頻型號。AMD 基于 CDNA 架構的 GPU 的本地內存延遲則要高得多。

原子操作可用于在同一工作組內的線程之間交換數據。在Nvidia平臺上，這意味著運行在同一SM上的線程之間交換數據。使用atomic_cmpxchg在線程間快速傳遞數據，其延遲與AMD的MI300X相當。與指針追蹤延遲一樣，B200相比前幾代產品僅有小幅改進。與大型計算GPU相比，AMD的RDNA系列在此項測試中表現出色。

現代GPU使用專用的原子ALU來處理原子加法和遞增等操作。使用atomic_add進行測試，B200的每個SM每個周期可以執行32次操作。這個測試是在MI300X測試結束后編寫的，所以我只有MI300A的數據。與GCN架構類似，AMD的CDNA3計算單元每個周期可以執行16次原子加法。這使得B200盡管核心數量較少，卻依然能夠勝出。

帶寬測量

更高的SM單元數量使B200的L1緩存帶寬比其前代產品有了顯著優勢。在OpenCL測試中，它的性能也趕上了AMD的MI300X。而像RX 6900XT這樣較老、尺寸較小的消費級GPU則被遠遠甩在了后面。

在B200平臺上，本地內存和L1緩存的帶寬相同，因為它們都基于同一塊存儲介質。這使得AMD的MI300X在帶寬方面擁有巨大的優勢。本地內存更難充分利用，因為開發者必須顯式地管理數據移動，而緩存則能自動利用局部性。但即便如此，MI300X在這一領域依然保持領先地位。

Nemez 基于 Vulkan 的基準測試可以大致反映 B200 的 L2 帶寬情況。本地 L2 分區內較小的數據量可以達到 21 TB/s 的帶寬。當數據開始在兩個分區之間傳輸時，帶寬會下降到 16.8 TB/s。AMD 的 MI300X 不支持圖形 API，也無法運行 Vulkan 計算。不過，AMD 指出其 256 MB 的 Infinity Cache 可以提供 14.7 TB/s 的帶寬。MI300X 不需要從 Infinity Cache 獲得如此高的帶寬，因為其前面的 4 MB L2 實例應該可以吸收大部分 L1 緩存未命中流量。

與上一代 H100 相比，B200 在緩存層次結構的各個層級都擁有顯著的帶寬優勢。得益于 HBM3E，B200 的顯存帶寬也優于 MI300X。雖然 MI300X 也配備了八個 HBM 堆棧，但它使用的是較老的 HBM3，最高帶寬僅為 5.3 TB/s。

全局內存原子

（Global Memory Atomics）

AMD 的 MI300X 在使用 atomic_cmpxchg 在線程間切換數值時表現出不同的延遲。其復雜的多芯片結構可能是造成這種現象的原因。B200 也存在同樣的問題。在這里，我啟動了與 GPU 核心（SM 或 CU）數量相同的單線程工作組，并選擇不同的線程對進行測試。我使用的訪問模式類似于 CPU 端核心間延遲測試，但無法控制每個線程的放置位置。因此，這并非一個標準的 CPU 端核心間延遲測試，且不同運行的結果并不一致。但這足以展示延遲的變化，并表明 B200 具有雙峰延遲分布。

在理想情況下，延遲為 90-100 納秒，這很可能是因為線程位于同一個 L2 分區上。在較差的情況下，延遲則在 190-220 納秒之間，這很可能是因為通信跨越了 L2 分區邊界。AMD MI300X 的測試結果在 116 納秒到 202 納秒之間。B200 在理想情況下的性能略優于 AMD，但在較差情況下的性能則略遜一籌。

與RX 6900XT等高頻消費級GPU相比，數據中心GPU的線程間延遲通常更高。即使在最佳情況下，在擁有數百個SM或CU的GPU之間交換數據也是一項挑戰。

全局內存上的原子操作通常由GPU共享緩存級別的專用ALU處理。Nvidia的B200芯片每個周期可以支持GPU上近512次此類操作。AMD的MI300A芯片在這項測試中表現不佳，吞吐量甚至低于面向消費者的RX 6900XT。

計算吞吐量

SM 數量的增加使得 B200 在大多數向量運算中擁有比 H100 更高的計算吞吐量。然而，FP16 運算是個例外。Nvidia 的舊款 GPU 可以以 FP32 兩倍的速度執行 FP16 運算，而 B200 則不能。

AMD 的 MI300X 也能進行雙倍速率的 FP16 計算。英偉達可能決定將 FP16 計算的重點放在 Tensor Core（矩陣乘法單元）上。總的來說，MI300X 的強大運算能力在大多數向量運算方面都遠超 H100 和 B200。盡管采用了較舊的制程工藝，AMD 激進的芯片組架構仍然具有優勢。

張量內存

B200 的目標應用是人工智能，因此，如果不提及它的機器學習優化，討論就不完整。英偉達早在圖靈/伏特架構時代就開始使用張量核心（Tensor Core），也就是專用的矩陣乘法單元。GPU 提供了一種 SIMT 編程模型，開發者可以將每個通道視為一個獨立的線程，至少從正確性的角度來看是如此。張量核心打破了 SIMT 的抽象，要求矩陣在一個波（或向量）上采用特定的布局。Blackwell 的第五代張量核心更進一步，允許矩陣在一個工作組（CTA）中跨越多個波。

Blackwell 還引入了張量內存（Tensor Memory，簡稱 TMEM）。TMEM 類似于專用于張量核心（Tensor Core）的寄存器文件。開發人員可以將矩陣數據存儲在 TMEM 中，Blackwell 的工作組級矩陣乘法指令使用 TMEM 而非寄存器文件。TMEM 的組織結構為 512 列 x 128 行，每個單元格為 32 位。每個波形只能訪問 32 行 TMEM 數據，具體行數由其波形索引決定。這意味著每個 SM 子分區都有一個 512 列 x 32 行的 TMEM 分區。“張量核心收集器緩沖區”（TensorCore Collector Buffer）可以利用矩陣數據重用，充當 TMEM 的寄存器重用緩存。

因此，TMEM 的工作方式類似于 AMD CDNA 架構上的累加器寄存器文件 (Acc VGPR)。CDNA 的 MFMA 矩陣指令同樣操作 Acc VGPR 中的數據，但 MFMA 也可以從常規 VGPR 中獲取源矩陣。在 Blackwell 架構上，只有較早的波形級矩陣乘法指令才接受常規寄存器輸入。TMEM 和 CDNA 的 Acc VGPR 容量均為 64 KB，因此兩種架構的每個執行單元分區都擁有 64+64 KB 的寄存器文件。常規向量執行單元無法從 Nvidia 的 TMEM 或 AMD 的 Acc VGPR 中獲取輸入。

盡管 Blackwell 的 TMEM 和 CDNA 的 Acc VGPR 在總體目標上相似，但 TMEM 對分離式寄存器文件理念的實現更加完善和成熟。CDNA 必須為每個 wave 分配相同數量的 Acc 和常規 VGPR。這樣做可能簡化了簿記，但卻造成了一種不靈活的安排，即混合使用矩陣波和非矩陣波會導致寄存器文件容量的低效利用。相比之下，TMEM 使用了一種動態分配方案，其原理類似于 AMD RDNA4 上的動態 VGPR 分配。每個 wave 開始時都沒有分配 TMEM，并且可以分配 32 到 512 列（以 2 的冪次方為單位）。所有行同時分配，并且 wave 必須在退出前顯式釋放已分配的 TMEM。TMEM 還可以從共享內存或常規寄存器文件加載，而 CDNA 的 Acc VGPR 只能通過常規 VGPR 加載。最后，TMEM 可以在加載數據時選擇性地將 4 位或 6 位數據類型“解壓縮”為 8 位。

與之前的英偉達架構相比，引入 TMEM 有助于降低常規寄存器文件的容量和帶寬壓力。引入 TMEM 可能比擴展常規寄存器文件更容易。Blackwell 的 CTA 級矩陣指令每個周期、每個分區可以支持 1024 次 16 位 MAC 操作。由于矩陣輸入始終來自共享內存，TMEM 每個周期只需讀取一行并將其累加到另一行。而常規向量寄存器對于 FMA 指令則需要每個周期進行三次讀取和一次寫入。此外，TMEM 無需連接到向量單元。所有這些特性使得 Blackwell 能夠像擁有更大的寄存器文件一樣運行，從而簡化硬件。自 2012 年 Kepler 架構以來，英偉達一直使用 64 KB 的寄存器文件，因此增加寄存器文件容量似乎勢在必行。TMEM 在某種程度上實現了這一點。

AMD方面，CDNA2放棄了專用的Acc VGPR，并將所有VGPR合并到一個統一的128KB寄存器池中。采用更大的統一寄存器池可以使更廣泛的應用程序受益，但代價是無法簡化某些硬件。

一些簡單的基準測試

數據中心級GPU歷來擁有強大的FP64性能，B200也不例外。其基本FP64運算速度僅為FP32的一半，遠超消費級GPU。在我們自行編寫的基準測試中，B200的表現依然優于消費級GPU和H100。然而，即便MI300X是一款即將停產的GPU，其龐大的體積依然顯露無疑。

在上述工作負載中，我使用一個 2360x2250 的 FITS 文件（包含列密度值）并輸出相同尺寸的引力勢值。因此，數據量為 85 MB。即使沒有性能計數器數據，也可以合理地假設它能夠放入 MI300X 和 B200 的末級緩存中。

FluidX3D 的情況則有所不同。它的基準測試采用 256x256x256 的單元配置，FP32 模式下每個單元占用 93 字節，因此需要 1.5 GB 的內存。根據在 Strix Halo 顯卡上使用性能計數器進行的測試，它的訪問模式對緩存并不友好。FluidX3D 充分發揮了 B200 的顯存帶寬優勢，目前 B200 的性能已經超越了 MI300X。

FluidX3D 還可以使用 16 位浮點格式進行存儲，從而降低內存容量和帶寬需求。計算仍然使用 FP32，格式轉換需要額外的計算資源，因此 FP16 格式可以帶來更高的計算帶寬比。這通常會提升性能，因為 FluidX3D 的性能很大程度上受限于帶寬。當使用 IEEE FP16 進行存儲時，AMD 的 MI300A 略有進步，但仍然遠勝于 B200。

另一種 FP16C 格式降低了使用 16 位存儲格式帶來的精度損失。它是一種無需硬件支持的自定義浮點格式，這進一步提高了計算帶寬比。

計算能力再次成為焦點，AMD 的 MI300A 脫穎而出。B200 的表現也不錯，但它無法與 AMD 大型芯片 GPU 所提供的強大計算吞吐量相媲美

Teething Issues

在數周的測試中，我們遇到了三次 GPU 掛起問題。問題表現為 GPU 進程卡死。隨后，任何嘗試使用系統八個 GPU 中任何一個的進程都會掛起。即使使用 SIGKILL 信號也無法終止任何掛起的進程。將 GDB 附加到其中一個進程也會導致 GDB 凍結。系統對僅使用 CPU 的應用程序保持響應，但只有重啟系統才能恢復 GPU 功能。nvidia-smi 進程也會掛起。內核消息顯示，Nvidia 統一內存內核模塊（nvidia_uvm）在禁用搶占的情況下獲取了鎖。

堆棧跟蹤信息表明，Nvidia 可能正在嘗試釋放已分配的虛擬內存，或許是在 GPU 上。獲取鎖是合理的，因為 Nvidia 可能不希望其他線程在頁面空閑列表被修改時訪問它。至于為什么它始終無法離開臨界區，原因尚不清楚。或許它向 GPU 發出了請求但從未收到響應。又或許這純粹是主機端的一個軟件死鎖 bug。

# nvidia-smi -r

The following GPUs could not be reset:

GPU 00000000:03:00.0: In use by another client

GPU 00000000:04:00.0: In use by another client

GPU 00000000:05:00.0: In use by another client

GPU 00000000:06:00.0: In use by another client

GPU 00000000:07:00.0: In use by another client

GPU 00000000:08:00.0: In use by another client

GPU 00000000:09:00.0: In use by another client

GPU 00000000:0A:00.0: In use by another client

出現這種系統卡死的情況并不令人意外。硬件加速增加了系統的復雜性，也就意味著更多的故障點。但現代硬件架構已經發展到無需重啟即可處理GPU問題。例如，Windows的超時檢測與恢復（TDR）機制可以請求驅動程序重置卡死的GPU。nvidia-smi確實提供了重置選項。但令人沮喪的是，如果GPU正在使用中，該選項就無法生效。這完全違背了提供重置選項的初衷。我希望Nvidia能夠隨著時間的推移解決這些問題，尤其是在根本原因完全在于軟件或固件的情況下。但在如此短的時間內多次遇到此類問題并非好兆頭，如果Nvidia能夠提供無需重啟系統即可解決此類問題的方法，那就更好了。

結語

英偉達在芯片組升級方面并未做出重大性能妥協。B200 是 H100 和 A100 的直接繼任者，軟件無需考慮多芯片架構。與 AMD 的 MI300X（12 芯片怪獸）相比，英偉達的多芯片策略顯得較為保守。盡管 MI300X 已是即將停產的產品，但它仍然保留了一些令人驚喜的優勢，優于英偉達最新的 GPU。AMD 即將推出的數據中心 GPU 很可能也會保持這些優勢，同時在 B200 已經領先一些的領域迎頭趕上。例如，MI350X 將把顯存帶寬提升至 8 TB/s。

但英偉達的保守策略是可以理解的。他們的優勢不在于打造市面上最強大、性能最卓越的GPU，而在于其CUDA軟件生態系統。GPU計算代碼通常首先針對英偉達GPU編寫，而對非英偉達GPU的考慮則往往是次要的，甚至根本不會考慮。硬件如果沒有相應的軟件運行，就毫無用處，而快速移植也無法獲得同等程度的優化。英偉達無需在所有方面都與MI300X或其后續產品匹敵，他們只需要足夠優秀，足以阻止競爭對手填補CUDA的“護城河”即可。試圖打造一款能夠與MI300X匹敵的“怪物”風險極大，而英偉達在占據市場主導地位的情況下，完全有理由規避風險。

盡管如此，英偉達的策略也給AMD留下了機會。AMD如果敢于冒險、追求卓越，必將獲益匪淺。像MI300X這樣的GPU堪稱硬件工程的杰作，充分展現了AMD實現高難度設計目標的能力。英偉達保守的硬件策略和強大的軟件實力能否使其繼續保持領先地位，值得我們拭目以待。

https://chipsandcheese.com/p/nvidias-b200-keeping-the-cuda-juggernaut

（來源：編譯自chipsandcheese）

*免責聲明：本文由作者原創。文章內容系作者個人觀點，半導體行業觀察轉載僅為了傳達一種不同的觀點，不代表半導體行業觀察對該觀點贊同或支持，如果有任何異議，歡迎聯系半導體行業觀察。

今天是《半導體行業觀察》為您分享的第4260期內容，歡迎關注。

加星標??第一時間看推送，小號防走丟

求推薦