GPU利用率低？从12%到80%的排查与优化实战

上线前夜，我盯着nvidia-smi的输出，GPU-Util 那一栏稳稳停在 12%。后台压测流量已经拉满，数百个并发请求在服务里排队，机器轰鸣，可显卡却像集体午休。那种感觉就像装了个火箭发动机，结果油管被堵成吸管，火苗再旺也推不动车身。我先把这句话记下来：GPU 利用率低，绝大多数时候不是 GPU 的问题，而是它在上游没等到活干。

这篇文章想复盘的就是这次“上线前夜”的故障驱动优化。从 12% 到 80% 以上，我只动了几段配置和一批调用方式，没有换卡、没有改模型结构、没有加机器。整个过程涉及指标解读、工具链定位、数据管线剖析、batch 策略调整和 CUDA Graphs 实战，适合做 AI 推理服务、模型训练，或者发现 GPU 花钱不干活的工程师参考。没基础的读者也不要紧，我会把涉及的概念用最直白的方式讲清楚，你可以直接拿着操作步骤回到自己的环境里试。

1. 先别急着改代码：重新看懂 nvidia-smi 里的 12%

1.1 GPU-Util 到底在测什么

很多人的第一反应是“单卡利用率 12%，那就堆卡”。我先泼一盆冷水：nvidia-smi显示的这个GPU-Util，和 CPU 的负载百分比不是一回事。它统计的是在过去一个采样窗口内，SM（流式多处理器）上有多少个周期在执行计算指令，取一个平均占比。说得直白一点，它衡量的是“计算单元被指令占用的密度”，不是“这台机器忙不忙”，更不代表显存用了多少。

所以 12% 意味着：你的 SM 绝大部分时间处于空转或者等待状态。真正干活的时间可能很短，但每次干完之后，下一批数据迟迟没来。模型推理的前向计算也许只需要几百微秒，但前处理、数据搬移、Python 调用链条把每次请求的端到端时间拉长到了几十毫秒。GPU 在中间那段时间里除了等着，什么都做不了。

我见过不少团队对“GPU 利用率”有一套错误执念：看到 90% 就开心，看到 20% 就焦虑。实际上 90% 也可能很糟糕——比如训练脚本里每个 step 都做一次.item()然后打印 loss，虽然 SM 一直在跑，但跑的那些 kernel 可能又碎又小，真正的有效吞吐远低于理论值。反过来，12% 也未必是灾难，要配合延迟和吞吐指标一起看。但在我们这次场景里，12% 确实就是灾难，因为它代表系统明明接了这么多请求，却交付不了应有的吞吐量。

1.2 第一轮观察：别只盯一个数字

我习惯先跑一条命令，看整体趋势：

nvidia-smi dmon -c 100 -d 1

dmon 的输出比默认视图信息更多，能同时看到 SM 利用率（gr 列）、显存带宽（fb 列）、显存占用（mem 列）、功耗（pwr 列）和温度（tm 列）。尤其是功耗这一项，如果pwr也偏低，说明 GPU 是真的没怎么发力，不是“算力跑满但报告不准”。接着再用一次查询确认关键指标：

nvidia-smi --query-gpu=index,utilization.gpu,memory.used,power.draw,temperature.gpu --format=csv -l 2

那一晚我看到的数据是：SM 利用率 12%，显存占用却到了 13GB，功耗远低于满载。这是典型的“显存有东西、SM 没东西”——模型权重都在显存里躺着，但前向计算就是喂不满 SM。此时基本可以判断问题不在 GPU 内部，而是外部在供货不足。

为了确认不是多卡之间负载不均，我还看了一眼所有卡的利用率和 NVLink/PCIe 链路。多卡场景里有一张卡只有个位数利用率很常见，因为每张卡的输入分配不均衡会导致某个 rank 变成木桶短板。我们这次是 8 张卡的推理集群，卡间差不多都是 12% 左右，说明是共性瓶颈，不是某一卡坏了或者调度偏斜。

2. 工具链排查：从“卡住的线程”到“空转的 SM”

2.1 用 py-spy 和 perf 找出谁在拖后腿

确认 GPU 侧没坏之后，下一步就是判断瓶颈在哪一层：是 CPU 上的预处理算太慢，还是数据从内存搬到显存的路上太慢，或者是 GPU kernel 本身太小导致启动开销淹没了计算时间。

