4、显存分配的性能瓶颈：cudaMalloc/cudaFree的同步开销，显存碎片化问题，频繁分配释放对吞吐的影响
好，咱们来聊聊显存分配这个事儿。说实话，很多做推理优化的同学，一开始都容易忽略这个环节。大家总觉得，显存嘛，不就是申请一下、用完了释放掉，能有多大事？
嗯，我以前也这么想。直到有一次，我负责一个高并发推理服务，QPS死活上不去。排查了半天，发现罪魁祸首居然是 cudaMalloc 和 cudaFree。你想想看，每次推理都去申请释放显存，那性能能好吗？
4.1 cudaMalloc/cudaFree 的同步开销
先说说 cudaMalloc 和 cudaFree 这两个函数。它们可不是简单的内存分配和释放。
它们都是同步操作。 什么意思？就是调用 cudaMalloc 的时候，CPU 会等着 GPU 把内存分配好，才返回。这期间，CPU 啥也干不了。同样，cudaFree 也是同步的，它要等 GPU 上所有使用这块内存的任务都执行完了，才能释放。
我给大家看个例子：
// 糟糕的做法：每次推理都分配释放
for (int i = 0; i < 1000; i++) {
float* d_data;
cudaMalloc(&d_data, batch_size * sizeof(float)); // 同步！CPU 等待
// ... 执行推理 ...
cudaFree(d_data); // 同步！等待 GPU 完成
}
这段代码，每次循环都要等两次。1000次循环，就是2000次同步等待。你说吞吐能高吗？
核心问题： cudaMalloc/cudaFree 是同步的，会阻塞 CPU 流水线。频繁调用会严重拖累吞吐。
我个人习惯是，能少调用就少调用。最好是一次分配，重复使用。
4.2 显存碎片化问题
除了同步开销，还有个更隐蔽的问题——显存碎片化。
你想想看，如果每次推理的 batch size 不一样，或者模型结构有变化，分配的内存块大小就不固定。频繁分配释放，显存就会像硬盘一样产生碎片。
碎片化会导致什么后果？
- 分配失败： 明明显存总量还有剩余，但找不到一块连续的大块内存，
cudaMalloc直接报错。 - 分配变慢： 即使能分配，GPU 驱动也要花时间去找合适的空闲块，分配延迟增加。
- 利用率下降： 碎片占着茅坑不拉屎，实际可用的显存变少了。
我记得有一次，一个线上服务跑着跑着突然 OOM 了。我一看，显存总量还有 2GB 空闲，但 cudaMalloc 就是分配不出一个 1GB 的连续块。这就是典型的碎片化问题。
避坑指南： 我曾经在一个动态 batch 的服务里，没做显存池，结果每处理几千次请求就崩一次。后来加了显存池，世界清净了。
4.3 频繁分配释放对吞吐的影响
把前面两个问题加起来，就是频繁分配释放对吞吐的致命打击。
咱们可以算一笔账：
| 操作 | 单次耗时（微秒） | 1000次总耗时（毫秒） |
|---|---|---|
| cudaMalloc (1GB) | ~500 | 500 |
| cudaFree (1GB) | ~300 | 300 |
| 推理计算 | ~2000 | 2000 |
你看，光分配释放就占了总时间的 40%。这还没算碎片化导致的额外延迟。
说白了，频繁分配释放就是给吞吐「上刑」。你想想看，本来 GPU 算得飞快，结果 CPU 一直在等内存分配，GPU 空转，吞吐能高才怪。
4.4 解决方案：显存池
那怎么办？答案就是——显存池。
显存池的核心思想很简单：提前申请一大块显存，自己管理，按需分配，用完归还，不释放给驱动。
这样做的好处：
- 避免同步开销： 分配和归还都在用户态完成，不涉及 cudaMalloc/cudaFree，没有同步等待。
- 消除碎片化： 池内可以自己实现内存整理，或者用固定大小的块来避免碎片。
- 提升吞吐： 分配延迟从微秒级降到纳秒级，CPU 流水线不被阻塞。
下面是一个简单的显存池示意图：
我的建议： 对于高吞吐场景，一定要用显存池。哪怕是最简单的「预分配+复用」模式，也能带来数倍的性能提升。
好了，关于显存分配的性能瓶颈，咱们就聊到这儿。核心就三点：同步开销、碎片化、频繁分配对吞吐的影响。解决方案就是显存池。下一节，咱们会深入讲讲显存池的具体实现和优化技巧。
想要更多资料，联系可可