第 3 章 — 面向生成式 AI 的数据中心 GPU

发布于: 2026-04-25 最后更新于: 2026-07-08 版本: 1
第 3 章 — 面向生成式 AI 的数据中心 GPU

第 3 章 — 面向生成式 AI 的数据中心 GPU

LLM Primer VI: Scaling AI Systems》章节走读的第三篇。这一章要说的是:挑一块 serving GPU,该看的是它的 HBM 带宽和 VRAM 容量,而不是数据表正面那个 FLOP/s 数字。


这一章为什么存在

第 1、2 章已经把工作负载摆清楚:prefill 想要矩阵引擎跑满,decoding 想要权重和 KV cache 尽可能快地流过来,而且 KV cache 的占用是乘法级的。硅片选型就是这两副画像撞上市场的地方。2026 年数据中心 GPU 目录是一小组表面看起来很像的显卡 —— 一块加速器、几千个核、一堆封装内内存 —— 但在两个真正决定 decoding 成本的维度上分歧很大:HBM 带宽和 VRAM 容量。第 3 章走一遍今天生产里占主导的这些型号 —— H100、H200、B200、L40S、MI300X —— 给工程师一份靠机制而不是靠 benchmark 图表来挑显卡的判断。

一句话:对 serving 来说,数据表上真正重要的两个数字是 HBM 带宽(权重和 KV 流得多快)和 VRAM(模型能装下多大,还没必要拆到多卡)—— FLOP/s 那个数字主要跟 prefill 有关。

3.1 H100 是安全默认,H200 是给带宽打的补丁

H100 仍然是几乎每一个生产推理 fleet 的主力,除非有特别的理由换到别的东西上。80 GB HBM3、SXM 版 3.35 TB/s 带宽(PCIe 版 2.04 TB/s)、989 BF16 TFLOPs,还有一点很关键 —— tensor core 里原生的 FP8 支持,能把每 token 的权重流量砍半,让 70B 模型装进 70 GB 而不是 140 GB。软件栈成熟,价格也稳了下来。H100 吃紧的地方是容量:80 GB 卡住了 70B FP8 加上 serving batch 的 KV cache,再往上就必须上 tensor 并行。H200 是精准的补丁 —— 同一套 Hopper 算力、同一份 700 W 功耗、但 141 GB HBM3e、4.80 TB/s 带宽。对于任何在 H100 上 HBM 受限的工作负载(几乎每一个 decoding 都是),H200 单从带宽这条就能带来大约 40% 的即插即用吞吐提升,再顺便留出 H100 装不下的 KV cache 余量。

3.2 Blackwell 加了 FP4,把带宽天花板再翻一倍

B200 不是 Hopper 的小改款。192 GB HBM3e、8.00 TB/s 带宽、2250 BF16 TFLOPs,加上第二代 transformer engine 原生支持 tensor core 里的 FP4。相对 FP8,FP4 又把每 token 的权重流量砍半;和裸带宽翻倍加起来,一个在 H100 上单用户 24 token/s decode 的 70B 模型,在 B200 上单用户能舒服地超过 100 token/s,batch 上去后大致线性扩展。192 GB 容量能在一块卡上装下 FP8 的 180B 模型或者 FP16 的 70B 加大量 KV 余量,把 tensor 并行从很多部署里彻底拿掉。代价是价格和 1000 W 的热设计;Blackwell 最明显能回本的,是那些每一个请求都在 H100 上撞带宽或撞容量天花板的工作负载。

3.3 L40S 和 MI300X 是关于工作负载形状的选择

L40S 是 Ada 代那张不需要数据中心档次显卡的替补。48 GB GDDR6、0.86 TB/s 带宽、大概 H100 HBM 吞吐的四分之一 —— 但价格是三分之一,标准 PCIe 形态。对小模型(13B 以下)、对异步批处理、或者对没有数据中心 HGX 机箱可用的边缘部署,L40S 是对的答案,买 H100 反而浪费。AMD MI300X 站在另一头:192 GB HBM3、5.30 TB/s 带宽、OAM 上 1307 BF16 TFLOPs。裸 serving 性能上,它在容量上不输 H200 甚至更好,在带宽受限的 decoding 上大致打平,而单价明显更低。取舍在软件栈 —— ROCm 已经把和 CUDA 的差距补得差不多,但没补齐,那些成熟的 engine(vLLM、TensorRT-LLM、SGLang)在 NVIDIA 上被踩得更实。有 ROCm 能力的团队,MI300X 是省钱那根杠杆;没有的团队,H200 是更稳的买法。

值得记住:读数据表按这个顺序:VRAM(模型装得下吗?)、HBM 带宽(decoding 跑多快?)、FP8/FP4 支持(量化能换回多少?),最后才是 FLOP/s。按反过来那个营销顺序读,买的就是错的卡。

第 3 章为下面铺了什么

把 GPU 数据表从"带宽和 VRAM"这副眼镜重新读过一遍,自然的下一个问题是:通用 GPU 到底是不是对的底座。第 4 章走一遍那些专用硅片的替代选项 —— Groq LPU、AWS Inferentia2、Google TPU v5p 和 v6、Intel Gaudi 3 —— 每一款都在主张 LLM 推理规律到足以支撑一块 purpose-built 的芯片。第 5 章接着走软件侧那个直接压缩每 token 带宽的动作:从 FP16 一路量化到 FP8 和 FP4 —— 让一个带宽受限的工作负载,把瓶颈挪到别处去。


下一章 — 第 4 章:专用 AI 芯片与 ASIC那些 purpose-built 的加速器 —— Groq、Inferentia2、TPU、Gaudi 3 —— 以及它们在延迟或每 token 成本上打败 GPU 的那些区间。

想看完整的全貌?书里这一章包括带 MSRP 和 TDP 的完整规格对比表、当 VRAM 天花板逼你上多卡时 tensor 并行的算术、benchmark 里最容易踩到的 SXM/PCIe 差别,以及那份"怎么按 serving 视角读一张数据表"的 In Plain English 边栏。在 Amazon 上查看 LLM Primer VI →

下田 昌平
下田 昌平
作为株式会社Receipt Roller的CEO兼CTO,目前负责开发电子收据服务以及自动将对话分类并生成行动任务的系统「ACTIONBRIDGE」。从小便接触编程,1996年参与开发测量仪器的相关程序,始终保持着对技术的深刻探索与热情。 在此前的职业生涯中,曾担任日本最大呼叫中心行业企业的子公司——一家研究开发公司的CEO/CTO,领导了多个技术开发项目。目前,我依然活跃在编程的最前沿,持续书写代码。