一、显存基础与瓶颈分析

大家好，我是你们的GPU工程师老K。今天咱们聊聊显存——这个在CUDA编程里最让人头疼的东西。

说实话，我见过太多同学把精力全放在计算优化上，结果程序跑起来直接OOM。或者更惨，跑是能跑，但速度慢得像蜗牛。为什么？说白了，就是没搞懂显存这玩意儿到底怎么工作的。

1.1 GPU显存架构：HBM vs GDDR

先说说显存的两种主流方案。你打开一张显卡的规格表，看到的要么是GDDR6/GDDR6X，要么是HBM2/HBM2E/HBM3。这两者有什么区别？

特性	GDDR6/GDDR6X	HBM2/HBM2E/HBM3
典型带宽	~500-1000 GB/s	~1-3 TB/s
单颗容量	8-32 GB	4-16 GB（堆叠）
功耗	较高	较低
成本	较低	较高
典型应用	消费级显卡	数据中心/高端计算卡

我个人习惯把GDDR比作「高速公路上的卡车」——带宽够用，但延迟高、功耗大。HBM则像「城市地铁系统」——带宽极高、延迟低，但造价贵、容量受限。

我在项目中遇到过一件事：用RTX 3090跑一个NLP模型，显存24GB刚好够。换成A100（40GB HBM2E）后，同样的模型居然快了将近2倍。为什么？不是计算更快，而是HBM的带宽优势让数据搬运不再是瓶颈。

核心要点：显存架构决定了你的程序能跑多快。HBM适合带宽密集型任务（如大模型推理），GDDR适合容量敏感型任务（如渲染）。

1.2 显存带宽与延迟

带宽和延迟，这两个参数决定了你的GPU到底「饿不饿」。

带宽，说白了就是「单位时间能搬多少数据」。延迟，就是「从发出请求到拿到数据要等多久」。

你想想看，GPU的计算单元（SM）跑得飞快，但数据要从显存里搬过来。如果带宽不够，SM就得干等着——这就是所谓的「内存墙」问题。

我举个例子：

// 带宽敏感型操作：矩阵乘法
// 每个线程需要反复读取A和B矩阵
// 如果带宽不足，计算单元会大量空闲

__global__ void matmul_kernel(float* A, float* B, float* C, int N) {
    int row = blockIdx.y * blockDim.y + threadIdx.y;
    int col = blockIdx.x * blockDim.x + threadIdx.x;
    
    float sum = 0.0f;
    for (int k = 0; k < N; ++k) {
        // 每次循环都要从显存读数据
        sum += A[row * N + k] * B[k * N + col];
    }
    C[row * N + col] = sum;
}

这段代码看起来没问题，对吧？但实际跑起来，你会发现SM利用率可能只有30%-40%。为什么？因为每次循环都在读显存，带宽根本喂不饱计算单元。

我的经验：遇到这种问题，优先考虑共享内存（shared memory）来缓存数据。我曾经把一个矩阵乘法的带宽利用率从35%提升到85%，就靠这个技巧。

1.3 显存容量限制

容量问题，嗯，这是最让人头疼的。你辛辛苦苦写好了代码，一跑就报错：

RuntimeError: CUDA out of memory. Tried to allocate 2.00 GiB.
GPU 0 has a total capacity of 8.00 GiB. 
Of which, 7.50 GiB is already allocated by PyTorch.

看到这个错误，你是不是想砸电脑？我当年第一次遇到时，整整排查了两天。

显存容量限制主要来自三个方面：

物理限制：显卡焊了多少显存颗粒，就是多少。RTX 4090 24GB，A100 80GB，没得商量。
碎片化：频繁分配释放小张量，会导致显存碎片化。明明总量够，但就是分配不出连续的大块。
临时变量：很多框架（比如PyTorch）会在计算过程中创建大量临时张量，这些你肉眼看不见。

避坑指南：我曾经在训练一个Transformer模型时，显存占用从12GB突然飙升到23GB，然后OOM。排查了半天，发现是某个中间层的激活值没有及时释放。用torch.no_grad()或者del显式删除临时变量，问题就解决了。

1.4 显存溢出（OOM）的常见场景

OOM，全称Out of Memory，是每个CUDA开发者都绕不开的噩梦。我总结了几种最常见的场景：

批量大小过大：batch size设得太大，显存直接爆掉。我建议从1开始慢慢往上试。
模型参数过多：一个7B参数的模型，光参数就要占14GB（FP16）。加上优化器状态、梯度、激活值，轻松突破40GB。
数据预处理不当：把整个数据集一次性加载到显存里。嗯，这个错误我犯过不止一次。
内存泄漏：循环中不断创建新张量但不释放。用nvidia-smi监控显存占用，如果持续增长，八成是泄漏了。

为什么会这样？说白了，就是没有「显存预算」的概念。你写代码前，应该先算一笔账：

// 显存预算示例（以FP16为例）
// 模型参数: 7B * 2 bytes = 14 GB
// 梯度: 7B * 2 bytes = 14 GB
// 优化器状态（Adam）: 7B * 4 bytes * 2 = 56 GB
// 激活值（估算）: 约 10-20 GB
// 总计: 约 94-104 GB
// 结论: 单卡A100 80GB根本跑不了，需要模型并行或梯度检查点

我的建议：每次写CUDA代码前，先画一张显存分配图。把每个张量的大小、生命周期都标清楚。这听起来麻烦，但能帮你避免90%的OOM问题。

知识体系总览

下面这张图，是我自己总结的显存优化知识体系。你可以把它当作一张「地图」，后续的章节都会围绕这些点展开。

这张图把显存优化分成了三个层次：先理解硬件架构，再学会诊断瓶颈，最后才是具体的优化策略。后面的章节，我会逐一展开每个细节。

好了，第一章就到这里。记住一句话：显存不是无限的，但优化空间是无限的。

📚 课程目录

一、显存基础与瓶颈分析

1.1 GPU显存架构：HBM vs GDDR

1.2 显存带宽与延迟

1.3 显存容量限制

1.4 显存溢出（OOM）的常见场景

知识体系总览