第10章：AI 系统优化案例研究

前 4 章把方法论和工具讲完了。这一章换个口吻——讲故事。性能工程不是抽象的”goodput 公式 + cheat sheet”——它是无数工程师在真实硬件、真实模型、真实预算约束下做出的一个个权衡选择。本章选七个 2024-2025 间公开披露的真实案例:从 OpenAI 跨年度训出 GPT-4.5 的协同战、到 DeepSeek 用受限 H800 干出 671B 模型、到 MobileEye 一周让 ViT 训练快一倍、到 AlphaTensor 让 AI 自己发现矩阵乘法新算法 —— 每个案例都按”约束 → 关键决策 → 数字结果 → 给性能工程师的启示”组织,把它们当成一份份工程小传来读。

📑 目录

1. 案例阅读法:看什么、不看什么
2. 案例 A:OpenAI 训 GPT-4.5 —— 跨年度协同战
3. 案例 B:DeepSeek-V3 —— 受限 H800 上的 $5.6M 671B 模型
4. 案例 C:MobileEye FP8 + torch.compile —— 一周省一半训练时间
5. 案例 D:NVIDIA Dynamo —— 推理服务白送的 2× 吞吐
6. 案例 E:vLLM —— PagedAttention 与 continuous batching
7. 案例 F:AlphaTensor —— AI 发现的 GEMM 新算法
8. 案例 G:DeepSeek-R1 自动生成 CUDA kernel
9. 横向对比:七个故事的共同脉络
自我检验清单
参考资料

1. 案例阅读法:看什么、不看什么

性能工程的案例容易被读成”硬件 / 框架 / 算法”的产品广告。正确的阅读方式是把它当成”工程决策的逆向工程”——把当时的约束、可选方案、最终选择、量化结果四件事单独拎出来。

1.1 阅读模板(本章每个案例都套用)

维度	你要在故事里找的答案
约束	团队当时被什么困住?(预算 / 硬件代际 / 时间 / 出口管制 / 人力)
关键决策	在 N 个备选里他们选了什么?为什么没选另外的?
量化结果	数字到底是多少?加速 X×、节省 Y 美元、训练时间从 A 到 B
可迁移启示	抛开他们的具体场景,对一个性能工程师而言最有价值的 1-2 条经验

1.2 不要陷入的三个误区

❌ “他们用 X 框架,所以 X 框架最好”——这是产品营销读法,不是工程读法
❌ “我们集群没那么大,跟我无关”——核心方法论从 8 卡到 80,000 卡都有效
❌ “他们的数字我也能复现”——案例数字依赖他们的具体硬件/模型/数据,你的复现可能差 30%。重要的是决策路径,不是绝对数字

⭕ 阅读节奏:每个案例先看 30 秒”约束 + 决策 + 结果”,感兴趣再看背景细节。

2. 案例 A:OpenAI 训 GPT-4.5 —— 跨年度协同战

2.1 约束

期望 比 GPT-4 强 10× 的下一代模型
项目周期接近 2 年(从筹备到训练上线)
全新一代计算集群——硬件本身还没踩熟
ML 团队和 infra 团队历史上分别工作,这个项目要求他们深度协同

2.2 关键决策

早期投入大量 de-risking 实验:在新集群跑小规模”模拟训练”,在真正烧钱跑全量训练前把基础设施稳定性验证一遍
跨团队联合 oncall:训练过程中 ML 研究员和 infra 工程师同步排查任何故障——故障来源可能是某个稀有 code path 触发了 sum() 这种”原本以为完全可靠”的函数 bug
Scaling laws 与 infra 设计反向耦合:模型架构和训练目标的选择直接影响多集群编排和网络可靠性需求,反之亦然

2.3 量化结果

早期阶段故障率高——硬件、网络、罕见软件 bug 三种来源叠加
通过持续监控 + 跨团队协作,问题逐步收敛
最终成为”超大规模训练的 blueprint”——不仅交付了模型,更产出了下一代训练的工程方法论

2.4 给性能工程师的启示

🌟 核心启示:超大规模训练的瓶颈不在 FLOPs,在跨团队信息流动。一个 ML researcher 提出的”scaling law”假设,会反向决定 infra 团队需要支持多大的 cluster size、什么样的 checkpoint 频率、什么样的网络可用性 SLA。

