GPU显存基础：显存层次结构、显存带宽、显存容量与性能关系

在深入CUDA显存碎片与TensorRT分配策略之前，必须先建立对GPU显存系统的准确认知。显存并非一个简单的“大仓库”，而是一个具有明确层次、带宽差异和容量约束的复杂存储体系。绝大多数显存分配失败、性能瓶颈乃至程序崩溃，根源都在于对显存层次和带宽特性的误解。

2.1 显存层次结构：从寄存器到全局内存

现代NVIDIA GPU的显存体系可以划分为六个主要层级，每一层级的容量、延迟和带宽差异巨大。理解这个层次是后续分析碎片问题的前提。

层级	典型容量	延迟（周期）	带宽	作用域	管理方式
寄存器文件	每SM 256KB	~1	极高	线程私有	编译器分配
共享内存	每SM 0-228KB	~20-30	极高	线程块共享	显式/动态
L1缓存	每SM 128-256KB	~30	极高	SM内部	硬件管理
L2缓存	20-40MB	~200	高	GPU全局	硬件管理
全局内存（显存）	8-80GB	~400-800	中	所有线程	cudaMalloc
主机内存（PCIe）	系统内存	数千	低（PCIe 4.0 x16约32GB/s）	CPU-GPU	cudaHostAlloc

这张表揭示了几个关键事实：寄存器到全局内存的延迟差距超过400倍；共享内存和L1缓存共享同一物理SRAM，可动态配置；全局内存虽然容量最大，但却是性能的“瓶颈层”。TensorRT在构建推理引擎时，会尽可能将权重、中间激活值驻留在L2缓存或共享内存中，以减少对全局内存的访问。

关键认知：CUDA的“显存”通常特指全局内存（Global Memory），即通过 cudaMalloc 分配的空间。而寄存器、共享内存、L1/L2缓存属于片上存储，它们的分配和释放机制与全局内存完全不同，不会产生传统意义上的“碎片”问题，但会限制kernel的占用率。

2.2 显存带宽：为什么它比容量更“值钱”

显存带宽决定了GPU每秒能从全局内存读取或写入多少数据。以NVIDIA A100为例，其HBM2e显存带宽约为1.6TB/s，而L2缓存带宽可达3TB/s以上。对于计算密集型算子（如矩阵乘法），如果数据能驻留在寄存器或共享内存中，计算单元可以全速运转；一旦需要频繁访问全局内存，内存带宽就会成为瓶颈，GPU计算单元将大量时间处于等待状态。

带宽的计算公式为：

显存带宽 = 显存时钟频率 × 位宽 × 2（DDR/HBM双倍速率） / 8
例如A100：1215MHz × 5120bit × 2 / 8 ≈ 1.6TB/s

在实际CUDA编程中，合并访问（Coalesced Access）是充分利用带宽的关键。当同一warp的32个线程访问连续内存地址时，硬件可以合并为少数几次内存事务；若访问地址分散，则会产生多次事务，有效带宽急剧下降。TensorRT在优化推理引擎时，会重排权重布局和算子执行顺序，以最大化内存访问的局部性和合并度。

2.3 显存容量：分配策略的硬约束

显存容量是推理部署中最直观的约束。一个典型的深度学习推理模型，其显存占用由以下几部分组成：

模型权重：FP16下，7B模型约14GB；INT8量化后约7GB。
中间激活值：取决于batch size、序列长度和网络深度，可能从数百MB到数GB不等。
工作缓冲区：TensorRT的算子执行需要临时显存，如卷积的im2col变换、Softmax的中间结果等。
CUDA上下文：每个进程约200-600MB，包含模块、常量、设备栈等。
碎片空洞：由于分配/释放顺序不当产生的不可用空间。

容量规划经验法则：部署TensorRT引擎时，建议预留总显存的10%-20%作为余量。例如在24GB的RTX 3090上，引擎实际占用不应超过19-20GB，否则在运行时会因CUDA上下文、驱动开销或小幅内存波动而触发OOM。

2.4 案例：为什么“显存够用”却OOM？

