1、显存溢出基础：什么是显存溢出（OOM）
显存溢出，英文叫 Out of Memory，简称 OOM。说白了就是——你的 GPU 显存放不下数据了。
我刚开始接触深度学习时，觉得显存这东西就像硬盘，用不完。直到第一次跑一个 70B 的大模型，看着终端里那个红色的 "CUDA out of memory" 弹出来，我才意识到：显存其实很金贵。
你想想看，GPU 显存是有限的。一张 A100 80G，看着挺大对吧？但如果你加载一个 13B 的模型，再加上 batch size 设成 32，优化器状态、梯度、中间激活值……分分钟爆掉。我有个项目，训练一个多模态模型，batch size 从 8 调到 4 才勉强跑起来。嗯，这就是典型的 OOM。
OOM 的典型表现
OOM 不是突然就炸的。它有几个明显的信号：
- 训练中断：跑着跑着，终端弹出 "CUDA out of memory"，训练直接挂掉。我遇到过最惨的一次，跑了 12 个小时，第 13 个小时 OOM 了，checkpoint 还没保存……
- 推理卡死：模型推理时，显存不够，程序直接崩溃。或者更隐蔽的——推理速度突然变慢，因为 GPU 开始用 CPU 内存做 swap。
- 显存泄漏：每次迭代显存占用都在涨，直到爆掉。我曾经排查过一个模型，发现是某个层的梯度没释放，每次 forward 都多占 200MB。
- 多卡训练时某张卡先爆：分布式训练中，数据分配不均匀，某张卡的显存先撑不住。我调试过一个项目，就是因为 DataLoader 的 shuffle 没做好，导致一张卡多处理了 20% 的数据。
⚠️ 注意：OOM 不一定是显存真的不够。有时候是代码里有显存泄漏，或者某个操作临时申请了超大显存。我曾经遇到一个 case，一个简单的 reshape 操作，因为维度计算错误，申请了 200GB 的显存……嗯，那肯定爆。
OOM 对训练/推理的影响
OOM 的影响，不只是「程序崩了」这么简单。我总结了几点：
| 场景 | 影响 | 我的经验 |
|---|---|---|
| 训练 | 训练中断，浪费算力 | 有一次训练跑了 3 天，第 3 天 OOM，之前的结果全废了。后来我养成了每 10 分钟存一次 checkpoint 的习惯。 |
| 训练 | 被迫减小 batch size，影响收敛 | batch size 从 64 降到 8，模型收敛速度明显变慢。我试过用梯度累积来弥补，但效果还是差一些。 |
| 推理 | 服务不可用，用户体验差 | 线上推理服务 OOM，直接导致用户请求失败。我经历过一次，大半夜被叫起来排查…… |
| 推理 | 推理延迟飙升 | 显存不够时，GPU 会频繁和 CPU 交换数据，推理时间从 100ms 变成 2s。用户反馈说「卡死了」。 |
| 开发调试 | 无法快速迭代 | 每次改个参数都要等 10 分钟才知道 OOM 没，开发效率极低。我后来写了个显存预估脚本，先算一下再跑。 |
为什么会这样？说白了，显存是 GPU 的「工作台」。工作台不够大，你就没法同时放太多东西。训练时，模型参数、梯度、优化器状态、中间激活值，全都要占显存。推理时，模型参数和中间结果也要占。
我个人的习惯是：在开始训练或部署前，先估算一下显存需求。比如一个 7B 的模型，FP16 下参数占 14GB，梯度占 14GB，优化器状态（Adam）占 28GB，再加上激活值……嗯，一张 80G 的卡其实挺紧张的。
💡 小技巧：可以用
torch.cuda.memory_summary() 查看显存分配情况。我每次排查 OOM 时，第一件事就是看这个输出。它能告诉你每个 tensor 占了多少显存，哪个操作最吃显存。
知识体系：显存溢出核心逻辑
下面这张图，是我自己总结的显存溢出排查思路。你可以把它当成一个「决策树」：
这张图的核心逻辑是：先判断是训练还是推理场景，然后根据具体原因选择对应的优化手段。我每次遇到 OOM，都会按这个思路走一遍，基本能定位到问题。
🔑 核心要点：
- OOM 的本质是显存需求 > 显存容量
- 训练场景下，batch size、激活值、优化器状态是三大显存杀手
- 推理场景下，模型大小、KV Cache、并发数是主要瓶颈
- 排查 OOM 时，先看
torch.cuda.memory_summary()，再对症下药
嗯，这一章就到这里。记住：OOM 不是 bug，是资源管理问题。理解了它，你就能更好地驾驭 GPU。