🍎 给小团队的对应版本:即使你只有 8 卡 + 1 个研究员 + 1 个 infra 工程师,让两人同坐 oncall——比”研究员提需求 → infra 工程师实现”的瀑布流快得多。

3. 案例 B:DeepSeek-V3 —— 受限 H800 上的 $5.6M 671B 模型

3.1 约束

受美国出口管制,只能用 NVIDIA 的 H800(H100 的”阉割版”:显著降低的内存带宽 + 更慢的 NVLink)
训练目标:671B 参数的 MoE 模型,对标 GPT-4 级别能力
团队规模 / 预算都远小于美西大厂

3.2 关键决策

决策	内容	解决什么
用 MoE,只激活 37B/671B	64 个 expert,每 token 路由到几个 expert	计算量受控、显存压力小
自研 DualPipe 流水线并行	把通信和计算严格 overlap,把 H800 慢的通信隐藏	抵消 H800 NVLink 慢的硬伤
自写 CUDA kernel 绕过部分默认 NCCL collective	自定义 All-to-All 路由(后来开源为 DeepEP)	进一步压低通信占比
FP8 训练	Hopper Transformer Engine + 自定义 scaling	把算力翻倍、显存压力降一半

🧠 核心洞察:通信带宽被卡死时,你的优化重心就从”算得更快”变成”通信塞进计算里”。DeepSeek 把所有通信和计算的 overlap 做到极致。

3.3 量化结果

训练成本估算 ~$5.6M(GPU time)——同期同等能力闭源模型动辄数千万到上亿美元
DeepSeek-V3 在多项 benchmark 上追平甚至超过 GPT-4
后续基于 V3 训出 R1 推理模型,质量逼近 OpenAI O1
2025 年 2 月开源 FlashMLA / DeepGEMM / DeepEP / 3FS 全套 infra,让全行业受益

3.4 给性能工程师的启示

🌟 核心启示:硬件约束不是你的敌人,是你的过滤器。它强制你放弃一切”算力够就能解决的方案”,逼你去发明那些在不受限的环境里也是更优的算法和系统设计。事实上 DeepSeek 的 MLA、DualPipe、DeepGEMM 在不受限的 H100 上也比默认实现更快。

📍 可立刻借鉴的具体技术:

大模型训练 → 看 DualPipe(模块三第 6 章会展开)
MoE 路由通信 → 看 DeepEP 源码
FP8 GEMM 实现 → 看 DeepGEMM(对照模块二第 4 章 GEMM 章节)

4. 案例 C:MobileEye FP8 + torch.compile —— 一周省一半训练时间

4.1 约束

MobileEye 自动驾驶团队训练 Vision Transformer (ViT) 模型
已有 PyTorch + bfloat16 训练 pipeline,跑在 NVIDIA H100 上
想用上 Hopper 新出的 FP8 Tensor Core + Transformer Engine——但不能花几个月重写 pipeline

4.2 关键决策路径(踩坑顺序很重要)

步骤	配置	结果	原因
1. baseline	bfloat16,batch=16	23.12 samples/s	基准线
2. 加 torch.compile	bfloat16 + torch.compile,batch=16	24.92 samples/s(+8%)	编译器自动 fuse 一些算子
3. 直接换 FP8	FP8,batch=16	17.88 samples/s(−23%!)	慢了——FP8 算子覆盖不全,scale 转换 overhead 大
4. FP8 + 加大 batch	FP8,batch=32	18.82 samples/s(−19%)	还是慢
5. FP8 + torch.compile + batch=32	全开	34.01 samples/s(+47%)	赢家

🧠 关键洞察:FP8 单独开会变慢——它需要 torch.compile 帮忙做 kernel fusion 才能把 FP8 的算力优势真正释放出来。如果在第 3 步就放弃,会错过 47% 的加速。

4.3 量化结果

单步训练时间几乎减半(0.692s → 0.941s 看起来变长,但 batch 翻倍后 effective throughput +47%)
整体训练时间~减少一半
工程投入:几周的实验和调参,无需算法层改动

