第27讲：显存去哪儿了？——大模型训练与推理显存全景账本、FLOPs 白板手算与 KV Cache 容量规划

主讲人：👓 Ringi（大厂 AI Infrastructure 资深性能架构师）
所属专栏：《AI_Infra大话西游之水滴石穿》 ➔ Module 03: LLM 架构、FLOPs 与显存建模
篇章范式：📐 模型架构、算法与显存建模范式（Model Architecture & Memory Ledger Paradigm）
源码与实验环境：NVIDIA A100-SXM4-80GB / H100-SXM5-80GB | CUDA 12.4 | Python 3.10 | PyTorch 2.3+
知识底账索引：

显存与 KV 核心底账：大模型训练内存与参数计算（AIInfra）

推理内存与 KV Cache：大模型推理内存与参数计算（AIInfra）

MFU 与算力利用率：CODE 03: MFU 模型利用率评估（AIInfra）

ZeRO 显存切分实现：ZeRO 显存优化深入拆解（AIInfra）

=================================================================================================
                                   Ringi 3D 架构工坊 · 核心全景
                                 大模型显存四大账本与生命周期全景
=================================================================================================
   ┌────────────────────────────────────────────────────────────────────────────────────────┐
   │                                GPU 物理显存 (80 GB / 卡)                                │
   └───────────────────────────────────────────┬────────────────────────────────────────────┘
                                               │
               ┌───────────────────────────────┴───────────────────────────────┐
               ▼                                                               ▼
   ┌───────────────────────┐                                       ┌───────────────────────┐
   │    【静态显存账本】    │                                       │    【动态显存账本】    │
   │  进程常驻 · 与序列无关 │                                       │  生命周期瞬态 · 随并发与│
   │                       │                                       │  序列长度动态激增      │
   └───────────┬───────────┘                                       └───────────┬───────────┘
               │                                                               │
       ┌───────┴───────┐                                               ┌───────┴───────┐
       ▼               ▼                                               ▼               ▼
 ┌───────────┐   ┌───────────┐                                   ┌───────────┐   ┌───────────┐
 │ 训练态    │   │ 推理态    │                                   │ 训练激活值│   │ 推理动态  │
 │ (16Ψ~20Ψ) │   │ (2Ψ / 1Ψ) │                                   │ (Activation)│ │ (KV Cache)│
 ├───────────┤   ├───────────┤                                   ├───────────┤   ├───────────┤
 │•权重: 2Ψ  │   │•BF16: 2Ψ  │                                   │•无重算:   │   │•传统连续: │
 │•梯度: 2Ψ  │   │•FP8:  1Ψ  │                                   │ O(L·S)暴涨│   │ 碎片率>60%│
 │•AdamW:12Ψ │   │•INT4: 0.5Ψ│                                   │•全重算:   │   │•PagedAttn:│
 │ (Master+  │   │           │                                   │ 33%算力换 │   │ 分页虚拟化│
 │  m + v)   │   │           │                                   │•选择重算: │   │ 零外部碎片│
 └─────┬─────┘   └─────┬─────┘                                   │ 0%损耗省70│   │ 显存率>96%│
       │               │                                         └─────┬─────┘   └─────┬─────┘
       ▼               ▼                                               ▼               ▼
 ┌───────────┐   ┌───────────┐                                   ┌───────────┐   ┌───────────┐
 │ ZeRO-1/2/3│   │ TP 并行   │                                   │ MFU / HFU │   │ 最大并发  │
 │ 切分打散  │   │ 权重平摊  │                                   │ 算力开销  │   │ 容量水位  │
 └───────────┘   └───────────┘                                   └───────────┘   └───────────┘
=================================================================================================

📑 目录导航

0. Ringi 开场：生产真实现场与痛点冲突
1. 静态显存白板手算：权重、梯度与 AdamW 优化器（ $16\Psi \sim 20\Psi$ 底账）
2. 动态激活显存深度拆解：激活值的三档重算（Recomputation）博弈
3. 推理显存账本与 KV Cache 容量规划
4. 计算量（FLOPs）、MFU 与 HFU 工业级算盘
5. 全场景实战：编写工业级容量规划与显存诊断脚本
- 5.1 实验一：原生 PyTorch 动态激活显存峰值与重算打点测试
- 5.2 实验二：工业级全栈容量规划器 cluster_capacity_planner.py
6. Ringi 避坑指南与生产黄金准则
- 6.1 7 大常见小白认知误区 vs 大厂 AI Infra 正确物理认知
- 6.2 生产容量工程黄金 Checklist
7. Ringi 5 点核心速记口诀、自我检验清单与课后深度思考题
8. 📚 参考资料与核心源码/经典论文指引
附录：Appendix A — 大厂硬核高频面试题与白板推导（Interview Drill）
🎨 【配图工坊生图 Prompt 暂存区 · 生成配图后可一键整块删除】

0. Ringi 开场：生产真实现场与痛点冲突

0.1 真实工程矛盾：千卡训练的“幽灵 OOM” vs 线上推理的“虚胖碎片”

在 AI Infrastructure 性能工程的日常中，有两场灾难最让架构师夜不能寐：第一场灾难发生在训练侧：
千卡分布式预训练集群平稳运行了整整两周，一切监控指标看似风平浪静。突然在第 15,200 个 Step，某台计算节点毫无征兆地爆出 CUDA out of memory。分布式框架的容错机制触发，整组任务被强行拉起，但从 Checkpoint 恢复加载后仅仅跑了 3 个 Step，相同的节点又在同一个位置暴毙！
算法同学信誓旦旦：“Ringi，我们的 Batch Size 根本没改，静态权重和优化器也是固定的，为什么训练突然就 OOM 了？这是不是显卡硬件显存坏块？”
答案往往是：数据采样遇到了极端长序列，前向传播激增的激活值（Activation）与反向传播的临时梯度 Buffer 瞬间交汇，在毫秒级瞬间刺穿了最后的显存红线！ 第二场灾难发生在推理侧：
线上部署了 8 张 A100-80GB 推理卡，算法根据模型参数和理论 KV Cache 估算：每个请求占 1 GB，整机剩余显存 500 GB，理论上承载 500 并发绰绰有余。然而压测刚拉到 80 并发，显卡内存利用率就已经飙红到 98%，后续请求全部被拒。
运维同学惊呼：“为什么才 80 并发显存就满了？剩下的 400 GB 显存到底被谁吃掉了？！”
答案极其讽刺：显存根本没被真正用上，而是被框架朴素的连续显存预分配机制切割成了无数无法回收的“内部碎片与外部碎片”，系统虚胖致死！

0.2 线上真实事故复盘：某 1024 卡集群扩充 16K 上下文引发的全链路瘫痪

2024 年盛夏，国内某顶尖 AI 实验室在 1024 张 H800 GPU（128 个 8 卡节点）上进行 70B 稠密模型的第二阶段预训练（从 4K 上下文正式热扩充至 16K）。为了保证吞吐，团队使用了 Tensor Parallel (TP=8) + Data Parallel (DP=128)，并开启了 ZeRO-1（切分优化器状态）。在 4K 阶段，单卡显存稳固在 68 GB / 80 GB，系统安全裕量良好。但在修改配置将 max_position_embeddings 调整为 16384 并继续训练的第 1 个 Step：

前向传播执行到第 40 层 Transformer Block；
由于未开启选择性重算（Selective Activation Recomputation），Attention 算子内部的中间概率矩阵激活值开销随着序列长度呈 $S^2$ 二次形式暴涨；
单卡动态激活值从 4K 时的 8.5 GB 瞬间膨胀到惊人的 34.8 GB；
静态显存（权重 17.5 GB + 梯度 17.5 GB + ZeRO-1 优化器 12 GB = 47 GB）叠加激增的 34.8 GB 激活值，瞬间达到 81.8 GB > 80 GB；
全集群 1024 张 GPU 在 2 秒内相继触发级联 OOM 崩溃，网络心跳超时，分布式通信拓扑彻底死锁。

[Crash Log: Node-042:GPU-3]
torch.cuda.OutOfMemoryError: CUDA out of memory. 
Tried to allocate 2.14 GiB (GPU 3; 79.25 GiB total capacity; 77.82 GiB already allocated; 
850.00 MiB free; 78.40 GiB reserved in total by PyTorch)

这次故障导致千卡集群停机排查长达 6 小时，直接硬件机时损失超过 30 万元。最终的解法不是减小 Batch Size，而是由 Infra 团队介入：

将优化器与梯度切分升级为 ZeRO-2（单卡静态显存从 47 GB 压降至 21 GB）；
开启基于 FlashAttention 的选择性激活重算（动态激活值压缩 72%）；
最终在 16K 序列下，单卡显存不仅没有爆，反而降到了舒适的 48 GB，为后续进一步扩充到 32K 留足了护城河。

0.3 显存四大账本（容量 vs 流量）与全景指标速查表

显存账本类别	包含实体	生命周期	决定性公式 / 典型开销	核心受限维度	优化与破局武器
训练静态账本	权重、梯度、AdamW 优化器状态	训练全生命周期常驻	$16\Psi \sim 20\Psi$ 字节（ $\Psi$ 为参数量）	Capacity-Bound（单卡绝对容量）	ZeRO-1/2/3 切分、张量并行（TP）、流水线并行（PP）
训练动态账本	前向激活值（Activation）、临时规约缓冲区	随前向反向步数瞬态分配与释放	$34bsh + 5bs^2$ 字节/层（无重算）	Capacity + Bandwidth 双重敏感	激活值全重算、选择性重算、FlashAttention 反向融合
推理静态账本	模型推理权重（BF16/FP8/INT4）	推理服务进程常驻	$2\Psi$ 字节 (BF16) / $1\Psi$ 字节 (FP8)	Capacity-Bound	权重量化（AWQ/GPTQ）、张量并行切分
推理动态账本	KV Cache（Key/Value 缓存）、输出 Logits	随请求生成长度线性激增	$4 \cdot B \cdot S \cdot L \cdot d \cdot \frac{H_{kv}}{H_q}$ 字节	Bandwidth-Bound（Decode 阶段极度访存受限）	GQA 架构、PagedAttention 分页调度、FP8 KV Cache、投机采样

