拓冰网站定制 
1. 为什么GPU运维跟普通服务器运维不是一回事我先说个真实感受干运维这些年Linux服务器玩得再溜第一次面对一整机GPU卡的时候还是会有种“明明每个命令都认识但就是不知道哪里不对劲”的感觉。CPU服务器你查负载、看内存、查磁盘IO基本能定位出八九成的问题。但GPU服务器不一样它上面跑的东西——训练脚本、推理服务、渲染任务——对GPU的依赖是“独占式”的一张卡状态不对整个任务可能直接卡死或者OOM而且报错信息有时候看起来完全跟GPU没关系。这也是为什么我特别想写这篇GPU运维基础知识。现在随便一个做AI、做渲染、做科学计算的团队多少都会有几台带GPU的服务器。再加上“GPU租用”“GPU集群”“GPU微调大模型”这些需求越来越普遍运维同学躲是躲不掉的。与其等到线上任务挂了再去翻文档不如先把GPU运维最核心的那套知识体系搭起来。这篇文章我从实操角度出发覆盖这么几块内容怎么正确识别和监控GPU、驱动和CUDA版本到底怎么配才不打架、压力测试工具怎么用、多卡机器和集群调度要注意什么、以及最常见故障的排查链路。内容定位是“运维视角”不是“算法工程师视角”——算法关心的是loss有没有降运维关心的是卡稳不稳定、显存够不够、驱动别崩、温度别爆、任务别把整台机器拖死。适合谁看只要你的工作职责里包含“管GPU服务器”这几个字不管是专职的AI基础设施运维还是兼职管几台带卡服务器又或者是刚接手公司GPU集群的初级运维这篇文章都能给你搭出一个相对完整的知识框架。里面涉及的命令、工具、排查思路都是可以直接拿去用的。2. 先学会看懂nvidia-smi除了显存占用还要看什么2.1 GPU识别的两条路径系统层与驱动层拿到一台新服务器第一步永远是搞清楚机器上到底有几张卡、是什么型号、是不是所有卡都被系统正常识别了。这个“识别”分两个层面系统层和驱动层。系统层看的是PCIe总线上有没有这张卡驱动层看的是驱动有没有成功加载、卡有没有进入可用状态。先看系统层。Linux下最直接的命令是lspci | grep -i nvidia这个命令走的是PCIe总线扫描不依赖任何NVIDIA驱动。输出大概是这样的$ lspci | grep -i nvidia 01:00.0 3D controller: NVIDIA Corporation GA102 [GeForce RTX 3080] (rev a1) 02:00.0 3D controller: NVIDIA Corporation GA102 [GeForce RTX 3080] (rev a1)如果这里能列出卡说明硬件层面没问题PCIe链路是通的。如果这里什么都查不到那问题就大了——先别急着装驱动优先怀疑物理安装、供电、PCIe插槽接触这些硬件层面的原因。驱动层就靠nvidia-smi了。装好驱动后nvidia-smi会跟内核态的驱动通信列出所有被驱动接管且状态正常的GPU。建议执行下面这条命令它会输出非常详细的信息$ nvidia-smi -q你会看到每张卡的型号、显存总容量、驱动版本、CUDA版本、运行状态、温度、功耗、利用率、显存占用、PCIe链路速率等一大堆信息。看下面几个关键字段就够日常使用字段含义关注点Product NameGPU型号确认卡对不对Driver Version驱动版本决定后面能装哪个CUDA版本CUDA Version驱动支持的最高CUDA版本不是当前运行版本后面细说Memory Total显存总量区分卡型的重要依据ECC Errors显存ECC错误计数有增长就要警惕硬件故障Temperature当前温度长期超过85度要处理散热Power Draw / Limit当前功耗 / 功耗上限撞功耗墙会造成性能下降UtilizationGPU利用率判断任务是否真的在跑Persistence Mode持久模式开关建议开启后面解释2.2 区分GPU利用率和显存占用两个完全不同的指标很多刚接触GPU运维的同学会犯一个错误看到nvidia-smi里显存占用很高就以为GPU在忙看到显存占用不高就以为GPU很闲。这俩根本不是一回事。显存占用说的是数据放了多少在显存里GPU利用率说的是计算单元SM忙不忙。有的模型推理服务启动后会把权重全部加载进显存这时候显存占用可能跑到80%但利用率只有个位数——因为大多数时间都在等请求进来。反过来有的任务显存占用不高但计算极度密集利用率直接拉满。判断GPU是不是真的在干活要看Utilization和Volatile GPU-Util这类利用率字段。如果显存占用很高但利用率长期为0要么任务在等数据加载要么程序卡死了。这时候就该用nvidia-smi配合进程信息来定位$ nvidia-smi --query-compute-appspid,used_memory,process_name --formatcsv这个命令能列出每个占用GPU的进程及其显存使用量比你在ps aux里大海捞针快多了。真正常用的几个监控方式后面第5章细说这里先把概念掰清楚。2.3 驱动层的“状态字段”藏着硬件健康信息nvidia-smi -q里有一组字段平时不怎么被关注但关键时刻能救命——GPU的健康状态、时钟频率、PCIe链路相关信息。先看这两个Current ECC Mode : Enabled ECC Errors: Volatile SRAM Correctable : 0 SRAM Uncorrectable : 0 DRAM Correctable : 0 DRAM Uncorrectable : 0ECC是显存的纠错机制。可纠正错误Correctable可以理解为“偶尔算错了一两位但被自动补回来了”少量出现不用太紧张但如果这个计数持续增长说明显存在劣化得准备走售后。不可纠正错误Uncorrectable一旦出现意味着显存真的坏了这张卡不能继续承担关键计算任务必须立刻隔离和维修。这个逻辑跟内存ECC是一回事你可以把它理解成显存的“体检报告”。再看时钟和功耗Clocks: Graphics : 210 MHz Memory : 405 MHz SM : 210 MHz Power: Draw : 35.26 W Limit : 300.00 W正常情况下满载时图形时钟和SM时钟都会顶到boost频率附近。如果跑着大任务但时钟频率上不去、功耗也拉不上去就要怀疑是不是被其他进程限制比如有人用nvidia-smi -lgc把时钟锁死了或者供电异常、温度保护介入导致掉频。3. 驱动、CUDA、框架的版本兼容矩阵安装翻车重灾区3.1 先理清三个“CUDA”到底分别指什么这是GPU运维里最容易把人绕晕的地方我们常说的CUDA其实对应三个不同层面的东西。第一个是NVIDIA显卡驱动自带的CUDA Driver API就是你nvidia-smi里看到的CUDA Version字段这个值表示“当前驱动最高支持哪个CUDA版本”它是运行时的基础所有上层CUDA应用都必须跟它兼容。第二个是CUDA Toolkit就是算法那边装的那一大包开发工具和运行时库。Toolkit里带了自己的libcudart、libcublas这些东西安装时它会要求“驱动版本不低于某个值”。第三个是深度学习框架自己编译用的CUDA比如PyTorch的cu118、cu121这些轮子实际上是把CUDA运行时库跟框架打了个包。运维最容易犯的错是把这三者混为一谈。比如看到nvidia-smi显示CUDA Version 12.4就以为服务器上已经能跑CUDA 12.4的程序了——这是不对的。nvidia-smi显示的只是驱动支持的上限至于框架能不能用上CUDA取决于运行时库跟驱动的兼容性。实际排查时驱动版本是硬约束只要驱动够新上面跑什么CUDA版本都由算法那边装什么Toolkit决定。3.2 版本匹配的实操思路向上兼容但别乱向上我见过太多因为版本不匹配导致的奇奇怪怪问题PyTorch训练时报CUDA error: no kernel image is available for execution on the device、PaddleOCR装完一跑就崩、驱动装完系统直接起不来。这些问题九成都能通过版本规划规避。一个稳妥的做法是先定框架版本再反推驱动版本。比如算法要用PyTorch 2.1对应的官方预编译包是cu118或cu121那么驱动至少得满足11.8或12.1的要求。驱动向下兼容CUDA版本只要驱动够新低版本的CUDA库都能跑但不能向上兼容CUDA库版本比驱动支持的高就废了。版本选型时建议建一个这样的对照表贴在团队wiki里框架/工具需要的CUDA版本驱动最低版本建议PyTorch 2.1 (cu121)12.1Driver 530PyTorch 2.3 (cu121)12.1Driver 545PaddleOCR GPU版10.2 / 11.2 / 12.6按你装的CUDA Toolkit版本定TensorFlow 2.1311.8Driver 520注意这张表只是示例实际请以官方文档为准但思路是清晰的每次升级框架、驱动、CUDA这三个里的任何一个都要走一次全面的兼容性检查。3.3 驱动安装翻车的三个典型环节第一是内核模块编译。NVIDIA驱动本质上是一个内核模块通过DKMS或直接编译的方式跟当前内核版本匹配。服务器升级内核后驱动经常失效就是因为模块跟新内核不匹配。更稳的做法是开DKMS$ sudo dnf install dkms $ sudo ./NVIDIA-Linux-x86_64-XXX.run --dkms这样升级内核时DKMS会自动重新编译驱动模块少掉很多坑。第二是Nouveau驱动没屏蔽。NVIDIA官方驱动的安装脚本通常会要求先禁用开源的Nouveau驱动否则会冲突。CentOS/RHEL系的服务器要新建或修改/etc/modprobe.d/blacklist-nouveau.confblacklist nouveau options nouveau modeset0改完后重建initramfs并重启$ sudo mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak $ sudo dracut /boot/initramfs-$(uname -r).img $(uname -r) $ sudo reboot第三是安装模式和图形界面的冲突。带图形界面的服务器装驱动时建议临时切到多用户模式systemctl isolate multi-user.target再装装完再切回来。不切的话X server会占用显卡设备节点驱动模块无法正常加载。3.4 安装完驱动后必须做的验证确认装完驱动别急着说完工至少做这么几步验证# 1. 确认驱动已加载 $ lsmod | grep nvidia # 2. 确认GPU能被正常识别 $ nvidia-smi # 3. 查看驱动版本和内核模块是否匹配 $ cat /proc/driver/nvidia/version # 4. 查看内核日志里有没有GPU相关报错 $ dmesg | grep -i nvidia | tail -n 20一个容易被忽略的点是模块加载顺序。如果服务器上有多个GPU型号混插还可以检查nvidia-smi -L确认每张卡都被识别了没有显示ERR!状态。某张卡显示ERR!大概率是这张卡跟驱动通信异常常见原因是显卡掉PCIe链路或供电不稳定先查物理连接再查日志。4. 用gpu-burn做压力测试是骡子是马拉出来遛遛4.1 为什么必须做GPU压力测试而不是直接跑业务GPU服务器跟CPU服务器不一样拿到手或者出现故障后恢复维修你不能直接丢个训练任务上去验证“好像能用了”。原因有三第一训练任务通常只占一部分显存和计算单元很多硬件隐患根本触达不到第二训练任务跑挂了的报错往往是“CUDA OOM”这种表象你看不出是驱动问题、散热问题还是显存颗粒本身有坏块第三多卡机器相对容易出现单一卡在特定负载下掉链子的情况——只有系统性压力测试才能覆盖。业界用得比较多的GPU压测工具是gpu-burnGitHub上开源的用法非常简单。它通过CUDA来给GPU施加持续的计算负载同时可以配置显存占用量让每张GPU卡都以较高强度连续工作从而暴露散热、供电、显存、驱动层面潜在的不稳定因素。4.2 gpu-burn的安装和压测实操先装依赖和拉代码$ sudo apt install build-essential git # Ubuntu系 $ sudo yum groupinstall Development Tools # CentOS系 $ git clone https://github.com/wilicc/gpu-burn.git $ cd gpu-burn $ make编译需要CUDA Toolkit环境变量CUDA_HOME指到正确的路径常见路径是/usr/local/cuda。如果编译时找不到头文件就在Makefile里把CUDA_INCLUDE_PATH修一下。快速压测直接用$ ./gpu_burn 60这个命令会持续烤卡60秒。更标准的做法推荐烤个10到30分钟尤其是新到货的机器或者刚从售后回来的卡。压测过程中开另一个终端持续观察卡片状态$ watch -n 1 nvidia-smi重点看温度曲线和功耗曲线。压测输出的日志里有GPU 0: OK这样的字段压完以后所有卡都显示OK才算通过。日志里的误差值要重点关注——GPU浮点计算有极小的误差是正常的但误差值异常飙升往往暗示显存或GPU芯片有硬件问题。4.3 如何从压测结果里读出真正的隐患光看到“所有卡都OK”还不够你得学会看几张卡的数值是否一致性。比如4张同型号卡一起压测某张卡的温度比其他卡高15度以上那基本可以判定这张卡的散热模组有问题——也许硅脂干了也许风扇转速异常。这时候就算压测通过了也要标记这张卡重点关注因为它的寿命和稳定性会差一截。再比如压测时某张卡的功耗始终上不去只有别的卡的一半那要么是供电模块有问题要么是卡被某种方式锁了功耗。这里有个运维老手常用的命令$ nvidia-smi -q -d POWER | grep -E Power Draw|Power Limit如果Power Limit和Power Draw长期有明显差距且GPU利用率一直是100%说明卡吃不满功耗存在供电限制或硬件老化。压测过程中如果出现SW Notify之类的信息或者某个GPU突然从nvidia-smi列表里消失说明这张卡出现了严重不稳定基本可以判定PCIe链路或供电存在问题稳妥的做法是整卡下线送修。4.4 压测和业务冲突的处理技巧压测会长时间占满GPU团队里如果有算法同学在跑训练先协调时间窗口。再或者你可以在非核心时段跑用CUDA_VISIBLE_DEVICES0,1 ./gpu_burn 600指定只压某几张卡不干扰其他卡上的业务。我在实际运维中还习惯配合nvidia-smi -pl把功耗上限临时拉高来做更严苛的压测。比如默认功耗上限300W你可以尝试$ nvidia-smi -pl 350如果卡的供电余量不够这个操作会直接失败或者在压测时触发过流保护。这种极限测试能提前暴露供电短板——毕竟业务高峰期的负载是最刁钻的供电余量越早发现越安全。注意这只是测试操作测完一定要把功耗拉回默认值。5. 多卡与GPU集群运维调度、隔离和共享的那些事5.1 多卡机器上最容易被忽略的“卡间通信”问题多卡训练比如分布式数据并行对卡间通信带宽极其敏感。很多算法同学会觉得我4张卡都100%利用率了训练速度怎么就上不去呢这时候运维要重点排查PCIe链路拓扑和卡间通信方式。先用nvidia-smi topo -m查看卡间互联拓扑$ nvidia-smi topo -m输出里会显示卡与卡之间是NV#NVLink、PIX同一PCIe交换机下、PXB走PCIe桥还是SYS跨CPU走QPI/UPI互联。如果两张需要高频通信的卡之间显示SYS说明它们在跨CPU通信延迟和带宽都会差很多这种拓扑对训练性能影响非常大。很多非专业AI服务器的主板只有x16的PCIe插槽若干插满4卡之后会是PXB甚至SYS拓扑这时候跑分布式训练的性能是远不如NVLink互联的。运维能做的是在装卡时提前规划好插槽位置优先让卡落在同一颗CPU的PCIe控制器下尽量保持通信走PIX级别。5.2 让GPU利用率不塌方的驱动层调优打开持久化模式是第一步$ nvidia-smi -pm 1这个操作会让驱动后台常驻避免每个CUDA进程启动时重新初始化驱动能明显缩短任务启动时间和降低CPU开销多卡机器上尤其管用。然后要看GPU工作时钟是否正常。有的运维在调试时用nvidia-smi -lgc锁过时钟这个设置在某些驱动版本下会持久保存导致后续所有任务都跑在低频率上。排查手法很简单$ nvidia-smi -q -d CLOCK | grep -E Graphics|SM|Memory满载时如果Graphics时钟还停留在几百MHz的idle频率检查一下有没有锁频设置$ nvidia-smi --query-gpuclocks.gr,clocks.max.gr --formatcsv性能调优的另一面是显存时钟和GPU时钟的联动。有些驱动会把显存频率调得很激进导致某些有问题的显存颗粒报错。如果观察ECC错误持续增长且跟负载强相关可以通过nvidia-smi -lmc锁定显存频率到一个稍低的档位做临时稳定——注意这是临时手段最终还是要走硬件维修。5.3 怎么用MIG做卡级别隔离让一张卡当多张用A100/H100这类新卡支持MIGMulti-Instance GPU功能可以把一张物理GPU切成多个互不干扰的实例。这对多人共用一台服务器非常有用算法A用1g.5gb跑推理算法B用4g.20gb跑训练两边互不可见天然隔离显存和计算单元。开启MIG的运维操作是这样的$ nvidia-smi -mig 1 # 先开启MIG模式需要root $ nvidia-smi mig -cgi 1g.5gb,1g.5gb,4g.20gb # 创建实例配置 $ nvidia-smi mig -cci # 应用配置创建好之后用户通过CUDA_VISIBLE_DEVICES0访问的就是第一个1g.5gb实例互不干扰。MIG有一个运维必须知道的坑它只支持Ampere及之后的专业卡A100/A30等消费级卡和部分旧卡不支持。另外开启MIG后nvidia-smi的展示逻辑会变复杂每个物理卡下面会列出多个实例监控脚本如果还是按物理卡数量做巡检会出现误报。5.4 GPU集群监控体系怎么建采集、告警、报表三件套单机用watch nvidia-smi可以凑合但一旦到了十几台甚至几十台GPU服务器就必须有集中式监控。我推荐的轻量方案是node_exporter加dcgm-exporter采集指标Prometheus存储Grafana出图Alertmanager报警。DCGM是NVIDIA官方的数据中心GPU管理工具指标比nvidia-smi更全包括GPU温度、功耗、利用率、显存带宽、PCIe吞吐、NVLink流量等非常建议用这个。DCGM部署起来不复杂。先装DCGM$ sudo dnf install datacenter-gpu-manager # CentOS/RHEL $ sudo systemctl enable --now nv-hostengine然后跑dcgm-exporter暴露Prometheus格式指标$ ./dcgm-exporter --address:9400在Prometheus里配好采集之后Grafana可以直接套用NVIDIA官方提供的DCGM dashboard模板几分钟就能出一套完整的GPU监控大屏。告警规则至少要覆盖这么几条监控项建议阈值说明GPU温度持续10分钟高于85度散热异常检查风扇和积灰显存ECC正确错误24小时内增长超过X显存劣化信号GPU掉卡卡从nvidia-smi消失严重硬件或链路故障显存利用率长期接近100%服务可能即将OOMGPU利用率有任务但持续为0进程可能已卡死功耗异常偏离与基准偏离超过20%供电异常告警一定要分级别。温度偏高、ECC缓慢增长这类是Warning级别掉卡、不可纠正ECC这类是Critical级别。别把所有问题都设成同一个级别不然告警疲劳比没有告警更可怕。5.5 租用GPU服务器时运维要提前搞清楚的事现在很多团队会临时租GPU服务器跑深度学习。租来的机器虽然不用管硬件采购和机房但运维要为使用方把关以下几件事。第一件是驱动和CUDA版本是否满足框架要求。我碰到过几次这种情况租来的机器驱动版本太老PyTorch的CUDA 12版本根本没法跑。所以下单之前一定先确认驱动版本或者跟供应商说清楚你要跑什么框架让他们提前装好匹配的驱动。第二件是多卡机器的卡间拓扑。租4卡或8卡机器前先问清楚是不是NVLink互联有些“便宜的8卡机器”实际上是两套4卡平台拼起来的跨卡通信走网络训练性能会大打折扣。第三件是数据存储位置和IO带宽。GPU机器如果配的是机械硬盘或者普通云盘加载数据会成为新的瓶颈训练时GPU利用率一直抖动这时候不是GPU的锅而是数据读太慢。建议至少配一块NVMe SSD放数据集。有条件的团队可以搞并行文件系统或对象存储挂载但前期先用本地SSD就能解决大部分问题。6. 故障排查实录从“机器卡顿”到“GPU掉卡”的完整链路6.1 案例一GPU、CPU、内存占用都不高但机器整体卡顿这是热搜词里让我印象最深的一条——“gpu cpu 内存占用都不高但卡”。我在实际运维中遇到过好几次这种情况而且每次都极具迷惑性。最典型的一次是某算法同学反馈“服务器很卡但看资源占用都不高”。排查链路是这样的第一步先看整体负载。top和free -h正常CPU和内存都没有跑满的趋势。这时候不要慌着下结论说“资源够”。第二步看磁盘IO。很多老手会忽略的是数据加载对磁盘的压力。执行iostat -x 1我看到util几乎到了100%瓶颈立刻就出来了。训练每次迭代都要读一批图片数据如果数据集放在局域网挂载盘或者性能很差的磁盘上CPU在等数据GPU也在等数据整台机器看起来就是“占用不高但卡”。第三步再看进程D状态。ps aux里如果有一堆进程卡在D state不可中断睡眠就是在等IO。用pidstat -d 1能看到具体是哪个进程在疯狂等待磁盘。这类问题的解法分两层短期缓解可以给数据集加缓存、调整DataLoader的num_workers和prefetch_factor长期方案是把数据放到本地NVMe SSD上或者跟算法同学商量改用内存映射的方式读数据。那次排查之后我把团队里所有GPU服务器的数据集目录全部迁到了本地SSD类似投诉就再也没出现过。“占用不高但卡”这个话题还可以延展到一种情况GPU利用率不高但任务变慢了。这时候要看是不是GPU在等CPU喂数据或者是不是存在数据预处理瓶颈。排障思路是一样的——先看CPU是不是忙再看磁盘IO最后排查GPU时钟有没有异常。6.2 案例二训练中途GPU掉卡从日志里定位根因交易所级的惨案很多但最有代表性的是“训练跑到一半GPU从nvidia-smi里消失了”。这种情况的现场通常很诡异训练脚本还在跑但速度突然断崖式下跌报错信息是CUDA设备不可用而nvidia-smi一查本来4张卡只剩3张了。遇到这种问题先稳住的结论可能是卡坏了但也不一定。排查链路是这样的第一步立刻看内核日志$ dmesg -T | grep -i -E nvrm|NVRM|nvidia | tail -n 50如果看到类似NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus的日志说明GPU从PCIe总线上掉下来了。Xid 79是最常见的掉卡错误码对应的原因通常是供电波动、PCIe链路不稳定或者GPU过热保护导致芯片主动脱离总线。第二步查整机的供电状态。GPU服务器功耗非常吓人满负荷运行时单卡功耗可以到300W以上4卡就是1.2千瓦以上。如果电源功率余量不够或者线缆老化供电不稳大负载时电压波动就会让显卡掉链子。我看过很多机房里的GPU服务器配了非常廉价的电源或使用了劣质转接线这些都是隐患。第三步查散热。掉卡之前如果温度日志显示卡已经冲到90多度甚至100度那过热导致的自我保护是大概率原因。这种情况要拆开机器清理灰尘、检查风扇转速顺便看看GPU散热器的硅脂干了没有。Xid错误其实不止79这一种常见的有这么几个Xid错误含义典型原因79GPU从PCIe总线掉线供电不稳、PCIe链路松动、过热13CUDA图形引擎错误显存访问异常31显存ECC不可纠正错误显存硬件故障45内存分配失败显存不足或驱动程序问题48电源管理异常供电模块不稳定63驱动异常GPU已重置驱动bug或硬件不稳定排障完Xid 79之后即使卡重新出现了也要跑一轮gpu-burn压测确认稳定性并且重点观察ECC错误计数和温度。如果短期内再次掉卡直接走硬件维修流程别拖。6.3 案例三PyTorch装完不认GPU一步步排查到根因“pytorch安装教程gpu”是热搜词里很常见的关键词实际工作中我也被问过很多次“为什么装完PyTorch还是不认GPU”。典型现场是代码执行torch.cuda.is_available()返回False。第一层排查是驱动层面$ nvidia-smi如果这里都报错先解决驱动问题参考第3章。如果nvidia-smi正常说明驱动没问题问题大概率出在PyTorch侧。第二层排查是看PyTorch编译用的CUDA版本跟驱动匹配不匹配$ python -c import torch; print(torch.version.cuda)如果显示11.8而你机器的驱动版本支持的最高CUDA版本是10.2那PyTorch根本找不到可用的CUDA运行时。查驱动支持的最高版本用nvidia-smi里的CUDA Version字段。驱动支持的最高CUDA版本不能低于PyTorch需要的CUDA版本这是铁律。第三层排查是看PyTorch的二进制包有没有问题。用pip list | grep torch看装的是CPU版还是GPU版。很多人装翻车是因为直接执行了pip install torch在部分环境下默认会装CPU版执行nvidia-smi正常但PyTorch就是用不了GPU这个坑我已经见过很多次了。正确安装GPU版PyTorch的方式是$ pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完后执行$ python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count())输出True和卡的张数才算真正通了。第四层排查是权限和容器层面的。如果在容器里跑需要加--gpus all参数或配置nvidia-container-runtime否则容器里根本看不到GPU设备。宿主机正常但容器里nvidia-smi报错第一时间检查容器运行时是不是nvidia-container-runtime。6.4 GPU机器最常见的“隐形坑”Shared Memory、ulimit、dmesg权限排在故障排查最后要提几个很容易被忽视却又高频出现的“隐形杀手”。第一是/dev/shm太小。PyTorch的DataLoader要用共享内存做进程间数据传输默认的/dev/shm只有物理内存的一半数据量大就会报DataLoader worker (pid xxx) is killed by signal: Bus error。这个排查思路比较冷门很多人以为是程序有bug。修复方法是启动容器时加大/dev/shm$ docker run --shm-size32g ...或者在宿主机上直接调大$ mount -o remount,size64G /dev/shm第二是ulimit限制。深度学习框架会开大量线程和文件描述符如果ulimit -n默认只有1024跑大规模数据加载时就会报Too many open files。建议在/etc/security/limits.conf里把相关用户的nofile调高比如65535。第三是一张卡上多个进程的事。GPU显存是独占式的如果两拨人同时在同一张卡上跑大任务必然有一个会OOM。运维要建立GPU资源分配规范比如统一通过调度平台分配或者在无法上调度平台的情况下用CUDA_VISIBLE_DEVICES硬隔离。7. 运维工具箱和效率手段日常巡检脚本怎么做7.1 一份能直接抄走的GPU每日巡检脚本单台机器可以用一行命令巡检多台机器建议写成脚本放到crontab里每天早上自动检查一遍并把结果发到群里或者邮件。我分享一个精简但足够实用的巡检脚本思路#!/bin/bash # GPU daily health check # 1. 检查nvidia-smi是否正常 if ! nvidia-smi /dev/null; then echo CRITICAL: nvidia-smi unavailable exit 1 fi # 2. 检查是否有GPU处于ERR!状态 ERROR_GPUS$(nvidia-smi --query-gpuindex,name --formatcsv,noheader | grep ERR! | wc -l) if [ $ERROR_GPUS -gt 0 ]; then echo CRITICAL: $ERROR_GPUS GPU(s) in ERR! state fi # 3. 检查温度 # 4. 检查显存剩余空间 # 5. 检查ECC错误计数 # 6. 输出整体摘要 nvidia-smi --query-gpuindex,name,temperature.gpu,memory.used,memory.total,utilization.gpu,power.draw,power.limit --formatcsv第3到第5步的实现不难用nvidia-smi --query-gpu...分别取温度、显存和ECC字段跟阈值比一下就行。巡检脚本最重要的是稳定输出、明确阈值不要一次性报一大堆噪声那样没人会看。7.2 GPU压力测试与基准数据建立每台机器的“性能基线”运维最怕的不是机器性能差而是性能差了你不知道。要解决这个问题建议在每台GPU服务器首次交付验收时跑一次标准化的压测和基准测试记录一套“性能基线”比如gpu-burn跑30分钟的最大温度、稳定功耗、压测误差值再用一个标准的矩阵乘法或训练脚本跑一遍记录耗时。之后每次故障排查或者驱动升级之后再跑一遍同样的基准跟基线对比。温度高了10度、同样的任务慢了20%、功耗少了30W这些偏差都是早期硬件劣化的信号。我见过很多团队的驱动版本长期不更新排查问题容易走弯路。其实驱动升级本身也算一次“小保养”升级完必做的动作就是重跑基线和压测确认性能没有回退。7.3 从“救火”到“防火”GPU运维的日常SOP最后分享一套我梳理给团队的SOP已经反复验证过效果不错每天早上8点巡检脚本自动执行异常告警钉钉/企微推送。每周一次人工检查一遍nvidia-smi -q里ECC错误累计情况看是否有趋势性增长。每月一次选业务低峰窗口对随机抽取的一张卡做10分钟gpu-burn快速压测。每季度一次全部GPU跑一次完整压测重新记录性能基线。驱动或CUDA版本变更时先在一台非业务机器上验证兼容性再灰度扩大最后全量。变更后必须重跑基准。这套SOP看起来简单但能覆盖绝大多数GPU服务器的故障演进路径。GPU硬件的故障不像CPU主板那种“突然就完了”更多是渐进劣化——ECC误差先增长接着温度变高再然后出现偶发Xid错误最后整卡掉线。巡检的意义在于把这些渐进信号提前抓出来在影响业务之前处理掉。我个人最深刻的体会是GPU运维的多数事故不是“能力不够”而是“发现太晚”。只要把监控做起来、基线立起来、变更流程规范起来GPU服务器的稳定性是可以做到非常高的。 GPU运维实战：从驱动配置到故障排查全解析
1. 为什么GPU运维跟普通服务器运维不是一回事我先说个真实感受干运维这些年Linux服务器玩得再溜第一次面对一整机GPU卡的时候还是会有种“明明每个命令都认识但就是不知道哪里不对劲”的感觉。CPU服务器你查负载、看内存、查磁盘IO基本能定位出八九成的问题。但GPU服务器不一样它上面跑的东西——训练脚本、推理服务、渲染任务——对GPU的依赖是“独占式”的一张卡状态不对整个任务可能直接卡死或者OOM而且报错信息有时候看起来完全跟GPU没关系。这也是为什么我特别想写这篇GPU运维基础知识。现在随便一个做AI、做渲染、做科学计算的团队多少都会有几台带GPU的服务器。再加上“GPU租用”“GPU集群”“GPU微调大模型”这些需求越来越普遍运维同学躲是躲不掉的。与其等到线上任务挂了再去翻文档不如先把GPU运维最核心的那套知识体系搭起来。这篇文章我从实操角度出发覆盖这么几块内容怎么正确识别和监控GPU、驱动和CUDA版本到底怎么配才不打架、压力测试工具怎么用、多卡机器和集群调度要注意什么、以及最常见故障的排查链路。内容定位是“运维视角”不是“算法工程师视角”——算法关心的是loss有没有降运维关心的是卡稳不稳定、显存够不够、驱动别崩、温度别爆、任务别把整台机器拖死。适合谁看只要你的工作职责里包含“管GPU服务器”这几个字不管是专职的AI基础设施运维还是兼职管几台带卡服务器又或者是刚接手公司GPU集群的初级运维这篇文章都能给你搭出一个相对完整的知识框架。里面涉及的命令、工具、排查思路都是可以直接拿去用的。2. 先学会看懂nvidia-smi除了显存占用还要看什么2.1 GPU识别的两条路径系统层与驱动层拿到一台新服务器第一步永远是搞清楚机器上到底有几张卡、是什么型号、是不是所有卡都被系统正常识别了。这个“识别”分两个层面系统层和驱动层。系统层看的是PCIe总线上有没有这张卡驱动层看的是驱动有没有成功加载、卡有没有进入可用状态。先看系统层。Linux下最直接的命令是lspci | grep -i nvidia这个命令走的是PCIe总线扫描不依赖任何NVIDIA驱动。输出大概是这样的$ lspci | grep -i nvidia 01:00.0 3D controller: NVIDIA Corporation GA102 [GeForce RTX 3080] (rev a1) 02:00.0 3D controller: NVIDIA Corporation GA102 [GeForce RTX 3080] (rev a1)如果这里能列出卡说明硬件层面没问题PCIe链路是通的。如果这里什么都查不到那问题就大了——先别急着装驱动优先怀疑物理安装、供电、PCIe插槽接触这些硬件层面的原因。驱动层就靠nvidia-smi了。装好驱动后nvidia-smi会跟内核态的驱动通信列出所有被驱动接管且状态正常的GPU。建议执行下面这条命令它会输出非常详细的信息$ nvidia-smi -q你会看到每张卡的型号、显存总容量、驱动版本、CUDA版本、运行状态、温度、功耗、利用率、显存占用、PCIe链路速率等一大堆信息。看下面几个关键字段就够日常使用字段含义关注点Product NameGPU型号确认卡对不对Driver Version驱动版本决定后面能装哪个CUDA版本CUDA Version驱动支持的最高CUDA版本不是当前运行版本后面细说Memory Total显存总量区分卡型的重要依据ECC Errors显存ECC错误计数有增长就要警惕硬件故障Temperature当前温度长期超过85度要处理散热Power Draw / Limit当前功耗 / 功耗上限撞功耗墙会造成性能下降UtilizationGPU利用率判断任务是否真的在跑Persistence Mode持久模式开关建议开启后面解释2.2 区分GPU利用率和显存占用两个完全不同的指标很多刚接触GPU运维的同学会犯一个错误看到nvidia-smi里显存占用很高就以为GPU在忙看到显存占用不高就以为GPU很闲。这俩根本不是一回事。显存占用说的是数据放了多少在显存里GPU利用率说的是计算单元SM忙不忙。有的模型推理服务启动后会把权重全部加载进显存这时候显存占用可能跑到80%但利用率只有个位数——因为大多数时间都在等请求进来。反过来有的任务显存占用不高但计算极度密集利用率直接拉满。判断GPU是不是真的在干活要看Utilization和Volatile GPU-Util这类利用率字段。如果显存占用很高但利用率长期为0要么任务在等数据加载要么程序卡死了。这时候就该用nvidia-smi配合进程信息来定位$ nvidia-smi --query-compute-appspid,used_memory,process_name --formatcsv这个命令能列出每个占用GPU的进程及其显存使用量比你在ps aux里大海捞针快多了。真正常用的几个监控方式后面第5章细说这里先把概念掰清楚。2.3 驱动层的“状态字段”藏着硬件健康信息nvidia-smi -q里有一组字段平时不怎么被关注但关键时刻能救命——GPU的健康状态、时钟频率、PCIe链路相关信息。先看这两个Current ECC Mode : Enabled ECC Errors: Volatile SRAM Correctable : 0 SRAM Uncorrectable : 0 DRAM Correctable : 0 DRAM Uncorrectable : 0ECC是显存的纠错机制。可纠正错误Correctable可以理解为“偶尔算错了一两位但被自动补回来了”少量出现不用太紧张但如果这个计数持续增长说明显存在劣化得准备走售后。不可纠正错误Uncorrectable一旦出现意味着显存真的坏了这张卡不能继续承担关键计算任务必须立刻隔离和维修。这个逻辑跟内存ECC是一回事你可以把它理解成显存的“体检报告”。再看时钟和功耗Clocks: Graphics : 210 MHz Memory : 405 MHz SM : 210 MHz Power: Draw : 35.26 W Limit : 300.00 W正常情况下满载时图形时钟和SM时钟都会顶到boost频率附近。如果跑着大任务但时钟频率上不去、功耗也拉不上去就要怀疑是不是被其他进程限制比如有人用nvidia-smi -lgc把时钟锁死了或者供电异常、温度保护介入导致掉频。3. 驱动、CUDA、框架的版本兼容矩阵安装翻车重灾区3.1 先理清三个“CUDA”到底分别指什么这是GPU运维里最容易把人绕晕的地方我们常说的CUDA其实对应三个不同层面的东西。第一个是NVIDIA显卡驱动自带的CUDA Driver API就是你nvidia-smi里看到的CUDA Version字段这个值表示“当前驱动最高支持哪个CUDA版本”它是运行时的基础所有上层CUDA应用都必须跟它兼容。第二个是CUDA Toolkit就是算法那边装的那一大包开发工具和运行时库。Toolkit里带了自己的libcudart、libcublas这些东西安装时它会要求“驱动版本不低于某个值”。第三个是深度学习框架自己编译用的CUDA比如PyTorch的cu118、cu121这些轮子实际上是把CUDA运行时库跟框架打了个包。运维最容易犯的错是把这三者混为一谈。比如看到nvidia-smi显示CUDA Version 12.4就以为服务器上已经能跑CUDA 12.4的程序了——这是不对的。nvidia-smi显示的只是驱动支持的上限至于框架能不能用上CUDA取决于运行时库跟驱动的兼容性。实际排查时驱动版本是硬约束只要驱动够新上面跑什么CUDA版本都由算法那边装什么Toolkit决定。3.2 版本匹配的实操思路向上兼容但别乱向上我见过太多因为版本不匹配导致的奇奇怪怪问题PyTorch训练时报CUDA error: no kernel image is available for execution on the device、PaddleOCR装完一跑就崩、驱动装完系统直接起不来。这些问题九成都能通过版本规划规避。一个稳妥的做法是先定框架版本再反推驱动版本。比如算法要用PyTorch 2.1对应的官方预编译包是cu118或cu121那么驱动至少得满足11.8或12.1的要求。驱动向下兼容CUDA版本只要驱动够新低版本的CUDA库都能跑但不能向上兼容CUDA库版本比驱动支持的高就废了。版本选型时建议建一个这样的对照表贴在团队wiki里框架/工具需要的CUDA版本驱动最低版本建议PyTorch 2.1 (cu121)12.1Driver 530PyTorch 2.3 (cu121)12.1Driver 545PaddleOCR GPU版10.2 / 11.2 / 12.6按你装的CUDA Toolkit版本定TensorFlow 2.1311.8Driver 520注意这张表只是示例实际请以官方文档为准但思路是清晰的每次升级框架、驱动、CUDA这三个里的任何一个都要走一次全面的兼容性检查。3.3 驱动安装翻车的三个典型环节第一是内核模块编译。NVIDIA驱动本质上是一个内核模块通过DKMS或直接编译的方式跟当前内核版本匹配。服务器升级内核后驱动经常失效就是因为模块跟新内核不匹配。更稳的做法是开DKMS$ sudo dnf install dkms $ sudo ./NVIDIA-Linux-x86_64-XXX.run --dkms这样升级内核时DKMS会自动重新编译驱动模块少掉很多坑。第二是Nouveau驱动没屏蔽。NVIDIA官方驱动的安装脚本通常会要求先禁用开源的Nouveau驱动否则会冲突。CentOS/RHEL系的服务器要新建或修改/etc/modprobe.d/blacklist-nouveau.confblacklist nouveau options nouveau modeset0改完后重建initramfs并重启$ sudo mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak $ sudo dracut /boot/initramfs-$(uname -r).img $(uname -r) $ sudo reboot第三是安装模式和图形界面的冲突。带图形界面的服务器装驱动时建议临时切到多用户模式systemctl isolate multi-user.target再装装完再切回来。不切的话X server会占用显卡设备节点驱动模块无法正常加载。3.4 安装完驱动后必须做的验证确认装完驱动别急着说完工至少做这么几步验证# 1. 确认驱动已加载 $ lsmod | grep nvidia # 2. 确认GPU能被正常识别 $ nvidia-smi # 3. 查看驱动版本和内核模块是否匹配 $ cat /proc/driver/nvidia/version # 4. 查看内核日志里有没有GPU相关报错 $ dmesg | grep -i nvidia | tail -n 20一个容易被忽略的点是模块加载顺序。如果服务器上有多个GPU型号混插还可以检查nvidia-smi -L确认每张卡都被识别了没有显示ERR!状态。某张卡显示ERR!大概率是这张卡跟驱动通信异常常见原因是显卡掉PCIe链路或供电不稳定先查物理连接再查日志。4. 用gpu-burn做压力测试是骡子是马拉出来遛遛4.1 为什么必须做GPU压力测试而不是直接跑业务GPU服务器跟CPU服务器不一样拿到手或者出现故障后恢复维修你不能直接丢个训练任务上去验证“好像能用了”。原因有三第一训练任务通常只占一部分显存和计算单元很多硬件隐患根本触达不到第二训练任务跑挂了的报错往往是“CUDA OOM”这种表象你看不出是驱动问题、散热问题还是显存颗粒本身有坏块第三多卡机器相对容易出现单一卡在特定负载下掉链子的情况——只有系统性压力测试才能覆盖。业界用得比较多的GPU压测工具是gpu-burnGitHub上开源的用法非常简单。它通过CUDA来给GPU施加持续的计算负载同时可以配置显存占用量让每张GPU卡都以较高强度连续工作从而暴露散热、供电、显存、驱动层面潜在的不稳定因素。4.2 gpu-burn的安装和压测实操先装依赖和拉代码$ sudo apt install build-essential git # Ubuntu系 $ sudo yum groupinstall Development Tools # CentOS系 $ git clone https://github.com/wilicc/gpu-burn.git $ cd gpu-burn $ make编译需要CUDA Toolkit环境变量CUDA_HOME指到正确的路径常见路径是/usr/local/cuda。如果编译时找不到头文件就在Makefile里把CUDA_INCLUDE_PATH修一下。快速压测直接用$ ./gpu_burn 60这个命令会持续烤卡60秒。更标准的做法推荐烤个10到30分钟尤其是新到货的机器或者刚从售后回来的卡。压测过程中开另一个终端持续观察卡片状态$ watch -n 1 nvidia-smi重点看温度曲线和功耗曲线。压测输出的日志里有GPU 0: OK这样的字段压完以后所有卡都显示OK才算通过。日志里的误差值要重点关注——GPU浮点计算有极小的误差是正常的但误差值异常飙升往往暗示显存或GPU芯片有硬件问题。4.3 如何从压测结果里读出真正的隐患光看到“所有卡都OK”还不够你得学会看几张卡的数值是否一致性。比如4张同型号卡一起压测某张卡的温度比其他卡高15度以上那基本可以判定这张卡的散热模组有问题——也许硅脂干了也许风扇转速异常。这时候就算压测通过了也要标记这张卡重点关注因为它的寿命和稳定性会差一截。再比如压测时某张卡的功耗始终上不去只有别的卡的一半那要么是供电模块有问题要么是卡被某种方式锁了功耗。这里有个运维老手常用的命令$ nvidia-smi -q -d POWER | grep -E Power Draw|Power Limit如果Power Limit和Power Draw长期有明显差距且GPU利用率一直是100%说明卡吃不满功耗存在供电限制或硬件老化。压测过程中如果出现SW Notify之类的信息或者某个GPU突然从nvidia-smi列表里消失说明这张卡出现了严重不稳定基本可以判定PCIe链路或供电存在问题稳妥的做法是整卡下线送修。4.4 压测和业务冲突的处理技巧压测会长时间占满GPU团队里如果有算法同学在跑训练先协调时间窗口。再或者你可以在非核心时段跑用CUDA_VISIBLE_DEVICES0,1 ./gpu_burn 600指定只压某几张卡不干扰其他卡上的业务。我在实际运维中还习惯配合nvidia-smi -pl把功耗上限临时拉高来做更严苛的压测。比如默认功耗上限300W你可以尝试$ nvidia-smi -pl 350如果卡的供电余量不够这个操作会直接失败或者在压测时触发过流保护。这种极限测试能提前暴露供电短板——毕竟业务高峰期的负载是最刁钻的供电余量越早发现越安全。注意这只是测试操作测完一定要把功耗拉回默认值。5. 多卡与GPU集群运维调度、隔离和共享的那些事5.1 多卡机器上最容易被忽略的“卡间通信”问题多卡训练比如分布式数据并行对卡间通信带宽极其敏感。很多算法同学会觉得我4张卡都100%利用率了训练速度怎么就上不去呢这时候运维要重点排查PCIe链路拓扑和卡间通信方式。先用nvidia-smi topo -m查看卡间互联拓扑$ nvidia-smi topo -m输出里会显示卡与卡之间是NV#NVLink、PIX同一PCIe交换机下、PXB走PCIe桥还是SYS跨CPU走QPI/UPI互联。如果两张需要高频通信的卡之间显示SYS说明它们在跨CPU通信延迟和带宽都会差很多这种拓扑对训练性能影响非常大。很多非专业AI服务器的主板只有x16的PCIe插槽若干插满4卡之后会是PXB甚至SYS拓扑这时候跑分布式训练的性能是远不如NVLink互联的。运维能做的是在装卡时提前规划好插槽位置优先让卡落在同一颗CPU的PCIe控制器下尽量保持通信走PIX级别。5.2 让GPU利用率不塌方的驱动层调优打开持久化模式是第一步$ nvidia-smi -pm 1这个操作会让驱动后台常驻避免每个CUDA进程启动时重新初始化驱动能明显缩短任务启动时间和降低CPU开销多卡机器上尤其管用。然后要看GPU工作时钟是否正常。有的运维在调试时用nvidia-smi -lgc锁过时钟这个设置在某些驱动版本下会持久保存导致后续所有任务都跑在低频率上。排查手法很简单$ nvidia-smi -q -d CLOCK | grep -E Graphics|SM|Memory满载时如果Graphics时钟还停留在几百MHz的idle频率检查一下有没有锁频设置$ nvidia-smi --query-gpuclocks.gr,clocks.max.gr --formatcsv性能调优的另一面是显存时钟和GPU时钟的联动。有些驱动会把显存频率调得很激进导致某些有问题的显存颗粒报错。如果观察ECC错误持续增长且跟负载强相关可以通过nvidia-smi -lmc锁定显存频率到一个稍低的档位做临时稳定——注意这是临时手段最终还是要走硬件维修。5.3 怎么用MIG做卡级别隔离让一张卡当多张用A100/H100这类新卡支持MIGMulti-Instance GPU功能可以把一张物理GPU切成多个互不干扰的实例。这对多人共用一台服务器非常有用算法A用1g.5gb跑推理算法B用4g.20gb跑训练两边互不可见天然隔离显存和计算单元。开启MIG的运维操作是这样的$ nvidia-smi -mig 1 # 先开启MIG模式需要root $ nvidia-smi mig -cgi 1g.5gb,1g.5gb,4g.20gb # 创建实例配置 $ nvidia-smi mig -cci # 应用配置创建好之后用户通过CUDA_VISIBLE_DEVICES0访问的就是第一个1g.5gb实例互不干扰。MIG有一个运维必须知道的坑它只支持Ampere及之后的专业卡A100/A30等消费级卡和部分旧卡不支持。另外开启MIG后nvidia-smi的展示逻辑会变复杂每个物理卡下面会列出多个实例监控脚本如果还是按物理卡数量做巡检会出现误报。5.4 GPU集群监控体系怎么建采集、告警、报表三件套单机用watch nvidia-smi可以凑合但一旦到了十几台甚至几十台GPU服务器就必须有集中式监控。我推荐的轻量方案是node_exporter加dcgm-exporter采集指标Prometheus存储Grafana出图Alertmanager报警。DCGM是NVIDIA官方的数据中心GPU管理工具指标比nvidia-smi更全包括GPU温度、功耗、利用率、显存带宽、PCIe吞吐、NVLink流量等非常建议用这个。DCGM部署起来不复杂。先装DCGM$ sudo dnf install datacenter-gpu-manager # CentOS/RHEL $ sudo systemctl enable --now nv-hostengine然后跑dcgm-exporter暴露Prometheus格式指标$ ./dcgm-exporter --address:9400在Prometheus里配好采集之后Grafana可以直接套用NVIDIA官方提供的DCGM dashboard模板几分钟就能出一套完整的GPU监控大屏。告警规则至少要覆盖这么几条监控项建议阈值说明GPU温度持续10分钟高于85度散热异常检查风扇和积灰显存ECC正确错误24小时内增长超过X显存劣化信号GPU掉卡卡从nvidia-smi消失严重硬件或链路故障显存利用率长期接近100%服务可能即将OOMGPU利用率有任务但持续为0进程可能已卡死功耗异常偏离与基准偏离超过20%供电异常告警一定要分级别。温度偏高、ECC缓慢增长这类是Warning级别掉卡、不可纠正ECC这类是Critical级别。别把所有问题都设成同一个级别不然告警疲劳比没有告警更可怕。5.5 租用GPU服务器时运维要提前搞清楚的事现在很多团队会临时租GPU服务器跑深度学习。租来的机器虽然不用管硬件采购和机房但运维要为使用方把关以下几件事。第一件是驱动和CUDA版本是否满足框架要求。我碰到过几次这种情况租来的机器驱动版本太老PyTorch的CUDA 12版本根本没法跑。所以下单之前一定先确认驱动版本或者跟供应商说清楚你要跑什么框架让他们提前装好匹配的驱动。第二件是多卡机器的卡间拓扑。租4卡或8卡机器前先问清楚是不是NVLink互联有些“便宜的8卡机器”实际上是两套4卡平台拼起来的跨卡通信走网络训练性能会大打折扣。第三件是数据存储位置和IO带宽。GPU机器如果配的是机械硬盘或者普通云盘加载数据会成为新的瓶颈训练时GPU利用率一直抖动这时候不是GPU的锅而是数据读太慢。建议至少配一块NVMe SSD放数据集。有条件的团队可以搞并行文件系统或对象存储挂载但前期先用本地SSD就能解决大部分问题。6. 故障排查实录从“机器卡顿”到“GPU掉卡”的完整链路6.1 案例一GPU、CPU、内存占用都不高但机器整体卡顿这是热搜词里让我印象最深的一条——“gpu cpu 内存占用都不高但卡”。我在实际运维中遇到过好几次这种情况而且每次都极具迷惑性。最典型的一次是某算法同学反馈“服务器很卡但看资源占用都不高”。排查链路是这样的第一步先看整体负载。top和free -h正常CPU和内存都没有跑满的趋势。这时候不要慌着下结论说“资源够”。第二步看磁盘IO。很多老手会忽略的是数据加载对磁盘的压力。执行iostat -x 1我看到util几乎到了100%瓶颈立刻就出来了。训练每次迭代都要读一批图片数据如果数据集放在局域网挂载盘或者性能很差的磁盘上CPU在等数据GPU也在等数据整台机器看起来就是“占用不高但卡”。第三步再看进程D状态。ps aux里如果有一堆进程卡在D state不可中断睡眠就是在等IO。用pidstat -d 1能看到具体是哪个进程在疯狂等待磁盘。这类问题的解法分两层短期缓解可以给数据集加缓存、调整DataLoader的num_workers和prefetch_factor长期方案是把数据放到本地NVMe SSD上或者跟算法同学商量改用内存映射的方式读数据。那次排查之后我把团队里所有GPU服务器的数据集目录全部迁到了本地SSD类似投诉就再也没出现过。“占用不高但卡”这个话题还可以延展到一种情况GPU利用率不高但任务变慢了。这时候要看是不是GPU在等CPU喂数据或者是不是存在数据预处理瓶颈。排障思路是一样的——先看CPU是不是忙再看磁盘IO最后排查GPU时钟有没有异常。6.2 案例二训练中途GPU掉卡从日志里定位根因交易所级的惨案很多但最有代表性的是“训练跑到一半GPU从nvidia-smi里消失了”。这种情况的现场通常很诡异训练脚本还在跑但速度突然断崖式下跌报错信息是CUDA设备不可用而nvidia-smi一查本来4张卡只剩3张了。遇到这种问题先稳住的结论可能是卡坏了但也不一定。排查链路是这样的第一步立刻看内核日志$ dmesg -T | grep -i -E nvrm|NVRM|nvidia | tail -n 50如果看到类似NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus的日志说明GPU从PCIe总线上掉下来了。Xid 79是最常见的掉卡错误码对应的原因通常是供电波动、PCIe链路不稳定或者GPU过热保护导致芯片主动脱离总线。第二步查整机的供电状态。GPU服务器功耗非常吓人满负荷运行时单卡功耗可以到300W以上4卡就是1.2千瓦以上。如果电源功率余量不够或者线缆老化供电不稳大负载时电压波动就会让显卡掉链子。我看过很多机房里的GPU服务器配了非常廉价的电源或使用了劣质转接线这些都是隐患。第三步查散热。掉卡之前如果温度日志显示卡已经冲到90多度甚至100度那过热导致的自我保护是大概率原因。这种情况要拆开机器清理灰尘、检查风扇转速顺便看看GPU散热器的硅脂干了没有。Xid错误其实不止79这一种常见的有这么几个Xid错误含义典型原因79GPU从PCIe总线掉线供电不稳、PCIe链路松动、过热13CUDA图形引擎错误显存访问异常31显存ECC不可纠正错误显存硬件故障45内存分配失败显存不足或驱动程序问题48电源管理异常供电模块不稳定63驱动异常GPU已重置驱动bug或硬件不稳定排障完Xid 79之后即使卡重新出现了也要跑一轮gpu-burn压测确认稳定性并且重点观察ECC错误计数和温度。如果短期内再次掉卡直接走硬件维修流程别拖。6.3 案例三PyTorch装完不认GPU一步步排查到根因“pytorch安装教程gpu”是热搜词里很常见的关键词实际工作中我也被问过很多次“为什么装完PyTorch还是不认GPU”。典型现场是代码执行torch.cuda.is_available()返回False。第一层排查是驱动层面$ nvidia-smi如果这里都报错先解决驱动问题参考第3章。如果nvidia-smi正常说明驱动没问题问题大概率出在PyTorch侧。第二层排查是看PyTorch编译用的CUDA版本跟驱动匹配不匹配$ python -c import torch; print(torch.version.cuda)如果显示11.8而你机器的驱动版本支持的最高CUDA版本是10.2那PyTorch根本找不到可用的CUDA运行时。查驱动支持的最高版本用nvidia-smi里的CUDA Version字段。驱动支持的最高CUDA版本不能低于PyTorch需要的CUDA版本这是铁律。第三层排查是看PyTorch的二进制包有没有问题。用pip list | grep torch看装的是CPU版还是GPU版。很多人装翻车是因为直接执行了pip install torch在部分环境下默认会装CPU版执行nvidia-smi正常但PyTorch就是用不了GPU这个坑我已经见过很多次了。正确安装GPU版PyTorch的方式是$ pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完后执行$ python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count())输出True和卡的张数才算真正通了。第四层排查是权限和容器层面的。如果在容器里跑需要加--gpus all参数或配置nvidia-container-runtime否则容器里根本看不到GPU设备。宿主机正常但容器里nvidia-smi报错第一时间检查容器运行时是不是nvidia-container-runtime。6.4 GPU机器最常见的“隐形坑”Shared Memory、ulimit、dmesg权限排在故障排查最后要提几个很容易被忽视却又高频出现的“隐形杀手”。第一是/dev/shm太小。PyTorch的DataLoader要用共享内存做进程间数据传输默认的/dev/shm只有物理内存的一半数据量大就会报DataLoader worker (pid xxx) is killed by signal: Bus error。这个排查思路比较冷门很多人以为是程序有bug。修复方法是启动容器时加大/dev/shm$ docker run --shm-size32g ...或者在宿主机上直接调大$ mount -o remount,size64G /dev/shm第二是ulimit限制。深度学习框架会开大量线程和文件描述符如果ulimit -n默认只有1024跑大规模数据加载时就会报Too many open files。建议在/etc/security/limits.conf里把相关用户的nofile调高比如65535。第三是一张卡上多个进程的事。GPU显存是独占式的如果两拨人同时在同一张卡上跑大任务必然有一个会OOM。运维要建立GPU资源分配规范比如统一通过调度平台分配或者在无法上调度平台的情况下用CUDA_VISIBLE_DEVICES硬隔离。7. 运维工具箱和效率手段日常巡检脚本怎么做7.1 一份能直接抄走的GPU每日巡检脚本单台机器可以用一行命令巡检多台机器建议写成脚本放到crontab里每天早上自动检查一遍并把结果发到群里或者邮件。我分享一个精简但足够实用的巡检脚本思路#!/bin/bash # GPU daily health check # 1. 检查nvidia-smi是否正常 if ! nvidia-smi /dev/null; then echo CRITICAL: nvidia-smi unavailable exit 1 fi # 2. 检查是否有GPU处于ERR!状态 ERROR_GPUS$(nvidia-smi --query-gpuindex,name --formatcsv,noheader | grep ERR! | wc -l) if [ $ERROR_GPUS -gt 0 ]; then echo CRITICAL: $ERROR_GPUS GPU(s) in ERR! state fi # 3. 检查温度 # 4. 检查显存剩余空间 # 5. 检查ECC错误计数 # 6. 输出整体摘要 nvidia-smi --query-gpuindex,name,temperature.gpu,memory.used,memory.total,utilization.gpu,power.draw,power.limit --formatcsv第3到第5步的实现不难用nvidia-smi --query-gpu...分别取温度、显存和ECC字段跟阈值比一下就行。巡检脚本最重要的是稳定输出、明确阈值不要一次性报一大堆噪声那样没人会看。7.2 GPU压力测试与基准数据建立每台机器的“性能基线”运维最怕的不是机器性能差而是性能差了你不知道。要解决这个问题建议在每台GPU服务器首次交付验收时跑一次标准化的压测和基准测试记录一套“性能基线”比如gpu-burn跑30分钟的最大温度、稳定功耗、压测误差值再用一个标准的矩阵乘法或训练脚本跑一遍记录耗时。之后每次故障排查或者驱动升级之后再跑一遍同样的基准跟基线对比。温度高了10度、同样的任务慢了20%、功耗少了30W这些偏差都是早期硬件劣化的信号。我见过很多团队的驱动版本长期不更新排查问题容易走弯路。其实驱动升级本身也算一次“小保养”升级完必做的动作就是重跑基线和压测确认性能没有回退。7.3 从“救火”到“防火”GPU运维的日常SOP最后分享一套我梳理给团队的SOP已经反复验证过效果不错每天早上8点巡检脚本自动执行异常告警钉钉/企微推送。每周一次人工检查一遍nvidia-smi -q里ECC错误累计情况看是否有趋势性增长。每月一次选业务低峰窗口对随机抽取的一张卡做10分钟gpu-burn快速压测。每季度一次全部GPU跑一次完整压测重新记录性能基线。驱动或CUDA版本变更时先在一台非业务机器上验证兼容性再灰度扩大最后全量。变更后必须重跑基准。这套SOP看起来简单但能覆盖绝大多数GPU服务器的故障演进路径。GPU硬件的故障不像CPU主板那种“突然就完了”更多是渐进劣化——ECC误差先增长接着温度变高再然后出现偶发Xid错误最后整卡掉线。巡检的意义在于把这些渐进信号提前抓出来在影响业务之前处理掉。我个人最深刻的体会是GPU运维的多数事故不是“能力不够”而是“发现太晚”。只要把监控做起来、基线立起来、变更流程规范起来GPU服务器的稳定性是可以做到非常高的。