1. 显存溢出概述：什么是OOM？
大家好，我是你们这堂课的主讲。咱们直接开门见山——显存溢出，圈里人通常叫它OOM（Out of Memory）。
说白了，就是你的GPU显存不够用了。你想想看，模型参数、梯度、优化器状态、中间激活值……这些东西全都要塞进显存里。一旦总需求超过了硬件上限，系统就会直接罢工。
核心定义：OOM是指深度学习任务在运行时，向GPU申请显存资源失败，导致进程被强制终止的现象。
1.1 我遇到过的典型OOM场景
我记得刚入行那会儿，调一个BERT-large模型，batch size设了32，心想“这卡可是24G的，够用了吧？”结果跑了不到两个step，直接崩了。当时我还纳闷，怎么显存说爆就爆？
后来才明白，显存消耗不是线性的。你加一个层，可能就多占好几G。尤其是Transformer结构，中间激活值占用的显存，往往比模型参数本身还大。
1.2 OOM的典型表现
OOM来了，它不会跟你打招呼。常见的表现有这几种：
- 直接报错：PyTorch会抛出
CUDA out of memory，TensorFlow则是ResourceExhaustedError。这是最直接的信号。 - 训练卡死：有时候不报错，就是GPU利用率突然掉到0%，进程挂在那不动了。嗯，这种情况更让人头疼。
- 显存泄漏：跑第一个epoch没事，第二个epoch显存涨一点，第三个再涨一点……直到某个时刻突然爆掉。我曾经排查过一个模型，发现是DataLoader里有个变量没释放，每次迭代都偷偷占着显存不走。
避坑指南：我曾经遇到过一个情况，代码里用了 .cuda() 但忘记 .detach()，结果计算图越积越大，显存像漏水的桶一样慢慢流干。这种隐性OOM最难定位。
1.3 OOM对训练和推理的影响
影响？说白了就是两个字——中断。
| 场景 | 影响 |
|---|---|
| 训练阶段 | 训练进程直接崩溃，之前跑了几小时的checkpoint可能没保存，全白干。如果是分布式训练，一个节点OOM可能导致整个集群任务失败。 |
| 推理阶段 | 线上服务直接挂掉，用户请求失败。我见过一个推荐系统，因为batch size设太大，高峰期显存爆了，导致半小时内所有推荐请求都返回空结果。 |
| 调试阶段 | 你刚改完代码想跑个测试，结果OOM了。反复调batch size、清缓存，浪费大量时间。 |
个人经验：我建议你在训练脚本里加上显存监控，比如用 nvidia-smi 或者 torch.cuda.memory_summary()。这样OOM之前你能看到显存曲线在往上飙，提前做调整。
1.4 课程目标与学习路径
这门课的目标很明确：让你从“遇到OOM就慌”变成“看到OOM就知道怎么修”。
我们会系统性地讲清楚：
- 显存到底被谁吃了？——参数、梯度、激活值、优化器状态，每一块怎么算。
- 怎么定位OOM？——用工具看、用代码测、用日志查。
- 怎么解决？——从调batch size、梯度检查点、混合精度，到模型并行、流水线并行，各种手段我都会讲。
我个人习惯把OOM问题分成三类：显存不够用（硬件瓶颈）、显存浪费（代码问题）、显存泄漏（资源未释放）。每一类都有对应的排查思路和解决方案。
下面这张图，是我自己总结的OOM知识体系，你可以先有个整体印象：
这张图把OOM的三大成因和对应的解决方向都串起来了。后面的课程，我们会逐一深入每个分支。你不用担心一次性记不住，跟着节奏走就行。
好，第一章就到这里。记住一句话：OOM不是玄学，它是有迹可循的工程问题。我们后面慢慢拆解。
想要更多资料，联系可可