第17章 AI Infra 计算

本章建立 AI Infra 工程决策所需的整套理论计算体系：从硬件参数、参数量、前反向计算量、训练显存、训练效率、网络 通信、存储 IO 到推理效率，最后以端到端案例串联全书公式。各节公式以第一性原理推导，配合主流模型的数值算例， 覆盖训练与推理全链路的容量规划与成本估算。

17.1 核心硬件概念

17.1.1 FLOPs 基本概念

在 AI Infra 理论计算中，FLOPs 是衡量计算工作量的基本单位，代表一次浮点运算（Floating-point Operation）。理解 FLOPs 与 MAC（Multiply-Accumulate）的区别，是后续所有训练和推理计算分析的基础。

1. FLOPs 与 MAC 的关系 一次乘加运算（MAC）包含一次乘法和一次加法，因此： 1 MAC = 2 FLOPs GPU 上的 FMA 指令（Fused Multiply-Add）在单条指令中完成 a × b + c 操作，每执行一条 FMA 指令即完成 2 次 FLOPs。这不同于某些学术论文中将一次矩阵乘法中每个元素计算计为 1 次 MAC 的统计方式。本书统一采用 FLOPs 作为 计量单位，换算关系如上。
2. 基本计算公式 计算量的通用公式为： total_FLOPs = operations_per_element × element_count

以矩阵乘法 C = A × B 为例，其中 A 为 m × k，B 为 k × n，C 为 m × n： •计算 C 中每个元素需要 k 次乘法 + k 次加法 = 2k 次 FLOPs •C 中共有 m × n 个元素 因此： FLOPs(m×k)×(k×n) = 2 × m × n × k 3) 矩阵乘法实例 以 C = A × B 为例，其中 A 形状为 [2, 3]，B 形状为 [3, 4]：

 # Matrix multiply: A (2×3) ×
 # m=2
 flops = 2 * 2 * 3 * 4 # = 48 FLOPs
 # Alternatively: (6 mult + 6 add)

对于线性层 y = xW ，其中 x 为 [B, d ]，W 为 [d , d ]，FLOPs 为 2 × B × d × d 。 T in out in out in 4) 训练计算量系数 训练涉及前向传播（Forward）和反向传播（Backward）。对于典型的 Transformer 模型，反向传播的计算量约为前向 的 2 倍，加上权重更新，全量训练的总 FLOPs 约为前向的 3 倍。 理解 FLOPs 的另一个关键用途是计算 MFU（Model FLOPs Utilization），即有效算力利用率。MFU = 实际达到的 TFLOPS / GPU 理论峰值 TFLOPS，这是衡量训练效率的核心指标。 示例 1 LLaMA-7B 的 Q 投影层为 d = 4096 到 d = 4096 的线性变换。给定 batch=1 , seq_len=4096 ，计算该层一次前 向传播的 FLOPs： model model FLOPs = 2 × B × S × din × dout = 2 × 1 × 4096 × 4096 × 4096 •4096 = 68, 719, 476, 736 •2 × 68, 719, 476, 736 = 137, 438, 953, 472 结果：约 137.4 GFLOPs。LLaMA-7B 的 K 和 V 投影层尺寸相同，贡献同样的计算量。三层合计约 3 × 137.4 ≈ 412 GFLOPs，加上 Attention 输出投影的另一个 137.4 GFLOPs，仅 Attention 部分的矩阵乘法就约 550 GFLOPs。 示例 2 LLaMA-70B 的 FFN 层包含三个线性变换： gate_proj （8192 → 28672）、 up_proj （8192 → 28672）和 down_proj （ 28672 → 8192）。以单个 Token（B × S = 1）为单位： gate_proj: FLOPs = 2 × 1 × 8192 × 28672 ，×2 = 469, 762, 048 FLOPs。 8192 × 28672 = 234, 881, 024 up_proj: 同 gate_proj，469, 762, 048 FLOPs。 down_proj: FLOPs = 2 × 1 × 28672 × 8192 = 469, 762, 048 FLOPs 单个 Token 经一个 FFN 层的总 FLOPs 为： 3 × 469, 762, 048 = 1, 409, 286, 144 ≈ 1.41 GFLOPs/token 若 B × S = 4096 Token，则单层 FFN 约 1.41 × 4096 ≈ 5774 GFLOPs ≈ 5.8 TFLOPs。70B 模型约 80 层，仅 FFN 部分即约 80 × 5.8 ≈ 464 TFLOPs 每步。

17.1.2 三大带宽类型

AI Infra 中的带宽按数据传输路径分为三类：HBM 带宽、NVLink 带宽和网络带宽。这三者构成 GPU 集群的“血管系 统”，各自瓶颈直接影响训练和推理效率。

1. HBM 带宽 HBM（High Bandwidth Memory）带宽指 GPU 芯片与片上显存之间的数据传输速率。数据量公式： data = bandwidth × time

H800 SXM 与 H100 SXM 采用相同的 HBM3 显存，带宽为 3.35 TB/s。对于大模型训练，每步迭代中的权重加载、激活值 读写均经过此路径，HBM 带宽通常是显存密集型操作的主要瓶颈。 2) NVLink 带宽 NVLink 是 GPU 间直连总线。H800 配备 8 条 NVLink 4（受限版本），双向聚合带宽 400 GB/s；H100/H200/H20 配备完 整 18 条，双向聚合 900 GB/s。NVLink 用于节点内张量并行（TP）通信，其带宽远高于网络，因此 TP 跨 GPU 通信时应 优先利用 NVLink 全互联拓扑。H800 的 NVLink 带宽减半对节点内 TP 通信效率有直接影响。 3) 网络带宽 跨节点通信依赖 InfiniBand 或 RoCE 网络。8 张 NDR 网卡（每口 400 Gbps）的总物理带宽为： 8 × 400 Gbps = 3.2 Tbps = 400 GB/s 由于 64b/66b 编码开销，有效带宽约为物理带宽的 ≈ 97%。实际业务能达 70–85% 有效带宽已属良好水平。 4) 带宽层级总览 三种带宽的量级呈阶梯式下降，如图17-1所示。理解这一层级关系，有助于在并行策略选择时判断通信瓶颈出现在哪一 层。 GPU Chip (Compute) 3.35 TB/s 400-900 GB/s HBM VRAM NVLink (in-node) 50 GB/s per port Network (cross-node) 图17-1 GPU 带宽层级总览 5) 实测带宽与理论峰值 理论峰值通常基于信号线速率计算，未计入协议开销和拥塞折损。在生产环境中，应使用 nccl-tests 或 dcgmi 获取 实测带宽。估算时建议对 HBM 取理论值的 90%，对 NVLink/网络取 70–80%，留出安全余量。 示例 1 LLaMA-7B 以 BF16 格式存储权重，参数总量 7B，每参数 2 字节： data = 7 × 109 × 2 = 14 GB 在 H800 SXM（HBM3 带宽 3.35 TB/s = 3350 GB/s）上，从 HBM 加载全部权重到计算单元的时间为： 14 GB t= = 0.004179 s = 4, 179 μs 3350 GB/s 结果：约 4.2 ms（理论下限）。实际受限于内存控制器队列深度和访问模式，通常在 5–10 ms 量级。此例说明：即使是 7B 模型，仅读一遍权重已经需要毫秒级时间，Decode 阶段每次生成一个 Token 都要遍历一次全部权重。 示例 2 假设需在 GPU 之间传输 7B 模型的完整梯度（BF16，14 GB），对比 H800、H20 及跨节点路径： H800 节点内 NVLink（双向聚合 400 GB/s）： 14 GB tH800 = = 0.035 s = 35 ms 400 GB/s H20 节点内 NVLink（双向聚合 900 GB/s）： 14 GB tH20 = = 0.01556 s = 15.6 ms 900 GB/s 单路 InfiniBand NDR（50 GB/s 有效，单端口）： 14 GB t= = 0.28 s = 280 ms 50 GB/s 8×IB NDR 聚合（8 端口并行，400 GB/s 有效）： 14 GB t= = 0.035 s = 35 ms 400 GB/s 在 H800 节点内，跨节点通信比 NVLink 慢约 280/35 ≈ 8 倍（单端口）。而 8 端口聚合带宽（400 GB/s）恰好与 H800 的 NVLink 总带宽持平，意味着 H800 集群中 8×NDR 聚合的跨节点带宽可接近节点内 NVLink。在 H20 节点内，NVLink 保 持 900 GB/s 全速，跨节点 vs 节点内比例约为 280/15.6 ≈ 18 倍（单端口）或 35/15.6 ≈ 2.2 倍（8 端口），与 H100 一致。 这就是张量并行（TP）应尽量限制在节点内的根本原因。 示例 3 8 张 GPU 对 14 GB 梯度做 All-Reduce。以单遍带宽受限下界估算，H800 节点内 NVLink 有效约 150 GB/s，一次完整梯 度同步约 163 ms；H20 有效约 300 GB/s，约 82 ms。H800 的 NVLink 带宽减半使 All-Reduce 耗时约为 H20/H100 的两 倍。若训练每步中 All-Reduce 耗时超过前反向计算的 5–10%，则网络成为瓶颈，需考虑切换并行策略或增大梯度累积步 数。

17.1.3 显存层次与 Roofline

GPU 显存呈金字塔层次：离计算核心越近，带宽越高、容量越小。优化 GPU 程序的核心课题是让数据复用停留在高速小 容量层级，训练与推理的显存规划也以此为出发点。 Roofline 以算术强度（FLOPs/字节）与岭点的比较判断 kernel 是算力受限还是带宽受限。H100 BF16 稠密峰值 989.5 TFLOPS、HBM 带宽 3.35 TB/s，岭点约 295 FLOP/B。大 batch 的矩阵乘法算术强度远高于岭点，属算力受限，是训练 吞吐的主要贡献者；Decode 阶段算术强度仅约 1 FLOP/B，属典型的内存带宽受限场景，这也解释了推理优化为何聚焦 量化与 KV Cache 压缩。

17.1.4 训练精度对比

数值精度决定了模型的显存占用、计算吞吐和收敛质量。本节梳理主流浮点与整型格式的位宽分配和使用场景。

1. 精度格式一览 如表17-1所示，各精度格式的位宽、字节数与动态范围构成后续显存与算力计算的基础。 表17-1 主流数值精度格式参数 格式 字节数 位布局 (S/E/M) 动态范围 (approx) 最小正规格数 FP32 4 1/8/23 ±3.4 × 1038 1.17 × 10−38 TF32 4 1/8/10 同 FP32 1.17 × 10−38 BF16 2 1/8/7 同 FP32 1.17 × 10−38 FP16 2 1/5/10 ±6.5 × 104 6.1 × 10−5 FP8 E4M3 1 1/4/3 ±448 2−6 = 0.015625 FP8 E5M2 1 1/5/2 ±57344 2−14 ≈ 6.1 × 10−5 INT8 1 — [−128, 127] — INT4 0.5 — [−8, 7] — NF4 0.5 — 非均匀量化 — 其中 S/E/M 分别代表符号位（Sign）、指数位（Exponent）、尾数位（Mantissa）。
2. 格式要点 BF16 与 FP32 共享 8 位指数，动态范围等价于 FP32，可直接无溢出转换；FP16 仅 5 位指数，需配合 loss scaling 防止 梯度下溢。FP8 有 E4M3（1/4/3，范围 ±448，精度高、范围窄，适合前向传播）与 E5M2（1/5/2，范围 ±57344，范 围广，适合梯度反向传播）两种格式。
3. 各精度使用场景 •FP32：Optimizer 主权重副本（master weights），保证累加精度 •BF16/FP16：前向与反向计算的默认精度，Hopper 和 Ada 架构均有原生支持 •FP8：Hopper 架构引入，训练吞吐提升约 2 倍 •INT8/INT4：推理量化主流，GPTQ、AWQ 等算法已广泛支持 INT4 •NF4：QLoRA 使用的 4-bit 非均匀量化格式，基于分位数的信息最优量化
4. 显存换算公式 训练中优化器状态的显存与精度直接相关： memory_bytes = Nparams × bytes_per_element × (1 + Noptimizer_states )

以 Adam 为例（N = 2，即一阶动量和二阶方差），各配置的显存比例如表17-2所示。 optimizer_states 表17-2 优化器状态显存配置对比 配置 bytes/elem 乘数 示例（7B 参数） FP32 + Adam 4 1+2 = 3 7B × 4 × 3 = 84 GB BF16 混合精度 + Adam 2+4 1+1+2 = 4 7B × 2 + 7B × 4 × 2 = 70 GB 混合精度训练中，权重以 BF16 存储，梯度以 BF16 计算，但优化器状态（FP32 主权重 + FP32 动量）仍需 FP32。这解 释了为何训练显存往往远大于单纯权重所需的显存。 示例 1 LLaMA-7B 约 70 亿参数。仅存储权重本身（不含优化器状态和各层激活），不同精度格式的显存占用如表17-3所示。 表17-3 不同精度格式的权重显存占用 精度 字节/参数 总显存 节省量（相对 BF16） BF16 2 7 × 109 × 2 = 14 GB 基准 FP8 1 7 × 109 × 1 = 7 GB 节省 7 GB（50%） 精度 字节/参数 总显存 节省量（相对 BF16） INT4 0.5 7 × 109 × 0.5 = 3.5 GB 节省 10.5 GB（75%） 7 GB 的节省意味着一块 80 GB 的 H800 能在推理时容纳约 10 个用户的 BF16 KV Cache 额外空间，或将 batch size 从 32 提升至 64。INT4 量化将模型压缩至 3.5 GB，使 7B 模型可在消费者级 GPU（如 RTX 4090 24 GB）上轻松部署。 示例 2 纯 FP32 训练 + Adam 优化器的显存构成（每参数字节数）如表17-4所示。 表17-4 纯 FP32 训练显存构成 组件 字节/参数 说明 FP32 权重 4P 模型参数本身 FP32 动量 m 4P Adam 一阶矩估计 FP32 方差 v 4P Adam 二阶矩估计 合计 12P 对 7B 模型： memory = 12 × 7 × 109 = 84 × 109 bytes = 84 GB 仅优化器状态就占 56 GB（8 × 7 × 10 = 56 GB），而模型权重本身仅 28 GB。这是全精度 Adam 训练极少用于大规模模 型的原因——84 GB 已超出 H800 的 80 GB 显存，必须借助 ZeRO 分片或混合精度才能将优化器状态分布到多卡上。 示例 3 对 70B 参数模型，对比三种精度策略的参数本体显存（不含优化器状态）： BF16 + FP32 主权重（标准混合精度）： memory = 70 × 109 × (2 + 4) = 420 GB 其中 BF16 副本 140 GB（训练前反向用），FP32 主副本 280 GB（参数更新用）。 纯 FP8（低精度训练，如 FP8 混合精度）： memory = 70 × 109 × 1 = 70 GB 两种精度策略的参数显存对比如表17-5所示。 表17-5 参数显存策略对比 策略 参数显存 节省量 节省比例 BF16 + FP32 master 420 GB — 基准 纯 FP8 70 GB 350 GB 83% 即使不考虑优化器状态，仅在参数本身层面从 BF16+FP32 master 切换到 FP8 即可释放 350 GB 显存。实际训练中，FP8 混合精度仍需保留 FP16/BF16 的梯度副本（2P），加上 FP32 优化器状态（8P），总计约 11 × 70 × 10 = 770 GB，仍需 9 要多卡 ZeRO 分片。

17.1.5 主流 GPU 参数

本节汇总常用 GPU 的核心参数结论，完整规格见附录B。

1. BW/TFLOPS Ratio 解读 BW/TFLOPS 比值（HBM 带宽 / BF16 峰值算力，均取 dense 值）是 Roofline 转折点的倒数放大版。比值越高，该 GPU 的“每单位算力配给的带宽”越多。H20 比值高达约 27 × 10 ，意味着它是“带宽强、算力弱”的卡，在 Decode 推理 −3 等内存带宽受限场景中表现优异；H100/H800 比值约 3.39 × 10 ，算力密度极高，更偏向训练或 Prefill 等计算密集型场 −3 景。值得注意的是，消费级 RTX 4090 因 GDDR6X 高带宽 + 大幅裁剪的 Tensor Core 算力，比值约 12.2 × 10 ，介于数 −3 据中心 GPU 之间。
2. 训练能力速览 •FP8 训练：Hopper 架构（H100/H800/H20/B200）原生支持，需搭配 Transformer Engine •FP4 推理：Blackwell 架构（B200）引入，峰值达约 9000 TFLOPS •内存总线宽度：H100 为 5120-bit（HBM3），H20 为 6144-bit（HBM3e） •PCIe 接入带宽：所有数据中心 GPU 均为 PCIe 5.0 ×16，单向约 64 GB/s 示例 1 训练 70B 模型（BF16 混合精度 + Adam 优化器），总显存需求约 16P （含 BF16 权重 2P、FP32 主权重 4P、FP32 动量 4P、FP32 方差 4P、BF16 梯度 2P）： total = 16 × 70 × 109 = 1.12 × 1012 bytes ≈ 1.1 TB

采用 ZeRO-3 将全部状态分片到 8 张 GPU：

1.12 TB

                                    per_GPU =            = 140 GB

对照常见 GPU 容量逐个筛选，结果如表17-6所示。 表17-6 各 GPU 显存容量筛选 GPU HBM 容量 ≥ 140 GB ? H100 SXM 80 GB ✗ H800 SXM 80 GB ✗ A100 SXM 80 GB ✗ B200 192 GB ✓ L40S 48 GB ✗ RTX 4090 24 GB ✗ H20 96 GB ✗ 仅 B200（192 GB）可在 8 卡 ZeRO-3 下容纳 70B 模型。对于 H800 等 80 GB 卡，需结合 ZeRO-3 + CPU Offload 或进一 步梯度累积与激活检查点来压缩显存。实际生产环境中，DeepSpeed ZeRO-3 + activation checkpointing 可将 70B 模型 部署在 16–32 张 H800 上。 示例 2 LLaMA-70B 推理部署，不同精度下的单卡/双卡适配分析。BF16 权重（70 × 10 × 2 = 140 GB）单卡需 HBM ≥ 140 GB， 仅 B200（192 GB）满足；BF16 × 2 卡每卡 70 GB，H800/A100/A800（80 GB）、H20（96 GB）、B200 均可。FP8（1 字 节/参数）单卡需 ≥ 70 GB，INT4（0.5 字节/参数）单卡仅需 ≥ 35 GB。选型决策如表17-7所示。 表17-7 70B 模型推理部署方案 部署方案 最小 HBM/卡 可选 GPU 1 卡 BF16 140 GB B200 2 卡 BF16 70 GB H800, A100, A800, H20, B200 1 卡 FP8 70 GB H800, A100, A800, H20, B200 1 卡 INT4 35 GB H800, A100, A800, H20, B200, L40S 量化显著降低部署门槛：INT4 使 70B 模型能在 L40S（< 1 万美元级 GPU）上运行，而无需动用 H800/B200 等数据中心 级 GPU。

17.1.6 网络硬件与分布式通信

大规模 AI 训练中，节点间通信网络是限制线性扩展的关键因素。节点内 GPU 通过 NVSwitch 全互联（DGX H800 内置 4 颗 NVSwitch，8 颗 GPU 全互联，总双向带宽 3.2 TB/s）；NVLink Switch 将互联扩展到机架级别，GB200 NVL72 通过 9 台 NVLink Switch 托盘将 72 颗 Blackwell GPU 连接为单一 NVLink 域，最大支持 576 GPU（8 台 NVL72 机柜）的全互联 域。跨节点通信依赖 InfiniBand 或 RoCE，8 张 NDR 网卡（每口 400 Gbps）聚合约 400 GB/s，可接近单 GPU 的 NVLink 带宽，但成本高昂，仅在 Rail-optimized 拓扑中常用。 单 GPU 视角下，H800 的 NVLink 双向聚合带宽为 400 GB/s，而单路 IB NDR 有效带宽约 50 GB/s——节点内/跨节点带宽 比约 8:1。这一巨大差距决定了 TP（张量并行）几乎只能在节点内使用，而 DP（数据并行）和 PP（流水线并行）对跨 节点带宽的敏感度相对较低。 示例 1 DGX H800 节点内含 4 颗 NVSwitch 芯片，8 张 GPU 通过 NVSwitch 实现全互联。每张 GPU 的 NVLink 双向聚合带宽为 400 GB/s（8 条 NVLink 4，受限版本）。 将 8 张 GPU 等分为两组（4+4），对分带宽即两组间所有 GPU 对的总通信带宽： bisection_BW = 4 × 400 GB/s = 1.6 TB/s 等效于总聚合 NVLink 带宽（8 × 400 = 3.2 TB/s）的一半。NVSwitch 的无阻塞交换架构确保了每张 GPU 可同时以全速 率与对侧 GPU 通信，不会因内部拥塞而降速。换言之，节点内做 All-Reduce 时，有效通信带宽可接近各卡 NVLink 的全 速率，远优于传统的 PCIe 树形拓扑。 示例 2 64 张 GPU 分布在 8 个 DGX 节点，每节点 8 张 GPU。对 70B 模型的完整梯度（140 GB，BF16 2 字节/参数）做 All- Reduce： 节点级带宽：每个 DGX 节点 8 个 NDR 端口，聚合有效带宽 8 × 50 GB/s = 400 GB/s。 Ring All-Reduce 耗时（8 节点环，N = 8）： N −1 7 data_per_node = 2 × × 140 GB = 2 × × 140 = 245 GB N 245 GB t= = 0.6125 s = 613 ms 400 GB/s 一轮跨节点梯度同步约 613 ms。对比典型每步前反向计算时间（若干秒），网络通信占比在 10–20% 量级。若使用 Tree All-Reduce（log N 跳，每跳传输全量数据），耗时约为： 2 × 140 GB ttree = = 0.7 s = 700 ms 400 GB/s 两种算法接近，Ring 在 N 较大时略优（传输量 2(N − 1)/N vs 2 份）。

17.2 参数量分析

本章推导标准 Dense Transformer（以 LLaMA 族为代表）的参数量构成，涵盖注意力层、前馈网络、归一化层及词嵌入 模块，最终给出总参数量公式并简化近似。

17.2.1 Dense 参数推导

标准 Dense Transformer 的参数量由四个部分累加：多头注意力（MHA）、前馈网络（FFN）、RMS 归一化（RMSNorm） 和词嵌入/输出头。 注意力层。每个注意力层包含 Q、K、V、O 四个投影矩阵： •Q、K、V 投影：各为 d × d ，三个合计 3d model model •输出投影 O：d × d ，计 d model model model •每层注意力总参数量：4d model model 门控前馈网络（SwiGLU）。现代模型多采用 SwiGLU 激活，包含上投影（up）、门投影（gate）和下投影（down）： •up 与 gate：各 d × d model ff •down：d × d ff model •三层合计：3d d model ff 为保持与非门控 FFN（参数量 2d d ）参数规模一致，SwiGLU 通常取 d = 8d /3。代入得 3d ⋅ ，与标准 FFN 的 2d ⋅ 4d = 8d 等价。 model ff ff model model 2 2 (8d model/3) = 8d model model model model RMS 归一化。每层两个 RMSNorm（注意力前、FFN 前），各含 d 个可学习缩放参数：2d 。 model model 词嵌入与输出头。输入嵌入矩阵大小 V × d 。多数模型将嵌入与 LM Head 权重共享（tied），仅计一次；若不共享则 加倍。 model 完整公式 整合以上，Dense Transformer 总参数量为： P = V dmodel + L ⋅ (4d2model + 3dmodel dff + 2dmodel ) 当Vd 2 model ≪ 12Ldmodel 时（大模型常见），可简化为： P ≈ 12Ld2model ( 当d = 4d 时) ff model 若采用 SwiGLU 且 d = 8d /3，简化式仍近似成立。 ff model 示例 1 LLaMA-7B 实例验证 以 LLaMA-7B 为例：L = 32，d = 4096，d = 11008，V = 32000。逐组件分解如表17-8所示。 model ff 表17-8 LLaMA-7B 参数量逐组件分解 组件 计算 参数量 每层注意力 4 × 40962 67,108,864 每层 FFN (SwiGLU) 3 × 4096 × 11008 135,266,304 每层 RMSNorm 2 × 4096 8,192 每层合计 — 202,383,360 32 层合计 32 × 202,383,360 6,476,267,520 组件 计算 参数量 嵌入 + LM Head 2 × 32000 × 4096 262,144,000 总参数量：6,476,267,520 + 262,144,000 = 6,738,411,520 ≈ 6.7B，与官方报告一致。简化近似 12Ld ≈ 6.44B 偏差约 2 4%，在粗略估算中可接受。 model 示例 2 LLaMA-3-8B 以 LLaMA-3-8B 为例，使用标准 Dense 公式（忽略 GQA 带来的 K/V 节省）：L = 32，d = 4096，d = 14336，V = 128,256。 model ff 逐组件分解如表17-9所示。 表17-9 LLaMA-3-8B 参数量逐组件分解 组件 公式 计算 结果 每层注意力 4d2model 4 × 40962 67,108,864 每层 FFN (SwiGLU) 3dmodel dff 3 × 4096 × 14336 176,160,768 每层 RMSNorm 2dmodel 2 × 4096 8,192 每层合计 — — 243,277,824 32 层合计 — 32 × 243,277,824 7,784,890,368 词嵌入（共享） V dmodel 128,256 × 4096 525,336,576

                               P = V dmodel + L ⋅ (4d2model + 3dmodel dff + 2dmodel )
                                                = 525.3M + 32 × (67.1M + 176.2M + 0.008M)
                                                = 525.3M + 32 × 243.3M
                                                = 525.3M + 7,784.9M

≈ 8.31B 标准 Dense 公式给出约 8.31B，与官方标称 8.0B 存在约 0.3B 偏差。这部分偏差主要来自 GQA（g = 8）节省的 K/V 参 数：将注意力从 4d 降至约 2d + 2gd d 。GQA 单层节省约 1.6d ≈ 26.8M，32 层合计约 0.86B，扣除后 2 2 2 8.31B − 0.86B ≈ 7.45B。剩余偏差由 untied embedding 等因素解释，说明 LLaMA-3-8B 的 LM Head 与嵌入权重可能不 model model head model model 共享，需额外再加 525M，合计约 8.0B，与官方值吻合。 示例 3 LLaMA-3.1-405B LLaMA-3.1-405B 是目前最大的开源 Dense 模型：L = 126，d = 16384，d = 53248，V = 128,256，h = 128， = 128，采用 GQA（g = 8）。其参数规模演示了万卡集群级别的计算需求。 model ff d head 注意力层（GQA）。Q 和 O 投影各为 d ；K 和 V 投影各为 g ⋅ d ⋅ d ： model head model

                              PQ = 163842 = 268,435,456
                              PK = 8 × 128 × 16384 = 16,777,216
                              PV = 8 × 128 × 16384 = 16,777,216
                              PO = 163842 = 268,435,456
                            Pattn = 268.4M + 16.8M + 16.8M + 268.4M = 570.4M

FFN 层（SwiGLU）： PFFN = 3 × 16384 × 53248 = 3 × 872,415,232 = 2,617.2M RMSNorm：2 × 16384 = 32,768（可忽略） 单层合计：570.4M + 2,617.2M + 0.03M ≈ 3,187.7M 126 层合计：126 × 3,187.7M ≈ 401,650M ≈ 401.7B 词嵌入与输出头。此规模下 LM Head 通常不共享： Pemb = 2 × 128,256 × 16384 = 2 × 2,101.3M = 4,202.7M ≈ 4.2B 总参数量： Ptotal = 401.7B + 4.2B ≈ 405.9B ≈ 405B ✓ 单层参数即达 3.2B，已超过一个完整 LLaMA-3-8B 的 40%。126 层的累计使得总参数突破 400B，是 LLaMA-3-8B 的约 50 倍。若使用简化式 P ≈ 12Ld = 12 × 126 × 268.4M ≈ 405.8B 恰好也落在 405B 附近，因为大模型下 d ≈ 与简化式的隐含假设 d ≈ 4d 偏差被词嵌入项的差异所抵消。 model ff 3.25d model ff model Dense Transformer 的单层参数流动如图17-2所示。 Input Tokens Embedding Transformer Layer × L Multi-Head Attention RMSNorm SwiGLU FFN RMSNorm Next Layer or Output LM Head Output Logits V × d_model 4 × d_model² d_model 3 × d_model × d_ff d_model V × d_model (tied) 图17-2 Dense Transformer 单层参数流动

17.2.2 MoE 参数推导

混合专家（Mixture of Experts, MoE）模型将标准 FFN 替换为多个并行的专家网络，由路由器决定每个 token 激活哪些 专家。其参数量分析的核心在于区分总参数和每 token 激活参数。 密集组件不变。注意力层、RMSNorm 和词嵌入与 Dense 模型完全相同。 MoE 层参数。设每层有 N 个专家，每个专家为一个 SwiGLU FFN（含 up、gate、down 三个投影矩阵），隐藏维度为 d ： ff_expert PMoEperlayer = N ⋅ 3 ⋅ dmodel ⋅ dff_expert 路由网络。路由器为一个 d × N 的小矩阵（有时含偏置），参数量为 N d 。在总参数中占比可忽略。 model model 激活参数。每个 token 仅路由到 top_k 个专家（通常 k = 1 或 2）。每 token 实际激活的 MoE 参数量为： PactiveMoEpertoken = top_k ⋅ 3 ⋅ dmodel ⋅ dff_expert 共享专家。部分模型（如 DeepSeek-V2）设置若干“共享专家”对所有 token 始终激活，其参数计入激活量。 完整公式： Ptotal = Pdense_non_moe + N ⋅ 3 ⋅ dmodel ⋅ dff_expert Pactive = Pdense_non_moe + top_k ⋅ 3 ⋅ dmodel ⋅ dff_expert 其中 P 为注意力层、归一化层与词嵌入的参数之和。 dense_non_moe 示例 1 Mixtral 8×7B 实例 Mixtral 8×7B 的命名意为“8 个专家、每个专家规模相当于 7B 模型的 FFN”。N = 8，top_k = 2，d model = 4096 ， = 14336。参数分解如表17-10所示。 d ff_expert 表17-10 Mixtral 8×7B 参数分解 指标 计算 结果 每层 MoE 参数 8 × 3 × 4096 × 14336 1,409M 32 层 MoE 合计 — 45,097M 密集部分 注意力 + 词嵌入等 约2,410M 总参数 — 约47.5B 指标 计算 结果 每 token 激活 密集 + 2 × 3 × 4096 × 14336 × 32 约13.7B 总参数约 47B，激活参数约 13B，与官方数据吻合。激活参数占总参数的约 29%，这揭示了 MoE 架构的核心优势：以少 量激活参数获得大规模参数容量。 DeepSeek-V2 风格 DeepSeek-V2 采用细粒度专家（d 较小但 N 很大）：N = 160，top_k = 6，d ff_expert = 1536。其总参数中专家占比 ff_expert 极大，但每 token 仅激活 6/160 = 3.75% 的专家。此外还有 2 个共享专家始终激活。DeepSeek-V3 在此基础上引入无辅 助损失的负载均衡策略，通过动态偏置调节专家选择，避免了传统 MoE 中负载均衡损失对训练目标的干扰。 示例 2 DeepSeek-V2 细粒度 DeepSeek-V2 核心参数：L = 60，d = 5120，d = 1536，N = 160，top_k = 6，V = 102,400。其设计思想是 ff_expert 用大量“细粒度”小专家（d 仅 1536，远小于 d = 5120）换取路由的灵活性和激活效率。 model ff_expert model 单专家 FFN 参数量（SwiGLU 结构，含 up、gate、down 三个投影矩阵）： Pper_expert = 3 × 5120 × 1536 = 23,592,960 ≈ 23.6M 单层 MoE 总参数量（所有 160 个专家的总和）： PMoE_per_layer = 160 × 23.6M = 3,774,873,600 ≈ 3.77B 单层路由网络（d model → N 的线性层，含偏置）： Prouter = 5120 × 160 + 160 ≈ 0.82M ( 可忽略) 单层激活参数（每 token 路由到 top_k = 6 个专家，外加 2 个共享专家）：

                                                       Prouted_active = 6 × 23.6M = 141.6M
                                                       Pshared_active = 2 × 23.6M = 47.2M
                                           PMoE_active_per_layer = 141.6M + 47.2M = 188.8M

密集组件（注意力 + 词嵌入 + RMSNorm，使用 MLA 注意力，此处近似为标准 MHA）： Pattn_per_layer ≈ 4 × 51202 = 104.9M Pattn_total = 60 × 104.9M ≈ 6.29B Pemb = 102,400 × 5120 ≈ 524M 各组件参数汇总如表17-11所示。 表17-11 DeepSeek-V2 参数汇总 指标 计算 结果 密集组件 注意力 + 词嵌入 约6.8B 总参数 — 约233B 每 token 激活 密集 + 60 × 188.8M 约18.1B 激活/总参比 18.1/233 7.8% 官方标称 DeepSeek-V2 总参数 236B、激活约 21B，与上述推算接近。差异源于 MLA 注意力的精确参数结构与标准 MHA 不同（MLA 进行 KV 压缩，进一步降低激活量）。激活率仅约 8%，意味着推理时 92% 的参数不被当前 token 使用，这是 细粒度 MoE 的核心价值。 示例 3 Mixtral 8×22B Mixtral 8×22B 是 Mixtral 8×7B 的放大版本，名称意为“8 个专家、22B 规模的专家 FFN”。核心参数：L ≈ 56， d model = 6144，d = 16384，N = 8，top_k = 2。 ff_expert 单专家 FFN： Pper_expert = 3 × 6144 × 16384 = 301,989,888 ≈ 302M 单层 MoE： PMoE_per_layer = 8 × 302M = 2,415,919,104 ≈ 2.42B 单层激活 MoE（top_k = 2 个专家）： Pactive_per_layer = 2 × 302M = 604M 密集组件（注意力 + 词嵌入，使用 GQA g = 8）： Pattn_per_layer ≈ 4 × 61442 = 151.0M ( 忽略 GQA 节省) Pattn_total = 56 × 151.0M ≈ 8.46B Pemb ≈ 32,000 × 6144 ≈ 197M 各组件参数汇总如表17-12所示。 表17-12 Mixtral 8×22B 参数汇总 指标 计算 结果 MoE 总参数 56 × 2.42B 约135.3B 密集组件 注意力 + 词嵌入 约8.7B 总参数 — 约144.0B 每 token 激活 密集 + 56 × 604M 约42.5B 激活/总参比 42.5/144.0 29.5% 官方标称总参数约 141B、激活约 39B。推算与官方值的微小偏差来源于：(1) 层数可能为 56 或略少；(2) GQA 实际节省 了部分注意力参数；(3) 专家 FFN 的具体实现细节（部分 MoE 模型对专家使用共享 down-projection 或其他优化）。关键 结论：与 DeepSeek-V2 仅激活约 8% 的参数相比，Mixtral 8×22B 激活了近 30%，因为其专家数量少（8 vs 160）且每 个专家尺寸大得多——这是粗粒度 MoE 与细粒度 MoE 在设计哲学上的根本差异。 MoE 层的 token 路由流程如图17-3所示。 Hidden State d_model Router d_model ▶ N Softmax + Top-k Expert 1 (active) Expert k (active) Expert N (inactive) Weighted Sum Output 图17-3 MoE 层 Token 路由流程

17.2.3 MQA 与 GQA 对比

多头注意力（MHA）的变体多查询注意力（MQA）与分组查询注意力（GQA），核心差异在于 K、V 投影矩阵的共享策 略：MHA 的 h 个查询头对应 h 个 K/V 头，MQA 仅保留 1 组 K/V 供全部 Q 头共享，GQA 将 K/V 分为 g 组（1 < g < h）供 组内 Q 头共享。共享度越高，K/V 参数量与 KV Cache 越小，这是此类变体省显存、省通信带宽的机理。 单层 K/V 投影矩阵参数量：MHA 为 h × d × d = d ，合计 2d ；MQA 为 1 × d × d = d /h，合计 2 2 2 /h；GQA 为 g × d ，合计 2gd /h。K/V 参数量分别降至 MHA 的 1/h 与 g/h，KV head model model model head model model 2 2 2 2d ×d = (g/h)d Cache 读取流量相应减少，三种方案的对比见表17-13。 model head model model model 表17-13 MHA、GQA 与 MQA 的 K/V 参数量对比 方案 K/V 头数 K/V 参数量（单层） 相对 MHA 比例 MHA h 2d2model 100% GQA (g = 8) 8 2 × (8/h) × d2model 8/h MQA 1 2d2model /h 1/h 实际模型对比 以 70B 规模模型为例（L = 80，d model = 8192 ，h = 64，d head = 128 ），各模型的 K/V 参数对比如表17-14所示。 表17-14 70B 模型 K/V 参数对比 模型 注意力类型 K/V 组数 K/V 总参数 节省量 LLaMA-2-70B MHA g = 64 约10.7B 基准 LLaMA-3-70B GQA g=8 约1.3B 9.4B PaLM-540B MQA g=1 取决于 h 最大 LLaMA-3-70B 单层 K/V 参数：2 × 8 × 128 × 8192 = 16,777,216，80 层合计约 1.34B。对比 MHA 的 10.7B，节省约 9.4B 参数——约占 70B 总参数的 13%。 GQA 在 MHA 的精度和 MQA 的效率之间取得了实用平衡：g = 8 时 K/V 参数量降至 MHA 的 1/8，KV Cache 也按同比例缩 减，同时在主流评测中质量损失极小。 示例 1 LLaMA-2-70B LLaMA-2-70B 采用标准 MHA：L = 80，d = 8192，h = 64，d = 128，g = 64（每个 Q 头对应独立 K/V 头，即 MHA）。 model head 单层 K/V 总参数量，即 h 个 K 头与 h 个 V 头、每个头为 d × d 矩阵： head model PKV = 2 × h × dhead × dmodel = 2 × 64 × 128 × 8192 逐步计算： dhead × dmodel = 128 × 8192 = 1,048,576 h × dhead × dmodel = 64 × 1,048,576 = 67,108,864 = d2model PKV = 2 × 67,108,864 = 134,217,728 ≈ 134.2M 80 层累计 K/V 参数： PKV_total = 80 × 134.2M = 10,737,418,240 ≈ 10.74B 占 70B 总参数的约 15.3%。每个 token 的 KV Cache 需存储所有 h = 64 个头的 K/V 向量，每层 2 × 64 × 128 = 16,384 个 元素，80 层合计 1,310,720 个 float16 值，每个 token 约 2.5 MB 的 KV Cache 开销。 示例 2 LLaMA-3-70B LLaMA-3-70B 在相同架构上将 K/V 组数从 64 降至 8：L = 80，d = 8192，h = 64，d = 128，g = 8。 model head 单层 K/V 总参数量，仅 g = 8 组 K/V 头： PKV = 2 × g × dhead × dmodel = 2 × 8 × 128 × 8192 逐步计算： dhead × dmodel = 128 × 8192 = 1,048,576 g × dhead × dmodel = 8 × 1,048,576 = 8,388,608 PKV_per_layer = 2 × 8,388,608 = 16,777,216 ≈ 16.8M 80 层累计 K/V 参数： PKV_total = 80 × 16.8M = 1,342,177,280 ≈ 1.34B MHA 与 GQA 的节省级别对比如表17-15所示。 表17-15 MHA 与 GQA 的 K/V 参数节省级别对比 指标 MHA (g = 64) GQA (g = 8) 节省 单层 K/V 134.2M 16.8M 117.4M 80 层 K/V 10.74B 1.34B 9.40B KV Cache/token 约2.5 MB 约0.31 MB 8× 缩减 9.4B 的参数节省占 70B 总参数的 13.4%。在推理场景中，KV Cache 同样缩减 8 倍，从每个 token 的 1.3M 个 float16 值 降至 164K 个，这对长序列推理和批量服务至关重要。 示例 3 PaLM MQA PaLM 系列采用 MQA（g = 1），是所有多头注意力变体中 K/V 参数最少的方案。以 PaLM-540B 的底层架构为例： d model= 18432，h = 72（d = 256），g = 1。 head MQA 下单层 K/V 参数： PKV = 2 × 1 × 256 × 18432 = 2 × 4,718,592 = 9,437,184 ≈ 9.44M 对比 MHA 下单层 K/V（h = 72，每个头独立 K/V）： PKV_MHA = 2 × 72 × 256 × 18432 = 2 × 72 × 4,718,592 = 679,477,248 ≈ 679.5M MHA 与 MQA 的单层 K/V 参数对比如表17-16所示。 表17-16 MHA 与 MQA 的 K/V 参数对比 方案 K/V 投影参数量 相对 MHA 节省 MHA (g = 72) 679.5M 100% 基准 MQA (g = 1) 9.44M 1.4% 670.1M 单层 K/V 参数从 679.5M 降至 9.44M，节省 670M，缩减至原来的 1/72。在 118 层（PaLM-540B 层数）的结构中，仅 K/V 投影一项就从 MHA 的 118 × 679.5M ≈ 80.2B 降至 MQA 的 118 × 9.44M ≈ 1.11B，节省约 79B 参数，超过许多完整小 模型的总参数量。 MQA 的代价是 K/V 表达能力受限，细粒度注意力任务中可能产生精度损失，这也正是 GQA 作为折中方案的原因。 MHA、GQA 与 MQA 的注意力头结构对比如图17-4所示。 MQA (h heads) Q₁..Qₕ K (single) V (single) Attn GQA (g=2, h=4) Q₁ Q₂ K_G₁ V_G₁ Q₃ Q₄ K_G₂ V_G₂ Attn G₁ Attn G₂ MHA (h heads) Q₁ K₁ V₁ Q₂ K₂ V₂ Attn Attn 图17-4 MHA、GQA 与 MQA 的注意力头结构对比 图中 MHA 每个 Q 头有独立 K/V 头；GQA 多个 Q 头共享一组 K/V；MQA 仅一组 K/V 供所有 Q 头共用。

17.2.4 词表参数占比

词嵌入矩阵规模为 V × d ，输出投影（LM Head）通常与输入嵌入共享权重，合并计为 V d 。当词表 V 极大时， 这一部分在大模型中占比可观，在小模型中甚至占主导。 model model 占比公式： V dmodel fvocab = Ptotal 大词表模型的典型场景。Qwen-2.5-7B 的词表 V = 152,064（为覆盖多语言需求），d model = 3584 ，嵌入矩阵参数量： 152,064 × 3584 ≈ 545M 占总参数 7B 的约 7.8%。相比之下，LLaMA-3-8B 的词表 V = 128,256，嵌入占比约 6.6%。 小模型场景。当 d 较小而 V 相当时，词表占比显著上升。例如 d = 512、V = 50,000 时，嵌入参数 25.6M。若模 型总参数仅 80M，占比高达 32%，这意味着每 3 个参数中就有 1 个用于词表。 model model 多语言模型的影响。词表随语言覆盖范围增长，各模型的词表参数占比对比如表17-17所示。 表17-17 各模型词表参数占比对比 模型 V dmodel 嵌入参数 总参数 占比

GPT-2 Small                           50,257                  768                          38.6M                             124M        31.1%
LLaMA-2-7B                            32,000                  4,096                        131M                              6.7B        2.0%
LLaMA-3-8B                            128,256                 4,096                        525M                              8.0B        6.6%
Qwen-2.5-7B                           152,064                 3,584                        545M                              7.6B        7.2%
BLOOM-7B                              250,880                 4,096                        1,028M                            7.1B        14.5%
XGLM-7.5B                             250,000                 4,096                        1,024M                            7.5B        13.7%

BLOOM 和 XGLM 等多语言模型的词表参数已超过总量的 13%，在显存规划中不可忽视。 示例 1 三模型词表对比 选取三个典型模型，按嵌入参数公式逐项计算占比，直观对比 V 与 d 的组合效应。前两个模型的数值已列于表17- 17，此处给出公式代入过程。 model 表17-18 三模型词表参数对比 模型 V dmodel 嵌入参数 总参数 占比 Small Model 50,000 512 25.6M 80M 32.0% LLaMA-3-8B：英文为主的词表，占比较低。 525.3 Pemb = 128,256 × 4096 = 525,336,576 ≈ 525.3M, f= ≈ 6.6% Qwen-2.5-7B：为覆盖中文等多语言，V 扩展到 152K，虽 d 略小（3584），嵌入参数仍接近 545M，占比 7.2%—— 比 LLaMA-3-8B 高出近 1 个百分点。多语言词表的代价并非免费。 model 545.0 Pemb = 152,064 × 3584 = 544,997,376 ≈ 545.0M, f= ≈ 7.2% Small Model（d = 512，V = 50,000，总参数 80M）：词表占比高达 32%，如表17-18所示。在此规模下，每 3 个参 数中约 1 个用于存储词嵌入。训练时若不使用梯度检查点或参数冻结策略，词表将占据不可忽视的显存比例。 model 25.6 Pemb = 50,000 × 512 = 25,600,000 = 25.6M, f= = 32.0% 词表占比随参数规模与词表大小变化的规律如表17-19所示。 表17-19 词表参数占比变化规律 关键规律 说明 V 增大 → 占比上升 词表翻倍，嵌入参数翻倍 d 增大 → 嵌入增长但总参数增长更快 model 占比通常下降 小模型 + 大词表 → 占比最高 典型如 GPT-2 Small（31%）、上述 Small Model（32%） 大模型 + 适度词表 → 占比最低 典型如 LLaMA-2-7B（2.0%） 示例 2 大规模多语言模型 假设一个多语言模型：V = 250,000，d model = 8192 ，总参数 70B。词嵌入矩阵的绝对规模令人瞩目： Pemb = 250,000 × 8192 = 2,048,000,000 = 2.05B 2.05B f= ≈ 2.9% 70B 仅嵌入矩阵就已超过许多完整小模型（如 GPT-2 Small 的 124M 或 BERT-base 的 110M）一个数量级以上，但在 70B 的 总参数中仅占 2.9%。若不共享嵌入与 LM Head 权重，嵌入与输出头合并参数按前述公式为： 4.10B Pemb+head = 2 × 2.05B = 4.10B, f= ≈ 5.9% 70B 共享与独立两种情形的嵌入参数与占比如表17-20所示。 表17-20 嵌入权重共享与独立的参数对比 场景 嵌入参数 占比 共享权重（tied） 2.05B 2.9% 独立权重（untied） 4.10B 5.9% 即使 250K 的大词表，在 70B 规模下占比仍可控。真正需要警惕词表占比的场景是：(1) 小模型配大词表；(2) 多语言模型 使用独立（untied）嵌入和输出权重。 不同模型词表参数占总参数的比例如图17-5所示。 Embedding Fraction Across Models )%( noitcarF GPT-2 S LLaMA-2-7B LLaMA-3-8B Qwen-2.5-7B BLOOM-7B 图17-5 不同模型词表参数占总参数比例 从图中可见，词表占比从大词表小模型（GPT-2 Small，31.1%）到标准英文模型（LLaMA-2-7B，2.0%）跨越一个数量 级以上。规划显存预算时，应优先确认目标模型的 V 与 d ，避免低估词表开销。 model

17.2.5 模型参数速查

本节汇总主流开源模型的架构参数，供显存估算、训练规划时快速查阅，如表17-21所示。参数量可通过 L、d 、d 、V 四个核心参数按参数量公式反推验证。 model ff 表17-21 主流开源模型架构参数速查 模型 总参数 L d model dff h dhead 注意力 V 激活 可验证

LLaMA-3-8B        8.0B 32 4,096                                                       14,336 32 128 128,256 GQA(g=8)                             SwiGLU ✓
LLaMA-3-70B       70.6B 80 8,192                                                      28,672 64 128 128,256 GQA(g=8)                             SwiGLU ✓
LLaMA-3.1-405B    405B 126 16,384                                                     53,248 128 128 128,256 GQA(g=8)                            SwiGLU ✓
Qwen-2.5-7B       7.6B 28 3,584                                                       18,944 28 128 152,064 GQA(g=4)                             SwiGLU ✓
Qwen-2.5-72B      72.7B 80 8,192                                                      29,568 64 128 152,064 GQA(g=8)                             SwiGLU ✓
DeepSeek-V2       236B 60 5,120                                                       1,536 128 128 102,400 MLA                                  SwiGLU MoE
DeepSeek-V3       671B 61 7,168                                                       2,048 128 128 129,280 MLA                                  SwiGLU MoE

Mixtral 8×7B 46.7B 32 4,096 14,336 32 128 32,000 GQA(g=8) SwiGLU MoE Mistral 7B 7.2B 32 4,096 14,336 32 128 32,000 GQA(g=8) SwiGLU ✓ GPT-4 (估算) 约1.8T 约120 约20,480 约55,000 约128 约160 约100,000 GQA SwiGLU 估算 Gemma-2-27B 27.2B 46 4,608 36,864 32 256 256,000 GQA(g=8) GeGLU ✓ 注：MoE 模型的“可验证”标记为 MoE，因为其参数量涉及专家路由，无法仅用上表四个参数反推。MLA（Multi-head Latent Attention）为 DeepSeek 特有的 KV 压缩注意力，其参数量同样无法仅凭四个参数反推。LLaMA-3-8B 的完整代 入过程已在前文参数推导小节展开，此处不再重复。 示例 1 快速验证三模型 给定速查表中的 L、d 、d 、V ，代入公式可验证官方参数量。除已推导的 LLaMA-3-8B 外，再取 Mistral 7B 与 Qwen-2.5-7B 两个代表性模型验证： model ff Mistral 7B（L = 32，d = 4096，d = 14336，V = 32,000，GQA g = 8）： model ff

                                                    Pattn = 32 × (2 × 40962 + 2 × 8 × 128 × 4096)
                                                          = 32 × (33.55M + 8.39M) = 32 × 41.94M ≈ 1.34B
                                                    PFFN = 32 × 3 × 4096 × 14336 = 32 × 176.16M ≈ 5.64B
                                                    Pemb = 32,000 × 4096 ≈ 131.1M
                                                    Ptotal = 1.34B + 5.64B + 0.13B ≈ 7.11B ≈ 7.2B ✓
Qwen-2.5-7B（L = 28，d          model = 3584                     ，d = 18944，V = 152,064）：

ff

                                                    Pattn = 28 × 4 × 35842 = 28 × 51.38M ≈ 1.44B
                                                    PFFN = 28 × 3 × 3584 × 18944 = 28 × 203.69M ≈ 5.70B
                                                    Pemb = 152,064 × 3584 ≈ 545.0M
                                                    Ptotal = 1.44B + 5.70B + 0.55B ≈ 7.69B ≈ 7.6B ✓

LLaMA-3-8B 的 MHA 公式给出 8.31B，GQA 公式给出 7.50B；若 LM Head 独立（untied），再加 525M → 8.03B ≈ 8.0B。此例说明 LLaMA-3-8B 的两种情况：(1) 共享嵌入时为 GQA + tied（约7.5B，偏低）；(2) 独立 LM Head 时为 GQA + untied（约8.0B，吻合官方值）。 需注意简化式 P ≈ 12Ld 在 LLaMA-3-8B 上给出约 6.44B，偏差约 20%，因为其 d = 14336 = 3.5 × d ，远超标 准 4 × d 。简化式仅在 d ≈ 4d 时准确，使用前需确认模型的实际 d 取值。 model ff model model ff model ff 三个模型的公式验证结果如表17-22所示。 表17-22 三模型参数量公式验证 模型 MHA 公式 GQA 修正 官方值 吻合 Mistral 7B 7.91B 7.11B ✓ 7.2B 极好 Qwen-2.5-7B 7.69B ✓ 7.07B 7.6B 极好 LLaMA-3-8B 8.31B 7.50B → 8.03B (untied) 8.0B 良好 三个模型的公式验证偏差均在 ±2% 以内。Dense 模型只要掌握 L、d 、d 、V 四个参数并确认是否使用 GQA 和 tied embedding，即可高精度反推总参数量。MoE 模型（如 Mixtral、DeepSeek-V2）不适用此简单公式，需额外引入 model ff N 、d 、top_k 等参数。 ff_expert 示例 2 笔算速估 在缺乏完整 config 的场景中，仅凭零散信息也能快速估计参数规模。这是阅读论文或技术报告时的核心技能。 场景：某论文描述模型为 “L = 40，d = 5120，SwiGLU 激活”。未给出的参数（d 、V 、注意力类型）需按典型值 假设。 model ff 步骤 1: 估计 d 。对 SwiGLU，典型取值 d = 8d /3 ≈ 2.67 × 5120 ≈ 13653，或 d ≈ 3.5d ≈ 17920（LLaMA-3 风格）。以下使用保守的 d = 4d = 20480（GPT-3 风格）作为估计。 ff ff model ff model ff model 步骤 2: 代入简化式。对大模型，V d 项占比通常 < 5%，可先用简化式： model P ≈ 12Ld2model = 12 × 40 × (51202 ) = 12 × 40 × 26,214,400 = 12,582,912,000 ≈ 12.6B 步骤 3: 精细修正。代入完整公式（假设 d = 20480，V = 50,000）： ff

                                              P = V dmodel + L(4d2model + 3dmodel dff + 2dmodel )
                                                       = 50,000 × 5120 + 40 × (4 × 26.21M + 3 × 5120 × 20480)
                                                       = 256M + 40 × (104.86M + 314.57M)
                                                       = 256M + 40 × 419.43M
                                                       = 256M + 16,777M ≈ 17.0B

精细计算给出约 17B，高于简化式的 12.6B，因为 d = 20480 的假设偏大（4d 而非 2.67d ）。实际模型的 d 取 值在两者之间，总参数约 1317B。 ff model model ff 如果这是 MoE 模型（8 个专家，top_k=2）：总参数粗略为 Dense 的 8 倍，约 100136B；激活参数约 Dense + 2 个专家 ≈ 25~34B。 速估口诀：“12 乘层数乘 d ，是 Dense 底座；MoE 乘专家数，是总量上限；top_k 除 N，得激活比例。” 模型参数量验证流程如图17-6所示。 Attention 4L·d_model² Input Parameters Check against official valu L (num layers) d_model d_ff V (vocab size) Feed-Forward Network Total Parameters P es 3L·d_model·d_ff formula correct if error < 5% Embedding V·d_model 图17-6 模型参数量验证流程 从核心架构参数出发，分别计算注意力、FFN 和词嵌入三部分的参数量再求和，与官方标称值比对即可核验。Dense 模 型误差通常在 5% 以内。

17.3 前反向计算量

本节从矩阵乘法出发，逐层推导 Transformer 前向与反向的计算量构成，涵盖线性投影、注意力、归一化、激活函数与 词嵌入，最终给出单 token 与全量训练的 FLOPs 公式。归一化与激活函数因占比可忽略，推导中可安全省略。

17.3.1 矩阵乘法 FLOPs

矩阵乘法是一切深度学习 FLOPs 计算的基础。设矩阵 A ∈ R ，B ∈ R ，计算 C = A × B，其中： m×k k×n k C[i, j] = ∑ A[i, l] × B[l, j] l=1 每个输出元素需要 k 次乘法与 k 次加法，共 2k 次浮点运算。输出矩阵共有 m × n 个元素，因此： FLOPs(A × B) = 2 × m × n × k •转置情形：若 C = A × B 且 B ∈ R ，内积维度仍是 k，FLOPs 不变，仍为 2 × m × n × k。 T n×k •关键模式：FLOPs = 2×（输出元素数）×（内积维度）。这一模式贯穿 Transformer 所有线性层的计算。 •批处理推广：对 A ∈ R 与 B ∈ R 的批量矩阵乘，FLOPs = 2 × b × m × n × k。 b×m×k b×k×n

1. 为什么矩阵乘主导 Transformer Transformer 的所有线性投影和注意力分数计算本质上都是矩阵乘法。MLP 的上下投影、QKV 生成、输出投影、以及 QK 和 AV ，全部归结为 matmul。因此，掌握矩阵乘法的 FLOPs 公式就掌握了全书计算量的核心。 T
2. 数值示例 m, n, k = 1024, 2048, 4096 flops = 2 * m * n * k

flops = 2 * 1024 * 2048 * 4096 = 17

一次 1024 × 4096 与 4096 × 2048 的矩阵乘法需要约 17.18 GFLOPs。在 H800（989.5 TFLOPS BF16）上，这一运算的理 论耗时仅约 17.4 μs，但实际受限于内存带宽和矩阵分块策略，耗时往往在数十至数百微秒级别。 示例 1 LLaMA-7B QKV QKV 投影权重 W ∈ R QKV （d = 4096，3d = 12288），输入 X ∈ R 4096×12288 model （B = 1, S = 4096）： model 4096×4096 FLOPsQKV = 2 × 4096 × 4096 × 12288 = 412, 316, 860, 416 ≈ 412.3 GFLOPs 示例 2 LLaMA-7B FFN FFN 上投影权重 W ∈ R up 4096×11008 ，输入同 QKV 投影： FLOPsup = 2 × 4096 × 4096 × 11008 = 369, 367, 187, 456 ≈ 369.4 GFLOPs 单次 up 投影的 FLOPs 接近 QKV 投影的 90%，是 Transformer 层中计算量第二大的操作。 关键结论：矩阵乘 FLOPs = 2mnk，Transformer 的所有计算密集型操作均以此公式为基石。

17.3.2 线性层 FLOPs

Transformer 每层包含五组核心线性投影：QKV 融合投影、输出投影 O、FFN 上投影、FFN 门控投影（SwiGLU）、FFN 下投影。本节以矩阵乘 FLOPs 公式逐个推导。

1. QKV 投影 输入形状 [B, S, d model ] ，权重 [d model , 3dmodel ] ，输出 [B, S, 3d model ] ： FLOPsQKV = 2 × B × S × dmodel × 3dmodel = 6BSd2model
2. 输出投影 O 权重 [d , d ]，输出 [B, S, d model model model ] ： FLOPsO = 2BSd2model
3. FFN 上下投影 上投影（up）：[B, S, d model ] × [dmodel , dff ] → 2BSdmodel dff 门控投影（gate）：同上，2BSd model dff 下投影（down）： [B, S, dff ] × [dff , dmodel ] → 2BSdff dmodel
4. 单层线性 FLOPs 汇总 记 D = d ，F = d ，单层线性投影总 FLOPs（不含 QK 与 AV ）： model ff T FLOPslinear = 2BSD(4D + 3F )

其中：QKV 贡献 6BSD ，O 贡献 2BSD （合计 8BSD = 2BSD ⋅ 4D），FFN 三投影贡献 6BSDF = 2BSD ⋅ 3F 。 2 2 2 5) 实例：LLaMA-7B 取 B = 1, S = 4096, D = 4096, F = 11008，各组件 FLOPs 如表17-23所示。 表17-23 LLaMA-7B 单层线性投影 FLOPs 组件 FLOPs 数值 (GFLOPs) QKV 投影 6BSD2 ≈ 412 输出投影 O 2BSD2 ≈ 137 FFN 三投影 6BSDF ≈ 1, 108 单层合计 2BSD(4D + 3F ) ≈ 1, 658 单层 forward 约 1.66 TFLOPs。LLaMA-7B 含 32 层，仅线性层 forward 即约 53 TFLOPs。 6) 反向传播 对线性层 y = xW ，forward 为 2mnk FLOPs。反向传播需计算两项梯度： •∂L/∂x = (∂L/∂y) × W ：2mnk FLOPs T •∂L/∂W = x × (∂L/∂y)：2mnk FLOPs T 反向总计 4mnk = 2× forward。这是神经网络中经典的 forward : backward = 1 : 2 比例。 示例 1 LLaMA-7B 单层 合并本节五个组件（B = 1, S = 4096, D = 4096, F = 11008），单层分解如表17-24所示。 表17-24 LLaMA-7B 单层线性投影组件分解 组件 计算 结果 (GFLOPs) QKV 6 × 1 × 4096 × 40962 412.3 O 2 × 1 × 4096 × 40962 137.4 up 2 × 1 × 4096 × 4096 × 11008 369.4 组件 计算 结果 (GFLOPs) gate 2 × 1 × 4096 × 4096 × 11008 369.4 down 2 × 1 × 4096 × 11008 × 4096 369.4 合计 2 × 1 × 4096 × (4 × 40962 + 3 × 4096 × 11008) 1,657.9 即单层 forward 约 1.66 TFLOPs，32 层合计约 53 TFLOPs。 示例 2 单 Token 线性 FLOPs 除以序列长度 S = 4096，得到每 token 线性投影 FLOPs： 1, 657.9 GFLOPs FLOPslinear_per_token = ≈ 0.405 GFLOPs = 405 MFLOPs 每 token 约 4 亿次浮点运算，对应两个 token 即可完成一篇短文长度的推理。 关键结论：单层 Transformer 线性投影 forward FLOPs = 2BSD(4D + 3F )，backward 约为 forward 的 2 倍。

17.3.3 注意力层 FLOPs

标准多头注意力（MHA）包含两次大矩阵乘：QK 与 AV 。两者产生 Transformer 中唯一的 O(S ) 项。 T 2

1. QK^T 计算 Q∈R ，K ∈ R B×h×S×dhead ，输出 [B, h, S, S]： T B×h×dhead ×S FLOPsQK T = 2 × B × h × S × S × dhead = 2BS 2 dmodel 因为 h × d = d ，FLOPs 简化为 2BS d 。 head model model
2. Softmax 每元素约 5 次操作（指数、求和、除法），总计约 5BhS FLOPs，相对 matmul 可忽略。 2
3. AV 计算 注意力权重 [B, h, S, S] × V [B, h, S, d ]： head FLOPsAV = 2 × B × h × S × dhead × S = 2BS 2 dmodel
4. MHA 注意力总 FLOPs FLOPsattn ≈ 4BS 2 dmodel ( 忽略Softmax)
5. MQA 与 GQA 多查询注意力（MQA）中 K 和 V 仅 1 个头：Q[B, h, S, d ] 与 K[B, 1, S, d ] 做 broadcast 乘。FLOPs 仍为 2BS d 2 （每个 query head 与共享 K 相乘，总量不变）。同理 AV 也仍为 2BS d 。 head head model model MQA 的收益在于 KV 缓存量减少 h 倍，而非 FLOPs 减少。分组查询注意力（GQA）同理。
6. FlashAttention FlashAttention 通过分块（tiling）避免物化完整的 S × S 注意力矩阵，将 HBM 读写量从 O(S ) 降至 O(S)。其实际 2 FLOPs 因重缩放步骤略高于标准注意力，但 IO 收益远超微小的算力增量。FlashAttention 的核心优势是 IO 而非 FLOPs。
7. 注意力反向传播 反向传播中，若无 FlashAttention，S × S 注意力矩阵必须被存储（或重计算）以用于梯度传播，内存开销为 O(S )。反 2 向 FLOPs 约等于 2 倍 forward，与线性层一致。 示例 1 LLaMA-7B 注意力 B = 1, S = 4096, d = 4096： model FLOPsattn = 4 × 1 × 40962 × 4096 = 274, 877, 906, 944 ≈ 275 GFLOPs

单层注意力约 275 GFLOPs。32 层合计约 8.8 TFLOPs，对比单层线性投影的 1,656 GFLOPs，注意力在短序列下仅为线性 层的约 17%。 示例 2 LLaMA-7B 注意力 FLOPsattn = 4 × 1 × 327682 × 4096 = 17, 592, 186, 044, 416 ≈ 17.6 TFLOPs 序列长度扩大 8 倍，注意力 FLOPs 扩大了 8 = 64 倍，从 275 GFLOPs 飙升至 17.6 TFLOPs。此时注意力超过线性投影 （约 1.66 TFLOPs）的 10 倍以上。注意力在长序列中完全主导计算量。 示例 3 LLaMA-70B GQA LLaMA-70B 使用 GQA（g = 8）但 FLOPs 公式不变（每个 query head 仍与共享的 K 做内积）： FLOPsattn = 4 × 1 × 40962 × 8192 = 549, 755, 813, 888 ≈ 550 GFLOPs 从 4096 翻倍至 8192，注意力 FLOPs 也恰好翻倍。80 层合计约 44 TFLOPs。 dmodel 标准注意力的计算图如图17-7所示。 V['B,h,S,dh'] Q['B,h,S,dh'] AV Matmul Output['B,h,S,dh'] QK^T Softmax Attention Weights['B,h,S, S'] K['B,h,S,dh'] 图17-7 标准注意力计算图 关键结论：MHA 注意力 forward FLOPs ≈ 4BS d 。MQA/GQA 不改变 FLOPs，FlashAttention 优化 IO 而非 FLOPs。 model

17.3.4 归一化 FLOPs

现代 Transformer 普遍使用 RMSNorm 替代 LayerNorm，计算量进一步降低。本节量化两种归一化的每元素 FLOPs。

1. RMSNorm 给定输入向量 x ∈ R ： d d RMS(x) = ∑ x2 + ϵ d i=1 i xi outi = × γi RMS(x)

每元素约 5-7 次运算（平方、累加、均值、开方、加 ϵ、除、乘 γ）。近似取 5 FLOPs/element，总 FLOPs： FLOPsRMS ≈ 5BSdmodel 2) LayerNorm LayerNorm 额外需要减均值、除标准差两步： xi − μ outi = × γi + β i σ 每元素约 8-10 次运算，近似为 RMSNorm 的 2 倍： FLOPsLN ≈ 10BSdmodel 3) 与主线计算量对比 以 LLaMA-7B 单层为例（B = 1, S = 4096, D = 4096），归一化与主线计算量对比如表17-25所示。 表17-25 归一化层与主线计算量对比 组件 FLOPs 占比 Attention + FFN matmuls ≈ 1.66 TFLOPs > 99.99% RMSNorm（2 处） ≈ 0.08 GFLOPs < 0.01% 归一化层对总 FLOPs 的贡献完全可以忽略。在反推显存、带宽、训练时间等工程决策中，一般不计入归一化 FLOPs。 4) 反向传播 RMSNorm 反向传播的 FLOPs 与 forward 同一量级，同样可忽略不计。 示例 LLaMA-7B RMSNorm LLaMA-7B 每层有 2 处 RMSNorm（attention 前和 FFN 前），32 层共 64 处： FLOPsRMSNorm_total = 64 × 5 × 1 × 4096 × 4096 = 5, 368, 709, 120 ≈ 5.4 GFLOPs 而单层线性投影就达到约 1,660 GFLOPs。RMSNorm 全模型总量（5.4 GFLOPs）仅相当于一次 QKV 投影 FLOPs 的约 1.3%，即 < 0.01% 的全模型 FLOPs。 RMSNorm 的计算步骤如图17-8所示。 Input x['BS,d'] Square: x_i^2 Reduce Mean: mean(x^2) Sqrt + epsilon Divide: x_i / RMS Scale: * gamma_i Output['BS,d'] 图17-8 RMSNorm 计算步骤 关键结论：RMSNorm FLOPs ≈ 5BSd ，占总计算量 < 0.01%，工程估算中可安全忽略。 model

17.3.5 激活函数 FLOPs

激活函数作用于 FFN 中间层的每个元素，每 token 共 d 个元素。三种主流激活函数的每元素 FLOPs 如下。 ff

1. ReLU ReLU(x) = max(0, x)

一次比较即 1 FLOP。FLOPs = BSd 。 ff 2) GELU 精确形式 x ⋅ Φ(x)（Φ 为高斯 CDF），实际用近似： GELU(x) ≈ x ⋅ σ(1.702x) 约 4-5 FLOPs/element（乘、sigmoid、再乘）。FLOPs ≈ 5BSd 。 ff 3) SiLU 激活函数 x SiLU(x) = x ⋅ σ(x) = 1 + e−x 约 5 FLOPs/element（取负、指数、加 1、除、乘）。FLOPs ≈ 5BSd 。 ff 4) 实际占比 LLaMA-7B 使用 SwiGLU，SiLU 作用于 FFN 中间向量（d = 11008）： ff FLOPsSiLU ≈ 5 × 1 × 4096 × 11008 ≈ 225MFLOPs 单层 forward 总 FLOPs 约 1.66 TFLOPs，SiLU 仅占约 0.014%。 5) 三个结论

1. 激活函数 FLOPs 占比极小（< 0.1%），反向传播同理。
2. 在选择 SiLU/GELU/ReLU 时，建模效果是决策因素，FLOPs 差异可忽略。
3. 在训练时间和成本的粗略估算中，可以完全省略激活函数项。 示例 LLaMA-7B SiLU LLaMA-7B 含 32 层 SwiGLU，每层 SiLU 作用于 d = 11008 维向量，32 层合计： ff FLOPsSiLU_total = 32 × 5 × 1 × 4096 × 11008 = 7, 211, 089, 920 ≈ 7.2 GFLOPs

全模型 SiLU 总计约 7.2 GFLOPs，而前向单层线性投影即约 1,660 GFLOPs。SiLU 占比为 7.2/(32 × 1660) ≈ 0.014%，在 工程估算中可完全省略。 三种激活函数的计算量对比如图17-9所示。 ReLU: max(0,x) 1 FLOP/elem Input x GELU: x*sigmoid(1.702x) ~5 FLOPs/elem SiLU: x/(1+e^-x) ~5 FLOPs/elem 图17-9 三种激活函数的计算量对比 关键结论：激活函数 FLOPs < 0.1% 总量，工程估算中可安全忽略。

17.3.6 词嵌入 FLOPs

嵌入层的 FLOPs 分析需区分输入嵌入（查表）和输出投影（全矩阵乘）。

1. 输入嵌入：查表操作 输入嵌入是索引到行向量的映射： token_id → embedding[token_id, :] 。这是一个 gather/scatter 操作，不是矩阵 乘法。严格意义上： FLOPsinput_embed ≈ 0 然而在 GPU 实现中，查表仍需访问 HBM，有内存带宽开销。但从 FLOPs 计数角度，输入嵌入贡献为零。
2. LM Head：全矩阵乘 当使用权重绑定（weight tying）时，输出 logits 的计算是一个完整 matmul： logits = hidden[B,S,dmodel ] × embeddingT[dmodel ,V ] FLOPsLM_Head = 2BSdmodel V

对于 LLaMA-7B（V = 32000, D = 4096）： •全序列：2 × 1 × 4096 × 4096 × 32000 ≈ 1.07 TFLOPs •每 token：2 × 4096 × 32000 ≈ 262 MFLOPs 3) Chinchilla 惯例 Chinchilla 缩放定律采用的惯例是不计入嵌入和 LM Head 的 FLOPs，只统计非嵌入参数的计算量。原因是：

1. 嵌入层的 forward 是查表，本身不产生 FLOPs。
2. 缩放定律以非嵌入参数量 P non_embed 为核心变量，代入 C = 6P D 即得总 FLOPs。 non_embed
3. 若用 P 代入，会高估实际计算量。 total 本书默认采用此惯例，但涉及吞吐量估算（如推理延时）时需加回 LM Head。

4. 反向传播 嵌入层的梯度计算同样是非密集的 gather/scatter 操作。LM Head 反向传播与 forward 等量（2BSd model V FLOPs）。 示例 LLaMA-7B LM LLaMA-7B，V = 32000, D = 4096, S = 4096： FLOPsLM_Head = 2 × 1 × 4096 × 4096 × 32000 = 1, 073, 741, 824, 000 ≈ 1.07 TFLOPs

全序列 4096 个 token 分摊后，每 token 仅约 262 MFLOPs。对比单 token 前向总 FLOPs 约 15.6 TFLOPs，LM Head 占 比约 1.7%。Chinchilla 惯例将其排除不显著影响训练成本估计。 关键结论：输入嵌入 FLOPs ≈ 0（查表），LM Head FLOPs = 2BSd model V 。Chinchilla 惯例不计入嵌入 FLOPs。

17.3.7 单 Token 总 FLOPs

汇总前六节的各组件 FLOPs，给出单 token 的前向与总训练 FLOPs。

1. 前向 FLOPs 近似 忽略 Norm 和激活函数后，前向 FLOPs 的主要来源是线性投影与注意力： Cf wd ≈ 2Pnon_embed + 4LSdmodel •2P ：每个非嵌入参数对应 2 FLOPs/token（来自 matmul forward，每参数贡献一次乘加）。 non_embed •4LSd ：注意力 QK 与 AV 的 O(S d ) 项，×2 再简化为 4LSd 。 T 2 model model model
2. LLaMA-7B 实例 P ≈ 6.74B，L = 32, S = 4096, D = 4096，单 token 前向 FLOPs 构成如表17-26所示。 non_embed 表17-26 LLaMA-7B 单 token 前向 FLOPs 构成 组件 公式 单 Token FLOPs 线性投影（全部层） ≈ 2P ≈ 13.48 GFLOPs 注意力 QK + AV T 4LSD ≈ 2.15 GFLOPs 前向合计 2P + 4LSD ≈ 15.63 GFLOPs 注意力项占前向 FLOPs 的约 14%。当序列长度较短（S ≪ D）时，注意力可忽略，前向简化为 2P ；当 S 极大时（S ≫ D），注意力主导。
3. 反向与总训练 FLOPs 反向传播 FLOPs 约为前向的 2 倍。因此每个 token 的总训练 FLOPs： Ctotal ≈ Cf wd + Cbwd ≈ 3 × Cf wd 在忽略注意力项的近似下： Ctotal ≈ 3 × 2Pnon_embed = 6Pnon_embed 这就是 Chinchilla 缩放定律中的 6N D 公式。 示例 1 LLaMA-7B 单 Token 训练 P = 6.74 × 10 ：

non_embed •前向：C ≈ 2 × 6.74 × 10 = 13.48 GFLOPs f wd •反向：C ≈ 2 × C = 26.96 GFLOPs bwd f wd •总训练：C ≈ 3 × 13.48 = 40.44 GFLOPs/token total 在 H800（989.5 TFLOPS BF16）上，单 token 训练的纯理论下限为 40.44 × 10 /(989.5 × 10 ) ≈ 40.8 μs。实际受内存和 9 12 通信限制，远高于此。 示例 2 LLaMA-70B 单 Token P ≈ 70 × 10 ： non_embed •前向：C ≈ 2 × 70 × 10 = 140 GFLOPs f wd •反向：C ≈ 280 GFLOPs bwd •总训练：C ≈ 3 × 140 = 420 GFLOPs/token total 70B 的单 token FLOPs 是 7B 的约 10.4 倍，与参数量比例一致。 示例 3 LLaMA-3.1 405B 单 Token P ≈ 405 × 10 ： non_embed •前向：C ≈ 2 × 405 × 10 = 810 GFLOPs f wd •反向：C ≈ 1620 GFLOPs bwd •总训练：C ≈ 3 × 810 = 2, 430 GFLOPs/token = 2.43 TFLOPs/token total 405B 模型训练单个 token 即需 2.43 TFLOPs，比 LLaMA-7B 单层前向（1.66 TFLOPs）还要多。 4) 长序列的影响 当 S = 128K 且 L = 32, D = 4096： 4LSD ≈ 4 × 32 × 128000 × 4096 ≈ 67.1 GFLOPs 注意力项远超 2P ≈ 13.5 GFLOPs。长序列场景下，O(S ) 项成为计算瓶颈，此时 C 2 total ≫ 6P 。 LLaMA-7B 单 token 前向 FLOPs 的构成比例如图17-10所示。 13% Linear Projection [87] Attention QK^T+AV [13] 87% 图17-10 LLaMA-7B 单 Token 前向 FLOPs 构成（S=4096） 关键结论：单 token 训练 FLOPs ≈ 6P non_embed （短序列）。长序列时注意力 O(S ) 项不可忽略。

17.3.8 全量训练 FLOPs

从单 token 扩展到全量训练，仅需乘以总训练 token 数 D。

1. Chinchilla 公式 忽略嵌入和注意力后，总训练 FLOPs 为： Ctotal = 6 × Pnon_embed × D

其中 P 为非嵌入参数量，D 为训练 token 总数。 non_embed •推导：每个 token 的 forward 约 2P FLOPs，backward 约 4P FLOPs，合计约 6P FLOPs/token，乘以 D 即得。 2) 主流模型训练 FLOPs 主流模型的训练 FLOPs 与 H800 GPU-天估算如表17-27所示。 表17-27 主流模型训练 FLOPs 与 GPU-天 模型 Pnon_embed 训练 Tokens 总 FLOPs H800 GPU-天 (100% MFU)

LLaMA-7B            6.74B               2T                       8.09 × 1022   ≈ 947
GPT-3 175B          175B                300B                     3.15 × 1023   ≈ 3, 690
LLaMA-3.1 405B      405B                15T                      3.65 × 1025   ≈ 426, 600

H800 BF16 峰值算力：989.5 TFLOPS。GPU-天 = C /(989.5 × 10 × 86400)。 total 3) MFU 修正 实际训练中无法达到 100% 利用率。引入模型浮点利用率（MFU）修正 GPU-天估算： 实际GPU − 天 = 峰值FLOPs/sC× 86400 × MFU total 各 MFU 下 LLaMA-7B 的 GPU-天估算如表17-28所示。 表17-28 不同 MFU 下的 GPU-天 MFU GPU-天 100% ≈ 947 50% ≈ 1, 894 40% ≈ 2, 368 主流开源训练方案的 MFU 通常在 40%-55% 范围内。 4) 使用 P total 若用总参数量代入公式 6P D，LLaMA-7B（P = 7B）将得到 6 × 7 × 10 × 2 × 10 = 8.4 × 10 FLOPs，比真实值 9 12 22 偏高约 4%（因嵌入参数占比小）。对嵌入参数占比大的小模型，偏差更显著。 total total 示例 1 LLaMA-7B 全量 Ctotal = 6 × 6.74 × 109 × 2 × 1012 = 8.088 × 1022 FLOPs H800 峰值 989.5 TFLOPS，MFU = 40% 时： GPU-天 = ≈ 2, 366 天

8.088 × 10

989.5 × 10 × 0.4 × 86400 12

即约 2,366 张 H800 跑 1 天，或 128 张 H800 跑约 18.5 天。40% MFU 是一个现实的估计，Meta 报告 LLaMA 训练 MFU 约 42-45%。 示例 2 LLaMA-3.1 405B 全量 Ctotal = 6 × 405 × 109 × 15 × 1012 = 3.645 × 1025 FLOPs MFU = 40%： 天 = 989 × 3.645 ≈ 1, 067, 000 天 × 10 GPU- 12 10 × 0.4 × 86400 即约 106 万 H800 天，若部署 16,000 张 H800，需训练约 67 天。这与 Meta 公开的 LLaMA 3 训练集群规模（16,384 张 H100）基本吻合。 示例 3 GPT-3 175B 全量 Ctotal = 6 × 175 × 109 × 300 × 109 = 3.15 × 1023 FLOPs OpenAI 论文报告实际使用约 3.14 × 10 FLOPs，与公式预测基本一致。GPT-3 在 V100 上以约 22% MFU 训练，V100 峰 值 125 TFLOPS： V100-天 = ≈ 132,600 天

3.15 × 10

125 × 10 × 0.22 × 86400 12 与 OpenAI 论文报告的估算吻合，验证了 6P D 公式的工程可用性。 主流模型训练 FLOPs 的量级对比如图17-11所示。

                  LLaMA-7B 8.09e22 FLOPs
             GPT-3 175B 3.15e23 FLOPs
            LLaMA-3.1 405B 3.65e25 FL

OPs 图17-11 主流模型训练 FLOPs 量级对比 关键结论：C total = 6Pnon_embed D 。实际 GPU-天需除以 MFU。LLaMA-3.1 405B 训练成本达数十万 H800 GPU-天。

17.3.9 MoE 有效 FLOPs

混合专家（MoE）模型有总参数和激活参数两个概念，FLOPs 计算必须以激活参数为准。

1. MoE 前向 FLOPs 每个 token 仅激活 top_k 个专家，FFN 部分 FLOPs 为： FLOPsFFN_MoE = 2 × top_k × 3 × dmodel × dff_expert

注意力层和归一化层为稠密组件，按常规方式计算。因此每 token 前向 FLOPs： Cf wd ≈ 2 × Pactive Ctotal = 6 × Pactive × D •不使用 P 。这是理解 MoE 训练成本的关键。 total 2) 实例对比 稠密与 MoE 模型的 FLOPs 对比如表17-29所示。 表17-29 MoE 与稠密模型每 token FLOPs 对比 模型 Ptotal Pactive 每 Token FLOPs 相对稠密等价模型 Mixtral 8×7B 47B 13B ≈ 78B 3.6× 更少 FLOPs DeepSeek-V3 671B 37B ≈ 222B 18× 更少 FLOPs Mixtral 若为稠密 47B 模型，每 token FLOPs 约为 6 × 47B = 282B。用 MoE 后仅需 6 × 13B = 78B，FLOPs 降低 3.6 倍。 3) FLOPs 与显存的脱节 MoE 的本质矛盾在于：FLOPs 由激活参数决定，但所有参数都必须加载到显存中，且专家间的 All-to-All 通信开销随总参 数量增长。三维度的缩放关系如表17-30所示。 表17-30 MoE 的 FLOPs 与显存脱节 维度 缩放因子 瓶颈 FLOPs Pactive 计算吞吐 显存 Ptotal HBM 容量 通信 Ptotal （All-to-All） 网络带宽 这一脱节导致 MoE 训练的实际瓶颈往往是显存和通信，而非计算。DeepSeek-V3 有 671B 总参数，虽 FLOPs 仅相当于 37B 稠密模型，却需要数十个节点的显存来承载和通信全部参数。 4) 路由开销 路由网络（gate）的 FLOPs 极微小（通常是一个小的线性层 d → N ，≈ 2BSd N ，远低于 FFN），可以 忽略。 model experts model experts 示例 1 Mixtral 8×7B FLOPs Mixtral 总参数 P = 47B，激活参数 P ≈ 13B（含共享注意力）： total active •MoE 每 token FLOPs：6 × 13 × 10 = 78 GFLOPs 9 •若为稠密 47B 模型：6 × 47 × 10 = 282 GFLOPs 9 •FLOPs 节省比：282/78 ≈ 3.6× 这意味着 Mixtral 的每 token 训练成本仅为同等稠密模型的约 28%。但显存仍需容纳全部 47B 参数（top_k = 2，每个 token 激活 2 个 7B 专家 + 1 个共享注意力），且 All-to-All 通信开销额外增加。实际训练时间比 FLOPs 比例偏大。 示例 2 DeepSeek-V3 极致省算力 DeepSeek-V3 总参数 P = 671B，激活参数 P ≈ 37B： total active •MoE 每 token FLOPs：6 × 37 × 10 = 222 GFLOPs 9 •若为稠密 671B 模型：6 × 671 × 10 = 4, 026 GFLOPs 9 •FLOPs 节省比：4, 026/222 ≈ 18.1× DeepSeek-V3 的激活比（37/671 ≈ 5.5%）使其每 token 训练 FLOPs 仅相当于 37B 稠密模型。但 671B 总参数仍需分布 在大量 GPU 上，这与 FLOPs 的低成本形成鲜明对比，是 MoE 架构的根本矛盾。 稠密与 MoE 模型的 FLOPs 与显存对比关系如图17-12所示。 Dense Model MoE Model Memory: P_total Memory: P_total FLOPs: 6 × P_total × D FLOPs: 6 × P_active × D (same as dense) Comparison Memory Gap 图17-12 稠密与 MoE 模型的 FLOPs 与显存对比 关键结论：MoE 训练 FLOPs = 6P active D （非 P ）。显存和通信仍按 P 缩放，这是 MoE 训练的真正瓶颈。 total total

17.4 训练显存分析

本章系统推导训练过程中各类显存占用——模型权重、优化器状态、梯度、激活值，并覆盖 KV Cache 与推理显存，最终 给出完整的显存规划公式与决策方法。

17.4.1 显存全景图

大模型训练的内存瓶颈是选择并行策略的第一驱动力。训练期间的显存主要由四大类构成：模型权重、优化器状态、梯 度、激活值。理解各类别的大小与占比，才能合理规划 GPU 资源配置。 训练期间的显存全景——各类内存组件的堆叠关系如图17-13所示。 GPU HBM (e.g. H800 80GB, H20 96GB) Weights Optimizer States Gradients Activations 7B x BF16 = 14 GB FP32 master + Adam m/v BF16 = 14 GB variable, ~1-50 GB Overhead 5-10% = 84 GB 图17-13 训练显存四大部分堆叠示意 核心公式： Mtotal = Mweights + Mopt + Mgrads + Macts + Moverhead 全书统一采用 16 字节/参数的显存账本：BF16 权重 2、BF16 梯度 2、FP32 主权重 4、Adam 一阶动量与二阶方差各 4。 按名义 7B 参数计约 112 GB（按 LLaMA-7B 非嵌入参数 6.74B 计约 108 GB），70B 约 1.1 TB。各部件的典型占比（以 LLaMA-7B BF16 + Adam 为例）如表17-31所示。 表17-31 训练显存组件占比 组件 计算方法 典型值 占比 权重 2P (BF16) 13.5 GB 约13% 优化器状态 12P (FP32 master 4P + Adam m/v 8P) 80.9 GB 约75% 梯度 2P (BF16) 13.5 GB 约13% 激活值 可变量，依赖 B×S×L 150 GB 余量 临时缓冲 CUDA work space 等 约2-5 GB 约5% 为什么单卡放不下 7B 模型？ 仅前三项（权重 + 优化器 + 梯度）已约 108 GB，远超 H800 的 80 GB 上限（H20 96 GB 同 样不够）。这解释了为何需要 ZeRO 切分优化器/梯度/权重，以及张量并行将模型切到多张卡上。后续各节逐一展开推导 每一个分项，并给出 ZeRO 如何将显存按 DP 数均摊。

17.4.2 权重显存

模型权重是所有显存组件中最直观的一项：每个可学习参数根据所用精度占用相应字节数。

1. 基本公式： Mweights = P × bytes_per_param

其中 P 为模型总参数量，bytes_per_param 取决于数值精度，各精度格式的字节数如表17-32所示。 表17-32 数值精度格式字节数 精度格式 字节数 典型用途 FP32 (float32) 4 bytes 早期训练，常作为 master 副本 FP16 / BF16 2 bytes 前向/反向传播主流 FP8 (E4M3 / E5M2) 1 byte 训练加速（Hopper+） INT8 1 byte 推理量化 INT4 / NF4 0.5 bytes 推理极致压缩 训练场景中，绝大多数实现同时持有 BF16 副本（用于前反向）和 FP32 master 副本（用于优化器更新），权重文件自身 需要 2P + 4P = 6P 字节。在全量显存账本（16 字节/参数）中，BF16 副本计入权重（2P ），FP32 master 计入优化器状 态，此处 6P 仅描述权重文件的存储构成，与优化器账本不重复累加。 是否需要 FP32 master 取决于优化器实现。纯 BF16 训练配合 Kahan 求和或随机舍入可在某些场景省略 FP32 副 本，但实践中 Adam 等自适应优化器的数值稳定性要求通常保留。 2) LLaMA 系列示例：各模型的权重显存构成如表17-33所示。 表17-33 LLaMA 系列权重显存构成 模型 参数量 BF16 (2P) FP32 master (4P) 合计 (6P)

LLaMA-7B               6.74B             13.48 GB                      26.96 GB                     40.44 GB
LLaMA-13B              13.0B             26.00 GB                      52.00 GB                     78.00 GB
LLaMA-70B              70.0B             140.0 GB                      280.0 GB                     420.0 GB
LLaMA-405B             405.0B            810.0 GB                      1620.0 GB                    2430.0 GB

3. 推理场景：推理无需 FP32 master，权重内存仅 M infer_weights = 2P 字节（BF16）。若使用 INT4 量化，降至 0.5P 但需 少量额外 FP16 scale/zero 参数。
4. 公式总结： Mweights_train = P × (2 + 4) = 6P bytes(BF16 + FP32master) Mweights_infer = P × 2 = 2P bytes(BF16only)

示例 1 BF16 与 INT4 权重 各规模模型的纯权重显存（不含 FP32 master 和优化器）如表17-34所示。 表17-34 BF16 与 INT4 权重显存对比 模型 BF16 权重 INT4 权重 节省 LLaMA-7B 6.74 × 10 × 2 = 13.48 GB 9 6.74 × 10 × 0.5 = 3.37 GB 9 75% LLaMA-70B 70 × 10 × 2 = 140 GB 9 70 × 10 × 0.5 = 35 GB 9 75% INT4 下 70B 模型仅需 35 GB，刚好装入单张 H800 80 GB 显卡（H20 96 GB 则留有 61 GB 余量，可容纳大 batch 或长上 下文 KV Cache）。这是 INT4 量化在推理部署中最直接的价值。 示例 2 LLaMA-405B 纯权重 BF16 下 405B 模型权重为： Mweights = 405 × 109 × 2 = 810 GB 仅权重一项就需要至少 ⌈810/80⌉ = 11 张 H800 80 GB（H20 96 GB 需 ⌈810/96⌉ = 9 张）。若加上 KV Cache 和峰值激活， 实际部署通常需要 16 张或更多。这也是 LLaMA-405B 必须采用多机多卡部署的根本原因。

17.4.3 优化器状态

优化器状态是训练中最占空间的单项。不同优化算法所需的辅助变量差异极大，本节逐一量化。

1. Adam / AdamW Adam 为每个参数维护一阶矩 m 和二阶矩 v，均为 FP32。加上 FP32 master 权重，总计： Madam =

4P + 4P + 4P = 12P bytes m(FP32) v(FP32) masterweights 若 FP32 master 已计入，则纯优化器状态为 8P （m+v）。为避免重复，本章采用全量视角：优化器内部状态 8P + master 权重 4P = 12P 。LLaMA-7B → 12 × 6.74B = 80.88 GB。 2) SGD + Momentum 仅维护一份 velocity buffer（FP32）： Msgd = 4P bytes LLaMA-7B → 26.96 GB。比 Adam 节省约 8P 。 3) 8-bit Adam Adam 的 m 和 v 量化为 8-bit，但 master 权重仍是 FP32： Madam8bit ≈ 1P (m) + 1P (v) + 4P (master) = 6P bytes LLaMA-7B → 40.44 GB，比全精度 Adam 减少 6P 。 4) 各算法对比 各优化算法的显存占用对比如表17-35所示。 表17-35 优化器状态显存对比 优化器 公式 LLaMA-7B 占用 相对 Adam Adam/AdamW 12P 80.88 GB 基准 Adam (仅 m+v) 8P 53.92 GB -33% SGD + Momentum 4P 26.96 GB -67% 8-bit Adam 6P 40.44 GB -50% Adam-mini (近似) 4P 26.96 GB -67% Adam 优化器状态三大组成部分的占比如图17-14所示。 Adam Memory Breakdown (LLaMA-7B, 80.88 GB) 33% 33% m (FP32): 26.96 GB [26.96] v (FP32): 26.96 GB [26.96] Master Weights (FP32): 26.96 GB [26.96] 33% 图17-14 Adam 优化器状态三大组成部分占比 5) 关键结论 8-bit Adam 在理论上可节省 6P ，但 Adam-mini 等更激进的方法通过减少状态数量（如按块而非逐参数维护统计量）进 一步压缩。选择的依据是内存预算与收敛精度的权衡，在显存充足时，全精度 Adam 仍是默认选项。 示例 1 各规模 Adam 全量 各规模模型的 Adam 优化器状态显存如表17-36所示。 表17-36 各规模 Adam 优化器状态显存 模型 m (FP32) v (FP32) master (FP32) 合计 (12P ) 7B 4 × 6.74 = 26.96 GB 26.96 GB 26.96 GB 80.88 GB 13B 52.0 GB 52.0 GB 52.0 GB 156.0 GB 70B 280.0 GB 280.0 GB 280.0 GB 840.0 GB 405B 1620.0 GB 1620.0 GB 1620.0 GB 4,860.0 GB 405B 仅优化器状态就需要 4.86 TB，相当于约 61 张 H800 80 GB（或 51 张 H20 96 GB）的全部显存。这是 Adam 最大的 缺点：显存开销是参数量的 12 倍。 示例 2 SGD + Momentum 内存 7B 模型使用 SGD + Momentum，仅需维护 velocity buffer： Msgd = 4 × 6.74 × 109 = 26.96 GB 对比 Adam 的 80.88 GB，节省 80.88 − 26.96 = 53.92 GB（67%）。代价是收敛速度和最终质量通常略逊于 Adam。 示例 3 8-bit Adam 节省显存 7B 模型使用 8-bit Adam（m + v 各 1B，master 仍 4B）： Madam8bit = (1 + 1 + 4) × 6.74 × 109 = 40.44 GB 对比全精度 Adam： •节省：80.88 − 40.44 = 40.44 GB（50%） •m 从 26.96 GB 降至 6.74 GB（4×） •v 从 26.96 GB 降至 6.74 GB（4×） •master 不变（26.96 GB） 40.44 GB 的节省量恰好等于原始 FP32 m 和 v 的总和。

17.4.4 梯度显存

每个需训练的参数维护一份梯度，形状与参数一致。梯度在反向传播中计算，在 optimizer.step() 后释放。

1. 基本公式： Mgrad = P × bytes_per_grad

PyTorch 默认梯度精度与参数 dtype 相同。BF16 训练时： Mgrad = 2P bytes LLaMA-7B (BF16)：6.74B × 2 = 13.48 GB。 2) 混合精度与 FP32 梯度 部分框架（如 NVIDIA Megatron-LM）在梯度归约时使用 FP32 以保留累加精度，此时 M = 4P 。BF16 梯度配合 FP32 归约的实现（gradient scaling + unscaling）则不增加额外存储：梯度在 FP32 中累加后写回 FP16。两种策略的梯度显 grad 存如表17-37所示。 表17-37 梯度精度策略对比 精度策略 梯度存储 LLaMA-7B BF16（默认） 2P 13.48 GB FP32（特殊） 4P 26.96 GB 3) 梯度累积 梯度累积（Gradient Accumulation）指连续 micro-batch 的梯度在参数上累加后再执行一次 optimizer step。此过程不 增加梯度峰值显存：各个 micro-step 的梯度在同一 buffer 中累加，buffer 大小恒定。 4) ZeRO 中的梯度切分 ZeRO-2 将梯度也按 DP 组切分：每个 GPU 仅持有 2P /N 的梯度。 DP 5) 梯度生命周期 标准训练循环中梯度在反向传播开始分配，在 optimizer.step() 后释放：

 # Typical training loop
 loss.backward()       # allocates gradient buffers
 optimizer.step()      # consumes gradients, then releases
 optimizer.zero_grad() # ensures deallocation

一个关键推论：推理不存在梯度（无反向传播），因此 M grad_infer = 0 。 示例 1 各规模 BF16 梯度 各规模模型的梯度显存如表17-38所示。 表17-38 各规模 BF16 梯度显存 模型 梯度显存 (2P )

LLaMA-7B (6.74B)                                  2 × 6.74 = 13.48 GB
LLaMA-13B (13B)                                   2 × 13.0 = 26.0 GB
LLaMA-70B (70B)                                   2 × 70.0 = 140.0 GB

梯度显存等于 BF16 权重大小。在 16P 全量训练公式中，梯度占 2P /16P = 12.5%。 示例 2 梯度累积不增加显存 以 LLaMA-7B 为例（G = 8 步累积，micro-batch = 1）： •梯度 buffer 大小恒定：13.48 GB •每个 micro-step 的 loss.backward() 将梯度累加到同一 buffer •第 8 步后 optimizer.step() 使用累计梯度更新参数 •整个过程梯度峰值始终为 13.48 GB，不会因 G = 8 而变为 8 × 13.48 = 107.84 GB 这正是梯度累积的核心价值：以更多的计算步数换取等效的大 batch，而不增加显存。

17.4.5 激活值显存

激活值（Activations）是最复杂的显存组件：大小随 batch size、序列长度和模型深度而变化，且每个 Transformer 层 内部分布极不均衡。

1. 为何需要存储激活 反向传播时计算每层梯度需要该层前向通过的中间结果。以 ReLU 为例，求导需知道 x > 0 的条件；以矩阵乘法 y = xW T 为例，对 W 的梯度 = x ⋅ 需要输入激活 x。 ∂L ∂W T ∂L ∂y 若不存储激活值且不重算，框架须在前向时保留这些中间张量。
2. 单层激活明细 以 LLaMA 风格 Transformer 层为例，BF16 下逐项计算（B = 1, S = 4096, d = 4096, d = 11008），单层激活明细如 表17-39所示。 model ff 表17-39 LLaMA-7B 单层激活明细 张量 形状 大小 Attention input (B, S, d_model) 33.6 MB QKV projection (B, S, 3×d_model) 100.7 MB QK^T (per head) (h, S, S) 1.07 GB Softmax( QK^T/√d ) (h, S, S) 1.07 GB Attention output (B, S, d_model) 33.6 MB FFN input (B, S, d_model) 33.6 MB FFN up (SwiGLU) (B, S, d_ff) 90.1 MB FFN gate (SwiGLU) (B, S, d_ff) 90.1 MB FFN output (B, S, d_model) 33.6 MB 单层合计（计入 QK^T 和一个 softmax 副本）：约 2.5 GB（在实际实现中 softmax 矩阵可能复用一段内存）。
3. QK^T 是罪魁 注意力矩阵（Attention Scores, QK^T）是 S × S 的 O(S²) 项。32 层模型，S = 4096 时仅 QK^T 就占 32 × 1.07 ≈ 34 GB。S = 32768 时，S 增长 (32768/4096) = 64 倍，单层 QK^T 飙至 68.7 GB，单卡无论如何放不下。 2 2 QK^T 矩阵随序列长度的平方级增长关系如图17-15所示。 S=4096

QK^T: 1.07 GB/layer S=8192 QK^T: 4.29 GB/layer S=16384 QK^T: 17.2 GB/layer S=32768 QK^T: 68.7 GB/layer 图17-15 QK^T 矩阵随序列长度的平方级增长 4) 总激活公式 略去归一化等小项，每层主导项为： Mact_per_layer ≈ B × S × (4dmodel + 2dff ) × 2 + h × B × S 2 × 2 总激活量： Mact ≈ L × Mact_per_layer 其中 O(L × S ) 项决定了长序列不可行的根源。FlashAttention 将 QK^T 分块计算，不需完整存储该矩阵，将 S 项从显 2 2 存中消除（但计算量不变）。激活重计算（下一节）则从策略层面解决这一问题。 示例 1 LLaMA-7B 单层 LLaMA-7B（B = 1, S = 4096, d = 4096, d = 11008, h = 32, BF16）各张量的形状、元素数与大小如表17-40所示。 model ff 表17-40 LLaMA-7B 单层激活张量明细 张量 形状 元素数 大小 Attention input 1 × 4096 × 4096 16.78 × 106 33.6 MB QKV 投影 1 × 4096 × 12288 50.33 × 106 100.7 MB QK^T（per head） 32 × 4096 × 4096 536.87 × 106 1.07 GB Softmax(QK^T/√d) 32 × 4096 × 4096 536.87 × 106 1.07 GB Attention output 1 × 4096 × 4096 16.78 × 106 33.6 MB FFN up (SwiGLU) 1 × 4096 × 11008 45.09 × 106 90.1 MB FFN gate (SwiGLU) 1 × 4096 × 11008 45.09 × 106 90.1 MB FFN down 输入 1 × 4096 × 11008 45.09 × 106 90.1 MB 单层合计（不计嵌套复用）： Mact_layer ≈ (33.6 + 100.7 + 1070 + 1070 + 33.6 + 90.1 + 90.1 + 90.1) MB ≈ 2, 578 MB ≈ 2.52 GB 若将 Softmax 输出复用（不另存一份），单层降至约 1.45 GB。32 层合计约 46.4 GB。若进一步优化（QKV 在反向可由 attention input 恢复），可降至约 1.07 GB/层，32 层约 34.2 GB。 示例 2 长序列 QK^T 显存 LLaMA-7B，S = 32768（8 倍于标准 4096）： •QK^T 单层：32 × 32768 × 2 bytes = 68, 719, 476, 736 bytes ≈ 68.7 GB •Softmax 副本：同样 68.7 GB •单层仅 QK^T + Softmax：137.4 GB S = 32768 时，单层 QK^T + Softmax 即超过 H800 80 GB。这是长序列训练必须依赖 FlashAttention（避免物化 QK^T） 和激活重计算的根本原因。 示例 3 LLaMA-70B QK^T 显存 LLaMA-70B（d = 8192, h = 64, d = 128），S = 4096： model head •QK^T 单头：B × S = 1 × 4096 = 16.78 × 10 元素 2 2 6 •64 个头：64 × 16.78 × 10 = 1.07 × 10 元素 6 9 •BF16：1.07 × 10 × 2 = 2.15 GB 每层 80 层合计仅 QK^T 矩阵就需 80 × 2.15 = 172 GB。即使使用 FlashAttention 跳过前向存储，反向传播仍需这些值，激活 重计算在此几乎不可商榷。

17.4.6 激活重计算

激活重计算（Activation Recomputation / Gradient Checkpointing）以少量额外计算换取大量显存节约——它是长上下 文训练得以实施的关键技术。

1. 核心思想 反向传播不存储激活值，而是在反向阶段从 checkpoint 重新前向计算，以约 33% 的额外前向计算量换取 O(S ) 级显存 2 的清零。 激活重计算的时间线如图17-16所示：前向阶段仅保存 checkpoint，反向阶段从 checkpoint 重算。 Forward Checkpoint Backward Layer 1 save input activation Layer 2..L save input per layer Layer L recompute forward from ckp compute gradients Layer L-1 .. 1 Forward Checkpoint Backward 图17-16 激活重计算时间线：前向存 checkpoint，反向重算
2. 三种策略 激活重计算的三种策略对比如表17-41所示。 表17-41 激活重计算策略对比 策略 存储内容 显存节约 额外计算 无重算 所有激活 0% 0% 选择性重算 存 QKV，重算 QK^T 约70% 约20% 全量重算 仅每层输入 (residual) 约95% 约33% 全量重算将激活从 O(L × S × d + L × h × S ) 降至 O(L × S × d model model ) ，跨层 QK^T 的 S 项被彻底消除。
3. 实际案例 LLaMA-7B，S = 4096 时不同重算配置的激活显存如表17-42所示。 表17-42 LLaMA-7B 重算配置激活显存 配置 激活显存 相对于无重算 无重算 约43.5 GB 基准 全量重算 约1.0 GB 仅 2.3% S = 32768：无重算时仅激活就已超过数百 GB（单卡不可行），全量重算后激活降至 约8 GB，配合 ZeRO-3 即可训练。
4. 计算成本 全量重算使前向多跑一遍。原始训练：1 forward + 2 backward（梯度 + 参数梯度）≈ 3× forward 计算量。全量重算： 1 forward + 1 forward recompute + 2 backward ≈ 4× forward。Chinchilla 公式 C = 6P D 假定无重算；加入全量重 算后等效为： Crecompute ≈ × 6P D = 8P D 实践中通常仅对个别层或选择性重算，总开销低于 33%。
5. 与 FlashAttention 的关系 FlashAttention 通过分块避免完整存储 S × S 矩阵，但反向传播仍需其值，须配合重算 QK^T；两者结合 （FlashAttention + 选择性重算）是当前实际部署的标配。 示例 1 LLaMA-7B 全量 S = 4096，32 层： •无重计算：约 43.5 GB（含 QK^T + Softmax + 中间激活） •全量重计算：每层仅存输入（33.6 MB）→ 32 × 33.6 ≈ 1, 075 MB ≈ 1.05 GB •节省：43.5 − 1.05 = 42.45 GB（97.6%） 计算代价：原始训练每 step 约 3× forward 计算量（1 fwd + 2 bwd）。全量重计算增加一次 forward recompute，变为 约 4× forward，计算增加约 33%。 权衡结果：牺牲 33% 的算力，换取 97.6% 的激活显存节约。在绝大多数场景中这是明智的取舍。 示例 2 选择性重算 一种常用的折中配置：存储 attention output（33.6 MB/层），重算 FFN 中间值（up + gate + down 输入 = 270.3 MB/层） 和 QK^T（1.07 GB/层）。 •每层存储：33.6 MB（attention input）+ 33.6 MB（attention output）= 67.2 MB •每层重算省下：1.07 GB（QK^T）+ 270.3 MB（FFN）= 1.34 GB •32 层激活总量：32 × 67.2 ≈ 2.15 GB •对比无重算：43.5 → 2.15 GB，节省约 95% •额外计算：仅重算约 60% 的内容（QK^T 占大头），额外前向约 20% 总计算增幅： 增幅 ≈ 3 +30.6 = 1.2× 选择性重计算以 20% 的计算代价获得 95% 的显存节约，是实际训练中性价比最高的策略。

17.4.7 总显存估算

整合前六节的各项推导，给出单卡训练的总显存公式与跨模型规模的速查表。

1. 完整公式 BF16 训练 + Adam 优化器，全量重算激活（典型配置）： Mtotal =

2P + 8P + 4P + 2P + Mact_recomp + Moverhead weightsBF16 Adamm+v master grads 前三项优化器 + 权重合并为常见简记： Mbase = 16P bytes Mtotal ≈ 16P + Mact_recomp + Moverhead 经验法则：带 Adam 和 BF16 权重时，权重 + 优化器 + 梯度三项固定占用约 16P 字节。激活值在启用全量重算时约为 1-8 GB（取决于上下文长度），未重算时可达 30-50 GB 以上。 2) 各规模速查 假设 BF16 + Adam + 全量重算 + S = 4096 + CUDA overhead 约2 GB，各规模总显存如表17-43所示。 表17-43 各规模训练总显存速查 模型 P 16P +Activations 总计 vs H800 80GB LLaMA-7B 6.74B 107.8 GB +1 GB 约109 GB 超过 36% LLaMA-13B 13.0B 208.0 GB +1.5 GB 约210 GB 需要 3 卡 LLaMA-70B 70.0B 1120 GB +5 GB 约1125 GB 需要 15 卡 LLaMA-405B 405.0B 6480 GB +10 GB 约6490 GB 需要 82 卡 7B、70B 与 405B 的显存组件堆叠对比见图17-17，单位为 GB，未按比例。 405B: 6490 GB 70B: 1125 GB 7B: 109 GB W: 810 Opt: 4860 Grad: 810 Act: 10 W: 140 Opt: 840 Grad: 140 Act: 5 W: 13.5 Opt: 80.9 Grad: 13.5 Act: 1 图17-17 7B / 70B / 405B 显存组件堆叠对比 单位：GB，未按比例。 3) 单卡阈值 H800 80 GB 的单卡上限意味着（H20 96 GB 提供 20% 额外余量，可容纳更大 micro-batch 或更宽松的激活预算）： •7B 模型：即使在 BF16 + 全量重算下仍需约 109 GB，单卡不可训。需 ZeRO-3（≥2 卡）或 TP（≥2 卡）。 •13B 模型：16P = 208 GB，最小约需 3 张 H800（或 3 张 H20，96 GB × 3 = 288 GB 余量更大）。 •70B 模型：16P = 1120 GB，至少 14-15 张 H800 以容纳 16P /80 ≈ 14，加上通信开销通常不少于 16 张（H20： 1120/96 ≈ 12 张）。 这就是为什么 16P 被广泛作为第一条筛选公式：先用它判断是否需要切分，再根据激活量选择 ZeRO stage 或 TP/PP。 示例 1 LLaMA-7B 总显存 BF16 + Adam + 全量重计算（S = 4096）下 LLaMA-7B 的总显存分解如表17-44所示。 表17-44 LLaMA-7B 总显存分解 组件 公式 大小 权重 (BF16) 2P 2 × 6.74 = 13.48 GB Adam m (FP32) 4P 26.96 GB Adam v (FP32) 4P 26.96 GB Master weights (FP32) 4P 26.96 GB 梯度 (BF16) 2P 13.48 GB 激活（全量重计算） 约 1 GB 1.05 GB CUDA overhead 约 2 GB 2.00 GB 总计 110.89 GB GB，加激活和 overhead 后约 111 GB。单张 H800 80 GB 无法容纳（H20 96 GB 同样不够，差约 Mbase = 16P = 107.84 15 GB），需以下任一方案： •ZeRO-3, N=2：16P /2 = 53.92 GB/卡 + 激活 1 GB + overhead ≈ 57 GB/卡 •TP=2：权重 + 激活对半切，约 111/2 ≈ 55.5 GB/卡 两种方案均满足 H800 80 GB 限制（H20 96 GB 提供更大安全裕量）。 示例 2 LLaMA-70B 总显存 LLaMA-70B 的总显存分解如表17-45所示。 表17-45 LLaMA-70B 总显存分解 组件 大小 权重 (BF16) 2 × 70 = 140 GB Adam m + v (FP32) 8 × 70 = 560 GB Master weights (FP32) 4 × 70 = 280 GB 梯度 (BF16) 2 × 70 = 140 GB Mbase 16 × 70 = 1, 120 GB 激活（全量重计算） 约 5 GB 基础总计 约 1,125 GB 纯 ZeRO-3 方案： •N=16：1, 120/16 = 70 GB + 激活 5 GB = 75 GB/卡（刚好塞入 H800 80 GB；H20 96 GB 提供 21 GB 余量） •N=32：1, 120/32 = 35 GB + 激活 5 GB = 40 GB/卡（安全裕量） 混合 TP+PP+DP 方案（例如 TP=8, PP=4, DP=2 在 64 张卡上）： •TP=8 切权重 + 激活：M /8 ≈ 140 GB base •PP=4 进一步切层：每卡约 140/4 = 35 GB + 局部激活 •最终每卡约 40-50 GB，分布均匀

17.4.8 ZeRO 显存分解

ZeRO (Zero Redundancy Optimizer) 将优化器状态、梯度和权重按 DP 组切分，逐级降低单卡显存占用。本节量化各 stage 的精确节省量。

1. 三级切分 令 N 为数据并行度（DP size），各 stage 的单卡显存占用如表17-46所示。 表17-46 ZeRO 三级切分显存 Stage 切分内容 单卡公式 单卡 (7B, N=8) ZeRO-1 优化器状态 12P N 10.1 GB ZeRO-2 + 梯度 14P N 11.8 GB ZeRO-3 + 权重 16P N 13.5 GB 从单卡的 107.8 GB 被 N=8 切至 13.5 GB，激活约 1-5 GB，总计在 80 GB 内绰绰有余。 Mbase = 16P ZeRO 三级切分的递进关系如图17-18所示。 ZeRO-1: Opt Split

GPU 0: 12P/8 = 10.1 GB opt GPU 1-7: same ZeRO-2: Opt + Grad Split GPU 0: (12P+2P)/8 = 11.8 G B ZeRO-3: Full Split GPU 0: 16P/8 = 13.5 GB Weights gathered per-laye r during fwd/bwd 图17-18 ZeRO 三级切分递进：优化器 → 梯度 → 权重 2) ZeRO-3 通信开销 ZeRO-3 在每层前向/反向时需 all-gather 权重再 reduce-scatter 梯度。每个 parameter byte 被发送两次（all-gather 一 次，reduce-scatter 一次）： comm_per_step ≈ 2 × 2P × bytes = 4P × 2 = 8P bytes(BF16params) LLaMA-7B：8 × 6.74B = 53.9 GB 通信量。以 NVLink 900 GB/s 或 InfiniBand 400 GB/s 级别互联衡量，与单步计算时间 相比，通信占比通常在可控范围，是当前最通用的分布式训练方案。 3) 各模型 ZeRO 规划 各模型在不同 DP 规模下的单卡显存如表17-47所示。 表17-47 各模型 ZeRO 显存规划 模型 N=8 N=16 N=32 N=64 LLaMA-7B (16P/GPU) 13.5 GB 6.7 GB 3.4 GB — LLaMA-70B (16P/GPU) 140 GB 70 GB 35 GB 17.5 GB LLaMA-70B 在 ZeRO-3 N=16 时单卡 70 GB（+ 激活 约5 GB）→ 75 GB，刚好塞进 H800 80 GB（H20 96 GB 提供 21 GB 激活预算余量）。N=32 更安全并留有激活预算。 注：ZeRO-3 计算量不增（FLOPs 不变），开销纯在通信。当 NVLink 带宽不足以覆盖通信时，应升级至 ZeRO-3 + TP 混合方案。混合策略可进一步提升扩展性。

17.4.9 KV Cache 计算

KV Cache 是自回归生成（训练中的 teacher forcing 和推理中的逐 token 解码）所需存储的 K 和 V 矩阵缓存。它随序列 长度线性增长，在长上下文场景中成为内存瓶颈。

1. 存储公式 每层 K Cache 和 V Cache 的形状取决于注意力头配置，如表17-48所示。 表17-48 注意力变体的 K/V 形状 注意力变体 每层 K/V 形状 说明 MHA (B, h, S, dh ) 每层独立 K、V 头 GQA (B, g, S, dh ) KV 头数 g < h MQA (B, 1, S, dh ) 所有查询头共享一对 KV 统一量化公式： MKV = 2 × L × B × S × hkv × dh × bytes_per_elem

其中 h × d = d 为每层的 KV 维度（MHA 下 d = d ）。上式等价为： kv h kv kv model MKV = 2 × L × B × S × dkv × bytes 2) 典型模型速查 BF16，B = 1 下典型模型的 KV Cache 大小如表17-49所示。 表17-49 典型模型 KV Cache 速查 模型 L dkv S=8192 S=32768 S=131072

LLaMA-3-8B (MHA)                                     32              4096                   4.3 GB                17.2 GB          68.7 GB
LLaMA-3-70B (GQA)                                    80              1024                   2.7 GB                10.8 GB          42.9 GB
LLaMA-2-7B (MHA)                                     32              4096                   4.3 GB                17.2 GB          68.7 GB

GQA 将 d 从 4096 降至 1024（8 头 → 64 查询头但仅 8 个 KV 头），KV Cache 缩减比例为 g/h = 1/8。 kv 各层 K 和 V 张量的缓存结构如图17-19所示。 Layer 0 Layer 1 Layer L-1 K: (B,g,S,d_h) V: (B,g,S,d_h) K: same shape V: same shape K: ... V: ... 图17-19 各层 K 和 V 张量缓存 L 层 × 2 个张量，每个形状由 batch、KV 头数、序列长度决定。 3) 多请求场景 B 个并发请求使 KV Cache 线性放大。LLaMA-3-70B GQA, S = 32768, B = 64： MKV = 2 × 80 × 64 × 32768 × 1024 × 2 = 687.2 GB 这远超单卡容量。分页 KV Cache（PagedAttention）和量化压缩（KV Cache 压缩）是应对这一规模的常用手段。 示例 1 LLaMA-3-8B L = 32, h = 32（MHA 各头独立 KV），d = 4096/32 = 128, BF16： kv h S = 8192, B = 1： MKV = 2 × 32 × 1 × 8192 × 4096 × 2 = 4, 294, 967, 296 bytes ≈ 4.29 GB S = 131072 （128K 上下文）： MKV = 2 × 32 × 1 × 131072 × 4096 × 2 = 68, 719, 476, 736 bytes ≈ 68.7 GB LLaMA-3-8B MHA 的 d = d = 4096，在 128K 上下文下 KV Cache 即接近 H800 80 GB 上限（H20 96 GB 可多容纳约 16/68.7 ≈ 23% 的额外上下文）。 kv model 示例 2 LLaMA-3-70B L = 80, g = 8, d = 128, d = 8 × 128 = 1024（仅 1024 而非 8192）： h kv S = 131072, B = 1： MKV = 2 × 80 × 1 × 131072 × 1024 × 2 = 42, 949, 672, 960 bytes ≈ 42.9 GB 对比若为 MHA（d = 8192）则需 8× 更多，即 343.3 GB。GQA 将 KV Cache 降至 MHA 的 1/8，使 70B 模型在 128K 上 下文中免于 KV Cache 爆炸。 kv 示例 3 多请求 Batch 放大 LLaMA-3-70B GQA，S = 8192, B = 64： MKV = 2 × 80 × 64 × 8192 × 1024 × 2 = 171, 798, 691, 840 bytes ≈ 171.8 GB 即使使用 GQA，64 个并发请求下 KV Cache 即超过 171 GB，远超单卡 80 GB。多请求推理的性能瓶颈往往不是计算而是 KV Cache 显存。PagedAttention（vLLM）通过将 KV Cache 按块管理而非整序列分配，可在这类场景中显著降低碎片化 浪费。

17.4.10 KV Cache 压缩

当长上下文或大 batch 导致 KV Cache 超出显存预算时，可通过量化、结构优化和淘汰策略压缩其大小。

1. 压缩方法对比 各 KV Cache 压缩方法的原理与压缩比例如表17-50所示。 表17-50 KV Cache 压缩方法对比 方法 原理 压缩比 代价 KV 量化 (INT8) K、V 存储精度降为 8-bit 2× 轻微精度损失 KV 量化 (FP8) K、V 存储精度降为 FP8（H100 起原生支持） 2× 精度损失极小 GQA 多查询头共享一组 K、V h/g 模型质量轻微下降 MQA 所有头共享一组 K、V h 训练即需选择 MLA (DeepSeek) K、V 压缩至低维潜空间 dmodel /dc 架构级改动 Token Eviction 只保留关键 token 的 KV 可变 (2-10×) 可能丢失上下文
2. 各方法量化 KV 量化：最简单且可直接应用。将 K 和 V 从 BF16 量化为 INT8（2× 压缩）或 FP8（同 2×，硬件友好）。 DeepSpeed、vLLM 等推理框架均支持。 MLA（Multi-head Latent Attention）：DeepSeek-V2 将 K 和 V 先压缩至一个低维潜向量 c （维度 d ≪ d ），推理 时从 c 恢复 K 和 V。d 远小于原始 KV 维度，Cache 压缩通常可达 5-10×（DeepSeek-V2 常见配置下约 8×）。 KV c model KV c Token Eviction：算法（如 H2O、StreamingLLM）持续评估每个 token 的“注意力权重累计”，仅保留最重要的 k 个 token 的 KV 并丢弃其余。适用于无限长上下文流式场景，但存在信息丢失风险。
3. 效果速查 LLaMA-3-70B, S = 131072, B = 1：原始 KV Cache = 42.9 GB。 LLaMA-3-70B S = 128K 下不同 KV Cache 压缩方案的路线如图17-20所示。 INT8 Quant GQA + INT8 21.5 GB 2.7 GB No Compression Token Eviction 50% 42.9 GB 21.5 GB MLA (8×) 5.4 GB 图17-20 LLaMA-3-70B S=128K 下不同 KV Cache 压缩方案效果 各压缩方案在 LLaMA-3-70B S = 131072 场景下的 KV Cache 如表17-51所示。 表17-51 KV Cache 压缩方案效果对比 方案 KV Cache vs 原始 无压缩 42.9 GB 1.0× INT8 量化 21.5 GB 0.5× GQA + INT8 2.7 GB 0.06× MLA (8×) 5.4 GB 0.13× 50% Eviction 21.5 GB 0.5× 实际部署常组合使用：GQA（结构） + INT8 量化（精度）是当前最成熟的组合，兼顾压缩比与工程成熟度。 示例 1 INT8 KV Cache 量化 LLaMA-3-70B GQA，S = 131072, B = 1： •原始 BF16 KV Cache：42.9 GB •INT8 量化：42.9/2 = 21.45 GB — 2× 压缩 S = 131072, B = 64： •原始 BF16：2 × 80 × 64 × 131072 × 1024 × 2 = 2, 748.5 GB •INT8 量化：2, 748.5/2 = 1, 374.3 GB — 仍远超出单卡，但显著降低多卡部署成本 INT8 量化是最简单、最广泛支持的 KV Cache 压缩手段，vLLM、SGLang、TGI 等主流推理框架均内置支持。 示例 2 MLA 压缩倍率 DeepSeek-V2 的 MLA 将 K 和 V 的原始维度压缩至潜向量 c 的维度 d ≪ d 。以代表性配置为例： KV c model •原始 d ≈ 4096（或等效于按 head 展开的维度） kv •压缩后 d ≈ 512（潜向量维度） c •压缩比：4096/512 = 8× LLaMA-3-70B 风格模型若采用类似 MLA： •原始 KV Cache：42.9 GB（S = 128K ） •MLA 后：42.9/8 ≈ 5.4 GB MLA 的压缩是架构级别的，模型需从头训练时即采用，无法对已有模型后装。其压缩效率远超后处理量化，是长上下文 模型推理的架构级解决方案。

17.4.11 推理显存全景

推理阶段的显存分布与训练本质不同：无优化器状态、无梯度、无反向存储激活。主导项变为权重和 KV Cache。

1. 推理显存公式 Minf er = Mweights + MKV + Mpeak_act + Moverhead 推理显存公式中各项的含义如表17-52所示。 表17-52 推理显存组件说明 组件 量级 说明 权重 M weights 2P (BF16) 约 0.5P (INT4) 无 FP32 master KV Cache M KV 2LBSd ⋅ bytes kv 按前述 KV Cache 公式 峰值激活 M peak_act 几 GB 仅当前层前向临时 Overhead 约1-2 GB CUDA context、workspace
2. 权重与 KV Cache 之争 在长上下文推理中，KV Cache 可远超权重。以下示例均为 BF16，权重与 KV Cache 的主导关系如表17-53所示。 表17-53 推理显存主导项对比 场景 权重 KV Cache 谁主导 7B, B=1, S=4K 14 GB 2.1 GB 权重 7B, B=64, S=4K 14 GB 134 GB KV Cache 70B, B=1, S=128K 140 GB 42.9 GB (GQA) 权重 70B, B=64, S=128K 140 GB 2.75 TB (GQA) KV Cache 推理显存主导项随上下文与批量的转移如图17-21所示。 S=128K, B=64 S=4096, B=1

70B Weights 140 GB 7B Weights 14 GB KV Cache 2.75 TB KV Cache 2.1 GB 图17-21 推理显存主导项的转移 短上下文由权重主导，长上下文大 batch 由 KV Cache 主导。 3) 峰值激活 推理前向传播仅需当前层的中间张量。最大临时张量通常是 Prefill 阶段的 QK^T 矩阵（大小 h × B × S × 2 bytes）。分 2 块 Prefill（Chunked Prefill）将长序列 Prefill 切分为小块，控制该峰值。 4) TP 下推理显存 张量并行（TP=8）切分权重：M = 2P /8。LLaMA-3-70B 权重从 140 GB 降至 17.5 GB/卡。但 KV Cache 在 weights_per_gpu TP 下是否切分取决于注意力实现，按头切分将 KV 也除以 TP 数，进一步压缩。 示例 1 LLaMA-70B BF16 S = 4096, B = 32（GQA, d = 1024）下 LLaMA-70B 的推理显存分解如表17-54所示。 kv 表17-54 LLaMA-70B 推理显存分解 组件 计算 大小 权重 BF16 70 × 109 × 2 140.0 GB KV Cache 2 × 80 × 32 × 4096 × 1024 × 2 85.9 GB 峰值激活 约 2 GB 2.0 GB Overhead — 2.0 GB 总计 229.9 GB 229.9GB 远超 H800 80 GB（H20 96 GB 同样不够）。TP=4 方案： •权重切分：140/4 = 35 GB/卡 •KV Cache 按头切分：85.9/4 = 21.5 GB/卡 •激活 + overhead ≈ 4 GB/卡 •每卡约 35 + 21.5 + 4 = 60.5 GB 4 张 H800 可运行 70B BF16、batch=32、4K 上下文推理（H20 96 GB：权重 70 × 2 = 140 GB → TP=4 每卡 35 GB，总计 约 60.5 GB/卡，余量更充裕）。 示例 2 INT4 权重降低部署成本 同上场景但使用 INT4 权重（0.5 bytes/param + scale/zero ≈ 0.55 bytes/param）： •权重：70 × 10 × 0.55 = 38.5 GB •KV Cache + 激活 + overhead：85.9 + 4.0 = 89.9 GB •总计：38.5 + 89.9 = 128.4 GB TP=2 时： •权重切分：38.5/2 = 19.3 GB/卡 •KV Cache 切分：85.9/2 = 43.0 GB/卡 •激活 + overhead ≈ 4 GB/卡 •每卡约 19.3 + 43.0 + 4.0 = 66.3 GB INT4 量化使 70B 推理从需要 4 张 H800 降至 2 张，大幅降低部署成本和节点间通信需求。

17.4.12 CPU 卸载分析

当 GPU HBM 不足以容纳所有张量时，可将部分数据卸载到 CPU DRAM（甚至 NVMe SSD），以带宽换容量。

1. 带宽鸿沟 各存储层级的带宽与相对 HBM 的倍数如表17-55所示。 表17-55 存储层级带宽对比 存储层级 带宽 相对 HBM H800 HBM3 3350 GB/s 1× H800 PCIe Gen5 128 GB/s 0.038× (26× 慢) CPU DRAM (DDR5) 约50 GB/s 0.015× (67× 慢) NVMe SSD (Gen4) 约7 GB/s 0.002× 每次跨层级的数据搬运都会引入不可忽视的延时。卸载策略的核心问题是：该数据被访问的频率。
2. 卸载对象与代价 各卸载目标的访问频率与流量特征如表17-56所示。 表17-56 卸载对象与代价对比 卸载目标 访问频率 每次步流量 适用性 优化器状态 1×/step (only .step()) 4P bytes 适用 权重 (ZeRO-Offload) 1×/layer (fwd + bwd) 4P bytes 代价高 KV Cache Every token decode 2Sdkv B 不适用 激活值 Every backward 极大 不适用 优化器状态卸载是唯一在实践中广泛使用的卸载方式：Adam 的 m、v 与 master 权重常驻 CPU，每步经 PCIe 往返搬运 一次，数据流如图17-22所示。 pci: 128 GB/s GPU HBM copy params + grads to CP CPU DRAM Weights (BF16) U Adam m,v (FP32) Grads (BF16) update and copy Master weights (FP32) updated weights back 图17-22 ZeRO-Offload 数据流 优化器状态常驻 CPU，每步做一轮 PCIe 搬运。
3. 时间代价量化 LLaMA-7B，每次 step 需搬运：参数拷出 2P (BF16) = 13.5 GB + 参数拷回 2P = 13.5 GB，合计 27 GB。PCIe 128 GB/s 下 耗时约 0.21 秒。 若单步计算耗时约 0.5 秒，卸载增加约 42% 的 step time，在 I/O 与计算之间需要仔细重叠（pipeline）以降低影响。 DeepSpeed ZeRO-Offload 通过多 CUDA stream 实现计算与拷贝重叠，实际额外开销可降至约 15-25%。
4. 何时不该卸载 KV Cache 卸载是常见误用。在推理 Decode 阶段每 token 均需访问完整 KV Cache。以 S = 128K 、PCIe 128 GB/s 为 例，仅读取一次完整 KV Cache 就需要数十秒，完全不可接受。正确的策略是压缩 KV Cache（KV Cache 压缩）或增加 GPU，而非卸载。 卸载是最后的弹性手段，不是首选方案。充分应用 ZeRO、激活重计算和量化后，CPU 卸载作为额外的 1.5-2× 容 量扩展。

17.5 训练效率评估

本章将前四章的公式映射到真实硬件，建立“给定模型与硬件，需要多少 GPU、多长时间”的完整计算方法。覆盖 MFU、训练时间、并行策略选择与成本估算。

17.5.1 峰值与有效算力

算力是训练效率的起算点。但规格书上的 TFLOPS 与实际可用的 TFLOPS 之间存在巨大鸿沟。

1. 理论峰值：以 H800 SXM 为例，BF16 Tensor Core 峰值 = 989.5 TFLOPS（非稀疏）。H800 与 H100 使用同一架构芯 片，计算峰值相同。H20 为降级芯片，BF16 峰值 148 TFLOPS，FP8 峰值 296 TFLOPS。H20 的算力仅为 H800 的 15%，但 HBM 容量更大（96 GB vs 80 GB）且 NVLink 带宽更宽（900 GB/s vs 400 GB/s），专为推理和高内存带宽场景 设计。
2. 有效算力：实际训练中通常只能达到峰值的 30% 到 60%。损耗来源包括： •内存带宽瓶颈：HBM 带宽不足以喂饱 Tensor Core •小矩阵维度：尾层、小 batch 无法填满 Tensor Core 分块 •Kernel 启动开销：每次 CUDA kernel 调用有固定延迟 •流水线气泡：PP 各阶段等待前驱 •通信开销：All-Reduce 占用 GPU 时间 •非矩阵运算：LayerNorm、Softmax、激活函数等
3. 矩阵分块约束：Tensor Core 要求特定分块大小才能达到峰值。例如 MMA 指令每次处理 16 × 16 × 16 分块（H100 FP16）。若矩阵维度不是分块倍数的整数倍，尾块利用率骤降。尤其是最后一层的投影矩阵维度较小，无法填满。
4. Roofline 模型：H100 BF16 稠密峰值 989.5 TFLOPS，岭点约 295 FLOP/B（推导在 04-03）。算术强度高于岭点为计 算密集，低于岭点为内存带宽受限。
5. Decode 阶段为何算力浪费：Decode 每步仅产生 1 个 token，算术强度约 1 FLOP/B，吞吐仅为峰值的 0.34%。这也 是推理优化聚焦 KV Cache 和批处理的原因。H20 的 4.0 TB/s HBM 带宽在此场景下略有优势（4.0/3.35 ≈ 1.19×），但算 力仅为 H800 的 15%，纯内存受限场景下 H20 的 decode 延迟与 H800 接近。
6. 训练前向：大 batch 线性层算术强度约等于 d （通常数千），远高于岭点，为计算密集；小 batch 则落入内存密集 区。 ff 示例 1 H800 SXM BF16 Tensor Core 峰值 989.5 TFLOPS。某矩阵乘法 kernel 实测达到 692 TFLOPS，则有效算力占比： Effective = = 0.70 = 70%

989.5 这是典型的“良好优化”水平。剩余 30% 损耗来自 kernel 启动开销、wave 尾块不饱和和内存带宽受限的辅助算子。 H800 的 NVLink 减半（8 links vs H100 的 18 links）不影响单卡矩阵乘法利用率，但会降低分布式训练时的整体 MFU。 示例 2 同一 kernel（相同算法、相同 batch size）在 H20 上运行。H20 BF16 峰值 148 TFLOPS，若同样达到 70% 有效利用 率： Effective H20 = 0.70 × 148 = 103.6 TFLOPS H20 的绝对有效 TFLOPS 仅为 H800 的 15%。但 H20 的 HBM 带宽更高（4.0 vs 3.35 TB/s），内存受限的 kernel（如 LayerNorm）在 H20 上反而更快。实际训练场景中，H20 的有效利用率可能略高于 H800（内存受限算子占比越高，H20 的带宽优势越明显），但总体训练吞吐差距仍在 5× 到 7× 之间。 示例 3 考虑一个仅执行逐元素加法（如 LayerNorm 的残差连接）的 kernel。算术强度约 1 FLOP/byte。H800 HBM3 带宽为 3.35 TB/s： Max GFLOPs = 1 FLOP/byte × 3350 GB/s = 3.35 GFLOPs

3.35 × 109

989.5 × 1012

                                       Utilization =                = 0.00034%

这个 kernel 仅用到了 GPU 峰值算力的 0.00034%，是纯内存带宽受限的极端案例。大部分归一化算子（LayerNorm, RMSNorm）落入此区间，这也是它们在大模型训练中占比虽小却不能忽视的原因。 关键结论：理论算力是上界，有效算力由内存带宽、矩阵尺寸和通信开销共同决定。大 batch 趋于计算密集，小 batch 趋于内存密集。H800 与 H20 的取舍：H800 计算峰值 6.7× H20，适合训练；H20 的 HBM 带宽 1.19× H800，在内存受限算子（如 decode）中略有优势。

17.5.2 MFU 定义与计算

MFU（Model FLOPs Utilization）是衡量训练效率的核心指标：实际每秒有效 FLOPs 占理论峰值 FLOPs 的比例。 actual_FLOPs_per_second MFU = theoretical_peak_FLOPs_per_second

1. 两种计算方式
2. 方法一：从训练日志反推（最常用）。已知每秒处理的总 token 数和模型非嵌入参数：

                                      actual_FLOPs/s = tokens/s × 6 × Pnon_embed
                                                           tokens/s × 6P
                                              MFU =

NGP U × peak_per_GPU 3) 方法二：从 Profiler 直接读取。Nsight、Nsys 可报告 GPU 周期内实际执行的 FLOPs。 4) 工作示例 LLaMA-7B 在 8×H800 上训练：

 # Given
 tokens_per_second = 40000   # total across 8 GPUs
 P_non_embed = 6.74e9        # 7B minus embedding params
 N_gpu = 8
 peak_per_gpu = 989.5e12     # H800 BF16
 flops_per_token = 6 * P_non_embed # ≈ 4.04e10
 total_flops = tokens_per_second * flops_per_token # ≈ 1.62e15
 flops_per_gpu = total_flops / N_gpu # ≈ 202.25e12 (TFLOPS)
 MFU = flops_per_gpu / peak_per_gpu   # ≈ 0.204 ▶ 20.4%

5. 业界 MFU 基准 业界公开的 MFU 基准如表17-57所示。 表17-57 业界 MFU 基准 模型/规模 硬件 MFU 来源 GPT-3 (175B) V100 约22% OpenAI 2020 Chinchilla (70B) TPUv3 约32% DeepMind 2022 模型/规模 硬件 MFU 来源 PaLM (540B) TPUv4 46.2% Google 2022 LLaMA (65B) A100 约38% Meta 2023 LLaMA-2-70B（单机） A100 约55% 优化后报告 千卡级集群 H100/H800 40-52% 业界大规模训练 DeepSeek-V3 (671B) H800 约43% DeepSeek 2024
6. GPU vs TPU 差异：TPU 架构更简洁，跨芯片互联效率高，MFU 普遍高于 GPU。GPU 需借助 FlashAttention、fused kernels、NCCL tuning 等大量优化手段提升 MFU。
7. H800 MFU 惩罚：H800 仅 8 条 NVLink 链路（vs H100 的 18 条），有效 NVLink 带宽约 150 GB/s（vs H100 的 300 GB/s）。TP 通信耗时约为 H100 的 2 倍，DP All-Reduce 同样加倍。在相同配置下，H800 的 MFU 通常比 H100 低 2 到 5 个百分点。H20 的 MFU 与 H100 接近（NVLink 带宽相同），但绝对吞吐仅为 H800 的 15% 到 20%。
8. MFU 计算流程图 从训练日志和 GPU 规格计算 MFU 的流程如图17-23所示。 Training Logs 6P × tokens/s tokens/s, N_GPU = actual FLOPs/s MFU = actual / peak

GPU Spec Sheet N_GPU × peak peak TFLOPS = total peak 图17-23 从训练日志和 GPU 规格计算 MFU 的流程 示例 1 8×H800 训练 LLaMA-7B，观察到的整体吞吐为 40000 tokens/s。每 GPU 吞吐为 5000 tokens/s。 actual_FLOPs_per_GPU = 5000 × 6 × 6.74 × 109 = 2.022 × 1014 FLOPs/s = 202.2 TFLOPS 202.2 MFU = = 0.204 = 20.4% 989.5 这个 MFU 偏低（远低于 30% 到 50% 的业界 SOTA），可能原因：梯度累积不足导致频繁通信、激活重计算策略过激、或 未开启 FlashAttention。 示例 2 MFU 的差异反映了硬件架构（TPU vs GPU）、软件栈质量和工程优化投入三者的综合结果。从 22% 到 55% 的差距，等 价于训练时间差 2.5 倍。 示例 3 给定模型和硬件，可以从目标 MFU 反推预期的 tokens/s： N × peak × MFU tokens/s = 6P 对于 256×H800 训练 70B 模型，假设 MFU=45%（H800 的 MFU 通常比 H100 低约 5 个百分点，此处取保守值）： 256 × 989.5 × 1012 × 0.45 1.140 × 1017 tokens/s = = ≈ 2.71 × 105 6 × 70 × 10 9 4.2 × 1011 即约 271K tokens/s。这是上限估算，实际依赖于并行策略的具体配置。 关键结论：MFU = 。这是全书最常用的效率公式。业界 SOTA 在 30% 到 55% 区间。H800 因 tokens/s×6P NGP U ×peak_per_GPU NVLink 减半，MFU 通常比 H100 低 2 到 5 个百分点；H20 在纯推理场景下 MFU 可能更高（内存带宽优势）。

17.5.3 训练时间公式

1. 核心推导 从全量训练所需总 FLOPs 已知 C total = 6P D 。有效算力 = N × peak × MFU。因此： 6×P ×D Tseconds =

N × peak × MFU 转为天： 6P D Tdays = N × peak × MFU × 86400 2) 实例

 P = 6.74e9      # non-embedding params
 D = 2e12         # training tokens
 N = 256          # H800 GPUs
 peak = 989.5e12 # BF16 per GPU
 MFU = 0.38       # H800 typically 2-5 pts lower than H100
 T_sec = (6 * P * D) / (N * peak * MFU)
 # = 8.088e22 / 9.629e16 = 8.40
 T_days = T_sec / 86400 # ≈ 9.7 days

若将 GPU 翻倍至 512，时间减半至约 4.9 天。若 MFU 优化至 45%，时间降至约 8.2 天。H800 因 NVLink 减半导致通信 占比更高，大规模扩展时 MFU 下降更明显。 3) 对标真实数据 LLaMA-65B 使用 2048×A100-80GB 训练约 21 天：

 P = 65e9; D = 1.4e12; N = 2048
 peak_A100 = 312e12 # BF16
 MFU = 0.55
 T_sec = (6 * 65e9 * 1.4e12) / (2048 * 312e12 * 0.55)
 # = 5.46e23 / 3.51e17 ≈ 1.56

计算值 18 天，与报告 21 天接近，差额来自检查点保存、重启开销和网络波动。 4) 训练时间决定链 训练时间的决定因素如图17-24所示：参数与 token 量决定总 FLOPs，GPU 数量、MFU 与硬件峰值决定有效算力。 Model Params P Total FLOPs 6PD Training Tokens D GPU Count N Training Time T = C / (N×Peak×MFU) MFU Hardware Peak 图17-24 训练时间的决定因素 参数→总 FLOPs→GPU 数量×效率→时间。 示例 1 P = 6.74 × 10 （非嵌入），D = 2 × 10 tokens，N = 256，MFU=38%（H800 保守值）： 9 12 6 × 6.74 × 109 × 2 × 1012 Tseconds = 256 × 989.5 × 1012 × 0.38

8.088 × 1022

9.629 × 1016

8.40 × 105

                                  =                = 8.40 × 105 s
                                  Tdays =                      ≈ 9.7 days

86400 若 MFU 从 38% 提升到 45%，时间降至 9.7 × 0.38/0.45 ≈ 8.2 天。MFU 每提升 10 个百分点，约节省 2 天训练时间。 示例 2 P = 70 × 10 ，D = 3 × 10 （Chinchilla 最优），N = 1024，MFU=38%： 9 12 6 × 70 × 109 × 3 × 1012 Tseconds = 1024 × 989.5 × 1012 × 0.38

1.26 × 1024

3.851 × 1017

3.27 × 106

                                  =                = 3.27 × 106 s
                                  Tdays =                     ≈ 37.9 days

86400 约 38 天。若需缩至 21 天，可将 GPU 翻倍至 2048（线性缩放成立的前提是 MFU 不因扩展而恶化，实际中 DP 增大后通 信占比上升，MFU 可能从 38% 降至 32%）。 示例 3 P = 405 × 10 ，D = 15 × 10 ，N = 16384，MFU=42%（对应 Meta 官方报告的 400-430 TFLOPS/GPU，约 41-43%） 9 12 ： 6 × 405 × 109 × 15 × 1012 Tseconds = 16384 × 989.5 × 1012 × 0.42

3.645 × 1025

6.809 × 1018

5.35 × 106

                                                    =                = 5.35 × 106 s
                                                    Tdays =                      ≈ 62 days

86400 约 62 天。这是 3.6 × 10 FLOPs 级别训练的代价。16384 GPU 规模下，硬件故障、网络波动和检查点开销会使实际时间 再增加 10% 到 15%。 关键结论：T = 。训练时间的三大杠杆：增大 GPU 数量、提升 MFU、升级硬件峰值。H800 6P D 的 MFU 低于 H100，同样 GPU 数量下训练时间约长 5% 到 10%。 days N ×peak×MFU×86400

17.5.4 反推 GPU 数量

给定模型和时间预算，反推所需 GPU 数量是工程规划中最常见的计算。

1. 反推公式 6P D N=

Tseconds × peak × MFU 转换为天： 6P D N= Tdays × 86400 × peak × MFU 2) 示例 LLaMA-70B，30 天 deadline，H800，MFU=38%：

 P = 70e9; D = 2e12; T_days = 30
 peak = 989.5e12; MFU = 0.38
 N = (6 * 70e9 * 2e12) / (30 * 86400 * 989.5e12 * 0.38)
 # = 8.4e23 / 9.736e17 ≈ 863 GPUs

若 MFU 提升至 45%，N ≈ 728 GPUs。H20 场景下（BF16 峰值 148 TFLOPS，MFU 取 40%），相同模型需约 863 × 989.5/148 × 0.38/0.40 ≈ 5490 张 H20，约为 H800 的 6.4 倍。 3) 并行度整除约束 N 必须能被 TP × PP 整除。设 TP=8、PP=4，则每 32 张卡为一个并行组。819 需凑整至 832（26 组 × 32）。实际采购 时应预留 5% 到 10% 冗余。 4) 不同模型的 GPU 需求速查 不同模型在 30 天 deadline 下的 GPU 需求如表17-58所示。 表17-58 不同模型的 GPU 需求速查 模型 Token 量 H800 MFU=38% 30天 H800 MFU=45% 30天 H20 MFU=40% 30天

LLaMA-7B                  2T           147                                            124                   890
LLaMA-13B                 2T           274                                            231                   1,655
LLaMA-70B                 2T           863                                            728                   5,218
LLaMA-405B                15T          23,480                                         19,822                —

H20 的 405B 大规模训练在实践中很少采用（单卡算力太低，需 > 100K 卡），此处不给出估算。 5) 额外考虑 •GPU 故障率：大规模集群日故障率 1% 到 2%，需预留备用卡 •维护窗口：定期固件升级、网络拓扑调整 •检查点开销：写检查点期间 GPU 可能暂停 示例 1 P = 70 × 10 ，D = 2 × 10 ，T = 30 天，H800，MFU=38%： 9 12 6 × 70 × 109 × 2 × 1012 N= 30 × 86400 × 989.5 × 1012 × 0.38

8.4 × 1023 8.4 × 1023

                                   =                             =              ≈ 863

30 × 86400 × 3.760 × 1014 9.736 × 1017 理论值 863 张。取 TP = 8（NVLink 域）、PP = 4（80 层 / 4 = 20 层每阶段），每组 32 张。863/32 ≈ 27 组，向上取整至 27 组： Nactual = 27 × 32 = 864 GPUs 预留约 0.1% 的计算裕量（864 vs 863），建议预留 5% 到 10% 冗余以吸收 GPU 故障（日产约 1% 到 2% 的卡故障）。 示例 2 P = 6.74 × 10 ，D = 2 × 10 ，T = 7 天，H800，MFU=38%： 9 12 6 × 6.74 × 109 × 2 × 1012 N= 7 × 86400 × 989.5 × 1012 × 0.38

8.088 × 1022 8.088 × 1022

                                   =                            =              ≈ 3560

7 × 86400 × 3.760 × 1014 2.272 × 1016 约 3584 张 GPU（取 112 组 × 32）。但问题：7B 小模型在 3500+ GPU 规模下 DP 组过大，跨 IB All-Reduce 严重拖低 MFU。实际 MFU 可能从 38% 降至 22%，导致有效训练时间反而 > 7 天。 更好的策略：放宽 deadline 至 14 天：

8.088 × 1022

                                          N=                                ≈ 1780

14 × 86400 × 3.760 × 1014 约 1792 张（56 组 × 32）。这个规模下 DP 分组更合理，MFU 更可控。 关键结论：N = 6P D T ×peak×MFU ，向上取整至 TP × PP 的倍数，预留 5% 到 10% 冗余。

17.5.5 Step Time 拆解

1. 单步构成 一个训练 step = 前向 + 反向 + 梯度同步 + 优化器更新 + 其他开销： tstep = tf wd + tbwd + tcomm + topt + tother
2. 各阶段耗时估算 以 H800 训练 LLaMA-7B micro-batch B=4、S=4096 为例： •前向计算：FLOPs ≈ 2 × 6.74 × 10 × 4 ≈ 53.9 GFLOPs。纯算力耗时 ≈ 53.9 × 10 /(989.5 × 10 × 0.7) ≈ 78μs。但实 9 9 12 际约 5 到 10 ms，因为内存密集算子（LayerNorm、Softmax）和 kernel 启动开销占主导。 •反向计算：约 2 倍前向 FLOPs，实际约 10 到 20 ms。 •梯度同步：节点内 Ring All-Reduce 约 163 ms（H800 NVLink 有效约 150 GB/s，7B 梯度约 14 GB）。 •优化器更新：逐元素操作，约 1 到 3 ms。
3. 通信重叠 训练 step 的时序如图17-25所示，反向计算与梯度通信在流上重叠。 Training Step Timeline (with overlap) Forward Layer 1-N Backward Layer N-1 GPU 0 AllReduce (hidden) Optimizer Step 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 图17-25 训练 step 时序：反向通信与梯度计算重叠 现代框架通过多 stream 将反向计算与梯度通信重叠。重叠后 step 时间由计算与通信中的较大者决定： tstep = max(tcompute , tcomm_overlapped ) + tnon_overlapped

若 t < t ，通信完全隐藏。若 t > t ，step 时间由通信决定。 comm bwd comm bwd 4) 瓶颈诊断 step time 瓶颈的常见现象、原因与验证方法如表17-59所示。 表17-59 step time 瓶颈诊断表 现象 可能原因 验证方法 tbwd ≫ tf wd × 2 激活重计算开销 关闭重计算对比 tcomm 出现在关键路径上 DP 规模过大或网络拥塞 增大 GA 降低通信频率 tf wd 占比过高 PP bubble 增加 micro-batch 数量 5) 实例 8×H800 NVLink 节点内，单步典型耗时约 150 到 300 ms。跨节点 DP 扩展时，IB 网卡的延时会使 t 增大 3 到 5 倍。 comm 示例 1 配置：B = 4，S = 4096，8×H800 单节点 NVLink 全互联（8 links, 双向聚合 400 GB/s，有效约 150 GB/s）。 6) 前向计算：32 层 transformer，每层含 attention + FFN。总 FLOPs ≈ 2 × 6.74 × 10 × 4 ≈ 5.39 × 10 。有效算力约 9 10 70%（矩阵乘部分），纯计算时间约 5.39 × 10 /(989.5 × 10 × 0.7) ≈ 78μs。但 LayerNorm、Softmax 等算子内存受 10 12 限，实际前向约 8 ms。 7) 反向计算：FLOPs 约为前向的 2 倍（梯度 + 激活梯度），实际约 16 ms。含激活重计算时可能增至 20 ms。 8) DP All-Reduce（H800 NVLink 有效约 150 GB/s）：7B 梯度约 14 GB，节点内 Ring All-Reduce 约 163 ms。层间通信 与反向计算重叠后，关键路径上有效暴露约 54 ms。 H800 vs H100 对比：H100 的 NVLink 有效带宽约 300 GB/s，相同场景下 All-Reduce 约 79 ms，暴露约 27 ms。 H800 的通信时间长约 2 倍，step time 从 H100 的 30 ms 增加到约 56 ms。 9) 有效 step time（含通信重叠）： step ≈ max(8 + 16, 54) + 2 ≈ 56 ms tH800 其中 +2 ms 为优化器更新开销。对比 H100 的典型值 30 ms/step，H800 几乎翻倍，根源是 NVLink 带宽减半。 示例 2 相同工作负载扩展到 4 节点 × 8 GPU，IB 50 GB/s 每端口。 计算的单卡时间不变：前向 8 ms + 反向 16 ms = 24 ms。 DP All-Reduce（32 GPU，Ring 算法，BW ≈ 50 GB/s 每 GPU 单向）： eff data = 2 × × 13.48 ≈ 26.1 GB 26.1 Tcomm = ≈ 0.522 s = 522 ms 通信时间（522 ms）远超计算时间（24 ms），形成“通信墙”。此时 GPU 绝大部分时间在等待网络，有效 step time 约 540 ms。与单节点 56 ms 相比，吞吐仅提升 56/540 × 32/8 ≈ 42%，而非线性翻 4 倍。H800 因节点内 NVLink 已慢于 H100，跨 IB 后通信占比更严重。 10) 修复：梯度累积 GA = 16，通信频率降至 1/16，有效通信时间约 522/16 ≈ 33 ms，与计算 24 ms 平衡，恢复良好扩 展性。 关键结论：step time 的核心优化是计算与通信重叠。当 t comm ≤ tbwd 时通信对总时间零贡献。

17.5.6 梯度累积策略

梯度累积（Gradient Accumulation，GA）是平衡显存与通信的核心技术。

1. 梯度累积定义 Beff = Bmicro × GA × DP

其中 B 是单卡单步处理的样本数，GA 是累积步数，DP 是数据并行副本数。 micro 2) 梯度累积工作机制 执行 GA 次前向 + 反向（micro-batch 逐一处理），梯度本地累积，GA 步完成后执行一次 All-Reduce。PyTorch 在每次 反向后释放激活值，梯度缓冲区累加。 3) 通信节省 核心收益是降低通信频率：原每 micro-batch 一次 All-Reduce 变为每 GA 步一次。等效通信带宽需求降为原始的 1/GA 。 raw_bandwidth effective_comm_BW_requirement = GA GA=128时，等效通信需求仅为原始的 0.78%，NVLink 轻松覆盖。 4) 学习率调整 增大 B 影响收敛。常见缩放规则如表17-60所示。 eff 表17-60 学习率缩放规则 规则 公式 适用场景 线性缩放 lr ∝ Beff GPT 系列常用 平方根缩放 lr ∝ Beff SGD 优化器 自适应 lr 不变 + warmup Adam 优化器 当 B 从 256 增至 4096，线性缩放法则要求学习率增大 16 倍，通常配合 warmup 防止初期发散。 eff 5) 实例 8×H800 节点，DP=8，B = 1，GA = 128，得 B = 1024。每 128 个 micro-batch 通信一次，通信开销可忽略。 micro eff 6) 局限 •过大 B 可能降低收敛速度或泛化性能 eff •GA 不减少总通信量，仅降低频率 •需额外显存存储累积梯度（通常可忽略） 示例 1 配置：B = 4，GA = 16，DP = 8。 micro Beff = 4 × 16 × 8 = 512 All-Reduce 仅在每 16 个 micro-batch 后执行一次，通信频率降为原始的 1/16。等效通信带宽需求随之降为原始的 1/16 。 对于 7B 模型（梯度 14 GB），8 GPU DP All-Reduce 耗时约 163 ms（H800 NVLink 150 GB/s）。不使用 GA 时，每 24 ms 计算后即触发一次 163 ms 通信，通信占比约 163/(24 + 163) = 87%。使用 GA = 16 后，每 24 × 16 = 384 ms 计算后才触 发一次 163 ms 通信，通信占比降至 163/(384 + 163) = 30%。 示例 2 70B 模型（梯度 140 GB），64 GPU 跨 IB DP。不使用 GA 时，每 GPU 所需有效通信带宽： 2 × 63 × 140 GB BW_needed = Tcompute 若T compute ≈ 100 ms ： 275.6 GB

0.1 s

                                                            BW_needed =                            ≈ 2756 GB/s

远超单 IB 端口 50 GB/s，即使用 8 条 IB rail 聚合也仅 400 GB/s，仍差 7 倍。 使用 GA = 16 后，等效 T 变为 100 × 16 = 1600 ms：compute 275.6 GB

1.6 s

                                                             BW_needed =                           ≈ 172 GB/s

4 条 IB rail（200 GB/s）即可满足，大幅降低网络要求。GA 的“代价”是有效 batch size 和收敛行为改变（需配合学习 率调整），但这是跨节点 DP 扩展中代价最小的杠杆。 关键结论：effective_comm_BW = raw_BW/GA。梯度累积以降低通信频率为代价换取更大等效 batch，适合 DP 规模较小的场景。

17.5.7 Micro Batch 约束

micro batch 大小受到显存和并行策略的双重约束。

1. 显存约束 MGP U − Mweights_opt_grads Bmicro,max = ⌊ ⌋ Mact_per_token LLaMA-7B 示例（ZeRO-3 8 卡）：

 M_per_gpu = 80e9        # H800 80GB
 M_wog = 13.5e9           # ZeRO-3 weights+opt+grads
 M_avail = 66.5e9         # available for activations
 M_act_per_token = 0.5e6 # ~0.5 MB with recompute
 B_max = 66.5e9 / 0.5e6 # ≈ 133,000 tokens total
 B_micro_max = B_max / S # ≈ 32 for S=4096

实际中 B 通常取 1 到 16，远低于硬上限，受训练稳定性约束。 micro 2) 全局 Batch 下限 Token 总量 B × S 低于约 256K 时收敛质量下降。对 S = 4096，B global global ≥ 64 。 3) PP 约束 1F1B 调度要求 micro-batch 数 ≥ PP 阶段数： Bmicro × GA ≥ P Psize 示例：8 卡 TP=4、PP=2、DP=1，需 ≥ 2 个 micro-batch。若 B micro = 1 ，需 GA ≥ 2。 4) 常见约束汇总 micro batch 的各类约束如表17-61所示。 表17-61 Micro Batch 约束汇总 约束 公式 说明 显存上限 Bmicro ≤ Mavail /(S × Mact ) 单步激活值需装进 GPU 全局 batch 下限 Bmicro × GA × DP × S ≥ 256K 收敛质量保证 PP 下限 Bmicro × GA ≥ PP 1F1B 调度要求 PP 效率上限 Bmicro × GA ≥ 4 × PP 减少 bubble，提升流水线利用率 5) 典型配置

 # 8×H800
 B_micro = 4
 GA = 32
 B_eff = 4 * 32 * 8 = 1024
 # Global tokens = 1024 * 4096 ≈ 4.19M ✓
 # PP constraint: 4*32=128 >= 1 ✓

示例 1 配置：LLaMA-70B，8×H800 (80 GB)，TP = 8，DP = 1，PP = 1。 每 GPU 权重内存（BF16）：70 B × 2 bytes/8 ≈ 17.5 GB。 优化器状态（Adam, FP32）：70 B × 12 bytes/8 ≈ 105 GB。 6) 问题：17.5 + 105 = 122.5 GB > 80 GB，即使 TP=8 也无法将 70B 装进单卡。这是因为 Adam 优化器状态（FP32 的动 量 + 方差 + 参数副本）占 12 字节/参数，是权重本身的 6 倍。 7) 必须启用 ZeRO-1（优化器状态分片到 DP 卡上）。设 DP = 4： 每 GPU 优化器状态：70 B × 12/(8 × 4) = 26.25 GB。 每 GPU 总内存：17.5 + 26.25 = 43.75 GB。剩余 36.25 GB 用于激活值。 B = 1，S = 4096，激活值约 1 × 4096 × 8192 × 80 layers × 2 bytes/8 ≈ 0.67 GB/step（1F1B 调度下最多存 2 份）。 可容纳。 micro 若 B = 2，激活翻倍至 1.34 GB/step × 2 份 ≈ 2.7 GB，仍在余量内。 micro 结论：70B + TP=8 + DP=4 可行，但需 ZeRO-1 分片优化器。这是最常见的“刚好能跑”配置。 示例 2 64 张 H800：TP = 8（NVLink 域），PP = 4（每阶段 2 张 TP 组 = 16 GPU），DP = 2（2 份数据并行副本）。 每 GPU 权重（TP=8 切分 + PP=4 切层）：70 B × 2/(8 × 4) ≈ 4.375 GB。 每 GPU 权重 + 梯度 + 优化器（ZeRO-2, DP=2）：4.375 + 4.375 + (4.375 × 6)/2 = 4.375 + 4.375 + 13.125 = 21.875 GB。 剩余约 80 − 21.875 = 58.125 GB 用于激活值。对 B = 1, S = 4096 绰绰有余。 micro B = 4 时激活约 0.67 × 4 × 2 ≈ 5.4 GB（1F1B 存 2 份），仍然充裕。这个配置在显存上是“高裕量”的，适合需要大 micro-batch 以降低 PP bubble 的场景。 micro 关键结论：micro batch 受显存上限（M ）、收敛下限（256K tokens）和 PP 阶段数三重约束。 avail

17.5.8 并行策略约束

总 GPU 数必须可分解为各并行维度的乘积： N = TP × PP × DP × EP (MoE 含EP) 每维度有实用约束。

1. 各维度约束 各并行维度的实用约束如表17-62所示。 表17-62 并行维度约束 维度 范围 约束原因 TP ≤8 NVLink 域内有效，跨节点性能骤降 PP 1 到L 每阶段至少 1 层，实际 2 到 16 DP ≥1 无上限，最易扩展 EP（MoE） ≈ topk × 2 负载均衡所需
2. 组合约束 64 GPUs 的合法拆分方案如表17-63所示。 表17-63 64 GPU 并行拆分方案 TP PP DP N 适用场景 8 4 2 64 大模型，单层需切分 4 4 4 64 中等模型 8 2 4 64 层数少，单层大 1 1 64 64 纯 DP，小模型
3. 策略选择决策树 并行策略选择决策树如图17-26所示。 Model Size P Fits on 1 GPU? Yes No Pure DP Single layer fits 1 GPU? N = DP

Yes No PP + DP Add TP no TP needed TP ≤ 8, PP ≥ 1 N = PP × DP N = TP × PP × DP 图17-26 并行策略选择决策树 4) 启发式原则

1. DP 优先：计算/通信比最优，优先最大化 DP
2. TP 用于显存：单层参数装不进 1 张卡时启用 TP
3. PP 用于深度：层数太多单卡装不下时启用 PP
4. MoE EP 用于专家：激活参数量远超密集参数时

5. 验证反例 N = 100 GPUs：无法拆分为 TP ≤ 8 的合法组合（TP 取 4/8 均无法整除 100）。应使用 96 或 128 GPUs。 示例 1 全部在 64 颗 H800（8 节点 × 8 GPU）下训练 70B 模型，候选并行方案如表17-64所示。 表17-64 64 GPU 训练 70B 并行方案对比 方案 TP PP DP 通信特征 气泡 适用 A 8 4 2 DP small, TP NVLink-local moderate 推荐 B 4 8 2 TP 轻但 PP 深 大（PP=8 气泡多） 层数极多时 C 8 2 4 DP=4 跨 IB, TP NVLink 小 DP 扩展有限 方案 A（推荐）：TP=8 充分利用 NVLink 域内带宽，每层切分为 1/8 后显存压力小。PP=4 气泡适中（m = 128 微批次时 气泡约 3/128 ≈ 2.3%）。DP=2 跨 IB 通信量极小，可选 GA ≈ 8 进一步降频。 方案 B：PP=8 将 80 层每阶段仅 10 层，气泡大（7/128 ≈ 5.5%，需更多微批次补偿）。TP=4 使每 GPU TFLOPS 利用更充 分（TP 通信更低），但 PP 深的代价通常大于 TP 收益，除非模型 > 200 层。 方案 C：DP=4 跨 IB，每 GPU 2 × 3/4 × 140 = 210 GB All-Reduce 数据，在 50 GB/s IB 上约 4.2 秒。必须用 GA ≥ 64 才 能维持效率。 示例 2 512 GPU 集群拆分 N = 512。取 TP = 8（NVLink 域上限），PP = 8（80 层每阶段 10 层，合理），则： DP = =8

8×8 的跨节点 All-Reduce 量：每 GPU 2 × 7/8 × 140 = 245 GB。IB 50 GB/s 下约 4.9 秒。仍必须靠 GA ≥ 32 降频。 DP = 8 若改为 TP = 8, PP = 4, DP = 16（8 × 4 × 16 = 512），DP=16 使通信量略增（2 × 15/16 × 140 = 262.5 GB，约 5.25 秒），但 PP 气泡从 7/m 降至 3/m，整体效率更优。选择取决于气泡与通信的权衡，需要实测。 关键结论：N = TP × PP × DP ，TP ≤ 8，各维度值须为整数。最大化 DP、用 TP 降显存、用 PP 裁深度。

17.5.9 训练成本估算

1. 基础公式 Cost = NGP U × Thours × price_per_GPU_hour
2. 云 GPU 定价 2025 年参考 2025 年云 GPU 定价参考如表17-65所示。 表17-65 云 GPU 定价参考 GPU 按需（$/h） 预留/承诺（$/h）

H800-80GB                         2.5-4.0                                 1.5-2.5
H20-96GB                          1.0-1.8                                 0.6-1.0
A100-80GB                         2.0-3.5                                 1.0-1.8
A100-40GB                         1.5-2.5                                 0.8-1.5

H800 定价通常略低于 H100（NVLink 减半导致 MFU 略低，云厂商反映在定价上）。H20 单价低但需要更多卡才能 达到相同吞吐。 3) 工作示例 LLaMA-7B：256×H800，10 天，$3/h： Cost = 256 × 240 × 3 = $184, 320 H800 与 H100 算力相同（989.5 TFLOPS），但 MFU 低 2 到 5 个百分点，实际训练时间略长。若用 H20 训练 7B（BF16 148 TFLOPS，MFU≈40%），需约 256 × (989.5/148) × (0.38/0.40) × 0.75 ≈ 1215 张卡。 LLaMA-3.1-405B 估算：总 FLOPs ≈ 3.8 × 10 ，16000×H800，MFU=42%：

 T_sec = 3.8e25 / (16000 * 989.5e12 * 0.42) # ≈ 5.72e6 sec ≈ 66 days
 gpu_hours = 16000 * 66 * 24 # ≈ 25.3M hours
 cost = 25.3e6 * 2.0 # ≈ $50.6M (reserved pricing)

4. 典型模型训练成本估算 典型模型的训练成本估算如表17-66所示。 表17-66 典型模型训练成本估算 模型 GPU 数量 GPU 类型 训练时长 估算成本 LLaMA-7B 256 H800 约10 天 约$184K LLaMA-65B 2048 A100 约21 天 约$2.4M LLaMA-405B 16000 H800 约66 天 约$50.6M GPT-3 175B 约3640 V100 约14 天 约$4.6M Chinchilla 70B 2048 TPUv4 约18 天 约$2.3M Meta 使用自有硬件时实际成本更低。
5. TCO vs 云 云租赁与自建的 TCO 对比要素如表17-67所示。 表17-67 云租赁与自建 TCO 对比 要素 云租赁 自建 电力（$/GPU/天） 含在价格中 约$1.7 (H800 700W, $0.1/kWh) 冷却 含 电力 30%-50% 网络（IB 交换机） 含 $50K+/台 存储（$/GB/月） $0.02-0.10 $0.01-0.05 要素 云租赁 自建 人力运维 含 全职 FTEs 持续利用率超过 60%、周期超过 1 年时，自建方案成本更低。
6. 成本优化杠杆 •提升 MFU：从 30% 到 45% 节省约 33% GPU 时 •预留实例：云端节省 40% 到 50% •队列填充：避免 GPU 空闲 示例 1 256×H800，10 天，按云租赁 $2/h（预留实例）计算： Cost = 256 × 10 × 24 × 2 = $122, 880

若按按需 $3/h 计算则为 $184,320。 自建成本估算（仅电力 + 硬件折旧）：256 卡 × 700W × 24h × 10 天 × $0.1/kWh = $4,301 (电力)。硬件折旧（H800 $25K/卡，3 年折旧）：256 × 25000/(3 × 365) × 10 = $58, 447。总自建约 62, 748。 自建比云租赁节省约 49%（预留实例比较）或 66%（按需比较）。前提是集群利用率足够高（> 60%），否则闲置成本抵 消差价。 示例 2 16384×H800，62 天，MFU=42%： GPU_hours = 16384 × 62 × 24 = 24, 379, 392 ≈ 24.4 M hours 按预留 $2/h 计： Cost = 24.4 × 106 × 2 = $48.8M 这是 self-hosted 的估算。云服务商对大集群通常提供专属折扣（$1.2/h 到 $1.5/h），但仍需 $29M 到 $37M。加上数据准 备、人力、存储等附加成本，总持有成本（TCO）可能达 $70M 到 $90M。 H800 的训练成本约比 H100 高 12% 到 15%（MFU 更低 + 训练时间更长）。 这解释了为何只有少数公司（Meta, OpenAI, Google, Anthropic）能负担百亿参数级训练。 示例 3 7B 模型从头训练：$123K（256 H800 × 10 天）。同等规模微调（LoRA，4×H800 × 2 天）：4 × 48 × 2.5 = $480。 $122, 880 Nbreak_even = ≈ 213 fine_tunes $576 若需超过 213 个独立微调任务（每个针对不同领域/语言/任务），从头训练一个通用基座模型在成本上更优。这还未计入 基座模型可复用于下游任务的长期价值。 成本杠杆：提升 MFU 从 30% 到 50% → GPU 时减少 40% → $123K 降至 $74K。MFU 是成本敏感度最高的单一变量。 关键结论：Cost = GPU_hours × price，成本与 GPU 数量、时间、云定价三者线性相关。MFU 每提升 1% 直接等 价于节省约 2% 到 3% 成本。

17.5.10 并行选择决策

本节给出从模型参数出发，确定 TP、PP、DP 组合的六步框架。

1. 六步决策流程 并行策略六步决策流程如图17-27所示。 Step 1 Single GPU fit? Yes No Step 2 N = DP N_mem = M_total / M_per

_gpu Step 3 N_time from 5.4 Step 4 N = max(N_mem,N_time) Factor: TP×PP×DP Step 5 Verify memory after partitioning Step 6 Verify comm not bottlenec k (Chapter 6) 图17-27 并行策略六步决策流程 2) 完整工作示例 场景：LLaMA-70B，2T tokens，30 天 deadline，H800 GPUs。 Step 1：单卡能否容纳？ M_total = 70e9 * 16 # BF16 weights + BF16 grads + FP32 master + Adam m/v

≈ 1.12 TB >> 80 GB ▶ NO

Step 2：最少显存 GPU 数？（ZeRO-3 + 激活重计算）

 # ZeRO-3: each GPU holds 1
 # Assume 60 GB available per GPU
 M_per_gpu_usable = 60e9
 M_total_per_gpu = 70e9 * 16 / DP
 # N_mem ≈ 70e9*16/60e9 ≈ 19

Step 3：时间要求 GPU 数？ 6 × 70 × 109 × 2 × 1012 N_time = ≈ 863 30 × 86400 × 989.5 × 1012 × 0.38 Step 4：取大值并分解。N = max(19, 863) = 863，凑整至 864（与 TP=8,PP=4 兼容）：

 N = 864
 TP = 8   # NVLink domain
 PP = 4   # ok for LLaMA-70B's 80 layers (20 layers/stage)
 DP = N / (TP * PP) = 864 / 32 = 27

Step 5：验证显存。TP=8 后每层参数切分为 1/8，PP=4 后每卡仅存 1/4 层。

 params_per_gpu = 70e9 * 2 / (TP * PP * DP)    # rough
 # = 140e9 / (8 * 4 * 27) ≈ 162M
 # Activation per step with B_
 # Total << 80 GB ✓

Step 6：通信验证。DP=27 跨节点 All-Reduce 需注意 IB 无拥塞。H800 的 NVLink 有效带宽仅 150 GB/s，TP 通信耗时 为 H100 的 2 倍，需更大 GA 来平衡。 3) 最终配置 最终并行配置如表17-68所示。 表17-68 864 GPU 最终配置 参数 值 GPU 总数 864 (27 nodes × 8 GPUs) TP 8 (node-local) PP 4 DP 27 微 batch 1 GA 128 $B_{eff}$ 3328 4) 参数敏感性 N 对各变量的敏感度如表17-69所示。 表17-69 参数敏感性分析 变量 N 的灵敏度 D 加倍 N 加倍 MFU 从 40% 降至 30% N 增加 33% T 从 30 天缩至 15 天 N 加倍 示例 1 Step 1：总 FLOPs C = 6 × 70 × 109 × 3 × 1012 = 1.26 × 1024 FLOPs Step 2：根据时间反推 GPU（H800, MFU=38%）

1.26 × 1024 1.26 × 1024

                         N=                          12
                                                             =              ≈ 647

60 × 86400 × 989.5 × 10 × 0.38 1.948 × 1018 Step 3：并行度整除。647/32 ≈ 20.2 组（每组 TP=8, PP=4 = 32 卡）。向上取 21 组：N = 672。 Step 4：分解并行度。672 = TP × PP × DP 。候选： •A: 8 × 4 × 21 = 672（DP=21 跨 IB） •B: 8 × 8 × 10.5（不可整除） •C: 4 × 8 × 21 = 672（TP 轻、DP 大） 选择 A：TP = 8, PP = 4, DP = 21。理由：TP=8 用满 NVLink 域，PP=4 气泡可控（3/128 ≈ 2.3%），DP=21 跨 IB 需 GA 辅助。 Step 5：显存验证。每 GPU 权重（TP=8, PP=4）：70B × 2/(8 × 4) = 4.375 GB。优化器+梯度（ZeRO-2, DP=21）： 4.375 × (2 + 12)/21 = 2.92 GB。总计 7.30 GB，远低于 80 GB。激活值：B = 2 约 0.67 × 2 × 2 = 2.7 GB（1F1B）。 可增至 8 以降低 PP 气泡。 micro Bmicro Step 6：通信验证。DP 梯度 All-Reduce（DP = 21）：每 GPU 2 × 20/21 × 140 = 266.7 GB。IB 50 GB/s → 5.33 秒。 GA = 16 → 等效 0.33 秒。TP 通信（H800 NVLink 150 GB/s） ：每层 V = 16 × 1 × 4096 × 8192 × 7/8 ≈ 1.61 GB，80 层 × 1.61 GB ≈ 129 GB，H800 NVLink 150 GB/s ≈ 0.86 秒。PP 通信：可忽略。 layer 计算时间（estimate）：每 micro-batch B = 1, S = 4096 约 150 ms（含重计算）。GA = 16 → 累积计算 2.4 秒。DP 通信 重叠后：t ≈ max(2.4, 0.33 + 0.86) = 2.4 秒。通信占比约 1.19/2.4 = 50%，尚可接受但偏高。 step H800 vs H100 对比：同一配置下 H100 的 TP 通信约 0.43 秒，通信占比仅 0.76/2.4 = 32%。H800 的 TP 通信翻倍 是 NVLink 减半的直接后果。 Step 7：成本校验。672 H800 × 60 天 × 24h × $2/h = $1,935,360。在 $2M 预算内，但余量极小（约 3.2%）。 5) 最终配置： 最终并行配置如表17-70所示。 表17-70 672 GPU 最终配置 参数 值 GPU 总数 672 (21 nodes × 32) TP 8 (node-local NVLink 150 GB/s) PP 4 (20 layers/stage) 参数 值 DP 21 (across IB, GA=16) $B_{micro}$ 2 GA 16 $B_{eff}$ $2 \times 16 \times 21 = 672$ 训练时间 约58 天 (有 2 天余量) 估算成本 约$1.94M 关键结论：$N = \max(N_{mem}, N_{time})$，分解为 TP ≤ 8、$PP \le L$ 的整数乘积。每一步均需验证显存与 通信。H800 通信占比高，TP 通信为 H100 的 2 倍，需更大 GA 补偿。

17.6 网络通信分析

本章将各类并行策略的通信开销逐一量化，回答“通信花多长时间、是否阻塞计算、何时需要升级网络”。覆盖 6 种 NCCL 通信原语的带宽公式，以及 DP/TP/PP/EP/SP 的逐层通信量推导。

17.6.1 通信原语概览

分布式训练中所有通信最终分解为 NCCL 的 6 种原语。以下用 G 表示每个 GPU 上的数据量（字节），N 表示参与 GPU 数 量。

1. All-Reduce：每个 GPU 提供一份数据，所有 GPU 收到求和结果。实现方式主要有 Ring 和 Tree 两种。带宽最优为 Ring 算法：每 GPU 收发各 2 G 字节。 N −1 N
2. All-Gather：每个 GPU 提供 G 字节数据，所有 GPU 收到 N × G 字节拼接结果。每 GPU 收发各 G × N = (N − N −1 1)G 字节。TP 前向中列并行输出使用此原语。 N
3. Reduce-Scatter：All-Gather 的逆操作。每个 GPU 提供 G 字节，先求和再按 GPU 拆分，每个 GPU 收到 G/N 字节。 DP 梯度 All-Reduce 可分解为先 Reduce-Scatter 再 All-Gather。
4. Broadcast：一个 root GPU 发送 G 字节给其余 N − 1 个 GPU。Ring 或 Tree 实现，每 GPU 收 G 字节，root 发 (N − 1)G 字节。
5. P2P（Send/Recv）：点对点传输 G 字节。收发端各 G 字节。PP 阶段边界传输和 TP 中的激活切片均使用 P2P。
6. All-to-All：每个 GPU 向每个目标 GPU 发送不同数据。每 GPU 发 (N − 1)G/N 字节，收 (N − 1)G/N 字节。EP 的 token dispatch 和 gather 均依赖 All-to-All。
7. 通信量与双向带宽对比表： 6 种 NCCL 通信原语的数据移动量对比如表17-71所示。 表17-71 NCCL 通信原语数据量对比 原语 每 GPU 入口 (bytes) 每 GPU 出口 (bytes) 总数据移动 (bytes) All-Reduce (Ring) 2 NN−1 G 2 NN−1 G 2(N − 1)G All-Gather (N − 1)G (N − 1)G N (N − 1)G Reduce-Scatter (N − 1)G/N (N − 1)G/N (N − 1)G Broadcast (Ring) G (each non-root) (N − 1)G (root) (N − 1)G P2P G G 2G All-to-All (N − 1)G/N (N − 1)G/N N (N − 1)G All-Reduce、All-Gather、All-to-All 三种原语的数据流动对比如图17-28所示。 All-to-All All-Gather All-Reduce

GPU0: a0-a3 GPU0: a a,b,c,d GPU0: a sum GPU1: b0-b3 GPU1: b a,b,c,d GPU1: b Each GPU gets result=a+b+c+d a_i,b_i,c_i,d_i GPU2: c0-c3 GPU2: c a,b,c,d GPU2: c GPU3: d0-d3 GPU3: d a,b,c,d GPU3: d 图17-28 All-Reduce、All-Gather、All-to-All 的数据流动对比 使用频率排序：All-Reduce（DP 梯度同步）> All-Gather（TP 前向）> Reduce-Scatter（ZeRO 分发）> P2P（PP 边界）> All-to-All（MoE EP）> Broadcast（权重分发）。

17.6.2 All-Reduce 剖析

All-Reduce 是 DP 训练的核心通信原语，每次 step 都执行一次梯度同步。其性能直接决定 DP 的扩展上限。

1. Ring All-Reduce 算法 Ring 是带宽最优算法，每 GPU 收发各 2 G 字节，All-Reduce 时间： N −1 N N −1 G Tar = 2 ×

× N BWeff 其中 BW 是通信链路的有效单向带宽（考虑协议开销后约 85% 到 90% 物理带宽）。 eff 2) 总线带宽：Ring All-Reduce 的算法带宽等效于一条 BW = × BW 的总线；当 N → ∞ 时 BW → bus N phy bus BW /2，即 Ring 最多利用物理带宽的一半，另一半消耗在逐跳转发上。 2(N −1) phy 3) Tree All-Reduce Tree 用二叉树归约，延迟 O(log N ) 而带宽项固定为 2βM ，大消息利用率差。当 N ≤ 4 时 Tree 比 Ring 快（树深 2，步数 更少）；当 N 很大时 Ring 占优（每步数据量仅 G/N ）。 4) NVLink 与 InfiniBand 对比 节点内（H800）：H800 配备 8 条 NVLink 4.0 链路（H100 为 18 条），双向聚合带宽 400 GB/s（单向物理约 200 GB/s）。 经协议开销后，GPU 间有效单向带宽约 150 GB/s。这是 H100 的一半（H100 有效约 300 GB/s）。8 GPU 全互联无需交换 机。 节点内（H20）：H20 配备 18 条 NVLink 4.0 链路，双向聚合带宽 900 GB/s（单向物理约 450 GB/s），有效约 300 GB/s， 与 H100 持平。H20 的 NVLink 带宽不降级，但计算峰值仅为 148 TFLOPS。 5) 跨节点：InfiniBand NDR 单端口 400 Gbps（64b/66b 编码后有效 约50 GB/s）。8 路 NIC 提供每节点 400 GB/s 聚合带 宽。 6) 实例计算 LLaMA-7B BF16 梯度总大小 G = 14 GB。8 GPU DP 下 Ring All-Reduce： 7 14 × 109 V Link = 2 × TNH800 × ≈ 163ms 8 150 × 109 7 14 × 109 V Link = 2 × TNH20 × ≈ 82ms 8 300 × 109 63 14 × 109 TIB_8node = 2 × × ≈ 551ms 64 50 × 109 H800 的节点内 All-Reduce 约为 H20/H100 的 2 倍（163 vs 82 ms），跨节点 All-Reduce 比 H800 节点内慢约 3.4 倍（vs H100 的 7 倍），因为 H800 节点内 NVLink 本身已较慢。 Ring 与 Tree 两种 All-Reduce 算法的执行步骤对比如图17-29所示。 Tree All-Reduce Ring All-Reduce GPU1 GPU1 GPU2 GPU0 GPU2 GPU0 chunk 1▶2 chunk 2▶3 GPU3 reduce chunk 0▶1 chunk 3▶0 broadcast GPU3 图17-29 Ring(4 GPU) vs Tree(4 GPU) All-Reduce 执行步骤 示例 1 N = 4，G = 14 GB，H800 BW = 150 GB/s 时 Tree 与 Ring 对比： eff 14 × 109 Ttree = 2 × log2 (4) × ≈ 373 ms 150 × 109 3 14 H800 Tring =2× × ≈ 140 ms 4 150 Ring 在 N = 4 时仍比 Tree 快（140 vs 373 ms）。Tree 仅在极小 N 且网络延迟主导时有优势。 选择建议：节点内 All-Reduce 始终用 Ring（NVLink 带宽充足）。H800 的 8-link NVLink 有效带宽 150 GB/s，All- Reduce 时间约为 H100/H20 的 2 倍。N ≤ 4 且跨慢速网络时考虑 Tree。生产环境通常按 rail 拓扑自动选择。 DP

17.6.3 DP 通信分析

DP 通信开销简单：每步一次 All-Reduce 同步梯度。但 DP 规模放大后，通信可能成为瓶颈。

1. 通信量与时间 设模型参数量 P ，DP 组大小 N ，精度为 BF16。每个 GPU 的梯度大小 G = 2P 字节。单步 DP 通信量： DP NDP − 1 VDP = 2 × × 2P bytes

NDP 通信时间（Ring 算法）： NDP − 1 2P TDP = 2 × × NDP BWeff 注意：当 N 较大时 DP ≈ 1，T ≈ 4P /BW ，即 DP 通信时间几乎与 GPU 数量无关。 NDP −1 NDP DP eff 2) 梯度累积降频 每 k 个 micro-batch 执行一次梯度累积，All-Reduce 仅发生一次。等效通信开销降至原来的 1/k： eff TDP = TDP /k 代价是显存额外存储 k − 1 份未归约梯度，且有效 batch size 增大可能影响收敛。 3) 计算通信比 定义 R = T /T ： compute DP •R > 1：计算主导，通信可被计算掩盖 •R < 1：通信主导，GPU 空闲等待 LLaMA-7B 在 8×H800 DP 下的场景（B = 4, S = 4096）： Tcompute ≈ 50ms, TDP ≈ 54ms, R ≈ 0.93 （近平衡） 扩展到 64×H800 DP 跨 IB（BW eff ≈ 200 GB/s 聚合）： TDP ≈ 4 × 14 × 109 200 × 109 ≈ 280ms, R ≈ 0.18 （通信密集） 4) DP 扩展效率 DP 扩展效率 η 的定义： Tcompute_1GPU η= NDP × Tstep_per_GPU 带入 T step = Tcompute + TDP 且T compute = T1 /NDP ： η= 1 + NNDPDP−1 × BWeff ×Tcompute_per_GPU 4P DP 扩展中计算通信比随 GPU 数量的退化过程如图17-30所示，GA 可逆转退化。 N=8 DP N=32 DP N=64 DP Rescue: GA=8 NVLink 150 GB/s IB 200 GB/s agg IB 200 GB/s R≈1.2 R≈0.9 R≈0.5 R≈0.15 图17-30 DP 扩展中计算通信比随 GPU 数量的退化过程 示例 1 N = 8，G = 14 GB，BW = 150 GB/s（H800 NVLink）。 DP eff 7 14 TDP = 2 × × = 0.1633 s ≈ 163 ms 8 150 单 micro-batch 计算时间（B = 4, S = 4096）：前向 8 ms + 反向 16 ms = 24 ms（不含重计算）。 Tcompute 24 R= = ≈ 0.15 TDP R<1时计算无法完全掩盖通信。H800 的通信时间约为 H100（82 ms）的 2 倍，R 从 0.29 降至 0.15。但 GA=4 或以上 可恢复平衡。 H20 对比：H20 的 NVLink 有效带宽 300 GB/s，T DP ≈ 82 ms，R ≈ 0.29，与 H100 持平。H20 在节点内 DP 通信 方面不逊色，但计算吞吐仅为 H800 的 15%。 示例 2 NDP = 64 ，BW eff = 50 GB/s （单端口 IB）。 63 14 TDP = 2 × × = 0.551 s ≈ 551 ms 64 50 R= ≈ 0.044 R = 0.044 ≪ 0.5 ，通信完全主导。GPU 95.6% 的时间在等待 All-Reduce 完成。无效扩展。 示例 3 梯度累积 16 步，每 16 次 micro-batch 计算后才执行一次 All-Reduce： eff 551 TDP = ≈ 34.4 ms 24 × 16 384 R= = ≈ 11.2 34.4 34.4 R = 11.2 ≫ 1 ，通信被大量计算完全掩盖。DP 扩展效率恢复。代价：等效 batch size 增大 16 倍，需配合学习率缩放规 则。 H800 特殊性：H800 节点内 DP All-Reduce 已比 H100 慢 2 倍，跨 IB 后通信墙出现更早。建议在 H800 上将 GA 取得比 H100 大 2 倍作为经验法则。 DP 扩展铁律：R ≥ 0.5 是 DP 有效扩展的底线。低于此值应考虑增大梯度累积、引入 TP 减小组内 DP 规模、或升 级 interconnect（如 NVSwitch 替代 IB）。H800 因 NVLink 减半，DP 扩展效率天然低于 H100/H20，需更大 GA 补偿。

17.6.4 TP 通信分析

TP 将每层权重按列或行切分到多个 GPU。每个 transformer 层的前向传播涉及两种通信操作。

1. f 与 g 操作 Megatron-LM 定义的两种操作： •f （列并行线性层）：权重按列切分。前向：每个 GPU 计算 Y = XW ，然后 All-Gather 拼接输出。每 GPU 收发量： 字节。 i i TP −1 2× × BSd model •g（行并行线性层）：权重按行切分。前向：每个 GPU 计算 Y = X W ，然后 All-Reduce 求和。每 GPU 收发量与 f 相 TP 同。 i i i
2. 每层通信量 单层 transformer 含 attention 和 FFN 两个模块，每个模块前后各一对 f /g，每层共 4 对。前向加反向共 8 次通信。每次 f 或 g 通信量： TP − 1 Vf g = B × S × dmodel × 2 × bytes(BF16)

TP 每层总通信量（前向 + 反向）： TP − 1 Vlayer = 8 × Vf g = 16 × B × S × dmodel × TP 3) 实例 B = 1, S = 4096, dmodel = 4096, L = 32, TP = 4 ： Vlayer = 16 × 1 × 4096 × 4096 × ≈ 201.3 MB 总 TP 通信 32 × 201.3 ≈ 6.44 GB。在 H800 NVLink 150 GB/s 下约 42.9 ms；在 H20 NVLink 300 GB/s 下约 21.5 ms。在 IB 50 GB/s 下约 128.8 ms。与单层计算时间约 1.5 ms 相比，H800 TP 通信不可被完全隐藏（42.9ms ≫ 1.5ms），H20 仍 可接受。 4) 为什么 TP 必须绑定 TP 通信量正比于 L × S × d （模型总激活量），而非权重总量。长序列下 TP 通信暴涨。H800 NVLink 提供节点内 150 GB/s 有效单向带宽（8 链路），H20/H100 提供 300 GB/s（18 链路）。跨节点 IB 不仅带宽低（50 GB/s），还引入约 1 model μs 的交换机转发延迟。H800 的 8-link NVLink 使 TP 通信耗时约为 H100/H20 的 2 倍，但仍远优于 IB。 TP 中 f/g 操作的前向通信时序如图17-31所示，f 走 All-Gather、g 走 All-Reduce。 GPU0 (rank 0) GPU1 (rank 1) GPU2 (rank 2) GPU3 (rank 3) f: Column-Parallel Linear (forward)

                    All-Gather activation slice
                                                         All-Gather activation slice
                                                                                            All-Gather activation slice
                                                         All-Gather activation slice

g: Row-Parallel Linear (forward)

                      All-Reduce partial sum
                                                             All-Reduce partial sum
                                                                                              All-Reduce partial sum
                                                             All-Reduce partial sum

GPU0 (rank 0) GPU1 (rank 1) GPU2 (rank 2) GPU3 (rank 3) 图17-31 TP 中 f/g 的前向通信时序 f（All-Gather）与 g（All-Reduce）操作。 示例 1 B = 1, S = 4096, dmodel = 4096, L = 32, TP = 4 。每层 f /g 操作的单次通信量（All-Gather 或 All-Reduce 的每 GPU 收发 量）： TP − 1 3 Vf g = B × S × dmodel × 2 × = 1 × 4096 × 4096 × 2 × TP = 4096 × 4096 × 2 × 0.75 = 25.2 MB 每层 4 对 f /g（前向 attention f + g + 前向 FFN f + g），前向 4 次 + 反向 4 次 = 8 次通信： Vlayer = 8 × 25.2 ≈ 201.3 MB 32 层总 TP 通信量：32 × 201.3 ≈ 6.44 GB。 H800 NVLink 150 GB/s 下：6.44/150 ≈ 0.0429 s = 42.9 ms。H20 NVLink 300 GB/s 下：21.5 ms。 单步总计算时间约 24 ms（前向 8 ms + 反向 16 ms）。H800 的 T ≈ 43 ms > T （24 ms），通信无法被计算完全掩 盖。需通过每层通信与后续层计算重叠来减少暴露。H800 上 TP 通信的“免费午餐”已不存在。 TP compute 示例 2 BW = 50 GB/s（IB）： eff IB TTP = 6.44/50 = 0.1288 s ≈ 129 ms R= ≈ 0.186 通信占总步时的 129/(129 + 24) ≈ 84%。TP 跨 IB 的场景下 GPU 大部分时间在等通信，且 TP 通信频繁（每层都有），无 法像 DP 那样通过 GA 降低频率。TP 跨 IB 在生产中完全不可行。 TP 通信铁律：TP > 1 必须绑定 NVLink（或 NVSwitch）域。跨 IB 的 TP 在 S ≥ 4096 时通信占比超过 80%，实际 不可用。H800 的 8-link NVLink（150 GB/s）使 TP 通信耗时约为 H100/H20 的 2 倍，建议 TP ≤ 4 以控制通信占 比。

17.6.5 PP 通信分析

PP 是通信开销最低的并行策略。只在流水线阶段边界发生 P2P 传输。

1. 通信量 每个 micro-batch 在阶段边界传输激活值：forward 将最后层输出发送给下一阶段，backward 将梯度回传给前一阶段。 每次传输量： Vpp_transfer = Bmicro × S × dmodel × 2bytes(BF16)

每个阶段边界（前向 + 反向）共 2 次传输： Vpp_boundary = 2 × Vpp_transfer = 4 × Bmicro × S × dmodel 对 K 个 PP 阶段，有 K − 1 个边界，总通信： Vpp_total = (K − 1) × 4 × Bmicro × S × dmodel 2) 实例 LLaMA-7B PP = 2, B micro = 1, S = 4096, dmodel = 4096 ： Vpp_total = (2 − 1) × 4 × 1 × 4096 × 4096 × 2 ≈ 134MB 在 NVLink 150 GB/s 下约 0.9 ms；在 IB 50 GB/s 下约 2.7 ms。与每步总计算时间约 50 ms 相比，PP 通信占比不足 5%。 3) 真正的瓶颈 PP 的通信开销本身可忽略。限制 PP 效率的是流水线气泡（bubble），即 pipeline 中 GPU 等待前驱完成的空间段。1F1B 调度下： PP − 1 bubble_fraction = m 其中 m 为 micro-batch 数量。m 越大，气泡越小，但显存占用也越大。 PP 阶段边界的双向激活与梯度传输如图17-32所示。 Fwd: activation Stage 0 BS×d_model Stage 1 Fwd: activation Stage 2 GPU 0-3 Bwd: gradient GPU 4-7 Bwd: gradient GPU 8-11 BS×d_model 图17-32 PP 阶段边界的双向激活/梯度传输 示例 1 PP = 4，K − 1 = 3 个阶段边界。B = 2, S = 4096, d micro model = 8192 。 每个边界每个 micro-batch（前向 + 反向）传输量： Vpp_boundary = 4 × 2 × 4096 × 8192 × 2 ≈ 537 MB 3 个边界总通信量：3 × 537 = 1.61 GB。 跨 IB（50 GB/s）时：T = 1.61/50 ≈ 0.032 s = 32 ms。 PP 单步计算时间（1F1B, m = 16 微批次）：每个 micro-batch B = 2, S = 4096 约 80 ms（70B 模型），16 个 micro-batch 总计算约 16 × 80 = 1280 ms。 RPP = ≈ 40 通信占比仅为 32/(1280 + 32) ≈ 2.4%。PP 跨 IB 几乎不影响总吞吐，验证了“PP 通信可跨任意网络”的结论。 真正的限制在流水线气泡：m = 16 时气泡比例 (4 − 1)/16 = 18.75%。更值得优化 m 而非通信。 PP 通信结论：PP 通信量通常不超过总计算时间的 1%。跨 IB 部署 PP 完全可行。瓶颈始终在气泡，不在带宽。

17.6.6 EP 通信分析

MoE 模型中，每个 token 仅激活部分 expert。Expert Parallelism 将不同 expert 分布在不同 GPU 上，每层需通过 All- to-All 完成 token dispatch 和 result gather。

1. All-to-All 通信 设 EP 组大小 N 。每 GPU 有 N − 1 个 peer。每个 token 的 hidden states（d 维 BF16）被路由到特定 expert GPU。每 GPU 发送量： EP EP model NEP − 1 Va2a = B × S × dmodel × × 2bytes

NEP 每个 MoE 层前向需 2 次 All-to-All（dispatch + combine），反向再加 2 次，共 4 次。每 MoE 层总通信： NEP − 1 Vmoe_layer = 4 × Va2a = 8 × B × S × dmodel × NEP 2) DeepSeek-V2 实例 NEP = 64, B = 1, S = 4096, dmodel = 4096 ，BF16： Va2a = 1 × 40962 × × 2 ≈ 33.1MB DeepSeek-V2 约有 24 个 MoE 层（交错排列），每层 4 次 All-to-All： Vep_total = 24 × 4 × 33.1 ≈ 3.18GB NVSwitch 域（400 GB/s）内约 8 ms；跨 IB 约 64 ms。单节点内 EP 可行，跨节点需谨慎。 3) 负载不均衡问题 MoE 路由可能导致某些 expert 收到的 token 远多于其他 expert（“热门 expert”效应）。负载不均使部分 All-to-All 传输 数据量增大，造成 straggler。实际有效带宽通常低于理论值。辅助负载均衡损失函数（auxiliary load balancing loss） 可缓解，但无法消除。 MoE 层 token 经 All-to-All 路由到 expert GPU 的通信过程如图17-33所示。 Tokens (GPU k) Router Expert GPU 0 Expert GPU 1 Expert GPU 2 Token hidden states

                                                          All-to-All: dispatch to expert 0
                                                                           All-to-All: dispatch to expert 1
                                                                                               All-to-All: dispatch to expert 2
                                              All-to-All: gather results
                                                            All-to-All: gather results
                                                                               All-to-All: gather results

Tokens (GPU k) Router Expert GPU 0 Expert GPU 1 Expert GPU 2 图17-33 MoE 层 token 经 All-to-All 路由 token 经 All-to-All 路由到 expert GPU 的通信过程。 示例 1 Mixtral 使用 8 个 expert（N = 8），每 token 激活 top-2。B = 32, S = 4096, d EP model = 4096 ，BF16。 每 GPU 每 MoE 层的 All-to-All 发送量（一次 dispatch）： NEP − 1 7 Va2a = B × S × dmodel × × 2 = 32 × 4096 × 4096 × × 2 NEP = 32 × 40962 × 0.875 × 2 ≈ 0.94 GB Mixtral 每层 MoE 需 2 次 All-to-All（dispatch + combine），前向 + 反向共 4 次： Vmoe_layer = 4 × 0.94 = 3.76 GB Mixtral 共 32 层，每层均为 MoE 层：总 EP 通信 32 × 3.76 = 120.3 GB。 H800 NVLink 150 GB/s：T = 120.3/150 ≈ 802 ms。 EP 单步计算时间（32 MoE 层 + attention）：B = 32 时约 600 ms（估算）。 R= ≈ 0.75 EP 通信占比约 802/(802 + 600) ≈ 57%。在 H800 节点内，N = 8 的 EP 已接近瓶颈（R < 1），需要更大 batch 或降低 EP 规模。若 B 降至 8，计算时间约 150 ms，R 降至 150/802 ≈ 0.19，EP 通信完全主导。 EP H800 vs H20：H20 的 NVLink 300 GB/s 下 T ≈ 401 ms，R ≈ 1.5，EP 在 H20 上更宽松。 EP 4) 关键启示：EP 需要大 batch 来保证足够的计算密度以覆盖 All-to-All 开销。 EP 通信铁律：All-to-All 是 O(N × BSd) 量级，比 DP 的 All-Reduce 更重。N > 8 时跨节点 EP 通常不可行， 坚持跨节点则需大 batch 或降低路由 top-k 以控制通信量。 EP EP

17.6.7 SP 通信分析

Sequence Parallel 将长序列沿 S 维度切分。Ring Attention 是当前主流方案，通过环形传递 K/V 实现完整注意力计算。

1. Ring Attention 原理 SP 个 GPU 各持 S/SP 长度的序列片段。每 GPU 计算本地 QKV 后，需与其他 GPU 的 K、V 交互才能获得完整注意力输 出。K 和 V 沿环形旋转 SP − 1 步，每步每个 GPU 发送自身 K/V 并接收邻居的 K/V。 每步传输量（仅 K 和 V，不含 Q）： S Vstep = 2 × B × hkv ×

× dhead × 2bytes(BF16) SP 总传输 SP − 1 步，每步每个 GPU 收 + 发各一份： Vring = (SP − 1) × 2 × Vstep 化简为： Vring = (SP − 1) × 4 × B × S × dkv /SP 2) LLaMA-3-70B GQA 实例 SP = 8, B = 1, S = 128K, dkv = 1024 （GQA 下 h = 8, d kv head = 128 ）： Vring = 7 × 4 × 1 × 131072 × 1024/8 ≈ 0.47GB 80 层总 SP 通信 80 × 0.47 ≈ 37.6 GB。H800 NVLink 150 GB/s 下约 251 ms；IB 50 GB/s 下约 752 ms。若单层计算约 2.5 ms（128K 上下文），IB 下通信是瓶颈。 3) SP 对带宽的强依赖 SP 通信量与序列长度 S 成正比。S = 1M 时通信量约 S = 128K 时的 8 倍。超长上下文训练必须结合 SP + TB（Tensor Broadcast）或 DeepSpeed Ulysses 以分摊通信负担。 Ulysses（All-to-All 方案）：将序列沿 S 维度切分后，用 All-to-All 交换注意力头维度的数据。通信量类似但拓扑不同，适 用于 SP × d ≈ d 的场景。 head model Ring Attention 中 K/V 沿环形旋转两步（SP=4）的示意如图17-34所示。 Step 2 Step 1 GPU1: K2,V2 GPU2: K3,V3 GPU1: K1,V1 GPU2: K2,V2 GPU0: K1,V1 GPU3: K0,V0 GPU0: K0,V0 GPU3: K3,V3 图17-34 Ring Attention 中 K/V 沿环形旋转 2 步（SP=4） 示例 1 GQA 配置：h = 8, d = 128, d = h × d kv head kv kv head = 1024 。B = 1, S = 131072（128K）。 每 GPU 每步传输量（只传 K 和 V，不含 Q）： 131072 Vstep = 2 × 1 × 8 × × 128 × 2 = 2 × 1 × 8 × 16384 × 128 × 2 = 67.1 MB SP − 1 = 7 步，收 + 发各一次： Vring_per_layer = 7 × 2 × 67.1 ≈ 0.94 GB 80 层总 SP 通信：80 × 0.94 = 75.2 GB。 H800 NVLink 150 GB/s：T = 75.2/150 ≈ 0.501 s = 501 ms。 N V Link SP 单层计算时间（128K 上下文 + GQA，B = 1）：约 2.5 ms。80 层总计算约 200 ms。 R= ≈ 0.40 ，通信占比 501/(200 + 501) ≈ 71%。在 H800 当前配置下 SP 通信已是严重瓶颈。若 S 扩展到 256K，V 翻倍 R ≈ 0.40 至 134 MB，总 SP 通信 150 GB，T ≈ 1.0 s，R 降至 0.20。 step SP H20 NVLink 300 GB/s：T ≈ 250 ms，R ≈ 0.8，SP 在 H20 上仅接近瓶颈而非严重过度。 SP 跨 IB（50 GB/s）：T = 75.2/50 ≈ 1.5 s，R = 200/1500 ≈ 0.13。SP 跨 IB 在 128K 上下文下已不可用。 IB SP SP 通信铁律：SP 通信量与 S 正比，长上下文场景下比 TP 更重。S > 64K 且 SP > 4 时跨 IB 部署 SP 通信占比超 60%。优先在 NVLink 域内使用 SP。

17.6.8 混合并行通信

真实训练场景中，TP、PP、DP、EP 同时生效。每种策略有独立的通信时间和计算重叠机会。

1. 典型配置分解 以 64×H800、LLaMA-70B 为例：TP = 4, PP = 2, DP = 8。每个 PP stage 内有 TP × DP = 4 × 2 = 8 GPU 分两 TP 组（每组 4 GPU），DP 跨两组和阶段。 local 单步通信构成： •TP（节点内）：每 transformer 层 4 对 f /g，70B 模型 L = 80。d ≈ 8192。每层 V ≈ 16 × 1 × 4096 × 8192 × 3/4 ≈ 1.6 GB。80 层约 128 GB。H800 NVLink 150 GB/s 下约 853 ms。可与计算重叠约 50%。 model layer •PP（阶段间）：2 个 PP 阶段的 1 个边界，每 micro-batch 约 134 MB，跨 IB 约 2.7 ms，可忽略。 •DP（跨节点）：70B BF16 梯度 G = 140 GB。8 GPU Ring All-Reduce 每 GPU 约 245 GB 传输量。IB 50 GB/s 下约 4.9 s。这是主要瓶颈。
2. 总步长时间 假设计算时间 T = 500 ms（经验值），通信可与计算重叠： compute Tstep = max(Tcompute , TTP , TDP ) ≈ max(500, 853, 4900) ≈ 4900ms

DP 通信占绝对主导。解决方案：

1. 梯度累积 k = 16：等效 DP 通信降至 306 ms，但 TP 通信 853 ms 成为瓶颈
2. 减少 TP 规模：TP = 2 时 TP 通信量降至约 64 GB/430 ms，但仍大
3. 减少 DP 规模 + 增大 GA：TP = 2, DP = 32，DP 通信加倍但 GA 可降频 H800 的特殊挑战：H100 上 TP 通信约 427 ms 可被计算完全覆盖；H800 上 853 ms 无法完全覆盖，TP 成为 DP 以外的第二瓶颈。

3. 并行分解优化公式 给定总 GPU 数 N 和拓扑约束： N = NTP × NPP × NDP × NEP

目标是最小化 T 。两个经验法则：step •TP 优先在 NVLink 域内完成（N ≤ 8） TP •DP 通信量 O(1)，但跨 IB 时延迟高；N 尽量小，辅以梯度累积 DP 混合并行下单步各通信阶段的时间线（未重叠）如图17-35所示，DP 通信占主导。 Step Timeline (TP=4, PP=2, DP=8, 70B) Fwd+Bwd Stage 0 Compute Fwd+Bwd Stage 1 TP Comm f/g Ring (NVLink) DP Comm All-Reduce (IB) 图17-35 混合并行下单步各通信阶段的时间线（未重叠） 示例 1 N = 64，分解为 TP = 4（单节点 NVLink），PP = 4，DP = 4（跨 IB）。 4) 计算时间（单 micro-batch B = 1, S = 4096）： 70B × 6 × 2/(64 × 989.5 × 10 × 0.7) → 每 micro-batch 约 120 ms（含重计算）。GA = 8 时累积计算 8 × 120 = 960 ms 。 5) TP 通信（H800 NVLink 150 GB/s）： 每层 V = 16 × 1 × 4096 × 8192 × 3/4 ≈ 1.61 GB。80 层共 128.8 GB。128.8/150 ≈ 0.859 s = 859 ms。与计算重叠约 60% → 有效暴露约 344 ms，在 GA = 8 下 TP 通信发生在每个 micro-batch 的每层。H800 上 TP 通信暴露量是 H100 的 layer 2 倍。 6) PP 通信：3 个边界 × 8 micro-batch × 4 × 1 × 4096 × 8192 × 2 ≈ 6.45 GB。IB 50 GB/s → 129 ms。占 960 ms 总计算 的 13%，可接受。 7) DP 通信（跨 IB，DP = 4，G = 140 GB）： 3 140 TDP = 2 × × ≈ 4.2 s 4 50 这是通信瓶颈。用 GA = 8 降频到每 960 ms 计算后一次： eff TDP = 4.2/8/4 = 0.131 s = 131 ms （除以 8 是 GA，除以 4 是每个 DP 副本内 4 GPU 共享 IB 带宽的粗略估计）。 8) 总步长（H800）： Tstep ≈ 960 + max(0, 344 + 131 − 960) = 960 ms DP 通信被计算覆盖，但 TP 暴露 344 ms 已成为瓶颈。配置在 H800 上勉强平衡，比 H100 差约 20% step 效率。 H800 vs H100 关键差异：H100 上该配置 TP 暴露仅 172 ms，T step ≈ 960 ms 完全计算主导。H800 上 TP 通信翻 倍后成为不可忽视的第二瓶颈。 示例 2 若 GA = 1，B = 1 × 1 × 4 = 4（< 256K tokens 下限，本身就不合理）。 eff 计算时间：仅 120 ms。 DP 通信：T = 4.2 s。 DP R= ≈ 0.029 Tstep ≈ 4.2 s 通信占比 4200/(4200 + 120) ≈ 97%。GPU 几乎完全闲置。这个配置在实际训练中不可用。 混合并行铁律：T 由最慢的通信阶段决定。跨 IB 的 DP All-Reduce 通常是瓶颈。先用 TP 耗尽 NVLink 带宽， DP 跨 IB 用梯度累积降频，PP 几乎是免费的。H800 因 NVLink 减半，TP 通信可能成为仅次于 DP 的第二瓶颈，建 step 议 TP ≤ 4 在 H800 上。

17.6.9 通信占比分析

当通信时间占总步时过半，GPU 扩展进入“通信墙”区域。本节量化不同扩展模式下通信占比的增长规律。

1. 弱扩展 弱扩展下每 GPU 的计算量不变（如每 GPU B = 4），仅增加 GPU 数量以支撑更大全局 batch。此时： •DP：梯度大小不变（模型未变），Ring 时间 ≈ 4P /BW ，几乎不随 N 增长。通信占比 ≈ 为常数。DP 弱扩 eff 4P /BWeff 展通信天然友好。 Tcompute •TP：S 不变但 d 不变，TP 通信量不变。通信占比恒定。 model •PP：通信量不变，气泡占主导。
2. 强扩展 强扩展下全局 batch 固定，N 增大时每 GPU 计算量按 1/N 递减。通信量不变但计算时间骤降： Tcomm Rcomm = Tcomm + Tcompute /N

当 N 足够大时 R → 1，增加 GPU 不再缩短训练时间。 comm 3) 关键 GPU 数（DP 场景）： BWeff × Tcompute_1GPU Ncrit = 4P 超出 N 后通信占比超 50%。以 LLaMA-7B、BW crit eff = 150 GB/s（H800 NVLink）、T compute_1GPU = 50 ms 为例： 150 × 109 × 0.05 Ncrit = ≈ 13 4 × 14 × 109 弱扩展到 27 GPU 前 DP 效率良好；强扩展到 27 GPU 后每 GPU 计算量已极小，通信开始主导。 4) 各策略通信占比对比 各并行策略的通信量级别与跨 IB 容忍度对比如表17-72所示。 表17-72 各并行策略通信特征对比 策略 通信量级别 对 N 的敏感度 跨 IB 容忍度 DP O(2P ) 每 step 几乎不变 中等（需 GA 辅助） TP 每 step O(L × S × dmodel ) O(1/N ) 低（必须 NVLink） PP O(S × d ) 每 micro-batch model O(1/NPP ) 高（可跨 IB） EP O(S × d ) 每 MoE 层 model O(1/NEP ) 低（N > 8 不可行） EP SP O(S × d ) 每层 kv O(1/NSP ) 低（长 S 不可行） 示例 1 弱扩展：每 GPU B = 4（固定计算量），仅增加 GPU 数以增大全局 batch。 N 从 8 增至 64 时，每 GPU 的 T DP ≈ 24 ms 不变（7B 模型）。 compute Ring All-Reduce 通信量：T ≈ 4P /BW （N 足够大时）。对 7B、H800 NVLink 150 GB/s：T DP ≈ 4 × 14/150 ≈ 373 ms（N = 8 时精确值为 163 ms，趋近于 373 ms 当 N → ∞）。 DP eff Rcomm = ≈ 0.940 373 + 24 在 H800 NVLink 内弱扩展，R 约为 94%，随 N 略微上升（从 N = 8 的 163/187 ≈ 87% 到 N → ∞ 的 373/397 ≈ 94% ）。H800 弱扩展下 DP 通信占比已极高，H100 对应值约 89%。 comm 跨 IB（BW = 50 GB/s）：T ≈ 4 × 14/50 = 1.12 s。R = 1.12/(1.12 + 0.024) ≈ 97.9%。IB 下弱扩展也不乐观， 需 GA 降频。 eff DP comm 示例 2 强扩展：固定全局 batch，N 增大时每 GPU 计算量减半。 基准（H800）：N = 8 时 T = 24 ms，T = 163 ms（NVLink 150 GB/s），R = 163/(163 + 24) = 87.2%。 compute DP comm N = 16：T = 12 ms，T ≈ 2 × 15/16 × 14/150 = 175 ms。R compute = 175/(175 + 12) = 93.6%。 DP comm N = 64：T = 3 ms，T ≈ 2 × 63/64 × 14/150 = 184 ms。R compute = 184/(184 + 3) = 98.4%。 DP comm N = 256：T = 0.75 ms，T ≈ 187 ms。R compute ≈ 99.6%。 DP comm 从 N = 8 到 N = 64，理论加速 = 8×，实际加速 = (24 + 163)/(3 + 184) × 8/64 = 187/187 × 0.125 = 0.125×。增加了 8 倍 GPU 数量，吞吐零提升。这是 H800 强扩展的“通信墙”现象，比 H100 出现更早（H100 在 N = 8 → 64 时实际加速约 0.14×）。 通信占比最小化法则：优先 DP（通信量固定、可梯度累积降频），其次 PP（通信量极小），避免跨 IB 的 TP/SP/EP。NVLink 域内 TP 可接受。

17.6.10 网络拓扑规划

AI 训练集群的网络拓扑影响 All-Reduce 有效带宽，拓扑选择决定 DP 扩展上限。Fat-Tree 以 Leaf-Spine 两级交换实现非 阻塞任意流（1:1 链路提供全二分带宽，2:1 oversubscription 时减半），千卡规模成本高。Rail-Optimized（如 DGX SuperPOD 的 8-rail）让同 rail 的 GPU 仅穿越一个交换机完成 All-Reduce，延迟极小；节点内以 NVLink 全互联、节点间 以 IB 组网，NVSwitch 可将全互联域扩至 576 GPU。

1. 所需带宽公式 根据前述 DP 通信分析，每 GPU 需要的网络带宽： 2 × NNDPDP−1 × 2P BWper_GPU =

Tstep 若T step = 1 s，P = 70B（BF16），N DP = 64 ： 2 × 0.984 × 140 × 109 BWper_GPU = ≈ 276GB/s 1.0 单 IB 仅 50 GB/s，需至少 6 条 IB rail。按 8-rail SuperPOD 可满足。 2) 拓扑选择决策 不同集群规模的推荐网络拓扑如表17-73所示。 表17-73 网络拓扑选择决策 集群规模 推荐拓扑 理由 ≤ 8 GPU NVLink only（单节点） 零交换机，延迟最低 ≤ 64 GPU 2-rail Fat-Tree 2 条 IB，成本可控 ≤ 576 GPU NVSwitch + 8-rail NVSwitch 扩大 NVLink 域

576 GPU 多 pod Fat-Tree 三层 CLOS，逐级收敛 Fat-Tree 与 Rail 两种拓扑的 All-Reduce 路径对比如图17-36所示。 Rail-Optimized (SuperPOD) Node0-GPU0 Rail 0 Switch Fat-Tree (CLOS) Node1-GPU0 Spine 1 Leaf 1 GPU 0,1,2,3 Node0-GPU1 Spine 2 Leaf 2 GPU 4,5,6,7 Rail 1 Switch Node1-GPU1 图17-36 Fat-Tree 与 Rail 的 All-Reduce 路径对比 示例 1 N = 128，7B 模型 G = 14 GB，目标 T DP = 1 s。 step 2 × 127 × 14 GB

1.0 s

                        BWper_GPU =                   = 2 × 0.992 × 14 = 27.8 GB/s

单条 IB NDR （50 GB/s）即可满足 7B 模型的需求。 换成 70B 模型（G = 140 GB）： BWper_GPU = 2 × 0.992 × 140 = 278 GB/s 需要 278/50 ≈ 6 条 IB rail。8-rail SuperPOD（400 GB/s）完全覆盖。 若 T 需要 500 ms（即每秒 2 步），70B 带宽需求翻倍至 556 GB/s，需要 12 条 IB rail — 超过标准 8-rail 拓扑的上限。 此时要么接受 T = 1 s，要么改用 GA 降低 All-Reduce 频率。 step step GA=4 时等效 T = 2 s，带宽需求降至 139 GB/s（约 3 条 rail），8-rail 绰绰有余。网络拓扑设计需要与 GA 策略协同规 划。 step 规划铁律：All-Reduce 有效带宽由单 rail 带宽 × 并行 rail 数决定。每 rail 50 GB/s（NDR），8-rail 提供 400 GB/s 节点间聚合带宽。预算充足时优先选择 Rail-Optimized 方案。

17.7 存储 IO 规划

本章量化训练所需的各类存储开销：数据集、检查点、日志和中间文件。每节从理论公式出发，代入典型训练规模，推导 存储容量和读写带宽需求。

17.7.1 数据集存储量

本节从 token 出发，估算不同规模训练语料的原始存储需求，并覆盖文本、图像、视频等多模态数据场景。

1. Token 到字节的换算 自然语言语料以 token 为基本单元，存储以字节为基本单元。两者间的换算取决于 tokenizer 的压缩率： •英文文本：典型 tokenizer（如 GPT-2/LLaMA 的 BPE）约 4 字符/token。UTF-8 下 ASCII 字符占 1 字节，因此约 4 字 节/token。 •中文文本：约 2 字符/token，UTF-8 下 CJK 字符占 3 字节，因此约 6 字节/token。但大规模训练语料以英文为主 （CommonCrawl 约 85% 英文），保守估算取 4 字节/token。 •代码数据：Python/C++ 等编程语言的 tokenizer 压缩率更低，约 3 字符/token。 全书统一采用保守估计 4 字节/token，涵盖常见混合语料的均值。
2. 原始语料存储公式 设训练总 token 数为 D ，则原始文本语料所需存储： tokens Mdata_raw = Dtokens × 4 bytes/token

以 GB 为单位的表达式： Dtokens × 4 Dtokens × 4 Mdata_raw (GB) = = 10243 230 典型训练规模代入： 典型训练规模的原始文本存储量如表17-74所示。 表17-74 典型训练规模原始存储量 训练规模 Token 数 原始存储 LLaMA-7B（1.0T tokens） 1012 约3.7 TB LLaMA-7B（2.0T tokens） 2 × 1012 约7.5 TB LLaMA-13B/34B 级 1.4 × 1012 约5.2 TB LLaMA-2-70B 2 × 1012 约7.5 TB LLaMA-3.1-405B 1.5 × 1013 约56 TB DeepSeek-V3 1.48 × 1013 约55 TB Chinchilla-optimal（7B 参考） 1.4 × 1011 约520 GB 以 2T tokens（LLaMA-7B 典型规模）为例： 2 × 1012 × 4 Mdata_raw = ≈ 7.45 TB 对于 LLaMA-3.1-405B 级别的 15T tokens（1.5 × 10 ），原始存储约 56 TB。虽然绝对数值不小，但相比几 PB 级别的检 查点和日志，这仍然只是总存储开销的一小部分。 3) 预处理中间文件的膨胀 原始文本在处理为训练就绪格式时，会产生中间文件： •Tokenized 格式：将文本转为 token ID 序列。每个 token 通常以 uint16 （2 字节）或 uint32 （4 字节）存储。与 原始文本（4 字节/token）相比，tokenized 格式为 24 字节/token，并无额外膨胀。 •分片打包：将 token 序列按固定长度（如 4096）打包成连续的 .bin 文件。分片间需小量重叠，通常带来 15% 的额 外开销。 •索引与元数据：每个分片通常伴生 .idx 索引文件，记录文档边界位置。索引文件约占数据文件的 25%。 •拷贝与冗余：实践中通常同时保留原始文本和 tokenized 分片，总存储需求为原始文本的 1.32 倍。 Mtotal = Mdata_raw × foverhead , foverhead ∈ [1.3, 2.0] 以 2T tokens 为例：原始 7.5 TB → 含预处理中间文件后约 1015 TB。 4) 多轮 Epoch 的影响 存储容量与训练 epoch 数无关。数据集存储一次，每个 epoch 重复读取。训练期间的总 IO 量由 epoch 数决定，而非存 储容量： Total_IO = Mtotal × Nepochs Chinchilla 最优条件下 N ≈ 1，此时总 IO 即为数据集大小。实际训练中 N 通常为 14（大规模模型倾向于少 epoch 以避免过拟合）。 epochs epochs 5) 多模态数据的存储差异 非文本模态数据存储需求显著高于文本： 图像数据： •ImageNet-1K（120 万张，平均分辨率 469×387 JPEG）：约 150 GB（含标注）。 •更高分辨率（如 1024×1024 PNG）：单张可达 13 MB，百万张级别即需 TB 级存储。 •常见视觉语料（如 LAION-2B）：数 PB 级别，远超纯文本。 视频数据： 常见视频规格的码率与 1 小时存储量如表17-75所示。 表17-75 视频规格存储量 视频规格 码率 1 小时存储 1080p H.264 约8 Mbps 约3.6 GB 1080p 高质量 约50 Mbps 约22.5 GB 4K H.265 约25 Mbps 约11.3 GB 短视频平台训练数据通常为 1080p 级别，数百万段短视频可轻松积累数十 PB。 音频数据： •16 kHz 采样率、16-bit 编码：1 小时约 115 MB。 •典型语音语料（如 LibriSpeech 约1000 小时）：约 115 GB。 多模态训练存储预算：以 100M 图文对（CLIP 级别）+ 1M 小时视频 + 1M 小时音频为例，总存储需求约为 25 PB，远超 纯文本训练。 6) 数据集存储量速查表 不同数据类型的存储量速查如表17-76所示。 表17-76 数据集存储量速查 数据类型 每 B tokens 存储 典型训练规模 所需存储 纯文本（英文为主） 约4 GB/B tokens 2T tokens 约8 TB 纯文本（大模型级） 约4 GB/B tokens 15T tokens 约60 TB 文本（含预处理） 约6 GB/B tokens 2T tokens 约12 TB 图像（JPEG） — 100M 张 约15 TB 图像（高分辨率） — 1M 张 约3 TB 视频（1080p） 约3.6 GB/h 100K 小时 约360 TB 音频（16kHz） 约115 MB/h 10K 小时 约1.2 TB 示例 1 LLaMA 级别训练使用约 2T tokens。按 4 字节/token 计算原始文本体积： Mraw = 2 × 1012 × 4 = 8 TB 考虑预处理中间文件（tokenized 分片、索引、同时保留原始文本），膨胀系数取 f overhead = 1.5 ： Mtotal = 8 × 1.5 = 12 TB 这约等于 3 块 4TB NVMe SSD。对个人或小团队而言，数据集存储完全可控。 示例 2 LLaMA-3.1 使用 15T tokens，带入同样公式： Mraw = 15 × 1012 × 4 = 60 TB Mtotal = 60 × 1.5 = 90 TB 90 TB 的数据集需要专门的存储阵列（如 24 块 4TB NVMe 的 RAID）。虽然绝对数值不小，但相比检查点开销（数百 TB），它仍只是总存储预算的一部分。 示例 3 多模态数据集 与纯文本不同，多模态数据集的存储需求可远超文本： •100M 张图像，平均 1 MB/张（高分辨率 JPEG/PNG）：100 × 10 × 1 = 100 TB 6 •加上标注元数据（约10% 开销）：约 110 TB 100M 图文对的存储需求（约110 TB）甚至超过了 15T tokens 的文本语料（90 TB）。若加上视频（如 100K 小时 1080p ≈ 360 TB），总存储可达 PB 级别。多模态训练的存储规划必须将图像/视频/音频数据纳入预算。 关键结论：纯文本语料存储需求可控，2T15T tokens 级别仅需 860 TB。真正的存储压力来自多模态语料和下一 节讨论的检查点。 原始文本到训练就绪数据集的存储膨胀路径如图17-37所示。 Raw Text Tokenize Token IDs Pack & Shard Sharded Files ×1.3-2× overhead Training-Ready ~4 bytes/token uint16 per token + Index Dataset 图17-37 原始文本到训练就绪数据集的存储膨胀路径

17.7.2 数据加载带宽

每个训练步消耗的 token 量决定了数据加载的吞吐需求。本节从每步 token 消耗出发，推导不同规模训练场景下的存储 读带宽，并给出存储节点数量的规划公式。

1. 每步 Token 消耗 每个训练步的 token 消耗量为： tokens_per_step = Bglobal × S

其中 B 为全局 batch size（样本数），S 为序列长度（token 长度）。以 LLaMA-7B 典型配置为例：B global = 1024 （micro batch 4 × DP 256），S = 4096： global tokens_per_step = 1024 × 4096 = 4.19 × 106 ≈ 4Mtokens 按 4 字节/token 计算，每步消耗的原始文本约 16 MB。这个数字很小，单步净读入仅数十 MB 量级，对于单步训练时间 1 秒的模型，数据加载带宽仅需 16 MB/s。 2) 大模型级别的数据加载 但上述结论仅在模型较小时成立。当模型规模和训练集群扩大，数据加载需求急剧增长。 考虑 LLaMA-3.1-405B 级别训练： •全局 batch size B = 16Mtokens（S 约为 4096，即约 4000 样本） global •假设单步时间 T = 3s step •GPU 数量 N = 16,000（H800） GP U 每步 token 消耗： tokens_per_step = 16 × 106 tokens/step 总的数据加载速率： Bglobal 16 × 106 tokens_per_second = = ≈ 5.33 × 106 tokens/s Tstep 以 4 字节/token 计，原始文本带宽： Read_BWraw = 5.33 × 106 × 4 ≈ 21.3 MB/s 这仍然不大。关键在于数据分片：16,000 张 GPU 同时从存储读取，每张 GPU 读入自己的 batch 分片。如果数据集未充 分分片，单节点存储的读带宽可能成为瓶颈。 3) Tokenized 数据的读取场景 实际训练中更常见的场景是从 pre-tokenized 分片直接读取 uint16 token ID（每 token 2 字节）。此时每步读取量减半， 但存储系统仍需处理 16,000 路并发读请求： 每 GPU 的读带宽需求（B = 16M，DP=1024）： global Bglobal × 2 16 × 106 × 2 Read_BW_per_GPU = = ≈ 10.4 MB/s DP × Tstep 1024 × 3 单 GPU 的需求微不足道，但 1024 路并发随机读对文件系统元数据服务和 IOPS 提出挑战。 4) 通用读带宽公式 将上述分析提炼为通用公式： Bglobal × S × bytes_per_token Read_BW = Tstep 转换为存储系统规划所需的聚合带宽（tokenized 格式， uint16 ）： Bglobal × 2 Read_BWagg = bytes/s Tstep 各规模训练场景的读带宽速查： 各规模训练场景的数据读带宽如表17-77所示。 表17-77 各训练场景读带宽速查 训练场景 Bglobal Tstep 读带宽（text） 读带宽（tokenized） LLaMA-7B（单机） 4M tokens 1s 16 MB/s 8 MB/s

LLaMA-13B              4M tokens               2s                  8 MB/s                    4 MB/s
LLaMA-70B              4M tokens               8s                  2 MB/s                    1 MB/s
LLaMA-3.1-405B         16M tokens              3s                  21 MB/s                   11 MB/s

DeepSeek-V3（MoE） 8M tokens 约2s 16 MB/s 8 MB/s 注意到一个反直觉的事实：物理数据读带宽从来不是瓶颈。考虑随机访问模式、缓存未命中与并发，文件系统按数 百 MB/s 至数 GB/s 的聚合带宽规划即可；真正的问题是并发随机读的元数据和 IOPS 压力。 5) 分片策略与 IOPS 规划 数据集的存储组织方式直接影响 IOPS 需求： •分片数 >> GPU 数：每张 GPU 随机读取少数分片，减少文件锁冲突。建议分片数 ≥ 10 × DP 。 size •分片大小：通常 64 MB512 MB/分片。过小导致元数据开销；过大则随机读取效率差。 •预读与缓存：现代 DL 框架（PyTorch DataLoader + num_workers ）在 CPU 内存中预取数据，存储 IOPS 与 GPU 计 算不完全耦合。 对于 1024 GPU 集群，推荐分片数 ≥ 10,000，每分片 128 MB，总 tokenized 数据集约 1.3 TB。这带来如下 IOPS 需求： •每个训练步，1024 个 dataloader 各读取 12 个分片（共 1024 × 2 = 2048 次读操作/步） •若 T = 3s，则 IOPS 需求约为 2048/3 ≈ 680 IOPS step •单台 NVMe 服务器可轻松提供 100K IOPS，远远超出 + 真正瓶颈在元数据服务：分布式文件系统（如 Lustre、GPFS）的元数据服务器（MDS）在高并发场景下可能成为瓶颈。 训练集群的存储规划应在 MDS 性能和分片总数之间做折中。 6) 存储节点数规划公式 按聚合读带宽规划存储节点数： Read_BW_required Nstorage ≥ BW_per_storage_node 当引入数据冗余（如 HDFS/CEPH 的 3 副本）时： Nstorage_total = Nstorage × freplication 示例：12.8 GB/s 读需求，每 NVMe 节点 7 GB/s → 需要 ≥ 2 个存储节点。3 副本下 → 6 个节点。 数据从存储分片经 DataLoader 预取到 GPU 的数据流管道如图17-38所示。 Dataset Shard 1 Dataset Shard 2 Dataset Shard K DataLoader Worker 1 DataLoader Worker 2 DataLoader Worker N Prefetch Buffer Prefetch Buffer Prefetch Buffer GPU 0 GPU 1 GPU N 图17-38 数据从存储分片到 GPU 的数据流管道 关键结论：纯文本训练的存储读带宽通常不是瓶颈（单步净读入仅数十 MB 量级）。考虑随机访问模式、缓存未命 中与并发，文件系统按数百 MB/s 至数 GB/s 的聚合带宽规划；真正的挑战来自多万路并发读的元数据压力，以及 下一节讨论的检查点写入。分片数应远大于 GPU 数以降低竞争。 示例 1 LLaMA-7B 典型配置：B global = 4Mtokens ，T step = 1s ，按 4 字节/token 计算： 4 × 106 × 4 Read_BW = = 16 MB/s 单块 SATA SSD（约500 MB/s）即可满足 30 倍余量。即使是最低端的存储设备也不会构成瓶颈。 示例 2 LLaMA-3.1-405B 典型配置：16K GPU，假设单 GPU 吞吐为 200K tokens/s（training throughput per GPU）。按 4 字 节/token 计算聚合数据加载速率： Read_BWagg = 16,000 × 200,000 × 4 = 12.8 GB/s 12.8 GB/s 的聚合读带宽可由少量 NVMe 存储节点承载（单存储节点 7 GB/s 读带宽下需 2 个，3 副本冗余 → 6 个）。这一 量级下物理读带宽仍非瓶颈，所有 GPU 同时随机读取不同分片形成的并发 IOPS 与元数据压力，才是需要分布式文件系 统的真正原因。 注意：此处 200K tokens/s/GPU 为 training throughput 而非推理吞吐。若步时为 3s，等效数据速率为 16,000 × 4 × 10 × 4/3 ≈ 85 MB/s，raw text 视角下仍很小，但所有 GPU 同时随机读取不同分片形成的并发 IOPS 才是瓶颈。 示例 3 若使用 pre-tokenized 数据集（ uint16 存储，2 字节/token），数据加载带宽可减半： 4 × 106 × 2 Read_BWtokenized = = 8 MB/s 对于 405B 级别：16,000 × 200,000 × 2 = 6.4 GB/s。Pre-tokenization 不仅消除了 CPU tokenize 瓶颈，还降低了存储读 带宽需求，一举两得。

17.7.3 CKPT 大小计算

检查点（Checkpoint）通常是整个训练中最大的单项存储开销。理解检查点的组成和大小公式，是存储容量规划的核 心。

1. 检查点的内部组成 一个典型训练检查点包含的组件如表17-78所示。 表17-78 训练检查点组件构成 组件 数据类型 每参数字节数 说明 工作权重 BF16 2 前向/反向使用的工作权重 梯度 BF16 2 反向传播的梯度副本 主权重 FP32 4 优化器维护的 FP32 主副本 优化器动量（m） FP32 4 Adam 一阶矩估计 优化器方差（v） FP32 4 Adam 二阶矩估计 学习率调度器状态 FP32 可忽略 少数 scalar 变量 随机数生成器状态（RNG） 整数 可忽略 每个 dataloader worker 前五项主导检查点大小。混合精度全量口径下，Dense 模型完整检查点（权重 + 梯度 + 优化器状态）合计： Bytes_per_param = BF16_weight(2) + BF16_grad(2) + FP32_master(4) + FP32_m(4) + FP32_v(4) = 16 bytes/param 本书统一采用此系数，即全量检查点大小约 16 字节/参数。
2. Dense 模型检查点大小公式 设模型总参数量为 P ，单个检查点的存储量为： MCKPT = P × 16 bytes

以 GB 表达： P × 16 MCKPT (GB) = 10243 主流 Dense 模型检查点速查： 主流 Dense 模型的检查点大小如表17-79所示。 表17-79 主流 Dense 模型检查点速查 模型 参数量 P 单 CKPT 大小 备注 GPT-2（1.5B） 1.5 × 109 22 GB 小模型基准 LLaMA-7B 6.74 × 109 100 GB 7B 级训练 LLaMA-13B 13.0 × 109 194 GB 13B 级 LLaMA-34B 33.5 × 109 500 GB — LLaMA-2-70B 68.9 × 109 约 1.1 TB 70B 级标准 LLaMA-3.1-70B 70.0 × 109 约 1.1 TB 同上 LLaMA-3.1-405B 405 × 109 约 6 TB 超大模型 Qwen-2.5-72B 72.7 × 109 约 1.2 TB 中文大模型 DeepSeek-V2-Lite 15.7 × 109 234 GB MoE 总参数 注意：LLaMA-7B 对应的计算值为 6.74 × 10 × 16/1024 ≈ 100 GB，实际由于某些框架保存 byte tensor 时可能有少量对 9 3 齐 padding，约 ±5% 浮动。 3) MoE 模型的检查点特殊 MoE 模型必须保存所有专家的完整参数，而非仅激活的 top − k 个专家。 以 DeepSeek-V3 为例： •总参数：671B（671 × 10 ） 9 •单 CKPT 大小：671 × 10 × 16 = 1.07 × 10 字节 ≈ 10 TB 9 13 即使每次前向仅激活 37B 参数，检查点也须保存全部 671B。这是 MoE 架构在存储方面的显著代价。 主流 MoE 模型检查点速查： 主流 MoE 模型的检查点大小如表17-80所示。 表17-80 主流 MoE 模型检查点速查 模型 总参数 P total 激活参数 单 CKPT 大小 Mixtral-8×7B 46.7B 12.9B 约 750 GB Mixtral-8×22B 141B 39B 约 2.3 TB DeepSeek-V2 236B 21B 约 3.8 TB DeepSeek-V3 671B 37B 约 10 TB 4) 分布式检查点格式 检查点存在两种存储形式： Sharded Checkpoint（分片 CKPT）：每个 DP rank 保存其权重和优化器分片。总大小不变，但写入和加载可并行化。 •写入时间：单 GPU 写入 M /DP → 并行写，总时间由最慢节点决定 CKPT size •优势：写带宽需求降低 DP 倍 size Consolidated Checkpoint（合并 CKPT）：将所有权重收集到单个文件。通常用于将模型移动到不同集群做推理。 •需要先做 All-Gather → 额外通信开销 •优势：加载简单，兼容性广 Delta Checkpoint（增量 CKPT）：仅保存权重相对于上一个检查点的变化量。理论可压缩 10100 倍，但实现复杂，框架 支持有限。 三种格式对比： 三种检查点格式的对比见表17-81。 表17-81 检查点格式对比 格式 存储大小 写时间 读时间 适用场景 Sharded MCKPT 短（并行） 短（并行回读） 在线训练重启 Consolidated MCKPT 长（需聚合） 短（单文件） 离线推理迁移 Delta MCKPT /c 短（增量小） 长（需重建） 频繁 checkpoint 5) 检查点文件内部结构 一个典型 DeepSpeed/Megatron 检查点的内部结构： checkpoint_step_1000/ ├── mp_rank_00/ │ ├── optimizer.pt # Optimizer states (m, v) │ ├── model_states.pt # Model weights (bf16) │ ├── random_state.pt # RNG state │ └── user_extra_state.pt # LR scheduler etc. ├── mp_rank_01/ │ ├── optimizer.pt │ └── ... ├── ... └── latest # Pointer to most recent checkpoint 每个 model_states.pt 保存该 rank 上的参数分片， optimizer.pt 保存对应的动量/方差状态。 典型检查点（混合精度全量口径）的体积分解如图17-39所示。 Full checkpoint (16 bytes/param) Weights (BF16) Gradients (BF16) Master weights (FP32) Optimizer m (FP32) Optimizer v (FP32) 2 bytes/param 2 bytes/param 4 bytes/param 4 bytes/param 4 bytes/param (12.5%) (12.5%) (25%) (25%) (25%) Meta + RNG + LR negligible 图17-39 典型检查点（混合精度全量口径）的体积分解 关键结论：单个检查点大小 ≈ P × 16 bytes（混合精度全量口径）。7B 模型 约100 GB，70B 模型 约1.1 TB，405B 模型 约6 TB，MoE 671B 模型 约10 TB。优化器状态与主权重副本（FP32）占检查点的 75%，权重与梯度 （BF16）各占约 12.5%。 示例 1 MCKPT = 6.74 × 109 × 16 = 107.8 × 109 bytes ≈ 100 GB 实际部署中考虑到框架对齐 padding（约5%），约 105113 GB。一块 128 GB 的 NVMe SSD 即可存储一个完整检查点。 示例 2 MCKPT = 70 × 109 × 16 = 1.12 × 1012 bytes ≈ 1.1 TB 单个检查点即超过 1 TB。若保留 20 个检查点，总存储需 20 × 1.1 ≈ 22 TB。单块 NVMe 已不够，需 RAID 阵列或分布式 存储。 示例 3 MCKPT = 405 × 109 × 16 = 6.48 × 1012 bytes ≈ 6 TB 单个检查点约 6 TB。仅保留最近 5 个（训练中常见配置）就需要约 30 TB。这是任何单机存储都需认真规划的规模。 示例 4 MCKPT = 671 × 109 × 16 = 1.07 × 1013 bytes ≈ 10 TB 即使每次前向传播仅激活 37B 参数，检查点也必须保存全部 671B 参数的权重和优化器状态。这是 MoE 架构在存储方面 的「总参数惩罚」：推理效率高，但训练存储需求按总参数而非激活参数计算。 示例 5 若训练采用 FP8 优化器（如 DeepSpeed FP8 Optimizer），优化器状态从 FP32（8 字节 m + v）缩减为 FP8（2 字节 m + v），每参数字节数从 16 降至 4（2 字节 BF16 权重 + 1 字节 FP8 m + 1 字节 FP8 v，梯度与主权重不再单独保存）： MCKPT_FP8 = 671 × 109 × 4 = 2.68 × 1012 bytes ≈ 2.5 TB 相比标准 16 字节/参数的约 10 TB，FP8 优化器将检查点缩减约 75%。对于 671B MoE，这节省了约 7.5 TB/检查点。

17.7.4 检查点策略

检查点频率和保留策略直接影响存储容量规划。过于频繁写入浪费空间，过于稀疏则故障时损失过多训练进度。

1. 检查点频率与 MTBF 检查点间隔取决于硬件的平均无故障时间（MTBF）和可接受的进度损失。两者关系： MTBF CKPT_interval ≤ , margin_factor = 5 ∼ 10 margin_factor margin_factor 的作用：提前保存，留出故障恢复的空间。 用步数表达： MTBF Nsteps_per_ckpt ≤ Tstep × margin_factor 以典型 GPU 集群为例： •H800 单卡 MTBF：约 36 个月（约10,00020,000 小时） •16,000 卡集群的 MTBF：由于并行节点数多，故障概率叠加，约 100500 小时（420 天） •训练步时 T = 3s，取 margin_factor=5： step 100 × 3600 Nsteps_per_ckpt ≤ = 24,000 steps 3×5 实际选择：每 1,000~5,000 步保存一次。以 1,000 步为例，每步 3s，间隔仅 50 分钟，比 MTBF 保守得多，但可以接受。
2. 故障时进度损失计算 设检查点间隔为 N 步，最坏情况下故障恰好发生在下一个检查点前： ckpt_interval Lost_steps_max = Nckpt_interval Lost_wall_time_max = Nckpt_interval × Tstep

检查点间隔与时间损失的关系如表17-82所示。 表17-82 检查点间隔与时间损失 CKPT 间隔（步） Tstep = 3s 的时间损失 Tstep = 1s 的时间损失 100 5 min 1.7 min 500 25 min 8.3 min 1,000 50 min 16.7 min 5,000 4.2 hours 1.4 hours 10,000 8.3 hours 2.8 hours 对于 T = 3s 的大型训练，每 1000 步保存使得单次故障最多损失 约50 分钟训练时间。这意味着训练集群的 checkpoint 写带宽必须足以在 50 分钟内完成一次写入，实际必须更快。 step 3) 保留策略与存储容量 训练日志中积累的检查点必须按策略清理，否则存储爆炸。 阶梯式保留（最常用）： 阶梯式保留策略如表17-83所示。 表17-83 检查点保留策略 检查点类型 保留策略 示例 最近 N 个 保留最新 N 个 CKPT N=5，覆盖最近 5,000 步 每日/每 N 步 保留每隔固定步数的 CKPT 每 10,000 步保存一个永久标记 里程碑 关键指标拐点手动标记 loss 骤降、验证集最佳点 初始 训练开始前的初始化状态 首次 loss 异常时可回溯 设单个检查点大小为 M CKPT ，则检查点总存储为： MCKPT_total = MCKPT × Nkept_ckpts 典型场景代入： 不同保留策略下的检查点总存储如表17-84所示。 表17-84 检查点保留策略存储量 模型 单 CKPT 大小 保留 20 个 保留 50 个（含里程碑）

LLaMA-7B                       100 GB                  2 TB           5 TB
LLaMA-2-70B                    1.1 TB                  22 TB          55 TB
LLaMA-3.1-405B                 6 TB                    120 TB         300 TB
DeepSeek-V3（671B MoE）          10 TB                   200 TB         500 TB

对于 LLaMA-3.1-405B 级别训练，仅保留 20 个检查点就需要 120 TB。若训练周期为 90 天，每天保留一个里程碑，再加 最近的 10 个，总计约 100 个检查点 ≈ 600 TB，比原始数据集（56 TB）大近 10 倍。检查点才是大模型训练的存储大 头。 4) 异步检查点写入 检查点写入和训练计算可以重叠，减少对吞吐的影响： 异步检查点写入与训练步骤的重叠时间线如图17-40所示。 GPU Cluster CPU Buffer Storage System Training Step N Compute step N Copy weights to CPU buffer Continue Training Step N+1 (overlapped) Async write checkpoint Compute step N+1 Write in progress (steps N+1 to N+K) Write complete (after K steps) GPU Cluster CPU Buffer Storage System 图17-40 异步检查点写入与训练步骤的重叠时间线 异步 CKPT 的核心代价： •CPU RAM 缓冲区：需要至少 M 的 CPU 内存用于暂存权重。以 405B 模型（约 6 TB）为例，需约 6 TB CPU RAM，需要 8 路以上服务器（如 8 路 Intel Sapphire Rapids，每路 8 通道 DDR5）或 CXL 内存扩展，成本不菲。 CKPT •带宽重叠：副本从 GPU 到 CPU 走 PCIe/NVLink，CPU 到磁盘走存储网络。两条路径可并行。 异步写入使得检查点时间窗口扩展为 N 个训练步。此时单步内的 CKPT 写带宽需求大幅降低。 ckpt_write_steps 5) 检查点加载与重启 故障恢复时，启动加载时间可能成为重启耗时的主要部分。分布式加载策略： •每个 DP rank 加载其参数分片 → 并行化 •加载带宽需求：BW = M /Tload CKPT load_target 以 70B 模型（约 1.1 TB）在 64 GPU 上加载，目标 2 分钟： 1120 GB BWload_per_GPU = ≈ 146 MB/s 64 × 120 s 每个 GPU 仅需约 146 MB/s，即使是 10 Gbps 网络也足够。这解释了为什么重启加载通常远快于写入（写入需要从所有 GPU 聚合权重到磁盘，读取只是分发）。 6) 检查点完整性校验 损坏的检查点等于丢失训练进度。验证方法： •校验和：写入后计算 checksum，加载时验证 •关键指标对比：加载后的 loss 与保存时对比，偏差 < 10 即正常 −4 •框架内置验证：Megatron-LM 和 DeepSpeed 均提供自动校验选项 关键结论：检查点间隔应根据集群 MTBF 确定（1,0005,000 步常见），保留策略采用“最近 N + 里程碑”混合。 检查点总存储可达数百 TB，超过原始数据集。异步写入是大型训练的基本配置。 示例 1 场景：LLaMA-70B 训练，T = 1s，检查点间隔 1000 步，MTBF 约 1 周，训练总时长 90 天。 step 检查点数量估算： •总步数：90 × 86400/1 = 7,776,000 步 •检查点间隔 1000 步 → 训练期间共保存约 7776 个检查点（但仅保留策略内的数量） •保留策略：最近 5 个 + 每日保留 1 个（90 天 = 90 个） •总保留检查点数：5 + 90 = 95 单检查点大小约 1.1 TB → 总检查点存储： MCKPT_total = 95 × 1.1 ≈ 105 TB 故障恢复分析：最坏情况下故障发生在下一个检查点前，损失 1000 步。 Tlost = 1000 × 1 = 1000 s ≈ 17 min 17 分钟的训练进度损失在 90 天训练中可忽略不计（约0.01%）。 示例 2 MCKPT_total = 95 × 6 ≈ 570 TB 加上原始数据集(约90 TB)，总存储需求约 660 TB。对于标准 100 TB 级的共享存储集群，这需要专门的容量规划，可能 需要扩容或采用数据生命周期管理（自动清理旧检查点）。 若进一步保留每 10K 步的永久标记点（约 778 个额外检查点），存储可达 PB 级。生产环境中必须严格限制保留数量。 示例 3 405B 模型异步写入需 CPU RAM 缓冲区暂存所有权重和优化器状态。缓冲区大小 = 单检查点大小： Mbuff er ≈ 6 TB 单台双路服务器最大内存约 4 TB，无法容纳 6 TB 缓冲。实际部署中： •使用 8 路服务器（64 通道 DDR5，最大 816 TB） •或使用 CXL Type-3 内存扩展（额外 512 GB~2 TB） •或使用 NVMe SSD 作为写入缓冲（牺牲部分带宽） 异步写入虽降低了写带宽需求，但 CPU RAM 成本不可忽视。

17.7.5 快照读写带宽

检查点的写入和读取带宽需求，是存储系统规划的核心约束。本节推导同步和异步两种场景下的带宽公式，并结合分布式 文件系统给出 OSS 数量规划。

1. 同步写带宽公式 无异步缓冲时，检查点必须在两个训练步之间完成写入。可用时间窗口即为单步时长： MCKPT BWwrite_sync =

Tstep 代入 70B 模型（M ≈ 1.1 TB）和不同步时，同步写所需带宽如表17-85所示。 CKPT 表17-85 同步写带宽需求 Tstep 所需写带宽 等效 NVMe 数量（7 GB/s） 1s 1120 GB/s 160 块 3s 373 GB/s 53 块 5s 224 GB/s 32 块 10s 112 GB/s 16 块 显然，同步写入对于中型以上模型是不可行的。单个存储节点的 NVMe 带宽约 2050 GB/s（取决于 RAID 配置和网络协 议），构建 100+ GB/s 的聚合带宽需要数十个存储节点，成本高昂。 2) 异步写带宽公式 异步写入利用 CPU 缓冲区将写操作分摊到多个训练步。设写入覆盖 N 个步长窗口： steps MCKPT BWwrite_async = Nsteps × Tstep 以 70B 模型（约 1.1 TB）异步写入为例，各窗口的带宽需求如表17-86所示。 表17-86 异步写带宽需求 Nsteps Tstep = 3s 可写时间 所需带宽 NVMe 数量 1（同步） 3s 3s 373 GB/s 53 5 3s 15s 74.7 GB/s 11 10 3s 30s 37.3 GB/s 6 50 3s 150s 7.5 GB/s 2 异步写入将带宽需求降低了 N 倍。对于 N = 10，即使是 405B 模型（约 6 TB）也仅需 6000/30 ≈ 200 GB/s，约 29 块 NVMe。 steps steps 但这依赖于 CPU 内存缓冲区。405B 模型需约 6 TB CPU RAM，在单节点上难以实现。实践中大型训练通常同时采用异步 写入 + 分布式写入。 3) 分布式写入 ZeRO-3 分片 在 ZeRO-3 或 FSDP 模式下，每个 DP rank 仅保存自己的参数分片。写入并行化为 DP 路： size MCKPT BWwrite_per_GPU = DPsize × Twrite_window 写入窗口 T 对于异步写为 N × T ，对于同步写为 T 。 write_window steps step step 以 70B 模型为例（M ≈ 1.1 TB，DP = 64，N = 10，T = 3s）： CKPT size steps step 1120 × 109 BWwrite_per_GPU = ≈ 583 MB/s 64 × 10 × 3 每张 GPU 仅需约 583 MB/s 的写带宽。单块 NVMe（37 GB/s）可承载约 512 张 GPU。这是分布式写入的核心优势：通 过分片将带宽瓶颈分摊到整个集群。 4) 分布式文件系统的聚合 生产环境的存储系统通常是共享的分布式文件系统（如 Lustre、GPFS/IBM Storage Scale、WEKA、DAOS）。聚合读写带 宽由 OSS（Object Storage Servers）数量和单台 OSS 带宽决定： BWagg = NOSS × BWper_OSS × feff iciency 其中 f ∈ [0.6, 0.9]，考虑网络和软件栈开销。 eff iciency 单台 OSS 典型带宽（2024-2025 年硬件）： 单台 OSS 的典型带宽如表17-87所示。 表17-87 单台 OSS 典型带宽 存储配置 单 OSS 读带宽 单 OSS 写带宽 典型 IOPS 10× NVMe（RAID0 软件） 约50 GB/s 约40 GB/s 约1M 24× NVMe（全闪存节点） 约100 GB/s 约80 GB/s 约2M InfiniBand NDR400（400 Gbps） 约50 GB/s 约50 GB/s 网络上限 规划 OSS 数量： Required_BWwrite NOSS ≥ BWper_OSS × feff iciency 以 405B 模型训练为例（异步 + 分布式，聚合写带宽 126 GB/s，BW per_OSS = 40 GB/s，f eff iciency = 0.8 ）： NOSS ≥ 40 × 0.8 ≈ 3.9 → 4 台OSS 若考虑数据冗余（3 副本），实际存储节点数需 ×3： Nstorage_total = 4 × 3 = 12 个存储节点 5) 重启时的读带宽分析 故障后重启加载检查点使用的是读带宽，分析过程与写入对称。区别： •加载是读操作，通常比写快（文件系统读优于写，无数据一致性开销） •加载只需一次同步（与写入窗口重叠不同） •实际加载时间是恢复训练前的阻塞时间 以 70B 模型（约 1.1 TB）在 64 GPU 上分布式加载： MCKPT Tload = DPsize × BWper_GPU 每 GPU 读带宽 BW per_GPU = 5 GB/s（NVMe 读吞吐），DP size = 64 ： Tload = ≈ 3.5 s 64 × 5 即便是 405B 模型（约 6 TB），在 1024 GPU 上分布式加载也仅需约 1.2 秒。分布式加载使得大型模型的重启极快。 6) 全场景带宽规划流程 从检查点大小到存储节点数的完整推导流程如图17-41所示。 Start: M_CKPT known Async write available? Yes No BW_req = M_CKPT / (N_ste BW_req = M_CKPT / T_step ps × T_step) Distributed write (ZeRO-3)? Yes No BW_per_GPU = BW_req / D BW_agg = BW_req P_size N_OSS ≥ BW_agg / (BW_O SS × η) N_total = N_OSS × replica tion_factor End: storage node count 图17-41 从检查点大小到存储节点数的完整推导流程 关键结论：同步写入仅适用于小型模型（<1B 参数）。中型以上训练必须组合使用异步写入（降低带宽需求）+ 分 布式写入（分摊到 DP rank）+ 分布式文件系统（聚合带宽）。70B 模型异步 10 步 + 64 GPU 分布式写，每 GPU 仅 需约 580 MB/s，单块 NVMe 即可满足。 示例 1 70B 模型单检查点约 1.1 TB，T step = 1s ，同步写入： 1120 × 109 BWsync = = 1120 GB/s 以单块 NVMe 写带宽 7 GB/s 计算：⌈1120/7⌉ = 160 块 NVMe。即使组 RAID0（10 块一组，约50 GB/s），也需要约 23 组、230 块 NVMe，这在单节点上完全不可行。同步写入对于 70B 以上模型是纯理论的方案，实践中从不使用。 示例 2 异步写入覆盖 10 个训练步（T = 1s，窗口 = 10s）： step 1120 × 109 BWasync = = 112 GB/s 单存储节点（10×NVMe RAID0）写带宽 约40 GB/s → 需要 3 个存储节点。仅从不可行变为可行。 若再结合分布式写入（DP=64，ZeRO-3 分片写）： 1120 × 109 /64 BWper_GPU = ≈ 1.75 GB/s 每 GPU 仅需约 1.75 GB/s 写带宽，单块 NVMe（37 GB/s 写入）可承载约 2~4 张 GPU。从「需要数十个存储节点」变为 「每节点本地 NVMe 即可」。 示例 3 每个 GPU 写作其参数分片（1120/64 ≈ 17.5 GB）。设单 GPU 写带宽 5 GB/s（NVMe 写吞吐）： 17.5 Twrite_per_GPU = ≈ 3.5 s 所有 64 个 GPU 并行写入，总时间约 3.5 秒，仍小于 10 步窗口（10s）。写入不再是训练吞吐的瓶颈。 硬件总结： •同步写：160 块 NVMe（不可行） •异步写（10 步）：3 个存储节点（可行但需专用存储） •异步 + 分布式（DP=64）：每 GPU 1 块本地 NVMe（最简方案）

17.7.6 日志存储开销

日志存储常被忽略，但对大规模集群而言可能成为意外的容量瓶颈。本节按日志类型分类估算，给出典型场景的总量。

1. TensorBoard 与标量指标 训练过程中记录 loss、learning rate、gradient norm 等标量指标，每个 step 写入一次： •单个标量：约100 字节（含 tag name + time + value，gzip 压缩后） •每步记录指标数：50~200（不同层 loss、各组 lr、系统指标） •总步数：N total_steps Mmetrics = metrics_per_step × Nsteps × 100 bytes

以 1M 步、200 个指标为例： Mmetrics = 200 × 106 × 100 ≈ 20 GB TensorBoard 日志本身可忽略。但如果训练中使用了高频率打印（如每步打印所有层的 norm），日志会膨胀。 2) 性能分析追踪 Deep Learning 性能分析器（Nsight Systems、PyTorch Profiler）在每次 profiling 时生成 Chromium trace JSON 文 件： •单次 trace 大小：100500 MB（取决于 trace 时长和 GPU 数量） •典型 profiling 频率：每 13 天一次（调试阶段可能更频繁） 以 90 天训练、每 2 天 profiling 一次、每次 300 MB： Mtraces = × 300 × 106 ≈ 13.5 GB 这只涉及单一 rank。若所有 rank 同时 profiling： （使用场景极少） Mtraces_all = 13.5 × Nrank 通常仅对 rank 0 做详细 profiling，所以 profiling 日志总量可控。 3) NCCL 调试日志 NCCL（NVIDIA Collective Communications Library）的调试日志是最大的隐藏日志源： • NCCL_DEBUG=INFO 级别：约10 MB/GPU/天 • NCCL_DEBUG=WARN （默认）：约1 MB/GPU/天 • NCCL_DEBUG=TRACE ：约100 MB/GPU/天（仅极端调试） 大规模集群的示例： 大规模集群的 NCCL 日志量如表17-88所示。 表17-88 NCCL 日志量估算 集群规模 日志级别 每 GPU 每日 90 天总量 64 GPU INFO 10 MB 57.6 GB 1024 GPU INFO 10 MB 921.6 GB 16,384 GPU WARN 1 MB 1.47 TB 16,384 GPU INFO 10 MB 14.7 TB 对于 LLaMA-3.1-405B 级别的 16K GPU 训练，NCCL INFO 日志即可产生 约15 TB。因此 NCCL 默认级别应为 WARN，仅 在调试时临时开启 INFO。 4) stdout/stderr 日志 每个 rank 的进程输出（Python 日志、框架日志）经 tee 或日志收集器聚合： •每 GPU：110 MB/天（取决于 logging verbosity） •大型集群：N × 10 × 10 × N 字节 GP U days 1024 GPU × 90 天 × 10 MB/天 ≈ 0.9 TB。 这部分通常被托管在集中式日志系统（如 Loki、ELK Stack）中，独立于训练存储。但仍需计入总存储预算。 5) Prometheus 监控指标 GPU 集群通常由 Prometheus 采集 DCGM（Data Center GPU Manager）和 Node Exporter 指标： •每样本：12 字节（Prometheus 的高效时间序列编码） •采样间隔：15 秒（推荐） •指标基数（cardinality）：每个 {gpu_id, rank, node} 标签组合为一个独立的时间序列 以 10,000 个指标、1024 GPU，15s 间隔，90 天为例： 每 GPU 的独立时间序列数 ≈ 20（主要 DCGM 指标），高基数标签（ gpu_id 、 rank ）： Nseries = 20 × 1024 = 20,480 存储量（假设 1.5 字节/sample）： 90 × 86400 Mprom = 20,480 × × 1.5 ≈ 15.9 GB Prometheus 数据通常存储在独立的时序数据库（如 VictoriaMetrics、Thanos），不出现在训练存储中。但它是集群运维 成本的一部分。 各规模集群的 Prometheus 存储估算： 各规模集群的 Prometheus 存储量如表17-89所示。 表17-89 Prometheus 存储量估算 GPU 数量 指标基数 采样间隔 90 天存储 64 1,280 15s 约1.0 GB 512 10,240 15s 约8.0 GB 1,024 20,480 15s 约15.9 GB 16,384 327,680 15s 约254.4 GB 16,384 327,680 5s 约763.3 GB 6) 各类日志汇总 各类日志的存储量汇总如表17-90所示。 表17-90 各类日志存储量汇总 日志类型 每 GPU 日速率 1024 GPU × 90 天 16K GPU × 90 天 TensorBoard 指标 < 0.1 MB < 2 GB < 2 GB Profiling traces 25 MB（平均） 约20 GB 约20 GB（仅 rank 0） NCCL WARN 1 MB 92 GB 1.5 TB NCCL INFO 10 MB 922 GB 14.7 TB stdout/stderr 110 MB 92922 GB 1.514.7 TB Prometheus 极低（< 1 MB） 约16 GB 约255 GB 合计（WARN 级别） — 约0.15 TB 约3.3 TB 合计（INFO 级别） — 约1.1 TB 约30 TB 7) 日志轮转策略 日志存储的核心不在容量规划，而在有效的轮转与压缩： •自动清理：删除 N 天前的旧日志（通常 3090 天） •压缩：日志文件通常可压缩 510 倍（gzip/lz4） •分级存储：近期日志存 NVMe，历史日志转 HDD •选择性记录：默认 NCCL WARN 级别，仅调试时切到 INFO 压缩前后的存储对比（16K GPU，90 天，NCCL INFO）： gzip 压缩前后的日志存储量对比如表17-91所示。 表17-91 日志压缩前后存储对比 阶段 原始大小 压缩后（gzip） NCCL INFO 日志 14.7 TB 约2.5 TB stdout/stderr 14.7 TB 约3 TB 合计 约30 TB 约5.5 TB 训练日志的分级存储生命周期如图17-42所示。 Hot tier: NVMe Hot Storage retention: 7 days Training Cluster Log shipper Centralized Log Warm tier: HDD Warm Storage NCCL + stdout + Metrics System retention: 30 days Cold tier: Archive Cold Archive retention: 6 months 图17-42 训练日志的分级存储生命周期 关键结论：WARN 级别日志总量可控（16K GPU × 90 天约 3 TB）。INFO 级别可达 30 TB，应在生产环境中限制。 日志存储的核心策略是轮转、压缩和分级存储，而非无限扩容。 示例 将各类日志叠加，得出完整的日志存储规划： NCCL 日志（INFO 级别）：每 GPU 10 MB/天 MNCCL = 1024 × 10 × 106 × 90 = 921.6 GB TensorBoard 指标：200 个指标/步，1M 步，100 字节/指标 MTB = 200 × 106 × 100 = 20 GB 但聚合到 rank 0 后仅约 500 MB（多 rank 共享同一 TensorBoard 写入路径）。 Profiling Traces：每周一次，每次 500 MB，90 天约 13 周 Mtrace = 13 × 500 × 106 × 1024 ≈ 6.66 TB stdout/stderr：每 GPU 5 MB/天 Mstd = 1024 × 5 × 106 × 90 = 460.8 GB 总计： Mtotal = 921.6 + 0.5 + 6660 + 460.8 ≈ 8.04 TB 加上 Prometheus 监控指标（约16 GB）和系统日志（约100 GB），总日志存储约 12 TB。 按 gzip 压缩比 5:1 估算，压缩后约 2.4 TB，两块 2TB NVMe 即可承载。关键优化：Profiling traces 是最大单项（6.66 TB），限制为仅 rank 0 + 每两周一次可降至 约2.5 TB。

17.7.7 数据加载管线

本节讨论从原始文本到 GPU 显存的数据预处理与加载全链路，各阶段带宽与 CPU 预算是避免 GPU 饥饿的基础。管线依 次为 Storage → Tokenize → Pack → Shuffle → Pin Memory → GPU，各阶段有独立的吞吐上限与延时特征。

1. 端到端数据管线概览 从存储到 GPU 的端到端数据加载管线如图17-43所示。 Raw Text Read CPU: Tokenize Encode CPU: Pack & Shuffle Create Batch CPU: Pin Memory PCIe DMA GPU: Training Step on Storage 图17-43 从存储到 GPU 的端到端数据加载管线
2. 预取缓冲的量化 数据加载器的预取深度决定内存缓冲大小。缓冲量与 worker 数、预取倍率和批次数据量成正比： buffer_size = num_workers × prefetch_factor × batch_data_size

典型预取倍率 prefetch_factor=24 。8 GPU 每 GPU 1 worker × 4 prefetch 的配置下缓冲约 250 MB，完全在 CPU 内 存预算内。 3) Tokenization 的 CPU 瓶颈 HuggingFace tokenizers 库的吞吐： •单核 CPU：15 MB/s 原始文本（取决于 tokenizer 复杂度） •BPE tokenizer（如 GPT-2/LLaMA）偏慢（约1 MB/s），WordPiece 更慢 •每核可处理约 250K~1.25M tokens/s 以 LLaMA-7B 的数据需求为例（每步 4M tokens，T = 1s）： step Required_tokenize_throughput = 4 × 106 tokens/s = 16 MB/s (raw) 以单核 1 MB/s 计算，需 16 CPU 核，可接受。 但对于大规模训练(3.2B tokens/s)，以单核 1MB/s 计算：

3.2 × 109 × 4

                                   CPU_cores_required =                      ≈ 12,800 cores

1 × 106 13,000 个 CPU 核只为做实时 tokenization，这完全不可接受。因此大模型训练几乎总是使用 pre-tokenized 数据集。 4) Pre-Tokenized 数据集实操 离线 tokenize 全部文本并存储为 token ID 序列（ uint16 / uint32 ），训练时直接读取，消除 CPU tokenize 瓶颈： tokenized 流吞吐由存储读带宽决定（NVMe 37 GB/s/盘可支撑 0.751.75M tokens/s），代价为一次性预处理时间与额 外存储。tokenized 数据按 128 MB1 GB 分片，配合 .idx 索引实现 O(1) 随机访问；16,000 GPU 规模下每 GPU 以极低 CPU 开销获取数据。 5) 在线数据增强的 CPU 开销 视觉和语音训练的在线数据增强可能成为 CPU 瓶颈，常用操作耗时如表17-92所示。 表17-92 在线数据增强操作耗时 增强操作 单张图像 CPU 耗时 说明 随机裁剪（224×224） 约0.5 ms Pillow/PIL 增强操作 单张图像 CPU 耗时 说明 随机水平翻转 < 0.1 ms NumPy 级 颜色抖动 约0.3 ms 逐像素操作 AutoAugment/RandAugment 25 ms 多步组合增强 MixUp/CutMix 510 ms 双图像混合 8 GPU × 64 samples/s × 5 ms/sample = 2.56s CPU 时间/s，需要约 3 个 CPU 核，需求远高于文本 tokenization。CPU 跟不上时可把增强移到 GPU（ torchvision.transforms GPU 加速）或改用 NVIDIA DALI，在 GPU 上完成 decode + augment。 6) Shuffle Buffer 的内存代价 全局 Shuffle 对整个数据集做排列，O(N ) 内存且无法流式处理，仅适用于小数据集；Shuffle Buffer 维护滑动窗口随机采 样，内存开销： Mbuff er = buffer_size_in_samples × sample_size_in_bytes 以 1M 样本、每样本 4KB（1024 tokens × 4 bytes 或 2048 × 2 bytes tokenized）为例： Mbuff er = 106 × 4096 ≈ 4.1 GB 数千万样本的 massive shuffle buffer 内存需求可达 100+ GB，超出单节点 CPU 内存时用分布式 shuffle（如 DistributedSampler ）分散到整个集群。 7) GPU 饥饿的量化与诊断 GPU 饥饿（GPU Starvation）指 GPU 因等数据而空闲，用利用率间隙量化： GPU_idle_time GPU_starvation_ratio = GPU_total_time 诊断时用 nvidia-smi /DCGM 观察利用率：持续 < 95% 且 CPU 也低为 IO 瓶颈（磁盘/NFS 慢），CPU 高则为 tokenize/augment 瓶颈（增加 num_workers ），利用率波动多为 rank 负载不均。常见症状、根因与修复如表17-93所 示。 表17-93 GPU 饥饿诊断表 症状 根因 修复 GPU < 95% 利用率，CPU < 30% 磁盘/NFS IO 慢 换 NVMe；增加分片数；使用本地 SSD 缓存 GPU < 95%，CPU > 90% Tokenize 瓶颈 改用 pre-tokenized 数据 GPU < 95%，内存不足 Shuffle buffer 过大 减小 buffer；使用分布式 shuffle GPU 利用率锯齿波动 Rank 间负载不均 检查 dataloader 的 drop_last=True ；平衡分片大小 8) 管线优化策略总结 数据管线优化策略汇总如表17-94所示。 表17-94 数据管线优化策略 策略 适用阶段 收益 代价 Pre-tokenize 离线 Tokenize 消除 CPU 瓶颈 预处理时间 + 额外存储 pin_memory=True H2D transfer 23× 传输加速 少量 CPU 内存 增加 num_workers IO + preprocessing 降低 GPU 空闲 CPU 上下文切换 本地 SSD 缓存 存储 IO 消除网络存储延迟 节点级维护成本 策略 适用阶段 收益 代价 NVIDIA DALI 图像 decode + augment 510× 加速 学习成本；仅限视觉 分布式 shuffle Shuffle 超越单机内存限制 通信开销 关键结论：数据管线瓶颈通常在 CPU tokenize/augment 而非存储 IO。大模型训练应使用 pre-tokenized 数据 集。 pin_memory 和适当的 num_workers 是避免 GPU 饥饿的最低配置。 示例 1 场景：8×GPU 单机，B = 4Mtokens/step，T = 1s，数据速率 16 MB/s。 global step Tokenization 的 CPU 需求：BPE tokenizer 单核吞吐约 1 MB/s： CPU_cores_for_tokenization = = 16 8-16 个 CPU 核对于一台 64 核服务器来说轻松可得。若使用 pre-tokenized 数据（跳过 tokenize），CPU 需求降至接近 0。 DataLoader 配置验证：8 GPU，每 GPU 1 worker × 4 prefetch： 4 × 106 buffer_size = 8 × 4 × × 2 bytes ≈ 250 MB 250 MB 的预取缓冲完全在 CPU 内存预算内（> 256 GB 典型配置）。 结论：LLaMA-7B 级别训练的 CPU 数据管线需求极低，单台 64 核服务器有大量余量。 示例 2 场景：16K GPU，B = 16Mtokens/step，T = 3s，数据速率约 21 MB/s raw（但 16K GPU 同时访问）。 global step 若尝试在线 tokenize： 16,000 × 16 × 106 × 4 CPU_cores_required = ≈ 341,333 3 × 1 × 106 34 万 CPU 核仅用于 tokenization，这需要 5500+ 台 64 核服务器，能耗和成本不可接受。 Pre-tokenized 方案： •离线 tokenize 全部数据（一次性开销，可并行到数千台机器分批完成） •训练时 GPU 直接读取 uint16 token IDs，CPU 仅负责 I/O 调度 •每 GPU 数据速率：16 × 10 × 2/(1024 × 3) ≈ 10.4 MB/s（tokenized 格式） •每 GPU 只需 12 个 DataLoader worker 结论：Pre-tokenize 将 CPU 需求从 34 万核降至 约3 万核（主要用于数据调度和 shuffle），降低约 10 倍。对于大模型训 练，pre-tokenize 不是可选项，而是必需项。

17.8 推理效率分析

本章从第一性原理出发，系统分析大语言模型推理的延时、吞吐和成本。按“Phases → Latency → Throughput → Optimization → Cost”的线索递进：先拆解 Prefill 与 Decode 两阶段的本质差异，然后分节计算各自的延时，接着推导 吞吐量和并发用户估算，最后覆盖 Continuous Batching、PagedAttention、Speculative Decoding、Chunked Prefill 和量化推理等生产级优化手段。

17.8.1 Prefill 与 Decode

自回归推理分为两个截然不同的阶段：Prefill 和 Decode。两者在计算模式、算力需求和内存行为上差异巨大。 Prefill 阶段 Prefill 阶段处理用户输入的全部 prompt token（设输入 token 数为 S ）。整个 prompt 在一次前向传播中完成。 in 计算量（仅前向，无反向）： FLOPspref ill = 2 × P × Sin 其中 P 是模型非嵌入参数量。因子 2 来自前向传播中每次矩阵乘法的一个乘法和一个加法。 并行性：所有 S 个 token 在 batch 维度上并行处理。Self-attention 中每个 token 可同时关注所有其他 token（因果掩 码严格下三角，但计算可以用 FlashAttention 完成）。 in 瓶颈：计算受限（Compute-Bound）。算术强度高，大量时间花在矩阵乘法上。 Decode 阶段 Decode 阶段逐 token 生成，每次只处理一个新 token。利用 KV Cache 存储历史 token 的 Key 和 Value 矩阵，避免重复 计算。 单步计算量： FLOPsdecode_step = 2 × P × 1 每生成一个 token 需一次完整前向传播，但序列维度为 1。 串行性：第 t 步的注意力计算依赖前 t − 1 步的 KV Cache。无法并行化 Decode 步，这是自回归推理的根本瓶颈。 瓶颈：内存带宽受限（Memory-Bandwidth-Bound）。每个 token 需从 HBM 加载全部模型权重（约 2P 字节），但只执 行约 2P 次浮点运算。算术强度极低。 算术强度对比 算术强度 I 定义为每字节内存访问对应的 FLOPs： FLOPs I= Bytes_from_HBM Prefill 算术强度： 模型权重加载约 2P 字节，KV Cache 写入约 L × S × d × 2 字节（可忽略不计）。因此： in kv 2P Sin Ipref ill ≈ = Sin FLOP/byte 2P 对于 S = 4096，算术强度约 4096 FLOP/byte。 in H800 Roofline：Ridge point = 989.5TFLOPS/3.35TB/s ≈ 295 FLOP/byte。因此 S > 295 时 Prefill 为计算受限。 in H20 Roofline：Ridge point = 148TFLOPS/4.0TB/s ≈ 37 FLOP/byte。S > 37 即进入计算受限区，几乎所有实际场景 下 Prefill 均计算受限。但由于峰值算力仅为 H800 的 15%，Prefill 耗时显著更长。 in Decode 算术强度： 每次 Decode 加载全部权重（2P 字节）和 KV Cache（L × S × d × 2 字节），执行 2P 次 FLOPs： kv 2P Idecode ≈ ≈ 1FLOP/byte 2P + 2LSdkv 远低于 Roofline 拐点。Decode 始终是内存带宽受限的。 对比总结： Prefill 与 Decode 两阶段的本质差异对比如表17-95所示。 表17-95 Prefill 与 Decode 对比 维度 Prefill Decode 处理方式 一次处理全部 S 个 token in 逐 token 串行生成 FLOPs 2P Sin 2P × 1/步 并行度 高（S 个 token 并行） in 低（单 token） 瓶颈 计算受限 内存带宽受限 算术强度 ≈ Sin ≈1 关键优化 高 MFU、Chunked Prefill 减少权重加载、量化、投机解码 对于 S = 4096，I : I ≈ 4096 : 1，约 4000 倍差距。这直接驱动了两阶段不同的优化策略：Prefill 追求高 MFU （更高 Tensor Core 利用率），Decode 追求高带宽利用率（更高的 HBM 利用率）。 in pref ill decode 示例 1 LLaMA-3-8B，P = 8 × 10 ，S = 4096，L = 32，d = 1024。 in kv Prefill 算术强度： 2 × 8 × 109 × 4096 Ipref ill = = 4096 FLOP/byte 2 × 8 × 109 （分母约为权重加载 16 GB，KV Cache 写入量相对极小） Decode 算术强度： 2 × 8 × 109 16 × 109 Idecode = ≈ ≈ 0.98 FLOP/byte 2 × 8 × 109 + 2 × 32 × 4096 × 1024 16 × 109 + 0.268 × 109 差距： Ipref ill 4096 = ≈ 4180 × 0.98 Idecode 约 4000 倍的算术强度差异解释了为何 Prefill 和 Decode 需要完全不同的优化策略。 H20 推理优势（1）：H20 峰值算力仅 148 TFLOPS（H800 的 15%），但 HBM 带宽达 4.0 TB/s（H800 的 120%）。 即 Decode（内存带宽受限）中 H20 表现优于 H800，Prefill（计算受限）中 H20 远落后于 H800。对于以 Decode 为主导的在线推理（输出 token 数远大于输入 prompt token 数），H20 的每 TFLOPS 带宽比约为 H800 的 8 倍，在带宽受限负载中性价比突出。 示例 2 Roofline 判断 H800 BF16 Roofline 拐点：

989.5 × 1012

3.35 × 1012

                                                            Ridge_pointH800 =                                 ≈ 295 FLOP/byte

H20 BF16 Roofline 拐点： 148 × 1012

4.0 × 1012

                                                                  Ridge_pointH20 =                                  ≈ 37 FLOP/byte

•Decode（I ≈ 1）：在 H800（拐点 295）和 H20（拐点 37）上均处于 Roofline 左侧，内存带宽受限。H20 的 HBM 带宽（4.0 TB/s）比 H800（3.35 TB/s）高 19%，Decode 更快。 decode •Prefill（I = 4096）：在 H800（拐点 295）上处于 Roofline 右侧，计算受限；在 H20 上同样计算受限，但峰值算 力仅为 148 TFLOPS（vs 989.5），Prefill 慢约 6.7×。 pref ill 实际含义：Decode 延时由 HBM 带宽决定，H20 在此场景下优于 H800（4.0 vs 3.35 TB/s）；Prefill 延时由 GPU 算力决 定，H800 在此场景下显著优于 H20（989.5 vs 148 TFLOPS）。两类 GPU 在推理中的优势互补。 Prefill 与 Decode 两阶段的流程对比如图17-44所示。 Decode (Memory-Bound) Prefill (Compute-Bound) Load ALL Weights One Forward Pass Input Prompt Single Forward Pass KV Cache KV Cache ~2P bytes from HBM FLOPs = 2P S_in tokens FLOPs = 2PS_in (L, S_in, d_kv) First Token (L, S, d_kv) Next Token 图17-44 Prefill 与 Decode 阶段流程对比 Prefill 一次并行处理全部 prompt，Decode 逐 token 串行并复用 KV Cache。 核心结论：Prefill 和 Decode 是两种截然不同的计算模式。Prefill 的计算量随 S 线性增长，受限于 GPU 算力 （H800 989.5 TFLOPS >> H20 148 TFLOPS）；Decode 的单步计算量恒定，受限于 HBM 带宽（H20 4.0 TB/s > in H800 3.35 TB/s）。两类 GPU 在推理两阶段中的优势互补：H800 适合 Prefill 密集型场景，H20 在 Decode 密集型 在线服务中更具成本优势。

17.8.2 Prefill 阶段延时

Prefill 延时是整个推理延时的第一段，由用户输入 prompt 长度决定，而非用户所能控制的输出长度。

1. 基础公式 Prefill 时间由模型 FLOPs 和有效算力决定： 2 × P × Sin Tpref ill = eff_TFLOPS 其中 eff_TFLOPS = peak_TFLOPS × eff_ratio。由于 Prefill 是计算受限的，eff_ratio 通常较高（60% - 80% 的峰值算 力）。
2. 典型模型实例 LLaMA-3-8B（P = 8 × 10 ，H800 BF16 峰值 989.5 TFLOPS，有效 70% ≈ 692 TFLOPS），S = 4096： in 2 × 8 × 109 × 4096 T = ≈ 95ms

692 × 1012 LLaMA-3-70B（P = 70 × 10 ，同样硬软件环境），S = 4096： 9 in 2 × 70 × 109 × 4096 T = ≈ 830ms 692 × 1012 830 ms 已接近不可接受的交互延时。引入 TP=8（Tensor Parallelism，每个 GPU 承担 1/8 计算量）并利用 NVLink 高带 宽消除通信开销： TTP 8 ≈ = 104ms LLaMA-3-70B 超长 prompt（S = 128K = 131072）： in 2 × 70 × 109 × 131072 T = ≈ 26.5s 692 × 1012 26 秒的 Prefill 延时对交互式应用完全不可接受。Chunked Prefill通过分块调度缓解这一问题。 3) Time To First Token TTFT 是用户感知的“第一个 token 出现”的时间： TTFT = Tpref ill + Tdecode_step1 Tdecode_step1 ≈ 5 − 50 ms（取决于模型规模和硬件），远小于 Prefill。因此 TTFT 主要由 Prefill 延时决定： TTFT ≈ Tpref ill SLO 视角的 TTFT 目标通常为 1-3 秒。对于 LLaMA-3-70B + H800，S = 4096 时 TTFT 约 830 ms（或 TP8 下 104 ms）， 满足多数交互场景需求。S = 32K 时 TTFT 约 6.6 s，需 TP 或 Chunked Prefill 降低。在 H20 上，由于峰值算力仅 148 in TFLOPS（H800 的 15%），相同 S = 4096 下 Prefill 延时约为 H800 的 6.7×（830 × 6.7 ≈ 5.56 s），远超出交互 SLO， in 需更大 TP 度补偿。 in 4) Prefill 延时随序列长度变 Prefill 延时随序列长度与模型规模的增长关系如图17-45所示。 S=2K S=4K S=8K S=16K S=32K S=128K LLaMA-8B: 47ms LLaMA-8B: 95ms LLaMA-8B: 190ms LLaMA-8B: 380ms LLaMA-70B: 6.6s LLaMA-70B: 26.5s 图17-45 Prefill 延时随序列长度与模型规模增长 延时与 S 成正比，70B 模型在长序列下迅速突破交互延时阈值。 in 5) 有效算力比率的决定因 Prefill 的有效算力比率受多个因素影响，如表17-96所示。 表17-96 Prefill 有效算力比率影响因素 因素 影响 典型范围 序列长度 S 越大，计算密度越高，MFU 越高 S=512: 40-50%, S=4096: 60-75% 模型规模 大模型有更多并行度 8B: 约65%, 70B: 约70% FlashAttention 节省 HBM 带宽，提升有效算力 +5-15% 并行策略 TP 引入通信，可能降低 eff TP2: 约95% of single, TP8: 约85% Kernel 优化 Fused kernels 减少 kernel launch +5-10% Batch size 大 B 提升算力利用率 B=1: 约60%, B=8: 约75% 优化建议：对于交互式场景，优先通过 TP 降低单请求 Prefill 延时。Chunked Prefill 是长 prompt 场景的关键优 化，可将排队延时从数十秒降至毫秒级。 示例 1 H800 BF16 有效算力（70% 峰值）： eff_TFLOPS = 989 × 0.7 = 692 TFLOPS Sin = 4096 ： 2 × 8 × 109 × 4096 6.554 × 1013 Tpref ill = = = 0.0947 s = 94.7 ms 692 × 1012 6.92 × 1014 TTFT ≈ 95 ms。远低于 1s SLO，体验良好。 示例 2 单卡： 2 × 70 × 109 × 4096 5.734 × 1014 Tpref ill = = = 0.829 s = 829 ms 692 × 1012 6.92 × 1014 830 ms 接近 1s SLO 边界。引入 TP=8（NVLink 带宽足以消除通信瓶颈，假设线性加速）： TP 8 0.829 Tpref ill = = 0.104 s = 104 ms TP=8 将 TTFT 从 830 ms 降至 104 ms，回到交互可用区间。 示例 3 超长 Prompt 的 Prefill LLaMA-3-70B，S = 128K = 131072： in 2 × 70 × 109 × 131072 1.835 × 1016 Tpref ill = = = 26.5 s 692 × 1012 6.92 × 1014 26.5 秒的单请求 Prefill 对交互式应用完全不可接受。即使 TP=8 也只能降至约 3.3 秒，仍远超 SLO。必须使用 Chunked Prefill。 示例 4 405B 参数，TP=8，S = 4096： in TP 8 2 × 405 × 109 × 4096 3.318 × 1015 Tpref ill = 12 = = 0.599 s = 599 ms 692 × 10 × 8 5.536 × 1015 600 ms 的 TTFT 仍然可用。但 S = 32K 时： in TP 8 32768 Tpref ill = 0.599 × = 4.79 s 已突破交互 SLO。需要更大的 TP 度（TP=16，约2.4s）或 Chunked Prefill。 示例 5 LLaMA-3-70B，S = 4096，H20 有效算力取 70%（148 × 0.7 = 103.6 TFLOPS）： in 2 × 70 × 109 × 4096 5.734 × 1014 H20 Tpref ill = = = 5.53 s

103.6 × 1012 1.036 × 1014

对比 H800 的 830 ms： TH20 5530 = ≈ 6.66 × TH800 H20 推理劣势：H20 的 Prefill 延时约为 H800 的 6.7×。对于 Prefill 密集型场景（长 prompt、文档摘要、RAG 检 索），H800 显著优于 H20。若业务以短 prompt 对话为主（Prefill 占比较小，Decode 占主导），H20 仍可接受。 但长 prompt 场景下必须通过更大 TP 度补偿，H20 需 TP=56 才能达到与 H800 TP=8 相当的 Prefill 延时，这在成 本上不划算。

17.8.3 Decode 阶段延时

Decode 阶段每生成一个 token 完成一次前向传播。与 Prefill 不同，Decode 是内存带宽受限的。

1. 延时分解 由于 Decode 处于内存带宽受限区，实际延时取决于内存加载时间： Tdecode = max(Tcompute , Tmemory )

即使 T 远小于 T compute memory ，最终延时也由后者决定。 计算时间： 2×P Tcomp = eff_TFLOPS 内存加载时间： Mweights + MKV_read Tmem = HBM_BW 其中 M = 2P × bytes_per_param（BF16 下 2 字节/参数），M KV_read 是每个 token 的 attention 阶段需要从 HBM 读 取的 KV Cache 量。 weights 2) 典型模型分析 LLaMA-3-8B on H800（HBM BW = 3.35 TB/s）： 2 × 8 × 109 Tcomp = ≈ 23 μs 692 × 1012 16GB + MKV_read Tmem = ≈ 4.8ms 3.35TB/s Tmem ≫ Tcomp （约 200 倍），Decode 确定是内存瓶颈。单 token 延时约 4.8 ms，即 Time Per Output Token（TPOT） ≈ 4.8 ms。 LLaMA-3-70B on H800（权重 140 GB BF16）： 140GB + MKV_read Tmem = ≈ 41.8ms 3.35TB/s H800 单 token 延时约 41.8 ms。TP=4 时每 GPU 加载 35 GB 权重，T ≈ 35/3.35 ≈ 10.5 ms。 decode 同一模型 on H20（HBM BW = 4.0 TB/s）：单卡 T = 140/4.0 ≈ 35.0 ms，相比 H800 加速 19%（3.35/4.0 = 0.838）。 TP=4 时 T ≈ 35/4.0 = 8.75 ms。 mem decode 3) KV Cache 读取的影响 KV Cache 读取量随上下文长度增长，每 token 的 KV Cache 读取量为 L × S × d × 2(K + V) × 2(bytes)。LLaMA-3-70B （GQA, g = 8，d = 1024，L = 80）各上下文下的 KV 读取量与 TPOT 如表17-97所示。 kv kv 表17-97 KV Cache 读取量与 TPOT 上下文 S 每 token KV 读取量 Tmem （包括 140 GB 权重） TPOT 4096 0.625 GB 42.0 ms 42.0 ms 32768 5.0 GB 43.3 ms 43.3 ms 131072 20.0 GB 47.8 ms 47.8 ms KV Cache 读取随 S 线性增长，但权重加载（140 GB）在中等 S 区间仍占主导。直到 S > 500K 时 KV Cache 读取才可能 与权重加载相当。 4) Time Per Output Token TPOT 是用户感知的“每秒生成多少个 token”的倒数： tokens/s = TPOT 对于 LLaMA-3-8B on H800：TPOT ≈ 4.8 ms → ≈ 208 tokens/s。 对于 LLaMA-3-70B on H800（单卡）：TPOT ≈ 41.8 ms → ≈ 24 tokens/s。在 H20 上（单卡）：TPOT ≈ 35.0 ms → ≈ 29 tokens/s（+19%）， 5) 批处理对 Decode 的影响 批大小 B 个请求同时执行 Decode 时，权重只加载一次，KV Cache 加载 B 次，此时 T (B) = (M + B × )/HBM_BW。以 LLaMA-3-70B、S = 4096 为例，不同批大小下的内存加载量与吞吐如表17-98所示。 mem weights MKV_per_token 表17-98 批处理对 Decode 的影响 Batch Size B 内存加载量 Tmem 总 token/s（B/T ）mem 1 140.6 GB 42.0 ms 24 8 145.0 GB 43.3 ms 185 32 160.0 GB 47.8 ms 670 64 180.0 GB 53.7 ms 1192 批处理通过分摊权重加载大幅提升总吞吐（B 越大，每 token 的权重加载成本越低），但单个 token 的延时也略有增加。 6) Roofline 分析 H800 BF16 的 Roofline 模型如图17-46所示，Decode 落在内存受限区、Prefill 落在计算受限区。 Prefill Decode H800 BF16 Roofline I ≈ S_in (>>295) I≈1 Peak: 989.5 TFLOPS, BW: 3. 35 TB/s Compute-Bound Memory-Bound Region Region Arithmetic Intensity > 295 Arithmetic Intensity < 120 图17-46 Roofline 模型 Decode 的算术强度（约1 FLOP/byte）远在拐点左侧，受限于 HBM 带宽；Prefill 的算术强度（S ）远在拐点右侧，受 限于 GPU 算力。两者的优化方向截然不同。 in 核心结论：Decode 延时主要由 HBM 带宽决定。H20 的 4.0 TB/s 带宽比 H800 的 3.35 TB/s 高 19%，因此 H20 在 Decode 阶段显著优于 H800。这也是 H20 的核心价值定位，以更低的算力峰值换取更高的 HBM 带宽，专为内存 带宽受限的 Decode 推理优化。优化方向包括减少每 token 的内存访问量（权重量化、KV Cache 压缩）或提高 HBM 带宽（HBM3e）。批处理通过共享权重访问显著提升吞吐。 示例 1 LLaMA-3-8B on H800，S = 4096： 计算时间： 2 × 8 × 109 Tcomp = = 2.31 × 10−5 s = 23.1 μs 692 × 1012 内存加载时间（权重 16 GB + KV Cache 读取）： 16 × 109

3.35 × 1012

                                                         Tmem =                            = 4.78 × 10−3 s = 4.78 ms

（KV Cache 读取量在 S = 4096 时约 0.27 GB，相对 16 GB 权重可忽略） 瓶颈确认：T ≫ T （4.78 × 10 /2.31 × 10 ≈ 207 倍）。Decode 牢固处于内存带宽受限区。 mem comp −3 −5 H800 TPOT ≈ 4.8 ms，单用户生成速度 ≈ 208 tokens/s。 H20 对比：LLaMA-3-8B on H20（HBM BW 4.0 TB/s），T = 16/4.0 ≈ 4.0 ms，TPOT 改善至 4.0 ms（208 → 250 tokens/s，+20%）。 mem 示例 2 权重 140 GB（BF16），S = 4096： H800：T =mem = 4.18 × 10 s = 41.8 ms TPOT ≈ 42 ms，单用户生成速度 ≈ 24 tokens/s。 140×109 3.35×1012 −2 H20：T = = 3.50 × 10 s = 35.0 ms TPOT ≈ 35 ms，单用户生成速度 ≈ 29 tokens/s。H20 Decode 快 140×109 −2 19%。 mem 4.0×1012 示例 3 B = 32，H800：权重 140 GB + 32×KV Cache 读取（S = 4096，每请求约 0.27 GB）： 140 × 109 + 32 × 0.27 × 109 148.6 × 109 H800

3.35 × 10 12 3.35 × 1012

                                    Tmem  =                                    =             = 0.0444 s = 44.4 ms

H20： H20 148.6 × 109

4.0 × 1012

                                                              Tmem =                         = 0.0372 s = 37.2 ms

B=32 时 H800 与 H20 的 Decode 吞吐对比如表17-99所示。 表17-99 B=32 时 Decode 吞吐对比 GPU Tmem 总吞吐（tokens/s） 每用户 tokens/s H800 44.4 ms 721 22.5 H20 37.2 ms 860 26.9 H20 总吞吐比 H800 高 19%，且单个用户感知的生成速度也从 22.5 提升至 26.9 tokens/s。 示例 4 LLaMA-3-70B INT4，权重大小从 140 GB 降至 35 GB（4× 压缩）： H800：T = INT 4 mem = 1.045 × 10 s = 10.5 ms TPOT 从 42 ms 降至 10.5 ms，约 4× 加速。 35×109 3.35×1012 −2 H20：T =INT 4 = 8.75 ms TPOT 从 35 ms 降至 8.75 ms。H20 上 INT4 模型生成速度约 114 tokens/s（vs H800 的 35×109 95 tokens/s）。且 35 GB 权重在 H20 96 GB 上有 61 GB 剩余，可容纳更大的 KV Cache 和更高的并发。 mem 4.0×1012

17.8.4 推理吞吐量

推理吞吐量是评估部署经济性的核心指标：每秒能生成多少个 token。它与 Prefill 延时、Decode 延时和批大小紧密耦 合。

1. 吞吐量公式 在 Decode 占主导的场景（输出 token 数远大于输入 token 数），总吞吐量由 Decode 阶段决定： B Throughput(tokens/s) = Tdecode (B) 其中 B 是 Decode 批大小，T (B) 是批处理 B 个请求时单步 Decode 的时间 decode
2. 批大小的影响 以 LLaMA-3-70B on H800 TP=4（每 GPU 权重 35 GB，HBM BW 3.35 TB/s，S = 4096，KV 每 token ≈ 0.008 GB）为 例，不同批大小下的吞吐如表17-100所示。 表17-100 吞吐量随批大小变化 B 内存加载量（GB） H800 Tdecode （ms） H800 吞吐（tokens/s） H20 吞吐（tokens/s） 1 35.008 10.5 95 114 8 35.064 10.5 762 910 32 35.256 10.5 3040 3630 64 35.512 10.6 6037 7210 128 36.024 10.8 11852 14150 256 37.048 11.1 23063 27540 H20 吞吐始终比 H800 高约 19%，因为 H20 HBM BW 4.0 TB/s vs H800 3.35 TB/s（4.0/3.35 ≈ 1.19×）。每增加一个请求 仅添加约 8 MB KV Cache 读取开销。
3. KV Cache 对最大批大小 GPU 显存是限制最大批大小的硬约束。以 M 为总显存： GP U MGP U − Mweights − Moverhead Bmax =

MKV_per_request LLaMA-3-70B on H800（80 GB）分析： •M （BF16）= 140 GB → 单卡装不下 weights •TP=2：每 GPU 权重 70 GB，剩余 10 GB •TP=4：每 GPU 权重 35 GB，剩余 45 GB H20（96 GB）对比： •单卡权重 140 GB → 同样装不下 •TP=2：每 GPU 权重 70 GB，剩余 26 GB（vs H800 的 10 GB） •TP=4：每 GPU 权重 35 GB，剩余 61 GB（vs H800 的 45 GB） H20 更大的 HBM 容量（96 GB vs 80 GB）意味着在同等 TP 配置下，可分配给 KV Cache 的空间多 35-160%，直接转化 为更大的批大小和并发能力。 TP=4 下的最大批大小： M （S = 4096, GQA d = 1024）： KV_per_request kv MKV = L × S × dkv × 2(K + V) × 2(bytes) = 80 × 4096 × 1024 × 2 × 2 ≈ 1.34GB Bmax = ≈ 33 1.34 时 M ≈ 2.68 GB，B ≈ 17。 S = 8192 KV_per max 不同序列长度下的最大批大小如表17-101所示。 表17-101 序列长度与最大批大小 序列长度 S KV/请求（GB） B_max（TP=4） 四 GPU TP 组总并发 2048 0.67 67 67 4096 1.34 33 33 8192 2.68 17 17 32768 10.72 4 4 131072 42.88 1 1 TP 的吞吐权衡：TP 降低每 GPU 权重，但增加通信开销。TP=1 时权重装不下 70B 模型；TP=8 时每 GPU 权重仅 17.5 GB，但跨 8 卡通信显著降低有效算力。最优 TP 度是 2 或 4，能装下模型且保有足够的 KV Cache 空间。 4) Prefill 对吞吐量的影响 虽然 Decode 通常占主导，但当请求队列中堆满长 prompt 等待 Prefill 时，吞吐量会下降。混合 Prefill 和 Decode 的调 度策略（Continuous Batching）是现代推理引擎的核心优化。 5) 主流模型吞吐速查 主流模型的推理吞吐速查如表17-102所示。 表17-102 主流模型推理吞吐速查 模型 硬件 B TPOT 吞吐量 LLaMA-3-8B H800 ×1 128 约5 ms 约25600 LLaMA-3-8B H20 ×1 128 约4 ms 约30600 LLaMA-3-70B H800 ×4（TP4） 32 10.5 ms 约3040 LLaMA-3-70B H20 ×4（TP4） 32 8.8 ms 约3630 LLaMA-3-70B H800 ×8（TP8） 64 7 ms 约9140 LLaMA-3.1-405B H800 ×8（FP8） 16 约25 ms 约640 6) 吞吐量随批大小变化 LLaMA-3-70B TP4 on H800 的吞吐量随批大小增长直至 KV Cache 容量饱和，如图17-47所示。 B=1 B=8 B=32 B=64 B=128 B=256 Saturation 95 tok/s 762 tok/s 3040 tok/s 6037 tok/s 11852 tok/s 23063 tok/s limited by KV Cache 图17-47 吞吐量随批大小增长 LLaMA-3-70B TP4 on H800：接近线性，直至 KV Cache 容量耗尽；H20 吞吐始终高约 19%。 核心结论：推理吞吐量主要受 Decode 阶段和批大小决定。增加批大小通过分摊权重加载提升吞吐，但上限由 KV Cache 容量约束。TP 降低 per-GPU 权重以换取更大的 KV Cache 空间，是平衡吞吐与并发量的核心杠杆。 示例 1 LLaMA-3-70B TP=4 on H800，S = 4096，从 B=1 到 B=256 的完整吞吐曲线（含 H20 对比）如表17-103所示。 表17-103 吞吐随批大小变化明细 B 内存加载(GB) H800 Tdecode (ms) H800 吞吐(tok/s) H20 Tdecode (ms) H20 吞吐(tok/s) 1 35.008 10.45 96 8.75 114 32 35.256 10.52 3040 8.81 3630 128 36.024 10.75 11907 9.01 14210 256 37.048 11.06 23153 9.26 27650 吞吐随 B 几乎线性增长（B = 256 时吞吐为 B=1 的 241×），但单个用户的 token 速率仅微降 6%（96→90）。这是 batch 处理的理想特性。 饱和点：当 B × 0.008 > 35（即 KV Cache 读取超过权重加载），吞吐增长开始明显放缓。B ≈ 35/0.008 = 4375。但实 际 B 上限受显存约束远低于此值。 break 示例 2 LLaMA-3-8B on H800×1，权重 16 GB，S = 4096，KV/req ≈ 1.07 GB，不同批大小下的吞吐如表17-104所示。 表17-104 LLaMA-3-8B 吞吐随批大小变化 B H800 Tdecode (ms) H800 吞吐(tok/s) H20 吞吐(tok/s) 1 4.78 209 250 128 4.88 26230 31310 256 4.98 51429 61390 256 个并发请求下，每用户仍得约 201 tokens/s。8B 模型的高吞吐来自两方面：权重小（16 GB，加载快）和 KV Cache 尺寸小（每请求 1.07 GB，但批量累积慢）。

17.8.5 Continuous Batch

传统静态批处理要求 batch 中所有请求全部完成后才处理下一批：短请求完成 5 步后 GPU 空转等待长请求（长尾阻塞）， 且 batch 末尾请求数递减，利用率降至 1/B（批末利用不足）。Continuous Batching（vLLM 称 In-flight Batching， Orca 首次提出）在每个 Decode 步动态调整 batch 组成，移除已生成结束符或达 max_tokens 的请求，从等待队列补入 新请求并执行 Prefill。其实现依赖 PagedAttention 以 block 为单位管理 KV Cache，使各请求独立分配释放，并可混合 同一批中的 Prefill 与 Decode；调度可用 FCFS、SRTF（最短剩余时间优先）或结合优先级的策略。

1. 吞吐提升 Continuous Batching 对吞吐的提升取决于请求负载特征，不同场景的提升倍数如表17-105所示。 表17-105 Continuous Batching 提升倍数 场景 静态批处理利用率 Continuous Batching 利用率 提升倍数 所有请求等长 约80% 约95% 1.2× 长短请求混合 约40% 约90% 2.3× 高并发短请求 约20% 约90% 4.5× 爆发式长请求 约60% 约92% 1.5× 典型的聊天机器人场景（prompt 长度差异大、输出长度差异大）下，提升通常为 2-10×。
2. 调度时序对比 静态批处理与 Continuous Batching 的调度时序对比如图17-48所示。 Continuous Batching Static Batching Step 1: Req A + Req B in ba Step 20: Req B finishes — r Step 21: Req C (new) joins Step 100: Req A finishes — Step 101: Req D joins alon Batch 1: Req A(100 tok) + R Req B finishes at 20 tok — Req A finishes at 100 tok Batch 2 starts only now tch emoved immediately batch with Req A removed gside Req C eq B(20 tok) GPU waits — batch complete 图17-48 静态批处理与 Continuous Batching 对比 Continuous Batching 每步动态调整 batch 组成，消除闲置和长尾阻塞。 核心结论：Continuous Batching 是现代 LLM 推理引擎的标配调度策略。它通过每步动态调整 batch 组成消除静 态批处理的长尾阻塞和批末利用不足问题，是 vLLM、TGI 等框架吞吐量大幅领先传统静态批处理方案的根本原 因。 示例 1 场景：batch=32 个请求同时处理，平均输出 200 tokens。各请求实际生成长度服从幂律分布（少数长请求拖尾）。 最坏情况下最快请求 20 tokens 即结束，最慢请求需 500 tokens。最快请求完成后，batch 从 32 递减，GPU 利用率如表 17-106所示。 表17-106 静态批处理利用率递减 剩余请求数 已完成步数 GPU 利用率 32 0-20 100% 16 21-50 50% 8 51-100 25% 4 101-200 12.5% 1 201-500 3.1% 整体 GPU 利用率： 32 × 20 + 16 × 30 + 8 × 50 + 4 × 100 + 1 × 300 640 + 480 + 400 + 400 + 300 2220 η= = = ≈ 13.9% 32 × 500 16000 16000 超过 86% 的 GPU 时间浪费在等待长尾请求上。这是静态批处理的根本缺陷。 示例 2 同样 32 个请求，每步动态补入新请求。只要等待队列非空，batch 始终保持 32。整体 GPU 利用率从 13.9% 提升至 90%+。 加速比分析： ηCB 0.90 speedup = = ≈ 6.4 ×

0.14 ηstatic 在典型聊天机器人工作负载（请求生成长度波动大、到达速率高）中，实测加速比通常为 2~5×。Continuous Batching 对吞吐的提升来自消除闲置而非提高单步效率。

17.8.6 并发用户估算

给定 GPU 集群和模型部署方案，能同时服务多少用户？这个问题需从 SLO 约束和显存约束两个维度回答。

1. 用户感知延时 用户的一次交互包括三段时间：

1. TTFT（Time To First Token）：从发送 prompt 到收到第一个 token 的延时。主要由 Prefill 决定
2. TPOT（Time Per Output Token）：每生成一个 token 的间隔。由 Decode 决定
3. 总延时：TotalLatency = TTFT + (O − 1) × TPOT，其中 O 为输出 token 数。 典型 SLO：TTFT < 2 s，TPOT < 50 ms（即 >20 tokens/s 的生成速度）。

2. SLO 驱动的并发估算 Continuous Batching 下，所有并发请求共享 GPU。每个 Decode 步生成 batch 中每个请求的一个 token。因此： user_TPOT = Tdecode (B)

即批大小 B 时，单个请求的 TPOT 等于总的单步 Decode 时间。 给定 SLO 要求的 TPOT 上限 TPOT ： SLO Bmax_by_SLO = arg max{B ∣ Tdecode (B) ≤ TPOTSLO } B 对于 LLaMA-3-70B TP=4 on H800，TPOT 在 B ≤ 128 时约 10.5-10.8 ms，远超 SLO 要求的 50 ms。此时并发上限不由 TPOT SLO 约束，而由显存约束。 3) 显存驱动的并发估算 KV Cache 是并发量的硬约束。每个并发请求需独立的 KV Cache 空间（PagedAttention 优化后，按实际使用分配而非预 分配 S ）： max MGP U − Mweights − Moverhead Nconcurrent = × NTP_groups MKV_per_request 其中 N =N TP_groups /TP 。 GP U 4) 实例 配置：TP=4，产生 2 个 TP group。每 GPU 80 GB。 单 GPU 预算： •权重：35 GB（BF16, TP=4） •激活/开销：约2 GB •KV Cache 可用：80 - 35 - 2 = 43 GB 单请求 KV Cache（S = 4096, GQA d = 1024）： kv MKV_per = 80 × 4096 × 1024 × 2 × 2 ≈ 1.34GB 单 TP Group 并发：43/1.34 ≈ 32 请求。 总并发：2 TP groups × 32 = 64 并发请求。 H20 对比（8×H20 96 GB，同样 TP=4）： •单 GPU KV Cache 可用：96 − 35 − 2 = 59 GB •单 TP Group 并发：59/1.34 ≈ 44 请求 •总并发：2 × 44 = 88 请求（比 H800 +37%） 更大的 HBM 容量（96 vs 80 GB）在同等 TP 配置下为 H20 带来更高的并发承载能力。 若启用 PagedAttention（80% KV 利用率提升到 90%），实际并发可进一步提升。 5) 不同配置下的并发估算 不同配置下的并发估算如表17-107所示。 表17-107 不同配置并发估算 模型 硬件 TP Smax KV/请求（GB） 并发 LLaMA-3-8B H800 ×1 1 4096 1.07 约54 LLaMA-3-8B H20 ×1 1 4096 1.07 约69 LLaMA-3-8B H800 ×1 1 32768 8.59 约6 LLaMA-3-70B H800 ×4 4 4096 1.34 约32 LLaMA-3-70B H800 ×8 4 4096 1.34 约64 LLaMA-3-70B H20 ×8 4 4096 1.34 约88 LLaMA-3-70B H800 ×8 4 32768 10.72 约8 LLaMA-3-70B H800 ×8 8 4096 1.34 约136 LLaMA-3.1-405B H800 ×16 8 4096 约2.68 约24 KV Cache 容量对上下文长度极其敏感：S 翻倍，KV Cache 翻倍，并发减半。 6) 实际并发与 SLO 的平衡 实际部署中还须考虑的因素如表17-108所示。 表17-108 并发估算的附加因素 因素 影响 用户思考时间 用户在 token 之间停顿，GPU 空闲。实际支持的订阅用户远多于并发数（10-100×） 请求到达速率 峰值期间并发可能超出估算，需队列缓冲（增加 TTFT） Token 生成分布 并非所有请求都用满 S 。PagedAttention 按需分配 max Prefill 开销 长 prompt 的 Prefill 可能挤占 Decode 时间，影响 TPOT 实用经验：以单请求的 KV Cache 需求为基准，按 GPU 可用显存除以 KV/请求，再乘以 TPgroup数 得到硬上限。 实际订阅用户数为并发数的 5-20 倍（取决于请求频率和生成长度）。 示例 1 配置：8×H800（80 GB/GPU），LLaMA-3-70B BF16，TP=4 → 2 个 TP group。 单 GPU 显存预算： Mavailable = 80 − 35 − 2 = 43 GB •权重：140 GB / 4 = 35 GB（BF16 TP=4） •激活/框架开销：约2 GB 单请求 KV Cache（S = 4096，GQA d_kv=1024, L=80）： max req MKV = 80 × 4096 × 1024 × 2 × 2 = 1.342 × 109 bytes ≈ 1.25 GB （注意：实际为 1.34 GB，这里用 1.25 GB 简化计算） 单 TP group 并发上限： Ngroup = ≈ 32.1 → 32 requests 1.34 总并发上限：2 × 32 = 64。 换用 PagedAttention（实际利用率 90% 而非 100%），有效并发约 58。 示例 2 同样 8×H800，LLaMA-3-70B INT4 → 权重从 140 GB 降至 35 GB，TP=1（单卡装得下）。 H800 单 GPU 显存预算（80 GB）： Mavailable = 80 − 35 − 2 = 43 GB H20 单 GPU 显存预算（96 GB）： H20 Mavailable = 96 − 35 − 2 = 59 GB 单请求 KV Cache（同前）：1.34 GB/req，两种 GPU 的 INT4 单卡并发如表17-109所示。 表17-109 INT4 单卡并发对比 GPU 单 GPU 并发 TP groups 总并发 H800 INT4 TP=1 43/1.34 ≈ 32 8 256 H20 INT4 TP=1 59/1.34 ≈ 44 8 352 H20 INT4 方案提供 352 并发，相比 H800 INT4 的 256 并发 +37%，相比 H800 BF16 TP=4 的 64 并发 +5.5×。 量化不仅降低了单 GPU 硬件需求，配合 H20 的大 HBM 容量（96 GB）还能在 INT4 基础上进一步扩大 KV Cache 空间， 实现「高带宽 + 大容量 + 低精度」的叠加效应。

17.8.7 分页 KV 缓存

传统推理引擎为每个请求预分配 S 长度的 KV Cache 空间，请求实际用不完也不释放，典型场景下 70-90% 显存被闲 置，直接压缩并发上限。PagedAttention 借鉴操作系统虚拟内存的分页机制：KV Cache 按固定大小的 block（page）管 max 理，新 token 在 block 满时分配新块，请求完成立即归还共享的 block pool，相同前缀的 blocks 可跨请求共享，从根上 消除内部碎片。

1. 碎片量化 S max = 4096 下，不同实际 token 用量的预分配情况如表17-110所示。 表17-110 KV Cache 预分配浪费 实际 token 使用量 预分配（GB） 实际使用（GB） 利用率 浪费 平均 prompt 500 + 输出 200 = 700 1.34 0.23 17% 83% 短对话 100 + 50 = 150 1.34 0.05 4% 96% 长文档 3200 + 800 = 4000 1.34 1.31 97% 3% 典型聊天机器人场景中，超过 80% 的显存被浪费在未使用的 KV Cache 空间上，这直接限制了并发用户数。
2. 分页量化 S = 4096、block_size = 16 时，预分配需 ⌈4096/16⌉ = 256 blocks/请求，实际使用 700 token 仅需 ⌈700/16⌉ = 44 blocks，显存节省比 256/44 ≈ 5.8×。 max 前缀共享下，20 个请求共享 128 token 的 system prompt：传统方案需 20 × 1.34 = 26.8 GB，PagedAttention 仅需 1 × 128 + 20 × 572 = 11568 tokens（约 3.9 GB）。不同 beam 同样从分歧点起各自分配新 blocks。 PagedAttention 的分页机制如图17-49所示，Block Pool 供所有请求共享。 PagedAttention Req1: 44 blocks Traditional KV Cache Req1: Pre-allocate max_S Req2: 44 blocks Block Pool (shared across all request Req2: Pre-allocate max_S Wasted: 83% s) Req3: 12 blocks Req3: Pre-allocate max_S Free Blocks 图17-49 PagedAttention 分页机制 类比 OS 虚拟内存：Block Pool 是所有请求共享的 KV Cache 空间，每个请求按需分配 blocks，前缀相同的部分可跨请求 共享。
3. 利用率对比 传统预分配与 PagedAttention 的利用率对比如表17-111所示。 表17-111 KV Cache 利用率对比 方案 聊天场景利用率 批处理场景利用率 并发提升 传统预分配 10-30% 40-60% 1× PagedAttention 80-95% 85-95% 3-6× 以 LLaMA-3-70B TP4 on 8×H800 为例：传统预分配（20% 利用率）实际可用并发 ≈ 64 × 0.2 ≈ 13，PagedAttention （90% 利用率）实际可用并发 ≈ 64 × 0.9 ≈ 58，4.5 倍并发提升来自同一批硬件，每月 GPU 费用减少 75%。 核心结论：PagedAttention 通过按需分页管理 KV Cache 消除传统预分配造成的 70-90% 显存浪费，使同等硬件 能服务 3-6 倍的并发用户。它是 vLLM 吞吐量领先的基础设施级创新，现已被 SGLang、TGI 等主流框架广泛采 用。 示例 1 Smax = 4096 ，LLaMA-3-70B（GQA d_kv=1024, L=80），单请求 KV Cache 预分配： prealloc MKV = 80 × 4096 × 1024 × 2 × 2 = 1.34 GB

典型聊天场景：prompt 500 tokens + output 200 tokens = 700 tokens 实际使用： used MKV = 80 × 700 × 1024 × 2 × 2 = 0.229 GB 浪费率：

1.34 − 0.229

                                               waste =                = 82.9%

1.34 每请求浪费 1.11 GB。以 43 GB 可用 KV 空间计，传统方案支撑 43/1.34 ≈ 32 个预分配槽位，但实际仅使用 43/0.229 ≈ 188 个等效 token 量。83% 的显存闲置，但无法分配给新请求，这是静态预分配的根本缺陷。 示例 2 Block size = 16 tokens。单请求实际使用 700 tokens： blocks_required = ⌈700/16⌉ = 44 blocks 预分配方案：⌈4096/16⌉ = 256 blocks。节省比： ≈ 5.82 × 即同等显存可服务 5.8× 的并发请求。 单块大小（16 tokens）： Mblock = 80 × 16 × 1024 × 2 × 2 = 5.24 × 106 bytes ≈ 5 MB 44 块 × 5 MB = 220 MB 实际使用 vs 256 块 × 5 MB = 1280 MB 预分配。 示例 3 PagedAttention 在 vLLM 基准测试中的典型表现（LLaMA-2-70B, A100-80GB×4, ShareGPT 数据集）如表17-112所示。 表17-112 PagedAttention 基准测试对比 指标 HuggingFace TGI（预分配） vLLM（PagedAttention） 提升 最大并发请求 32 128 4× 吞吐（tokens/s） 1200 3800 3.2× KV Cache 利用率 18% 88% 4.9× 平均 TTFT 2.3s 0.6s 3.8× 提升来自两方面：更高的 KV Cache 利用率直接增加并发数（4×），而 Continuous Batching 的结合进一步提升 GPU 利 用率，产生超线性的吞吐增益。

17.8.8 投机解码原理

投机解码（Speculative Decoding）通过小型草稿模型突破自回归 Decode 的串行瓶颈：标准 Decode 每步只生成一个 token，O 个输出 token 需 O 次串行前向传播，GPU 并行度被浪费。草稿模型（如 LLaMA-68M）自回归生成 K 个候选 token（K 通常为 3-8），目标模型（如 LLaMA-70B）以 K + 1 个 token 为输入一次前向并行验证各位置，按概率比 rand() < min(1, p /q ) 接受或拒绝，从第一个被拒绝的位置重新采样并重启草稿。理想情况下，草稿 K 次前向加目标模 型 1 次前向产出 K 个 token，速度提升 K 倍。 i i

1. 接受率与有效加速 令 α 为每个位置草稿 token 被接受的概率（接受率）。K 轮后期望生成的 token 数为： 1 − αK+1 E[tokensperstep] = 1−α 不同接受率 α 与草稿长度 K 下的期望生成 token 数如表17-113所示。 表17-113 期望生成 token 数 α K=3 K=5 K=8 0.9 2.44 3.54 4.58 0.8 2.08 2.76 3.37 0.7 1.72 2.10 2.40 0.6 1.42 1.62 1.76 对于 α = 0.8, K = 5：期望每步生成 2.76 个 token，约 2.76 倍加速。 草稿模型开销：LLaMA-68M（约 6.8 × 10 参数）的单次前向仅为 70B（70 × 10 参数）的约 1/1000。K=5 次草稿前向增 7 9 加的总计算量约 5/1000 = 0.5%，可忽略。
2. 影响接受率的因素 影响草稿接受率的因素如表17-114所示。 表17-114 接受率影响因素 因素 对 α 的影响 说明 草稿模型质量 高质量 → 高接受率 蒸馏版（如 LLaMA-3.2-1B 蒸馏自 70B）效果最好 温度 T T=0（贪婪）→ α 高；T>0 → α 降低 采样引入随机性，草稿与目标更可能分歧 任务类型 简单续写 → α 高；创意生成 → α 低 创造性任务分布更分散 上下文匹配度 上下文变化大时 α 下降 草稿模型对 downstream context 敏感
3. 实用加速效果 实际部署中，投机解码的加速效果取决于模型配对和任务，如表17-115所示。 表17-115 投机解码实际加速 草稿模型 目标模型 任务 K α 实际加速 LLaMA-68M LLaMA-7B 对话 5 0.85 2.1× LLaMA-160M LLaMA-13B 代码补全 5 0.80 1.9× LLaMA-3.2-1B LLaMA-3-70B 摘要 5 0.82 2.3× 前置条件：草稿模型需与目标模型共享 tokenizer。理想条件下（贪婪解码 + 高质量草稿模型），加速比可达 2-3×。但 Prefill 阶段不受影响，加速仅作用于 Decode。
4. 投机解码流程 投机解码的 Draft-Verify 循环如图17-50所示。 User Draft Model (LLaMA-68M) Target Model (LLaMA-70B) Prefix tokens loop [K rounds] Generate 1 token Prefix + K candidate tokens

One forward pass, verify all K Accept M (M <= K) tokens Rejected at position M+1 User Draft Model (LLaMA-68M) Target Model (LLaMA-70B) 图17-50 投机解码的 Draft-Verify 循环 草稿模型自回归生成 K 个候选，目标模型一次前向并行验证。 5) 变体与局限 变体：Medusa 在目标模型上增加多个预测头同时预测下 N 个 token，Eagle 在特征层面推测，Self-Speculative Decoding 跳过特定层充当草稿，均无需独立草稿模型。 局限： •对 Prefill 无帮助 •贪婪解码下效果最好（采样温度 T > 0 加速比例显著下降） •需要草稿模型与目标模型共享 tokenizer •草稿模型虽小（约 100 MB），仍需额外显存 核心结论：投机解码是解除自回归串行瓶颈的巧妙方案。通过草稿模型批量生成 + 大模型并行验证，在不改变输 出分布的前提下实现 2-3× Decode 加速。对于 Prefill 延时不敏感的批处理场景（如离线推理），是极具性价比的 优化。 示例 1 目标模型 LLaMA-70B（70 × 10 参数），草稿模型 LLaMA-68M（6.8 × 10 参数）。参数比： 9 7 Pdraf t 6.8 × 107 = ≈ 0.001 = 1/1000 70 × 109 Ptarget 草稿模型比目标模型小约 1000 倍。 取 K = 5（草稿每轮生成 5 个候选），接受率 α = 0.8。期望每轮目标模型前向生成的 token 数： 1 − 0.86 1 − 0.262 0.738 E[tokens] = = = = 3.69 1 − 0.8 0.2 0.2 每生成 3.69 个 token 的代价：草稿模型 5 次前向 + 目标模型 1 次前向。裸 Decode 需 3.69 次目标模型前向。 理论加速比： 3.69 speedup = = 3.69 × 扣除草稿模型开销（5/1000 = 0.5% 额外计算）： 3.69 speedupeff = ≈ 3.67 × 1 + 0.005 实际部署中因 kernel launch 开销、batch 调度等因素，加速比通常为 3.0~3.5×。 示例 2 贪婪解码（T=0）下草稿与目标分布确定，接受率最高。温度升高引入随机性，接受率下降，各温度下的加速比如表17- 116所示。 表17-116 温度对投机解码的影响 温度 T 接受率 α E[tokens] （K=5） 加速比 0（贪婪） 0.90 1−0.9 0.1 = 4.69 4.7× 0.3 0.85 1−0.856 0.15 = 3.88 3.9× 0.7 0.70 1−0.7 0.3 = 2.40 2.4× 1.0 0.55 1−0.55 0.45 = 1.67 1.7× 关键洞察：投机解码在低温度（T < 0.3）下效果最佳。高温度场景（如创意写作、对话多样性要求高）加速比显著下降， 可能不值得引入草稿模型的复杂性。

17.8.9 分块式 Prefill

长 prompt 的 Prefill 延时可能高达数十秒，不仅影响该请求的 TTFT，还会阻塞所有在它之后到达的新请求。Chunked Prefill 通过将长 Prefill 切分为小块并在 Decode 步间穿插执行，解决了这一排队阻塞问题。

1. 长 Prefill 的排队阻塞 传统调度中，一个 Prefill 必须一次性完成。当 S = 128K 的请求占据 GPU 26 秒时，所有新到达的短请求都在排队。 in 具体影响： •用户 A 发送 128K 的文档分析请求，Prefill 耗时 26 秒。 •用户 B 在 A 之后 1 秒发送一个简单的 50 token prompt。 •用户 B 的 TTFT 不是 Prefill 该有的 2 ms，而是 25 秒，全在排队。 这是交互服务不可接受的用户体验。
2. Chunked Prefill 原理 Chunked Prefill（Sarathi 论文提出，vLLM 实现）将长 prompt 切分为固定大小的 chunk（如 512 tokens），每步只处 理一个 chunk。 执行流程（chunk_size = 512, S_in = 128K）：

1. 第 1 步：处理 chunk 1（token 0-511），写入 KV Cache。
2. 第 2 步：处理 chunk 2（token 512-1023），同时 batch 中的其他请求执行 Decode。
3. …
4. 第 256 步：处理 chunk 256（token 130560-131071）。Prefill 完成，该请求进入 Decode。 每步的 GPU 计算被公平分配：长 Prefill 的 chunk 与其他请求的 Decode 共享 GPU 时间。

3. Split-Fuse 机制 DeepSpeed 提出的 Split-Fuse 进一步细化：不仅“切分”（Split）长 Prefill，还“融合”（Fuse）Prefill chunk 和 Decode 到同一 kernel 调用中。 优势： •减少 kernel launch：Prefill chunk 和 Decode 在同一个 GPU kernel 中完成，减少 40-60% 的 kernel launch 开销。 •计算负载均衡：每次 kernel 调用的计算量均衡，避免 Prefill 独占 GPU 时间片。
4. TTFT 改善 对于 Chunked Prefill 下的排队请求，其等待时间不超过一个 chunk 的时间： Twait_max = Tprefill_one_chunk

LLaMA-3-70B on H800，chunk_size = 512： 2 × 70 × 109 × 512 Tchunk = ≈ 104ms 692 × 1012 在 H20 上（有效算力 148 × 0.7 = 103.6 TFLOPS）： H20 2 × 70 × 109 × 512

103.6 × 1012

                              Tchunk =                        ≈ 692ms

H20 的 Chunked Prefill 单 chunk 耗时约 692 ms（vs H800 的 104 ms），慢约 6.7×。但这恰好是 Chunked Prefill 的设 计意图，将长 Prefill 切细后穿插 Decode，H20 的高带宽对 Decode 的加速（+19%）可部分抵消 Prefill 的劣势。 而完整 Prefill 需 26 秒。排队 TTFT 从 26 秒降至 约100 ms，提升了 260 倍。 对于不需要长 Prefill 的短请求，延时几乎不受影响，因为 chunk 计算与其他请求的 Decode 在同一 batch 中交替执行。 5) Chunked Prefill 时序 Chunked Prefill 切分长 Prefill 的时序如图17-51所示。 With Chunked Prefill t=0: Chunk1 of Req A Without Chunked Prefill

                                                        t=0: Req A (128K) starts Pre
         t=100ms: Chunk2 of Req A                                    fill
                + Decode
                                                        t=0-26s: Req B waits in que
          t=200ms: Chunk3 + Req                                     ue

B's Prefill + Decode t=26s: Req A Prefill done t=300ms: Chunk4 + Req B's Decode t=26s: Req B finally starts t=26s: Req A Prefill done (2 56 chunks total) 图17-51 Chunked Prefill 切分长 Prefill 将 26 秒的长 Prefill 切分为 256 个 100ms 的 chunk，穿插其他请求的 Decode。新请求不必等待完整 Prefill，仅需等待 当前 chunk 完成。 6) Chunk 大小的权衡 不同 Chunk 大小的优劣势如表17-117所示。 表17-117 Chunk 大小权衡 Chunk 大小 优势 劣势 小（64-128） 排队延时极低，公平性好 Kernel launch 开销大，Prefill MFU 略低 中（256-512） 平衡延时与效率 排队延时适中 大（1024+） Prefill MFU 高 排队延时较高，趋近完整 Prefill vLLM 默认 chunk_size = 256，并支持自适应调整。兼顾 Prefill 算力利用率和排队公平性。 7) 与 Continuous Batching 的协同 Chunked Prefill 和 Continuous Batching 是天然配合： •Continuous Batching：每步动态调整 batch 组成，移除完成请求、加入新请求。 •Chunked Prefill：长 Prefill 被切成小块，在每次 Continuous Batching 分配的一小段 GPU 时间中执行。 两者结合使每步的 GPU 计算均衡、公平分配，无论 prompt 长短，所有请求都能在 100 ms 左右开始收到第一个 token。 核心结论：Chunked Prefill 是解决长 prompt 排队阻塞的关键调度策略。它将原本需要数十秒的完整 Prefill 切分 为百毫秒级的小块，穿插 Decode 执行，将新请求的排队 TTFT 降低 2-3 个数量级。与 Continuous Batching 结合 后，推理系统可同时容纳长文档分析和短对话请求而不互相阻塞。 示例 1 LLaMA-3-70B，S = 128K，完整 Prefill 耗时 26.5s。 in 请求到达时间线： •t=0：请求 A（128K 文档分析）到达，开始 Prefill •t=1s：请求 B（50 token 对话）到达，排队 •t=5s：请求 C（200 token 翻译）到达，排队 •t=26.5s：请求 A Prefill 完成 •t=26.5s：请求 B 开始 Prefill（TTFT = 25.5s） •t=26.5+0.002s：请求 B Prefill 完成 •t=26.5s：请求 C 开始 Prefill（TTFT = 21.5s） 请求 B 和 C 的 TTFT 不是它们应得的 约2 ms，而是 25.5s 和 21.5s，全部被请求 A 阻塞。 示例 2 chunk_size=512，LLaMA-3-70B 单 chunk Prefill 时间： 2 × 70 × 109 × 512 Tchunk = = 0.1036 s ≈ 104 ms 692 × 1012 总 chunk 数：⌈131072/512⌉ = 256。 同样请求时间线（带 Chunked Prefill）： •t=0：请求 A chunk 1 执行（104 ms） •t=104ms：请求 A chunk 2 + 请求 B Prefill（2ms）并列执行 •t=106ms：请求 B Prefill 完成，TTFT ≈ 106ms（vs 25.5s） •t=208ms：请求 A chunk 3 + 请求 C Prefill（4ms） •t=212ms：请求 C Prefill 完成，TTFT ≈ 212ms（vs 21.5s） •…（每隔 104ms，请求 A 完成一个 chunk，新请求随时插入） TTFT 改善倍数：

25.5 × 103

≈ 241 × 即新请求的等待时间从数十秒降至百毫秒级别。对于交互服务，这是「不可用」与「即时响应」的差异。

17.8.10 量化推理分析

模型量化通过降低权重和激活值的数值精度减少推理的内存需求。在 Decode 阶段（内存带宽受限），量化直接转化为吞 吐提升和成本下降。

1. 量化对推理的影响 Decode 阶段每步需从 HBM 加载全部权重。减少每个参数的字节数，等比例减少内存加载时间： 量化减少每个参数的字节数，等比例减少内存加载时间。不同精度的权重大小与理论加速如表17-118所示。 表17-118 量化精度与理论加速 精度 字节/参数 P = 8B 权重大小 P = 70B 权重大小 理论加速 FP32 4 32 GB 280 GB 0.5×（基线更慢） BF16/FP16 2 16 GB 140 GB 1×（基线） FP8 1 8 GB 70 GB 2× INT8 1 8 GB 70 GB 2× INT4 0.5 4 GB 35 GB 4× LLaMA-3-70B INT4：140 GB → 35 GB。单 H800（80 GB）可装下带余量，单 H20（96 GB）余量更大，无需 TP。
2. FP8 推理 NVIDIA H800/H20 及以上（Hopper 架构）支持原生 FP8 Tensor Core。FP8 有 E4M3（4 位指数、3 位尾数）和 E5M2 （5 位指数、2 位尾数）两种格式。 特点： •权重和激活值均为 1 字节 •动态范围与 BF16 相近（E4M3 格式） •精度损失极小（通常 < 0.1% perplexity 增加） •无需校准数据集 吞吐计算： LLaMA-3-70B FP8 on H800 TP=4，每 GPU 权重 17.5 GB（vs BF16 35 GB）： 17.5GB H800 Tdecode ≈ ≈ 5.2ms 3.35TB/s H20 FP8 TP=4，每 GPU 权重 17.5 GB： H20 17.5GB Tdecode ≈ ≈ 4.4ms 4.0TB/s H20 FP8 Decode 延时 4.4 ms 相比 H800 BF16 的 10.5 ms 快了 2.4×（组合量化 + 高带宽效应）。 相比 BF16 的 10.5 ms，约 2× 加速。单 TP group 吞吐从 约3040 tokens/s 提升至 约6100 tokens/s。
3. INT8 量化 INT8 量化（SmoothQuant、LLM.int8()）使用 8 位整数表示权重。 核心挑战：激活值存在异常值（Outlier），简单 Uniform INT8 量化会造成显著精度损失。LLM.int8() 将异常值特征维度 保留为 FP16，其余量化；SmoothQuant 通过数学上等效变换将量化难度从激活值转移到权重。 精度与性能： •典型 perplexity 增加 < 0.1% •需校准数据集（数百条样本即可） •对长序列 KV Cache 也可 INT8 量化（节省 2× KV 显存）
4. INT4 量化 GPTQ（Optimal Brain Surgeon 量化）和 AWQ（Activation-Aware Weight Quantization）是 INT4 的主流方法。每个 参数仅 0.5 字节。 GPTQ：基于 Hessian 矩阵逐层量化，补偿量化误差。需校准数据集（128 样本即可）。 AWQ：观察到并非所有权重同等重要，激活值较大的 channel 对应权重应保留更高精度。通过 per-channel scaling 保护 关键 channel。 精度对比（LLaMA 系列，WikiText-2 困惑度）： 各量化方法在 LLaMA 系列上的精度损失如表17-119所示。 表17-119 量化精度损失对比 模型 BF16 INT4-GPTQ INT4-AWQ 精度损失 LLaMA-2-7B 5.47 5.62 (+2.7%) 5.54 (+1.3%) 中度 LLaMA-2-13B 4.88 4.97 (+1.8%) 4.93 (+1.0%) 轻度 LLaMA-2-70B 3.32 3.38 (+1.8%) 3.35 (+0.9%) 轻微 LLaMA-3-8B 6.14 6.22 (+1.3%) 6.18 (+0.7%) 轻微 越大模型对量化越不敏感。70B INT4 的困惑度增加通常在 1% 以内。
5. 量化的硬件适用性 各量化方案的硬件适用性与收益如表17-120所示。 表17-120 量化方案硬件适用性 量化方案 所需硬件 显存节省 Decode 加速 适用场景 FP8 H800+ 2× 2× 生产级推理，精度无损 INT8 通用 GPU 2× 2× 长上下文、KV Cache 压缩 INT4 通用 GPU 4× 3-4× 大模型单卡部署、低成本服务 INT4 的实际加速通常低于理论值（接近 3-3.5×），因 INT4 反量化有额外计算开销。
6. 组合量化 同时量化权重和 KV Cache 可获得更大的显存节省，各组合方案如表17-121所示。 表17-121 权重与 KV Cache 组合量化 组合 权重（GB） KV Cache/请求（GB, S=4096） 单卡并发 加速 BF16 权重 + BF16 KV 140 1.34 0（需 TP4=32） 1× INT8 权重 + BF16 KV 70 1.34 7 2× INT4 权重 + BF16 KV 35 1.34 33 3.5× INT4 权重 + INT8 KV 35 0.67 67 3.5× LLaMA-3-70B INT4 权重 + INT8 KV Cache：单 H800 可支撑 67 个并发，单 H20（96 GB）可支撑更多，是 BF16 TP=4 方 案的 2× 以上。
7. 精度与效率权衡 量化阶梯如图17-52所示，从左到右精度降低、吞吐提升。 FP8 2× mem 1 byte ~0% loss FP32 BF16 INT8 4 bytes 2× mem 2 bytes 2× mem 1 byte Baseline Standard <0.1% loss INT4 4× mem 0.5 bytes 0.5-2% loss 图17-52 量化阶梯 从左到右精度降低，吞吐提升。FP8 是 H800/H20 推理的首选（精度无损、2× 加速），INT4 是大模型单卡部署的极致选 择。 核心结论：INT4/INT8/FP8 量化是推理提效最直接的杠杆。INT4 可 4× 压缩权重，使 70B 模型在单卡运行。FP8 （H800/H20）在精度无损下实现 2× 加速。量化 + PagedAttention + Continuous Batching 的组合是生产级推理 效率的三大支柱。 示例 1 LLaMA-3-70B on H800 TP=4（BF16 为基线），S = 4096，B = 32。为聚焦精度对比，此处采用仅权重流时间的上界口径 （含 KV 访存的批处理口径数值略低）： H800,BF 16 35

3.35 × 103

                     Tdecode     =              = 10.45 ms → 3062 tok/s

H20 BF16 TP=4： H20,BF 16 35

4.0 × 103

                      Tdecode    =             = 8.75 ms → 3657 tok/s

各精度下 H800 与 H20 的吞吐对比如表17-122所示。 表17-122 各精度推理吞吐对比 精度 H800 吞吐(tok/s) H20 吞吐(tok/s) H20 优势 BF16 TP=4 3062 3657 +19% FP8 TP=4 6130 7300 +19% INT4 TP=1 12260 14630 +19% H20 在所有精度下吞吐均比 H800 高约 19%，因为 Decode 吞吐与 HBM 带宽呈正比，而 H20 的 4.0 TB/s 比 H800 的 3.35 TB/s 高 19.4%。表中各行均为纯权重流时间推出的理论上限；INT4 计入反量化与校准开销后，实际加速约为 3~3.5×。 示例 2 S = 128K，LLaMA-3-70B 的 KV Cache 大小： BF 16 MKV = 80 × 131072 × 1024 × 2 × 2 ≈ 42.9 GB INT8 KV Cache（2× 压缩）： INT 8 MKV = 42.9/2 = 21.5 GB 组合效果（INT4 权重 + INT8 KV Cache，单卡部署，权重 35 GB，overhead 2 GB）： H800 Mavailable = 80 − 35 − 2 = 43 GB H800 Nconcurrent = = 2 requests 21.5 H20 96 GB 对比： H20 Mavailable = 96 − 35 − 2 = 59 GB H20 Nconcurrent = ≈ 2.7 → 2 requests 21.5 两款卡都能在单卡上承载 2 个 128K 长上下文并发。作为参照：BF16 权重共 140 GB，无法装入任何单卡，只能以 TP=4 组运行；组内 KV 按 4 卡分片后每请求占每卡约 10.7 GB，每卡折合仅支撑 1 个长上下文并发。而 INT4 权重 + INT8 KV 组 合下，一张卡即可独立承载 2 个完整的长上下文请求。量化与 KV 压缩的叠加效应在长上下文场景中从「量变」升级为 「质变」。

17.8.11 推理成本估算

将前述各节的推理性能指标转化为经济指标，回答核心商业问题：服务一个用户、处理一百万个 token、支撑日活一万用 户，分别要花多少钱？

1. 基础成本模型 推理的总成本由 GPU 时间决定： Cost = GPU_hours × price_per_GPU_hour

GPU 小时数由部署 GPU 总数和运行时长决定： GPU_hours = NGP U × uptime_hours 更精细的每条请求成本由请求的 token 数和系统吞吐决定： Sin + O Costperrequest = × price_per_GPU_hour Throughput 2) 按 Token 计费模型 price_per_GPU_hour Costpertoken = Throughput(tokens/hour) 实例 1：LLaMA-3-70B BF16 TP=4 on 4×H800，吞吐 3040 tokens/s，H800 按 $2.50/h/GPU 计算： Throughputperhour = 3040 × 3600 = 10.94 × 106 tokens TotalGPUcostperhour = 4 × $2.50 = $10.00 $10.00 Costper1Mtokens = ≈ $0.91 10.94 实例 2：LLaMA-3-8B BF16 on 1×H800，吞吐 25600 tokens/s： $2.50

25.6 × 3.6

                                     Costper1Mtokens =               ≈ $0.027

对比 API 定价（2025 年参考）与自建成本如表17-123所示。 表17-123 API 定价与自建成本对比 服务 价格（$/1M tokens） 说明 GPT-4o $2.50 / $10.00 (input/output) OpenAI Claude 3.5 Sonnet $3.00 / $15.00 Anthropic DeepSeek-V3 $0.27 / $1.10 极高性价比 Self-host LLaMA-3-8B 约$0.03 仅 GPU 成本 Self-host LLaMA-3-70B（4×H800） 约$0.91 仅 GPU 成本 Self-host LLaMA-3-70B INT4（1×H800） 约$0.30 量化降低成本 自建 8B 模型推理的纯 GPU 成本仅 0.03$/M tokens。70B INT4 单卡方案约 0.30$/M tokens，介于知名 API 价格之下。 3) Cloud API vs Self-Hosted Cloud API 优势：按使用量付费，闲置时无成本；运维由提供商负责，SLA 有保障；起量快，无需硬件采购周期。 Self-Hosted 优势：GPU 满负荷时单位成本更低；数据不出自有环境，合规要求满足；可定制推理 pipeline。 盈亏平衡点：自建成本由集群规模决定、与用量无关，API 成本严格按用量计费，二者存在平衡点。以日 token 量表示： NGP U × PGP U × 24 Vbreakeven (M tokens/day) = PAP I − Cinf ra 其中 P 为单卡时价（$/h），P 为 API 输出单价（$/1M tokens），C 为自建侧每百万 token 摊销的基础设施开 销（电力、带宽、运维）。两组典型基线的计算： GP U AP I inf ra •GPT-4o 基线（$2.50/1M output tokens）：Self-host 取 4×H800（$10/h，日成本 $240），C = 0.5：V = 240/(2.50 − 0.50) = 120 M tokens/day。 inf ra breakeven •GPT-4 基线（$30/1M output tokens）：Self-host 取单节点 8×H800（$24/h，日成本 $576），保守起见忽略 C ： = 576/30 = 19.2 M tokens/day。 inf ra V breakeven 盈亏平衡点对 API 基线和集群规模都高度敏感：API 单价越贵、单位 token 分摊的 GPU 越少，自建越早划算。同时注意 自建是固定成本，8×H800 满载一天可产出 216M tokens（2500 tokens/s × 86400 s），若日需求只有 1000 万，利用率 不足 5%，$576 的日固定成本远高于同等用量下 $300 的 API 支出。需求规模小或波动大时，API 通常更经济。 4) 多租户与 LoRA 适配 一 GPU 可服务多个 LoRA adapter（轻量微调），共享基础模型权重。 LoRA 成本分摊： •基础模型权重加载一次（如 LLaMA-3-8B BF16 16 GB） •每个 LoRA adapter 仅增加约 10-50 MB（取决于 rank 和 target modules） •100 个 concurrent adapters 额外显存仅 1-5 GB 一台 H800 可同时服务数十个不同 LoRA adapter，每个适配器的边际推理成本几乎为 0。这使“模型服务即平台” （Model-as-a-Platform）的经济模型可行。 5) Spot / Preemptible 实例降本 GPU spot 实例以标准价格的 30-40% 提供，但可被随时回收，各 GPU 的 spot 价格如表17-124所示。 表17-124 Spot 实例价格对比 GPU 类型 On-demand ($/h) Spot ($/h) 节省

H800-80GB              $2.50-4.00                               $0.80-1.20             60-70%
H20-96GB               $0.80-1.50                               $0.30-0.60             60-70%
A100-80GB              $1.50-2.50                               $0.50-0.80             60-70%
A100-40GB              $1.00-1.50                               $0.30-0.50             60-70%

适用场景：离线批处理推理（如全量数据标注、批量 embedding 生成），通过 checkpoint 机制处理中断。不适合在线服 务。 6) 不同规模的成本估算 不同规模产品的推荐方案与日成本如表17-125所示。 表17-125 不同规模推理成本估算 规模 日 token 量 推荐方案 GPU 需求 日成本 个人开发者 < 10K API 0 约$0.05/日 小型产品 1M Self-host LLaMA-3-8B 1×H800 约$60/日 中型产品 100M Self-host LLaMA-3-70B INT4 4×H20 约$100/日 大型产品 1B Self-host LLaMA-3-70B 集群 32×H800 约$1920/日 平台级 10B+ 混合部署 + LoRA 多租户 128-256×H800 约$8K-16K/日 7) 成本分解 自建推理的成本分解如图17-53所示，GPU 计算占主导。 1M Output Tokens GPU Compute Power & Cooling Network Egress DevOps & Oncall ＄0.03-0.91 ~10% of GPU ~＄0.01/GB Labor cost Total Cost ＄0.05-1.50/M tokens 图17-53 自建推理成本分解 GPU 计算占主导（约80%），电力网络和运维占剩余部分。 核心结论：推理成本是模型大小和吞吐的函数。小模型（8B 级）单卡即可提供极低成本（$0.03/M tokens）。大模 型（70B）通过 INT4 量化可单卡部署降低成本至 约$0.30/M tokens。盈亏平衡点对 API 基线高度敏感：对标 GPT-4（$30/M）约在日 2000 万 token，对标 GPT-4o（$2.5/M）则需日 1 亿以上。LoRA 多租户和 spot 实例是进 一步降低单位成本的有效手段。 示例 1 LLaMA-3-70B BF16 部署于单节点 8×H800（运行 2 个 TP=4 组），混合 Prefill/Decode 负载下总吞吐约 2500 tokens/s （保守估计），H800 on-demand 价格 $3.00/h/GPU： Cost/hour = 8 × 3.00 = $24.00 Tokens/hour = 2500 × 3600 = 9 × 106 24.00 Cost/1M tokens = = $2.67 对比 GPT-4 API（$30/1M tokens output）： ≈ 11.2 × 2.67 Cloud API 溢价约 11×。这个溢价覆盖了 API 提供商的利润、运维、闲置 GPU 摊销、带宽和研发成本。 示例 2 Spot 实例可进一步压缩单位成本。取 H800 spot 约 $1.00/h、H20 spot 约 $0.50/h（均在上文 spot 价格区间内），对比 相同的 4 卡 TP=4 配置： H20（4 卡 TP=4，吞吐 3630 tokens/s，时产约 13.1M tokens）： 4 × 0.50 Cost/1M tokens = ≈ $0.15 13.1 H800（4 卡 TP=4，吞吐 3040 tokens/s，时产约 10.9M tokens）： 4 × 1.00 Cost/1M tokens = ≈ $0.37 10.9 H20 推理成本优势：H20 在推理场景中提供「高带宽 + 低价格 + 大容量」的组合优势。相同 TP=4 配置下，H20 每 百万 token 成本约 $0.15（vs H800 $0.37），优势达 2.4×。这来源于两方面：(a) H20 单卡 spot 价格约为 H800 的一半；(b) 更高的 HBM 带宽直接转化为更高的 Decode 吞吐（+19%）。

17.9 端到端案例

本节将前述各节的公式串联为完整训练方案：依次给出 LLaMA-7B Dense 训练、DeepSeek-V2 风格 MoE 训练与千卡级 GPT 量级训练三个递进案例，并抽象出从零规划与常见经验法则，最后以 H800 与 H20 的选型对比收尾。

17.9.1 LLaMA-7B 训练

本节将全书计算方法串联为一个完整案例：用 H800 训练 LLaMA-7B 模型。

1. 模型参数验证 LLaMA-7B 的核心架构参数： •层数 L = 32 •模型维度 d = 4096 •FFN 中间维度 d = 11008 ff •词表大小 V = 32000 •注意力头数 n = 32（MHA，非 GQA） heads 代入参数量公式，非 Embedding 参数量（舍去词表项）： Ptransf ormer = L × (4d2 + 3d ⋅ dff + 2d) 主项计算： P ≈ 32 × (4 × 40962 + 3 × 4096 × 11008 + 2 × 4096) P ≈ 32 × (67,108,864 + 135,266,304 + 8,192) ≈ 6.48 × 109 加上词表 Embedding 与 LM Head 约 0.26B 后总参数量约 6.74B，与官方报告一致。
2. 训练 FLOPs 计算 单 Token 计算量： Cf wd ≈ 2P = 2 × 6.74 × 109 ≈ 13.48 GFLOPs 全量训练 FLOPs，目标训练 Token 数 D = 2 × 10 （2T tokens）： Ctotal = 6P D = 6 × 6.74 × 109 × 2 × 1012 = 8.09 × 1022 FLOPs

这个数字约 8 × 10 FLOPs，即约 80.9 万亿亿（80.9 Zetta）次浮点运算。 3) 显存全景分析 以 BF16 混合精度 + Adam 优化器计算：

 P = 6.74e9   # non-embedding params
 # Weights: BF16 master + FP32
 W_bf16 = 2 * P    # 13.48 GB
 W_fp32 = 4 * P    # 26.96 GB
 # Optimizer: Adam m + v
 Opt_m   = 4 * P   # 26.96 GB
 Opt_v   = 4 * P   # 26.96 GB
 # Gradients: BF16
 Grads   = 2 * P   # 13.48 GB
 # Base memory (16P bytes
 M_base = 16 * P # 107.84 GB

单卡结论：107.8 GB 基础显存远超 H800 的 80 GB。即便不算激活值，LLaMA-7B 也无法在单卡完成 BF16 训练。必须使 用并行策略分片。 4) 方案对比 方案 A：ZeRO-3 on 8 GPU： ZeRO-3 将权重、梯度、优化器状态均分至 N = 8 卡： 16P 107.84 Mper_GPU_base = = = 13.48 GB 8 8 激活值在全量重计算下，序列长度 S = 4096 时约 1 GB。CUDA context 和临时缓冲区约 0.5 GB。 Mper_GPU_total ≈ 13.48 + 1.0 + 0.5 = 14.98 GB 远小于 80 GB，余量充裕。ZeRO-3 的额外通信开销（参数 All-Gather）在 NVLink 环境下可被计算覆盖。 方案 B：TP=4, DP=2： TP 按 4 卡切分，DP 按 2 组拷贝： 107.84 Mper_TP_GPU = = 26.96 GB 加上激活值和开销后约 28.5 GB，仍可装入 80 GB。 方案选择：如果只有单节点 8 卡，ZeRO-3 通信更均衡（DP 通信为主），且总显存余量更大。TP=4 引入了跨卡 All- Reduce 和 All-Gather，可能导致少量通信开销。本案例采用 ZeRO-3 继续分析。 5) 训练时间估算 单节点 8×H800：

 P = 6.74e9; D = 2e12; N = 8
 peak = 989.5e12 # BF16 per H800
 MFU = 0.45       # NVLink-only, ZeRO-3 ◀ optimistic for single node
 T_sec = (6 * P * D) / (N * peak * MFU)
 # = 8.09e22 / (8 * 989.5e12
 # = 8.09e22 / 3.56e15 ≈ 2.27
 T_days = T_sec / 86400 # ≈ 263 days

263 天，完全不现实。单节点 8 卡即使满效率也只有约 3.56 PFLOPS 的有效算力，而总需求是 8.09 × 10 FLOPs。 22 扩展到 256 GPU（32×8 节点）：

 N = 256
 MFU = 0.38    # cross-node IB reduces MFU ~7 pts
 T_sec = 8.09e22 / (256 * 989.5e12 * 0.38)
 # = 8.09e22 / 9.62e16 ≈ 8.41
 T_days = T_sec / 86400 # ≈ 9.7 days

256 卡约 10 天，这是 LLaMA-7B 训练的典型配置。 6) Step Time 拆解 以 B = 4、S = 4096、ZeRO-3、GA=16在 32 节点配置下拆解单步： micro 计算时间： 前向 FLOPs ≈ 2 × 6.74 × 10 × 4 = 53.9 GFLOPs。反向约 2 倍。总共约 162 GFLOPs。纯算力耗时约 162/989.5 ≈ 0.16 ms，但实际因内存墙约 15 ms。 DP 通信： 梯度 All-Reduce：每卡传输量 = 2 × × 2P 。DP 跨 32 节点： N −1 N PerGPUcomm = 2 × × 2 × 6.74 × 109 ≈ 2.61 × 1010 bytes ≈ 26.1 GB IB NDR 每卡 50 GB/s，通信时间： 26.1 tcomm_raw = ≈ 0.52 s 梯度累积 16 步后触发一次 All-Reduce，实际分摊通信： 0.52 tcomm_amortized = ≈ 33 ms 重叠效果：33 ms 通信可被 15 ms 计算部分重叠（反向计算期间后台通信）。最终 step time ≈ 20 到 25 ms。 7) 检查点与存储 检查点包含 BF16 权重 (2P=13.5 GB) + FP32 优化器 (8P=53.9 GB) ≈ 67.4 GB。 256 GPU 异步写检查点，每卡写 67.4/256 ≈ 263 MB。使用 Lustre 并行文件系统（聚合写带宽约 100 GB/s），全局保存时 间约 0.7 秒，可忽略。 8) 成本估算 256 H800 × 10 天 × 24h = 61,440 GPU-hours。按 2/h预留价格：Cost = 61, 440 × 2 = $122, 880按需价格4/h 则为约 246K 。加上网络和存储开销，总成本约150K-300K。 9) 全流程系统架构 LLaMA-7B 256 卡训练集群的系统拓扑如图17-54所示。 Pre-tokenized Dataset 2T tokens Training Cluster (256 H800, 32 Nodes) Node 1 (8xH800, NVLink) GPU 0 GPU 1 GPU 2 GPU 3 Node 2 8xH800 NVLink GPU 4 GPU 5 GPU 6 GPU 7 IB NDR 50GB/s IB NDR DP All-Reduce Lustre FS Loss Monitoring IB Switch CKPT ~67GB Logs + TensorBoard Rail-Optimized Save <1s Aggregate 400GB/s ... Node 32 图17-54 LLaMA-7B 256卡训练集群系统拓扑 10) 小结 LLaMA-7B 训练案例的关键数字汇总如表17-126所示。 表17-126 LLaMA-7B 训练案例关键数字 维度 数值 模型参数 6.74B（非 Embedding） 训练 Token 2T 单卡显存 13.5 GB（ZeRO-3 后） 并行策略 DP=256, ZeRO-3, GA=16 GPU 规模 256×H800 训练时长 约10 天 MFU 约38% 训练成本 约$123K（预留）/ 约$246K（按需） 检查点大小 67.4 GB 核心经验：LLaMA-7B 级别的模型，单卡装不下训练状态，但 8 卡单节点 ZeRO-3 即可解决显存问题。真正的瓶颈是训练 时长，单节点 263 天不可接受，必须扩展到数百卡。256 卡时 IB 跨节点通信是 MFU 的主要损耗源。

17.9.2 DS-V2 训练

本节以 DeepSeek-V2 Lite 风格的 MoE（Mixture of Experts）模型为例，分析大规模 MoE 训练的显存、通信和算力特 征。与上一节 Dense 模型不同，MoE 引入了专家并行（EP）和 All-to-All 通信，通信模式从 DP 主导变为 EP 主导。

1. 模型架构 目标模型参数： •总参数量 P ≈ 236 B total •激活参数量 P ≈ 21 B active •专家数 E = 64，每 Token 激活 k = 6（Top-K gating） •共享专家层：每层另有少量非 MoE 参数 •模型维度 d = 5120model •含 MoE 的层数 L 占全部层的约 60% moe MoE 的核心特征：总参数量巨大（236B），但每个 Token 只激活约 21B 参数。训练时所有专家均有梯度更新，因此显存 和通信面对的是 236B，而计算面对的是 21B。
2. 显存分析 基础显存： Mtotal_base = 16Ptotal = 16 × 2.36 × 1011 ≈ 3.78 TB

在 64 GPU 上（8 节点 × 8 GPU），未经分片每卡基础显存：

3.78 TB

                                               Mper_GPU_base =                                            ≈ 59 GB

加上激活值（MoE 层激活值更大，约 5-10 GB），单卡约 65-69 GB，接近 H800 80 GB 上限。 并行策略分片： MoE 训练常用组合为 EP + DP + ZeRO-1（而非 ZeRO-3，因为 All-to-All 通信已十分密集，ZeRO-3 的参数 All-Gather 会 进一步加剧通信压力）： •EP=8：每个 EP 组含 8 GPU，共 64/8 = 8 个 EP 组 •DP=8：DP 组与 EP 组大小相同 •ZeRO-1：仅分片优化器状态，不分片参数和梯度 ZeRO-1 分片优化器（8P）： 8Ptotal 8 × 236 × 109 Mopt_per_GPU = = ≈ 29.5 GB 64 64 BF16 权重 (2P ) 在各 GPU 复制（专家参数只在对应 EP 组内）： EP=8 下，每个 GPU 持有的专家参数约为 P /8 ≈ 29.5 B，2P ≈ 59 GB。加上梯度、激活值和开销后，单卡总显 per_GPU 存约 70-75 GB，勉强可装入 80 GB。 total 更常见的做法是叠加 ZeRO-2（同时分片梯度和优化器），将单卡显存降至 40-50 GB。 3) 通信分析 MoE 的通信瓶颈来自专家并行。每层 MoE 的通信模式如下： 单个 MoE 层的 All-to-All 传输量： EP − 1 Va2a = B × S × dmodel × ×2 EP 以B micro = 4 、S = 4096、d model = 5120 、EP = 8 代入： Va2a = 4 × 4096 × 5120 × × 2 ≈ 1.47 × 108 bytes ≈ 140 MB 一次 All-to-All 分 dispatch（Token→Expert）和 combine（Expert→Token）两个方向，每方向各一个 All-to-All。单层 总通信： Va2a_per_layer = 2 × 140 = 280 MB 假设 L moe = 24 层 MoE（占全部层 60%，共约 40 层），每步总通信： Va2a_total = 24 × 280 MB ≈ 6.7 GB 通信时间： •EP 组内（NVLink, 400 GB/s for H800）：t comm = 6.7/400 ≈ 16.8 ms。可接受。 •EP 跨节点（IB NDR, 50 GB/s 每卡）：t = 6.7/50 ≈ 134 ms。严重瓶颈。 comm 结论：EP 组必须保持在 NVLink 域内（EP ≤ 8），否则 All-to-All 通信会成为训练瓶颈。H800 的 NVLink 带宽（400 GB/s）为 H100（900 GB/s）的 44%，在同等 EP 规模下通信时间更长，需更保守的 EP 规划。 4) 训练 FLOPs 与时间 有效计算量（只计激活参数）： Cper_token ≈ 6Pactive = 6 × 21 × 109 = 126 GFLOPs 目标 8T Token 训练： Ctotal = 126 × 109 × 8 × 1012 = 1.01 × 1024 FLOPs 训练时间（256 GPU，H800 BF16，MFU 需下调）： MoE 训练 MFU 通常比 Dense 低 5-15 个百分点（All-to-All 开销、负载不均衡）。取 MFU=35%（vs. Dense 40-45%）：

 N = 256; peak = 989.5e12; MFU = 0.35
 T_sec = 1.01e24 / (256 * 989.5e12 * 0.35)
 # = 1.01e24 / 8.87e16 ≈ 1.14
 T_days = T_sec / 86400 # ≈ 132 days

132 天过长。扩展到 1024 GPU：

 N = 1024; MFU = 0.32 # further MFU drop at scale
 T_days = 1.01e24 / (1024 * 989.5e12 * 0.32) / 86400
 # ≈ 36 days

5. EP+DP 通信拓扑 DS-V2 风格 MoE 训练的 EP+DP 通信模式如图17-55所示。 Input Tokens (B=4, S=4096) Token Batch Top-6 Gating

EP Internal EP Internal Shared Expert All-to-All (NVLink) All-to-All (NVLink) All GPUs ~140MB/dispatch EP Group 0 (8 GPUs, NVLink) EP Group 7 (8 GPUs, NVLink) GPU 0: Expert 0-7 GPU 1: Expert 8-15 GPU 2: Expert 16-23 GPU 3: Expert 24-31 GPU 4: Expert 32-39 GPU 5: Expert 40-47 GPU 6: Expert 48-55 GPU 7: Expert 56-63 Same expert distribution Shared Expert as Group 0 DP Replica DP All-Reduce DP All-Reduce Gradients (IB NDR) Gradients (IB NDR) IB Switch 图17-55 DS-V2 风格 MoE 训练的 EP+DP 通信模式 6) 关键洞察 Dense 与 MoE 训练特征的关键对比如表17-127所示。 表17-127 Dense 与 MoE 训练特征对比 维度 Dense（LLaMA-7B） MoE（DS-V2 Lite） 总参数量 6.74B 236B 激活参数量 6.74B 21B 每 Token FLOPs 13.5 GFLOPs 126 GFLOPs 主要通信模式 DP All-Reduce EP All-to-All 维度 Dense（LLaMA-7B） MoE（DS-V2 Lite） 通信瓶颈 跨节点 IB EP 必须在 NVLink 内 MFU 38-45% 30-35% 核心约束 显存分片（ZeRO-3） EP 通信 + 负载均衡 核心经验：MoE 的聪明之处在于用更少的计算（激活参数）撬动更大的模型容量（总参数），但代价是更复杂的通信模式 （All-to-All 比 All-Reduce 更“重”）和更低的 MFU。EP 组跨节点是绝对禁忌，All-to-All 必须限制在 NVLink 域内。

17.9.3 千卡 GPT 训练

本节以一个 GPT-4 量级的 MoE 模型（约 1.8T 总参数）在 1024×H800 上的训练为案例，推演超大模型的并行分解、通 信规划和成本估算。这是“推向极限”的案例，几乎所有维度都接近当前硬件的天花板。

1. 模型参数 •总参数量 P ≈ 1.8 × 10 （1.8T） total •专家数 E = 16，Top-2 gating，激活参数量 P ≈ 2.2 × 10 （220B） active •模型维度 d ≈ 16384 model •层数约 L ≈ 120 •目标训练 Token 数 D ≈ 15 × 10 （15T） 12
2. 并行策略分解 1.8T 参数的基本显存：M = 16P = 28.8 TB。1024 GPU 均分后每卡约 28.1 GB，尚有余量。但实际训练还需考虑： base total •激活值（长序列下可达 20-30 GB 每卡） •通信缓冲区 •CUDA context 和框架开销 因此需叠加多种并行策略。采用 4D 并行分解： Ntotal = EP × TP × PP × DP = 1024

采用 4D 并行分解，具体分配如表17-128所示。 表17-128 1024 GPU 并行分解 维度 符号 取值 作用域 通信方式 专家并行 EP 8 NVLink 节点内 All-to-All 张量并行 TP 8 NVLink 节点内 All-Reduce + All-Gather 流水线并行 PP 8 跨节点 P2P Send/Recv 数据并行 DP 2 跨 PP 副本 All-Reduce 验证：8 × 8 × 8 × 2 = 1024。EP 和 TP 各 8 卡正好填满一个 NVLink 节点，避免了跨节点的高频通信。 3) 每卡显存验证 EP=8 将专家参数分布在 8 个 EP 组，TP=8 按张量维度再切分，PP=8 使每卡只持有 1/8 的层。三者叠加后每卡持有的参 数为： Ptotal 1.8 × 1012 Pper_GPU = = ≈ 3.5 × 109 EP × TP × PP 8×8×8 EP、TP、PP 三者叠加后，每卡的显存组件如表17-129所示。 表17-129 每卡显存组件 组件 公式 每卡 权重 + FP32 master 6Pper_GPU 21 GB Adam 优化器状态 8Pper_GPU 28 GB BF16 梯度 2Pper_GPU 7 GB 合计（无 ZeRO） 16Pper_GPU 56 GB 56 GB 基础显存已可装入 80 GB，但叠加激活值（PP=8 下每卡仅存 1/8 层激活，约 8-12 GB）、通信缓冲区（约 2 GB）和 框架开销（约 1.5 GB）后总显存逼近 70 GB。实践中最常叠加 ZeRO-1 沿 DP 维再分片优化器状态，将优化器降至约 14 GB，总显存降至约 48-55 GB，在 H800 80 GB 内充裕。 4) 通信逐层拆解 按每一步的通信模式，四种并行的通信特征如下： TP 通信（节点内，每层）： TP=8 的 All-Reduce 和 All-Gather 在每层 Transformer 中触发约 2-4 次。每层通信量约 B × S × d × 3（约 100 MB/ 层）。在 NVLink 400 GB/s（H800）上约 0.25 ms/层，120 层共约 30 ms。通常被计算覆盖。 model PP 通信（节点间，每 micro-batch）： P2P 传递激活张量，大小为 B × S × d 。B = 1 时约 1 × 4096 × 16384 ≈ 67 MB。在 IB 50 GB/s 上约 1.3 ms。PP bubble 通过足够多的 micro-batch（≥ 4×PP）减至可接受。 micro model micro EP 通信（节点内，每 MoE 层）： 每个 MoE 层的 All-to-All。EP=8 组内通信，单层约 B × S × d × × 2： model EP −1 EP Va2a ≈ 1 × 4096 × 16384 × × 2 ≈ 117 MB dispatch + combine 共约 235 MB/层。假设 MoE 层占全部层的 30%（约 36 层），总通信 36 × 235 ≈ 8.5 GB。 在 NVLink 400 GB/s（H800）上约 21 ms。这是单步内需要显式暴露的通信开销，但仍在可控范围。H800 的 NVLink 带 宽仅为 H100（900 GB/s）的 44%，在相同 MoE 配置下 All-to-All 通信时间约为 2.3×，这是 H800 在中国市场定位下的 关键权衡。 DP 通信（节点间，每 GA 步）： DP=2，梯度 All-Reduce 量极小（2 × × 2P ，约 P × 2 ≈ 3.5 GB），且配合大 GA（≥ 32），分摊后几乎不计。 per_GPU 5) 训练时间估算 总 FLOPs（只计激活参数）： Ctotal = 6 × 2.2 × 1011 × 1.5 × 1013 = 1.98 × 1025 FLOPs 1024 GPU，H800 BF16=989.5 TFLOPS，MFU 取 35%（MoE All-to-All 压缩 MFU）：

 C = 1.98e25; N = 1024; peak = 989.5e12; MFU = 0.35
 T_sec = C / (N * peak * MFU)
 # = 1.98e25 / (1024 * 989.5e12
 # = 1.98e25 / 3.55e17 ≈ 5.58
 T_days = T_sec / 86400 # ≈ 646 days

1024 卡需要约 646 天（近两年），实际不可行。这是一个重要信号：1.8T MoE 模型的 1024 卡训练完全不现实，必须纳 入数千到数万卡的规划。 扩展到 16384 GPU（2048 节点 × 8 GPU），MFU 下调至 32%：

 N = 16384; MFU = 0.32
 T_days = 1.98e25 / (16384 * 989.5e12 * 0.32) / 86400
 # ≈ 43 days

16384 卡约 43 天，这是业界 GPT-4 量级模型的典型训练规模。 6) 网络拓扑 2048 节点（每节点 8×H800 NVLink），采用 8-rail 优化的 IB NDR 网络： 16384-GPU 集群的 8-Rail 优化 IB 拓扑如图17-56所示。 One Node (8×H800) GPU 0 GPU 1 GPU 2 GPU 3 GPU 4 GPU 5 GPU 6 GPU 7 Rail 0 (256 nodes × 1 GPU) Rail 7 (256 nodes × 1 GPU) GPU 0 of each node ▶ IB S GPU 7 of each node ▶ IB S witch 0 50 GB/s per port witch 7 50 GB/s per port Aggregate 12.8 TB/s Bisection Bandwidth 8 Rails × 12.8 TB/s = 102.4 TB/s 图17-56 16384-GPU 集群的 8-Rail 优化 IB 拓扑 每 rail 含 256 个端口，单向 50 GB/s，单 rail 聚合带宽 12.8 TB/s。8 rails 总计 102.4 TB/s 对分带宽。 7) 存储规划 检查点大小： Mckpt ≈ 10Ptotal = 10 × 1.8 × 1012 = 18 TB 16384 GPU 每卡写约 18 TB/16384 ≈ 1.1 GB。使用 Lustre 并行文件系统（聚合写带宽约 1 TB/s），全局保存时间： tsave ≈ ≈ 18 seconds 1.0 异步检查点（在下一训练步中后台写入），不会阻塞训练。 8) 成本估算 16384 GPU × 43 天 × 24 h = 16.9M GPU-hours。按 2/h预留价：Cost = 16.9 × 10 × 2.0 ≈ $33.8M按需价4/h 则为约 67.6M 。这是典型的大模型训练成本区间。附加成本包括：2048台服务器（约300K/台 → 614MTCO均摊）、IB 交换机（约50K/台 × 约256 台 = 12.8M ）、存储（Lustre约1M-3M）、电力和冷却（约 2 − 4M /月）。自有硬件3年TCO摊销后GP U 小时成本约1.0-1.3/h。 9) 关键数字总览 GPT-4 量级训练案例的关键数字汇总如表17-130所示。 表17-130 GPT-4 量级训练关键数字 维度 数值 模型总参数量 1.8T（MoE, 16 experts） 激活参数量 220B（Top-2） 训练 Token 数 15T 并行分解 EP×TP×PP×DP = 8×8×8×2 GPU 规模 16384×H800（2048 节点） 训练时长 约43 天 MFU 约32% 训练成本 约$34M（预留） 检查点大小 18 TB 网络对分带宽 102.4 TB/s 每步通信 约21 ms（EP All-to-All）+ DP/TP 覆盖 核心经验：超大模型训练不是简单的 GPU 叠加。核心约束从“显存够不够”转移到“通信能不能在合理时间内完成”。 EP All-to-All 必须在 NVLink 内（EP ≤ 8）、DP 通过梯度累积压缩通信频率、网络拓扑需 rail-optimized。H800 的 NVLink 带宽（400 GB/s）仅为 H100（900 GB/s）的 44%，在 MoE 训练中 All-to-All 通信开销约放大 2.3×，对 MFU 有 额外压制。

17.9.4 从零规划方案

前三个案例分别解了 LLaMA-7B、DS-V2 和 GPT-4 量级模型的完整训练路线。本节将这套方法抽象为一个可复用的 10 步 决策流程：给定模型规格、训练目标和预算，输出基础设施方案。

1. 输入信息 规划开始前需要明确以下输入，如表17-131所示。 表17-131 规划输入信息 输入 符号 说明 模型架构参数 $L, d_{model}, d_{ff}, V, n_{heads}$ 层数、维度、FFN 大小、词表、注意力头数 注意力类型 MHA / MQA / GQA 影响参数量和激活值 MoE 配置 $E, k$ 是否需要专家并行 目标训练 Token 数 $D$ Chinchilla 最优：$D \approx 20P$ 目标训练时长 $T_{target}$ 业务截止日期 最大预算 $B_{max}$ 财力约束 GPU 候选型号 — H800 / A100 / B200 等
2. 十步决策流程 Step 1 — 计算参数量 使用 Dense 与 MoE 的参数量公式计算总参数量 $P_{total}和激活参数量P_{active} 。Dense模型的快速估算（忽略词表和P ositionEmbedding ）：P ≈ 12Ld (1 + total model dff 3dmodel ) 若为M oE，则P_{total}乘以E ，P_{active}约等于Dense部分的参数 + T op − k专家的参数。 ∗ ∗Step2—计算总F LOP s ∗ ∗按总F LOP s公式：C = × D∗ ∗ Step3—选择GP U 并估计MF U ∗ ∗根据GP U 参数表和MF U 定义： − total 6×P Dense模型，单节点N V Link ：MF U ≈ 40 − 50 − Dense模型，多节点IB ：MF U ≈ 35 − 42 − active M oE 模型，多节点：MF U ≈ 30 − 35 − 非常大集群（ > 1000GP U ）：在上述基础上再减3 − 5个百分点 ∗ ∗Step4—显存下限GP U 数 ∗ ∗按全量训练账本16字节/参数，计算基础显存占用M_{total} \approx 16P_{total} （不含激活）。暂按ZeRO − 3估计可降至M_{per_GPU} \approx 16P_{total}/N。N = ⌈ ⌉M_{act} mem 16Ptotal MGP U −Mact −Moverhead 在全量重计算下约1 − 8GB（取决于序列长度），M_{overhead}约2 − 5GB。 ∗ ∗Step5—时间下限GP U 数 ∗ ∗按训练时间公式反推：N =⌈ time ⌉若T_{target}很紧，N_{time}可能远大于N_{mem} 6Pactive D Ttarget ×peak×MFU 。最终GP U 数量取最大值：N = max(N , N )∗ ∗ Step6—分解并行策略 ∗ ∗将N分解为EP \times TP \times PP \times DP： − ∗ ∗ TP ≤ 8 ∗ ∗（N V Link限制）：优先取4或8 − ∗ ∗ EP ≤ 8 ∗ ∗（N V Link限制）：若为M oE模型 − ∗ ∗ mem time PP ≥ 2 ∗ ∗：当模型层数大于单卡可容纳激活层数时 − ∗ ∗ DP ∗ ∗：剩余因子，DP 可跨节点，是大规模扩展的主要方式分解原则： ∗ ∗DP 优先，TP 节点内，PP 最后 ∗ ∗。 ∗ ∗Step7—验证显存 ∗ ∗用选定并行策略回算每卡总显存（含激活与开销）：M = +M +M 确认 per_GPU 16Ptotal M_{per_GPU} < M_{GPU}。若超限，调整TP /PP /EP 或引入ZeRO − 3。 ∗ ∗Step8—验证通信 ∗ TP ×PP ×EP act overhead ∗计算各并行策略的单步通信时间： − TP 通信（节点内N V Link ）：通常可覆盖 − EP 通信（必须在节点内）：All − to − All，若跨节点则否决方案 − DP 通信（可跨节点IB ）：配合梯度累积（GA）压缩 − PP 通信（P 2P ）：P 2P 量小，可忽略若通信时间超过计算时间的20 ∗ ∗Step9—验证存储IO ∗ ∗按检查点与数据加载公式： − 检查点大小M_{ckpt} \approx 10P_{total}字节 − 数据加载带宽需求 − 确认文件系统聚合带宽满足保存/恢复时间要求 ∗ ∗Step10—验证预算 ∗ ∗按训练成本公式：Cost = N × T × price_per_GPU_hour确认Cost ≤B_{max}。若超预算，有以下选项： − 减少训练T oken数D（牺牲模型质量） − target 延长训练时长（若业务允许） − 切换到更低价的GP U （A100而非H800） − 缩短GP U 生命周期TCO摊销 ∗ ∗3)工作示例 ∗ ∗ ∗ ∗输入 ∗ ∗： − 模型：P=70BDense（如LLaM A − 2 − 70B 量级） − 目标T oken：D = 3\times10^{12} （3T ） − 目标时长：T_{target} = 60天 − 最大预算：B_{max} = $2M （预留价） − GP U ：H800 − 80GB，BF 16 = 989.5TF LOPS ∗ ∗Step1 ∗ ∗：P_{total} = P_{active} = 70\times10^9（Dense模型） ∗ ∗Step2 ∗ ∗：C_{total} = 6 \times 70\times10^9 \times 3\times10^{12} = 1.26\times10^{24}F LOP s ∗ ∗Step3 ∗ ∗：H800多节点，取MF U = 40 ∗ ∗Step4—显存下限 ∗ ∗：M_{total} = 16 \times 70\times10^9 = 1.12TB。M_{act} \approx 3GB （全量重计算）， M_{overhead} \approx 2GB。每卡可用约75GB。N = ⌈1120/75⌉ ≈ 15∗ ∗ Step5—时间下限 ∗ ∗：N = mem time ⌈ ⌉=⌈ ⌉ ≈ 615N_{time} \gg N_{mem}。时间约束主导。取N=640GP U （80个8 × 24 24 1.26×10 1.26×10 60×86400×989.5×1012 ×0.40 2.05×1021 H800节点）。 ∗ ∗Step6—并行分解 ∗ ∗：TP = 8（填满N V Link ），PP = 2（减少层数堆积），DP = 40。验证：8 \times 2 \times 40 = 640。 ∗ ∗Step7—验证显存 ∗ ∗：M = +3+2= per_GPU+ 5 ≈ 70 + 5 = 75 GB75 < 80 16×70×109 1120 GB ，通过。 ∗ ∗Step8—验证通信 ∗ ∗：TP 在节点内（N V Link900GB/s），可覆盖。DP = 8×2 16 40跨40个DP 副本（80节点/2PP = 40DP 组），梯度All − Reduce跨40节点。使用GA = 16将通信频率降至原来的1/16。每DP 步通信量：V = 2 × × 2P ≈ 2 × 0.975 × 2 × 39 ≈ 6.8 GB per_DP_GPU 70×109 IB50GB/s单卡，通信时间约136ms。GA = 16分摊后约8.5ms/step。可接受。 ∗ ∗Step9—验证存储 ∗ ∗：M_{ckpt} comm \approx 10 \times 70\times10^9 = 700GB。640GP U 并行写，每卡约1.1GB。Lustre聚合100GB/s，保存约7秒。 ∗ ∗Step10—验证预算 ∗ ∗：Cost = 640 × 60 × 24 × 2.0 = $1, 843, 2001.84M < $2M$，通过。 最终方案： 最终基础设施方案如表17-132所示。 表17-132 最终基础设施方案 维度 数值 GPU 型号 H800-80GB GPU 数量 640（80 节点） 并行策略 TP=8, PP=2, DP=40, GA=16 训练时长 60 天 预期 MFU 约40% 训练成本 约$1.84M 维度 数值 检查点大小 700 GB
3. 十步决策流程图 从零规划的十步决策流程如图17-57所示。 Input: Model Specs L,d,V,D, T_target,B_max Step 1: Calc P_total, P_acti ve Step 2: C_total = 6P_activ eD

Step 3: Choose GPU + Esti mate MFU Step 4: N_mem = ceil(16P Step 5: N_time = ceil(C / (T / M_avail) PeakMFU)) N = max(N_mem,N_time) Step 6: Factor N = EPxTPxP PxDP Step 7: Verify M_per_GPU < M_limit Fit in Memory? No Yes Increase TP/PP/EP or add Step 8: Verify comm < 20% ZeRO-3 of compute Comm bottleneck? Yes No Increase GA / add NVLink / Step 9: Verify storage IO ad re-factor equate Step 10: Verify Cost <= B_ max Budget OK? No Yes Reduce D / longer T / chea Final Infrastructure Plan per GPU 图17-57 从零规划十步决策流程 5) 使用建议 •快速估算（< 10 分钟）：只走 Step 1 → 2 → 4 → 5 → 10。得到的 N 和成本足以用于早期立项判断。 •详细规划（半天）：走完全部 10 步，每步写入文档形成正式的 Infra 方案。 •优化迭代：若 Step 8（通信）或 Step 10（预算）不通过，调整参数后从 Step 6 重新执行。

17.9.5 常见经验法则

以下是 AI Infra 领域经过大规模训练实践验证的经验法则。每条法则一行总结，两到三句话解释原理

1. 并行策略 法则 1：DP 优先，PP 最后。 DP 的计算/通信比最高（每 GA 步才通信一次，GA 越大越“便宜”）。TP 通信频繁但限制在 NVLink 内，性价比居中。PP 引入 pipeline bubble 且 P2P 延迟固定，仅当模型层数超过单卡激活容量时使用。 法则 2：TP 留在 NVLink 内。 TP 的 All-Reduce 和 All-Gather 在每层 Transformer 中触发 2-4 次，通信频率极高。若跨节点通过 IB 执行，延迟会放大 10-30 倍，步长直接被拉长。TP 组大小 ≤ 8（一个 NVLink 节点）。 法则 3：梯度累积让 DP 通信接近免费。 梯度累积步数 GA 每翻一倍，DP All-Reduce 的触发频率就减半，等效带宽需求除以 GA。只要 t /GA < t ，通 信就可被完全覆盖。 comm compute 法则 4：EP 不跨节点。 MoE 的 All-to-All 通信比 All-Reduce 更密集（每层两个完整 All-to-All），跨节点 IB 延时下会成为致命瓶颈。EP 组也必须 限制在 NVLink 域内（EP ≤ 8）。
2. 显存 法则 5：Adam 占用 8P 字节。 对于每个参数，Adam 存储 m（FP32）和 v（FP32），共 8 字节。优化器状态是训练时最大的单一项，约占 16P 基础显 存的 50%。ZeRO-1 就是专门为了分片这 8P。 法则 6：激活重计算几乎总是划算的。 全量重计算让激活显存降至原来的 1/10 到 1/50（取决于层数和序列长度），计算量增加仅 33%（反向需重算一次前向）。 在现代 GPU 上，这 33% 的额外计算比容纳更多 Token 带来的吞吐提升更值。 法则 7：16P 字节是训练自重的底线。 BF16 权重（2P）+ FP32 主副本（4P）+ Adam（8P）+ BF16 梯度（2P）= 16P 字节。这是未分片时单卡训练的最低显 存，也是所有显存估算的起点。加上激活值后，模型 P 超过 5B 几乎必然需要并行。 法则 8：检查点 ≈ 10P 字节。 检查点需同时保存 BF16 权重（2P）用于恢复训练，以及 FP32 优化器（8P）用于继续优化。10P 是保守估计，有的框架 还保存学习率调度器状态和 RNG seed。
3. 效率 法则 9：GPU 数量每翻 10 倍，MFU 掉 2-5 个百分点。 通信开销随节点数增加呈超线性增长（更多跳、更多交换机、更多拥塞）。从 8 卡到 80 卡，MFU 从 约48% 降到 约 43%；从 80 卡到 800 卡，降到 约38%；从 800 卡到 8000 卡，降到 约33%。这是“通信税”在规模化中的体现。 法则 10：MoE 训练 MFU 比同规模 Dense 低 5-15 个百分点。 All-to-All 通信的不可覆盖部分、专家负载不均衡、Token 路由的开销共同压低了 MoE 的有效算力利用率。即便是最优 gating 策略，也很难把 MFU 提升到 Dense 的水平。它体现了MoE训练的根本挑战。
4. 推理 法则 11：Decode 永远是带宽墙（Memory-Bandwidth-Bound）。 Decode 阶段每次生成一个 Token，每 Token 的算术强度约 1 FLOP/byte，而 H800 的 Roofline 转折点约 295 FLOP/byte （H20 约 37 FLOP/byte）。Decode 在 Roofline 曲线上处于极左位置，再高的算力也用不上，全部时间在等内存。 法则 12：KV Cache 在长序列下爆炸。 KV Cache 大小 = 2 × L × S × n × d × precision，其中 n × d 为 GQA 折算后的每层 KV 维度（LLaMA-3-70B 为 8 × 128 = 1024，而非 d = 8192）。对于 70B 模型、S = 128K ：2 × 80 × 131072 × 1024 × 2 bytes ≈ 42.9 GB；若无 GQA kv h kv h 折算（KV 维度按 8192 计），同一请求将膨胀至约 343 GB，超过模型权重本身。PagedAttention 和 GQA 是应对这一爆炸 model 的核心手段。 法则 13：量化到 INT4 求吞吐，FP8 求精度。 INT4 将带宽和显存需求降至原来的 1/4，在内存受限的 Decode 推理中吞吐提升约 2-3×，但通常有 1-2% 的质量损失。 FP8 几乎无损，带宽需求减半，适用于 Prefill 和对质量敏感的场景。
5. 运维 法则 14：一块 GPU 挂掉就毁掉整趟训练，要做好心理准备。 千卡以上集群的 GPU 日均故障率约 1-2%。若 MTBF（Mean Time Between Failures）为 500 GPU-hours，在 1000 GPU 集群上约每 30 分钟就有一块卡故障。必须频繁保存检查点，间隔 ≤ N × MTBF。 法则 15：CPU Tokenization 可能成为隐藏瓶颈。 在 GPU 训练的同时，CPU 需要实时 tokenize 下一批数据并加载到 GPU。若 tokenizer 吞吐低于 GPU 消费速率，训练被 “饿着”。预处理数据集（pre-tokenized dataset）可彻底消除这个瓶颈，代价是额外的存储空间。 法则 16：网络在规模下不是免费的。 在 64 GPU 以下的集群中，NVLink 通常能让通信“免费”。但跨过 64 卡门槛后，IB 通信开始占据显著时间比例（10- 30%）。Rail-optimized 拓扑可减少拥塞，但无法消除物理距离带来的延迟。
6. 快速估算公式 下表给出一个 Dense 模型从架构参数到训练时间和成本的一站式估算，如表17-133所示。填入 P （参数量）、D（训练 Token 数）、N （GPU 数量）和 MFU，即可得到核心数字。 表17-133 快速估算公式汇总 指标 公式 记忆口诀 参数量（Dense） P ≈ 12Ld2 (1 + d ff /3d) 十二乘层乘维方，再乘 FFN 因子 总 FLOPs C = 6P D 六倍的 P 乘 D 基础显存 Mbase = 16P 字节 十六 P，单位是字节 检查点大小 Mckpt = 10P 字节 十 P，单位是字节 单卡分片后显存 ≈ 16P /(EP × TP × PP ) 十六 P 除以分片因子 训练天数 Tdays ≈ 6P D/(N × Peak × MFU × 86400) 六倍 P 乘 D，除以每天的总有效 FLOPs 训练成本 Cost = N × Thours × price GPU 数量乘时间乘单价 使用示例：训练一个 70B Dense 模型，3T Token，640×H800，MFU=40%：

 P = 70e9; D = 3e12; N = 640; peak = 989.5e12; MFU = 0.40
 # FLOPs
 C = 6 * P * D   # 1.26e24
 # Memory
 M_base = 16 * P / 1e9   # 1120 GB
 M_ckpt = 10 * P / 1e9   # 700 GB
 # Training days
 T_days = C / (N * peak * MFU * 86400)      # ≈ 59.7 days
 # Cost
 cost = N * T_days * 24 * 2.0     # ≈ $1.84M

这组公式覆盖了日常 Infra 估算 80% 的场景。

17.9.6 H800 vs H20 场景选型

本节汇总全书各章的分析结论，从训练和推理两个维度对比 H800 和 H20 的适用场景。

1. 核心硬件对比 H800 与 H20 的核心硬件参数对比如表17-134所示。 表17-134 H800 与 H20 硬件参数对比 维度 H800 SXM 80GB H20 96GB BF16 TFLOPS 989.5 148 FP8 TFLOPS 1979 296 HBM 容量 80 GB 96 GB HBM 带宽 3.35 TB/s 4.0 TB/s NVLink 带宽（uni） 400 GB/s (8 links) 900 GB/s (18 links) Roofline 拐点（BF16） 295 FLOP/byte 37 FLOP/byte TDP 700 W 500 W
2. 训练场景 H800 优势： 各训练场景下 H800 与 H20 的对比如表17-135所示。 表17-135 训练场景对比 场景 H800 H20 结论 大模型 Prefill 1×（基准） 6.7× 慢 H800 显著占优 Dense 模型训练 MFU 40-45% 不适合（算力不足） H20 不适合大模型训练 MoE 训练（EP ≤ 8） All-to-All 42 ms/step NVLink 更快（42→19 ms）但算力不足 H800 综合占优 H20 不需要训练，这不是它的定位。H800 在训练场景中计算吞吐碾压，NVLink 带宽虽为 H100 的 44%，但对 Dense 模 型训练影响可控（主要瓶颈在 IB 跨节点而非 NVLink 节点内）。 关键结论（训练）：H800 是大模型训练的唯一选择。H20 的 148 TFLOPS 算力在训练场景中不具备竞争力（约需 6.7× 的 GPU 数量才能达到同等 Prefill 吞吐）。
3. 推理场景 这是 H20 的核心战场。 H20 在推理场景的核心数据对比如表17-136所示。 表17-136 推理场景 H800 与 H20 对比 维度 H800 H20 H20 优势 Decode 延时（70B BF16 单卡） 41.8 ms 35.0 ms +19%（更快） Decode 吞吐（70B TP4, B=32） 3040 tok/s 3630 tok/s +19% KV Cache 可用容量（TP=4 单卡） 43 GB 59 GB +37%（更多并发） Prefill 延时（70B, 4K） 830 ms 5.53 s 6.7× 慢（劣势） INT4 单卡并发（70B, S=4K） 256 352 +37% 单卡价格（spot） 约$1.00/h 约$0.50/h 50% 更低 推理成本（$/1M tokens, BF16 TP4, on-demand） 约$0.91 约$0.30 3.0× 更便宜 推理成本（$/1M tokens, BF16 TP4, spot） 约$0.37 约$0.15 2.4× 更便宜 H20 推理优势总结：H20 在 Decode 为主导的在线推理场景中提供三重叠加优势：

1. 更高带宽：4.0 vs 3.35 TB/s → Decode 快 19%
2. 更大容量：96 vs 80 GB → 同等 TP 下 KV Cache 容量多 37%
3. 更低价格：spot 价格约 H800 的 50% 三个优势叠加后，H20 在推理每美元吞吐量（tokens/$）上约为 H800 的 2.4-3.0 倍（spot 口径 2.4×，on-demand 口 径 3.0×）。

4. 选型决策矩阵 按业务特征选型的决策矩阵如表17-137所示。 表17-137 选型决策矩阵 业务特征 推荐 GPU 原因 大模型预训练（>7B） H800 计算密度是关键 在线推理（短 prompt，长输出） H20 Decode 主导 = HBM BW 主导 在线推理（长 prompt，短输出） H800 Prefill 主导 = 算力主导 离线批处理推理 H20 成本敏感 + 吞吐导向 高并发在线服务（S=4K，100+ 并发） H20 大 HBM 容量 = 更多 KV Cache MoE 模型的推理 H20 MoE 模型参数虽大但激活参数小，H20 的高带宽匹配 Decode 需 求 混合负载（长短 prompt 交织） H800 + H20 混合部 长 prompt 路由到 H800，短 prompt 路由到 H20 署
5. 量化 + H20 的叠加放大 H20 与 INT4/FP8 量化形成叠加效应，各组合方案的对比见表17-138。 表17-138 量化与 H20 叠加组合对比 组合 单卡权重(GB) KV Cache 可用(GB)/卡 S=4K 并发 成本/1M tokens H800 BF16 TP=4 35 43 64 约$0.37 H20 BF16 TP=4 35 59 88 约$0.15 H20 INT4 TP=1 35 59 352 约$0.01 H20 FP8 TP=4 17.5 76.5 114 约$0.08 并发按单台 8 卡服务器、S = 4K、BF16 KV（约 1.34 GB/请求）、每卡预留 2 GB 计算；INT4 TP=1 为 8 个独立单卡实例 （每卡 59/1.34 ≈ 44 并发）。成本为 spot 口径满载估算。 终极方案：H20 INT4 TP=1 部署 70B 模型，单台 8 卡 H20 服务器即可承载 352 个并发请求，满载 spot 口径成本 低至约 $0.01/M tokens，即便实际利用率只有一成也不足 $0.10/M tokens，低于小模型（8B）的 API 定价。这是 一条从「买算力」到「买内存带宽」的范式转变。