1. 静态显存白板手算：权重、梯度与 AdamW 优化器（ $16\Psi \sim 20\Psi$ 底账）

为了在深入具体细节前建立完整的物理心智模型，下方给出了大模型显存四大账本、ZeRO 状态切分模型、动态激活值三档重算博弈与 FLOPs 矩阵计数的工业级全景架构拓扑：

1.1 混合精度训练的四重身：从 BF16 到 FP32 Master Weight

很多人直觉上认为：“我用 BF16 混合精度训练模型，显存里应该全都是 16 位的 2 字节数字。”
大错特错！ 在标准混合精度训练中，显存的大头从来不是 BF16，而是为了保证更新稳定性所维护的 FP32 主参数副本（Master Weight）。

为什么不能纯用 BF16 完成更新？

在优化器步进（optimizer.step()）时，学习率

\eta

通常是一个微小的数字（如

1 \times 10^{-4}

到

5 \times 10^{-5}

）。
当计算参数增量

\Delta W = -\eta \cdot \frac{m_t}{\sqrt{v_t} + \epsilon}

时，

\Delta W

的数值通常处于

10^{-6} \sim 10^{-8}

数量级。
而 BF16 只有 7 位尾数（有效数字仅 2~3 位十进制精度）。如果直接在 BF16 权重上累加：

W_{t+1} = W_t + \Delta W

由于两者的阶数相差过大，微小的

\Delta W

会在浮点对齐时被硬件直接截断（Underflow 消失）！这意味着模型在训练后期，权重根本得不到任何微小更新，训练彻底停滞。因此，工业级标准实践必须维护一套完整的 FP32 状态体系：

[前向传播 Forward]
FP32 Master Weight ─── 动态转换为 ───► BF16 Weight (2 Bytes) ───► 与输入计算出激活值

[反向传播 Backward]
BF16 Weight ─── 求导产出 ───► BF16 Gradient (2 Bytes) (或累加为 FP32)

[优化器更新 Optimizer Step]
BF16 Gradient ─── 传给 ───► AdamW 优化器:
                              • FP32 Gradient (4 Bytes)
                              • FP32 一阶动量 m_t (4 Bytes)
                              • FP32 二阶动量 v_t (4 Bytes)
                              • 更新 FP32 Master Weight (4 Bytes)

1.2 为什么是 $16\Psi$ ？什么时候会膨胀到 $18\Psi$ 或 $20\Psi$ ？

我们用严密的算盘，对一个参数量为

\Psi

的稠密模型进行静态显存手算：

标准 $16\Psi$ 显存底账（主流 Megatron-LM / DeepSpeed 默认）：

模型权重（Model Weights）：BF16 存储，占用 $2\Psi$ 字节；
模型梯度（Gradients）：BF16 存储，占用 $2\Psi$ 字节；
AdamW 优化器状态（Optimizer States）：
- FP32 Master Weight： $4\Psi$ 字节；
- FP32 梯度一阶动量（First Moment $m$ ）： $4\Psi$ 字节；
- FP32 梯度二阶动量（Second Moment $v$ ）： $4\Psi$ 字节；
- 优化器状态小计： $4 + 4 + 4 = \mathbf{12\Psi}$ 字节。

M_{\text{static-16}} = 2\Psi (\text{权重}) + 2\Psi (\text{梯度}) + 12\Psi (\text{优化器}) = \mathbf{16\Psi} \quad (\text{Bytes})

何时会膨胀到 $18\Psi$ ？

在部分对数值稳定性要求极高的框架中（如早期的 Apex 混合精度），为了防止梯度在跨 Micro-Batch 累加时溢出，梯度本身以 FP32 格式常驻：

M_{\text{static-18}} = 2\Psi (\text{BF16 权重}) + 4\Psi (\text{FP32 梯度}) + 12\Psi (\text{优化器}) = \mathbf{18\Psi} \quad (\text{Bytes})

何时会膨胀到 $20\Psi$ ？

如果在分布式数据并行（DDP）同步规约中，额外开辟了一个全尺寸的 FP32 通信平坦缓冲区（Bucket Flat Buffer），则会再增加

2\Psi

的常驻开销，达到惊人的 $20\Psi$ 。

工业基准：在白板面试与工程估算中，一律以 $16\Psi$ 为严谨基准！

1.3 ZeRO-1 / ZeRO-2 / ZeRO-3 状态切分模型与单卡显存推导

对于一个 70B 模型（

\Psi = 70 \times 10^9

），

16\Psi

意味着静态显存需要：

70 \times 10^9 \times 16\text{ Bytes} \approx \mathbf{1120\text{ GB}}

单张 80GB 卡显然不可能装下。微软提出的 ZeRO（Zero Redundancy Optimizer） 算法，通过数据并行维度的切分彻底粉碎了这一死局：

ZeRO 级别	核心切分策略	单卡显存公式（数据并行度为 $N_{\text{DP}}$ ）	70B 模型在 $N=8$ 卡时的单卡显存	通信开销变化
Baseline (DDP)	无切分，每卡保存完整冗余副本	$2\Psi + 2\Psi + 12\Psi = 16\Psi$	$1120\text{ GB}$ (直接 OOM)	基线：反向传播 1 次 AllReduce（通信量 $2\Psi$ ）
ZeRO-1 ( $P_{\text{os}}$ )	仅切分优化器状态，权重与梯度全量保存	$2\Psi + 2\Psi + \frac{12\Psi}{N_{\text{DP}}}$	$140 + 140 + 105 = \mathbf{385\text{ GB}}$	通信量无增加（仅在更新后广播分片，总量 $2\Psi$ ）
ZeRO-2 ( $P_{\text{os+g}}$ )	切分优化器状态 + 梯度，仅权重全量保存	$2\Psi + \frac{2\Psi + 12\Psi}{N_{\text{DP}}} = 2\Psi + \frac{14\Psi}{N_{\text{DP}}}$	$140 + 122.5 = \mathbf{262.5\text{ GB}}$	通信量无增加（反向时用 Reduce-Scatter 替代 AllReduce）
ZeRO-3 ( $P_{\text{os+g+p}}$ )	切分优化器 + 梯度 + 模型参数（全切分）	$\frac{16\Psi}{N_{\text{DP}}}$	$1120 / 8 = \mathbf{140\text{ GB}}$ （ $N=64$ 时仅需 $17.5\text{ GB}$ ）	通信量增加 50%（前向每层前需 AllGather 收集权重，前向完即丢弃；反向需再次 AllGather）

1.4 ZeRO-Offload 的物理瓶颈：PCIe 带宽与 Host 内存延迟惩罚

当显卡显存极度紧张时，很多工程师会寄希望于开启 ZeRO-Offload，将优化器状态甚至部分权重卸载到主机内存（Host CPU DRAM）甚至 NVMe SSD 上。 掏出工程算盘手算：这笔账到底划不划算？ 假设你在单台 8 卡服务器上训练 70B 模型，通过 PCIe 4.0 x16 互联：

PCIe 4.0 x16 双向理论带宽：约 32 GB/s（实际单向有效吞吐仅约 24 GB/s）；
需要卸载的数据量：70B 模型的优化器状态占 $70 \times 12 = 840\text{ GB}$ ；
每次参数更新，GPU 必须把梯度通过 PCIe 搬运给 CPU，CPU 计算完 AdamW 后，再把更新后的参数通过 PCIe 搬运回 GPU；
单次跨 PCIe 搬运耗时：

\text{Latency} = \frac{840\text{ GB}}{24\text{ GB/s}} \approx \mathbf{35 \text{ s}}（约 35 秒）!

而 8 卡 H800 执行一步前向和反向计算只需要 1.2 秒！
这意味着：开启 ZeRO-Offload 之后，训练 Step Time 从 1.2 秒被硬生生拉长到 36.2 秒，整机算力利用率（MFU）暴跌至不足 3%！
生产结论：ZeRO-Offload 仅适合低成本个人微调或死里求生的救急场景，在大规模工业预训练中严禁作为主流方案。

2. 动态激活显存深度拆解：激活值的三档重算（Recomputation）博弈

2.1 逐层激活值公式白板推导：Attention 与 FFN 的激活开销

在前向传播中，除了静态权重，每一层计算出的中间变量（Activations）都必须缓存在显存中，直到反向传播求导用完后才能被销毁。我们以单层标准 Transformer Block 为例，输入批大小

B

，序列长度

S

，主干维度

d

，Query 头数

H_q

（为简化推导先按标准 MHA

H_q = H_{kv}

分析，单头维度

d_h = d / H_q

）：

1. Attention 模块激活值明细：

$Q, K, V$ 投影输入：共享输入 $X$ ，无需存三份，保存输入 $X \in \mathbb{R}^{B \times S \times d}$ （BF16）： $2BSd$ 字节；
$Q, K$ 投影产物：用于求导，需存 $Q, K \in \mathbb{R}^{B \times S \times d}$ ： $2 \times 2BSd = 4BSd$ 字节；
注意力得分矩阵 $S = QK^T$ ：尺寸为 $[B, H_q, S, S]$ ，元素数为 $B H_q S^2$ ： $2B H_q S^2$ 字节；
Softmax 归一化概率矩阵 $P$ ：尺寸同为 $[B, H_q, S, S]$ ： $2B H_q S^2$ 字节；
Dropout 掩码（若开启）：按 Byte 存储（1 字节/元素）： $1B H_q S^2$ 字节；
Value 投影产物与 Attention 输出： $2BSd$ 字节；
输出投射 $W_o$ 与残差连接： $2BSd$ 字节。

