GPU 硬件与 HBM

GPU 训练/推理的硬件底座是「算力 + 显存带宽 + 显存容量」三个维度的组合。以 H100 SXM 为基准: 80GB HBM3, 带宽 3.35TB/s; FP16/BF16 密集算力 989 TFLOPS(稀疏 1979), FP8 1979 TFLOPS; L2 50MB、132 个 SM(每 SM 228KB 共享内存 SRAM)。显存层级自快到慢: 寄存器(每 SM 256KB)→ 共享内存 SRAM → L2(50MB)→ HBM(80GB)→ 主机内存/NVMe, 带宽逐级下降约一个数量级、容量逐级上升。内存墙: 70B 模型 FP16 权重 140GB, 以 3.35TB/s 搬运一遍需 $\frac{140\,\text{GB}}{3.35\,\text{TB/s}} \approx 42\,\text{ms}$; 而单 token 前向计算量约 $2 \times 70\text{B} = 140\,\text{GFLOP}$, 在 989 TFLOPS 下仅需 $\approx 0.14\,\text{ms}$——搬运与计算比约 300:1, 权重驻留 HBM、每次使用都要全量读出的训练/推理流程被显存带宽锁死(带宽受限)。算术强度(arithmetic intensity)$I = \frac{\text{FLOP}}{\text{byte}}$ 是判断依据: H100 平衡强度约 $\frac{989\,\text{TFLOP/s}}{3.35\,\text{TB/s}} \approx 295\,\text{FLOP/byte}$, 低于它为带宽受限(LayerNorm、激活、逐元素算子), 高于它为算力受限(大矩阵乘)。

训练 Infra 面试第一课——显存估算(16Ψ、激活、KV Cache 都以 80GB 为参照)、算子瓶颈分析(torch.profiler 看 memory-bound vs compute-bound)、并行策略选型(TP 需要节点内 NVLink 承载高频小消息, 因为其消息量 ~$b \times s \times h$ 与带宽强相关)。

解释“为什么大模型训练/推理吃不满 FLOPs”——权重 140GB 必须反复从 HBM 读出, 搬运时间 42ms 是计算时间 0.14ms 的约 300 倍; 一切 Infra 优化(FlashAttention 用 SRAM、量化减字节、TP/PP 并行摊薄、KV Cache 优化)本质上都是在与这条带宽墙博弈。

报 H100 关键数字: 80GB HBM3、3.35TB/s 带宽、989 TFLOPS FP16、L2 50MB; 口算平衡算术强度 $\approx 295\,\text{FLOP/byte}$ 并判断它是算力受限还是带宽受限。

手算内存墙: 70B FP16 权重 140GB, 搬运一遍 $\frac{140\,\text{GB}}{3.35\,\text{TB/s}} \approx 42\,\text{ms}$; 单 token 前向 $2 \times 70\text{B}$ FLOP 在 989 TFLOPS 下 $\approx 0.14\,\text{ms}$; 比值约 300:1, 由此说明训练为何带宽受限。

画出显存层级: 寄存器 → SRAM/共享内存 → L2 → HBM → 主机内存, 每级典型容量与带宽量级(H100: 228KB/SM、50MB、80GB); FlashAttention 为什么要把中间结果留在 SRAM 而不写回 HBM。

用算术强度 $I=\text{FLOP/byte}$ 判断算子类型: 给出 H100 平衡点 $\approx 295$; 举出带宽受限(LayerNorm/激活/GELU)与算力受限(大 matmul)的例子并解释判断过程。

从带宽/容量角度论证: 为什么 70B 单卡放不下(权重 140GB > 80GB), 需要权重切分(TP/ZeRO)或量化; 为什么权重反复全量读出的场景优先优化字节数(量化、重计算)而非算力。