一个常见的生产事故场景：某团队在A100（80GB）上部署一个需要约60GB显存的推荐系统模型。他们使用TensorRT的 setMemoryPoolLimit 将工作池限制为62GB，认为留出了足够余量。然而实际运行时，cudaMalloc 返回 out of memory。

排查过程如下：

使用 nvidia-smi 查看显存占用，发现进程已占用58GB，但仍有22GB空闲。
使用 cudaMemGetInfo 查询，发现 free 为22GB，但 largestFreeBlock 仅为3GB。
进一步用CUDA的 cuMemGetAddressRange 检查，发现显存被分割成大量碎片，最大连续块只有3GB。
根因：TensorRT在构建引擎时，为不同层分配了大小不等的临时缓冲区，且释放顺序与分配顺序不一致，导致地址空间碎片化。

解决方案是启用TensorRT的 Pool 分配器，将多次小分配合并为一次大块分配，并在引擎内部复用。这正体现了显存容量与碎片之间的直接关系：容量充足不等于可用，连续地址空间才是关键。

常见误区：很多开发者认为“显存碎片只影响性能，不影响正确性”。实际上，当碎片导致 cudaMalloc 失败时，程序会直接崩溃或抛出异常。此外，碎片还会降低TLB命中率，导致访问延迟增加20%-30%。在实时推理场景中，这种延迟抖动是不可接受的。

2.5 显存性能的量化评估方法

在优化显存分配策略前，需要先量化当前显存的使用效率。推荐使用以下工具和方法：

工具/API	用途	关键输出
`nvidia-smi`	进程级显存监控	总显存、已用、空闲、进程列表
`cudaMemGetInfo`	运行时显存查询	free大小、total大小
`cuMemGetAddressRange`	检查地址空间连续性	每个分配块的起始地址和大小
`Nsight Compute`	内存吞吐分析	DRAM吞吐率、L2命中率、内存事务数
`CUDA Memory Checker`	检测越界和泄漏	非法访问位置、泄漏大小

一个实用的诊断脚本片段：

size_t free_byte = 0;
size_t total_byte = 0;
cudaMemGetInfo(&free_byte, &total_byte);

// 检查最大连续块
CUdeviceptr start_addr;
size_t largest_block = 0;
CUmemAllocationProp prop = {};
prop.type = CU_MEM_ALLOCATION_TYPE_PINNED;
prop.location.type = CU_MEM_LOCATION_TYPE_DEVICE;
prop.location.id = 0;
cuMemGetAllocationGranularity(&granularity, &prop, CU_MEM_ALLOC_GRANULARITY_MINIMUM);

// 通过二分法尝试分配不同大小的块，找到最大可分配连续空间
size_t low = 0, high = free_byte;
while (low < high) {
    size_t mid = (low + high + 1) / 2;
    CUdeviceptr ptr;
    CUresult res = cuMemAddressReserve(&ptr, mid, granularity, 0, 0);
    if (res == CUDA_SUCCESS) {
        low = mid;
        cuMemAddressFree(ptr, mid);
    } else {
        high = mid - 1;
    }
}
largest_block = low;
printf("Free: %zu MB, Largest contiguous: %zu MB\n",
       free_byte >> 20, largest_block >> 20);

通过上述方法，可以准确判断显存瓶颈是容量不足还是碎片过多，从而决定是优化分配策略、启用TensorRT的Pool机制，还是升级更大显存的硬件。

2.6 误区复盘：三个常见错误认知

误区一：“显存越大，性能越好”。实际上，如果程序的内存访问模式很差（如非合并访问），即使显存带宽再高也无法发挥。容量只决定能否装下数据，带宽和访问模式才决定运行速度。

误区二：“cudaMalloc很轻量，可以频繁调用”。每次 cudaMalloc 都会触发驱动层的地址空间管理、页表更新和TLB刷新，开销可达数十微秒。在推理循环中频繁分配会严重拖慢性能，这也是TensorRT使用内存池的根本原因。

误区三：“L2缓存命中率不重要”。对于Transformer等模型，自注意力计算中QKV矩阵的重复读取如果命中L2，可以节省大量DRAM带宽。实测中，L2命中率从50%提升到90%，端到端推理延迟可降低15%-25%。