📑 本页目录（点开跳转）
01 · AI Infra 在解决什么问题
⏱ 22 分钟 ｜ ⭐ 先看清战场
🎯 一句话
模型的数学是完美的，硬件是有限的。AI Infra 就是这条鸿沟里的全部工程。 而这条鸿沟有多宽，可以用一个数字概括：大部分人的 GPU，实际只发挥了 20–40% 的性能。
😱 一、四个让人不舒服的事实
事实 ① 你的 GPU 大概率在摸鱼
关键信息
- A100 标称算力：312 TFLOPS（BF16）
- 而实际训练中的 MFU（模型算力利用率）：
- 未经优化的朴素实现 10 ~ 20% 💀
- 用了主流框架的默认配置 30 ~ 40%
- 认真优化过的 45 ~ 55%
- 顶级团队的大模型训练 55 ~ 60% ⭐ 这已经是天花板附近
- ⚠️ 也就是说：【一半以上的钱是浪费的】，而且这还是优化之后
🔑 第一个反直觉：60% 就是优秀。 不是因为工程师不行，而是因为存在物理上无法消除的开销（下面会讲）。 知道这个基准，你才不会在 55% 的时候还在盲目优化。
事实 ② 算力涨得比带宽快得多
关键信息
对照
一个具体的对照（A100 量级）：
做一次 FP16 乘加 ≈ 极快，几乎免费
从 HBM 读一个数 ≈ 比它慢【两个数量级以上】
从另一张卡读 ≈ 再慢一个数量级
从另一台机器读 ≈ 再慢一个数量级
🔑 这是整个领域最重要的一句话： 现代 GPU 优化的主线不是"少算点"，而是"少搬点"。 FlashAttention、算子融合、量化、KV Cache 优化 —— 全都是这一句的推论。
事实 ③ 显存是最硬的墙
算一算
训练一个 7B 模型（BF16）到底要多少显存？
模型参数 7B × 2 字节 = 14 GB
梯度 7B × 2 字节 = 14 GB
Adam 优化器状态 7B × 8 字节 = 56 GB ⭐ 最大的一块！
（FP32 的 m、v，各 4 字节）
激活值 取决于 batch 和序列长度，几 GB ~ 几十 GB
合计 ≥ 84 GB + 激活
→ 一张 80GB 的 A100【装不下一个 7B 模型的训练】💀
💡 注意优化器状态是最大的一块 —— 这就是 ZeRO 存在的理由。 它不优化计算，它只是把这 56GB 切开分给多张卡。
事实 ④ 推理的账和训练完全不一样
关键信息
🗺️ 二、这个领域的地图
- · 并行策略（数据/张量/流水线/专家）
- · 显存管理（ZeRO / 检查点 / 量化）
- · 计算优化（融合 / FlashAttention / 编译）
- · 推理引擎（KV Cache / 连续批处理 / 调度）
- · 通信（NCCL / AllReduce / 拓扑）
四个核心矛盾，整套教程都在处理它们：
| 矛盾 | 表现 | 对应章节 |
|---|---|---|
| 算力 vs 带宽 | 算得快但喂不饱 | 03、04、08 |
| 显存容量 vs 模型大小 | 装不下 | 09、11、18 |
| 并行度 vs 通信开销 | 卡越多效率越低 | 10–14 |
| 吞吐 vs 延迟 | 快和多不可兼得 | 17、20 |
💰 三、一笔具体的账（这个领域为什么值钱）
关键信息
- 假设你要服务一个 70B 模型，日均 1000 万次请求
- 朴素部署（HuggingFace transformers + 循环生成）：
- 吞吐低、显存浪费严重
- 需要约 100 张 A100 ≈ 每月 200 万元
- 优化后（vLLM + INT8 量化 + 连续批处理 + 张量并行）：
- KV Cache 显存利用率从 ~30% 提到 >90%（第 17 章）
- 权重显存减半（第 18 章）
- 需要约 15 张 A100 ≈ 每月 30 万元
- ⭐ 差距接近 7 倍 —— 这就是这个领域的价值
💡 这些数字是量级示意，不是精确基准（实际取决于序列长度、并发模式、SLO 要求）。 但"优化前后差一个数量级"这件事是真实且常见的。
🧠 四、这个领域的思维方式
⭐ 第一性原理：算一算它的理论下界
结果对照
一个例子：
算一算
问题："我的 attention 好慢"
算一下（序列长度 n=4096，头维度 d=128）：
计算量 ≈ 2 × 2 × n² × d = 8.6 GFLOP
数据量 ≈ 中间矩阵 n² × 2 字节 = 33.5 MB（还要读写多次）
算术强度 = 8.6e9 / 33.5e6 ≈ 256 FLOP/字节 · 看起来够高？
⚠️ 但标准实现会【把 n² 的中间矩阵写回 HBM 再读出来】好几次
→ 实际数据量翻好几倍，算术强度暴跌
→ 变成【带宽瓶颈】
⭐ 这就是 FlashAttention 要解决的问题（第 8 章）
⚠️ 反面：三个常见的错误直觉
| ❌ 错误直觉 | ✅ 实际情况 |
|---|---|
| "换更强的卡就快了" | 如果瓶颈是带宽或通信，算力翻倍可能一点用没有 |
| "多加几张卡就能线性加速" | 通信开销会吃掉收益，卡越多效率越低 |
| "OOM 就调小 batch" | 可能只是显存碎片或没开梯度检查点，调小 batch 会让 MFU 更差 |
🔗 和站内其他章的关系
| 相关的地方 | 这里的位置 |
|---|---|
| ML 基础第 8 章 反向传播要缓存激活 | 这就是激活显存的来源 ⭐ |
| ML 基础第 9 章 Adam 有 m、v 两个状态 | 优化器状态占 56GB 的原因 |
| 全景导论主线 2 · 模型怎样看懂一句话 attention 是 O(n²) | 带宽瓶颈的主要来源 |
| 数学原理第 12 章 | 梯度检查点的理论依据 |
✅ 检查点
- 实际训练中 MFU 的典型范围是多少？多少算优秀？
- 过去 20 年算力和带宽的增长差了多少？这导致了什么后果？
- 训练 7B 模型要多少显存？哪一块最大？为什么？
- 为什么说长期看推理成本会超过训练成本？
- 这个领域的四个核心矛盾是什么？
- 拿到性能问题该先问哪三个问题？
- 三个常见的错误直觉分别错在哪？
👀 答案
- 朴素实现 10–20%，框架默认 30–40%，认真优化 45–55%，顶级团队 55–60% 就是天花板附近。知道这个基准才不会在 55% 时还盲目优化。
- 算力涨约 1000 倍，带宽只涨约 30 倍，差一个数量级以上。后果：计算越来越便宜，搬数据越来越贵 → 优化的主线不是"少算点"而是"少搬点"。
- ≥84GB + 激活。最大的是 Adam 优化器状态 56GB（7B × 8 字节，FP32 的 m 和 v 各 4 字节）。这就是 ZeRO 存在的理由——它不优化计算，只是把这块切开分给多卡。
- 因为训练是一次性投入，推理是每个请求都在烧钱且永不停止，还会随用户增长。
- ①算力 vs 带宽 ②显存容量 vs 模型大小 ③并行度 vs 通信开销 ④吞吐 vs 延迟。
- ①理论上需要多少次浮点运算 ②至少要搬多少字节 ③按硬件算力和带宽理论最快多久。然后和实测对比，差距在哪答案就在哪。
- ①"换更强的卡"——瓶颈是带宽或通信时算力翻倍没用 ②"多加卡线性加速"——通信开销会吃掉收益，卡越多效率越低 ③"OOM 就调小 batch"——可能是显存碎片或没开梯度检查点，调小 batch 反而让 MFU 更差。
🛑 可以停在这里
⚡ 走神救援
先记住这几件事
- 模型能算出来，不等于硬件能高效运行；算力、带宽、容量和通信分别约束性能。
- 先估算计算量、搬运量与资源下界，再与实测对照。
- 训练和推理的瓶颈不同；换卡、加卡或减 batch 前先确认限制来自哪里。
下一节 👉 02-GPU到底是什么.md