一、显存池概述：什么是显存池、为什么需要显存池、显存池的核心目标
1.1 什么是显存池？
显存池，说白了就是一块预先申请好的显存“仓库”。
我刚开始做部署时，习惯每次需要显存就调用 cudaMalloc 去申请，用完再 cudaFree 释放。后来发现，这种做法在推理服务里简直是灾难——频繁的内存分配和释放，不仅慢，还会导致显存碎片化。
显存池的思路很简单：一次性申请一大块显存，自己管理分配和回收。就像你开餐厅，不会每次有客人点菜才去菜市场买菜，而是提前备好食材在仓库里。
核心定义：显存池是一个预分配的显存块管理器，负责统一管理显存的申请、复用和回收，避免直接与 GPU 驱动交互。
嗯，这里要注意：显存池不是简单的“大块内存”，它需要支持不同大小的显存请求，还要能高效地回收和复用。
1.2 为什么需要显存池？
你想想看，一个典型的 AI 推理服务，每秒可能要处理几十上百个请求。每个请求涉及的模型推理、中间结果存储，都需要显存。如果每次请求都去 cudaMalloc，会有什么问题？
- 性能开销大：
cudaMalloc是同步操作，调用一次可能要几十微秒。高并发下，这个开销会被放大。 - 显存碎片化： 频繁申请释放不同大小的显存块，会导致显存出现大量“空洞”。我曾在项目中遇到过，明明总显存还有 4GB，但就是申请不到一个 1GB 的连续块——全是碎片。
- 内存泄漏风险： 手动管理显存，很容易忘记释放。特别是异常分支处理不当，显存就“丢”了。
- 延迟抖动： 每次
cudaMalloc的耗时不稳定，会导致推理延迟出现毛刺。
我的经验： 曾经有个线上服务，P99 延迟从 20ms 飙升到 200ms，查了半天发现是显存分配导致的。换成显存池后，P99 直接降到 25ms 以内。
1.3 显存池的核心目标
显存池要解决什么问题？我总结为三个核心目标：
| 目标 | 说明 | 我的实践建议 |
|---|---|---|
| 减少分配开销 | 避免频繁调用 cudaMalloc，用预分配+复用替代 |
建议预分配总显存的 70%-80%，留一些余量给突发请求 |
| 消除显存碎片 | 通过内存池的分配策略，减少外部碎片 | 我曾经用 buddy 算法管理显存池，碎片率从 30% 降到 5% 以下 |
| 提升吞吐量 | 让显存分配成为 O(1) 或 O(log n) 操作 | 高并发场景下，显存池能带来 2-3 倍的吞吐提升 |
说白了，显存池就是让显存管理变得“又快又稳”。
1.4 显存池的核心逻辑
我画了一张图，帮你理解显存池的工作流程：
这张图展示了显存池的核心逻辑：多个推理请求同时申请不同大小的显存，显存池管理器负责从预分配的池中分配空闲块，用完后再回收。整个过程不需要跟 GPU 驱动打交道。
1.5 什么时候该用显存池？
不是所有场景都需要显存池。我个人习惯这样判断：
- 高并发推理服务： 必须用。比如在线翻译、图像生成，每秒几十个请求。
- 批处理任务： 建议用。虽然并发不高，但显存碎片会随着时间累积。
- 单次推理： 没必要。比如离线跑一个模型，用完就退出了。
避坑指南： 我曾经在一个批处理任务里用了显存池，结果因为池大小设置不合理，导致显存浪费严重。后来调整为动态扩展的池，才解决问题。记住：显存池不是越大越好，要根据实际负载来配置。
1.6 小结
显存池的核心就三件事：预分配、复用、减少碎片。它不是什么高深的技术，但在实际部署中，能帮你省下不少头疼的时间。
嗯，这一章先讲到这里。显存池的概念清楚了，下一章我们聊聊具体的实现方案——怎么设计一个高效的显存池分配器。