4、最大大小调优：防止OOM的关键、与系统显存的关系、动态扩展机制

聊到显存池的最大大小，这其实是个挺有意思的话题。我见过不少团队，一开始觉得“显存嘛，有多少用多少”，结果线上频繁 OOM，搞得焦头烂额。说白了，最大大小这个参数，就是给显存池画的一条红线——你不能越界。

4.1 为什么最大大小是防止 OOM 的第一道防线？

显存池的本质是预分配。你想想看，如果池子没有上限，它会一直向系统申请显存。遇到突发流量或者模型加载失误，显存瞬间爆掉。嗯，这里要注意：OOM 不只是进程崩溃那么简单，它可能拖垮整个 GPU 节点，影响其他任务。

我个人习惯把最大大小设置为物理显存的 80%-90%。为什么留余量？因为系统本身也要用显存——驱动、CUDA 上下文、小张量临时分配，这些都不走池子。我曾经在项目里设了 95%，结果驱动报了个奇怪的错误，排查了半天才发现是显存碎片导致的。

4.2 与系统显存的关系：别把池子当全部

系统显存是有限的资源。你的池子再大，也不能超过物理上限。这里有个常见的误区：很多人以为池子最大大小设成 24GB，就能用满 24GB 的卡。其实不是的。

我建议你记住这个公式：

可用显存 = 物理显存 - 系统预留 - 其他进程占用
池子最大大小 ≤ 可用显存 × 安全系数（0.85-0.95）

举个例子，一张 24GB 的卡，系统预留大概 1-2GB，其他进程可能占 1GB，那实际可用的也就 21GB 左右。池子设成 20GB 比较稳妥。

物理显存	系统预留	其他占用	建议最大大小
24 GB	1.5 GB	0.5 GB	20 GB
32 GB	2 GB	1 GB	27 GB
80 GB	4 GB	2 GB	70 GB

4.3 动态扩展机制：池子不是死的

很多人以为池子的大小是固定的，其实不是。现代显存池支持动态扩展——当池子里的显存不够用时，它可以向系统申请新的块，只要不超过最大大小就行。

这个机制的好处很明显：

• 按需分配：一开始池子可以很小，比如只占 2GB。随着任务变重，慢慢扩展到 10GB、20GB。
• 避免浪费：如果任务只需要 5GB，池子不会傻乎乎地占满 20GB。
• 平滑扩容：扩展是逐块进行的，不会一次性申请大块显存导致卡顿。

我建议你关注两个关键参数：

初始大小：池子启动时预分配的显存量
扩展步长：每次不够用时，新增的显存块大小

举个例子，初始大小设 2GB，扩展步长设 1GB。任务需要 3.5GB 时，池子会先扩展一次到 3GB，发现还不够，再扩展一次到 4GB。这样既不会一开始就占满，也不会频繁扩展影响性能。

4.4 动态扩展的触发条件与回缩

动态扩展不是无条件的。池子内部会维护一个水位线：

• 低水位：空闲显存 > 20% 最大大小，不触发扩展
• 中水位：空闲显存 < 20%，开始准备扩展
• 高水位：空闲显存 < 5%，立即扩展

你想想看，如果每次分配都触发扩展，那池子就失去了缓存的意义。所以扩展是“懒加载”的——不到万不得已，不扩展。

另外，池子也支持回缩。当任务结束、显存释放后，空闲显存超过某个阈值（比如 30%），池子会把多余的块归还给系统。这个机制很重要，不然池子只会越来越大，永远不会变小。

4.5 实战调优建议

说了这么多，到底怎么调？我总结几条经验：

1. 先测后调：用 nvidia-smi 监控显存使用曲线，看看峰值是多少。池子最大大小设成峰值的 1.1 倍。
2. 留足余量：系统预留 + 其他进程，至少留 2GB 的缓冲空间。
3. 步长适中：扩展步长 = 最大大小的 5%-10%。比如最大 20GB，步长 1-2GB。
4. 开启回缩：如果框架支持，一定要开启显存回缩。不然池子只会膨胀，不会收缩。
5. 监控水位：定期打印池子的水位信息，看看是否频繁触发扩展。如果扩展次数太多，说明初始大小设小了。

4.6 知识体系图

下面这张图展示了最大大小调优的核心逻辑：

这张图把整个逻辑串起来了。从物理显存出发，减去系统预留和其他进程占用，得到可用显存。再乘以安全系数，就是池子最大大小。然后通过动态扩展和回缩机制，让池子灵活应对各种场景。最终目标就两个：防止 OOM，高效利用显存。

好了，关于最大大小调优，核心就是这些。记住一句话：池子再大，也不能超过物理显存；池子再小，也要留足余量。 下次遇到 OOM，先检查一下最大大小设得合不合理。