我第一个开刀的是 Python 进程。直接py-spy dump --pid <服务进程号>，看到所有线程当前的函数调用栈。这一步能非常直观地告诉你 Python 线程到底在等什么：是卡在socket.recv上等请求，是卡在队列get()上等数据，还是在 numpy 的像素变换循环里出不来。我们那晚的输出显示，大量 worker 线程阻塞在数据队列的get()上，而少数几个线程长时间停留在图像解码和 resize 的调用栈里。说明“产数据”的线程只有一两个，消费能力远大于供给能力。

再上perf top看 CPU 层面的热点。如果看到memcpy、cudaMemcpyAsync、page fault相关的符号占比很高，说明数据搬移路径上有严重的复制开销。如果看到libtorch.so里的算子调度函数占比较高，说明框架层在频繁做 kernel launch，GPU 每次启动的时间可能比计算本身还长。

记住这个顺序：先用系统工具缩小范围，再上专业 Profiler 看细节，不要一上来就对着代码猜。

2.2 Nsight Systems 才是救命工具

系统工具能看出“大概卡在哪”，但看不出“GPU 在等谁”。我直接用了 Nsight Systems：

nsys profile --trace=cuda,nvtx,osrt,python --output=report my_inference.py

它生成的时间轴会同时展示 CPU 上的 Python 函数活动和 GPU 上 kernel 的执行区间。你能非常直观地看到两件事：

• 相邻两个 CUDA kernel 之间是否有巨大空白段；
• 空白段对应的 CPU 那侧在跑什么函数。

我们抓到的特征非常典型：每个 batch 的 kernel 执行区只有短短一段，随后就是一个接近两三百毫秒的巨大空隙，空隙里 CPU 在跑图像前处理、显式.cpu()转换、numpy 拼接列表。GPU 在那个长空白里完全空闲，这就是 12% 的直接来源。

如果 Nsights 显示 kernel 之间没有大空白，但 kernel 本身执行时间远大于理论时间，那问题更可能出在 kernel 内部，这时候应该上 Nsight Compute（ncu）去看具体的 SM 吞吐、内存吞吐、warp 占用率。我们这次的场景属于前者，所以后面的优化主线很明确：压缩 CPU 处理链，让 GPU 永远有 kernel 可跑。

2.3 给问题重新建模：生产者与消费者的接力赛

把推理服务抽象成一条流水线：网络请求进来 -> 预处理（解码、resize、归一化）-> 从 CPU 内存拷贝到 GPU 显存 -> GPU kernel 计算 -> 后处理 -> 返回结果。

GPU 利用率不高相当于流水线后段的“机器”在等前段“送料”。生产者的速度决定消费者的利用率。想提 GPU 利用率，要么提高生产者速度，要么给消费者“多存点待加工原料”，也就是缓冲队列和预取机制。明白了这个接力赛模型，后面所有优化动作都能回归到一个公式：让下游投入的工作量始终大于上游的消耗能力，并且保持两者尽量重叠。

3. 三层瓶颈拆解：数据、批次和启动开销

3.1 第一关：数据加载与预处理链

我们服务原生的预处理逻辑是这样的：每个请求进来，分配给一个 Python worker，然后 worker 顺序执行解码、缩放、转 tensor、归一化，最后拼 batch 送 GPU。问题显而易见：预处理在 CPU 上，且是完全串行的。单张图片的预处理大概要 80 毫秒，而 GPU 前向计算只要不到 10 毫秒，生产者的速度只是消费者的十分之一。

我见过很多团队犯同一个错误：把注意力全放在模型参数上，但前处理写得很随意，for循环里还嵌套 N 个np.array、.tolist()、.copy()。这些东西每一处看起来很快，叠起来就能让 GPU 饿死。数据管线的优化空间往往比模型本身还大。

还要注意“队列阻塞”这个隐藏雷区。Python 的queue.Queue在放入和取出大量数据时会有锁竞争，worker 数量一多反而会更慢。有人在服务里为了提高吞吐，把 num_workers 加到了 32，结果 GIL 和锁竞争导致 CPU 全部打满，数据没变多，GPU 反而更低。合适 worker 数需要实测，不是越大越好。

3.2 第二关：batch size 与 GPU 算力的匹配

