GPU主机这个东西说起来高端真正用起来就是一部血泪史。我这些年经手过不少训练服务器、推理节点也帮朋友收拾过各种“疑难杂症”从驱动装不上、显存报错到多卡通信异常、CPU和内存占用都不高但训练就是卡得要命问题五花八门但根子上其实就那么几个方向。今天干脆把这些年踩过的坑、排过雷的过程整理一遍也算给搞GPU运维、跑深度学习训练的朋友一份实战排查手册。这篇内容主要围绕GPU主机的故障排查思路展开覆盖驱动层、显存层、性能层、硬件与散热、多卡集群这几个方向。不管你是跑PyTorch还是PaddleOCR是单卡调模型还是多卡微调大模型是在本地服务器还是租用的GPU实例上操作这套排查逻辑基本都通用。1. 驱动层故障GPU主机最常见的第一道坎1.1 驱动装不上先分清是系统问题还是卡的问题很多朋友拿到一台带独立显卡的服务器第一件事就是装驱动。最典型的场景是装NVIDIA驱动时装到一半报错或者装好了重启直接黑屏、卡在登录界面循环。遇到这种情况我建议先别急着怀疑显卡坏了九成问题出在驱动安装方式和系统环境上。先说一个最常见的坑Secure Boot没关。现在的服务器主板默认开启Secure Boot而NVIDIA驱动是第三方签名模块系统启动时会被拦下来。表现出来就是装了驱动但nvidia-smi提示找不到驱动或者重启后进不了图形界面。解决办法是在BIOS里关闭Secure Boot或者给驱动模块做签名后者操作复杂一般直接关掉省事。再说nouveau开源驱动的干扰。装NVIDIA官方驱动之前必须把nouveau禁掉否则两套驱动打架装到一半报错几乎必现。禁用的方法是在/etc/modprobe.d/blacklist-nouveau.conf里写入blacklist nouveau options nouveau modeset0然后执行sudo update-initramfs -u并重启。Ubuntu系统还要确保linux-headers和build-essential都装好了否则编译内核模块那一步会报错。如果装完驱动后输入nvidia-smi显示NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver排查顺序是先确认驱动模块是否加载运行lsmod | grep nvidia如果模块没加载再去看dmesg | grep -i nvidia看具体报什么错常见的是No such device这种情况通常是显卡没被正确识别检查PCIe插槽是不是松了或者换个插槽试一下。注意新卡和老系统之间有兼容性问题。我用过一张RTX 3090插在只装了老版本内核的CentOS 7机器上驱动怎么都编译不过最后升级了内核和gcc版本才解决。1.2 驱动“掉”了居然在运行中消失比装不上更让人崩溃的是驱动跑着跑着突然没了。训练跑了一半nvidia-smi一敲提示找不到驱动但机器没有重启。这种情况我遇到过几次原因主要有三类第一类是显卡过热导致的硬件自我保护GPU直接挂起驱动检测不到设备。这种情况在闷罐机箱或者对服务器散热改造过的机箱里特别常见。表现是风扇狂转但温度仍压不住dmesg里能看到NVRM: GPU at ... has fallen off the bus之类的日志。第二类是电源供电不稳定。GPU在高负载下瞬时功耗飙升如果电源功率不足或者供电线材质量问题显卡会瞬间掉电驱动随之丢失。我在未充分供电的情况下遇到过这个问题。排查方法是换一根原装供电线或者更换功率余量更大的电源。第三类是PCIe链路不稳定。GPU插在PCIe延长线或者转接卡上时容易出现跑大负载时链路降级甚至断开。这种情况优先检查PCIe插槽和延长线。如果你是在云上租用的GPU实例遇到驱动丢失大概率是宿主机层面的问题通常提交工单让平台方处理比自己在云主机里折腾更靠谱。这类问题自己往往无法根治。1.3 驱动版本选型为什么不能无脑装最新版很多教程一上来就让用户装最新版驱动这个说法在个人游戏卡上问题不大但在跑深度学习、需要配合CUDA环境的生产服务器上就有点坑了。NVIDIA驱动和CUDA版本有对应关系驱动可以向后兼容新版本的CUDA Toolkit但老驱动不认新版本的CUDA。比如你要跑PyTorch GPU版本PyTorch官方编译时用的是某个CUDA版本如果驱动太老应用层会报CUDA driver version is insufficient for CUDA runtime version。我的经验是先把目标框架的CUDA版本确定下来再倒推驱动版本。比如要跑PyTorch的CUDA 12.1版本那NVIDIA驱动至少得是525或以上如果要跑CUDA 11.8那驱动至少520。nvidia-smi右上角会显示当前驱动支持的最高CUDA版本这个数字只要不小于应用需要的CUDA版本就行。有些朋友还要装PaddleOCR GPU版、PaddlePaddle这类框架它们的CUDA要求和PyTorch又不一样。如果你一台机器上同时跑不同框架建议装尽量新的驱动比如最新稳定版因为新驱动对旧CUDA版本兼容性更好基本不会出现“驱动太新反而跑不了旧CUDA”的情况。关于适配性顺便提一句现在除了NVIDIA还有昇腾、寒武纪等国产加速卡。很多人问“昇腾系列有哪些GPU”严格来说昇腾不叫GPU叫NPU而且它们的驱动和开发栈是独立的nvidia-smi根本不会出现。如果项目里要兼容多厂家加速卡代码抽象层最好从一开始就做设备无关的封装否则后期适配很痛苦。硬件选型时也要提前确认好开发框架是否支持目标训练或推理卡。2. 显存类故障训练中断、OOM与ECC报错2.1 OOM到底分几种别一锅端显存不够导致的CUDA out of memory是训练中遇到最多的报错但同一条报错背后可能是完全不同的原因。最常见的当然是模型太大、batch size太大一次要装进显存的数据超过了显存容量。这种情况要么减小batch size要么开启梯度累积要么用混合精度训练。但有一种OOM比显存容量不足难查得多叫显存碎片化。现象是程序一启动就报OOM可是看nvidia-smi显示的显存占用并不高。这是典型的内存碎片问题连续显存块不够分配导致的。解决办法是在PyTorch里设置环境变量import os os.environ[PYTORCH_CUDA_ALLOC_CONF] max_split_size_mb:128max_split_size_mb小一点会减少碎片化但也可能降低内存利用率需要调一个平衡值。有些场景下重启训练进程反而最快因为显存从零开始分配时往往更整。还有一种情况是显存泄漏训练时间越长显存占用越高最后OOM。这个问题单独开一节专门讲。注意服务器上如果同时跑多个进程每个进程默认都会把显存占满。排查时先用nvidia-smi查看显存占用最高的PID确认是不是自己的僵尸进程。2.2 ECC显存报错怎么定位和判断严重性数据中心级的GPUA100、A800、V100这类都有ECC显存纠错功能这是一把双刃剑它能在一定程度上纠正显存错误但如果错误太多会导致性能下降甚至训练结果异常。排查显存错误的标准姿势是用nvidia-smi -a查看每个GPU的ECC错误计数nvidia-smi -a | grep -A 20 ECC重点关注Volatile Uncorrectable和Aggregate Uncorrectable这两项前者是本次驱动加载以来的不可纠正错误数量后者是累计值。只要不可纠正错误不为0这块卡就不适合跑核心业务了。可纠正错误Correctable少量出现不用太慌张但如果增长速度很快说明显存颗粒可能在劣化建议提前准备备卡。还有一种类似情况是运行gpu-burn压力测试时发现某些测试Pattern报错这种通常也是显存颗粒问题。后续在第三章会说到压力测试的具体玩法。2.3 显存泄漏训练越跑越卡的真实原因显存泄漏是个经典难题。现象是训练集每个epoch跑完显存占用稳步上升跑几十个epoch后OOM。PyTorch里最常见的泄漏来源是在计算图中不小心保留了不该保留的中间变量或者用了.item()却没有正确释放再就是DataLoader的num_workers开太多每个worker都会复制一部分显存上下文。定位泄漏的思路不复杂。在训练循环的每个step之后打印torch.cuda.max_memory_allocated()和torch.cuda.memory_allocated()观察两者差值是否持续增大。如果max_memory_allocated一直涨基本可以确定有变量被保留在计算图里。排查方法是用torch.cuda.memory_summary()看内存分配明细哪个张量占据了内存会显示得比较清楚。对于PyTorch 2.x还可以用torch.cuda.memory._dump_snapshot()生成内存快照再用内存可视化工具打开分析。这个工具能直接看到每个张量的创建栈定位泄漏点非常高效。3. 性能类故障GPU占用率低、CPU内存都不高却卡3.1 “CPU/GPU内存占用都不高但卡”的排查方向这是热搜词里最扎心的一个词。我自己也被这个坑过配置看起来完全够用但训练一个batch都要好几秒GPU利用率始终上不去。出现这种情况先看nvidia-smi里的GPU-Util这一列。如果GPU利用率很低说明GPU没在满负荷干活那么卡顿的瓶颈就不在GPU算力本身而在“喂数据”的链路或者其他地方被拖住了。我从实际经验里总结了一套排查顺序先排除CPU计算瓶颈。很多预处理逻辑比如图像解码、数据增强、文本Tokenize都在CPU上执行CPU计算不过来GPU就会一直空转等待。跑一下top、htop观察CPU是不是被打满了。如果是优化DataLoader的num_workers和prefetch_factor或者优化预处理逻辑本身。确认磁盘IO瓶颈。如果训练数据放在机械硬盘上或者网络存储延迟很高GPU等数据的时间可能比计算时间还长。用iostat -x 1看磁盘%util是否接近100%用iotop看IO等待的进程。数据量大的话建议把数据集放到NVMe SSD上或者先用内存缓存一部分。检查锁页内存与数据传输。PyTorch里把pin_memoryTrue打开能显著减少CPU到GPU的数据拷贝时间。但要注意锁页内存本身不能无限大开太大反而会挤占系统内存导致系统卡顿。小batch也很容易掩盖性能问题。batch size太小kernel启动开销和数据搬运开销占比就会变大GPU利用率上不去。这时候可以适当调大batch size同时配合混合精度来显存换算力。提示CPU、GPU、内存占用都不高的卡顿还有一个非常隐蔽的原因是主板PCIe带宽不足。GPU通过PCIe与CPU通信如果主板把GPU插在了PCIe x8甚至x4的插槽上数据搬运带宽会暴降。3.2 数据加载瓶颈排查从DataLoader到文件系统一条链数据加载是GPU利用率不高的头号嫌疑人。很多人在本地用小数据集调通的代码搬到全量数据上跑就变慢多数是在这里出的问题。排查数据加载瓶颈的一个简单办法在训练循环里把model.forward和loss.backward注释掉只跑DataLoader的迭代然后测一个epoch耗时。如果此时耗时占比很高说明瓶颈就在数据侧。优化手段按收益从高到低排列使用lmdb或webdataset这类打包格式减少小文件随机读取的开销要知道训练集里成千上万个几KB的小图逐张读取会拖垮文件系统。PyTorch的DataLoader开启persistent_workersTrue避免每个epoch都重建worker进程。用tf.data或torchdata做流水线重叠让数据加载和GPU计算并行。如果数据增强很重尝试把它放到GPU上做比如用albumentations的GPU加速版本或者用CUDA tensor做简单增强。3.3 GPU利用率上不去也可能是通信占了时间训练卡顿还有一种情况是单卡计算本身很快但数据在多卡之间搬来搬去GPU大部分时间在等通信完成。这在多卡训练、集群训练时尤其明显。判断方法不难。在单卡上跑同样一个step记录耗时再用多卡跑先用gloo后端做对比如果多卡反而更慢先怀疑通信瓶颈。nvidia-smi topo -m可以看到多卡之间的拓扑结构如果是通过PCIe Switch通信延迟和带宽肯定不如NVLink直接互联。对于多卡训练PyTorch DDP是主流方案但很多人没注意到nccl的环境变量调优export NCCL_DEBUGINFO export NCCL_P2P_DISABLE1 export NCCL_IB_DISABLE1这三个变量特别有用。训练跑不通或通信一直hang住时打开NCCL_DEBUG能看到详细的通信日志能定位是网络问题还是GPU间通信问题。P2P_DISABLE和IB_DISABLE是规避一些GPU型号或网络环境不兼容的临时手段但会降低性能调完定位问题后建议重新开启。如果是在GPU集群上做多机训练还要额外检查InfiniBand/RoCE网络的连通性、MTU配置、防火墙规则。gpu集群故障里多机通信比单机多卡更容易出问题因为牵涉网络、存储、调度多个环节。插一句配置环境的时候经常有人问“PyTorch安装教程GPU版本”为什么装完跑不通很多就是通信库没配对。PaddleOCR的GPU版安装也有类似情况paddlepaddle-gpu和CUDA版本、driver版本都有对应关系装之前一定要去官方表里核对。4. 硬件与散热降频、风扇狂转、PCIe链路异常4.1 温度和降频GPU变卡因为你没管住它的温度GPU和CPU一样温度过高会降频保护性能直线下降。很多人发现机器跑久了越来越卡重启后恢复很可能就是降频导致的。查看GPU当前温度、频率、功耗限制一条命令就够nvidia-smi -q -d TEMPERATURE,PERFORMANCE,POWER,CLOCK重点关注GPU Current Temp和GPU Max Operating TempA100/H100这类卡的极限温度通常在85-90度消费级卡稍低一些到90度以上就要警惕了。Current Clocks和Max Clocks如果当前频率明显低于最大频率说明在降频。Power Draw和Power Limit功率跑满但温度也很高的话散热系统大概率有问题。Performance StateP0是最高性能状态如果长期在P2以下说明负载没拉起来。服务器散热不好的典型表现是连续跑训练几小时后性能下降冷启动时恢复。排查时先看风道方向确认机柜前后通风没有堵再听风扇转速转速异常高但温度还是压不住大概率是散热器积灰或者导热硅脂干涸了。如果是戴尔、浪潮这类服务器的GPU建议用ipmitool查看整机功率和温度传感器ipmitool sensor list | grep -i GPU\|Temp整机功耗数据能帮助你判断是单卡过热还是机箱整体散热不足。4.2 PCIe链路异常性能下降的隐形凶手PCIe链路问题非常隐蔽显卡插上去能用能跑起来但性能远低于预期。最常见的是链路降级明明是PCIe x16的插槽实际只跑在x8或者x4速率。排查命令nvidia-smi -q -d PCI在Link字段里能看到Width和Speed。如果显示8X或4X说明链路宽度不对可能原因包括插槽物理规格就是x8、显卡金手指接触不良、BIOS里设置的链路宽度不对、PCIe转接延长线质量差。链路状态动态降级更麻烦。刚启动时是x16跑一段时间后变成x8甚至x4经常伴随dmesg里刷PCIe Bus Error日志。这种多半是信号完整性问题也就是金手指氧化、插槽松动、转接板质量太差。这里插一句很多自媒体说扩展坞外接显卡好用但从我实际接触的案例看通过雷电网口转PCIe再接GPU的方案稳定性和性能都不理想故障率明显高于直插主板。如果你在机房或公司做GPU服务器维护尽量别折腾这种方案。4.3 gpu-burn压力测试怎么压出GPU的隐藏问题GPU压力测试工具gpu-burn是我每次接手新机器、排查不稳定故障时的必备工具。它是一个专门跑CUDA计算把GPU负载拉满的工具能在短时间内暴露散热、供电、显存颗粒的隐患。编译安装不复杂git clone https://github.com/wilicc/gpu-burn cd gpu-burn make跑测试直接执行./gpu_burn 3600后面的数字是测试秒数3600表示跑1小时。测试过程中用另一个终端窗口观察watch -n 1 nvidia-smi正常跑起来GPU-Util应该稳定在95%-100%温度稳步上升后维持稳定不会超过卡的TjMax。如果过程中出现错误输出、驱动掉线、机器重启、温度异常说明硬件在极限负载下不稳定。我更推荐压测时同时记录功耗和温度数据nvidia-smi --query-gpuindex,temperature.gpu,utilization.gpu,power.draw --formatcsv -l 5这样能连续采样把数据导入Excel画个趋势图散热系统的优劣一目了然。注意gpu-burn会把GPU跑满压测期间机器其他任务会卡顿建议在业务低峰期或新机器验收期跑。5. 多卡集群和多云环境的故障判断5.1 怎么看当前用的哪块GPU进程和容器如何隔离很多人拿到一台多卡服务器经常搞不清自己跑的程序到底用的哪块卡。这个问题看似基础但在排查性能和故障时特别关键。最直观的办法是用nvidia-smi查看进程占用。在输出表格下半部分能看到每个PID占用了哪块GPU的多少显存。如果只想看某个进程在用哪块卡可以用nvidia-smi --query-compute-appspid,gpu_uuid,used_gpu_memory --formatcsv在代码里想指定用哪块卡通过环境变量控制CUDA_VISIBLE_DEVICES2,3 python train.py这句命令的意思是让程序只能看见物理GPU 2和3对应程序里的device 0和1。CUDA_VISIBLE_DEVICES是解决多卡隔离的最基础最常用方案但要注意用了这个变量后nvidia-smi在你程序里的视角和在命令行看到的GPU Index可能会不一样因为程序里看到的索引是屏蔽后的相对索引。容器场景下用Docker跑GPU时建议加--gpus device0,1参数做显式卡绑定不要让容器默认访问所有GPU。如果服务器上有多个团队共用建议给每个容器设置显存和计算限制避免一个容器把整卡显存吃满导致别的任务OOM。5.2 公有云GPU租用实例的排查差异现在有很多人选择GPU租用按小时付费跑训练。这种方式省去了硬件维护但故障排查思路和本地服务器有区别。云GPU实例最常见的坑是实例规格和实际拿到的不一致。之前我在某个云平台租过标注为“A100 40G”的实例运行时用torch.cuda.get_device_properties(0)一看显存只有20多G。不是平台骗人而是这个规格实际分配的是A100的MIG切片Multi-Instance GPU相当于一张卡被切成了多个虚拟实例。如果你的任务是整卡训练跑之前一定要确认分到的是不是全卡。云实例的驱动升级要格外小心。平台预装的驱动往往和底层虚拟机管理程序绑定擅自升级驱动可能导致GPU设备丢失。碰到驱动问题优先用平台镜像市场里提供的GPU镜像别自己折腾。另外云主机的nvidia-smi看到的温度和功耗数据可能是虚拟化后的和物理值有偏差判断硬件故障时不能完全依赖。5.3 监控体系与告警把故障扼杀在萌芽期GPU服务器和无状态Web服务器不同出问题不仅影响业务还可能损坏训练中的模型状态。所以监控告警这块很有必要重视。我个人的最小化监控配置是每台GPU服务器上部署一个采集脚本每30秒采集一次GPU温度、利用率、显存占用、功耗、进程列表写入时序数据库Prometheus node_exporter nvidia_gpu_exporter是现成方案再配合Grafana做可视化。告警规则至少包含GPU温度超过85度持续5分钟GPU利用率低于10%但CPU利用率超过90%持续10分钟这个组合说明数据加载瓶颈显存剩余不足1GBGPU的ECC不可纠正错误计数大于0nvidia-smi执行失败驱动掉线这套告警体系搭好之后很多故障可以在用户感知之前就暴露出来。比如之前有个训练任务每天定时卡死最后查出来是另一个团队的定时任务在同一时间把CPU占满GPU等数据等到超时。没有监控数据支撑这种问题全靠猜效率太低。6. 常见问题速查与经验总结把前面提到的典型故障整理成一个速查表方便你遇到问题时快速定位现象可能原因快速排查解决建议nvidia-smi找不到驱动Secure Boot开启、nouveau未禁用、驱动未编译成功dmesg查看错误日志关闭Secure Boot、禁用nouveau、重装匹配驱动驱动运行中消失散热不佳、供电不足、PCIe链路不稳dmesg、查看温度功耗日志改善散热、更换电源、更换插槽CUDA out of memory但显存没满显存碎片化查看PYTORCH_CUDA_ALLOC_CONF设置max_split_size_mb或重启进程ECC报错增多显存颗粒劣化nvidia-smi查看ECC计数备份数据、准备换卡GPU利用率低但CPU不高数据加载瓶颈、PCIe带宽不足单独测试DataLoader耗时优化数据管线、换NVMe、检查PCIe链路多卡训练反而更慢NCCL通信瓶颈开启NCCL_DEBUG优化网络、检查拓扑、调整NCCL参数运行越久越卡GPU降频、显存泄漏查看温度频率、内存快照清理散热器、定位泄漏点这个表格算是浓缩版经验每一条展开都能写一个完整案例。实际排查时最重要的原则是不要急着重启机器先收集信息再动手。重启能解决一时问题但根因没找出来的话故障还会复现。关于“GPU的CTA是什么”简单补充一句。CTACooperative Thread Array是CUDA编程模型里的线程组织单位是GPU硬件调度任务的核心粒度。开发和驱动优化相关的工作经常会接触到这个概念但普通应用层训练调参基本不用关心。我个人在实际操作中的体会是GPU机器故障排查最忌讳的是凭感觉换硬件。曾经有一台服务器反复出现训练中断前后换了三张显卡都没解决最后发现是主板PCIe插槽附近的电容老化导致供电纹波过大。很多问题层级其实很低但表现比较隐蔽。先从软件层、驱动层、日志层逐层排查再动手碰硬件能省下大量时间和经费。每台机器都有自己奇怪的脾气但只要掌握“先看日志、再查温度、再做压测、最后换硬件”的顺序大部分问题都能在一天内落地。