前段时间有朋友找我调一个不算大的视觉模型GPU显存明明还有富余算力也远没跑满训练速度就是上不去更诡异的是机箱里温度比满载还高。我用nvidia-smi盯了一会儿发现GPU利用率在0%和100%之间反复横跳显存带宽读数却很低核心温度线倒是非常稳定地冲向了86度。这种算力有余、热来凑的场面我见过太多次了结论基本一致不是计算核心在忙是带宽这条粮道堵住了GPU整个变成了饿肚子干烧的状态。这一篇作为发烫优化系列第2篇专门把粮道这件事拆开讲清楚。我会从带宽到底是什么、数据在GPU内部怎么流动、如何用工具定位堵点、为什么大模型特别容易踩中带宽瓶颈以及带宽问题和发热现象之间那层不太容易被注意到的关系逐段展开。全程基于我自己在训练、推理、多卡环境里踩过的坑能直接照着排查。1. 先把带宽拆开GPU的粮道到底指哪几段路很多人一提GPU带宽第一反应就是显存带宽比如RTX 4090的1TB/s。这个理解没错但它只是内粮道不是全部。GPU要高效工作需要数据从外到内、从内到计算单元一路顺畅任何一段路变窄整条生产线的节奏都会被拖垮。1.1 算力很强但速度上不去典型的吃不到粮现场先说一个我自己的实测案例。之前用PyTorch训练一个ResNet-50机子是双路至强加一张A5000数据集是几万张1920x1080的图片。一开始没有做任何数据管道优化训练一个epoch大概要40分钟。我第一反应是GPU不够好但看nvidia-smi的Volatile GPU-Util经常掉到60%以下很多时候甚至只有20%。这里要区分一个概念GPU利用率低不等于算力不够很多时候是数据压根喂不过来。CPU在忙着做图像解码、缩放、归一化然后通过PCIe一点点往显存搬。CPU处理一张图可能要20毫秒但GPU算一张图只要2毫秒那GPU就只能干等18毫秒。这种场景下瓶颈在外粮道——CPU到GPU之间这条路的输送速度远没有到显存内部带宽那一步。所以排查带宽问题第一步不是盯着显存规格参数看而是先搞清楚数据当前卡在哪一段路上。是压根还没进显存还是进了显存但内部的搬运路径太窄两种情况的原因和解决方法完全不同。1.2 每个带宽指标的含义并不一样别再混着聊我经常看到有人拿显卡的显存带宽参数去推断训练速度这其实很容易误判。GPU平台的带宽粗略分四层第一层是磁盘/网络的I/O带宽负责把数据集从SSD或远程存储里读出来通常几百MB/s到几GB/s取决于你用的是SATA固态、NVMe固态还是万兆网卡。这一层最慢也是数据管线的第一道闸门。第二层是系统内存带宽CPU把数据从内存读出来做预处理双通道DDR4大概在40-60GB/s四通道DDR5可以到100GB/s以上。这层决定了CPU能多快把数据准备好。第三层是PCIe总线带宽负责把数据从系统内存搬运到显存。PCIe 4.0 x16单向约32GB/sPCIe 5.0 x16能到64GB/s左右。很多人忽略一个细节实际很多显卡跑在x8甚至x4通道上带宽直接砍半再砍半。第四层才是显存与GPU核心之间的带宽也是大家最熟悉的那个数字从几百GB/s到数TB/s不等。这一层管的是计算核心能不能快速吃到已经就位在显存里的数据。四层之间是串联关系最慢的那一段决定整体吞吐。就像四段输水管道接在一起中间那节只有拳头粗两头的粗管子再粗也白搭。调试的时候一定要分层去看而不是只盯一个显存带宽指标。2. GPU内部的运粮路线图数据从磁盘到计算单元的全路径理解带宽瓶颈最关键的是脑子里有一张数据流动的路线图。很多性能问题归根结底是某一段路径上产生了不必要的绕路、等待或者重复搬运。2.1 外粮道磁盘/网络数据如何进入显存一次典型的深度学习训练数据的旅程是这样的数据从SSD/网络被CPU读入系统内存此时数据是普通文件字节流CPU对数据做解码、裁剪、归一化、打batch变成张量仍然住在系统内存里框架调用tensor.to(cuda)或者DataLoader的pin memory机制将这批张量通过PCIe总线复制到显存GPU kernel开始从显存读取数据进行计算。这条路径上最常被忽视的堵塞点有两个。第一个是CPU预处理太慢。图像解码、数据增强都是CPU的活儿如果数据增强逻辑很重CPU计算能力反而成了瓶颈。我在一个OCR项目里因为用了复杂的随机仿射变换和模糊增强训练速度比不用增强时慢了2倍以上GPU利用率一直上不去。后来把一部分增强操作挪到GPU上用CUDA核来做速度立刻提了上来。第二个是CPU到GPU的传输方式太粗糙。PyTorch里DataLoader如果不设num_workers或者不设pin_memoryTrue数据拷贝会有额外延迟和页面错误导致每次to(cuda)的耗时飙升。设置pin_memory后传输走DMA通道不再需要CPU逐页处理吞吐提升非常明显。这些细节单看都不大但在大批量数据循环里叠加起来就是几倍的时间差。2.2 内粮道显存与计算核心之间的搬运问题数据进入显存不等于万事大吉。现代GPU的工作方式是大量线程同时从显存读取数据放进寄存器计算再把结果写回显存。这中间也有带宽墙。GPU的算力增长是惊人的但显存带宽的增长相对缓慢。举个例子RTX 3090的FP32算力约35.6 TFLOPS显存带宽约936GB/s。如果一个kernel的算术强度即每字节数据要做多少次计算低于约38 FLOP/Byte那它就会受带宽限制——数据搬运时间占了主导计算单元大量时间在空转。这就是为什么一些看似简单的操作比如逐元素相加AB哪怕数据量很大GPU利用率也可以很高但你仔细观察会发现问题计算单元大部分时间在等数据流过来。带宽是这里真正的主角。2.3 第三条粮道多卡之间的数据交换多卡训练时粮道又多出来一条GPU与GPU之间的互联通道。常见的有NVLink和PCIe Peer-to-Peer。NVLink是NVIDIA为多卡互联设计的专用高带宽总线以A100为例单条NVLink带宽约600GB/s双向H100提升到900GB/s。PCIe Peer-to-Peer则依赖PCIe总线直接在两块GPU之间传数据带宽等同于PCIe带宽比NVLink差很多。多卡训练中梯度同步是最典型的通信密集场景。每个计算节点算完一批数据后需要把自己的梯度广播给其他节点这个过程如果是用PCIe P2PA100上一轮梯度同步可能要消耗几十甚至上百毫秒如果卡间走NVLink这个时间可以缩小一个数量级。很多人配了多卡机器结果训练速度不升反降一查原来是PCIe switch拓扑下跨switch通信带宽直接瓶颈了。我还遇到过一种更隐蔽的情况用torch.distributed做多节点训练时卡间走NVLink没问题但节点之间走万兆以太网梯度同步的瓶颈变成了网络带宽。有人在单机4卡上训练很顺一扩展到双机8卡速度反而变慢。这就是没算清外外粮道网络带宽的容量。所以在讨论GPU带宽时一定要先明确自己说的是哪一段路的带宽。我在下面第三章会直接给出一套排查方法帮你判断当前真正卡在哪里。3. 定位堵点用工具找到带宽瓶颈的真实位置很多人一听说带宽瓶颈就以为要看显卡规格表。实际上定位瓶颈不需要拆机器用现有工具就能在几分钟内判断是外粮道堵了还是内粮道堵了。3.1 先用nvidia-smi看基本盘进入终端跑一句nvidia-smi重点看三块内容GPU-Util、Memory Usage和温度。在训练过程中如果GPU-Util长期低于80%而Memory Usage并没有占满大概率是数据供给出问题数据压根没有频繁到达显存计算核心在空转。这种情况常见于CPU预处理或者PCIe搬运太慢。如果GPU-Util不低但训练速度依然很慢这时需要往下看显存带宽实际利用率。nvidia-smi本身不直接显示带宽利用率但可以看显卡的Tx/Rx字节数nvidia-smi -q -d PCIEPCIe Current Rx : 45 MB/s Current Tx : 12 MB/s Max Link Width : 16x Current Link Width : 16x如果你的应用在持续训练但Current Rx很低比如只有几十MB/s说明外粮道远没有跑满CPU或数据管道一定有问题。如果Current Link Width显示成8x甚至4x那就要注意了实际可用带宽只有设计带宽的四分之一到二分之一。3.2 进一步用NVTOP和Nsight看细粒度占用nvidia-smi看的是总体状态想看更细的带宽占用推荐用nvtop。它类似于htop能实时显示每张GPU的功耗、温度、利用率、显存占用部分版本还能显示PCIe读写速率和显存控制器利用率。apt install nvtop # Ubuntu/Debian nvtop如果跑训练时GPU Memory Controllers利用率很高而GPU Utilization也高但总FPS/吞吐不理想说明瓶颈在显存带宽。如果GPU Utilization低但GPU Memory读写速率很高那可能是访问模式太差导致了大量低效搬运。更细的定位建议用Nsight Systems做一次profiling。它能给出每个kernel的执行时间、访存吞吐、SM利用率等。典型案例我在一个Transformer推理测试里用Nsight发现80%的耗时在at::native::vectorized_elementwise_kernel上这是一个逐元素访存密集型kernel说明大量的时间浪费在了数据搬运而非真正计算上。顺着这条线通过算子融合和减少中间张量整卡耗时直接降了60%。3.3 用Roofline模型判断算力瓶颈还是带宽瓶颈Roofline是一个经典的分析模型对判断GPU负载属于算力受限还是带宽受限非常直观。它把问题归结为两个关键数字峰值算力PGPU每秒能做多少次浮点运算单位FLOPS峰值带宽BGPU每秒能从显存搬运多少字节单位Byte/s算术强度I你当前这个计算任务里每访问1字节数据需要执行多少次浮点运算单位FLOP/Byte。理论上如果任务的算术强度大于P/B就是算力受限小于P/B就是带宽受限。以A100 40GB为例FP16算力约312 TFLOPS显存带宽约1.5TB/s临界算术强度大约是208 FLOP/Byte。普通矩阵乘法在数据复用好的情况下能达到这个水平但很多逐元素、归约操作远远达不到所以很自然就是带宽受限。实操时可以这样估算用nsys或自定义kernel统计一个操作的FLOPs和访问的字节数然后对比算力/带宽比值。比如一个LayerNorm算术强度很低即使算法再高效也跑不满算力。这时候优化的方向不是减少FLOPs而是减少对数据的反复读写——比如把LayerNorm和前面的matmul融合减少一次读和写的往返。3.4 查看PCIe具体链路状态LnkCap与LnkSta很多人在排查PCIe带宽时会用lspci查看显卡对应的设备号比如热搜里常出现的01:00.0。这个设备号就是PCI总线上显卡的BDFBus:Device.Function编号通过它可以查看链路协商状态lspci -s 01:00.0 -vvv在输出里找LnkCap和LnkSta两项LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L0s 1us LnkSta: Speed 16GT/s, Width x16Speed 16GT/s对应PCIe 4.0Width x16代表16条通道。如果LnkSta显示的速度低于LnkCap或者Width变成了x8、x4说明链路协商没跑满。常见原因包括插槽物理尺寸不足、转接卡、CPU通道拆分设置有问题或者主板BIOS里的PCIe模式被设成了低版本兼容模式。我还碰到过一个很典型的案例一台服务器用了riser卡将GPU转接成x16但LnkSta只协商出x8速度减半。原因是riser卡本身只接到CPU的8条PCIe通道上或者主板第二根PCIe插槽物理上就是x8。这时候即使显卡的显存带宽再高数据从CPU到显存的通道已经变窄整体性能必然受影响。遇到LnkSta掉链子的情况可以先去BIOS确认PCIe版本和通道分配同时确认显卡是否插在最靠近CPU的x16插槽上。对于多数深度学习场景PCIe 3.0 x16和PCIe 4.0 x16在训练中的差异没有想象中那么大因为训练时数据复用度很高外粮道不是瓶颈但在推理场景、CPU offload场景以及数据增强全部在CPU做的场景下PCIe链路宽度影响非常明显。4. 大模型时代的带宽塌方为什么喂不饱GPU成了常态如果说早期深度学习模型还勉强能靠算力堆出来那么到了大模型时代带宽问题几乎成了每个做训练和推理的人绕不开的坎。原因不复杂模型越来越大但硬件的带宽增长速度远跟不上参数规模的增长。4.1 算力在涨带宽没跟上结构性的失衡NVIDIA从Ampere到Hopper再到Blackwell算力每一代都在大幅提升但显存带宽的提升幅度相对有限。以H100 SXM为例FP16算力约989 TFLOPS稠密显存带宽3.35TB/s临界算术强度大约295 FLOP/Byte。大模型中很多算子比如注意力打分、Softmax、LayerNorm、激活函数算术强度都远低于这个临界值所以这些算子在H100上几乎不可能跑满算力。这也是为什么业界会发明FlashAttention它要解决的核心问题不是减少计算量而是减少显存访问。标准Attention需要多次读写S、P矩阵这些中间矩阵的量级是序列长度的平方数据搬运开销巨大。FlashAttention通过分块计算和在线Softmax把中间结果尽量留在寄存器里避免频繁写回显存再读出来一下把访存量降了一个数量级。这个思路在带宽受限时代几乎成了标配能少搬就少搬能融合就融合。4.2 推理阶段的逐token生成本质上是带宽密集型任务如果你用llama.cpp或常规的PyTorch跑Llama类模型的推理会发现一个现象GPU利用率不低但生成速度并不快尤其是长上下文场景下。原因是推理在解码阶段是逐token串行生成的。每生成一个token需要把整个模型的权重都读一遍或者至少把参与计算的权重读一遍。模型权重的大小是固定的比如7B模型在FP16下约14GB每生成一个token至少要读14GB数据。按一张卡1TB/s的显存带宽计算理论最快每秒只能生成70个token左右这和实际生成的体验相差无几。所以很多人认为推理慢是算力不够实际上在batch1的场景里推理速度上限基本由显存带宽决定。这解释了为什么量化模型如4-bit的q4_0在推理中能显著提速不是减少计算而是把要搬运的权重字节数从16bit降到了4bit数据运输量直接砍掉75%生成速度自然就上来了。这也是为什么llama.cpp这类工具在CPU上也能跑CPU推理的瓶颈同样在内存带宽而不是CPU浮点算力。4.3 训练阶段同样躲不开中间状态和通信开销训练比推理更复杂的一点在于不仅要搬运权重还要搬运梯度、优化器状态、以及大量的中间激活值。以Adam优化器为例每个参数除了存储本身还需要保存一阶动量m和二阶动量v三者的数据量叠加起来通常是模型权重的3倍以上。如果做混合精度训练还要额外考虑FP32的权重主副本。这些数据在每一步迭代里都要被反复读取和写回哪怕单个kernel很简单数据搬运总量也是很可观的。分布式训练又把通信带宽的问题放大。每一轮迭代结束所有卡上的梯度要做一次全局AllReduce。数据量有多大一个7B模型FP32梯度约28GB即便单机4卡之间走NVLink一次梯度同步也要搬几十GB数据。如果卡间是PCIe P2P时间会成倍增加。因此大模型训练经常说的通信瓶颈本质上就是带宽瓶颈。4.4 显存不够时做CPU Offload双倍搬运的灾难当模型大到单卡显存放不下常见的方案是CPU offload就是把部分参数放在系统内存里用的时候再搬到显存。这个方案能在有限显存下跑起更大的模型但代价是外粮道成为绝对瓶颈。我在一台双路EPYC机器上试过用CPU offload跑一个13B模型微调PCIe 4.0 x16的带宽只有30GB/s左右而模型和优化器状态动辄几十GB每一轮迭代光是参数搬运就要好几秒。结果整个训练速度比纯显存方案慢了5到10倍。这不是意外而是数学上必然的PCIe带宽和显存带宽之间本来就是1-2个数量级的差距。所以在设计大模型训练/推理方案时一定要优先考虑让参数住得离计算核心越近越好实在装不下再考虑offload。同时可以结合量化、梯度检查点等手段减少搬运量而不是盲目依赖CPU offload。5. 粮道堵住之后为什么GPU反而更烫了这一节是发烫优化系列的核心联动点。很多人有个直觉如果性能瓶颈在带宽计算单元实际在等待那功耗应该下降才对。但实测经常相反——带宽受限的场景下温度依然很高有时甚至比正常满载更高。5.1 计算单元在空转不代表功耗会显著下降GPU内部有成百上千个SMStreaming Multiprocessor即便带宽不足SM也不会完全停止工作而是处于一种忙等状态线程在等待访存数据返回时调度器会尝试切换其他线程继续执行。现代GPU的并发线程数非常多靠线程级并行TLP来掩盖访存延迟所以即使访存成为瓶颈SM上依然有大量线程在运行只是做的都是等待和不可见的工作。这就是假满载现象从nvidia-smi看GPU-Util是90%甚至99%功耗也接近TDP但实际有效计算吞吐很低。这些空转线程同样消耗动态功耗同时产生了热量。我在排查一次A100温度过高问题时发现执行带宽受限的embedding查询和attention score计算时GPU功耗比执行高算术强度的矩阵乘法低不了多少但有效吞吐只有后者的三分之一。5.2 高带宽负载下的显存和VRM发热GPU发烫不只是核心的事。当显存带宽被拉满时显存颗粒本身的发热量非常可观。GDDR6X在满载读写时的功耗能到整卡功耗的20%-30%显存颗粒温度经常比核心还高。这个问题在RTX 3090上尤其典型因为GDDR6X的功耗和发热都更高很多非公版卡在长时间跑模型时显存温度能到100度以上而核心温度才70多度。VRM供电模块也是容易被忽视的发热源。显存带宽拉满意味着显存供电电路持续高负载MOS管和电感上的损耗会在高频开关中变成热量。如果散热片没覆盖好VRM区域局部热点反而比核心更危险。我拆过一张长时间跑大模型的显卡核心硅脂已经干裂但更严重的是显存颗粒对应的背板和导热垫处有明显的热老化痕迹。所以在评估GPU发烫问题的时候一定要把核心、显存、VRM三个部分的温度和功耗分开看光是盯着Core Temp很容易漏掉真正的热点。5.3 用带宽负载来控制功耗和热量反过来说如果想把功耗和温度降下来除了降低算力负载另一个有效切入点是降低带宽负载。因为带宽受限时功耗并没有显著下降如果能减少无效的数据搬运GPU在更短时间内完成有效计算然后早点进入低功耗状态整体发热量反而会下降。我常用的手段有这么几个在推理服务里合并请求加大batchsize让权重在一次读取后服务更多token摊薄单位token搬运量在训练里用混合精度或量化把权重的字节数降下来直接减少搬运量在不需要高帧率/高吞吐的时段用nvidia-smi -pl限制功耗墙比如把默认350W限制到250W温度能降十几度同时由于本来就是带宽受限性能损失往往不像想象中那么大在数据中心里可以结合温度传感器做动态调度把训练任务调度到散热条件更好的卡上或者主动限制带宽型任务的独占时间片。5.4 发烫优化系列联动散热设计和带宽瓶颈一起考虑这一系列的第一篇聊的是直接散热但散热设计不能孤立看必须结合负载特征。如果业务负载主要是带宽密集型比如大模型逐token推理、Embedding查询、批量特征预处理那么发热重心往往从核心转移到显存和VRM这时候风道设计、导热垫选择和供电散热方案需要倾斜到对应区域。在服务器端多卡并排安装时卡的散热器和卡的进风面容易互相干扰如果中间间距不够后方显卡的进风温度已经很高显存和VRM散热效率会进一步下降。我在一台8卡机器上就踩过这个坑把两张卡装在紧挨着的两个PCIe槽位跑大模型推理时后排卡的温度比前排高了近15度。后来换到间隔槽位并调整了机箱风扇转速曲线温差缩小到3度以内。散热不是独立的一门课它是带宽、功耗、频率、环境温度联合作用的结果。一个优秀的性能优化方案一定是把热墙和带宽墙放在一起考量的。6. 现实可行的疏通粮道优化清单前面把原理和排查方法讲完了这一节落到实操。我从软件、框架、硬件三个层面整理了个人验证过的优化方向按优先级排列。6.1 软件算法层减少搬运融合计算第一个方向是算子融合Kernel Fusion。把多个需要在显存里写中间结果的算子合并成一个kernel让中间结果留在寄存器或共享内存中避免反复读写显存。这个手段在Transformer里特别有效比如把QK^T计算和Softmax融合把LayerNorm融合进残差连接都是实操收益很大的优化。第二个方向是内存复用与减少临时变量。PyTorch里频繁使用torch.cat、torch.stack或者大量中间张量会产生很多额外拷贝。尽量用torch.cat之前先view成连续内存避免框架做隐式拷贝。写自定义CUDA kernel时优先使用共享内存做block内归约减少全局内存的读写。第三个方向是用更小的数据类型。FP16、BF16、INT8量化不只是为了加速计算对带宽也是直接利好。权重和激活值的字节数降一半搬运量就降一半。在llama.cpp里跑Q4模型速度比FP16模型快3-4倍核心原因就在这里。6.2 框架与数据管道层让CPU和GPU两班倒在PyTorch里我建议重点检查这几点DataLoader的num_workers至少要设为CPU核心数的一半以上让数据预处理和GPU计算并行打开pin_memoryTrue让CPU到GPU的传输走DMA尽量用torch.compile或者GPU上的数据增强算子把预处理放到GPU上执行避免在训练循环里频繁做.cpu()和.numpy()转换这会强制打断GPU流水线如果做分布式训练检查NCCL_P2P_DISABLE和NCCL_SHM_DISABLE等环境变量错误设置会强制走较慢的通信路径。我见过太多人卡在数据管道上用num_workers0跑大半天还以为是显卡性能问题。打开num_workers8和pin_memory之后训练速度翻了3倍GPU利用率也稳定在95%以上。6.3 硬件平台层链路宽度和互联拓扑检查如果你反复优化软件依然觉得带宽不够这时再看硬件层面确认显卡插在物理x16插槽且在BIOS里设置了PCIe 4.0/5.0模式多卡机器优先核对卡间互联拓扑。nvidia-smi topo -m能直观显示卡与卡之间的连接方式NV#代表NVLinkPIX、PXB代表不同级别的PCIe桥接如果卡与卡之间只有SYS说明要经过CPU间通信梯度同步带宽很低考虑调整任务分配方式使用NVLink的卡确认驱动和NVLink状态正常nvidia-smi nvlink -s。另外我要特别提醒的是很多人配新机器时只看显卡型号不关注CPU内存通道数和PCIe通道数。如果用一颗只有20条PCIe通道的消费级CPU去带一张x16显卡还要同时插NVMe固态和万兆网卡通道必然会被拆分显卡可能只能拿到x8甚至x4。这种硬件层面自带的带宽限制靠软件优化是补不回来的。6.4 最后分享一个小经验在我实际调优过的场景里带宽瓶颈很少是单一原因绝大多数是数据管道太弱 链路协商掉速 访存模式差三者叠加。所以遇到性能问题时不要急着换卡先按第3章的流程把链路状态、利用率、吞吐数据全部采一遍再针对性处理。另外日志和基准测试一定要保留。很多性能问题在环境变更后才暴露比如驱动更新后PCIe链路协商异常、BIOS设置被重置成PCIe 3.0、新加的采集卡抢占了PCIe通道。没有基准数据你会很难判断是硬件还是软件改动引起的倒退。我每次给服务器做完重大配置变更都会跑一遍gpu-burn和nvidia-smi dmon记录基线这个习惯帮我省了不少排查时间。带宽问题就像城市交通不是路修得越宽就一定越通畅还要看交叉口、信号灯、车流密度是否匹配。GPU的粮道也是这样算力再强数据到不了位、搬不动、走不快发热和低吞吐都会接踵而至。这篇的内容对普通用户可能偏底层的但如果你在搞大模型训练、推理部署或者只是想把GPU用得更效率花点时间理解带宽和粮道的关系一定值得。