把数据送到 GPU 之后，下一个问题是每次送多少。单个请求直接推理时，kernel 的启动开销和执行开销完全不成比例。打个比方，GPU 就像一辆核载 30 人的班车，启动一次的成本是固定的。你每次只拉 1 个人，虽然车一直在跑，但人均运输效率低下。SM 上有大量执行单元因为 batch 太小而闲置。

动态 batch 的原理就是在固定时间窗内攒请求，攒到一定数量，或者窗口到期，就把这一堆请求合并成一个 batch 送 GPU 一次算完。这样做能让单个 kernel 里的数据规模变大，SM 吞吐自然就上来了。代价是第一批请求的等待时间会变长，所以窗口不能设太大，通常用“最大 batch 数 + 最大等待毫秒数”双约束。

也有团队把这个度调过头，为了 GPU-Util 好看把 window 设到 100ms，结果所有请求的 P99 延迟飙到了 500ms。指标好看了，业务挂了。记住：我们优化 GPU 利用率是为了吞吐和成本，不是为了一个数字有多漂亮，牺牲延迟去换 high util 是最蠢的曲线救国。

3.3 第三关：kernel 启动开销与框架层等待

即便数据量够大，模型复杂的情况下，如果每个算子都从 Python 侧发出一条指令，那 launch 开销也会成为隐形瓶颈。PyTorch 默认每次调用模型都会经过 Python 解释器下发 kernel。核函数数量多但每个都很短时，GPU 会不断在“启动”和“完成”之间切换，SM 实际有效计算占比低。

这类情况在 T5、BERT 这类小算子密集的模型上特别典型。Stacked RNN、LayerNorm、Attention 里的多个小矩阵乘法，都是 kernel 启动开销的重灾区。单看单个 kernel 的执行时间都在 5 到 10 微秒，但一个模型里有几百个这样的 kernel，它们之间还有等待和同步，累计起来就把 GPU 的“有效工作时间”稀释得所剩无几。

还有一类隐藏开销来自 Python 侧的显式同步调用：torch.cuda.synchronize()、.item()、.cpu()、每步都 print loss。这些操作会强制 CPU 等待 GPU 完成，把流水线的“异步感”彻底打断。我在排查中顺手 grep 了一遍项目，发现测试代码里竟有 3 处.item()加打印，虽然每处只损失几十毫秒，但对一个追求低延迟的模型来说是加倍浪费。

4. 优化实操：把 12% 拉起来的四个步骤

4.1 杀招一：把数据管线从“串行阻塞”改成“异步预取”

我们彻底重构了预处理端的执行模式。原来每个 worker 都同步等待图片前处理完成，现在改成：请求先进一个线程池，线程池里的 worker 只负责把原始字节扔给一个多进程的预处理池，预处理池在后台并行跑解码和 resize，结果放进一个带预取容量的队列。模型的主循环只做一件事：从队列里取“已经是 tensor 的数据”，然后送 GPU。

这里有两个关键配置参数值得写下来：

• pin_memory=True。锁页内存在 host 到 device 的传输中可以不经过可分页内存的临时拷贝，直接走 DMA，减少一次隐性 memcpy。
• non_blocking=True。配合锁页内存，它能让拷贝操作变成异步，CPU 不用傻等拷贝完成。

如果你用的是 PyTorch 的 DataLoader，直接这样挂配置：

DataLoader( dataset, batch_size=32, num_workers=8, prefetch_factor=4, pin_memory=True, persistent_workers=True, )

num_workers=8意味着有 8 个进程并行准备数据；prefetch_factor=4表示每个 worker 会提前准备 4 个 batch 放进队列。这两个值并不总是越大越好，需要根据 CPU 核数和实际负载做调优。我们最终定的是 8 和 4，CPU 占用率大概在 75%，GPU 开始能稳定吃饱。

如果你自己写异步队列，推荐用multiprocessing而不是threading，因为在 CPU 密集的前处理场景里，Python 线程和 GIL 会互相争抢；多进程才能真正并行利用多核。如果团队已经在用 Ray，也可以直接用它的 actor 池做并行预处理，道理一样。

4.2 杀招二：用 pinned memory 和 Async 搬移消除 PCIe 停顿

数据准备好之后，下一步是快速从 CPU 内存搬到 GPU。很多人写代码时直接在 GPU tensor 初始化处用默认的 pageable memory：

input_tensor = torch.from_numpy(np_array).cuda()

