GPU显存管理机制：CUDA显存分配与释放策略
说到GPU显存管理，我得先坦白一件事。我早年做推理优化时，踩过一个很深的坑。模型跑得好好的，突然就OOM了。查了半天，发现显存碎片化严重，明明总量够用，就是分配不出连续空间。嗯，从那天起，我就开始认真研究CUDA的显存管理机制了。
cudaMalloc与cudaFree的工作原理
先聊聊最基础的两个API：cudaMalloc和cudaFree。说白了，它们就是CUDA版的malloc和free。但GPU上的内存分配，比CPU复杂得多。
cudaMalloc做的事情，我总结为三步：
- 向驱动申请一块物理显存
- 建立虚拟地址到物理地址的映射
- 返回用户可用的虚拟地址指针
你可能会问：为什么不能直接操作物理地址？因为GPU和CPU一样，也用了虚拟内存机制。这样做的好处是，不同上下文之间可以隔离，安全性更高。
但问题来了。cudaMalloc和cudaFree是同步操作。每次调用，都会触发一次GPU和CPU之间的同步。我在项目中遇到过，频繁调用这两个API，性能直接掉了30%。
核心要点：cudaMalloc/cudaFree是昂贵的操作。它们不仅分配/释放内存，还会引发同步开销。推理场景下，尽量避免频繁调用。
显存碎片：一个被忽视的性能杀手
显存碎片分两种：内部碎片和外部碎片。
| 碎片类型 | 产生原因 | 典型场景 |
|---|---|---|
| 内部碎片 | 分配粒度对齐导致浪费 | 申请17字节，实际分配32字节 |
| 外部碎片 | 频繁分配释放导致空闲块不连续 | 多次cudaMalloc/cudaFree后 |
外部碎片才是真正的噩梦。我记得有一次调试一个推理服务，显存总量8GB，模型只占4GB，但跑第二个实例时就是报OOM。用nvidia-smi一看，显存碎片化严重，最大连续空闲块只有1.2GB。
避坑指南：我曾经因为没注意碎片问题，导致线上服务频繁重启。后来加了个显存整理策略，才稳定下来。记住：显存够用 ≠ 能分配成功。
显存池（Memory Pool）的概念
为了解决碎片问题，CUDA从11.0版本开始引入了显存池（Memory Pool）。
显存池的核心思想很简单：预分配一大块显存，然后自己管理内部的分配和释放。这样就不需要每次都走驱动层了。
我画了一张图，帮你理解显存池的工作流程：
看到区别了吗？右侧的显存池模式，分配和释放都在用户态完成。只有池不够用时，才去驱动层申请新内存。
CUDA显存池的API使用
CUDA 11.0+提供了cudaMemPool相关API。我常用的几个：
// 创建显存池
cudaMemPool_t pool;
cudaMemPoolCreate(&pool, &poolProps);
// 从池中分配
float* d_data;
cudaMallocFromPoolAsync(&d_data, size, pool, stream);
// 释放回池
cudaFreeAsync(d_data, stream);
// 销毁池
cudaMemPoolDestroy(pool);注意看，我用的是cudaMallocFromPoolAsync和cudaFreeAsync。这两个是异步版本，不会阻塞当前流。配合多流使用，效果更好。
个人经验：我建议在推理服务启动时，就创建好显存池。根据模型大小，预分配1.2倍~1.5倍的内存。这样后续的请求，分配速度能提升5~10倍。
显存池的配置策略
显存池不是万能的。配置不好，反而会浪费显存。我总结了几条经验：
- 池大小：太小了频繁触发驱动分配，太大了浪费显存。我一般按峰值需求的1.3倍设置。
- 释放策略：默认是延迟释放。如果你对显存占用敏感，可以设置
cudaMemPoolReuseThreshold。 - 多池隔离：不同优先级的任务，用不同的池。避免高优任务被低优任务的碎片影响。
举个例子。我之前优化一个BERT推理服务，用了显存池后，P99延迟从45ms降到了32ms。为什么？因为去掉了频繁的cudaMalloc/cudaFree同步开销。
注意：显存池不是银弹。如果你的模型每次推理都申请不同大小的内存，池内碎片依然存在。这时候，考虑固定大小分配或者使用伙伴系统。
总结一下
显存管理这块，说白了就是「空间换时间」。预分配、复用、减少驱动交互，是核心思路。我见过太多人只关注计算优化，忽略了显存管理。结果模型跑得飞快，但内存分配成了瓶颈。
嗯，这一章就到这里。记住：好的显存管理，能让你的推理服务更稳定、更高效。