显存基础与瓶颈分析

显存这东西，说白了就是GPU的「临时仓库」。我刚开始做模型训练时，总觉得显存不够就加卡呗，后来发现事情没那么简单。你想想看，仓库再大，如果搬运工（带宽）效率低，或者货物堆放（内存布局）不合理，照样跑不快。

这一章，咱们就聊聊显存的底层逻辑。我会结合自己踩过的坑，帮你把显存架构、带宽计算、瓶颈定位这些基础打扎实。

显存架构：从物理到逻辑

现代GPU的显存，主流是GDDR6或HBM2e。我个人习惯把显存系统拆成三层来看：

• 物理层：显存颗粒本身。比如NVIDIA A100用的是HBM2e，带宽高达2TB/s。而消费级卡如RTX 4090用的是GDDR6X，带宽约1TB/s。
• 控制器层：GPU内部的显存控制器（Memory Controller）。它负责调度读写请求。我遇到过一个问题：同一张卡，跑不同框架时显存带宽利用率差了一倍，后来发现是控制器调度策略不同。
• 逻辑层：CUDA或ROCm等编程模型看到的显存视图。比如cudaMalloc分配的是连续虚拟地址，但物理上可能分散在不同颗粒上。

举个例子，一张RTX 3090的显存频率是1219 MHz，位宽384-bit，GDDR6X每个时钟传输2次数据。理论带宽 = 1219 × 384 / 8 × 2 ≈ 117 GB/s？不对，这里有个坑——GDDR6X用的是PAM4编码，实际有效带宽要乘以一个系数。我当年算这个的时候，差点被搞晕。

带宽计算：别被理论值骗了

咱们直接上公式：

理论带宽 = 显存时钟频率 × 数据速率 × 位宽 / 8

实际有效带宽 = 理论带宽 × 利用率系数

这个利用率系数，说白了就是你的程序能「榨出」多少带宽。我见过最夸张的情况：一个简单的向量加法，带宽利用率只有理论值的15%。为什么会这样？因为显存访问模式不对。

显存类型	理论带宽	典型利用率	实际可用
GDDR6 (RTX 3060)	360 GB/s	60%-70%	~250 GB/s
GDDR6X (RTX 4090)	1008 GB/s	65%-75%	~700 GB/s
HBM2e (A100)	2039 GB/s	75%-85%	~1700 GB/s

常见瓶颈定位方法

显存瓶颈，我把它分成三类。每类都有对应的定位手段：

1. 容量瓶颈

说白了就是显存放不下了。表现是OOM（Out of Memory）或者频繁的显存交换。我曾经在训练一个超大模型时，发现显存占用率一直卡在95%左右，但性能就是上不去。后来用torch.cuda.memory_summary()一看，发现是碎片化严重。

定位方法：

• 用nvidia-smi看显存占用
• 用PyTorch的torch.cuda.memory_stats()获取详细分配信息
• 检查是否有显存泄漏（比如循环中不断创建新tensor）

2. 带宽瓶颈

这是最常见的性能杀手。表现是：GPU计算单元利用率低，但显存带宽跑满了。我遇到过最典型的场景：在做图像预处理时，频繁从CPU拷贝数据到GPU，结果带宽成了瓶颈。

定位方法：

• 用Nsight Systems看Memcpy和Kernel的时间占比
• 用nvidia-smi dmon看显存带宽利用率
• 检查数据是否对齐（比如128字节对齐）

3. 延迟瓶颈

这个比较隐蔽。表现是：显存带宽没跑满，但GPU计算单元也在空等。说白了就是「数据没及时送到」。我做过一个实验：把一个小kernel反复启动1000次，结果发现每次启动的延迟（约5微秒）加起来比计算本身还长。

定位方法：

• 用Nsight Compute看每个kernel的启动延迟
• 检查是否有过多的同步操作（如cudaDeviceSynchronize）
• 用CUDA Graph合并多个小kernel

知识体系总览

下面这张图，是我自己总结的显存优化知识框架。你把它记在心里，后面几章的内容都能对号入座。

实战：快速定位显存瓶颈

我给你一个我常用的「三板斧」流程：

1. 第一板斧：看容量。用nvidia-smi看显存占用率。如果超过90%，先考虑减少batch size或使用梯度累积。
2. 第二板斧：看带宽。用nvidia-smi dmon -d 1看带宽利用率。如果超过80%但GPU计算单元利用率低于50%，说明是带宽瓶颈。
3. 第三板斧：看延迟。用Nsight Systems看kernel启动间隔。如果每次启动间隔小于10微秒，说明延迟不是问题；如果大于100微秒，就要考虑合并kernel了。

好了，这一章的基础就这些。你把这些概念吃透了，后面讲具体优化技巧时，就能理解为什么有些方法有效，有些是白费功夫。