这一句话的问题在于：.cuda()默认是同步拷贝，而且numpy数组在普通内存里，从普通内存到显存的拷贝需要先复制到锁页缓存，再走 PCIe。虽然每次拷贝只有几毫秒，但架不住请求量大，PCIe 阶段每次都让 GPU 空等。

改成这样：

# 显式分配锁页内存 pinned_array = torch.empty((batch_size, 3, 224, 224), dtype=torch.float32, pin_memory=True) pinned_array.copy_(numpy_batch, non_blocking=True) input_tensor = pinned_array.cuda(non_blocking=True)

non_blocking=True让拷贝变成异步操作，GPU 可以在拷贝进行的时候执行别的 kernel。在很多推理框架中，把输入张量统一放到 pinned memory，然后搭配 CUDA Stream 在不同 batch 之间交错传输和执行，能让 PCIe 的传输和计算重叠起来。

别小看这一步，在处理的 batch 不大的场景下，pin_memory+non_blocking往往能带来 20% 到 40% 的吞吐提升。如果你们的数据量更大，甚至可以调研 GPUDirect Storage / RDMA 方案，让数据从网卡或 NVMe 绕过 CPU 直接进显存，但这个要看硬件和基础设施的支持情况，踩坑成本不低。

4.3 杀招三：把算子启动压成一张图

如果模型 kernel 数量太多、每个都很短，靠数据管线已经救不回来，就该上 CUDA Graphs。它的思路是：把一连串 kernel 启动通过 API 捕获并固化为一整张图，之后每次执行都复放这张图，彻底省掉 CPU 逐条下发 kernel 的开销。相当于把你的模型从“每次临时排演一遍”变成“录制好一场完整演出，每次直接播录像”。

PyTorch 里启用 CUDA Graphs 的路径大概是这样：

# 先固定输入 shape，并做 warmup g = torch.cuda.CUDAGraph() s = torch.cuda.Stream() with torch.cuda.stream(s): for _ in range(3): output = model(input_tensor) torch.cuda.synchronize() # 捕获整张计算图 with torch.cuda.graph(g): output = model(input_tensor) # 之后每次推理 g.replay()

有几个坑会埋得比较深：

• 捕获时必须有稳定显存占用，不能在捕获过程中分配新的显存。所以输入输出张量必须先预先分配好。
• 模型必须是静态 shape 的。如果你的模型在推理时会根据输入长度动态变化，要么用多个静态图的组合，要么先 padding 到固定长度。
• CUDA Graphs 会占用额外显存，因为输出张量要长期驻留，不会自动释放。显存小的卡要注意。

效果如何？我们部署的模型有大约 120 个小 kernel，CUDA Graphs 直接省掉了大约 40% 的 kernel 启动时间。GPU-Util 没有立刻上升很多，因为处理器空闲的次数减少了，但延迟和吞吐都有改善。如果你不想手写 graphs，直接给模型加@torch.compile让编译器自动做算子融合和 graph 化，也能拿到一部分收益。

compiled_model = torch.compile(model, mode="reduce-overhead")

reduce-overhead模式会减少 Python 侧和 kernel 间的调度开销，对小算子密集型模型特别有效。但注意，torch.compile的编译冷启动很慢，不适合每次重启都频繁触发，生产环境建议提前 warmup 或保存编译产物。

4.4 杀招四：按业务需求设计正确的动态批处理策略

最后一块拼图是批次策略。线上推理的高效形态往往是动态 batch 而不是固定 batch。固定 batch 的问题是：为了攒够 32 个请求可能等太久，或者请求来太快时积压。

我们最终实现的策略非常简单：

1. 设置一个等待窗口，例如 6ms；
2. 窗口内收集请求，达到最大 batch 数（例如 32）就立即开算；
3. 窗口到期还不满，也开算，减轻首包延迟压力。

核心逻辑：

def scheduled_loop(): pending = [] deadline = None while True: if len(pending) >= max_batch: run_batch(pending) pending = [] elif deadline and now() > deadline: if pending: run_batch(pending) pending = [] deadline = None elif deadline is None: deadline = now() + wait_ms # 接新请求

关键参数是max_batch和wait_ms。max_batch受显存和模型最大支持 batch 影响；wait_ms直接决定延迟。我们当时压测取的点是：max_batch=24、wait_ms=6，P99 延迟增加了约 40ms，但吞吐量翻了两倍多，GPU 利用率终于能稳定在 80% 左右。