2. FFN 模块激活值明细（以标准 FFN $4d$ 为例）：

输入 LayerNorm 状态： $2BSd$ 字节；
第一层升维线性投射产物： $[B, S, 4d]$ ，占用 $2 \times 4BSd = 8BSd$ 字节；
激活函数（GELU/ReLU）中间保留值： $8BSd$ 字节；
第二层降维线性投射输入与残差： $4BSd$ 字节；
FFN 激活值小计： $\approx 22BSd \sim 24BSd$ 字节。

单层激活值总量大一统公式（无重算）：

M_{\text{act-layer}} = 34BSd + 5B H_q S^2 \quad (\text{Bytes})

全模型

L

层的总激活显存为：

M_{\text{act-total}} = L \times (34BSd + 5B H_q S^2) \quad (\text{Bytes})

致命痛点：注意公式右侧的 $5B H_q S^2$ ！
当序列长度从

S=2048

放大到

S=32768

（放大 16 倍）时，

S^2

项被放大了整整 256 倍！激活显存会瞬间突破数百 GB，这就是引发长文本 OOM 的头号元凶。

2.2 三档重算策略深度博弈：无重算 vs 全重算 vs 选择性重算

为了降服

S^2

的显存吞噬，系统工程师发明了激活值重算（Activation Checkpointing）。

重算策略	显存中保留的内容	反向传播时的额外操作	单层激活显存占用	额外计算量（FLOPs 开销）	生产场景建议
档位 1: 无重算 (No Recompute)	所有前向算子的中间产物完整保留在 HBM	零额外重算，直接读取激活值求导	$34BSd + 5BS^2 H_q$	0%（理论最快）	仅适用于短文本（ $S \le 2K$ ）且显存极度宽裕的场景
档位 2: 全重算 (Full Checkpoint)	仅保留每一层 Block 最外层的输入张量（Checkpoint）	反向传播到该层时，当场重新跑一遍前向传播	$2BSd$ （极小，与层数 $L$ 解耦）	+33.3%（前向算 2 次，总计算量从 $6P$ 飙升至 $8P$ ）	极致长文本（128K+）且显存即将见底时的保命底牌
档位 3: 选择性重算 (Selective Recompute)	保留大 GEMM 矩阵乘的输入输出，仅丢弃并重算 Attention 内部的 Softmax 与 Dropout	仅重新计算 $QK^T$ 和 Softmax，跳过所有沉重的 GEMM	$34BSd$ （彻底抹除 $S^2$ 二次项！）	< 3%（微乎其微）	大厂工业生产必选的黄金标准！

2.3 FlashAttention 反向融合如何抹平中间矩阵显存

在上一模块第 25 讲中，我们详细推导了 FlashAttention 的前向 Tiling。那么在显存账本中，FlashAttention 是如何拯救反向传播激活值的？ 传统 PyTorch 原生 Attention：必须将大小为

[B, H_q, S, S]

的中间注意力矩阵

S

和 Softmax 输出矩阵

P

完整落盘写出到 HBM，供反向传播求导读取。在 32K 序列下，仅这两个矩阵就要吞噬几十 GB 显存。 FlashAttention 反向融合机制：在前向传播时，根本不存 $S$ 和 $P$ ！它仅把 Softmax 的行归一化统计量（标量向量

L \in \mathbb{R}^{B \times H_q \times S}

，仅占微不足道的

2BS H_q

字节）保留在 HBM 中。
在反向传播时，Kernel 直接在 SM 内部的高速 SRAM 寄存器中，利用保留的

Q, K, V

以及标量

L

，当场重算局部的 $P_{ij}$ 块并立刻与梯度累加！ 收益结算：通过将反向求导融合进同一个 GPU Kernel，直接把

O(S^2)

激活值完全消除在 SRAM 中，使长文本下的 Attention 激活显存从“不可承受之重”降维打击为“几乎零感知”。

3. 推理显存账本与 KV Cache 容量规划

3.1 推理两阶段的物理分化：Prefill 阶段 vs Decode 阶段

在推理服务中，大模型的运行绝不是均匀同构的，而是分裂为特征完全相反的两个阶段：

[Prefill 预填充阶段]
用户输入长 Prompt: [Token_0, Token_1, ..., Token_1023] (共 1024 Tokens)
• 计算特征: GEMM 矩阵乘，计算强度极高 (Compute-Bound)，算力利用率高达 60%+
• 显存特征: 动态激活值占主导，从第 0 个到第 1023 个 Token 的 Key/Value 被一次性写入 HBM 生成 KV Cache

[Decode 自回归解码阶段]
每次只吐出 1 个新 Token: Token_1024 ──► Token_1025 ──► Token_1026 ...
• 计算特征: 退化为 GEMV 矩阵-向量乘，计算强度极低 (< 2 FLOP/Byte)，极度访存受限 (Memory-Bound)
• 显存特征: 静态激活值极小，但 KV Cache 随着每一步自回归线性膨胀，直至吞噬全卡显存！

3.2 No Naked Formula 2.0 穿透 KV Cache 容量公式

我们再次调用最严谨的 No Naked Formula 2.0（公式五步穿透法）：

① 为什么需要算它？

Decode 阶段生成每个 Token 时，由于模型必须与历史所有 Token 做注意力计算，如果不缓存历史 Key 和 Value，每生成一个新词都要把所有历史词重新过一遍模型，计算复杂度将从

O(S)

退化为

O(S^2)

，线上延迟彻底爆炸。

② Mental Model（物理直觉比喻）

KV Cache 就像是你在读一本长篇侦探小说时手边做的人物关系笔记本。每一章新登场一个角色，你都在本子上记下一笔（新增 Key 和 Value）。书越读越厚，笔记本占用的桌面空间（物理显存）越来越大，直到桌子被本子堆满，你再也放不下一页新纸。

③ Tiny Calculator（极简数字手算）

设单卡模型参数：

层数 $L = 1$
批大小 $B = 1$
序列总长度 $S = 2$
隐藏层大小 $d = 4$ ，Head 维度 $d_h = 2$ ，Query 头数 $H_q = 2$ ，KV 头数 $H_{kv} = 1$ （GQA 2:1）
数据类型：BF16（2 字节/元素）

对于单个 Token：

Key 向量大小： $H_{kv} \times d_h = 1 \times 2 = 2$ 个元素，占 $2 \times 2 = 4$ 字节；
Value 向量大小： $H_{kv} \times d_h = 1 \times 2 = 2$ 个元素，占 $2 \times 2 = 4$ 字节；
单 Token 单层 KV 字节： $4 + 4 = 8$ 字节。
总容量（ $L=1, B=1, S=2$ ）： $8 \times 2 = \mathbf{16 \text{ B}}（16 字节）$ 。

④ Formal Model（标准公式与映射）

对于一个

L

层、隐藏层大小

d

、Query 头数

H_q

、KV 头数

H_{kv}

的模型，在精度字节数为

U

（FP16/BF16 时

U=2

，FP8 时

U=1

）下：单 Token 在全模型中产生的 KV Cache 显存为：

\text{KV-token-size} = 2 \times U \times L \times d \times \left( \frac{H_{kv}}{H_q} \right) \quad (\text{Bytes})

在并发请求数为

B

，平均上下文长度为

S

时，全集群常驻的总 KV Cache 物理显存为：

M_{\text{kv}} = 2 \times U \times B \times S \times L \times d \times \left( \frac{H_{kv}}{H_q} \right) \quad (\text{Bytes})

⑤ Sanity Check（数量级校验）

以 LLaMA-3-70B（

L=80, d=8192, H_q=64, H_{kv}=8

，即 GQA 1:8 分组）为例：单 Token 全层 KV Cache 尺寸（BF16,

U=2

）：

\text{Size}_{\text{token}} = 2 \times 2 \times 80 \times 8192 \times \frac{8}{64} = 327,680\text{ 字节} \approx \mathbf{320\text{ KB/token}}

当部署在单机 8 卡 H100（TP=8）上时：

单卡平摊每 Token 仅：

320\text{ KB} / 8 = \mathbf{40\text{ KB/token}}

若并发 $B=32$ ，上下文平均长度 $S=8192$ （8K）：

M_{\text{kv-card}} = 40\text{ KB} \times 32 \times 8192 \approx \mathbf{10.48\text{ GB}}

80GB 显存扣除约 17.5 GB 静态权重后，剩余超过 50 GB 显存，服务运行非常宽裕！

3.3 传统连续预分配 vs PagedAttention 分页虚拟化

如果仅仅按上述理论公式计算，线上服务依然会频繁遭遇虚假的 OOM。为什么？

传统朴素推理引擎的致命痛点（显存虚胖）：

在 HuggingFace 等朴素框架中，由于 PyTorch 的张量必须在物理上占据连续内存空间：

预分配浪费（Internal Fragmentation）：当用户设定最大生成长度为 4096 时，框架必须在请求刚进来的一瞬间，就立刻按 4096 长度分配出一整块连续显存空间！但实际用户可能问了一个简单问题，模型只吐出 50 个 Token 就输出了 <eos> 结束符。剩下的 4046 个 Token 显存全部被白白锁死，无法给其他请求使用；
外部碎片（External Fragmentation）：由于不同请求的长度动态变化，频繁的分配与释放会导致 GPU 显存被割裂成无数细小、不连续的空闲碎片。当一个新请求需要 2 GB 连续空间时，虽然显存总空闲还有 10 GB，但最大的连续块只有 1.5 GB，系统依然报错 OOM！

