1. 显存省下来了GPU 为什么还是吃不满显存优化做到位了nvidia-smi一看显存占用从 22GB 降到 9GB心里美滋滋结果watch -n 0.5 nvidia-smi盯了十分钟GPU 利用率死活卡在 35% 到 50% 之间来回跳功耗也上不去风扇都不怎么转。这个场景我见过太多次了不管是自己搭的 LLM Training Lab还是帮别人看训练脚本十有八九都会撞上这个坎。先把结论摆出来显存和算力是两条独立的流水线显存省下来只代表你能塞进更大的 batch 或者更长的序列不代表 SM流式多处理器就有活干。GPU 吃不满本质上是数据供给、计算调度、通信同步这三条链路里至少有一条堵住了。显存优化解决的是装得下的问题而 GPU 利用率解决的是喂得饱的问题两者根本不是一回事。这篇内容适合谁看如果你正在用 PyTorch 跑 LLM 训练已经折腾过 gradient checkpointing、ZeRO、LoRA、量化这些显存优化手段但发现 GPU 利用率上不去、训练速度没提升、step time 反而变长了那这篇就是写给你的。我会从数据管线、算子调度、通信开销、CPU-GPU 协同这几个角度把显存省了但 GPU 吃不满这件事拆开讲清楚每个环节都给出可复现的排查方法和调优参数。需要提前说明的是下面涉及的具体参数和配置一部分来自我自己的实验记录一部分是基于 PyTorch 官方文档和常见工程实践做的合理推演你在自己环境里复现时数值可能需要根据实际硬件做微调。2. 先搞清楚 GPU 利用率到底在测什么2.1 nvidia-smi 的利用率是个谎言很多人把nvidia-smi里的GPU-Util当成 GPU 的真实负载这个理解有偏差。这个百分比的含义是在采样周期内至少有一个 kernel 在 SM 上处于活跃状态的时间占比。注意关键词——至少一个。哪怕你的 GPU 有 132 个 SM只有 1 个 SM 在跑一个很小的 kernel利用率照样显示 100%。这就解释了为什么有时候你看到利用率 95%但训练速度还是很慢——因为大部分 SM 在摸鱼只有少数几个在干活。反过来利用率 40% 也不一定代表 GPU 闲可能是 kernel 之间有间隙间隙里 SM 确实没活干。真正能反映 GPU 是否吃饱的指标是这几个SM OccupancySM 占用率每个 SM 上活跃 warp 数量与理论最大值的比值用 Nsight Compute 或者torch.cuda的 profiler 能看Tensor Core 利用率如果你的模型用了混合精度这个指标比 GPU-Util 有意义得多Memory Throughput显存带宽利用率LLM 训练里这个经常是真正的瓶颈Power Draw功耗上不去基本可以断定 GPU 没吃满我一般会同时开三个窗口一个nvidia-smi -l 1看粗粒度一个nvidia-smi dmon -s pucvmet看细粒度再挂一个 PyTorch profiler 抓 timeline。三个对不上问题基本就定位了。2.2 显存优化和算力利用是两码事这里要澄清一个常见的认知误区。显存优化手段大致分几类优化手段省的是什么对 GPU 利用率的影响Gradient Checkpointing激活值显存增加计算量可能降低利用率ZeRO / FSDP优化器状态、梯度分片增加通信可能降低利用率LoRA / QLoRA可训练参数量减少计算量利用率可能下降量化INT8/INT4权重和激活显存需要反量化可能增加开销Flash AttentionAttention 中间矩阵通常提升利用率梯度累积等效 batch 显存不改变单步利用率看出来了吧大部分显存优化手段要么增加计算量要么增加通信量要么减少单步计算量。它们让你能跑更大的模型但不保证跑得更快。Gradient checkpointing 是最典型的例子——它用 30% 左右的额外计算换显存如果你的瓶颈本来就在计算那开了它只会更慢。所以显存省下来了GPU 还是吃不满这个现象很多时候不是 bug而是这些优化手段的固有代价。真正要做的是找到当前配置下的真实瓶颈然后针对性解决。3. 数据管线最常见的饿死GPU 的元凶3.1 DataLoader 的 num_workers 和 pin_memory我敢说LLM 训练里 GPU 吃不满一半以上的原因是 DataLoader 喂数据太慢。尤其是当你做指令微调、多轮对话训练的时候数据预处理tokenize、padding、mask 构造的耗时经常被低估。先看几个关键参数from torch.utils.data import DataLoader dataloader DataLoader( dataset, batch_size8, num_workers8, # 关键参数 pin_memoryTrue, # 关键参数 prefetch_factor4, # 关键参数 persistent_workersTrue,# 关键参数 shuffleTrue, drop_lastTrue, )num_workers设多少合适经验公式是CPU 物理核心数 / GPU 数量但实际要看数据预处理复杂度。如果你的__getitem__里要做复杂的 tokenize 和 mask 构造可以设到核心数的 1.5 倍。设太多反而会因为进程切换开销导致变慢。pin_memoryTrue的作用是把数据放到锁页内存pinned memory这样 CPU 到 GPU 的拷贝可以用 DMA 直接传输速度能快 2 到 3 倍。这个参数很多人忘了开开了之后 H2D 拷贝时间能明显下降。prefetch_factor控制每个 worker 预取多少个 batch默认是 2。在数据预处理慢的场景下调到 4 到 8 能有效平滑数据供给。persistent_workersTrue让 worker 进程在 epoch 之间不销毁重建省掉每次 epoch 开始的进程启动开销。数据量小、epoch 多的时候效果明显。3.2 用 profiler 确认数据管线是不是瓶颈光看参数没用得实测。PyTorch profiler 能直接告诉你时间花在哪import torch from torch.profiler import profile, ProfilerActivity with profile( activities[ProfilerActivity.CPU, ProfilerActivity.CUDA], scheduletorch.profiler.schedule(wait1, warmup1, active3, repeat2), on_trace_readytorch.profiler.tensorboard_trace_handler(./log), record_shapesTrue, profile_memoryTrue, ) as prof: for step, batch in enumerate(dataloader): if step 10: break outputs model(**batch) loss outputs.loss loss.backward() optimizer.step() optimizer.zero_grad() prof.step()跑完之后看 trace重点看DataLoader相关的 CPU 操作和cudaMemcpyAsync之间的间隙。如果 timeline 上 GPU 有明显的空白段而空白段对应的 CPU 侧在跑__getitem__或者 tokenize那基本可以确诊是数据管线瓶颈。我踩过的一个坑数据集用了 HuggingFace 的datasets库map的时候没设num_proc结果 tokenize 是单进程跑的训练时每个 batch 都要现场 tokenizeGPU 等得花儿都谢了。后来改成预处理阶段用num_proc16一次性 tokenize 完训练时直接读 token id利用率从 45% 拉到 85%。3.3 数据格式和 IO 的隐藏开销数据存成什么格式对读取速度影响巨大。我做过对比测试同样 100 万条指令数据存储格式单次读取耗时备注JSON Lines120ms需要逐行解析Parquet35ms列式存储压缩好Arrow / HuggingFace datasets18ms内存映射零拷贝预 tokenize 的 numpy memmap8ms最快但灵活性差WebDataset (tar shards)12ms适合大规模分布式如果你的数据还在用 JSON Lines 存每次__getitem__都要json.loads那 GPU 不饿才怪。建议至少换成 Parquet 或者 Arrow 格式预处理阶段把 tokenize 做完训练时只做 tensor 拼接。还有一个容易忽略的点数据在机械硬盘上还是 SSD 上。LLM 训练数据动辄几十上百 GB如果放在机械盘上随机读取的 IOPS 根本跟不上。我见过一个案例训练脚本本身没问题就是数据放在了一块老机械盘上GPU 利用率死活上不去换到 NVMe SSD 之后直接翻倍。4. 算子调度与 kernel 间隙GPU 在等 CPU 发号施令4.1 Python 解释器和 GIL 的锅PyTorch 的训练循环是 Python 写的每个 step 里 CPU 要做的事情包括从 DataLoader 取 batch、把 tensor 搬到 GPU、构造计算图、启动各个 kernel、更新优化器状态。这些操作里kernel 启动是异步的但 Python 侧的调度是同步的。当模型比较小、单个 kernel 执行时间很短的时候CPU 启动 kernel 的速度可能跟不上 GPU 执行的速度GPU 就会在 kernel 之间出现间隙。这就是所谓的kernel launch bound。判断方法用 Nsight Systems 抓 timeline看 GPU 上 kernel 之间是否有明显空隙。如果有且空隙对应的 CPU 侧在跑 Python 代码那就是 launch bound。缓解手段有几个增大 batch size每个 kernel 执行时间变长相对间隙占比下降使用 CUDA Graph把整个 step 的 kernel 序列捕获成一个图一次启动消除逐个 kernel 的启动开销torch.compilePyTorch 2.0 之后的编译器能把 Python 侧的调度开销大幅降低减少 CPU 侧同步操作比如.item()、.cpu()、print(loss)这些都会强制同步CUDA Graph 在 LLM 训练里效果特别明显。我实测过一个 7B 模型的训练开 CUDA Graph 之前 step time 是 1.8s开了之后降到 1.3sGPU 利用率从 55% 拉到 78%。用法也不复杂# 简单示意实际使用需要处理动态 shape 和随机性 g torch.cuda.CUDAGraph() static_input torch.zeros_like(batch) with torch.cuda.graph(g): static_output model(static_input) loss static_output.loss loss.backward() optimizer.step() # 训练循环里 static_input.copy_(batch) g.replay()注意 CUDA Graph 对动态 shape 不友好LLM 训练里如果序列长度变化大需要做 padding 到固定长度或者用分段捕获。4.2 小算子过多导致的调度开销LLM 里有很多逐元素操作element-wise比如 LayerNorm、激活函数、残差连接、dropout。这些操作单独看都很快但数量多了之后kernel 启动开销和显存访问开销会累积。一个典型的 Transformer block 里逐元素操作的 kernel 数量可能占到 60% 以上但计算量占比不到 10%。这就是为什么算子融合operator fusion在 LLM 训练里这么重要。torch.compile能自动做一部分融合但效果取决于后端。更彻底的做法是用融合 kernel比如Flash Attention把 attention 的多个步骤融合成一个 kernelFused LayerNormApex 或者 xformers 提供的融合实现Fused Adam把优化器更新融合成少量 kernel我一般会先上torch.compile看能提升多少如果还不够再手动替换关键算子。torch.compile的用法model torch.compile(model, modemax-autotune)max-autotune模式会花更多编译时间但生成的 kernel 通常更快。第一次跑会慢因为要编译之后就好了。注意编译缓存要保留不然每次重启都要重新编译。4.3 同步点那些悄悄拖慢训练的调用训练循环里有些操作会强制 CPU 和 GPU 同步每次同步都会让 GPU 停下来等 CPU。常见的同步点包括loss.item()或者loss.cpu()为了打印 lossprint(tensor)会触发 tensor 的 repr需要同步if loss threshold条件判断需要把 GPU 上的值取回 CPUtorch.cuda.synchronize()显式同步某些自定义的 logging 逻辑我见过最离谱的一个案例训练循环里每个 step 都print(loss.item())而且 print 还带了一堆格式化字符串。GPU 每个 step 都要停下来等 Python 打印完利用率直接腰斩。改成每 100 步记录一次且用loss.detach()避免保留计算图利用率立刻上去了。正确的做法是把需要同步的操作攒起来批量处理。比如每 100 步记录一次 loss用torch.cuda.Event做计时日志写到内存里最后统一落盘。5. 通信开销分布式训练里的隐形杀手5.1 数据并行下的 all-reduce如果你用 DDPDistributedDataParallel做数据并行每个 step 结束都要做一次梯度 all-reduce。这个通信量和模型参数量成正比7B 模型用 FP16 就是 14GB 的通信量。如果网络带宽不够GPU 就会在等通信。判断方法看 timeline 上 all-reduce kernel 的耗时占比。如果超过 20%说明通信是瓶颈。缓解手段梯度累积多个 step 才做一次 all-reduce通信频率降低通信与计算重叠DDP 默认会尝试 overlap但效果取决于 bucket 大小调整 bucket_cap_mbDDP 的bucket_cap_mb参数控制梯度分桶大小默认 25MB调大能减少通信次数但增加显存用 NCCL 的调优参数比如NCCL_ALGO、NCCL_PROTOmodel DDP( model, device_ids[local_rank], bucket_cap_mb100, # 调大 bucket gradient_as_bucket_viewTrue, # 省显存 static_graphTrue, # 如果模型结构固定开启能优化 )static_graphTrue这个参数很多人不知道开启后 DDP 能做一些图级别的优化通信效率能提升 10% 到 20%。前提是你的模型在训练过程中计算图不变LLM 训练一般满足。5.2 ZeRO / FSDP 的通信代价ZeRO 和 FSDP 通过分片优化器状态、梯度、参数来省显存但代价是更多的通信。ZeRO-3 每个 step 都要 all-gather 参数通信量比 DDP 大好几倍。如果你的显存优化用的是 ZeRO-3 或者 FSDP 的 full shardGPU 吃不满很可能是通信瓶颈。这时候可以考虑降级到 ZeRO-2只分片优化器状态和梯度通信量小很多混合分片FSDP 支持sharding_strategy配置可以选SHARD_GRAD_OP而不是FULL_SHARD增大计算通信比增大 batch size 或者序列长度让每次通信对应的计算量更大我个人的经验是单机多卡场景下ZeRO-2 通常比 ZeRO-3 更划算除非模型大到 ZeRO-2 装不下。多机场景下通信更贵要更谨慎地选择分片策略。5.3 通信和计算的 overlap理想情况下通信应该和计算重叠GPU 在等通信的时候应该还有别的活干。但实际中 overlap 效果往往不理想原因包括通信和计算依赖同一个 stream无法并行bucket 划分不合理通信粒度太细网络带宽本身就不够PyTorch 2.x 之后FSDP 的 overlap 做得比之前好但还是要看具体配置。可以用torch.profiler看通信 kernel 和计算 kernel 是否真的重叠了。如果 timeline 上通信和计算是串行的那 overlap 没生效需要检查配置。6. 实操排查流程从现象到根因6.1 第一步建立基线在开始调优之前先建立一个干净的基线。用一个最简单的配置跑一遍记录以下指标# 终端 1粗粒度监控 nvidia-smi -l 1 # 终端 2细粒度监控 nvidia-smi dmon -s pucvmet -d 1 # 终端 3训练脚本 python train.py 21 | tee baseline.log基线配置建议batch size 设为能跑起来的最小值关闭所有显存优化gradient checkpointing、ZeRO 等关闭混合精度数据管线用最简单的配置记录 step time、GPU 利用率、显存占用、功耗。这个基线是后续所有对比的参照。6.2 第二步逐项开启优化观察变化每次只开一个优化观察指标变化。我一般按这个顺序开混合精度AMP看 step time 和利用率开 Flash Attention看 attention 部分耗时开 gradient checkpointing看显存和 step time 的 trade-off开 torch.compile看整体提升开分布式如果有看通信开销每开一项记录 step time、GPU 利用率、显存占用。如果某一项开了之后利用率反而下降说明这项优化在当前配置下不划算要么调整参数要么放弃。6.3 第三步用 profiler 定位瓶颈基线建立之后用 profiler 抓一次详细的 timelineimport torch from torch.profiler import profile, ProfilerActivity, tensorboard_trace_handler def train_step(model, batch, optimizer): outputs model(**batch) loss outputs.loss loss.backward() optimizer.step() optimizer.zero_grad() return loss with profile( activities[ProfilerActivity.CPU, ProfilerActivity.CUDA], scheduletorch.profiler.schedule(wait2, warmup2, active6, repeat1), on_trace_readytensorboard_trace_handler(./profiler_log), record_shapesTrue, profile_memoryTrue, with_stackTrue, ) as prof: for step, batch in enumerate(dataloader): if step 20: break loss train_step(model, batch, optimizer) prof.step()跑完之后用 TensorBoard 打开./profiler_log看 timeline。重点看GPU 上是否有空白段空白段对应的 CPU 侧在做什么哪些 kernel 耗时最长通信 kernel 占比多少显存分配和释放的模式6.4 常见瓶颈速查表现象可能原因排查方法解决方向GPU 利用率低timeline 有空白数据管线慢看 DataLoader 耗时增 num_workers、预处理数据GPU 利用率低kernel 间隙大kernel launch bound看 kernel 间空隙CUDA Graph、torch.compileGPU 利用率低通信 kernel 占比高通信瓶颈看 all-reduce 耗时梯度累积、调 bucket、换分片策略GPU 利用率高但速度慢小算子过多看 kernel 数量和耗时算子融合、torch.compile显存够但 batch 上不去激活值显存看显存分配gradient checkpointingstep time 波动大数据或 IO 不稳定看 step time 分布换存储、预处理功耗上不去GPU 没吃满看 power draw综合排查上述各项7. 几个容易被忽略的细节7.1 混合精度里的 dtype 转换开销AMP自动混合精度能省显存、加速计算但 dtype 转换本身有开销。如果模型里频繁在 FP16 和 FP32 之间转换开销会累积。torch.cuda.amp.autocast会自动管理转换但有些操作比如 LayerNorm、softmax在 FP16 下数值不稳定需要保持 FP32。这些例外操作会导致额外的转换。我一般会用torch.compile配合 AMP让编译器做更激进的融合和转换优化。另外bfloat16在数值稳定性上比float16好如果硬件支持Ampere 及以上优先用bfloat16。from torch.cuda.amp import autocast, GradScaler scaler GradScaler() with autocast(dtypetorch.bfloat16): outputs model(**batch) loss outputs.loss scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()注意bfloat16不需要 GradScaler因为它的动态范围和 FP32 一样。用float16才需要。7.2 优化器状态的内存布局Adam 优化器每个参数要存两个状态一阶矩和二阶矩如果用 FP32 存显存占用是参数量的 8 倍。7B 模型就是 56GB这也是为什么大家要用 ZeRO 或者 8-bit Adam。但优化器状态的内存布局也会影响性能。如果状态张量在显存里是碎片化的访问效率会下降。PyTorch 的foreach实现会把多个参数的状态合并操作减少 kernel 数量optimizer torch.optim.AdamW( model.parameters(), lr1e-4, foreachTrue, # 开启 foreach 实现 fusedTrue, # 如果可用用融合 kernel )foreachTrue在参数多的时候效果明显能把优化器更新的 kernel 数量从几百个降到几个。fusedTrue需要 CUDA 支持效果更好但兼容性差一些。7.3 梯度累积和 batch size 的等效关系梯度累积是省显存的常用手段但要注意它和 batch size 的等效关系。假设你想要的等效 batch size 是 64但显存只够放 8那就累积 8 次accumulation_steps 8 for step, batch in enumerate(dataloader): outputs model(**batch) loss outputs.loss / accumulation_steps loss.backward() if (step 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()注意 loss 要除以accumulation_steps否则梯度会放大。另外BatchNorm 这类依赖 batch 统计的层在梯度累积下行为和真实大 batch 不一样LLM 里一般用 LayerNorm 所以没这个问题。梯度累积的代价是每个 micro-step 都要做一次前向和反向但优化器更新频率降低。如果瓶颈在优化器更新梯度累积能加速如果瓶颈在前向反向计算梯度累积不改变单步计算量利用率不会提升。7.4 显存碎片和 caching allocatorPyTorch 的 CUDA caching allocator 会缓存显存块减少cudaMalloc调用。但缓存策略不当会导致碎片表现为显存够但分配失败。可以用环境变量调整export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:Trueexpandable_segments让 allocator 能扩展已分配的段减少碎片。PyTorch 2.1 之后支持效果不错。另外torch.cuda.memory_summary()能打印详细的显存分配情况包括碎片率。如果碎片率高可以考虑定期torch.cuda.empty_cache()但注意这会释放缓存下次分配又要重新cudaMalloc有开销不要频繁调用。8. 一个完整的调优案例8.1 初始状态假设我们有一个 7B 模型的指令微调任务单卡 A100 80GB初始配置batch size 4序列长度 2048FP32 训练无 gradient checkpointingDataLoader num_workers4无 torch.compile实测step time 3.2sGPU 利用率 42%显存占用 68GB功耗 180W。8.2 逐项优化第一步开 AMPbfloat16step time 降到 2.1s利用率 58%显存降到 42GB功耗 240W。提升明显。第二步开 Flash Attentionstep time 降到 1.7s利用率 65%显存降到 38GB。Attention 部分耗时从 0.6s 降到 0.25s。第三步DataLoader 调优num_workers 从 4 调到 12pin_memoryTrueprefetch_factor4。step time 降到 1.5s利用率 72%。timeline 上数据管线的空白段基本消失。第四步torch.compilestep time 降到 1.2s利用率 80%。编译花了 3 分钟但之后每个 step 都受益。第五步CUDA Graphstep time 降到 1.0s利用率 88%。注意序列长度要 padding 到固定值。第六步优化器调优AdamW 开 foreach 和 fusedstep time 降到 0.95s利用率 90%。最终step time 从 3.2s 降到 0.95s加速 3.4 倍GPU 利用率从 42% 拉到 90%功耗 320W。8.3 关键观察这个案例里显存优化AMP、Flash Attention和利用率优化DataLoader、torch.compile、CUDA Graph是交替进行的。每一步都观察指标确认有效再进入下一步。如果某一步没效果甚至变慢就回退。另外注意优化是有顺序的。如果先开 CUDA Graph 再调 DataLoaderCUDA Graph 的效果会被数据管线的空白段掩盖看起来提升不大。正确的顺序是先解决数据供给再解决 kernel 调度。9. 一些反直觉的经验9.1 有时候降低 batch size 反而更快听起来反直觉但在某些配置下确实如此。如果 batch size 太大导致显存压力大caching allocator 频繁触发碎片整理或者 gradient checkpointing 被强制开启那降低 batch size 反而能让每个 step 更快。我遇到过一个大 batch 导致 attention 的中间矩阵超出 SRAM 容量Flash Attention 退化到慢路径的情况。batch 减半之后attention 走快路径整体速度反而提升。9.2 不是所有优化都要开gradient checkpointing 省显存但增加计算如果你的显存本来就够开了只会变慢。同理ZeRO-3 在多机场景下通信开销巨大如果模型能塞进单机用 DDP 更划算。优化的原则是先测量再优化只优化瓶颈。不要因为某个技术听起来很厉害就无脑上。9.3 监控本身也有开销nvidia-smi -l 1每秒采样一次开销可以忽略。但如果你在训练循环里频繁调用torch.cuda.memory_allocated()或者torch.cuda.utilization()这些调用会触发同步拖慢训练。监控要用外部工具不要在训练循环里做。日志记录也要攒批不要每个 step 都写盘。10. 工具链和版本选择10.1 PyTorch 版本PyTorch 2.x 之后torch.compile和 FSDP 的成熟度大幅提升。如果还在用 1.x建议升级。但注意 CUDA 版本和驱动的兼容性升级前先在测试环境验证。我目前用的组合是 PyTorch 2.3 CUDA 12.1 cuDNN 8.9稳定性不错。torch.compile在这个版本下对 LLM 的支持已经比较完善。10.2 辅助工具Nsight Systems抓 timeline看 kernel 和通信Nsight Compute分析单个 kernel 的性能PyTorch Profiler集成在 PyTorch 里方便Weights Biases / TensorBoard记录训练指标nvitop比 nvidia-smi 更友好的监控工具nvitop我强烈推荐界面清晰能同时看多个 GPU 的利用率、显存、功耗、温度还能看进程级别的占用。安装pip install nvitop运行nvitop就行。10.3 环境变量调优# NCCL 调优 export NCCL_ALGORing # 或 Tree取决于拓扑 export NCCL_PROTOSimple # 或 LL取决于消息大小 export NCCL_NSOCKS_PERTHREAD4 export NCCL_SOCKET_NTHREADS2 # CUDA 调优 export CUDA_DEVICE_MAX_CONNECTIONS1 # 减少 stream 数量降低调度开销 export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True # 线程调优 export OMP_NUM_THREADS8 # 根据 CPU 核心数调整CUDA_DEVICE_MAX_CONNECTIONS1这个参数在 kernel launch bound 的场景下有效能减少 stream 之间的切换开销。但注意它可能影响通信和计算的重叠要实测。11. 最后再分享几个实操技巧第一个技巧用 dummy data 做基准测试。在排查数据管线问题的时候把 DataLoader 换成一个生成随机 tensor 的 dummy loader如果 GPU 利用率立刻上去了那问题就在数据侧。这个方法能快速排除数据管线的嫌疑。第二个技巧二分法定位瓶颈。如果 timeline 很复杂不知道从哪下手可以把模型截断只跑前几层看利用率。如果前几层利用率就低问题在数据或调度如果前几层正常后面低问题在模型结构或通信。第三个技巧关注 step time 的方差不只看均值。如果 step time 波动大说明有间歇性的瓶颈比如数据 IO 抖动、GC 暂停、其他进程干扰。用torch.cuda.Event记录每个 step 的耗时画个分布图比看均值有用得多。第四个技巧显存优化和利用率优化分开做。先把显存压到能跑再单独调利用率。两个一起调变量太多很难定位问题。第五个技巧保留一个能跑的最简配置。调优过程中经常会改坏保留一个 baseline 脚本随时能回退对比。我一般会把 baseline 的 commit hash 记下来出问题就git checkout回去。这些经验都是踩坑踩出来的你在自己环境里复现的时候硬件、驱动、库版本不同具体数值会有差异但排查思路是通用的。核心就一句话先测量再优化只优化瓶颈每次只改一个变量。
1. 显存省下来了GPU 为什么还是吃不满显存优化做到位了nvidia-smi一看显存占用从 22GB 降到 9GB心里美滋滋结果watch -n 0.5 nvidia-smi盯了十分钟GPU 利用率死活卡在 35% 到 50% 之间来回跳功耗也上不去风扇都不怎么转。这个场景我见过太多次了不管是自己搭的 LLM Training Lab还是帮别人看训练脚本十有八九都会撞上这个坎。先把结论摆出来显存和算力是两条独立的流水线显存省下来只代表你能塞进更大的 batch 或者更长的序列不代表 SM流式多处理器就有活干。GPU 吃不满本质上是数据供给、计算调度、通信同步这三条链路里至少有一条堵住了。显存优化解决的是装得下的问题而 GPU 利用率解决的是喂得饱的问题两者根本不是一回事。这篇内容适合谁看如果你正在用 PyTorch 跑 LLM 训练已经折腾过 gradient checkpointing、ZeRO、LoRA、量化这些显存优化手段但发现 GPU 利用率上不去、训练速度没提升、step time 反而变长了那这篇就是写给你的。我会从数据管线、算子调度、通信开销、CPU-GPU 协同这几个角度把显存省了但 GPU 吃不满这件事拆开讲清楚每个环节都给出可复现的排查方法和调优参数。需要提前说明的是下面涉及的具体参数和配置一部分来自我自己的实验记录一部分是基于 PyTorch 官方文档和常见工程实践做的合理推演你在自己环境里复现时数值可能需要根据实际硬件做微调。2. 先搞清楚 GPU 利用率到底在测什么2.1 nvidia-smi 的利用率是个谎言很多人把nvidia-smi里的GPU-Util当成 GPU 的真实负载这个理解有偏差。这个百分比的含义是在采样周期内至少有一个 kernel 在 SM 上处于活跃状态的时间占比。注意关键词——至少一个。哪怕你的 GPU 有 132 个 SM只有 1 个 SM 在跑一个很小的 kernel利用率照样显示 100%。这就解释了为什么有时候你看到利用率 95%但训练速度还是很慢——因为大部分 SM 在摸鱼只有少数几个在干活。反过来利用率 40% 也不一定代表 GPU 闲可能是 kernel 之间有间隙间隙里 SM 确实没活干。真正能反映 GPU 是否吃饱的指标是这几个SM OccupancySM 占用率每个 SM 上活跃 warp 数量与理论最大值的比值用 Nsight Compute 或者torch.cuda的 profiler 能看Tensor Core 利用率如果你的模型用了混合精度这个指标比 GPU-Util 有意义得多Memory Throughput显存带宽利用率LLM 训练里这个经常是真正的瓶颈Power Draw功耗上不去基本可以断定 GPU 没吃满我一般会同时开三个窗口一个nvidia-smi -l 1看粗粒度一个nvidia-smi dmon -s pucvmet看细粒度再挂一个 PyTorch profiler 抓 timeline。三个对不上问题基本就定位了。2.2 显存优化和算力利用是两码事这里要澄清一个常见的认知误区。显存优化手段大致分几类优化手段省的是什么对 GPU 利用率的影响Gradient Checkpointing激活值显存增加计算量可能降低利用率ZeRO / FSDP优化器状态、梯度分片增加通信可能降低利用率LoRA / QLoRA可训练参数量减少计算量利用率可能下降量化INT8/INT4权重和激活显存需要反量化可能增加开销Flash AttentionAttention 中间矩阵通常提升利用率梯度累积等效 batch 显存不改变单步利用率看出来了吧大部分显存优化手段要么增加计算量要么增加通信量要么减少单步计算量。它们让你能跑更大的模型但不保证跑得更快。Gradient checkpointing 是最典型的例子——它用 30% 左右的额外计算换显存如果你的瓶颈本来就在计算那开了它只会更慢。所以显存省下来了GPU 还是吃不满这个现象很多时候不是 bug而是这些优化手段的固有代价。真正要做的是找到当前配置下的真实瓶颈然后针对性解决。3. 数据管线最常见的饿死GPU 的元凶3.1 DataLoader 的 num_workers 和 pin_memory我敢说LLM 训练里 GPU 吃不满一半以上的原因是 DataLoader 喂数据太慢。尤其是当你做指令微调、多轮对话训练的时候数据预处理tokenize、padding、mask 构造的耗时经常被低估。先看几个关键参数from torch.utils.data import DataLoader dataloader DataLoader( dataset, batch_size8, num_workers8, # 关键参数 pin_memoryTrue, # 关键参数 prefetch_factor4, # 关键参数 persistent_workersTrue,# 关键参数 shuffleTrue, drop_lastTrue, )num_workers设多少合适经验公式是CPU 物理核心数 / GPU 数量但实际要看数据预处理复杂度。如果你的__getitem__里要做复杂的 tokenize 和 mask 构造可以设到核心数的 1.5 倍。设太多反而会因为进程切换开销导致变慢。pin_memoryTrue的作用是把数据放到锁页内存pinned memory这样 CPU 到 GPU 的拷贝可以用 DMA 直接传输速度能快 2 到 3 倍。这个参数很多人忘了开开了之后 H2D 拷贝时间能明显下降。prefetch_factor控制每个 worker 预取多少个 batch默认是 2。在数据预处理慢的场景下调到 4 到 8 能有效平滑数据供给。persistent_workersTrue让 worker 进程在 epoch 之间不销毁重建省掉每次 epoch 开始的进程启动开销。数据量小、epoch 多的时候效果明显。3.2 用 profiler 确认数据管线是不是瓶颈光看参数没用得实测。PyTorch profiler 能直接告诉你时间花在哪import torch from torch.profiler import profile, ProfilerActivity with profile( activities[ProfilerActivity.CPU, ProfilerActivity.CUDA], scheduletorch.profiler.schedule(wait1, warmup1, active3, repeat2), on_trace_readytorch.profiler.tensorboard_trace_handler(./log), record_shapesTrue, profile_memoryTrue, ) as prof: for step, batch in enumerate(dataloader): if step 10: break outputs model(**batch) loss outputs.loss loss.backward() optimizer.step() optimizer.zero_grad() prof.step()跑完之后看 trace重点看DataLoader相关的 CPU 操作和cudaMemcpyAsync之间的间隙。如果 timeline 上 GPU 有明显的空白段而空白段对应的 CPU 侧在跑__getitem__或者 tokenize那基本可以确诊是数据管线瓶颈。我踩过的一个坑数据集用了 HuggingFace 的datasets库map的时候没设num_proc结果 tokenize 是单进程跑的训练时每个 batch 都要现场 tokenizeGPU 等得花儿都谢了。后来改成预处理阶段用num_proc16一次性 tokenize 完训练时直接读 token id利用率从 45% 拉到 85%。3.3 数据格式和 IO 的隐藏开销数据存成什么格式对读取速度影响巨大。我做过对比测试同样 100 万条指令数据存储格式单次读取耗时备注JSON Lines120ms需要逐行解析Parquet35ms列式存储压缩好Arrow / HuggingFace datasets18ms内存映射零拷贝预 tokenize 的 numpy memmap8ms最快但灵活性差WebDataset (tar shards)12ms适合大规模分布式如果你的数据还在用 JSON Lines 存每次__getitem__都要json.loads那 GPU 不饿才怪。建议至少换成 Parquet 或者 Arrow 格式预处理阶段把 tokenize 做完训练时只做 tensor 拼接。还有一个容易忽略的点数据在机械硬盘上还是 SSD 上。LLM 训练数据动辄几十上百 GB如果放在机械盘上随机读取的 IOPS 根本跟不上。我见过一个案例训练脚本本身没问题就是数据放在了一块老机械盘上GPU 利用率死活上不去换到 NVMe SSD 之后直接翻倍。4. 算子调度与 kernel 间隙GPU 在等 CPU 发号施令4.1 Python 解释器和 GIL 的锅PyTorch 的训练循环是 Python 写的每个 step 里 CPU 要做的事情包括从 DataLoader 取 batch、把 tensor 搬到 GPU、构造计算图、启动各个 kernel、更新优化器状态。这些操作里kernel 启动是异步的但 Python 侧的调度是同步的。当模型比较小、单个 kernel 执行时间很短的时候CPU 启动 kernel 的速度可能跟不上 GPU 执行的速度GPU 就会在 kernel 之间出现间隙。这就是所谓的kernel launch bound。判断方法用 Nsight Systems 抓 timeline看 GPU 上 kernel 之间是否有明显空隙。如果有且空隙对应的 CPU 侧在跑 Python 代码那就是 launch bound。缓解手段有几个增大 batch size每个 kernel 执行时间变长相对间隙占比下降使用 CUDA Graph把整个 step 的 kernel 序列捕获成一个图一次启动消除逐个 kernel 的启动开销torch.compilePyTorch 2.0 之后的编译器能把 Python 侧的调度开销大幅降低减少 CPU 侧同步操作比如.item()、.cpu()、print(loss)这些都会强制同步CUDA Graph 在 LLM 训练里效果特别明显。我实测过一个 7B 模型的训练开 CUDA Graph 之前 step time 是 1.8s开了之后降到 1.3sGPU 利用率从 55% 拉到 78%。用法也不复杂# 简单示意实际使用需要处理动态 shape 和随机性 g torch.cuda.CUDAGraph() static_input torch.zeros_like(batch) with torch.cuda.graph(g): static_output model(static_input) loss static_output.loss loss.backward() optimizer.step() # 训练循环里 static_input.copy_(batch) g.replay()注意 CUDA Graph 对动态 shape 不友好LLM 训练里如果序列长度变化大需要做 padding 到固定长度或者用分段捕获。4.2 小算子过多导致的调度开销LLM 里有很多逐元素操作element-wise比如 LayerNorm、激活函数、残差连接、dropout。这些操作单独看都很快但数量多了之后kernel 启动开销和显存访问开销会累积。一个典型的 Transformer block 里逐元素操作的 kernel 数量可能占到 60% 以上但计算量占比不到 10%。这就是为什么算子融合operator fusion在 LLM 训练里这么重要。torch.compile能自动做一部分融合但效果取决于后端。更彻底的做法是用融合 kernel比如Flash Attention把 attention 的多个步骤融合成一个 kernelFused LayerNormApex 或者 xformers 提供的融合实现Fused Adam把优化器更新融合成少量 kernel我一般会先上torch.compile看能提升多少如果还不够再手动替换关键算子。torch.compile的用法model torch.compile(model, modemax-autotune)max-autotune模式会花更多编译时间但生成的 kernel 通常更快。第一次跑会慢因为要编译之后就好了。注意编译缓存要保留不然每次重启都要重新编译。4.3 同步点那些悄悄拖慢训练的调用训练循环里有些操作会强制 CPU 和 GPU 同步每次同步都会让 GPU 停下来等 CPU。常见的同步点包括loss.item()或者loss.cpu()为了打印 lossprint(tensor)会触发 tensor 的 repr需要同步if loss threshold条件判断需要把 GPU 上的值取回 CPUtorch.cuda.synchronize()显式同步某些自定义的 logging 逻辑我见过最离谱的一个案例训练循环里每个 step 都print(loss.item())而且 print 还带了一堆格式化字符串。GPU 每个 step 都要停下来等 Python 打印完利用率直接腰斩。改成每 100 步记录一次且用loss.detach()避免保留计算图利用率立刻上去了。正确的做法是把需要同步的操作攒起来批量处理。比如每 100 步记录一次 loss用torch.cuda.Event做计时日志写到内存里最后统一落盘。5. 通信开销分布式训练里的隐形杀手5.1 数据并行下的 all-reduce如果你用 DDPDistributedDataParallel做数据并行每个 step 结束都要做一次梯度 all-reduce。这个通信量和模型参数量成正比7B 模型用 FP16 就是 14GB 的通信量。如果网络带宽不够GPU 就会在等通信。判断方法看 timeline 上 all-reduce kernel 的耗时占比。如果超过 20%说明通信是瓶颈。缓解手段梯度累积多个 step 才做一次 all-reduce通信频率降低通信与计算重叠DDP 默认会尝试 overlap但效果取决于 bucket 大小调整 bucket_cap_mbDDP 的bucket_cap_mb参数控制梯度分桶大小默认 25MB调大能减少通信次数但增加显存用 NCCL 的调优参数比如NCCL_ALGO、NCCL_PROTOmodel DDP( model, device_ids[local_rank], bucket_cap_mb100, # 调大 bucket gradient_as_bucket_viewTrue, # 省显存 static_graphTrue, # 如果模型结构固定开启能优化 )static_graphTrue这个参数很多人不知道开启后 DDP 能做一些图级别的优化通信效率能提升 10% 到 20%。前提是你的模型在训练过程中计算图不变LLM 训练一般满足。5.2 ZeRO / FSDP 的通信代价ZeRO 和 FSDP 通过分片优化器状态、梯度、参数来省显存但代价是更多的通信。ZeRO-3 每个 step 都要 all-gather 参数通信量比 DDP 大好几倍。如果你的显存优化用的是 ZeRO-3 或者 FSDP 的 full shardGPU 吃不满很可能是通信瓶颈。这时候可以考虑降级到 ZeRO-2只分片优化器状态和梯度通信量小很多混合分片FSDP 支持sharding_strategy配置可以选SHARD_GRAD_OP而不是FULL_SHARD增大计算通信比增大 batch size 或者序列长度让每次通信对应的计算量更大我个人的经验是单机多卡场景下ZeRO-2 通常比 ZeRO-3 更划算除非模型大到 ZeRO-2 装不下。多机场景下通信更贵要更谨慎地选择分片策略。5.3 通信和计算的 overlap理想情况下通信应该和计算重叠GPU 在等通信的时候应该还有别的活干。但实际中 overlap 效果往往不理想原因包括通信和计算依赖同一个 stream无法并行bucket 划分不合理通信粒度太细网络带宽本身就不够PyTorch 2.x 之后FSDP 的 overlap 做得比之前好但还是要看具体配置。可以用torch.profiler看通信 kernel 和计算 kernel 是否真的重叠了。如果 timeline 上通信和计算是串行的那 overlap 没生效需要检查配置。6. 实操排查流程从现象到根因6.1 第一步建立基线在开始调优之前先建立一个干净的基线。用一个最简单的配置跑一遍记录以下指标# 终端 1粗粒度监控 nvidia-smi -l 1 # 终端 2细粒度监控 nvidia-smi dmon -s pucvmet -d 1 # 终端 3训练脚本 python train.py 21 | tee baseline.log基线配置建议batch size 设为能跑起来的最小值关闭所有显存优化gradient checkpointing、ZeRO 等关闭混合精度数据管线用最简单的配置记录 step time、GPU 利用率、显存占用、功耗。这个基线是后续所有对比的参照。6.2 第二步逐项开启优化观察变化每次只开一个优化观察指标变化。我一般按这个顺序开混合精度AMP看 step time 和利用率开 Flash Attention看 attention 部分耗时开 gradient checkpointing看显存和 step time 的 trade-off开 torch.compile看整体提升开分布式如果有看通信开销每开一项记录 step time、GPU 利用率、显存占用。如果某一项开了之后利用率反而下降说明这项优化在当前配置下不划算要么调整参数要么放弃。6.3 第三步用 profiler 定位瓶颈基线建立之后用 profiler 抓一次详细的 timelineimport torch from torch.profiler import profile, ProfilerActivity, tensorboard_trace_handler def train_step(model, batch, optimizer): outputs model(**batch) loss outputs.loss loss.backward() optimizer.step() optimizer.zero_grad() return loss with profile( activities[ProfilerActivity.CPU, ProfilerActivity.CUDA], scheduletorch.profiler.schedule(wait2, warmup2, active6, repeat1), on_trace_readytensorboard_trace_handler(./profiler_log), record_shapesTrue, profile_memoryTrue, with_stackTrue, ) as prof: for step, batch in enumerate(dataloader): if step 20: break loss train_step(model, batch, optimizer) prof.step()跑完之后用 TensorBoard 打开./profiler_log看 timeline。重点看GPU 上是否有空白段空白段对应的 CPU 侧在做什么哪些 kernel 耗时最长通信 kernel 占比多少显存分配和释放的模式6.4 常见瓶颈速查表现象可能原因排查方法解决方向GPU 利用率低timeline 有空白数据管线慢看 DataLoader 耗时增 num_workers、预处理数据GPU 利用率低kernel 间隙大kernel launch bound看 kernel 间空隙CUDA Graph、torch.compileGPU 利用率低通信 kernel 占比高通信瓶颈看 all-reduce 耗时梯度累积、调 bucket、换分片策略GPU 利用率高但速度慢小算子过多看 kernel 数量和耗时算子融合、torch.compile显存够但 batch 上不去激活值显存看显存分配gradient checkpointingstep time 波动大数据或 IO 不稳定看 step time 分布换存储、预处理功耗上不去GPU 没吃满看 power draw综合排查上述各项7. 几个容易被忽略的细节7.1 混合精度里的 dtype 转换开销AMP自动混合精度能省显存、加速计算但 dtype 转换本身有开销。如果模型里频繁在 FP16 和 FP32 之间转换开销会累积。torch.cuda.amp.autocast会自动管理转换但有些操作比如 LayerNorm、softmax在 FP16 下数值不稳定需要保持 FP32。这些例外操作会导致额外的转换。我一般会用torch.compile配合 AMP让编译器做更激进的融合和转换优化。另外bfloat16在数值稳定性上比float16好如果硬件支持Ampere 及以上优先用bfloat16。from torch.cuda.amp import autocast, GradScaler scaler GradScaler() with autocast(dtypetorch.bfloat16): outputs model(**batch) loss outputs.loss scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()注意bfloat16不需要 GradScaler因为它的动态范围和 FP32 一样。用float16才需要。7.2 优化器状态的内存布局Adam 优化器每个参数要存两个状态一阶矩和二阶矩如果用 FP32 存显存占用是参数量的 8 倍。7B 模型就是 56GB这也是为什么大家要用 ZeRO 或者 8-bit Adam。但优化器状态的内存布局也会影响性能。如果状态张量在显存里是碎片化的访问效率会下降。PyTorch 的foreach实现会把多个参数的状态合并操作减少 kernel 数量optimizer torch.optim.AdamW( model.parameters(), lr1e-4, foreachTrue, # 开启 foreach 实现 fusedTrue, # 如果可用用融合 kernel )foreachTrue在参数多的时候效果明显能把优化器更新的 kernel 数量从几百个降到几个。fusedTrue需要 CUDA 支持效果更好但兼容性差一些。7.3 梯度累积和 batch size 的等效关系梯度累积是省显存的常用手段但要注意它和 batch size 的等效关系。假设你想要的等效 batch size 是 64但显存只够放 8那就累积 8 次accumulation_steps 8 for step, batch in enumerate(dataloader): outputs model(**batch) loss outputs.loss / accumulation_steps loss.backward() if (step 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()注意 loss 要除以accumulation_steps否则梯度会放大。另外BatchNorm 这类依赖 batch 统计的层在梯度累积下行为和真实大 batch 不一样LLM 里一般用 LayerNorm 所以没这个问题。梯度累积的代价是每个 micro-step 都要做一次前向和反向但优化器更新频率降低。如果瓶颈在优化器更新梯度累积能加速如果瓶颈在前向反向计算梯度累积不改变单步计算量利用率不会提升。7.4 显存碎片和 caching allocatorPyTorch 的 CUDA caching allocator 会缓存显存块减少cudaMalloc调用。但缓存策略不当会导致碎片表现为显存够但分配失败。可以用环境变量调整export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:Trueexpandable_segments让 allocator 能扩展已分配的段减少碎片。PyTorch 2.1 之后支持效果不错。另外torch.cuda.memory_summary()能打印详细的显存分配情况包括碎片率。如果碎片率高可以考虑定期torch.cuda.empty_cache()但注意这会释放缓存下次分配又要重新cudaMalloc有开销不要频繁调用。8. 一个完整的调优案例8.1 初始状态假设我们有一个 7B 模型的指令微调任务单卡 A100 80GB初始配置batch size 4序列长度 2048FP32 训练无 gradient checkpointingDataLoader num_workers4无 torch.compile实测step time 3.2sGPU 利用率 42%显存占用 68GB功耗 180W。8.2 逐项优化第一步开 AMPbfloat16step time 降到 2.1s利用率 58%显存降到 42GB功耗 240W。提升明显。第二步开 Flash Attentionstep time 降到 1.7s利用率 65%显存降到 38GB。Attention 部分耗时从 0.6s 降到 0.25s。第三步DataLoader 调优num_workers 从 4 调到 12pin_memoryTrueprefetch_factor4。step time 降到 1.5s利用率 72%。timeline 上数据管线的空白段基本消失。第四步torch.compilestep time 降到 1.2s利用率 80%。编译花了 3 分钟但之后每个 step 都受益。第五步CUDA Graphstep time 降到 1.0s利用率 88%。注意序列长度要 padding 到固定值。第六步优化器调优AdamW 开 foreach 和 fusedstep time 降到 0.95s利用率 90%。最终step time 从 3.2s 降到 0.95s加速 3.4 倍GPU 利用率从 42% 拉到 90%功耗 320W。8.3 关键观察这个案例里显存优化AMP、Flash Attention和利用率优化DataLoader、torch.compile、CUDA Graph是交替进行的。每一步都观察指标确认有效再进入下一步。如果某一步没效果甚至变慢就回退。另外注意优化是有顺序的。如果先开 CUDA Graph 再调 DataLoaderCUDA Graph 的效果会被数据管线的空白段掩盖看起来提升不大。正确的顺序是先解决数据供给再解决 kernel 调度。9. 一些反直觉的经验9.1 有时候降低 batch size 反而更快听起来反直觉但在某些配置下确实如此。如果 batch size 太大导致显存压力大caching allocator 频繁触发碎片整理或者 gradient checkpointing 被强制开启那降低 batch size 反而能让每个 step 更快。我遇到过一个大 batch 导致 attention 的中间矩阵超出 SRAM 容量Flash Attention 退化到慢路径的情况。batch 减半之后attention 走快路径整体速度反而提升。9.2 不是所有优化都要开gradient checkpointing 省显存但增加计算如果你的显存本来就够开了只会变慢。同理ZeRO-3 在多机场景下通信开销巨大如果模型能塞进单机用 DDP 更划算。优化的原则是先测量再优化只优化瓶颈。不要因为某个技术听起来很厉害就无脑上。9.3 监控本身也有开销nvidia-smi -l 1每秒采样一次开销可以忽略。但如果你在训练循环里频繁调用torch.cuda.memory_allocated()或者torch.cuda.utilization()这些调用会触发同步拖慢训练。监控要用外部工具不要在训练循环里做。日志记录也要攒批不要每个 step 都写盘。10. 工具链和版本选择10.1 PyTorch 版本PyTorch 2.x 之后torch.compile和 FSDP 的成熟度大幅提升。如果还在用 1.x建议升级。但注意 CUDA 版本和驱动的兼容性升级前先在测试环境验证。我目前用的组合是 PyTorch 2.3 CUDA 12.1 cuDNN 8.9稳定性不错。torch.compile在这个版本下对 LLM 的支持已经比较完善。10.2 辅助工具Nsight Systems抓 timeline看 kernel 和通信Nsight Compute分析单个 kernel 的性能PyTorch Profiler集成在 PyTorch 里方便Weights Biases / TensorBoard记录训练指标nvitop比 nvidia-smi 更友好的监控工具nvitop我强烈推荐界面清晰能同时看多个 GPU 的利用率、显存、功耗、温度还能看进程级别的占用。安装pip install nvitop运行nvitop就行。10.3 环境变量调优# NCCL 调优 export NCCL_ALGORing # 或 Tree取决于拓扑 export NCCL_PROTOSimple # 或 LL取决于消息大小 export NCCL_NSOCKS_PERTHREAD4 export NCCL_SOCKET_NTHREADS2 # CUDA 调优 export CUDA_DEVICE_MAX_CONNECTIONS1 # 减少 stream 数量降低调度开销 export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True # 线程调优 export OMP_NUM_THREADS8 # 根据 CPU 核心数调整CUDA_DEVICE_MAX_CONNECTIONS1这个参数在 kernel launch bound 的场景下有效能减少 stream 之间的切换开销。但注意它可能影响通信和计算的重叠要实测。11. 最后再分享几个实操技巧第一个技巧用 dummy data 做基准测试。在排查数据管线问题的时候把 DataLoader 换成一个生成随机 tensor 的 dummy loader如果 GPU 利用率立刻上去了那问题就在数据侧。这个方法能快速排除数据管线的嫌疑。第二个技巧二分法定位瓶颈。如果 timeline 很复杂不知道从哪下手可以把模型截断只跑前几层看利用率。如果前几层利用率就低问题在数据或调度如果前几层正常后面低问题在模型结构或通信。第三个技巧关注 step time 的方差不只看均值。如果 step time 波动大说明有间歇性的瓶颈比如数据 IO 抖动、GC 暂停、其他进程干扰。用torch.cuda.Event记录每个 step 的耗时画个分布图比看均值有用得多。第四个技巧显存优化和利用率优化分开做。先把显存压到能跑再单独调利用率。两个一起调变量太多很难定位问题。第五个技巧保留一个能跑的最简配置。调优过程中经常会改坏保留一个 baseline 脚本随时能回退对比。我一般会把 baseline 的 commit hash 记下来出问题就git checkout回去。这些经验都是踩坑踩出来的你在自己环境里复现的时候硬件、驱动、库版本不同具体数值会有差异但排查思路是通用的。核心就一句话先测量再优化只优化瓶颈每次只改一个变量。
