4、显存瓶颈特征：OOM报错分析、显存利用率低但性能差、带宽饱和现象

做吞吐压测，最怕什么？

我个人最怕的不是性能差，而是莫名其妙地崩掉。尤其是显存相关的坑，有时候你盯着监控看半天，数据一切正常，结果程序突然就挂了。今天咱们就聊聊显存瓶颈的三种典型特征，都是我这些年踩过的坑。

4.1 OOM报错：最直接的显存瓶颈信号

OOM（Out of Memory）报错，说白了就是显存放不下了。你跑着跑着，控制台突然冒出一行红字：

RuntimeError: CUDA out of memory. Tried to allocate 2.00 GiB
GPU 0 has a total capacity of 24.00 GiB
Of which 218.00 MiB is free
Process 12345 has 22.00 GiB memory in use

嗯，这个我太熟了。刚入行那会儿，我经常被这种报错搞得焦头烂额。后来总结出几个规律：

• 显存碎片化：明明总显存还有空间，但就是分配不出连续的大块内存。我遇到过最夸张的一次，24GB显存还剩6GB，但分配一个2GB的tensor都报错。
• 内存泄漏：每次迭代都多占一点显存，跑着跑着就爆了。这种最恶心，因为前期完全看不出来。
• batch size过大：这个最直白，就是塞太多了。我建议从小的batch size开始试，逐步往上加。

4.2 显存利用率低但性能差：隐藏的瓶颈

这个现象很有意思。你打开nvidia-smi一看，显存占用才40%，但吞吐就是上不去。为什么会这样？

我个人的经验是，这往往意味着数据加载或预处理成了瓶颈。GPU在空转等数据，显存自然用不满。你想想看，GPU就像个高速流水线，如果上游供料跟不上，再快的机器也得闲着。

怎么判断？看这几个指标：

• GPU利用率：如果显存占用低，GPU利用率也低（比如低于50%），那大概率是数据加载的问题。
• CPU利用率：如果CPU跑满了，GPU闲着，那基本实锤了。
• 磁盘I/O：有时候磁盘读写成了瓶颈，尤其是从机械硬盘读数据的时候。

4.3 带宽饱和：GPU的"高速公路"堵车了

带宽饱和，是显存瓶颈里最隐蔽的一种。显存利用率可能很高，GPU利用率也很高，但吞吐就是上不去。这时候你要看的是显存带宽利用率。

我举个例子你就明白了。假设你的模型需要频繁读写显存，比如Transformer里的attention计算。每次计算都要把大量数据从显存搬到计算单元，再搬回去。如果带宽不够，计算单元就得等着数据到位，这就是所谓的内存带宽瓶颈。

怎么判断？用nvidia-smi看：

nvidia-smi --query-gpu=memory.bandwidth.utilization --format=csv

如果这个值长期超过80%，那基本就是带宽饱和了。我遇到过最典型的一个场景：

• 模型：一个超大batch的BERT训练
• 现象：GPU利用率99%，显存占用95%，但吞吐就是上不去
• 根因：attention计算需要频繁读写显存，带宽成了瓶颈

4.4 三种特征的关系与判断流程

这三种特征不是孤立的。有时候它们会同时出现，或者互相转化。我画了一张图，帮你理清思路：

这张图的核心逻辑很简单：先看OOM，再看显存利用率，最后看带宽。每一步都有对应的解决方案。我个人习惯把这个流程贴在工位上，每次压测遇到问题就按这个顺序排查，基本不会漏。

4.5 实战中的组合拳

最后分享一个我实际处理过的案例。当时在优化一个推荐系统的推理服务：

你看，显存利用率低的时候，性能反而更差。把数据加载优化好，显存用起来了，吞吐自然就上去了。这就是为什么我总说：别只看显存用了多少，要看它用得好不好。