实测数据表明：在朴素连续分配机制下，GPU 显存的真实有效利用率通常只有可怜的 20% ~ 35%！

PagedAttention（vLLM 核心算法）的破局之道：

借鉴现代操作系统虚拟内存的分页机制（Paging），PagedAttention 彻底打碎了物理连续的枷锁：

逻辑连续，物理离散：将每个序列的 KV Cache 切分为固定大小的 Block（如每个 Block 存 16 个 Token）；
页表路由（Page Table）：在 CPU 侧维护一张逻辑块到物理块的映射页表。每当生成 16 个新 Token，引擎才向显存内存池申请一个新的物理 Block；
Copy-on-Write 零拷贝分叉：在多轮对话或并行采样（Parallel Sampling）中，共享的前缀 Prompt 物理 Block 只有一份引用，仅在发生分叉写入时才申请新 Block。

工程成效：显存浪费直接降低到最后一个未填满 Block 的微量空间（平均每个请求浪费不到半个 Block，即 8 个 Token），物理显存有效利用率直接飙升至 96% 以上，线上推理并发承载能力原地提升 2.5 ~ 4 倍！

3.4 稠密模型 vs MoE 混合专家模型的显存账本分化

随着 Mixtral 8x7B、DeepSeek-V2/V3 等 MoE（Mixture of Experts）模型席卷工业界，显存账本出现了革命性的分化：

[稠密模型 (Dense Model, 如 LLaMA-3-70B)]
• 总参数量: 70B
• 每个 Token 激活参数量: 70B (100%)
• 显存与算力严格绑定：有多少参数，就占用多少静态显存，也发生多少 FLOPs 计算。

[稀疏门控 MoE 模型 (如 Mixtral 8x7B)]
• 总参数量: 47B (含 8 个专家)
• 每个 Token 激活参数量: 仅约 13B (Top-2 路由)
• 显存与算力彻底解耦：
  - 静态显存必须存下全部 47B 参数 (约 94 GB BF16)！
  - 动态计算量 FLOPs 却仅仅相当于一个 13B 的轻量模型！

MoE 显存架构设计的工业 Trade-off：

显存容量是硬门槛：部署 MoE 必须按**全量总参数（Total Params）**来规划 GPU 显存容量。哪怕每个 Token 只激活 1 个专家，整张卡也必须把所有未激活专家的静态权重完整常驻显存；
Decode 吞吐天然受益：在推理 Decode 阶段，由于算术强度由激活参数决定，MoE 模型以 13B 的微小计算量却拥有接近 70B 稠密模型的知识容量，使得端到端首字延迟（TTFT）和单字生成延迟（TPOT）表现极其优异；
EP（专家并行）通信开销：当单机显存塞不下海量专家时，必须引入专家并行（Expert Parallelism），这会引发跨节点的 All-to-All Token 路由通信，对集群机间 RDMA 带宽提出极高要求。

4. 计算量（FLOPs）、MFU 与 HFU 工业级算盘

4.1 前向 $2P$ 、反向 $4P$ 、训练 $6P$ 与全重算 $8P$ 的严格矩阵计数

在上一讲中我们推导了单 Token 的基本算盘。在此我们建立面向分布式全集群的完整 FLOPs 计数模型：设非 Embedding 模型参数量为

P

，全批次 Token 总数（

B \times S

）：

前向传播（Forward Pass）：

\text{FLOPs}_{\text{fwd}} = 2 \times P \times B \times S

反向传播（Backward Pass，激活求导 $2P$ + 权重求导 $2P$ ）：

\text{FLOPs}_{\text{bwd}} = 4 \times P \times B \times S

标准训练（Standard Training，无全重算）：

\text{FLOPs}_{\text{train}} = \text{FLOPs}_{\text{fwd}} + \text{FLOPs}_{\text{bwd}} = \mathbf{6 \times P \times B \times S}

全激活重算训练（Full Activation Checkpointing）：由于前向过程被完整多算了一次：

\text{FLOPs}_{\text{full-recompute}} = 2 \times P \times B \times S (\text{前向}) + 2 \times P \times B \times S (\text{重算}) + 4 \times P \times B \times S (\text{反向}) = \mathbf{8 \times P \times B \times S}

4.2 Attention 二次项修正量：何时不能忽略 $4LS^2d$ ？

在很多简化的参数计算中，大家往往习惯性使用

6P

。但在超长上下文（

S \ge 8192

）训练中，Attention 矩阵点乘带来的计算量绝对不容忽视！对于

L

层 Transformer，每层包含两个与参数量无关的纯张量乘法：

$Q \cdot K^T$ ： $[B, H_q, S, d_h] \times [B, H_q, d_h, S] \to [B, H_q, S, S]$ ，计算量为 $2 \times B \times H_q \times S \times d_h \times S = 2 B S^2 d$ ；
$\text{Attn} \cdot V$ ： $[B, H_q, S, S] \times [B, H_q, S, d_h] \to [B, H_q, S, d_h]$ ，计算量同样为 $2 B S^2 d$ 。

前向传播中每层产生

4 B S^2 d

FLOPs，反向传播约为前向的 2 倍（

8 B S^2 d

）。
因此，训练中 Attention 二次项的总计算量为：

\text{FLOPs}_{\text{attn-quadratic}} = 12 \times L \times B \times S^2 \times d

临界对比分析：

以 LLaMA-3-8B（

L=32, d=4096, P \approx 7 \times 10^9

）为例：

当 $S = 2048$ $S = 2048$ 时：
- 参数矩阵乘计算量：

6 \times 7 \times 10^9 \times S = 4.2 \times 10^{10} \times S

Attention 二次项计算量： $12 \times 32 \times S \times 4096 \times S \approx 1.57 \times 10^6 \times S^2$
二次项占比： $\frac{1.57 \times 10^6 \times 2048}{4.2 \times 10^{10}} \approx \mathbf{7.6\%}$ （可作为扰动项修正）；
当 $S = 32768$ $S = 32768$ （32K 长文本）时：
- 二次项占比飙升至： $\frac{1.57 \times 10^6 \times 32768}{4.2 \times 10^{10}} \approx \mathbf{122.5\%}$ ！
  惊人事实：在 32K 长度下，Attention 二次项的计算量已经彻底压过了全模型权重矩阵乘！此时必须使用严格公式修正 FLOPs。

4.3 MFU（模型算力利用率）vs HFU（硬件算力利用率）

在评估万卡大模型集群的性能时，业内存在两个核心指标：

[MFU: Model FLOPs Utilization (模型算力利用率) - 工业黄金金标准]
衡量的是模型在理论上完成学习所必需的最纯粹数学 FLOPs（通常按 6P 计算，不包含任何重算与 Padding 气泡）。
公式:
          纯理论必要总 FLOPs / 单步迭代时间
   MFU = ───────────────────────────────────────
          集群 GPU 数量 × 单卡硬件理论峰值 TFLOPS

[HFU: Hardware FLOPs Utilization (硬件算力利用率)]
衡量的是 GPU 物理核心上实际执行的所有指令（包含了激活全重算多出的 2P，以及数据 Padding 的无效计算）。
公式:
          实际执行总 FLOPs (含重算) / 单步迭代时间
   HFU = ───────────────────────────────────────────
          集群 GPU 数量 × 单卡硬件理论峰值 TFLOPS

两者的黄金关系：

如果开启了全激活重算，由于实际计算量由

6P

增加到

8P

：

\text{HFU} \approx \frac{8}{6} \times \text{MFU} = 1.333 \times \text{MFU}

警惕生产陷阱：在汇报性能数据时，有团队谎称自己的“利用率达到了 65%”，实际上他们汇报的是掺杂了全重算算力泡沫的 HFU！真实的行业评测一律以 MFU 为唯一客观铁律。

4.4 为什么大厂集群真实 MFU 往往只有 35%~55%？

如果 GPU 算力足够强，为什么工业界顶级集群（如 Meta LLaMA-3、DeepSeek）的真实 MFU 往往只能做到 38% ~ 54%，剩下的 50% 算力到底被什么黑洞吞噬了？

并行通信气泡（Communication Bubbles）：
- 流水线并行（PP）中的 1F1B 调度天然存在 Warmup 和 Cooldown 气泡；
- 张量并行（TP）在每层 Attention 和 FFN 都要做 2 次跨卡 All-Reduce，当多机扩展时，跨节点网络延迟导致 Tensor Core 频繁挂起等待；
Memory-Bound 访存受限算子的拖累：
- RMSNorm、Softmax、RoPE、SiLU 逐元素操作的算术强度极低，GPU 绝大部分时间被存储墙封锁；
数据 Padding 与长短不齐（Workload Imbalance）：
- 在同一个 Batch 中，为了对齐最长序列，短文本被补入了大量无效的 <pad> Token，这部分消耗了硬件时钟却无法计入有效 MFU；
底层 Kernel Launch 开销与 CPU 调度延迟：
- 数千个细小算子的调度如果未被 CUDA Graph 捕获，CPU 与 GPU 之间的指令流水线会出现微小空隙。

5. 全场景实战：编写工业级容量规划与显存诊断脚本

5.1 实验一：原生 PyTorch 动态激活显存峰值与重算打点测试

本实验通过原生 PyTorch 模拟单层 Transformer 的前向与反向，通过 torch.cuda.memory_allocated() 与 max_memory_allocated() 精确打点：

观察无重算时的激活值峰值；
观察开启 PyTorch 原生 checkpoint 后的显存陡降与算力时间开销。