4.4 给性能工程师的启示

🌟 核心启示:新 GPU 特性(FP8、FP4、Tensor Core 新指令)单独开往往不快——需要编译器层(torch.compile / Inductor)和 batch size 一起调到位。这是 hardware-software co-design 的微观表现。

📍 方法论模板:每次 NVIDIA 出新 GPU,做这套实验:

baseline (老精度)
baseline + torch.compile
新精度 (默认 batch)——可能变慢,别慌
新精度 + 大 batch
新精度 + 大 batch + torch.compile

把表格做出来再下结论。

5. 案例 D:NVIDIA Dynamo —— 推理服务白送的 2× 吞吐

5.1 约束

团队已有部署:Llama 模型,Hopper H100 集群,自己写的 request scheduling 代码
想要更高吞吐,但不想买更多 GPU——上一代基础设施还在折旧周期
服务延迟敏感(交互式 LLM 应用)

5.2 关键决策

把请求调度从自研代码换成 NVIDIA Dynamo(开源,2025)。

Dynamo 做了三件你自己难做好的事:

动态 batching:请求来一个就立即评估能否合并到正在跑的 batch 里,不等固定窗口
GPU 间负载均衡:动态调整 prefill 和 decode 在哪些 GPU 上跑
PD 解耦推理(disaggregated inference):prefill(memory-intensive)和 decode(compute-intensive)分开放在不同 GPU 上,各自最优配置

传统 serving:                          PD 解耦:
[GPU0: prefill+decode]                  [GPU0: prefill]──KV──→[GPU3: decode]
[GPU1: prefill+decode]                  [GPU1: prefill]──KV──→[GPU4: decode]
[GPU2: prefill+decode]                  [GPU2: prefill]──KV──→[GPU5: decode]
                ↑                                    ↑
        每张 GPU 同时做两种                  prefill 和 decode 各自最优
        谁也不最优                          硬件 + 软件配置

5.3 量化结果

2× 吞吐——同样的 GPU,服务能力翻倍
等价于”零成本扩容”:同样数量的卡能服务一倍用户

5.4 给性能工程师的启示

🌟 核心启示:调度层和推理引擎层是分离的”两本账”。再快的 vLLM/TensorRT-LLM 引擎,如果上面跑着糟糕的请求调度,goodput 就上不去。

📍 决策树(给推理服务):

单引擎 + 单卡 → vLLM / TensorRT-LLM 直接跑
多引擎 + 多卡 → 加上 Dynamo 这层,负责 routing / batching / PD 解耦
多引擎 + 多机 + 长上下文 → Dynamo + NIXL(KV-Cache 跨节点搬运,见第 4 章)

⭕ 互补:Dynamo 不取代 vLLM,Dynamo 用 vLLM 当 backend——它是”集群级编排”,vLLM 是”单引擎效率”。

6. 案例 E:vLLM —— PagedAttention 与 continuous batching

6.1 约束

UC Berkeley 团队的观察:LLM 推理服务在生产中GPU 经常空转——不是算力不够,是显存碎片和调度策略让 GPU 等在那里。

6.2 关键决策(两个核心创新)

PagedAttention

把 GPU 显存里的 KV-Cache 当成虚拟内存来管理:分页、动态分配、避免预留固定大块。

传统 KV-Cache:                          PagedAttention:
[ Request A: ████████____ ]             [Block1][Block2][Block3]
              预留过多,30% 浪费            ↑       ↑       ↑
                                       每个请求按需分配 page
[ Request B: ████____    ]
              短请求也要占大块             释放后立即可被其他请求复用

🍎 直觉比喻:像 OS 的 paging 那样管理 GPU 显存——什么时候用什么时候分,显存利用率从 60% 涨到 90%+。

Continuous Batching

不等一批请求”凑齐”再发,新请求一来立刻插入正在跑的 batch;请求结束立刻让出 batch slot。

静态 batching:                         continuous batching:
[ ████████ ]                           [ ████████████ ]
[ ██       ](等齐)                    [ ██▓▓▓▓     ]  (新请求立刻塞入)
[ ████     ]                           [ ████░░     ]
                                                  ↑
                                       请求 A 结束,B 立刻填进来

