一、显存池初探：什么是显存池、为什么需要显存池、显存池的核心价值

1.1 先聊聊我为什么开始关注显存池

说实话，我入行做GPU系统开发那会儿，压根没听过「显存池」这个词。

那时候做AI推理服务，模型一加载，显存就占得死死的。每次新请求进来，要么重新分配显存，要么等着别人释放。结果呢？延迟高得离谱，吞吐量上不去。

我记得有一次线上事故，一个客户的大模型推理任务，因为显存碎片化严重，明明还有20%的显存空闲，却分配不出一块连续的512MB空间。服务直接挂了。

嗯，从那天起，我开始认真研究显存管理。说白了，显存池就是解决这类问题的。

1.2 什么是显存池？

显存池，英文叫 GPU Memory Pool，是一种预先从GPU申请一大块显存，然后在内部自己管理分配和回收的机制。

你想想看，传统方式是这样的：每次需要显存，就调用 cudaMalloc 去申请；用完再 cudaFree 释放。这就像你每次喝水都去井边打水，喝完再把水倒回井里。

显存池的做法呢？一次性打一大桶水放在桌上，想喝就从桶里倒。喝完了，杯子洗洗放回桶边，下次再用。

我习惯把显存池比作一个「内存仓库」。仓库里堆满了各种尺寸的显存块，谁要用就来领，用完还回来。仓库管理员（也就是池管理器）负责记录哪些块空闲、哪些块在用、哪些块该合并了。

1.3 为什么需要显存池？

这个问题，我分三点来讲。

1.3.1 分配开销太大

cudaMalloc 和 cudaFree 是系统调用，涉及驱动层、内核层的操作。一次分配可能耗时几十微秒到几百微秒。

听起来不多？但AI推理场景下，一次请求可能涉及几十次显存分配。累积起来，光分配开销就能吃掉10%~30%的延迟预算。

我曾经在一个OCR服务中做过测试：去掉频繁的 cudaMalloc，改用显存池，单次推理延迟从45ms降到了32ms。效果立竿见影。

1.3.2 显存碎片化

这是个大坑。频繁分配和释放不同大小的显存块，会导致显存空间变得支离破碎。

举个例子：

• 先分配 100MB 的块 A
• 再分配 200MB 的块 B
• 释放块 A
• 现在想分配 150MB 的块 C

明明总空闲有100MB，但因为不连续，150MB的请求就失败了。这就是碎片化。

1.3.3 多任务共享显存

现代GPU上往往同时跑多个模型或服务。如果没有统一管理，每个任务各自为政，显存利用率极低。

比如模型A峰值需要4GB，模型B峰值需要3GB。但A的峰值和B的峰值可能错开。如果各自预留，就得分配7GB。用显存池统一管理，实际可能只需要5GB就够了。

1.4 显存池的核心价值

我总结了一下，显存池的价值可以用四个词概括：

价值维度	说明	我的经验
降低延迟	避免频繁系统调用，分配时间从微秒级降到纳秒级	实测分配延迟降低90%以上
消除碎片	通过内存合并、伙伴算法等策略，减少碎片	碎片率从30%降到5%以内
提高利用率	多任务共享，按需分配，避免浪费	显存利用率提升20%~40%
简化开发	开发者不用关心显存分配细节，专注业务逻辑	代码量减少，bug率下降

1.5 显存池的核心逻辑框架

下面这张图，是我自己画的一个显存池核心逻辑框架。你看完就能明白它内部是怎么运作的。

这张图展示了显存池的核心工作流程：

1. 用户请求分配或释放显存
2. 池管理器根据策略，从空闲列表中查找合适的内存块
3. 分配后，该块从空闲列表移到已分配列表
4. 释放时，块回到空闲列表，必要时进行合并
5. 后台线程定期做碎片整理

1.6 一个简单的显存池雏形

光说不练假把式。我写了一个极简的显存池示例，帮你理解核心思想：

// 极简显存池核心逻辑（伪代码）
class SimpleMemoryPool {
    // 预分配一大块显存
    void init(size_t total_size) {
        gpu_ptr = cudaMalloc(total_size);
        free_list.push_back({gpu_ptr, total_size});
    }
    
    // 分配：从空闲列表中找合适的块
    void* alloc(size_t size) {
        for (auto &block : free_list) {
            if (block.size >= size) {
                // 切出一块返回
                void* ptr = block.ptr;
                block.ptr += size;
                block.size -= size;
                alloc_list.push_back({ptr, size});
                return ptr;
            }
        }
        return nullptr; // 池子不够了
    }
    
    // 释放：把块放回空闲列表
    void free(void* ptr) {
        // 从alloc_list找到对应块
        // 放回free_list
        // 尝试合并相邻空闲块
    }
}

1.7 什么时候该用显存池？

我个人的判断标准很简单：

• 高频分配场景：每秒几十次以上的显存分配/释放，必须用
• 大模型推理：显存动辄几GB，碎片化是致命问题
• 多任务共享GPU：多个模型或服务共用一块卡，池化是唯一出路
• 延迟敏感服务：毫秒级延迟要求，不能容忍cudaMalloc的开销

反过来，如果你的程序只分配几次显存，用完就退出，那完全没必要上显存池。别为了用而用。

1.8 本章小结

显存池不是什么高深莫测的技术。说白了，它就是一套「先囤货、再零售」的管理策略。

核心就三件事：

• 预分配：一次性从GPU拿一大块
• 复用：分配和释放都在池内完成，不碰系统调用
• 管理：用合适的算法减少碎片、提高效率

嗯，这一章先带你入门。后面的章节，我会手把手教你实现一个真正能用的显存池。包括伙伴算法、分级分配、线程安全、性能调优……这些我都会结合我踩过的坑来讲。

---