"""
Ringi AI Infra 实验室：Minimal Runnable Code
实验一：PyTorch 激活值显存峰值打点与梯度重算对比实验
运行环境：需配备 NVIDIA GPU 并在支持 CUDA 的 PyTorch 环境中运行
"""

import torch
import torch.nn as nn
from torch.utils.checkpoint import checkpoint

class DummyTransformerLayer(nn.Module):
    def __init__(self, d_model: int):
        super().__init__()
        self.norm = nn.LayerNorm(d_model)
        self.linear1 = nn.Linear(d_model, 4 * d_model)
        self.act = nn.GELU()
        self.linear2 = nn.Linear(4 * d_model, d_model)

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        # 产生多步中间激活值
        residual = x
        x = self.norm(x)
        x = self.linear1(x)
        x = self.act(x)
        x = self.linear2(x)
        return x + residual

def run_memory_experiment():
    if not torch.cuda.is_available():
        print("[-] 未检测到 CUDA 环境，本实验需要在支持 GPU 的机器上执行以观测物理显存。")
        return

    device = torch.device("cuda:0")
    torch.cuda.empty_cache()
    torch.cuda.reset_peak_memory_stats(device)

    B, S, d_model = 8, 4096, 4096
    print(f"=== 配置参数: Batch={B}, SeqLen={S}, Dim={d_model} ===")

    # 1. 模拟无重算 (Standard Forward-Backward)
    model = nn.Sequential(*[DummyTransformerLayer(d_model) for _ in range(4)]).to(device)
    inputs = torch.randn(B, S, d_model, device=device, requires_grad=True)

    base_mem = torch.cuda.memory_allocated(device) / (1024 ** 2)
    print(f"[1. 无重算模式] 静态模型初始化显存: {base_mem:.2f} MB")

    out = model(inputs)
    fwd_mem = torch.cuda.memory_allocated(device) / (1024 ** 2)
    peak_mem_no_ckpt = torch.cuda.max_memory_allocated(device) / (1024 ** 2)
    print(f"[1. 无重算模式] 前向后常驻激活显存: {fwd_mem:.2f} MB (较静态激增 {fwd_mem - base_mem:.2f} MB)")
    print(f"[1. 无重算模式] 运行全程最高峰值显存: {peak_mem_no_ckpt:.2f} MB")

    loss = out.sum()
    loss.backward()
    del out, loss
    torch.cuda.empty_cache()

    # 2. 模拟全激活重算 (Checkpointing)
    print("\n------------------------------------------------------------------")
    torch.cuda.reset_peak_memory_stats(device)
    base_mem_ckpt = torch.cuda.memory_allocated(device) / (1024 ** 2)
    
    # 使用 checkpoint 包裹前向
    def run_with_ckpt(x):
        for layer in model:
            x = checkpoint(layer, x, use_reentrant=False)
        return x

    inputs_ckpt = torch.randn(B, S, d_model, device=device, requires_grad=True)
    out_ckpt = run_with_ckpt(inputs_ckpt)
    fwd_mem_ckpt = torch.cuda.memory_allocated(device) / (1024 ** 2)
    peak_mem_ckpt = torch.cuda.max_memory_allocated(device) / (1024 ** 2)

    print(f"[2. 激活重算模式] 前向后常驻激活显存: {fwd_mem_ckpt:.2f} MB (较静态激增 {fwd_mem_ckpt - base_mem_ckpt:.2f} MB)")
    print(f"[2. 激活重算模式] 运行全程最高峰值显存: {peak_mem_ckpt:.2f} MB")
    
    saved_ratio = (1 - (peak_mem_ckpt / peak_mem_no_ckpt)) * 100
    print(f"\n>>> 实测结论: 开启激活重算后，显存峰值降低了 {saved_ratio:.2f}%！")

if __name__ == "__main__":
    run_memory_experiment()

5.2 实验二：工业级全栈容量规划器 `cluster_capacity_planner.py`

在面对真实的集群规划、选型采买和架构排布时， Infra 工程师需要一套严密的计算引擎。本脚本实现了从任意模型参数手算集群节点配比、ZeRO 静态切分、动态激活值、长文本 KV Cache 与 MFU 倒推的全景规划器：

"""
Ringi AI Infra 实验室：Minimal Runnable Code
实验二：工业级千卡训练集群与万级并发推理全栈容量规划器
纯 Python 标准库编写，零第三方依赖，可直接执行！
"""