6.3 量化结果

吞吐 23×(对比传统 serving)——基于 vLLM 团队公开数据
显存利用率 +30-40%
项目大量被生产采用、被 Dynamo 选作官方 backend、扩展到 NVIDIA 之外的多种加速器

6.4 给性能工程师的启示

🌟 核心启示:LLM 推理的瓶颈往往不是 FLOPs,是请求/显存调度。FlashAttention 之外,vLLM 是另一个**“重写算法/调度,不动硬件”**就拿到 10× 改进的范例——和模块零第 1 章 Mechanical Sympathy 的精神高度一致。

📍 关键 takeaway:做推理服务,不要自己手搓请求调度。除非你能投入 1-2 个全职工程师做半年,否则用 vLLM/TensorRT-LLM 现成的方案基本能拿到大头收益。

7. 案例 F:AlphaTensor —— AI 发现的 GEMM 新算法

7.1 约束

DeepMind 的研究问题:矩阵乘法(GEMM)是 AI 训练 / 推理最核心的数学操作。Strassen 1969 年发现 2×2 矩阵可用 7 次乘法替代 8 次,之后 50+ 年人类几乎没有显著突破
想用 AI 自己搜索更快的 GEMM 算法

7.2 关键决策

把”找快速 GEMM”形式化成一个单人棋类游戏
用强化学习(RL)在巨大解空间里搜索

7.3 量化结果

重新发现了 Strassen 的 2×2 算法
对更大的矩阵找到了人类此前未发现的更快算法
在 NVIDIA Volta V100 上,实测某些矩阵尺寸下比当时标准 GPU 库快 10-20%

7.4 给性能工程师的启示

🌟 核心启示:最基础的运算还有优化空间。你以为 GEMM 已经被 cuBLAS / CUTLASS 优化到极致——AlphaTensor 证明人类的搜索盲区是 AI 的甜点。

🧠 更大的图景:在 GPU 库里替换掉一个 10-20% 更快的 GEMM 算法,对所有训练 / 推理工作负载都有立刻的加速——这是杠杆最高的优化。

📍 对个人工程师的可借鉴动作:

你不会真的去用 RL 找新 GEMM 算法
但你会用 LLM(尤其是 reasoning model)做局部 kernel 优化——这正是下一个案例

8. 案例 G:DeepSeek-R1 自动生成 CUDA kernel

8.1 约束

任务:为 Transformer Attention 写一个高性能 CUDA kernel
通常这是”CUDA Ninja”(资深 GPU 工程师)的活,人类专家几个月
NVIDIA 团队的实验:能不能让 reasoning LLM 自动做这事

8.2 关键决策

用 DeepSeek-R1(reasoning 模型,inference-time scaling 让它能”想得更久”)
在 H100 上给它 15 分钟生成 kernel
加一个 verifier loop:R1 出 kernel → verifier 检查正确性 + 测性能 → 反馈给 R1 改进 prompt → R1 再出新 kernel → 循环直到达标

                ┌──────────────┐
   初始 prompt → │  DeepSeek-R1 │ → kernel 代码
                └──────┬───────┘            │
                       │                    ▼
                       │             ┌──────────────┐
                       │             │   Verifier    │
                       │             │ (正确? 性能?) │
                       │             └──────┬───────┘
                       │                    │ 反馈
                       └────────refine prompt─────────┘

8.3 量化结果

生成的 kernel 达到甚至超过专家手写实现的某些性能水平
时间投入:15 分钟自动循环 vs 数月的专家工作

8.4 给性能工程师的启示

🌟 核心启示:“AI 写 CUDA kernel” 在 2025 年是真实可用的。这不是替代 CUDA Ninja,是让 CUDA Ninja 的产能放大 10-100×——专家定义 spec 和 verifier,让 reasoning LLM 跑搜索循环。

📍 可以马上动手的工程模板(伪代码):

