显存优化后GPU利用率反而下降？四大瓶颈排查指南

这个系列写到现在前几篇都在教大家怎么把 LLM 训练塞进不大的显存里——梯度检查点、ZeRO、Offload、LoRA 微调恨不得把每一兆显存都榨干。显存确实省下来了但紧接着评论区就出现同一个问题为什么显存占用下去了GPU 利用率反而也掉下来了有时候nvidia-smi里只有 20%~30%显卡像是在摸鱼。先把结论扔出来你的卡大概率没有被改坏。省显存这件事本质上是拿算力、时间、带宽去换容量。当你把显存这个约束挪开系统的瓶颈就会自动往后平移落到数据加载、kernel 启动、梯度通信这些环节上。你看到的GPU 吃不满不是优化失败了而是瓶颈转移了。这篇文章就把显存省了但 GPU 吃不满的几种典型原因掰开揉碎从原理到排查都给一遍。适合手里有单卡或多卡、正在做 LLM 预训练/微调/LoRA、并且被利用率搞到头大的朋友。我不会只丢给你几个工具名字而是把为什么慢、怎么定位、怎么验证每一步都写清楚。1. 省显存的技术都不是白拿的先算清时间换空间的账很多人一开梯度检查点看到显存掉下来就觉得自己赚了但 GPU 利用率同步下降后又开始怀疑人生。这里的问题不是显存优化失效而是你没搞清楚这些技术到底是用什么换显存。1.1 梯度检查点你多算了一次前向梯度检查点Gradient Checkpointing / Activation Recomputation的原理说白了就是过河拆桥前向传播的时候不保留每一层的中间激活值只留下少数几个 checkpoint反向传播要用某层的激活值算梯度时再从最近的 checkpoint 重新做一次前向把路铺回来。账本很清楚反向阶段每一层都会额外多算一次前向整体 FLOPs 大约增加 20%~40%业界一般按 30% 左右估算。如果省下显存后你的 batch size 没变那每个 step 的计算时间就是实打实变长了——GPU 自然显得没吃满甚至比不开检查点之前更慢。但这里有个非常关键的权衡如果你把省下来的显存拿去加大 batch size 或序列长度那么一次前向重算的 30% 开销就被摊薄了因为大 GEMM 的 Tensor Core 利用率更高、kernel 效率更好单位 token 成本反而可能下降。实操上我的建议是开检查点前先想清楚省出来的显存准备拿来干嘛。如果 batch 已经顶到显卡上限无路可加那强行开检查点只会换回来更低的吞吐如果能从 batch 4 加到 8、从序列 2048 加到 4096这 30% 的额外计算就值得付。1.2 ZeRO 不是在省钱是在交通信税ZeRO 系列是 DeepSpeed 的招牌省显存技术。ZeRO-1 分片优化器状态ZeRO-2 再分片梯度ZeRO-3 把参数也分片到各卡。显存确实被摊薄了但代价是通信量的上升。ZeRO-1/2 相比普通 DDP 的 all-reduce会把一次完整的通信拆成更细粒度的 reduce-scatter 和 all-gather分段数量变多通信总字节数也略有增加。到了 ZeRO-3每次迭代前都要先从各卡 all-gather 回完整的参数反向结束后还要对分片的梯度做 reduce-scatter等于每步训练都在集群网络上搬模型。我见过不少小团队在 4 卡 4090 上用万兆以太网跑 ZeRO-3显存是省得很漂亮但 GPU 每算一会儿就要停下来等参数从其他卡传过来利用率长期在 50% 以下。单机多卡用 NVLink 时问题还不明显一旦跨机走以太网通信税就立刻变成本文主角。如果设备不多、网络又不是 NVLink/InfiniBand我通常建议优先考虑 ZeRO-1 或 ZeRO-2别一上来就上 ZeRO-3。LoRA 微调场景更没必要全量分片改用 checkpointing 加更小的 optimizer state反而能把算力用满。1.3 Offload 到 CPU数据要在 PCIe 上来回跑把优化器状态甚至参数 offload 到 CPU 内存是低显存跑模型话题里最常被提到的手段。它确实能省出大量显存但你要清楚每一轮迭代发生了什么反向结束后梯度要从显存搬到内存CPU 更新完参数后新参数又要从内存搬回显存。显存带宽是 1.5~2TB/s 级别PCIe 4.0 x16 实际也就 30GB/s 左右两个数量级的差距。搬一趟数据GPU 在那儿干等着。如果你的 batch 比较小、每步计算只要几百毫秒offload 的搬运时间很可能比计算时间还长。我的经验是offload 适合两类场景一是计算步数少、总训练时间不敏感但显存极有限的微调二是推理场景下的 KV Cache 管理而不是高频迭代的预训练/全参微调。对于训练来说offload 基本是最后手段能避免尽量避免。2. 第一个被冤枉的替罪羊DataLoader 和数据预处理排除了显存优化本身的算力开销之后如果 GPU 利用率仍然上不去下一个要怀疑的往往是数据管线。很多人在这一步就开始怀疑代码写得不对实际上十次里有大半次是数据供不上。2.1 检查 GPU 有没有断粮最典型的症状是nvidia-smi里的 GPU-Util 呈现周期性波动90% 多掉到个位数再弹回 90%循环往复。这不是你的训练代码不稳定而是 DataLoader 在某一刻没把下一个 batch 准备好GPU 只能空转等数据。为什么会断粮GPU 算一个 step 可能只要几百毫秒而 CPU 侧的数据管线要做的事远比你想象的多读取文件、反序列化、tokenize、collate、padding这些加起来可能也需要几百毫秒。两边节奏一旦对不上GPU 就有空闲。PyTorch 的 DataLoader 默认情况下每个 worker 在内存里预取 2 个 batchprefetch_factor2对于 4090、A100 这种级别的卡来说这个预取深度经常不够。如果训练循环里还有明显的 Python 侧逻辑比如每步打印 loss、执行optimizer.zero_grad()等CPU 调度的压力会更大数据断供就越频繁。这里有个简单自查在训练循环里记录一次next(iter(data_loader))的耗时。如果这个时间偶尔超过 GPU 算一个 step 的时间数据断粮就实锤了。2.2 预处理链路里藏着的 CPU 开销很多人觉得 tokenizer 很快因为跑一次 API 调用看起来只要几毫秒。但在 DataLoader worker 里每个 batch 都要对一批文本做 tokenize而 HF 的 tokenizer 的 CPU 开销不是零如果你的数据还是 JSON 格式json.loads的解析成本也不容小觑更别提把 batch 里所有样本 padding 到最大长度时多余的填充 token 会白白消耗 GPU 算力和显存。一个常见错误是数据集本身已经是 tokenize 过的 ids但训练代码里每次迭代还是做一遍 decode 再 re-tokenize白白浪费 CPU。另一个错误是明文文本数据直接丢给 DataLoader让每个 worker 在训练过程中反复做预处理。2.3 数据管线的优化套路按性价比排序我一般建议依次做这几件事离线预处理把文本提前 tokenize 成 ids存成内存映射友好的格式比如.bin、.npy或 WebDataset/Parquet。训练时 DataLoader 只负责切分和搬运不再碰 tokenizer。长度分桶bucketing把相近长度的样本放进同一个 batch避免 padding 到全 batch 最大长度。这个优化对训练吞吐的影响经常被低估短样本多一点的话节省的计算量相当可观。加大 worker 数和预取深度num_workers可以往 CPU 核数靠prefetch_factor调到 4~8观察是否缓解周期性掉 0。使用 pinned memory 和non_blockingTrue把 CPU batch 放到页锁定内存再配合Tensor.to(device, non_blockingTrue)复制数据能让数据传输与 GPU 计算部分重叠。注意prefetch_factor只对num_workers0生效。如果你还在用默认的num_workers0那数据管线是纯串行的GPU 每算一个 step 就得干等着 CPU 把下一个 batch 备好。数据管线这一层排查完之后GPU 利用率往往已经能回到 70% 以上。如果还没达标那就要往 GPU 内部看了。3. GPU-Util 100% 不代表算力吃满利用率要看第二层这是最容易误导人的地方。很多人用nvidia-smi的 GPU-Util 判断卡有没有满负荷但 100% 只是一个时间比例概念不是算力密度概念。3.1 nvidia-smi 的 100% 是个时间概念nvidia-smi的 GPU-Util 统计的是采样周期内是否有 kernel 在 GPU 上执行。只要有一个 kernel 在跑无论它把 SM 用了几成、Tensor Core 有没有转起来这段采样时间就会被记为 busy。打个比方高速路上只要有一辆车在开这条路就是被使用状态哪怕车里只装了一行李箱的货。模型训练里大量 kernel 是 Elementwise 操作比如 LayerNorm、Dropout、残差相加、激活函数这些 kernel 主要被内存带宽卡住SM 里的 Tensor Core 其实是闲置的但nvidia-smi照样打 100%。所以别再把 GPU-Util 当唯一指标。它只能告诉你 GPU有没有醒着不能告诉你干得有多卖力。3.2 用 NCU 看 Tensor Core 的真实占用率要看算力有没有吃满得用 NVIDIA 的 Nsight Computencu。训练脚本里随便挑十来个 step跑一次完整的 kernel 级分析ncu --set full --section SpeedOfLight --launch-count 20 python train.py里面最关键的是 SpeedOfLight 部分的两个百分比SM 占用率和内存占用率。如果 SM% 接近 100说明计算单元确实忙如果内存% 接近 100说明 kernel 是内存带宽瓶颈如果两者都不高而你确认 batch 已经够大那多半是 kernel 之间的空隙或同步等待造成的。想看 Tensor Core 是不是真的在干活可以单独抓这个指标ncu --metrics sm__pipe_tensor_cycles_active.avg.pct_of_peak_sustained_elapsed python train.py如果这个数字只有十几个百分点你基本可以断定就算 GPU-Util 显示 100%算力也远没有吃满。3.3 计算密集还是内存密集瓶颈维度的判断判断模型当前的瓶颈维度直接决定了你该往哪个方向优化。这里做一个粗分类launch-boundGPU 大部分时间在等 CPU 提交 kernel。特征是 kernel 本身执行时间很短但 kernel 之间空隙很大。注意这种情况在nvidia-smi里往往显示利用率不高因为空闲时间长。memory-boundSM 空闲内存总线很忙。特征是用 ncu 看时内存% 高、SM% 低GPU-Util 却可以接近 100%。compute-boundSM 和 Tensor Core 都很忙。这种状态才是理想状态优化重心放在算法本身。LLM 训练里最常见的其实是前两种的混合算 Transformer 时 GEMM 部分 compute-bound但 LayerNorm、Dropout、残差、Softmax 这些部分 memory-bound融合算子能去掉大量内存搬运这也是torch.compile能带来收益的重要原因。4. 几千个小 Kernel 的排队效应CPU 调度成了天花板如果你已经排除了数据问题也确认了不是显存优化的正常副作用但 GPU 仍旧吃不满那下一个高频嫌疑就是 kernel 发射路径。这个坑很隐蔽尤其在小模型、小 batch、LoRA 微调这类单 step 计算量不大的场景里特别常见。4.1 每次 launch 都要收 3~10 微秒的过路费在一个训练 step 里model 的 forward 和 backward 会拆成几百到几千个 kernel。1B 模型一个 step 可能有两三千个 kernel7B 模型更多。每个 kernel 从 CPU 侧发起需要经过 PyTorch 调度、CUDA driver、命令队列初始化等固定环节大概要花 3~10 微秒。问题就出在这个固定成本上。如果 GPU 上单个 kernel 运行时间也是几微秒甚至亚微秒那整个 step 的时间就被 CPU 的 launch 速度卡住了——GPU 在大部分时间里都在等 CPU 把下一个 kernel 发过来。这类问题最容易出现在 batch 偏小、单算子计算量不大、模型层数多又碎的场合。你看到 GPU-Util 在 40%~60% 徘徊但把训练日志打开每个 step 的 wall time 却并不短就是典型的被 CPU 发射速度拖死。检查方法很简单用torch.profiler导出 trace看 kernel 之间的空隙。如果 CPU time 明显远大于 CUDA time说明 GPU 在等 CPU如果一条时间线上 kernel 密密麻麻几乎没空隙那就不是 launch-bound。4.2 解法一torch.compile 算子融合torch.compile的 inductor 后端会把相邻的 elementwise 算子融合进一个 kernel顺带干掉大量中间张量的读写。一个 Transformer block 里几十个小 kernel经常能被融合到只剩几个训练吞吐的提升在小模型上尤其明显。我用一个 1.5B 左右的模型做单卡实验开torch.compile之后每 step 时间缩短了接近 30%显存占用还略有下降因为中间激活变少了。要注意两点一是首步编译时间会比较长大概几十秒到几分钟别把它当成死机二是如果你的模型里有动态 shape或者代码里有比较刁钻的 Python 控制流编译器可能会 graph break效果大打折扣。训练阶段可以接受用固定序列长度把动态 shape 尽量压住torch.compile(dynamicFalse)就好。4.3 解法二CUDA Graph 绕开 CPU 发射CUDA Graph 的思路更彻底先把整个训练 step 里所有 kernel 的发射逻辑捕获成一张图之后每次迭代只需一次极轻量的 CPU 提交GPU 就按图把 kernel 依次跑完CPU launch 开销几乎被清零。PyTorch 里有torch.cuda.graph上下文管理器用起来大概长这样g torch.cuda.CUDAGraph() # 先跑一次 warmup确定显存地址和 shape with torch.cuda.graph(g): output model(input_batch) # 每次迭代只需要复制输入然后 replay input_batch.copy_(new_batch) g.replay()但训练场景比这个复杂不少loss.backward() 和 optimizer.step() 也要在 graph 里捕获或者至少要把 forwardbackward 放进 graphoptimizer 留在外面。而且 CUDA Graph 要求 shape 和显存地址在整个捕获周期内保持不变所以 batch 必须固定、padding 必须固定动态 shape 直接触发重新捕获。如果不介意这些约束CUDA Graph 在 launch-bound 场景下的收益很大小模型提升 20%~50% 我都见过模型越大、单 kernel 时间越长收益越小大概在 5%~15% 之间。4.4 动态 shape 和 MoE 的特殊情况MoE 模型或多模态模型是 kernel launch 瓶颈的重灾区。MoE 的路由结果是动态的每个 expert 分到多少 token 每步都变kernel 的 shape 跟着变CUDA Graph 很难一把抓。常见的妥协做法是固定 expert capacity超出容量的 token 丢弃宁可损失一点点精度也要让 kernel shape 稳定从而把 graph 捕获住。另一个思路是在图内 buffer 上做计算把动态的 token 数量塞进一个固定大小的 buffer多余的部分用 mask 掉。LoRA 微调其实也容易踩这个坑。adapter 的矩阵虽然小但两个小 GEMM 加几个 elementwise 算子数量一堆CPU launch 成本一点没少。遇到这种场景优先叠加torch.compile再考虑 CUDA Graph。5. 多卡的时候GPU 是在算还是在等队友单卡问题排查完之后多卡训练还有一个巨大的隐性开销梯度同步。在这个阶段GPU 利用率低往往根本不是算力问题而是每步训练都要等所有卡把梯度对齐。5.1 All-Reduce 同步点走到台前数据并行里每张卡独立计算梯度但下一轮更新前所有卡必须拿到所有梯度。这个 all-reduce 操作是同步的所有卡都要等最慢的那张卡完成后才能进入下一个 step。算一笔账7B 模型用 bf16 训练梯度体积就有约 14GB。all-reduce 要在集群网络上把梯度来回归约再广播回去实际流量通常是梯度体积的数倍。100GbE 以太网有效带宽也就 11~12.5GB/s 左右光传梯度就要好几秒。而 7B 模型在一个 8 卡集群上单 step 的计算时间也就几秒通信占比高得离谱。NVLink 的单向带宽能到几百 GB/s单机多卡通常还好一旦跨机走以太网通信墙立刻变成主瓶颈。之前提到的 ZeRO-3 会让这个问题雪上加霜因为参数分片后每步都要 from-scratch 收集参数。5.2 梯度桶、通信重叠和 bucket_cap_mb为了解决先算完 backward 再通信的零重叠问题DDP 会把梯度按反向传播的顺序从后往前切成桶bucket一边算 backward 一边对已经填满的桶发起通信让通信和计算重叠。这里有个值得调的参数bucket_cap_mb。默认是 25MB但对大模型来说桶太多会导致通信被切成大量小段碎片化严重桶太大又会推迟通信启动重叠效果变差。我在 7B 模型上试过把bucket_cap_mb调到 50~100step time 有可感知的下降。即便做了通信计算重叠每个 step 终归还是有同步尾巴——最慢的那张卡的最后一小块梯度必须等所有人到齐。这是数据并行的结构性成本减不了太多只能靠提高计算/通信比去摊薄。5.3 通信与计算的比例为什么大 batch 更划算通信总字节量由模型大小决定单张卡的 GPU 算力再强也省不掉。真正能改的是一次性同步前算了多少活。加大 batch size同样一次 all-reduce对应的计算量更大通信占比下降。梯度累积gradient accumulation注意它不会减少通信总字节只是把同步频率降下来让 GPU 在多个 mini-step 里连续算再统一同步一次。网络慢、GPU 算力快的小集群上这是一招很实用的缓兵之计。梯度压缩、梯度稀疏化通信量下降明显但是否影响收敛需要单独验证。我之前在 4 机 8 卡的千兆规模集群上调优时光是把 batch size 从 8 拉到 32并配合梯度累积到等效 batch 128GPU 利用率就从 40% 涨到了 80% 左右。通信量一点没少但 GPU 每算两秒才同步一次等待比例大幅下降。6. 一次完整排查实录从干瞪眼到定位根因前面把理论讲完了如果你已经对着自己的训练日志开始挠头那我把一次实际排查的完整链路放出来。这套流程我每次遇到显存省了但 GPU 吃不满都会走一遍通常半天内能定位。6.1 第一步用 dmon 记录利用率的波动模式先别急着上 profiler先用最简单的工具把整体观感拿到nvidia-smi dmon -s pcu -d 1盯一分钟看 GPU 利用率的波动模式如果 GPU-Util 稳定在低位几乎没有尖峰重点怀疑 kernel launch 或通信。如果 GPU-Util 周期性掉 0再弹回来重点怀疑数据管线。如果多卡利用率出现各卡参差不齐的错位重点怀疑负载不均或通信同步。我记得有一次排查一个 22B 模型微调任务显存只用了 14G 不到GPU-Util 在 25%~45% 之间抖动看起来像数据断供但 dmon 显示 vmem 和 SM 时钟都很稳定就意识到可能是 kernel 层面的问题。6.2 第二步把 step 时间拆开看在训练循环里插最简单的时间戳把每个 step 切成数据获取、forward、backward、optimizer 四段step_times [] for step in range(total_steps): t0 time.time() x, y next(data_iter) # data_fetch t1 time.time() out model(x) # forward t2 time.time() loss loss_fn(out, y) loss.backward() # backward t3 time.time() optimizer.step() optimizer.zero_grad() step_times.append([t1-t0, t2-t1, t3-t2, time.time()-t3])跑 50 个 step 之后看中位数和 p95。如果 data_fetch 的中位数超过了几百毫秒甚至和 forward 时间一个量级数据管线就是第一嫌疑。那次排查里data_fetch 中位数 400msforward 才 300ms前半段时光全耗在等数据上了。6.3 第三步用 Profiler 找空隙时间戳只能定位到哪个阶段慢还想再进一步就得看 kernel 层面。PyTorch 自带的 profiler 足够用了from torch.profiler import profile, ProfilerActivity, schedule with profile( activities[ProfilerActivity.CPU, ProfilerActivity.CUDA], scheduleschedule(wait5, warmup5, active10, repeat1), record_shapesTrue ) as prof: for step in range(100): train_step() prof.step() print(prof.key_averages().table(sort_bycuda_time_total, row_limit30))看两个东西CPU time 总量和 CUDA time 总量的比值以及 kernel 时间线上有没有明显的空洞。如果 CPU time 比 CUDA time 高一大截就是 launch 瓶颈如果 CUDA time 总量还不到 wall time 的一半说明 GPU 有大把时间在等。要更细的 GPU 时间线用 Nsight Systemsnsys profile -o train_profile --statstrue python train.pynsys stats train_profile.nsys-rep能直接看到 GPU 利用率、kernel 数量、CUDA API 等待时间。这个工具基本是我排查这类问题的最后一道大锤。6.4 第四步用开关实验锁定真凶工具定位完还要用单变量实验验证因果而不是看个热闹。把梯度检查点关掉重新计时。如果 step time 明显下降、利用率上升说明是检查点重算造成的算力开销远超预期此时最优解是检查点保持开启、同时把 batch 加大到显存边界。把 DataLoader worker 数从 4 加到 16prefetch_factor调到 8。如果利用率明显提升数据断供实锤。开torch.compile或 CUDA Graph。记住每次只改一个变量否则你永远不知道是不是多个因素叠加出来的。那次排查最后的结果很典型把num_workers从 4 加到 16、prefetch_factor调到 8 后GPU-Util 从 40% 跳到了 70%再叠加torch.compile稳定到 85%。显存优化本身没有任何问题纯粹是省下来的显存没让 GPU 干更多活反而让它在原地等数据。现象重点检查项常见根因顺手解法GPU-Util 周期性掉 0data fetch 耗时DataLoader 断供加 worker/prefetch、离线 tokenizeGPU-Util 低但稳定kernel 间空隙launch 瓶颈torch.compile、CUDA GraphGPU-Util 接近 100% 但训练慢NCU SpeedOfLightmemory-bound 小 kernel 多算子融合、减少中间张量多卡利用率参差/上不去all-reduce 时间通信墙加大 batch、梯度累积、调整 bucket_cap_mb开检查点后明显变慢A/B 开关对比检查点重算开销同时加大 batch或选择性 checkpointing最后聊点排查之外的体会。这套流程里最常用的工具就是nvidia-smi dmon、torch.profiler、nsys这三个但比工具更重要的是建立瓶颈转移的直觉——显存省下来只是第一关GPU 吃不满才是把系统真正的短板暴露出来。我个人的习惯是每次只改一个变量把 step time 的分布中位数和 p95记下来而不是只看平均值这样你才能分辨某个优化是稳赚还是只是拉平了极端情况。如果你也遇到过显存明明没满、GPU 利用率就是上不去的怪事不妨把训练日志里的时间分布和 kernel trace 拿出来对照一下八成能在上面四类原因里找到答案。要是找到的根因不在列表里欢迎把现象发在评论区这种奇怪问题往往是最涨经验的。