写《发烫优化系列》第1篇的时候我反复强调一句话GPU 发烫别急着怪散热先查查它到底有没有在认真干活。今天第2篇我打算把矛头对准一个经常背锅、又经常被忽略的角色——带宽。简单说带宽就是 GPU 的粮道。计算单元是士兵显存和内存是粮仓带宽就是运粮的路。粮仓再大路上堵死了士兵也只能饿着肚子等机器该热还得热活却没干多少。这篇文章适合正在做深度学习训练/推理、GPU 服务器运维、本地跑大模型或者被 GPU 温度居高不下折磨过的朋友。我不会只丢概念会把 GPU 内部的几条“粮道”掰开揉碎讲清楚拥堵点在哪怎么用命令测出来以及软件和硬件层面分别怎么“拓宽”。废话不多说直接进入正题。1. 先把“粮道”说清楚GPU 里的带宽到底是什么1.1 容量是仓库带宽是运力先记住一个类比显存容量是仓库面积显存带宽是仓库门口那条路的运力。仓库能存 100 吨32GB 显存不代表每秒能搬出 100 吨带宽。GPU 在计算时真正决定速度的往往不是“仓库里有没有货”而是“货能不能按时运到计算核心手里”。我见过不少运维朋友一看到显存占用 80% 就觉得显存不够急着加卡、换卡但问题根本不在容量。比如跑一个大矩阵乘法需要反复从显存读矩阵块这时如果显存带宽被打满计算核心只能在原地等数据显存再多也没用。带宽是“每秒能搬运多少 GB”容量是“同时能囤多少 GB”这是两个维度别混在一起。1.2 GPU 系统里到底有几条“粮道”一台 GPU 服务器里数据不是只在显存和计算核心之间流动而是经过好几条不同的路。我一般会按下面四条通道去排查通道典型速度主要用途常见瓶颈场景显存带宽HBM2/HBM3/GDDR6/GDDR6X几百 GB/s 到数 TB/sGPU 内计算核心读写显存大矩阵乘法、Transformer 训练、大模型权重读取PCIe 带宽Gen3/Gen4/Gen5 x16约 16/32/64 GB/sCPU 与 GPU 之间数据传输训练数据加载、CPU 预处理、小 batch 同步CPU 内存带宽几十 GB/s 到一两百 GB/s数据从内存到 CPU 缓存/PCIe大数据集读取、Embedding、数据增强片上缓存带宽L1/L2/共享内存几十 TB/s减少全局内存往返算子复用不足、缓存命中率低每条通道都可能成为瓶颈而且它们之间是串联关系CPU 内存里的数据要先过 PCIe 进显存显存里的数据再经 L2 缓存进 SM最后到寄存器。任何一个环节堵住整体性能都会塌下来。1.3 为什么带宽比容量更容易成为瓶颈因为半导体行业的“算力增长”和“带宽增长”严重失衡。GPU 的 FP16/FP32 算力每几年翻几倍但显存带宽的增速远远跟不上。业界管这个叫“内存墙”。你可以理解成士兵数量越来越多枪法越来越好但运粮的路还是那么几条于是大量士兵在营地里干瞪眼。具体到数字上以某款数据中心 GPU 为例FP16 稠密算力接近 1000 TFLOPS显存带宽只有 2 TB/s 左右。这意味着每个字节的数据被读进芯片后理论上要做几百次浮点运算才能“喂饱”算力。一旦代码的算术强度每字节数据对应的运算次数不够带宽立刻见底算力只能闲着。这就是“发烫但没干活”的根源之一。2. 粮道到底堵在哪四个最常见的拥堵点2.1 显存带宽堵住算力越高越容易“饿肚子”显存带宽瓶颈在 AI 训练里最典型。很多人第一次意识到这个问题是跑 Transformer 的时候模型不大显存也够但 GPU 利用率就是上不去GPU 核心明明在忙可训练速度很慢还特别热。为什么因为在没有优化的 Transformer 实现里注意力矩阵的中间结果会被频繁写回显存再读出来做 Softmax 和加权求和。每多一次“写显存→读显存”就给显存带宽增加一次压力。FlashAttention 的核心优化之一就是把这些中间步骤尽量留在 SRAM 里减少对 HBM 的访问。注意这里减少的是带宽消耗不是计算量但训练时间却可能快好几倍。判断方法也简单用nvidia-smi看Memory利用率如果长期在 90% 以上而GPU-Util反而不是特别高基本就是显存带宽瓶颈。带宽被打满就像高速路堵死了计算核心里再多的运算单元也使不上劲GPU 整体功耗还因为显存控制器和 HBM 芯片高强度工作而居高不下温度自然好看不了。2.2 PCIe 带宽堵住CPU 和 GPU 之间的独木桥相比显存带宽PCIe 带宽更容易被人忽略但它恰恰是很多“GPU 利用率低”案例的元凶。PCIe Gen4 x16 的理论带宽是 32 GB/s听起来不小可和显存带宽一比差距就出来了当前消费级旗舰卡的显存带宽普遍在 1 TB/s 以上PCIe 只有三十分之一。只要数据需要从 CPU 内存搬到 GPU速度就会被这条“独木桥”卡死。我经常遇到这样的训练代码每个 step 都从 CPU 内存里读一个 batch然后执行.cuda()拷贝到 GPU。如果 batch 稍微大一点比如 8GB按 25 GB/s 的实际 PCIe 吞吐算光拷贝就要 0.3 秒多。而一步训练本身可能只需要 0.1 秒于是 GPU 大部分时间都在等数据功耗不高但训练总时间被拉得极长。检查 PCIe 链路是否正常可以用下面这条命令每 1 秒打印一次当前 PCIe 代数和链路宽度nvidia-smi --query-gpuname,pcie.link.gen.current,pcie.link.width.current,temperature.gpu,utilization.gpu,utilization.memory,power.draw --formatcsv -l 1如果显示的是2.0 x8而你预期是4.0 x16那问题很可能不是代码而是显卡插槽插错了或者主板的 PCIe 通道被拆分了。最典型的就是两张显卡插在两个 x8 槽上或者是插在了 PCH 引出的 x4 槽里。先把硬件链路搞对再谈优化不然都是白费劲。2.3 缓存命中率不足粮车全在路上下不来还有一种情况显存带宽和 PCIe 链路都没问题但程序依旧慢。这时候要往芯片内部看GPU 的 L1/L2 缓存和共享内存是离计算单元最近的“临时粮仓”。如果算子写得不好每个线程都直接从显存读数据重复数据不缓存那么就算显存带宽再高也会被大量重复请求打爆。经典的做法是“分块 共享内存”把一个计算块的数据先批量搬到共享内存然后计算单元反复从共享内存读取。例如矩阵乘法里的 tiling 优化就是把 A 和 B 的每个小分块加载到共享内存再算局部乘积这样对显存的访问次数能减少一个数量级。CUDA 里的__shared__和同步指令要解决的就是这个问题。可以用 NVIDIA Nsight Compute 对单个 kernel 做 Memory Workload Analysis重点看两个指标DRAM Throughput 和 L2 Hit Rate。DRAM Throughput 接近 90% 以上说明显存带宽饱和L2 Hit Rate 很低说明数据复用率差。很多所谓的“GPU 优化”优化来优化去其实就是这两件事少读写显存多复用缓存。2.4 多卡通信带宽堵住集群里的“粮道”更乱单卡看完了多卡环境还有新的堵点。多卡训练时每张卡算完梯度后要做 AllReduce把梯度同步到所有卡。如果卡和卡之间走的是 PCIe那么带宽上限只有几十 GB/s如果走 NVLink带宽能到几百 GB/s。但不管是哪种只要通信量大于带宽GPU 就得停下计算去等数据这时候功率未必会降多少因为通信引擎也在工作但计算单元确实在空转。检查多卡拓扑可用nvidia-smi topo -m它会打印一张卡与卡之间的连接关系图标出 NVLink、PCIe 等不同链路。如果发现两张需要频繁通信的卡之间只有 PCIe而且中间还隔着 CPU那通信延迟会非常高。这种情况下要么调整进程和卡的绑定关系要么在代码里用通信压缩、梯度分批等技术把通信量压下来。3. 实地排查把“堵点”一条一条测出来3.1 先用 nvidia-smi 快速摸底我拿到一台 GPU 机器第一件事就是开一个实时监控终端watch -n 1 nvidia-smi重点看四组数据GPU-Util、Memory、Power Draw、Temperature。结合这四组数据能做一个初步判断GPU-Util低Memory高显存带宽可能饱和GPU 核心在等数据。GPU-Util低Memory低Power Draw偏低大概率在等 PCIe 传输或 CPU 预处理。GPU-Util高温度高功耗高通常算力在用先看代码和散热再决定是否优化带宽。两个利用率都很高但性能还是上不去可能是锁步问题、kernel 启动太频繁或者用了太多小算子。注意Memory这一列在较新驱动里表示的是“显存控制器利用率”不是显存占用率。这是很多人误读的地方。显存占用率高是仓库堆满了显存控制器利用率高才是运粮路堵死了。3.2 用 dmon 看实时利用率watch nvidia-smi看个大概可以但要看更细的 SM 和内存控制器利用率建议用 dmonnvidia-smi dmon -s u -d 5输出里主要有sm和mem两列。sm是流式多处理器利用率mem是内存控制器利用率。如果mem长时间接近 100%而sm只有百分之三四十那结论已经很清晰了显存带宽扛不住计算单元被“断粮”。dmon 的好处是采样密度高适合盯一段时间的负载变化。比如训练脚本刚启动时mem 可能冲到很高然后稳定在一个位置通过观察这个位置能反推当前 workload 是不是带宽敏感型。3.3 跑一次带宽基准测试工具乱猜没用最好直接跑一次标准带宽测试。CUDA 自带的bandwidthTest很实用在 /usr/local/cuda/samples 里编译完就能跑/usr/local/cuda/samples/1_Utilities/bandwidthTest/bandwidthTest输出一般有三项Host to Device Bandwidth、Device to Host Bandwidth、Device to Device Bandwidth。其中 Device to Device 反映显存带宽正常应接近该显卡的理论峰值Host to Device 反映 PCIe 实际吞吐正常能达到 PCIe 理论带宽的 70%–80%如果特别低就要怀疑是不是用了分页内存、PCIe 降速或者 CPU NUMA 访问远端内存。这个测试看起来简单但在实战里非常有用。有一次排查一台 GPU 利用率偏低的机器跑完发现 Host to Device 带宽只有 3 GB/s远低于 PCIe Gen3 应有的 10 GB/s 以上最后定位到是 CPU 降频 非页锁定内存的双重问题。3.4 用 Profiler 定位到具体 kernel自己写的 CUDA 代码或者 PyTorch 里某个算子特别慢只靠全局利用率很难定位。这时候可以用 Nsight Compute 对单个 kernel 做内存分析ncu --section MemoryWorkloadAnalysis python train.py重点关注dram__throughput.avg.pct_of_peak_sustained_elapsed这个值表示显存带宽达到峰值的百分比。超过 90% 基本就是显存带宽瓶颈如果只有 30%但 L2 Hit Rate 低、L1 Wavefronts 高说明数据复用不行优化方向是调整分块和访存模式而不是一上来就换卡。很多小白看到这里会慌觉得 NCU 太复杂。其实可以先不追求全量分析只看一两个指标。把最耗时的三个 kernel 记下来分别看它们的 DRAM Throughput就能搞清楚“粮道堵没堵、堵在哪一段”。4. 把粮道拓宽从硬件到软件的优化清单4.1 硬件层面别让链路“打折”先说硬件最简单但最容易踩坑。第一确认 PCIe 插槽。显卡要插在 CPU 直连的 x16 槽上而不是 PCH 引出来的 x4 槽或共享带宽的副槽。多卡服务器更是要看主板说明书别让两张卡把 x16 拆成两个 x8 还不自知。第二BIOS 里开启 Resizable BAR 和 Above 4G Decoding。这个功能允许 CPU 一次性访问更多显存地址空间对部分场景有显著提升。虽然它不直接增加带宽但能减少 CPU 与 GPU 之间的小块传输次数等于把“小推车”换成了“大卡车”。第三多卡场景优先用 NVLink 互联的卡。如果条件有限至少要让通信量大的卡在拓扑上相邻。用nvidia-smi topo -m确认别让数据绕一大圈经过 CPU 再回来。4.2 框架层面让数据少搬家大多数人的 GPU 工作负载跑在 PyTorch 里这里有几个立竿见影的改动。一是DataLoader开启pin_memoryTrue。它的作用是把主机内存锁定为页锁定内存让 GPU 可以直接通过 DMA 访问而不需要操作系统再复制一次。开启后 Host to Device 的传输效率能提升不少。配合.cuda(non_blockingTrue)还能把拷贝和计算重叠起来把搬运时间藏进计算时间里。二是少往 CPU 上传数据。很多人为了打印 Loss每个 step 都执行.item()或者做验证时反复.cpu()这些操作都会触发 GPU 到 CPU 的同步传输。一次两次没事频繁了就是在给 PCIe 粮道添堵。建议把 Loss 累积到一定步数再同步打印验证集也整批搬到 GPU 上算别来回折腾。三是在显存里做数据预处理。如果数据集不大可以一次性把归一化、增广等操作搬到 GPU 上执行哪怕只是把数据先.cuda()再变换也比在 CPU 里处理完再搬过来快。数据集大的时候可以用persistent_workersTrue让 DataLoader 的子进程常驻省去反复启动进程的开销。四是混合精度。FP16 比 FP32 少一半字节INT8 又少一半。在带宽受限的场景里降精度等同于直接拓宽粮道。PyTorch 的torch.autocast和torch.compile能省不少事跑大模型推理时量化到 INT4/INT8 效果更明显。4.3 算法层面让每个字节被多用几次框架层面的优化只能解决“搬运效率”问题算法层面要解决的是“搬运次数”问题。最核心的思路是提高数据复用率。矩阵乘法用分块 共享内存卷积用 im2col 加缓存复用注意力用 FlashAttention 把中间结果留在片上。这些技术的本质是一致的同一个字节的数据读一次能算十次就别读十次只算一次。再具体一点很多人写 PyTorch 模型时习惯把多个操作拆开写比如先做矩阵乘再激活再归一化。每个操作都可能产生一个中间 tensor 写回显存。用torch.compile或者手动把算子融合成一个 kernel中间 tensor 就不需要经过显存延迟和带宽压力都能降下来。在大模型推理场景带宽问题更突出。自回归生成每预测一个 token理论上都要把模型权重从头到尾读一遍。一个 7B 参数的 FP16 模型权重约 14GB就算显存带宽 1TB/s每个 token 至少需要 14ms。算力再高也没用因为带宽卡死了。这也是为什么大家疯狂用 KV Cache、GQA/MQA、量化权重的根本原因。跑llama.cpp时记得把层尽量全部加载到 GPU-ngl设大一点否则每层权重都要从系统内存经 PCIe 传进 GPU速度会慢一大截。很多人问“llamacpp 怎么跑 GPU”其实就是这个道理让权重少搬家一次全放显存。4.4 优化后如何验证功耗、温度、吞吐一起看优化有没有效果不能只盯一个指标。我优化完后会固定跑同样的任务记录一份对比表指标优化前优化后推理速度token/s1228平均功耗W220205峰值温度°C8476显存带宽利用率95%60%单任务总能耗Wh1.81.2注意优化后功耗不一定会降。如果任务从“长时间慢跑”变成“短时间快跑”瞬时功耗可能更高但总能耗会下降温度曲线也会更平滑。所以不要只看瞬间功耗要看“完成同样任务消耗的总能量”和“峰值温度”。5. 常见问题与排查技巧实录5.1 一张速查表帮你快速定位现象可能原因检查手段解决方向GPU-Util 低Memory 高显存带宽饱和ncu DRAM Throughput降精度、算子融合、缓存复用GPU-Util 低Memory 低PCIe 传输/CPU 预处理瓶颈query-gpu 看 PCIe 链路、bandwidthTestpin_memory、异步拷贝、GPU 预处理温度高功耗不高散热问题或小 kernel 频繁启动任务功耗曲线减少 kernel 启动次数、加固散热多卡通信时间占比高NVLink/网络带宽不足nvidia-smi topo -m调整卡间拓扑、梯度压缩、NCCL 配置显存占用不高但性能差内存碎片/分配频繁看运行时报错或 CUDA 日志使用内存池、cudaMallocAsync这张表不是万能药但能帮你把问题从“玄学”变成“确定性排查”。5.2 我实际踩过的三个坑第一个坑是把显存占用率当成带宽利用率。某次排查一台训练服务器运维说“显存占用 90%肯定不够”我上去一看Memory利用率只有 30%占用率高是因为 batch 开得大但带宽远没到顶。后来把 batch 调小一点用梯度累积速度反而更快。记住显存占用和带宽利用率是两码事。第二个坑是 PCIe 插槽问题导致链路减半。一台双卡服务器第二张卡性能总是不对劲跑nvidia-smi -q -d PCIE才发现当前链路只有 x8而第一张卡是 x16。原因是主板的两根 PCIe 槽共享通道插了两张卡后就自动从 x16 变成 x8。换到 CPU 直连的独立通道后问题立刻消失。遇到性能不对先查链路代数和宽度这一个命令能省一晚上排查时间。第三个坑是主机内存用分页内存导致 H2D 拷贝奇慢。早期我写 CUDA 程序习惯用普通的malloc分配主机内存结果 Host to Device 带宽连 PCIe 一半都不到。后来改用cudaHostAlloc分配页锁定内存带宽直接翻倍。PyTorch 里的pin_memoryTrue就是同一件事。5.3 别忘了“发烫优化”的测量底线做这一系列文章我最想强调的不是某个具体技巧而是“测量底线”。GPU 发烫也好性能差也好先问三个问题功耗是多少温度曲线是什么形状GPU/内存/PCIe 利用率分别是什么水平这三个问题有了数据再决定是换散热、调代码还是改选型。带宽优化不是只为了跑分它最终的收益是让功耗花在“计算”上而不是花在“等待”和“搬运”上。很多机器温度压不下去根本不是散热片不够大而是粮道堵了士兵们饿着肚子原地踏步高温自然就来了。先疏通路再看散热顺序别搞反。我在实际做优化时最深的体会是GPU 发热不完全是功耗太高很多时候是功耗没花在刀刃上。带宽一堵计算单元就在空转空转也在耗电也在产热。前面给的命令和思路基本能帮你在半小时内判断出粮道堵在哪。下一步我准备写算力和功耗的调度老规矩先量化再动手。
GPU发烫性能差？先查带宽瓶颈：从显存到PCIe的排查与优化指南
写《发烫优化系列》第1篇的时候我反复强调一句话GPU 发烫别急着怪散热先查查它到底有没有在认真干活。今天第2篇我打算把矛头对准一个经常背锅、又经常被忽略的角色——带宽。简单说带宽就是 GPU 的粮道。计算单元是士兵显存和内存是粮仓带宽就是运粮的路。粮仓再大路上堵死了士兵也只能饿着肚子等机器该热还得热活却没干多少。这篇文章适合正在做深度学习训练/推理、GPU 服务器运维、本地跑大模型或者被 GPU 温度居高不下折磨过的朋友。我不会只丢概念会把 GPU 内部的几条“粮道”掰开揉碎讲清楚拥堵点在哪怎么用命令测出来以及软件和硬件层面分别怎么“拓宽”。废话不多说直接进入正题。1. 先把“粮道”说清楚GPU 里的带宽到底是什么1.1 容量是仓库带宽是运力先记住一个类比显存容量是仓库面积显存带宽是仓库门口那条路的运力。仓库能存 100 吨32GB 显存不代表每秒能搬出 100 吨带宽。GPU 在计算时真正决定速度的往往不是“仓库里有没有货”而是“货能不能按时运到计算核心手里”。我见过不少运维朋友一看到显存占用 80% 就觉得显存不够急着加卡、换卡但问题根本不在容量。比如跑一个大矩阵乘法需要反复从显存读矩阵块这时如果显存带宽被打满计算核心只能在原地等数据显存再多也没用。带宽是“每秒能搬运多少 GB”容量是“同时能囤多少 GB”这是两个维度别混在一起。1.2 GPU 系统里到底有几条“粮道”一台 GPU 服务器里数据不是只在显存和计算核心之间流动而是经过好几条不同的路。我一般会按下面四条通道去排查通道典型速度主要用途常见瓶颈场景显存带宽HBM2/HBM3/GDDR6/GDDR6X几百 GB/s 到数 TB/sGPU 内计算核心读写显存大矩阵乘法、Transformer 训练、大模型权重读取PCIe 带宽Gen3/Gen4/Gen5 x16约 16/32/64 GB/sCPU 与 GPU 之间数据传输训练数据加载、CPU 预处理、小 batch 同步CPU 内存带宽几十 GB/s 到一两百 GB/s数据从内存到 CPU 缓存/PCIe大数据集读取、Embedding、数据增强片上缓存带宽L1/L2/共享内存几十 TB/s减少全局内存往返算子复用不足、缓存命中率低每条通道都可能成为瓶颈而且它们之间是串联关系CPU 内存里的数据要先过 PCIe 进显存显存里的数据再经 L2 缓存进 SM最后到寄存器。任何一个环节堵住整体性能都会塌下来。1.3 为什么带宽比容量更容易成为瓶颈因为半导体行业的“算力增长”和“带宽增长”严重失衡。GPU 的 FP16/FP32 算力每几年翻几倍但显存带宽的增速远远跟不上。业界管这个叫“内存墙”。你可以理解成士兵数量越来越多枪法越来越好但运粮的路还是那么几条于是大量士兵在营地里干瞪眼。具体到数字上以某款数据中心 GPU 为例FP16 稠密算力接近 1000 TFLOPS显存带宽只有 2 TB/s 左右。这意味着每个字节的数据被读进芯片后理论上要做几百次浮点运算才能“喂饱”算力。一旦代码的算术强度每字节数据对应的运算次数不够带宽立刻见底算力只能闲着。这就是“发烫但没干活”的根源之一。2. 粮道到底堵在哪四个最常见的拥堵点2.1 显存带宽堵住算力越高越容易“饿肚子”显存带宽瓶颈在 AI 训练里最典型。很多人第一次意识到这个问题是跑 Transformer 的时候模型不大显存也够但 GPU 利用率就是上不去GPU 核心明明在忙可训练速度很慢还特别热。为什么因为在没有优化的 Transformer 实现里注意力矩阵的中间结果会被频繁写回显存再读出来做 Softmax 和加权求和。每多一次“写显存→读显存”就给显存带宽增加一次压力。FlashAttention 的核心优化之一就是把这些中间步骤尽量留在 SRAM 里减少对 HBM 的访问。注意这里减少的是带宽消耗不是计算量但训练时间却可能快好几倍。判断方法也简单用nvidia-smi看Memory利用率如果长期在 90% 以上而GPU-Util反而不是特别高基本就是显存带宽瓶颈。带宽被打满就像高速路堵死了计算核心里再多的运算单元也使不上劲GPU 整体功耗还因为显存控制器和 HBM 芯片高强度工作而居高不下温度自然好看不了。2.2 PCIe 带宽堵住CPU 和 GPU 之间的独木桥相比显存带宽PCIe 带宽更容易被人忽略但它恰恰是很多“GPU 利用率低”案例的元凶。PCIe Gen4 x16 的理论带宽是 32 GB/s听起来不小可和显存带宽一比差距就出来了当前消费级旗舰卡的显存带宽普遍在 1 TB/s 以上PCIe 只有三十分之一。只要数据需要从 CPU 内存搬到 GPU速度就会被这条“独木桥”卡死。我经常遇到这样的训练代码每个 step 都从 CPU 内存里读一个 batch然后执行.cuda()拷贝到 GPU。如果 batch 稍微大一点比如 8GB按 25 GB/s 的实际 PCIe 吞吐算光拷贝就要 0.3 秒多。而一步训练本身可能只需要 0.1 秒于是 GPU 大部分时间都在等数据功耗不高但训练总时间被拉得极长。检查 PCIe 链路是否正常可以用下面这条命令每 1 秒打印一次当前 PCIe 代数和链路宽度nvidia-smi --query-gpuname,pcie.link.gen.current,pcie.link.width.current,temperature.gpu,utilization.gpu,utilization.memory,power.draw --formatcsv -l 1如果显示的是2.0 x8而你预期是4.0 x16那问题很可能不是代码而是显卡插槽插错了或者主板的 PCIe 通道被拆分了。最典型的就是两张显卡插在两个 x8 槽上或者是插在了 PCH 引出的 x4 槽里。先把硬件链路搞对再谈优化不然都是白费劲。2.3 缓存命中率不足粮车全在路上下不来还有一种情况显存带宽和 PCIe 链路都没问题但程序依旧慢。这时候要往芯片内部看GPU 的 L1/L2 缓存和共享内存是离计算单元最近的“临时粮仓”。如果算子写得不好每个线程都直接从显存读数据重复数据不缓存那么就算显存带宽再高也会被大量重复请求打爆。经典的做法是“分块 共享内存”把一个计算块的数据先批量搬到共享内存然后计算单元反复从共享内存读取。例如矩阵乘法里的 tiling 优化就是把 A 和 B 的每个小分块加载到共享内存再算局部乘积这样对显存的访问次数能减少一个数量级。CUDA 里的__shared__和同步指令要解决的就是这个问题。可以用 NVIDIA Nsight Compute 对单个 kernel 做 Memory Workload Analysis重点看两个指标DRAM Throughput 和 L2 Hit Rate。DRAM Throughput 接近 90% 以上说明显存带宽饱和L2 Hit Rate 很低说明数据复用率差。很多所谓的“GPU 优化”优化来优化去其实就是这两件事少读写显存多复用缓存。2.4 多卡通信带宽堵住集群里的“粮道”更乱单卡看完了多卡环境还有新的堵点。多卡训练时每张卡算完梯度后要做 AllReduce把梯度同步到所有卡。如果卡和卡之间走的是 PCIe那么带宽上限只有几十 GB/s如果走 NVLink带宽能到几百 GB/s。但不管是哪种只要通信量大于带宽GPU 就得停下计算去等数据这时候功率未必会降多少因为通信引擎也在工作但计算单元确实在空转。检查多卡拓扑可用nvidia-smi topo -m它会打印一张卡与卡之间的连接关系图标出 NVLink、PCIe 等不同链路。如果发现两张需要频繁通信的卡之间只有 PCIe而且中间还隔着 CPU那通信延迟会非常高。这种情况下要么调整进程和卡的绑定关系要么在代码里用通信压缩、梯度分批等技术把通信量压下来。3. 实地排查把“堵点”一条一条测出来3.1 先用 nvidia-smi 快速摸底我拿到一台 GPU 机器第一件事就是开一个实时监控终端watch -n 1 nvidia-smi重点看四组数据GPU-Util、Memory、Power Draw、Temperature。结合这四组数据能做一个初步判断GPU-Util低Memory高显存带宽可能饱和GPU 核心在等数据。GPU-Util低Memory低Power Draw偏低大概率在等 PCIe 传输或 CPU 预处理。GPU-Util高温度高功耗高通常算力在用先看代码和散热再决定是否优化带宽。两个利用率都很高但性能还是上不去可能是锁步问题、kernel 启动太频繁或者用了太多小算子。注意Memory这一列在较新驱动里表示的是“显存控制器利用率”不是显存占用率。这是很多人误读的地方。显存占用率高是仓库堆满了显存控制器利用率高才是运粮路堵死了。3.2 用 dmon 看实时利用率watch nvidia-smi看个大概可以但要看更细的 SM 和内存控制器利用率建议用 dmonnvidia-smi dmon -s u -d 5输出里主要有sm和mem两列。sm是流式多处理器利用率mem是内存控制器利用率。如果mem长时间接近 100%而sm只有百分之三四十那结论已经很清晰了显存带宽扛不住计算单元被“断粮”。dmon 的好处是采样密度高适合盯一段时间的负载变化。比如训练脚本刚启动时mem 可能冲到很高然后稳定在一个位置通过观察这个位置能反推当前 workload 是不是带宽敏感型。3.3 跑一次带宽基准测试工具乱猜没用最好直接跑一次标准带宽测试。CUDA 自带的bandwidthTest很实用在 /usr/local/cuda/samples 里编译完就能跑/usr/local/cuda/samples/1_Utilities/bandwidthTest/bandwidthTest输出一般有三项Host to Device Bandwidth、Device to Host Bandwidth、Device to Device Bandwidth。其中 Device to Device 反映显存带宽正常应接近该显卡的理论峰值Host to Device 反映 PCIe 实际吞吐正常能达到 PCIe 理论带宽的 70%–80%如果特别低就要怀疑是不是用了分页内存、PCIe 降速或者 CPU NUMA 访问远端内存。这个测试看起来简单但在实战里非常有用。有一次排查一台 GPU 利用率偏低的机器跑完发现 Host to Device 带宽只有 3 GB/s远低于 PCIe Gen3 应有的 10 GB/s 以上最后定位到是 CPU 降频 非页锁定内存的双重问题。3.4 用 Profiler 定位到具体 kernel自己写的 CUDA 代码或者 PyTorch 里某个算子特别慢只靠全局利用率很难定位。这时候可以用 Nsight Compute 对单个 kernel 做内存分析ncu --section MemoryWorkloadAnalysis python train.py重点关注dram__throughput.avg.pct_of_peak_sustained_elapsed这个值表示显存带宽达到峰值的百分比。超过 90% 基本就是显存带宽瓶颈如果只有 30%但 L2 Hit Rate 低、L1 Wavefronts 高说明数据复用不行优化方向是调整分块和访存模式而不是一上来就换卡。很多小白看到这里会慌觉得 NCU 太复杂。其实可以先不追求全量分析只看一两个指标。把最耗时的三个 kernel 记下来分别看它们的 DRAM Throughput就能搞清楚“粮道堵没堵、堵在哪一段”。4. 把粮道拓宽从硬件到软件的优化清单4.1 硬件层面别让链路“打折”先说硬件最简单但最容易踩坑。第一确认 PCIe 插槽。显卡要插在 CPU 直连的 x16 槽上而不是 PCH 引出来的 x4 槽或共享带宽的副槽。多卡服务器更是要看主板说明书别让两张卡把 x16 拆成两个 x8 还不自知。第二BIOS 里开启 Resizable BAR 和 Above 4G Decoding。这个功能允许 CPU 一次性访问更多显存地址空间对部分场景有显著提升。虽然它不直接增加带宽但能减少 CPU 与 GPU 之间的小块传输次数等于把“小推车”换成了“大卡车”。第三多卡场景优先用 NVLink 互联的卡。如果条件有限至少要让通信量大的卡在拓扑上相邻。用nvidia-smi topo -m确认别让数据绕一大圈经过 CPU 再回来。4.2 框架层面让数据少搬家大多数人的 GPU 工作负载跑在 PyTorch 里这里有几个立竿见影的改动。一是DataLoader开启pin_memoryTrue。它的作用是把主机内存锁定为页锁定内存让 GPU 可以直接通过 DMA 访问而不需要操作系统再复制一次。开启后 Host to Device 的传输效率能提升不少。配合.cuda(non_blockingTrue)还能把拷贝和计算重叠起来把搬运时间藏进计算时间里。二是少往 CPU 上传数据。很多人为了打印 Loss每个 step 都执行.item()或者做验证时反复.cpu()这些操作都会触发 GPU 到 CPU 的同步传输。一次两次没事频繁了就是在给 PCIe 粮道添堵。建议把 Loss 累积到一定步数再同步打印验证集也整批搬到 GPU 上算别来回折腾。三是在显存里做数据预处理。如果数据集不大可以一次性把归一化、增广等操作搬到 GPU 上执行哪怕只是把数据先.cuda()再变换也比在 CPU 里处理完再搬过来快。数据集大的时候可以用persistent_workersTrue让 DataLoader 的子进程常驻省去反复启动进程的开销。四是混合精度。FP16 比 FP32 少一半字节INT8 又少一半。在带宽受限的场景里降精度等同于直接拓宽粮道。PyTorch 的torch.autocast和torch.compile能省不少事跑大模型推理时量化到 INT4/INT8 效果更明显。4.3 算法层面让每个字节被多用几次框架层面的优化只能解决“搬运效率”问题算法层面要解决的是“搬运次数”问题。最核心的思路是提高数据复用率。矩阵乘法用分块 共享内存卷积用 im2col 加缓存复用注意力用 FlashAttention 把中间结果留在片上。这些技术的本质是一致的同一个字节的数据读一次能算十次就别读十次只算一次。再具体一点很多人写 PyTorch 模型时习惯把多个操作拆开写比如先做矩阵乘再激活再归一化。每个操作都可能产生一个中间 tensor 写回显存。用torch.compile或者手动把算子融合成一个 kernel中间 tensor 就不需要经过显存延迟和带宽压力都能降下来。在大模型推理场景带宽问题更突出。自回归生成每预测一个 token理论上都要把模型权重从头到尾读一遍。一个 7B 参数的 FP16 模型权重约 14GB就算显存带宽 1TB/s每个 token 至少需要 14ms。算力再高也没用因为带宽卡死了。这也是为什么大家疯狂用 KV Cache、GQA/MQA、量化权重的根本原因。跑llama.cpp时记得把层尽量全部加载到 GPU-ngl设大一点否则每层权重都要从系统内存经 PCIe 传进 GPU速度会慢一大截。很多人问“llamacpp 怎么跑 GPU”其实就是这个道理让权重少搬家一次全放显存。4.4 优化后如何验证功耗、温度、吞吐一起看优化有没有效果不能只盯一个指标。我优化完后会固定跑同样的任务记录一份对比表指标优化前优化后推理速度token/s1228平均功耗W220205峰值温度°C8476显存带宽利用率95%60%单任务总能耗Wh1.81.2注意优化后功耗不一定会降。如果任务从“长时间慢跑”变成“短时间快跑”瞬时功耗可能更高但总能耗会下降温度曲线也会更平滑。所以不要只看瞬间功耗要看“完成同样任务消耗的总能量”和“峰值温度”。5. 常见问题与排查技巧实录5.1 一张速查表帮你快速定位现象可能原因检查手段解决方向GPU-Util 低Memory 高显存带宽饱和ncu DRAM Throughput降精度、算子融合、缓存复用GPU-Util 低Memory 低PCIe 传输/CPU 预处理瓶颈query-gpu 看 PCIe 链路、bandwidthTestpin_memory、异步拷贝、GPU 预处理温度高功耗不高散热问题或小 kernel 频繁启动任务功耗曲线减少 kernel 启动次数、加固散热多卡通信时间占比高NVLink/网络带宽不足nvidia-smi topo -m调整卡间拓扑、梯度压缩、NCCL 配置显存占用不高但性能差内存碎片/分配频繁看运行时报错或 CUDA 日志使用内存池、cudaMallocAsync这张表不是万能药但能帮你把问题从“玄学”变成“确定性排查”。5.2 我实际踩过的三个坑第一个坑是把显存占用率当成带宽利用率。某次排查一台训练服务器运维说“显存占用 90%肯定不够”我上去一看Memory利用率只有 30%占用率高是因为 batch 开得大但带宽远没到顶。后来把 batch 调小一点用梯度累积速度反而更快。记住显存占用和带宽利用率是两码事。第二个坑是 PCIe 插槽问题导致链路减半。一台双卡服务器第二张卡性能总是不对劲跑nvidia-smi -q -d PCIE才发现当前链路只有 x8而第一张卡是 x16。原因是主板的两根 PCIe 槽共享通道插了两张卡后就自动从 x16 变成 x8。换到 CPU 直连的独立通道后问题立刻消失。遇到性能不对先查链路代数和宽度这一个命令能省一晚上排查时间。第三个坑是主机内存用分页内存导致 H2D 拷贝奇慢。早期我写 CUDA 程序习惯用普通的malloc分配主机内存结果 Host to Device 带宽连 PCIe 一半都不到。后来改用cudaHostAlloc分配页锁定内存带宽直接翻倍。PyTorch 里的pin_memoryTrue就是同一件事。5.3 别忘了“发烫优化”的测量底线做这一系列文章我最想强调的不是某个具体技巧而是“测量底线”。GPU 发烫也好性能差也好先问三个问题功耗是多少温度曲线是什么形状GPU/内存/PCIe 利用率分别是什么水平这三个问题有了数据再决定是换散热、调代码还是改选型。带宽优化不是只为了跑分它最终的收益是让功耗花在“计算”上而不是花在“等待”和“搬运”上。很多机器温度压不下去根本不是散热片不够大而是粮道堵了士兵们饿着肚子原地踏步高温自然就来了。先疏通路再看散热顺序别搞反。我在实际做优化时最深的体会是GPU 发热不完全是功耗太高很多时候是功耗没花在刀刃上。带宽一堵计算单元就在空转空转也在耗电也在产热。前面给的命令和思路基本能帮你在半小时内判断出粮道堵在哪。下一步我准备写算力和功耗的调度老规矩先量化再动手。