def auto_kernel_search(spec, verifier, budget_minutes=15):
    """让 reasoning LLM 在循环里写 + 改 + 验证 kernel"""
    prompt = initial_prompt_from(spec)
    best_kernel = None
    deadline = now() + budget_minutes * 60

    while now() < deadline:
        kernel = reasoning_llm.generate(prompt)
        result = verifier.evaluate(kernel)   # 正确性 + 性能
        if result.is_valid and result.is_faster_than(best_kernel):
            best_kernel = kernel
        prompt = refine_prompt(prompt, result)  # 把失败原因塞回去

    return best_kernel

⭕ 互补:这种循环目前不能完全替代人——它最适合 well-defined、小作用域的 kernel(单个算子的 fused 实现)。复杂跨算子优化、多 kernel 协作的优化还要靠人。

9. 横向对比:七个故事的共同脉络

把七个案例按”约束 / 武器 / 收益”放在一张表上看:

案例	主要约束	关键武器	量化收益
GPT-4.5	跨年度大规模 + 全新硬件	跨团队协同 + 早期 de-risking	训练完成 + blueprint
DeepSeek-V3	受限 H800 通信带宽	DualPipe + 自定义 kernel + FP8 + MoE	$5.6M 训出 671B
MobileEye	想用 H100 新精度但不重写	torch.compile + FP8 + 调 batch	训练快 47-50%
Dynamo	已有 GPU 想要更多吞吐	动态 batching + PD 解耦	推理 2× 吞吐
vLLM	LLM 推理 GPU 空转	PagedAttention + continuous batching	显存 +30%、吞吐 23×
AlphaTensor	50 年没人优化的 GEMM	RL 搜索新算法	GEMM 10-20% 加速
DeepSeek-R1 写 kernel	CUDA Ninja 太贵	Reasoning LLM + verifier loop	15 分钟达专家水平

9.1 三条共同的线

🌟 第一条:最大的收益往往不来自”换更贵的 GPU”,而来自”重新设计软件层”——七个案例里有 6 个的核心创新在软件 / 算法层。

🌟 第二条:硬件-软件 co-design 是杠杆。不只是 NVIDIA 设计芯片时考虑算法(co-design 第一面),也是工程师选用算法时贴着硬件特性写(第二面,Mechanical Sympathy)。

🌟 第三条:AI 自身正在成为性能工程师的工具——AlphaTensor 找算法、DeepSeek-R1 写 kernel,这是 2024-2025 的新维度。未来的性能工程师 = 人 + AI tool 的循环。

9.2 给”我现在该怎么做”的具体建议

你的处境	优先看哪个案例	立即行动
团队大、模型大、预算大	GPT-4.5、DeepSeek-V3	跨团队 oncall + de-risking 实验
老 GPU 想用上新精度	MobileEye	跑 baseline / compile / FP8 / batch 五组实验
推理服务 GPU 空转	Dynamo + vLLM	上 vLLM,再考虑 Dynamo
想 squeeze kernel 性能	AlphaTensor、DeepSeek-R1 写 kernel	给 LLM 一个 spec + verifier 试一试

AI Systems Performance Engineering: Optimizing Hardware, Software, and Algorithms for Efficient Training and Inference —— Chris Fregly, O’Reilly Media, 2025 (Early Release):learning.oreilly.com —— 本章七个案例的事实来源,Ch10 案例研究

案例原始资料

OpenAI GPT-4.5 Training Journey —— 多份 OpenAI 公开播客 / 博客整理
DeepSeek-V3 Technical Report:arXiv 2412.19437 —— DualPipe / FP8 / MLA 的官方说明
DeepSeek-R1 Technical Report:arXiv 2501.12948
DeepSeek Open-Source Week 2025:github.com/deepseek-ai —— FlashMLA / DeepGEMM / DeepEP / 3FS 仓库集合
MobileEye PyTorch Native FP8 Data Types(Chaim Rand, TDS):FP8 + torch.compile 47% 加速详细记录
NVIDIA Dynamo 介绍:developer.nvidia.com/blog/introducing-nvidia-dynamo
vLLM PagedAttention Paper (SOSP 2023):arxiv.org/abs/2309.06180
AlphaTensor (DeepMind, 2022):deepmind.google/discover/blog/discovering-novel-algorithms-with-alphatensor —— Nature 论文链接
NVIDIA Automating GPU Kernel Generation with DeepSeek-R1:developer.nvidia.com/blog