简介：GPU 显存使用率与算力利用率是两个容易混淆但本质不同的指标。本文从存储与计算的解耦关系出发，分析显存占满而算力未跑满的常见原因，对比两类资源瓶颈的差异，并给出定位与优化方向，帮助开发者在训练与推理任务中更准确地评估 GPU 真实利用效率。
在 GPU 任务调优中，一个常见困惑是：监控面板上显存已经接近满载，但计算利用率却并不高，甚至远低于预期。此时如果直接判断“GPU 已经跑满”，往往会掩盖真正影响吞吐和延迟的问题。
要理解这一现象，需要先明确两个基本概念：
两者并不存在必然的正相关关系。显存占用高，只说明“数据放了很多”，但不代表“数据正在被计算”。算力利用率高，则要求计算核心持续获得可执行的计算任务，并减少等待数据、等待调度或等待同步的时间。
因此，评估 GPU 是否被高效使用，不能只看显存使用率，还需要结合计算核心利用率、内存带宽利用率以及任务执行时间等指标一起判断。
可以把 GPU 看作一个由仓库和工人组成的系统。显存相当于仓库，负责容纳原材料、半成品和成品；计算核心相当于工人，负责对原材料进行加工。仓库堆满货物，只能说明存储空间吃紧，并不能说明工人正在高效工作。
更具体地说：
这也是二者从监控指标上容易产生割裂的原因。一个任务可以占用大量显存，却只触发少量计算；另一个任务可能显存占用不高，但计算密度极大，算力利用率却很高。
某些算子计算本身非常简单，但需要频繁读写显存。例如逐元素加法、乘法、激活函数中的部分操作，计算量很低，但需要从显存读取输入张量，再写出结果张量。此时，计算核心的大量时间消耗在等待数据到达，而不是执行运算。
这类问题本质上是内存带宽受限，而非计算受限。常见于数据处理、归一化、掩码生成、形状变换等场景。
部分操作会生成大尺寸中间结果，占用大量显存，但计算量却很小。例如：
这些操作往往具有较高的显存写入量，但单位数据上的运算密度偏低，难以充分利用 GPU 的大量计算核心。
在大模型训练或微调中，模型参数、优化器状态和梯度可能已经占满大部分显存。此时如果批大小仅为 1 或 2，单次前向与反向传播无法形成足够多的并行任务。
GPU 擅长同时执行大量相似计算，如果可并行任务太少，相当于大量计算核心处于空闲状态。即使显存已经吃满，每个计算步骤中真正激活的计算核心比例仍然可能很低。
有些计算流程天然存在先后依赖，例如时间步递归、自回归生成、需要等待上一阶段结果的算子。在这些场景下，即使所有数据都已在显存中准备好，后续计算也必须等待前序步骤完成。
这种串行依赖会导致 GPU 无法同时调度足够多的计算任务，拉低整体算力利用率。典型如推理阶段逐 token 生成、某些循环结构、多阶段流水线中的同步点。
如果代码中大量启动小规模 kernel，GPU 会在调度、启动和回收等过程中消耗大量时间，而实际计算时间占比很低。每个小 kernel 之间的空隙会使计算核心难以持续工作。
例如对张量逐项处理、频繁进行小矩阵运算、在循环中反复调用简单算子等，都可能引发这类问题。
训练或推理循环中如果包含大量条件判断、动态控制流或同步读取标量结果的操作，GPU 会频繁停下来等待 CPU 决策。例如反复调用同步接口获取损失值、指标值或某个张量元素，都会打断 GPU 执行节奏。
这种同步会把原本可以连续执行的计算任务切碎，显著降低计算核心的利用时间。
为了更清晰地判断当前任务更接近哪一类瓶颈，可以从以下维度进行对比：
| 对比维度 | 显存瓶颈 | 算力瓶颈 |
|---|---|---|
| 主要表现 | 显存使用率接近上限，可能出现内存不足或碎片化 | 显存可能未满，但计算核心利用率长期处于高位 |
| 受限资源 | 显存容量、激活值规模、模型大小 | 计算核心数量、指令吞吐、并行度 |
| 常见任务 | 大模型训练、长序列处理、大 batch 推理 | 高计算密度任务，如大矩阵乘法、卷积计算 |
| 优化方向 | 降低显存占用、显存复用、梯度检查点 | 提高并行度、减少等待、融合算子 |
| 性能表现 | 容易任务失败或触发显存回收 | 不会直接失败，但吞吐下降、延迟上升 |
| 监控关注点 | 显存使用率、碎片情况、峰值占用 | 计算核心利用率、带宽利用率、kernel 时间占比 |
需要强调的是，两类瓶颈可能同时存在，也可能在不同阶段交替出现。例如训练阶段显存吃紧，推理阶段算力利用率不足；或者在同一个模型中，某些层显存占用高，而另一些层计算密度低。
定位问题时，可以先观察几个关键信号：
显存已满，但计算核心利用率长期偏低
通常说明存在大量数据等待、串行依赖或小规模计算。此时应重点分析算子耗时分布和数据传输占比。
显存未满，但计算核心利用率接近上限
通常说明任务计算密度较高，计算核心在持续工作。此时即使显存没有占满，也可能已经是计算瓶颈。
显存和算力都没有占满，但吞吐上不去
常见原因是 CPU 与 GPU 同步频繁、数据加载慢、任务调度碎片化或通信开销大。
显存偶发性飙升，任务失败或触发回收
这类情况更偏向显存峰值控制问题，需要关注激活值、中间结果和临时缓冲区的生命周期。
通过对比“计算时间 / 总执行时间”与“显存读取等待时间 / 总执行时间”，可以粗略判断任务更偏向哪一类瓶颈。若计算时间占比很低，而数据搬运时间占比很高，则说明算力空闲主要来自内存带宽受限。
批大小越大，单次前向与反向计算中可并行任务越多，计算核心越容易被填满。但批大小受显存容量限制，需要结合显存占用情况进行调节。
适用条件：当前显存未完全耗尽，且模型单样本启动开销较高。
注意点：过大批大小可能导致收敛行为变化，需要适度调整学习率等超参数。
将多个小操作合并为一个 kernel，可以减少调度开销，提高计算密度。例如把逐元素计算、归一化和部分激活操作合并执行，降低中间结果写回显存的次数。
适用条件：计算图中存在大量轻量级算子，且这些算子之间无明显依赖。
注意点：融合可能增加单 kernel 的复杂度，需要保证数值稳定性和可维护性。
当某些操作计算密度过低、显存写入过多时，可以考虑使用矩阵乘法等高计算密度算子替代循环或逐项操作。例如将部分归一化、注意力计算组织成矩阵运算，以提升单位显存访问对应的计算量。
适用条件：算法逻辑允许用矩阵乘或归约操作等价替换。
注意点：不同实现方式可能在内存占用和计算量之间产生权衡，需要整体评估。
减少在训练循环中读取标量、判断条件或强制同步的次数，让 GPU 尽可能长时间保持连续计算。必要时可将控制逻辑移到 GPU 端，或使用异步方式处理指标记录。
适用条件：当前任务存在较多同步点和动态控制流。
注意点：完全消除同步并不现实，但可以降低对关键路径的打断频率。
如果显存占满限制了大 batch 和并行度，可以借助梯度检查点、激活重计算、显存复用和低精度存储等手段降低显存占用，从而为更大批大小或更长序列留出空间，间接提升算力利用率。
适用条件：显存瓶颈先于算力利用率提升出现。
注意点：部分方法可能引入额外计算或带宽开销，需要在显存与计算之间做取舍。
以 Transformer 类模型为例：
这些场景说明，显存占用与算力利用率应分别监控、分别优化，不应混为一谈。
在性能调优中，建议先判断当前更靠近哪类瓶颈，再有针对性地调整：
更合适的指标组合是同时观察显存使用率、计算核心利用率、内存带宽利用率以及每秒完成的有效样本数。不同任务对这三类资源的敏感度不同，不能仅凭单一指标判断性能好坏。
如果计划对现有 GPU 任务进行调优或迁移，需要注意以下几点：
GPU 显存用满而算力未用满，本质上是“存储资源耗尽”与“计算资源闲置”同时发生。显存只管数据放得下，算力才管数据算得快。真正高效的 GPU 任务，应尽量让计算核心处于持续工作状态，同时保持显存占用处于可控范围。
判断与优化 GPU 性能时，不能只看显存使用率。更合理的做法是：将显存使用率、计算核心利用率、内存带宽利用率和任务吞吐综合起来分析，先识别瓶颈类型，再选择合适的优化策略。只有在正确的位置解决正确的问题，才能让 GPU 从“显存占满”走向“算力真正跑满”。