课程导入：学习目标、课程结构、CUDA内存管理与TensorRT复用的重要性

1.1 为什么需要关注CUDA内存与TensorRT复用

在深度学习推理与高性能计算场景中，GPU显存（VRAM）是最昂贵、最稀缺的硬件资源之一。以NVIDIA A100 40GB为例，一张显卡的采购成本数万元，而一次Transformer大模型推理可能需要占用数GB显存。如果每次请求都独立分配显存、推理结束后立即释放，系统将面临两个严重问题：分配开销高（cudaMalloc/cudaFree是同步调用，单次耗时可达数十微秒）和显存碎片化（频繁分配释放导致可用显存被切割成不连续小块，最终出现“显存充足但分配失败”的假性OOM）。

TensorRT作为NVIDIA官方推理优化引擎，其核心能力之一就是显存池化——通过预先分配一块大显存，并在内部按需切分复用，将分配次数从“每层每请求”降为“每引擎一次”。理解这一机制，是掌握高性能推理服务开发的关键前提。

核心认知：CUDA内存池（Memory Pool）与TensorRT的显存复用，本质上是“用一次大分配换取无数次零分配”。在延迟敏感型服务（如实时语音识别、自动驾驶感知）中，这一优化往往能带来30%~70%的端到端延迟下降。

1.2 本节学习目标

完成本章学习后，你将能够：

描述CUDA显存分配的两级架构（驱动层与运行时层）及cudaMalloc的隐性开销来源；
解释TensorRT的IGpuAllocator接口与显存池化的工作流程；
对比“按需分配”与“池化复用”在碎片率、分配耗时、峰值显存三个维度的差异；
识别推理服务中常见的显存泄漏与碎片化陷阱，并给出排查方向。

1.3 课程结构总览

本课程共30章，按“原理→实践→调优→排障”四阶段递进。下表展示了各模块的核心主题与关联性：

模块	章节范围	核心内容	关键产出
基础原理	1~6章	CUDA内存模型、分配器机制、TensorRT架构	显存池化原理图
实践操作	7~15章	自定义分配器、TensorRT C++/Python集成、多流复用	可运行的池化推理示例
调优进阶	16~24章	碎片整理、显存预算控制、多模型共享池	显存监控与调优工具
排障复盘	25~30章	OOM分析、泄漏检测、性能基准对比	故障排查决策树

其中，第7~10章是实践核心，将手把手实现一个基于cudaMemPool的分配器并接入TensorRT；第16~18章则深入显存碎片整理算法，解决长期运行服务的显存膨胀问题。

1.4 CUDA内存管理的核心原理

CUDA显存管理分为两层：驱动层（cuMemAlloc/cuMemFree）与运行时层（cudaMalloc/cudaFree）。运行时层是驱动层的轻量封装，但两者都涉及CPU与GPU之间的同步操作。每次cudaMalloc调用，实际发生以下步骤：

检查当前上下文（Context）是否有效；
向驱动层请求显存块，驱动层查找空闲列表（Free List）；
若空闲列表无合适块，则调用底层驱动向GPU显存控制器申请新页（通常为2MB或更大粒度）；
更新上下文的内存映射表，返回设备指针。

这一过程涉及锁、同步、页表更新，在频繁调用时开销显著。更关键的是，显存释放（cudaFree）并不会立即归还给操作系统，而是保留在驱动层的空闲列表中——这导致显存峰值无法下降，且碎片化随分配次数线性恶化。

上图对比了两种策略的显存使用模式。左侧传统方式中，每次请求独立分配/释放，显存块之间产生大量不可用碎片；右侧TensorRT在引擎创建时一次性从驱动层申请大块显存（如2GB），内部通过空闲块链表管理，推理结束后内存归还池中而非释放给驱动层，从而彻底消除碎片化。

1.5 TensorRT显存复用的实现机制

TensorRT通过IGpuAllocator接口实现显存池化。其核心流程如下：

// TensorRT自定义分配器核心接口
class CustomAllocator : public nvinfer1::IGpuAllocator {
    void* allocate(uint64_t size, uint64_t alignment, uint32_t flags) override {
        // 1. 从预分配池中查找合适空闲块
        void* ptr = pool.find_free_block(size, alignment);
        if (ptr == nullptr) {
            // 2. 池中无合适块时，才调用cudaMalloc扩展池
            cudaMalloc(&ptr, size);
            pool.add_block(ptr, size);
        }
        return ptr;
    }
    void free(void* memory) override {
        // 3. 释放时归还池中，不调用cudaFree
        pool.return_block(memory);
    }
};

这一机制带来三个直接收益：

分配耗时降低：池内分配仅涉及链表查找（O(1)~O(n)），耗时约1~5微秒，而cudaMalloc平均耗时20~50微秒；
显存碎片消除：池内块按大小分类管理（如Buddy System或Slab分配），长期运行不产生外部碎片；
峰值显存可控：池大小可预设上限，超出时拒绝分配而非无限增长，避免OOM。

1.6 典型应用场景与误区

典型场景：某在线翻译服务使用TensorRT部署Transformer模型，输入batch=32，显存需求约1.2GB。未使用池化时，每秒处理50个请求，每个请求触发约200次cudaMalloc/cudaFree，导致GPU利用率仅35%，且运行2小时后出现显存碎片化OOM。改用自定义池化分配器后，显存分配次数降为1次，GPU利用率提升至78%，连续运行7天无OOM。

常见误区：许多开发者认为“TensorRT已经内置池化，无需自己实现”。实际上，TensorRT默认使用cudaMalloc直接分配，仅在显存紧张时启用setMemoryPoolLimit。要获得最佳复用效果，必须实现自定义IGpuAllocator并配合cudaMemPool使用。

另一个误区是混淆“显存池”与“CUDA缓存”。CUDA运行时也有自己的缓存机制（如cudaMallocAsync），但TensorRT的池化是应用层的，两者可以叠加使用。正确做法是：在应用层实现池化，底层使用cudaMallocAsync进一步减少驱动层开销。

📚 课程目录