一、显存基础与瓶颈识别
大家好，我是你们这堂课的老朋友。今天咱们聊聊显存——这个GPU里最金贵、也最容易成为瓶颈的资源。
说实话，我入行那会儿，显存还是个相对奢侈的东西。记得2016年我调一个BERT模型，12GB的显存愣是跑不起来，最后不得不把batch size压到1。那时候我就意识到：不懂显存，你连模型都跑不动。
1.1 显存架构：HBM vs GDDR
先说说显存的两大流派。你打开一张显卡的规格表，看到的要么是GDDR（Graphics Double Data Rate），要么是HBM（High Bandwidth Memory）。
GDDR 是主流消费级显卡的标配。它的特点是：
- 位宽相对窄（32-64 bit per chip）
- 频率高（可达20 Gbps以上）
- 成本低，容量大
HBM 则是高端计算卡的宠儿。比如NVIDIA的A100、H100都用HBM2e或HBM3。它的特点是：
- 位宽极宽（1024 bit per stack）
- 频率相对低（2-3 Gbps）
- 通过3D堆叠技术，把多个DRAM die叠在一起
我个人的经验是：HBM更适合计算密集型任务，因为它带宽大、延迟低；而GDDR更适合图形渲染，因为它的容量大、成本可控。
核心区别一句话：HBM是「宽而慢」的通道，GDDR是「窄而快」的通道。但HBM的「宽」带来的总带宽优势，远大于GDDR的「快」。
1.2 带宽与延迟：两个关键指标
显存性能好不好，主要看两个数：带宽和延迟。
带宽 是单位时间内能读写多少数据。单位是GB/s。你想想看，一个模型参数几百GB，如果带宽只有几十GB/s，那光加载参数就得等好几秒。
延迟 是从发出请求到拿到数据的时间。单位是纳秒（ns）。延迟高的时候，GPU核心就得空转等着——这就是所谓的「访存停顿」。
我在项目中遇到过最典型的场景：训练一个超大batch的Transformer模型，显存带宽被占满，但计算单元利用率只有30%。说白了，就是「等数据」的时间比「算数据」的时间还长。
避坑指南：我曾经以为带宽够大就万事大吉，结果发现延迟才是隐形杀手。尤其是小batch推理时，每次访存的延迟开销占比极高。所以，别只看带宽，延迟同样重要。
1.3 显存带宽计算公式
这个公式你得刻在脑子里：
显存带宽 (GB/s) = (显存频率 × 位宽 × 2) / 8 / 1000解释一下：
- 显存频率：单位MHz。比如GDDR6常见的1750 MHz（实际等效频率7000 MHz）
- 位宽：单位bit。比如RTX 3090是384 bit
- 乘以2：因为DDR（Double Data Rate）在时钟上升沿和下降沿都传输数据
- 除以8：把bit转成Byte
- 除以1000：把MHz转成GHz
举个例子：RTX 3090的显存频率是1219 MHz（等效4876 MHz），位宽384 bit。那么：
带宽 = (1219 × 384 × 2) / 8 / 1000 ≈ 117 GB/s嗯，这里要注意：实际等效频率是4876 MHz，所以更准确的计算是：
带宽 = (4876 × 384 × 2) / 8 / 1000 ≈ 468 GB/s这个数字和官方标称的936 GB/s差了一倍？别急，因为GDDR6X用了PAM4编码，每个时钟周期传输4 bit，所以还要再乘以2。最终：
带宽 = 468 × 2 = 936 GB/s你看，公式虽然简单，但细节里全是坑。
警告：不同显存类型（GDDR6、GDDR6X、HBM2e、HBM3）的传输机制不同，计算时一定要确认是否要额外乘系数。我见过有人把HBM2e的带宽算错一半，结果优化方向全偏了。
1.4 使用nvidia-smi定位显存瓶颈
nvidia-smi是咱们最趁手的工具。我一般这样用：
# 实时监控显存使用
nvidia-smi -l 1
# 只看显存相关
nvidia-smi --query-gpu=memory.total,memory.used,memory.free --format=csv
# 查看进程占用
nvidia-smi pmon -c 1关键指标解读：
- Memory-Usage：显存占用率。如果长期>90%，说明显存是瓶颈
- Volatile GPU-Util：计算单元利用率。如果这个值低但显存占用高，说明在等数据
- Processes：看看哪个进程在吃显存
我个人习惯是：先跑一轮训练，同时开三个终端——一个跑nvidia-smi -l 1，一个跑htop看CPU，一个跑Nsight Systems做profiling。这样能快速定位是「显存不够」还是「带宽不够」。
1.5 使用Nsight Systems深度分析
nvidia-smi只能看个大概，真要定位瓶颈，还得上Nsight Systems。
它的核心功能是时间线分析。你能看到：
- 每个kernel的启动时间
- 数据在CPU和GPU之间的传输时间
- 显存带宽的实际利用率
我常用的命令：
# 生成profile文件
nsys profile -o my_profile -t cuda,nvtx python train.py
# 打开GUI查看
nsys-ui my_profile.qdrep在Nsight Systems里，我重点关注两个地方：
- CUDA Memory操作：看cudaMemcpy的耗时。如果占比超过20%，说明数据传输是瓶颈
- Kernel执行时间：看每个kernel的occupancy和memory throughput。如果memory throughput接近理论带宽，说明显存带宽是瓶颈
实战经验：有一次我优化一个推荐模型，发现cudaMemcpy占了40%的时间。后来改成异步传输+流水线，直接把训练时间缩短了30%。Nsight Systems帮我找到了那个「罪魁祸首」。
1.6 知识体系总览
下面这张图，是我自己总结的显存瓶颈识别流程。你照着走一遍，基本能定位90%的问题。
这张图的核心逻辑是：先看显存容量够不够，再看带宽够不够，最后看kernel效率高不高。每一步都有对应的优化手段。
我的小习惯：每次调优前，我都会先跑一遍这个流程。它帮我省了至少一半的排查时间。你试试看，保证有用。
好了，这一章的内容就到这里。显存的基础知识、带宽计算、以及两个核心工具的使用方法，我都给你讲透了。下一章咱们聊聊更具体的优化技巧——怎么把显存「挤」出更多空间来。
想要更多资料，联系可可