2. 显存分配与释放的痛点：频繁cudaMalloc/cudaFree的开销、内存碎片化问题、显存泄漏风险
各位同学，咱们今天聊点实在的。显存管理这事儿，说白了就是跟GPU内存打交道。你想想看，每次跑模型都要跟显存较劲，是不是挺头疼的？我在项目中遇到过不少次，明明模型不大，显存却莫名其妙爆了。今天我就把这三个核心痛点掰开揉碎了讲清楚。
2.1 频繁cudaMalloc/cudaFree的开销
先说说最直观的问题——频繁分配和释放显存。很多人觉得，用cudaMalloc分配一块显存，用完再cudaFree释放掉，这不是天经地义吗？嗯，理论上没错，但实际跑起来你就知道有多慢了。
我做过一个测试：在A100上连续执行1000次cudaMalloc和cudaFree，每次分配1MB。你猜花了多久？差不多要200毫秒。看起来不多？但如果你在推理服务里，每次请求都要这么搞，QPS直接掉一半。
核心原因：
- 驱动层开销：每次cudaMalloc都要经过CUDA驱动，跟GPU硬件交互。这可不是简单的内存分配，背后有一堆上下文切换、页表更新操作。
- 同步等待：cudaFree会阻塞当前流，直到GPU完成所有依赖该内存的操作。说白了，就是等你算完了才能释放。
- 内存清零：新分配的显存默认是零值，这个清零操作本身就要花时间。
我记得有一次，一个同事写了个训练脚本，每个batch都重新分配中间变量的显存。结果训练速度比预期慢了3倍。我一看代码，好家伙，一个epoch里cudaMalloc调了上万次。改成显存池后，速度直接起飞。
我的建议：能用显存池就别裸调cudaMalloc。实在要调，也尽量在初始化阶段一次性分配好，别在热路径上搞分配释放。
2.2 内存碎片化问题
第二个痛点，内存碎片化。这玩意儿比频繁分配更隐蔽，也更致命。你想想看，显存就像一块大蛋糕，你切一块我切一块，切来切去就全是碎渣了。
碎片化分两种：
- 外部碎片：空闲显存总量够，但都是小碎片，凑不出一块大的。比如你有10GB空闲，但最大连续块只有2GB，想分配3GB就报OOM。
- 内部碎片：分配的内存比实际用的大。比如你只要1.5MB，但分配器给了2MB，那0.5MB就浪费了。
为什么会这样？我举个例子。假设你依次分配了A(1GB)、B(2GB)、C(1GB)，然后释放了B。这时候空闲块是2GB，但被A和C夹在中间。如果接下来要分配1.5GB，没问题。但要分配2.5GB，就尴尬了——总空闲有2GB+1GB+1GB=4GB，但没有一个连续块超过2GB。
避坑指南：我曾经在一个长期运行的推理服务里遇到过碎片化导致的OOM。服务跑了3天，显存占用从12GB慢慢涨到16GB，最后直接挂了。查了半天，不是内存泄漏，就是碎片化太严重，分配器找不到合适的连续块。
碎片化对性能的影响也很明显：
- 分配延迟增加：分配器要花更多时间搜索合适的空闲块
- 内存利用率下降：碎片越多，浪费越大
- 极端情况直接OOM：明明总量够，就是分配不出来
2.3 显存泄漏风险
第三个痛点，显存泄漏。这玩意儿比CPU内存泄漏更可怕。CPU内存泄漏顶多程序变慢，显存泄漏直接让GPU罢工——别的进程也用不了显存了。
显存泄漏的常见场景：
- 忘记释放：分配了显存，但代码路径提前返回了，cudaFree没执行到。
- 循环引用：Python对象互相引用，导致显存对应的Python对象无法被GC回收。
- 异常处理不当：程序抛异常了，catch块里没做显存清理。
- 第三方库泄漏：用的库有bug，内部分配了显存但不释放。
我遇到过最坑的一次，是某个版本的PyTorch DataLoader有显存泄漏。训练到第500个epoch，显存从8GB涨到了15GB。排查了整整两天，最后发现是num_workers开太多，子进程的显存没正确回收。
检测方法：
- 用
nvidia-smi监控显存变化，看是不是持续增长 - 用
torch.cuda.memory_summary()打印详细分配信息 - 写单元测试，分配-释放-检查，看显存是否回到基线
我的习惯：每次分配显存，我都会在注释里写明「这块显存谁负责释放」。代码review时重点检查有没有成对的cudaMalloc/cudaFree。说白了，就是养成好习惯，别让显存泄漏成为线上事故的导火索。
2.4 知识体系总览
下面这张图，我把三个痛点的关系梳理了一下。你看，它们不是孤立的，而是相互影响的。
你看，这三个问题其实是连锁反应。频繁分配释放导致碎片化，碎片化又加剧了分配延迟，而泄漏则让情况雪上加霜。所以，解决思路就是——用显存池把这仨问题一起收拾了。
好了，这一章就聊到这儿。下一章咱们具体看看显存池是怎么设计的，怎么把这三个痛点一个个解决掉。