再次强调：不要为了数字好看牺牲业务指标。如果你做的是在线接口，用户对延迟极其敏感，你可以把wait_ms调小甚至设成 0，那时 GPU 利用率低反而是正常的，因为你根本没有那么多请求同时到达。反过来，如果你既有高吞吐任务又有低延迟任务，最好拆成两个队列，分别跑不同的 batch 策略，不要混在一起。

5. 复盘、监控与“利用率不等于健康度”的清醒认知

5.1 优化前后的数据对比

上线前夜的整个压测过程，我记录了一张关键对比表：

吞吐翻了四倍多，延迟增加 40ms 左右，但单请求 GPU 耗时大幅下降，说明同样的请求量现在只需要更少的 GPU 算力就能跑完，这对应的就是硬件成本下降。如果当时没有这一段排查，我们上线后大概率会面临请求量一大就排队超时的线上故障，然后不得不临时扩容买卡。省下来的资源费用是实打实的。

5.2 监控怎么布，才能避免下次上线再慌

这之后我给团队写了一份 GPU 服务的监控标准清单，避免每次都靠人肉盯nvidia-smi：

• 每张卡都采集DCGM_FI_DEV_SM_UTIL、DCGM_FI_DEV_MEM_COPY_UTIL、DCGM_FI_DEV_POWER_USAGE、DCGM_FI_DEV_TEMPERATURE、PCIe 吞吐、NVLink 利用率。
• 对推理服务，额外采集 batch 大小分布、队列深度、等待窗口命中率、preprocess 耗时、inference 耗时、P50/P95/P99 延迟。
• 对训练任务，重点关注 MFU（模型浮点运算利用率）而不是单纯的 GPU-Util。一个 batch 内前向、反向、参数更新各占多少时间，这个数据能帮你判断是不是通信等待太久。
• 告警阈值不能用“GPU-Util < 20%”这种拍脑袋的值。应该基于“该服务的目标吞吐未达成”来告警。比如吞吐低于预期且 GPU 利用率也低，才说明上游阻塞；吞吐达标但 GPU 利用率低，说明你有余量，根本不用管。

我用 Grafana 建了一页“瓶颈诊断”视图，把 GPU SM util、CPU 前处理耗时、队列积压长度、PCIe 吞吐放在同一个时间轴上。之后再看到 SM util 低，直接按这个顺序读了：队列积压是否高？高则请求过载，低则 CPU 生产慢；PCIe 吞吐是否高？高则搬移也可能阻塞；然后再决定下一步看哪里。

5.3 一个反直觉的结论：GPU 利用率低不总是坏事

优化做完后，我想讲一个容易被新团队误解的点：GPU 利用率不是越高越好。

如果你只有一个低频接口，每天请求量就一两百次，每次 batch=1，那么 GPU-Util 长期是个位数是正常的，因为它真的不需要那么多计算量。这时候你强行上动态 batch、CUDA Graphs、多 worker 预取，只会把代码复杂度拉高、延迟恶化，成本反而上升。

判断 GPU “该不该更忙”，不是看绝对数值，而是看你的目标吞吐约束和延迟预算。只要延迟达标、吞吐够用，GPU 利用率低说明你还有很多冗余算力，性能余量是好事。真正该警惕的是：吞吐上不去、延迟劣化，GPU 还闲着，那才意味着系统有结构性瓶颈。

我们这次 12% 之所以是问题，是因为业务目标摆在那里，压测流量已经大到正常逻辑应该能打满卡，卡却闲着。优化后它跑到了 82%，但我在监控页上不会对“82%”再设置什么“应该冲到 95%”的 KPI。因为再往上压，延迟就会崩溃，得不偿失。

最后分享一个从那晚学到的检查技巧：遇到 GPU 利用率低，不要一上来就打开模型代码翻网络结构。先花五分钟确认数据生产者、队列缓冲、PCIe 搬移、kernel 启动这四段的耗时占比，任何一个环节是短板，GPU 就算堆到 100 卡也白搭。你可以用nsys profile生成时间轴后统计各阶段耗时比例，这个过程比盲目优化省力得多。

我自己的习惯是，在每次压测前都先看一眼“数据准备耗时 / GPU 计算耗时”的比值。这个比值大于 3，就说明 GPU 大概率吃不饱；小于 0.5，才适合认真分析模型和算子的效率。你下次上线前夜如果能用这个思路排查，大概率不用像我一样在凌晨盯着 dmon 发呆。