class ClusterCapacityPlanner:
    def __init__(
        self,
        model_name: str,
        num_layers: int,
        hidden_size: int,
        num_heads: int,
        num_kv_heads: int,
        intermediate_size: int,
        vocab_size: int = 128256
    ):
        self.name = model_name
        self.L = num_layers
        self.d = hidden_size
        self.H_q = num_heads
        self.H_kv = num_kv_heads
        self.d_ffn = intermediate_size
        self.V = vocab_size

        # 1. 严格手算非 Embedding 参数量 P 与全模型总参数量 Psi
        self.params_attn = 2 * (self.d ** 2) * (1 + self.H_kv / self.H_q) * self.L
        self.params_ffn = 3 * self.d * self.d_ffn * self.L
        self.params_embed = 2 * self.V * self.d
        self.non_embed_params = self.params_attn + self.params_ffn
        self.total_params = self.non_embed_params + self.params_embed

    def plan_training_cluster(
        self,
        num_gpus: int,
        gpu_memory_gb: float = 80.0,
        gpu_fp16_tflops: float = 989.0, # A100=312, H100=989 (Dense)
        batch_size_per_gpu: int = 1,
        seq_len: int = 4096,
        tensor_parallel: int = 8,
        recompute_mode: str = "selective" # "none", "full", "selective"
    ):
        """规划训练集群切分、显存水位与 MFU 吞吐预测"""
        psi = self.total_params
        
        # 静态显存分析 (ZeRO-3 全切分)
        # 单卡静态状态: (2 权重 + 2 梯度 + 12 AdamW) * psi / N
        static_total_gb = (16 * psi) / (1024 ** 3)
        static_per_gpu_gb = static_total_gb / num_gpus

        # 动态激活值显存手算 (考虑机内张量并行 TP=8 切分)
        B = batch_size_per_gpu
        S = seq_len
        d = self.d
        if recompute_mode == "none":
            act_per_layer_bytes = 34 * B * S * d + 5 * B * (S ** 2) * self.H_q
            total_act_bytes = self.L * act_per_layer_bytes
        elif recompute_mode == "full":
            total_act_bytes = 2 * B * S * d * self.L # 仅留输入 Checkpoint
        else: # "selective"
            total_act_bytes = self.L * (34 * B * S * d) # 抹除 S^2
        
        # 在 TP 并行下，隐藏维度在卡间分块，单卡激活值除以 TP
        act_per_gpu_gb = (total_act_bytes / tensor_parallel) / (1024 ** 3)
        runtime_overhead_gb = 3.5 # CUDA 上下文与通信缓存
        total_used_gpu_gb = static_per_gpu_gb + act_per_gpu_gb + runtime_overhead_gb
        is_oom = total_used_gpu_gb > gpu_memory_gb

        # 单步纯模型理论计算量 (6P FLOPs)
        total_tokens_per_step = B * S * num_gpus
        pure_model_flops = 6 * self.non_embed_params * total_tokens_per_step

        return {
            "model_params_b": psi / 1e9,
            "static_per_gpu_gb": static_per_gpu_gb,
            "act_per_gpu_gb": act_per_gpu_gb,
            "total_used_gpu_gb": total_used_gpu_gb,
            "is_oom": is_oom,
            "total_tokens_per_step": total_tokens_per_step,
            "step_pure_flops_e15": pure_model_flops / 1e15 # PFLOPs
        }

    def plan_inference_capacity(
        self,
        num_gpus: int,
        gpu_memory_gb: float = 80.0,
        seq_len: int = 8192,
        kv_dtype_bytes: int = 2 # 2 for BF16, 1 for FP8
    ):
        """规划推理单卡/多卡在给定长度下的最大承载并发极限"""
        # 权重平摊
        weight_gb = (self.total_params * 2) / (1024 ** 3) # 假设权重 BF16
        weight_per_gpu_gb = weight_gb / num_gpus
        
        runtime_gb = 3.0
        available_kv_mem_gb = max(0.0, gpu_memory_gb - weight_per_gpu_gb - runtime_gb)

        # 单 Token 全集群 KV Cache
        bytes_per_token = 2 * kv_dtype_bytes * self.L * self.d * (self.H_kv / self.H_q)
        bytes_per_seq_cluster = bytes_per_token * seq_len
        bytes_per_seq_card = bytes_per_seq_cluster / num_gpus

        # 考虑 PagedAttention 96% 内存利用率
        effective_kv_mem_bytes = (available_kv_mem_gb * (1024 ** 3)) * 0.96
        max_concurrency = int(effective_kv_mem_bytes // bytes_per_seq_card) if bytes_per_seq_card > 0 else 0

        return {
            "weight_per_gpu_gb": weight_per_gpu_gb,
            "available_kv_mem_gb": available_kv_mem_gb,
            "kv_cache_per_seq_card_gb": (bytes_per_seq_card) / (1024 ** 3),
            "max_concurrency": max_concurrency
        }

if __name__ == "__main__":
    print("==================================================================")
    print("  Ringi AI Infra 全栈容量规划器 (Cluster Capacity Planner)")
    print("==================================================================")

    # 实例化 LLaMA-3-70B
    llama3_70b = ClusterCapacityPlanner(
        model_name="LLaMA-3-70B",
        num_layers=80,
        hidden_size=8192,
        num_heads=64,
        num_kv_heads=8,
        intermediate_size=28672,
        vocab_size=128256
    )

    # 1. 模拟千卡训练集群规划 (1024 卡 H100, 4K 上下文, MicroBatch=1, TP=8, 选择性重算)
    train_res = llama3_70b.plan_training_cluster(
        num_gpus=1024,
        gpu_memory_gb=80.0,
        gpu_fp16_tflops=989.0,
        batch_size_per_gpu=1,
        seq_len=4096,
        tensor_parallel=8,
        recompute_mode="selective"
    )

    print(f"\n[1. 1024卡 H100 训练规划 (4K 上下文, TP=8 + ZeRO-3)]")
    print(f"• 模型有效参数量        : {train_res['model_params_b']:.2f} B")
    print(f"• 单卡平摊静态显存 (ZeRO-3): {train_res['static_per_gpu_gb']:.2f} GB")
    print(f"• 单卡动态激活值 (TP=8平摊): {train_res['act_per_gpu_gb']:.2f} GB")
    print(f"• 单卡预计总显存占用    : {train_res['total_used_gpu_gb']:.2f} GB / 80 GB")
    print(f"• 是否安全通过 (无 OOM) : {'✅ 极度安全' if not train_res['is_oom'] else '❌ 发生 OOM'}")
    print(f"• 单步处理总 Token 数   : {train_res['total_tokens_per_step']:,} Tokens")
    print(f"• 单步纯模型计算量      : {train_res['step_pure_flops_e15']:.2f} PFLOPs")

    # 2. 模拟线上 8 卡推理集群规划 (8 卡 A100-80GB, 16K 上下文, 对比 BF16 vs FP8 KV)
    print(f"\n[2. 8卡 A100 推理集群容量规划 (16K 长文本)]")
    infer_bf16 = llama3_70b.plan_inference_capacity(num_gpus=8, seq_len=16384, kv_dtype_bytes=2)
    infer_fp8 = llama3_70b.plan_inference_capacity(num_gpus=8, seq_len=16384, kv_dtype_bytes=1)

    print(f"• 单卡静态权重显存 (TP=8)  : {infer_bf16['weight_per_gpu_gb']:.2f} GB")
    print(f"• 单卡可用 KV 显存池       : {infer_bf16['available_kv_mem_gb']:.2f} GB")
    print(f"• BF16 KV Cache (单并发/卡): {infer_bf16['kv_cache_per_seq_card_gb']:.2f} GB")
    print(f"• BF16 下最大承载并发数    : {infer_bf16['max_concurrency']} 并发")
    print(f"• FP8 KV Cache  (单并发/卡): {infer_fp8['kv_cache_per_seq_card_gb']:.2f} GB")
    print(f"• FP8 优化后最大承载并发数 : {infer_fp8['max_concurrency']} 并发 (翻倍提升!)")
    print("==================================================================")

6. Ringi 避坑指南与生产黄金准则

6.1 7 大常见小白认知误区 vs 大厂 AI Infra 正确物理认知

序号	❌ 常见小白错误理解	✅ 大厂 AI Infra 正确物理认知	体系结构本质与底层机理解析
01	“训练时显存超了，肯定是模型太大，只要开启混合精度显存就能减半。”	混合精度主要是为了加速计算，静态显存由于要维护 FP32 Master Weight 和 AdamW 动量，反而高达 $16\Psi$ 字节。	FP16/BF16 权重仅占 $2\Psi$ ，但优化器状态占 $12\Psi$ ，总显存远大于纯 FP16 的静态设想。
02	“只要显存还有 10 GB 剩余，就能稳定跑进一个 8 GB 的推理请求。”	朴素分配由于存在严重的内外碎片，物理连续空间可能不足 2 GB；必须依赖 PagedAttention 虚拟分页。	显存碎片会导致虚假的 `CUDA out of memory`，显存池化与分块是高并发服务的生存基石。
03	“全激活重算（Full Recompute）是零代价节约显存的免费午餐。”	全重算会在反向传播时将前向计算完整重跑一遍，使得总计算量从 $6P$ 飙升至 $8P$ ，白白损失 33.3% 算力。	除非显存濒临熔断，否则生产环境首选算力开销 <3% 的选择性激活重算（Selective Recomputation）。
04	“推理服务中把 Batch Size 设得越大，吞吐量和延迟就会成正比变好。”	Decode 阶段是极度访存受限的，当并发加大导致 KV Cache 超载挤占带宽，TPOT（单字时延）会急剧恶化。	必须根据硬件 HBM 物理带宽极限与 SLO 延迟要求，寻找吞吐与延迟权衡的最佳饱和并发点。
05	“ZeRO-3 能把显存切到无限小，因此训练大模型卡越多越好，不需要张量并行。”	ZeRO-3 在每次前向和反向都要对每一层权重做 AllGather，跨机网络通信量激增 50%，千卡规模下网络容易跑瘫。	生产超大模型（70B+）标准范式是机内 TP=8（利用 NVLink 900GB/s 带宽）+ 机间 ZeRO/PP 的混合切分。
06	“我们汇报模型训练利用率时达到了 65%，证明我们的工程优化举世无双。”	绝大多数声称超过 60% 的利用率汇报偷换了概念，使用的是包含了重算泡沫的 HFU，真正的 MFU 超过 50% 已属顶级。	MFU 严格排除重算算力与 Padding 气泡，是检验集群工程真金白银计算效率的唯一标尺。
07	“MoE 架构激活参数小，所以推理部署时买几张便宜的小显存显卡就能跑。”	MoE 模型的静态权重必须全量常驻显存，显存容量门槛由总参数决定，算力消耗才由激活参数决定。	8x7B 模型必须准备能装下 47B 参数的显存底座，绝不可能只用跑 13B 模型的单张卡强行加载。

6.2 生产容量工程黄金 Checklist

1. 【静态显存对账闭环】：集群建站前，严格按 $16\Psi$ 校验单卡静态容量，若单卡静态显存超过物理容量的 60%，强制开启 ZeRO-2 或机内张量并行（TP）。
2. 【长文本重算三档选型】：序列长度 $S \le 2K$ 严禁开全重算； $2K < S \le 32K$ 强制开启基于 FlashAttention 的选择性重算；仅在 $S > 32K$ 且即将 OOM 时降级开启全重算。
3. 【PagedAttention 块大小调优】：线上推理服务强制开启 PagedAttention，长文本问答场景推荐 Block Size 设置为 16 或 32，权衡页表检索开销与碎片利用率。
4. 【FP8 KV Cache 渐进灰度】：对于 16K 以上的长文本推理服务，推进部署 FP8（E4M3 或 E5M2）KV Cache 量化，直接释放 50% 动态显存并成倍提升 Decode 访存带宽吞吐。
5. 【MFU 硬性验收红线】：千卡分布式预训练集群上线前，单步 MFU 必须通过基准验收（A100 SXM 节点 MFU $\ge 42\%$ ，H100 SXM 节点 MFU $\ge 46\%$ ），未达标禁止开跑正式数据。
6. 【预留 15% 碎片安全护城河】：任何容量规划模型中，计算得到的动态 KV Cache 上限必须强制乘以 0.85 的安全系数，坚决不把物理显存吃满到最后一兆字节。
7. 【Padding 动态剔除】：训练数据加载管线务必启用 Packing / Sample Multiplexing（将多条短样本拼接为固定长序列），彻底消灭无效 <pad> Token 对 FLOPs 的空耗。

7. Ringi 5 点核心速记口诀、自我检验清单与课后深度思考题

7.1 5 点押韵核心速记口诀

静态底账十六匹，动量副本莫忘记；
激活平方呈爆发，选择重算把灾避；
推理瓶颈在访存，分页管理消碎粒；
前二反四全六匹，重算平添两分力；
算盘打尽天下卡，容量规划定大计！

7.2 10 条白板自我检验清单

能否闭卷推导 AdamW 优化器占用 $12\Psi$ 显存的三个独立组成部分？
能否推导为什么混合精度训练不能直接用 BF16 累加梯度更新权重（下溢原理）？
能否解释 ZeRO-1、ZeRO-2、ZeRO-3 各自切分了哪些状态，并写出对应的单卡静态显存公式？
能否白板推导单层 Transformer 无重算时的激活值显存公式，并指出二次项 $5BS^2 H_q$ 的来源？
能否说明选择性重算（Selective Recomputation）为什么既能消灭 $S^2$ 显存，又几乎不增加计算时间？
能否写出单 Token 全模型 KV Cache 显存大小的通用计算公式（含 GQA 分组比参数）？
能否解释传统连续内存预分配导致推理显存碎片率高达 60% 以上的两大物理诱因？
能否阐明 PagedAttention 的 Block 机制与操作系统虚拟内存页表的设计映射？
能否严格手算前向 $2P$ 、反向 $4P$ 、全重算 $8P$ 的矩阵乘累加过程？
能否用一句话清晰区分 MFU 与 HFU 的本质差异，并说明为什么全重算会拉大两者差距？

7.3 3 道高阶开放式课后思考题（含极限 Corner Case）

【万卡集群下的网络风暴 Corner Case】：在一个由 1024 台 8 卡节点（共 8192 张 H100）组成的超大规模集群中，如果我们完全不采用 Pipeline 并行和 Tensor 并行，而是暴力使用纯 ZeRO-3 全切分跑 70B 模型，底层网络（RDMA / InfiniBand）会面临什么致命瓶颈？网络时延抖动将如何把整机 MFU 拉垮到个位数？
【超长上下文推理的 KV Cache 临界翻转】：在 1M（100 万）上下文长度下，哪怕开启了 GQA（1:8）和 FP8 KV Cache，单请求的 KV 缓存体积也将达到惊人的量级。此时一个请求是否可能需要跨节点进行分布式 KV Cache 切分？这会给推理引擎的调度器（Scheduler）带来什么重构挑战？
【DeepSeek-V3 的 DualPipe 算力遮蔽神技】：DeepSeek-V3 在极低训练成本下实现了顶尖性能，其核心创新之一是 DualPipe（双向重叠流水线并行）。请从计算与通信重叠（Overlap）的角度分析：它是如何利用前向和反向的不同计算块，将全切分带来昂贵跨节点通信时间几乎 100% 完美隐藏在计算之下的？

8. 📚 参考资料与核心源码/经典论文指引

权威学术论文：

ZeRO 显存切分奠基：Rajbhandari et al., “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models”, SC 2020. arXiv:1910.02054
激活值选择性重算：Korthikanti et al., “Reducing Activation Recomputation in Large Transformer Models”, MLSys 2023. arXiv:2205.05198
PagedAttention 与 vLLM：Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention”, SOSP 2023. arXiv:2309.06180
混合精度训练理论：Micikevicius et al., “Mixed Precision Training”, ICLR 2018. arXiv:1710.03740
FlashAttention-2：Dao, “FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning”, ICLR 2024. arXiv:2307.08691
DeepSeek-V3 技术报告：DeepSeek-AI, “DeepSeek-V3 Technical Report”, 2024. arXiv:2412.19437

工业级开源源码指引：

DeepSpeed ZeRO 引擎：deepspeed/runtime/zero/stage3.py 与 stage2.py（工业级状态切分与通信原语实现）
Megatron-LM 激活重算实现：megatron/core/tensor_parallel/cross_entropy.py 与 megatron/core/transformer/
vLLM PagedAttention 内核：csrc/attention/attention_kernels.cu（核心虚拟分页 CUDA Kernel）

本地 AI_BOOK 知识库精准映射：

训练显存分析：05TrainingMemory.md
推理显存与 KV：06InferenceMemory.md
MFU 与算力评估：CODE03MFU.md
ZeRO 原理与实战：Code01ZeRO.md

附录：Appendix A — 大厂硬核高频面试题与白板推导（Interview Drill）

面试真题 1：千卡集群训练 70B 模型，如果不开启张量并行（TP），仅使用纯数据并行 + ZeRO-3，单卡至少需要多大显存？网络通信量会暴涨多少？

考察维度：分布式切分边界、网络通信量手算、大规模集群拓扑常识。

标准推导路径：

单卡显存手算：
- 70B 稠密模型全量静态显存为 $16\Psi = 16 \times 70 \times 10^9\text{ Bytes} \approx 1120\text{ GB}$ ；
- 在 1024 张 GPU 下，采用纯 ZeRO-3 全切分：

\text{Mem}_{\text{static-card}} = \frac{1120\text{ GB}}{1024} \approx \mathbf{1.09\text{ GB}}

动态激活值（若使用选择性重算，设单卡 Batch=2, Seq=4096）：约占 4.5 GB；
临时通信缓冲区与框架开销：约 3.5 GB；
单卡总显存开销： $1.09 + 4.5 + 3.5 = \mathbf{9.09\text{ GB}}$ ！
结论 1：纯从显存容量来看，单卡仅需不足 10 GB，哪怕用 24GB 的老旧显卡都能塞下！

通信量暴涨分析（致命死局）：
- 在标准 DDP / ZeRO-1 中，通信仅在反向传播结束时发生 1 次权重梯度的 All-Reduce，总通信量为 $2\Psi$ ；
- 在 ZeRO-3 中：
前向传播：每一层计算前，必须通过 All-Gather 动态从其他卡收集该层参数，前向完毕立刻释放，通信量为 $\Psi$ ；
反向传播：每一层反向求导前，必须再次通过 All-Gather 重新收集一次该层参数，通信量为 $\Psi$ ；
梯度同步：计算完梯度后，通过 Reduce-Scatter 将梯度分片规约并回写到对应的拥有卡，通信量为 $\Psi$ ；

ZeRO-3 总通信量： $\Psi + \Psi + \Psi = \mathbf{3\Psi}$ ！
结论 2：通信量从 $2\Psi$ 飙升到 $3\Psi$ （净增加 50%）！更致命的是，在千卡规模下，原本可以在机内 NVLink 解决的通信被迫泛滥到跨机低速网络中，千卡同时频繁执行跨节点 AllGather，网络交换机瞬间发生严重拥塞与排队丢包，导致整机 MFU 出现断崖式暴跌（可能不足 15%）。这就是为什么生产环境必须强制机内 TP=8 + 机间 ZeRO 的根本原因！

面试真题 2：在 8 卡 H100 集群上做 32K 超长上下文推理，为什么开启 FP8 KV Cache 比把模型权重做 INT4 量化对系统吞吐提升更显著？

考察维度：Roofline 瓶颈定位、Decode 阶段访存特征、量化收益归因。

标准参考答案：

瓶颈定位：在 32K 长文本自回归生成（Decode）阶段，系统处于极端恶劣的 Memory-Bound（访存受限） 状态，算术强度极低，每个 Token 生成的延迟严格取决于：

\text{Step Latency} \approx \frac{\text{权重总读取量} + \text{全并发历史 KV Cache 读取量}}{\text{硬件 HBM 物理带宽}}

数据量对比 hand-calculation：以 70B 模型、并发 Batch=16、上下文平均 $S=32K$ $S = 32 K$ （32,768）为例：
- 权重读取量（每次生成 1 个 Token 固定发生）：

BF16 权重：

70\text{ GB} \times 2 = 140\text{ GB}

INT4 量化权重： $70\text{ GB} \times 0.5 = 35\text{ GB}$ （节省了 105 GB 访存）；
KV Cache 读取量（随序列激增）：
单 Token GQA KV Cache 约 320 KB；
并发 16 下，32K 长度的瞬时全量 KV Cache 为：

M_{\text{kv-BF16}} = 320\text{ KB} \times 16 \times 32768 \approx \mathbf{167.7\text{ GB}}!

开启 FP8 KV Cache 后，每个元素从 2 字节降至 1 字节：

M_{\text{kv-FP8}} = \frac{167.7\text{ GB}}{2} \approx \mathbf{83.8\text{ GB}}!

单次生成仅 KV 搬运就直接节省了整整 83.9 GB 显存带宽！ 3. 系统吞吐的核心放大器（显存容量解锁并发）：

INT4 权重虽然压缩了模型，但无法解决 KV Cache 吞噬显存的死局，最大并发数被死死卡在低水位；
而 FP8 KV Cache 不仅将庞大的 KV 访存量砍半，更直接将单卡可承载的最大并发容量翻了整整 2 倍！
并发翻倍意味着 GPU 能够在每个 Step 内并行服务更多的用户请求，端到端吞吐量（Tokens/s）直接实现翻倍跃迁。因此在长文本场景下，优化 KV Cache 永远享有第一优先级。

面试真题 3：请白板手算在单台 8 卡 A100-80GB 服务器上，训练一个 13B 稠密模型（ $L=40, d=5120, H_q=40$ ），在 Batch=16、SeqLen=2048 时，无重算与选择性重算下的激活值显存差值。

考察维度：激活值精确推导、二次项敏感度评估、工程直觉。

标准推导路径：

提取核心参数：
- 层数 $L = 40$
- 维度 $d = 5120$
- 头数 $H_q = 40$
- 批大小 $B = 16$
- 序列长度 $S = 2048$
计算单层线性项与二次项系数：
- 单层线性项（Linear Part）：

\text{Act}_{\text{linear}} = 34 \times B \times S \times d = 34 \times 16 \times 2048 \times 5120 \approx 5,704,253,440\text{ 字节} \approx \mathbf{5.31\text{ GB}}

单层 Attention 二次项（Quadratic Part）：

\text{Act}_{\text{quadratic}} = 5 \times B \times S^2 \times H_q = 5 \times 16 \times (2048)^2 \times 40 = 13,421,772,800\text{ 字节} \approx \mathbf{12.50\text{ GB}}

计算全模型（40 层）总和：
- 无重算模式（保留线性项 + 二次项）：

M_{\text{total-no-recompute}} = 40 \times (5.31\text{ GB} + 12.50\text{ GB}) = 40 \times 17.81\text{ GB} \approx \mathbf{712.4\text{ GB}}

选择性重算模式（抹除二次项，仅保留线性项）：

M_{\text{total-selective}} = 40 \times 5.31\text{ GB} \approx \mathbf{212.4\text{ GB}}

得出差值与结论：

\Delta \text{Memory} = 712.4\text{ GB} - 212.4\text{ GB} = \mathbf{500.0\text{ GB}}!

在 8 卡数据并行下，每张卡直接净省：

\Delta M_{\text{per-card}} = \frac{500\text{ GB}}{8} = \mathbf{62.5 \text{ GB}}（每卡 62.5 GB）!

结论：如果不开启选择性重算，单卡光激活值就要吃掉近 90 GB 显存，80GB 卡当场 OOM 暴毙；而开启选择性重算后，单卡激活值骤降到仅 26.5 GB，训练稳稳当当全速跑飞，且额外算力开销不足 3%！

⌘I

​第27讲：显存去哪儿了？——大模型训练与推理显存全景账本、FLOPs 白板手算与 KV Cache 容量规划

​📑 目录导航

​0. Ringi 开场：生产真实现场与痛点冲突

​0.1 真实工程矛盾：千卡训练的“幽灵 OOM” vs 线上推理的“虚胖碎片”

​0.2 线上真实事故复盘：某 1024 卡集群扩充 16K 上下文引发的全链路瘫痪

​0.3 显存四大账本（容量 vs 流量）与全景指标速查表

​1. 静态显存白板手算：权重、梯度与 AdamW 优化器（ 16Ψ∼20Ψ16\Psi \sim 20\Psi16Ψ∼20Ψ 底账）

​1.1 混合精度训练的四重身：从 BF16 到 FP32 Master Weight

​为什么不能纯用 BF16 完成更新？

​1.2 为什么是 16Ψ16\Psi16Ψ？什么时候会膨胀到 18Ψ18\Psi18Ψ 或 20Ψ20\Psi20Ψ？

​标准 16Ψ16\Psi16Ψ 显存底账（主流 Megatron-LM / DeepSpeed 默认）：

​何时会膨胀到 18Ψ18\Psi18Ψ？

​何时会膨胀到 20Ψ20\Psi20Ψ？

​1.3 ZeRO-1 / ZeRO-2 / ZeRO-3 状态切分模型与单卡显存推导

​1.4 ZeRO-Offload 的物理瓶颈：PCIe 带宽与 Host 内存延迟惩罚

​2. 动态激活显存深度拆解：激活值的三档重算（Recomputation）博弈

​2.1 逐层激活值公式白板推导：Attention 与 FFN 的激活开销

​1. Attention 模块激活值明细：

​2. FFN 模块激活值明细（以标准 FFN 4d4d4d 为例）：

​单层激活值总量大一统公式（无重算）：

​2.2 三档重算策略深度博弈：无重算 vs 全重算 vs 选择性重算

​2.3 FlashAttention 反向融合如何抹平中间矩阵显存

​3. 推理显存账本与 KV Cache 容量规划

​3.1 推理两阶段的物理分化：Prefill 阶段 vs Decode 阶段

​3.2 No Naked Formula 2.0 穿透 KV Cache 容量公式

​① 为什么需要算它？

​② Mental Model（物理直觉比喻）

​③ Tiny Calculator（极简数字手算）

​④ Formal Model（标准公式与映射）

​⑤ Sanity Check（数量级校验）

​3.3 传统连续预分配 vs PagedAttention 分页虚拟化

​传统朴素推理引擎的致命痛点（显存虚胖）：

​PagedAttention（vLLM 核心算法）的破局之道：

​3.4 稠密模型 vs MoE 混合专家模型的显存账本分化

​MoE 显存架构设计的工业 Trade-off：

​4. 计算量（FLOPs）、MFU 与 HFU 工业级算盘

​4.1 前向 2P2P2P、反向 4P4P4P、训练 6P6P6P 与全重算 8P8P8P 的严格矩阵计数

​4.2 Attention 二次项修正量：何时不能忽略 4LS2d4LS^2d4LS2d？

​临界对比分析：

​4.3 MFU（模型算力利用率）vs HFU（硬件算力利用率）

​两者的黄金关系：

​4.4 为什么大厂集群真实 MFU 往往只有 35%~55%？

​5. 全场景实战：编写工业级容量规划与显存诊断脚本

​5.1 实验一：原生 PyTorch 动态激活显存峰值与重算打点测试

​5.2 实验二：工业级全栈容量规划器 cluster_capacity_planner.py

​6. Ringi 避坑指南与生产黄金准则

​6.1 7 大常见小白认知误区 vs 大厂 AI Infra 正确物理认知

​6.2 生产容量工程黄金 Checklist

​7. Ringi 5 点核心速记口诀、自我检验清单与课后深度思考题

​7.1 5 点押韵核心速记口诀

​7.2 10 条白板自我检验清单

​7.3 3 道高阶开放式课后思考题（含极限 Corner Case）

​8. 📚 参考资料与核心源码/经典论文指引

​权威学术论文：

​工业级开源源码指引：

​本地 AI_BOOK 知识库精准映射：

​附录：Appendix A — 大厂硬核高频面试题与白板推导（Interview Drill）

​面试真题 1：千卡集群训练 70B 模型，如果不开启张量并行（TP），仅使用纯数据并行 + ZeRO-3，单卡至少需要多大显存？网络通信量会暴涨多少？

​考察维度：分布式切分边界、网络通信量手算、大规模集群拓扑常识。

​标准推导路径：

​面试真题 2：在 8 卡 H100 集群上做 32K 超长上下文推理，为什么开启 FP8 KV Cache 比把模型权重做 INT4 量化对系统吞吐提升更显著？

​考察维度：Roofline 瓶颈定位、Decode 阶段访存特征、量化收益归因。

​标准参考答案：

​面试真题 3：请白板手算在单台 8 卡 A100-80GB 服务器上，训练一个 13B 稠密模型（ L=40,d=5120,Hq=40L=40, d=5120, H_q=40L=40,d=5120,Hq​=40 ），在 Batch=16、SeqLen=2048 时，无重算与选择性重算下的激活值显存差值。

​考察维度：激活值精确推导、二次项敏感度评估、工程直觉。

​标准推导路径：

第27讲：显存去哪儿了？——大模型训练与推理显存全景账本、FLOPs 白板手算与 KV Cache 容量规划

📑 目录导航

0. Ringi 开场：生产真实现场与痛点冲突

0.1 真实工程矛盾：千卡训练的“幽灵 OOM” vs 线上推理的“虚胖碎片”

0.2 线上真实事故复盘：某 1024 卡集群扩充 16K 上下文引发的全链路瘫痪

0.3 显存四大账本（容量 vs 流量）与全景指标速查表

1. 静态显存白板手算：权重、梯度与 AdamW 优化器（ $16\Psi \sim 20\Psi$ 底账）

1.1 混合精度训练的四重身：从 BF16 到 FP32 Master Weight

为什么不能纯用 BF16 完成更新？

1.2 为什么是 $16\Psi$ ？什么时候会膨胀到 $18\Psi$ 或 $20\Psi$ ？

标准 $16\Psi$ 显存底账（主流 Megatron-LM / DeepSpeed 默认）：

何时会膨胀到 $18\Psi$ ？

何时会膨胀到 $20\Psi$ ？

1.3 ZeRO-1 / ZeRO-2 / ZeRO-3 状态切分模型与单卡显存推导

1.4 ZeRO-Offload 的物理瓶颈：PCIe 带宽与 Host 内存延迟惩罚

2. 动态激活显存深度拆解：激活值的三档重算（Recomputation）博弈

2.1 逐层激活值公式白板推导：Attention 与 FFN 的激活开销

1. Attention 模块激活值明细：

2. FFN 模块激活值明细（以标准 FFN $4d$ 为例）：

单层激活值总量大一统公式（无重算）：

2.2 三档重算策略深度博弈：无重算 vs 全重算 vs 选择性重算

2.3 FlashAttention 反向融合如何抹平中间矩阵显存

3. 推理显存账本与 KV Cache 容量规划

3.1 推理两阶段的物理分化：Prefill 阶段 vs Decode 阶段

3.2 No Naked Formula 2.0 穿透 KV Cache 容量公式

① 为什么需要算它？

② Mental Model（物理直觉比喻）

③ Tiny Calculator（极简数字手算）

④ Formal Model（标准公式与映射）

⑤ Sanity Check（数量级校验）

3.3 传统连续预分配 vs PagedAttention 分页虚拟化

传统朴素推理引擎的致命痛点（显存虚胖）：

PagedAttention（vLLM 核心算法）的破局之道：

3.4 稠密模型 vs MoE 混合专家模型的显存账本分化

MoE 显存架构设计的工业 Trade-off：

4. 计算量（FLOPs）、MFU 与 HFU 工业级算盘

4.1 前向 $2P$ 、反向 $4P$ 、训练 $6P$ 与全重算 $8P$ 的严格矩阵计数

4.2 Attention 二次项修正量：何时不能忽略 $4LS^2d$ ？

临界对比分析：

4.3 MFU（模型算力利用率）vs HFU（硬件算力利用率）

两者的黄金关系：

4.4 为什么大厂集群真实 MFU 往往只有 35%~55%？

5. 全场景实战：编写工业级容量规划与显存诊断脚本

5.1 实验一：原生 PyTorch 动态激活显存峰值与重算打点测试

5.2 实验二：工业级全栈容量规划器 `cluster_capacity_planner.py`

6. Ringi 避坑指南与生产黄金准则

6.1 7 大常见小白认知误区 vs 大厂 AI Infra 正确物理认知

6.2 生产容量工程黄金 Checklist

7. Ringi 5 点核心速记口诀、自我检验清单与课后深度思考题

7.1 5 点押韵核心速记口诀

7.2 10 条白板自我检验清单

7.3 3 道高阶开放式课后思考题（含极限 Corner Case）

8. 📚 参考资料与核心源码/经典论文指引

权威学术论文：

工业级开源源码指引：

本地 AI_BOOK 知识库精准映射：

附录：Appendix A — 大厂硬核高频面试题与白板推导（Interview Drill）

面试真题 1：千卡集群训练 70B 模型，如果不开启张量并行（TP），仅使用纯数据并行 + ZeRO-3，单卡至少需要多大显存？网络通信量会暴涨多少？

考察维度：分布式切分边界、网络通信量手算、大规模集群拓扑常识。

标准推导路径：

面试真题 2：在 8 卡 H100 集群上做 32K 超长上下文推理，为什么开启 FP8 KV Cache 比把模型权重做 INT4 量化对系统吞吐提升更显著？

考察维度：Roofline 瓶颈定位、Decode 阶段访存特征、量化收益归因。

标准参考答案：

面试真题 3：请白板手算在单台 8 卡 A100-80GB 服务器上，训练一个 13B 稠密模型（ $L=40, d=5120, H_q=40$ ），在 Batch=16、SeqLen=2048 时，无重算与选择性重算下的激活值显存差值。

考察维度：激活值精确推导、二次项敏感度评估、工程直觉。

标准推导路径：