写GPU运维这篇文章之前我先交代一下背景。过去几年我接触过的GPU服务器从几台散户自用的深度学习机器到几十卡规模的训练集群踩过的坑比顺利跑通的时候多得多。很多硬件和软件层面的问题表面上看起来是“卡了”、“坏了”、“驱动掉了”本质上是运维方法没对上GPU这套新体系的脾气。所以这篇不是官方手册的复述是我把GPU服务器当普通服务器折腾了几年之后沉淀下来的一套实操框架。内容包括环境搭建、驱动与CUDA版本匹配、日常监控、集群调度、压测验收、故障速查全部围绕“GPU运维”这件事展开。适合刚接手GPU服务器的运维同学也适合自己在宿舍跑深度学习顺便当兼职运维的研究生。1. GPU运维到底在运维什么1.1 为什么GPU服务器和普通服务器不一样在云时代之前我做运维的日常是盯CPU负载、内存占用、磁盘IO和网络流量这几大件基本覆盖了大多数故障场景。但GPU服务器进来之后传统那套经验直接失灵。CPU和内存占用都不高页面却卡成PPT这种例子在GPU机器上太常见了。原因在于GPU的工作模式是“并行打手”它在计算的峰值瞬间可以爆发出极高的显存带宽和计算吞吐但很多时候并不体现在CPU负载上。更关键的是GPU不是简单插在PCIe插槽上的“计算卡”它有自己独立的显存、显存控制器、流处理器、供电模组和散热系统。运维的维度从之前的三四个扩展到显存占用、GPU利用率、GPU温度、显存温度、功耗、供电接口状态、PCIe链路带宽、ECC纠错计数、驱动日志、NVLink拓扑等十几个。任何一个环节掉链子表现都可能非常诡异。还有一点很多人容易忽略GPU服务器通常是为特定负载定制的比如AI训练、推理、渲染、科学计算。不同负载对GPU的损耗模式完全不同。训练任务会让显存和算力长时间满载推理任务则是频繁的波峰波谷渲染任务对显存容量极其敏感。运维策略必须跟着负载类型走一把抓的“通用运维”在GPU这里行不通。1.2 GPU运维要盯的核心指标我从实际值班经验里归纳了七个必盯指标分别是算力利用率SM占用率、显存占用率、GPU核心温度、显存温度、当前功耗、显存ECC错误数、PCIe链路速率与带宽。算力利用率这块很多新手容易误解。nvidia-smi里的Volatile GPU-Util其实表示的是过去一段采样窗口内GPU计算单元有任务运行的时间比例并不是精确的浮点算力百分比。所以你会发现跑一个轻量推理任务的时候利用率在30%到80%之间跳动这是正常现象。但如果你跑的是大规模训练利用率长期低于70%那就要警惕是不是数据加载、CPU预处理或通信层面存在瓶颈。显存占用率直接关系到任务能否跑起来。CUDA out of memory是运维群里最常见的报错但很多时候不是显存真的不够而是之前的任务没释放干净或者碎片化严重。功耗指标用来判断GPU是否真正进入了满载状态很多卡标称300W结果跑满只有180W这个时候就要怀疑是不是被降频限制或者供电接口接触不良亦或者是驱动把功耗墙设低了。温度和显存温度是硬件寿命的决定因素。GPU核心温度虽然能到90度以上但我一向建议把警报线设在85度显存温度警报设在95度。ECC错误是GPU显存颗粒的定时炸弹轻微的错误可能有自纠能力但持续增长的不可纠正错误Uncorrectable ECC Error基本预示着显存颗粒即将物理失效该准备返修或换卡了。2. 从零搭建GPU运行环境驱动与CUDA实操2.1 驱动安装runfile方式最稳GPU运维里最基础也最容易翻车的操作就是装驱动。很多发行版的软件仓库里虽然有NVIDIA驱动包但版本通常偏旧而且和内核模块的兼容性不一定好。我自己更推荐从NVIDIA官网下载runfile安装包手动安装一个runfile只有几十MB但稳定性和可追溯性比包管理器好太多。装驱动的流程有个固定套路先禁用系统自带的nouveau开源驱动这是NVIDIA闭源驱动的天敌。在/etc/modprobe.d/blacklist-nouveau.conf里写入blacklist nouveau options nouveau modeset0然后重建initramfs并重启另一条常见命令是sudo update-initramfs -u重启后确认nouveau没加载lsmod | grep nouveau这条命令如果没输出就说明nouveau被成功禁用了。接下来关闭图形界面服务因为X server会占用GPU设备。很多人的教训都是忘了这步直接runfile安装结果报“You appear to have an X server running”只能强制退出图形界面后再试。实际安装命令我习惯这样执行chmod x NVIDIA-Linux-x86_64-550.54.14.run sudo ./NVIDIA-Linux-x86_64-550.54.14.run --no-opengl-files注意这里的--no-opengl-files它在纯计算服务器上非常重要。因为我们不需要在GPU机器上跑图形界面加上这个参数能避免把系统的OpenGL库替换掉很多时候桌面环境崩溃就是没加它导致的。安装完成后用nvidia-smi验证驱动是否正常识别到GPU。如果输出里能看到所有设备当前驱动版本和CUDA版本一栏有数字说明驱动这步已经通了。从运维角度讲我建议驱动装完顺手把安装包归档到本地因为后续排查Xid错误、驱动回归都需要知道具体的驱动版本号。2.2 CUDA版本与驱动版本怎么对应驱动装完之后CUDA Toolkit的安装就相对独立了。很多人有个误解以为一个程序要用的CUDA版本必须和驱动里显示的CUDA Version完全一致其实驱动那栏显示的版本只是一个“能支持的最高CUDA运行时版本”只要你的CUDA Toolkit不高于这个版本就行。举个实际例子如果你的nvidia-smi输出显示CUDA Version: 12.4那么你可以装CUDA 11.8、12.1、12.3等任意低于等于12.4的Toolkit但不能用CUDA 13.x。这就给运维留了很大的弹性空间。生产环境里同一个集群里不同容器用不同CUDA版本是非常常见的只要驱动够新都能向下兼容。CUDA Toolkit的安装建议用runfile而不要用deb包原因是runfile默认只解压到/usr/local下不会动系统级的OpenGL和驱动文件不会破坏现有环境。我尝试过在Ubuntu上用deb包装CUDA它有时会顺手替换显卡驱动导致一套环境刚搭好没两天就莫名其妙掉驱动排查一圈才发现是软件包依赖惹的祸。在安装CUDA Toolkit之前最好确认一下当前驱动支持的最大版本。可以使用nvidia-smi | grep CUDA Version也可以去NVIDIA官网查CUDA Toolkit和驱动版本的兼容矩阵。装完后把/usr/local/cuda-12.3这样的目录软链到/usr/local/cuda便于多版本切换sudo ln -s /usr/local/cuda-12.3 /usr/local/cuda export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH2.3 容器的GPU透传与常见配置现在几乎没有直接在宿主机上裸跑训练任务的做法了容器化已经成为GPU运维的主流。Docker本身不认识GPU需要借助NVIDIA Container Toolkit来把GPU设备文件、驱动库和运行时注入容器。安装这块的步骤稳定不变以Ubuntu为例distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker装好后在启动容器时加参数docker run --rm --gpus all -it nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi能正常输出GPU信息就说明透传成功。这里有几个很细节的坑一是run容器时最好加上--shm-size参数。PyTorch的DataLoader多进程模式有很大概率用到共享内存默认的64MB很容易导致“Bus error”或DataLoader worker挂掉我一般习惯设置成--shm-size16g甚至更大。另一个是容器内时间不同步的问题。GPU任务跑起来之后会出现CUDA error排查半天发现是宿主机和容器时间偏差过大导致的建议在容器编排时挂载/etc/localtime或者统一NTP同步。还有一点宿主机上的NVIDIA驱动版本如果后续升级需要重启所有正在运行的GPU容器否则旧容器内使用的驱动模块会和新内核模块不一致表现非常不稳定。PyTorch这类框架的GPU版本安装也属于环境搭建的重要环节。很多新人用pip直接装torch一运行就提示CUDA不可用然后再去折腾重装非常浪费时间。正确做法是先确认驱动支持的CUDA版本再去PyTorch官网选择对应CUDA版本的安装命令。比如CUDA 12.1对应的命令是pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121PaddleOCR要装GPU版本也是类似逻辑安装paddlepaddle-gpu时务必检查自己的CUDA版本比如python -m pip install paddlepaddle-gpu2.6.1 -i https://mirror.baidu.com/pypi/simple然后再安装paddleocr和paddlehub。这类框架装完可以直接用一个小测试脚本验证GPU是否参与计算import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))3. GPU状态监控与性能排查3.1 nvidia-smi深入解读nvidia-smi是整个GPU运维里出场率最高的命令没有之一。它输出本身不复杂但你要真正看懂每一个字段才能在出问题的时候第一时间定位。顶部表格里每一行代表一块GPU依次是设备编号、名称、风扇转速、温度、性能状态、功耗、显存使用、利用率。性能状态从P0到P12P0是最高性能数值越大代表越省电但性能越受限。如果你跑满负载时看到状态在P8往上就要检查是不是进入省电模式了。下面进程列表部分显示的是当前正在使用GPU的进程及其显存消耗这是排查显存泄漏最直接的窗口。如果一个训练任务退出后进程列表里还挂着残留进程显存占用却不掉可以把残留的PID杀掉。命令的扩展用法更值得掌握。实时的设备监控用nvidia-smi dmon -s pucvmet -d 1这个命令每秒刷新一次依次显示电源、利用率、计算、显存、温度等指标适合长时间观察GPU负载曲线。进程级监控用nvidia-smi pmon -c 1它会在进程粒度显示每个计算进程的GPU利用率、显存占用和SM使用率对定位多进程抢卡特别有用。如果你要看GPU的历史使用趋势做容量规划可以开启nvidia-smi的查询模式结合telegraf或自己写的采集脚本把数据持久化下来。查询单张卡显存总量、已用、利用率的方式如下nvidia-smi --query-gpuindex,memory.total,memory.used,utilization.gpu --formatcsvnvidia-smi还有个很容易被忽视的功能它可以设置GPU的功耗上限和锁频。对某些耗电量敏感的机房把GPU最大功耗从300W调到250W训练时间稍微增加一点但机柜不会跳闸这个操作在夏天屡试不爽。命令是nvidia-smi -pl 2503.2 GPU利用率不高的排查思路“CPU、GPU、内存占用都不高但就是卡”——这是我遇到的最多的性能问题这种现象背后通常是系统性的流程问题。常见的情况是数据加载在CPU端已经形成了瓶颈GPU大部分时间在空转等待数据。排查思路要从下往上逐步排除。先看存储层的IO延迟看磁盘读写是否成为瓶颈。训练数据如果是几万张小图片放在机械硬盘上IOPS根本不够喂饱GPU这几乎是新手上路最容易踩的坑。解决办法是把数据集放到SSD上或者用内存做文件缓存。接着看数据加载流程。PyTorch的DataLoader如果num_workers设成0默认是在主进程里同步加载数据GPU每算完一个batch都要等数据送到利用率自然上不去。合适的做法是把num_workers调整为机器逻辑核心数的一半左右并打开pin_memoryTrue这样数据能直接从页锁定内存传输到GPU省掉一次内存拷贝。再看是不是频繁的检查点保存或者日志输出导致GPU流水线停顿。很多人把eval过程里的打印日志放在主循环里每迭代一次就刷屏输出一次磁盘和终端IO直接拖垮整个训练速度。日志输出可以放到后台队列或者降频输出。还有一个容易被忽略的方向是通信瓶颈。在多卡训练时如果用的是PCIe互联而机器本身只有PCIe 3.0多卡通信带宽会迅速跑满。NVLink和NVSwitch在高性能场景下是必须的没有NVLink的多卡机器做分布式训练通信开销可能抵消大部分算力优势。nvidia-smi显示GPU利用率3%到20%之间剧烈波动大概率是“间歇性喂不动数据”的表现。先用上面的思路排查再考虑是不是单卡模型设置问题而不是急着换一块更贵的卡。3.3 温度、功耗与降频问题GPU是一种对温度极其敏感的硬件功耗和温度之间存在一种自我约束机制。当核心温度到达阈值后显卡驱动会自动降低频率以减缓发热这就是所谓的降频保护。最典型的降频场景是在夏天机房空调一坏或者机柜通风不畅满负载运行的GPU会在几分钟内触发降频训练速度肉眼可见下降。用nvidia-smi只能看到当前温度但看不到温度的历史趋势和频率变化这时候需要用到更专业的工具。nvtop是GPU版的top直接以交互界面的形式展示每张卡的温度、频率、功耗、显存占用和利用率安装命令一般是sudo apt install nvtop如果是腾讯云、阿里云这类云GPU实例也可以直接用厂商控制台自带的监控或者用NVIDIA官方提供的DCGMData Center GPU Manager工具集。DCGM提供的指标比nvidia-smi更细覆盖显存温度、GPU显存带宽利用率、SM时钟频率、功耗限制状态等适合大规模集群部署。功耗异常也值得单独说。GPU在空载状态下功耗应该在二三十瓦左右如果你发现GPU空闲时功耗一直挂在百瓦以上很可能是有残留进程在占用显存但没释放或者是驱动版本和CUDA版本配合得不好导致能耗管理失效。这种情况先清理进程列表再考虑驱动升级。供电问题是更隐蔽的坑。多路供电的高端卡如果只插了一根电源线或者电源线接触不良GPU在高负载时会直接掉驱动表现是系统日志里刷Xid错误甚至整个系统黑屏重启。GPU服务器运维要养成一个习惯开机后先检查供电线是否插紧定期清理机箱灰尘尤其注意显存散热片上堆积的灰尘那对散热效率的打击是立竿见影的。4. GPU集群算力管理与调度4.1 多卡机器的资源划分与共享GPU集群运维和单机运维相比最大的区别是“稀缺资源的调度”。一张A100要几万块算力可不能随便浪费。多卡机器的资源划分场景可以分为三个层面单用户多卡、多用户共享一卡、单用户虚拟化切分。单用户多卡是最简单的情况。训练脚本直接用CUDA_VISIBLE_DEVICES指定可见的GPU比如export CUDA_VISIBLE_DEVICES0,1,2,3只让当前任务看到0到3号卡。这个环境变量是运维给用户分卡最基础的手段但它的限制是进程实际上还是能独占整卡如果用户在卡上开了太多线程其他用户的性能还是会受影响。多用户共享一台机器时建议在系统层面做资源隔离。用systemd的cgroup限制某个用户的CPU和内存配额再用显卡厂商提供的MIGMulti-Instance GPU功能将物理GPU切分成多个实例。比如A100 40GB可以切成若干个计算实例每个实例拥有独立的显存和算力配额实例之间的故障隔离度很高。在支持MIG的GPU上执行nvidia-smi mig -cgi 1,2,3 -C就把一块物理GPU切成了三个实例每个实例对操作系统就像一块独立的小GPU。虚拟化层的GPU共享也可以用调度器实现。Kubernetes里通过NVIDIA Device Plugin实现GPU资源管理用户可以设置nvidia.com/gpu1来申请一整块GPU或者用时间片和显存配额实现多个Pod共享同一块GPU。但要注意默认的Device Plugin只支持独占模式共享GPU需要安装额外的GPU共享调度器插件这块在实际落地中比想象中复杂。4.2 集群级监控与调度器当GPU节点数量超过十台时逐台登录看nvidia-smi就成了灾难。集群监控要从“点”走向“面”通常以Prometheus为底座配合NVIDIA DCGM Exporter采集指标再通过Grafana出图展示集群GPU的总数、空闲数、利用率分布、显存使用率、温度与功耗等。DCGM Exporter的部署方式在容器环境下一行命令就能拉起来docker run -d --gpus all --rm --cap-add SYS_ADMIN \ -v /proc:/proc:ro \ -p 9400:9400 \ nvcr.io/nvidia/dcgm-exporter:latest然后配置Prometheus的scrape job每10秒抓一次http://节点IP:9400/metrics。Grafana里导入NVIDIA官方提供的dashboard模板整集群的状态就能一览无余。集群调度器层面Slurm仍然是传统HPC和AI训练场景的主流。Slurm的GPU调度靠GRES插件实现节点配置在slurm.conf里加上GresTypesgpu NodeNamegpu01 Gresgpu:8提交任务时指定srun --gresgpu:2 --cpus-per-task8 train.pySlurm最让我欣赏的地方是它对算力资源的统一管理和配额控制。运维可以把“黄牛党”任务按队列优先级限制住保证核心业务随时有卡可用。而如果是偏向云原生架构的团队Kubernetes加Volcano或Kueue这类批量调度器会更合适二者的取舍主要取决于团队已有的技术栈和业务形态。4.3 GPU压力测试与验收新上架的GPU服务器我都会建议先跑一轮压力测试别急着把生产任务布上去。扔两个重磅工具gpu-burn和DCGM的diagnostic工具。gpu-burn是一个专门压榨GPU算力的测试程序安装使用非常直接git clone https://github.com/wilicc/gpu-burn cd gpu-burn make ./gpu_burn 6060代表持续烤卡60秒。运行过程中建议额外开一个窗口执行nvidia-smi dmon -s pucvmet -d 1观察是否存在某张卡掉功耗、温度异常或Xid错误。测试跑完gpu-burn会输出每张卡的计算结果所有卡的数字应该一致或非常接近如果某张卡的数字明显偏低说明它的算力有问题多半是散热或供电拖了后腿。DCGM自带的诊断工具更全面一些重点检查PCIe链路、NVLink互联、显存压力、温度管理和供电稳定性dcgmi diag -r 1这里的-r 1是跑基础硬件诊断对显存做写入读取校验能发现已经处于亚健康状态的显存颗粒。验收时如果出现Level 3的Hardware Error比如显存测试失败直接走换卡流程千万不要想着系统层面通过软件绕过这种卡用着用着随时会出问题。5. 高频故障速查与避坑记录5.1 常见错误与处理GPU运维的故障表象就那么几种但背后的原因天差地别。我把这些年遇到的高频问题整理成了一张速查表新手照着查就能解决八成问题现象可能原因处理动作nvidia-smi报No devices were found驱动未加载或内核模块与当前内核不匹配执行modprobe nvidia测试不行就重装驱动CUDA out of memory但显存显示有剩余显存碎片化或残留进程未释放用nvidia-smi看进程列表杀掉残留PID后被释放训练中途Bus error容器共享内存不足加--shm-size16g重启容器系统风扇狂转但温度仍高机箱风道问题或GPU导热硅脂干涸清理灰尘严重时拆卡换硅脂多卡任务时某张卡利用率归零NVLink或PCIe链路接触不良重新插拔卡检查nvidia-smi -q里的Link速度训练结果出现NaN重新跑结果不同ECC错误累积或显存不稳定执行nvidia-smi -q -d ECC查ECC计数内核日志刷Xid 79或Xid 63GPU显存或电源故障收集日志进入返修流程开机后GPU风扇不转分辨率或负载较低或供电问题跑一次gpu-burn看温度升高后风扇是否启动Xid错误里Xid 79是GPU内部错误通常是硬件问题Xid 63是显卡与显存之间的链路错误也可能是供电不足。内核日志的查看方式是dmesg | grep -i xid定位到错误后不要只看错误码还要配合温度、功耗、PCIe链路信息才能判断是过热保护触发还是供电异常还是硬件确实要返修。这块的排查很像看中医望闻问切全用上。5.2 几个从实战中沉淀的细节习惯最后再分享一些不一定写在手册里但对我实际工作帮助很大的细节习惯。第一个习惯是装完驱动后立刻快照系统盘。GPU环境最怕的是驱动或CUDA配到一半重启之后系统再也进不去或者图形界面直接崩掉。有系统快照兜底任何失败都能退回去。第二个习惯是给GPU机器设独立的告警通道。GPU的故障发生速度比普通CPU故障快得多温度超过阈值后如果不处理硬件损坏风险是几何级上升的。温度告警、功耗异常告警、ECC错误告警都应该单独配置不要混在普通服务器告警里被刷屏刷掉。第三个习惯是定期做显存ECC检查。命令是nvidia-smi --query-gpuecc.errors.uncorrected.volatile.memory --formatcsv如果这个非零值在增加说明显存有物理故障倾向提前安排业务迁移总比业务跑一半卡崩了再处理要从容得多。第四个习惯是为每个计算任务记录GPU的“指纹信息”。启动训练任务之前记录一下当前驱动版本、CUDA版本、容器镜像、GPU利用率基线、功耗基线、温度基线。当任务性能和之前对比出现回退时把新的指纹数据和历史数据对比往往能迅速定位到是驱动升级造成的回归还是硬件老化导致性能衰退。GPU运维的很多东西都是“小习惯护大机”一台几万块的卡可能会因为一个简单习惯而多活一两年。这套知识不是一次性掌握的我也是在一次次故障和排查中一点点补全的。希望能给刚开始接触GPU运维的朋友一些启发和参考。