简介《2024年智算平台运维运营技术研究报告》立足AI算力规模化落地的现实需求系统梳理智算平台在效能、可用性、弹性伸缩与安全稳定等方面的运维挑战适合智算中心运维工程师、AI基础设施管理者、算力运营负责人以及关注智能运维转型的团队参考也可作为相关技术预研与内部培训的背景材料。报告重点解析持续监控、故障预测、自动化部署、资源管理、网络优化等落地方法并结合数据安全、隐私保护与算法模型调优展开应对策略讨论同时展望自我诊断、自我修复、自我优化的智能化运维演进方向对理解算力时代的运维体系变化有直接帮助。配套资源为1份PDF格式研究报告整体约3.95MB内容结构完整便于直接阅读与存档目前已有76人学习下载具备一定的实操借鉴与趋势研判价值。1. 智算平台的运维运营到底在解决什么问题2024年做智算平台的运维运营最直观的感受是GPU规模越大出问题的方式就越超出传统服务器的经验。CPU时代看负载、看磁盘、看网络丢包基本能过日子到了GPU集群一个Xid错误就能让几百张卡空转一次RDMA重传风暴就能让整个训练任务卡在同一个时间步上反复横跳。智算平台运维运营的核心其实只有两件事让算力尽量不闲着让大规模训练尽量不中断。前者靠资源调度和利用率优化后者靠分层监控和快速故障定位。这篇文章按一线运维的实际路径展开先搭监控体系再做调度优化再解决故障定位最后把运维数据沉淀成运营决策依据。内容面向两类人——刚接手AI算力集群的运维工程师以及被“利用率低、告警不断”折磨的平台负责人。我尽量少讲抽象概念多给能直接抄走的命令、参数和排错步骤凡是带配置和代码的后面都会说明为什么这么设、改了什么会有副作用。2. 分层监控体系搭建从GPU指标到作业生命周期监控是运维运营的第一步但智算平台的监控不能照搬传统的CPU服务器方案。GPU集群有三个截然不同的观察面硬件设备、调度平台、训练作业。把它们混在一张大盘里告警会互相淹没分成三层看故障发生时才能第一时间定位到“是哪一层出了问题”。2.1 智算平台监控为什么要分三层设备、调度、作业先明确分层逻辑。设备层看的是GPU本身、NVLink/IB网络、并行存储和供电散热回答“硬件有没有坏”平台层看的是调度器、节点状态、作业队列回答“算力有没有被正确分配”作业层看的是训练吞吐、Loss曲线、Checkpoint进度回答“训练到底跑得快不快”。分层还有一个实际好处告警的接收人不同。设备层的温度、掉卡告警应该发给机房和硬件负责人平台层的调度卡死、节点NotReady应该发给SRE作业层的Loss异常和训练中断应该发给算法团队。如果三层指标混在一个告警通道里算法同学会被硬件的例行维护刷屏硬件同学又不得不处理一堆作业OOM最后谁都不看告警。我见过不少平台只接节点存活和CPU负载监控GPU利用率和网络状态全在盲区。结果是训练任务挂了半小时最先发现的不是监控系统而是算法同学在群里所有人。这种情况不需要更多告警项而是先按三层把指标补齐再谈告警压缩和路由。2.2 用DCGM和Prometheus采GPU指标最小部署与关键阈值设备层的采集最通用的方案是NVIDIA的DCGM配合Prometheus生态。DCGM暴露的指标比nvidia-smi更细包括SM利用率、显存带宽、温度、功耗、Xid错误和NVLink状态。部署上不用自己写采集器直接跑一个dcgm-exporter容器把Metrics端口暴露给Prometheus# 在每一台GPU节点上启动dcgm-exporter再把9400端口加到Prometheus抓取配置里 docker run -d --name dcgm-exporter \ --restartalways \ --gpus all \ -p 9400:9400 \ nvcr.io/nvidia/dcgm-exporter:标签这里有个容易忽略的点exporter必须挂载GPU设备才能读到卡数据所以--gpus all不能省。端口可以改成别的但Prometheus抓取配置要同步改。镜像标签建议按你实际拉取到的版本来定不同版本导出的指标名略有差异尤其NVLink相关的字段最好起容器后先curl一下/metrics确认指标名再写告警规则。Prometheus侧的抓取配置长这样global: scrape_interval: 15s scrape_configs: - job_name: dcgm static_configs: - targets: - gpu-node01:9400 - gpu-node02:9400scrape_interval用15秒还是30秒取决于你的告警阈值。GPU掉卡这类故障15秒和30秒的发现时间差距不大但频率太高会给Prometheus和节点增加额外负载。我一般对设备层用15秒作业层用30秒。DCGM指标非常多以下字段建议最先加到告警规则里指标含义建议策略DCGM_FI_DEV_GPU_UTILSM利用率反映计算单元真实忙碌程度单卡连续5分钟低于10%且作业在运行大概率慢节点DCGM_FI_DEV_MEMORY_USED显存占用超过90%时要关注是否碎片化或超卖DCGM_FI_DEV_XID_ERRORSGPU运行时报错计数大于0立即告警这是掉卡和训练中断的前兆DCGM_FI_DEV_GPU_TEMP核心温度持续超过85摄氏度要降频排查NVLink带宽及重传计数卡间通信健康度远低于基线时多机训练性能会急剧下降2.3 作业维度数据怎么组织从sacct到生命周期事件设备层指标只能说明“卡有没有问题”没法回答“作业为什么失败”。作业维度的数据要从调度器里拿。以Slurm集群为例最常见的做法是用sacct拉作业的历史记账信息再定时同步到监控平台sacct -j 123456 \ --formatJobID,JobName,State,ExitCode,Elapsed,AllocTRES,ReqMem,MaxRSS,Start,End \ --unitsG这里重点看几个字段State区分作业是RUNNING、COMPLETED还是FAILEDExitCode区分作业自身逻辑失败和被动终止AllocTRES里能看到实际分配了几张卡MaxRSS用来判断是不是申请内存不够被打死。如果一台节点上频繁出现某个作业CANCELLED去查是不是被抢占而不是去查代码。作业生命周期里最值得盯的是四个事件排队、分配、启动、运行中失败。排队时间超过一小时而集群有空闲卡说明调度策略有问题启动阶段失败通常是镜像或环境问题运行中失败则要回到设备层的Xid和网络指标查原因。把这三类失败率按周统计运维运营的核心数据模型就基本成型了。Kubernetes集群可以走类似路径用调度器和Node事件做作业维度监控但字段含义不同。不管底层是Slurm还是K8s原则是一样的设备层解决“坏没坏”平台层解决“分没分”作业层解决“跑没跑”三层数据打通才算完整的监控体系。3. 资源调度与利用率优化把GPU从三成用到七成监控体系上线之后最容易暴露的问题就是利用率低。很多平台看完监控数据的第一反应是“加配额、加队列”但在调任何参数之前得先把“利用率”这三个字定义清楚。指标口径不一致优化做得再多汇报的时候也说不清到底有没有效果。3.1 先把“利用率”算清楚四种口径与对不上的原因同一个集群用不同算法算出来的利用率能差二十个百分点。常见的口径有四种口径计算方式谁在用单卡SM利用率GPU上计算单元的实际忙碌时间占比算法同学判断单次训练性能节点利用率节点内所有卡再按时间加权平均硬件负责人看机房效率集群配额利用率已分配GPU卡时数除以总GPU卡时数平台管理看资源占用有效算力产出扣除排队、故障、等待IO后的时间占比运营决策看真实产出日常争论大多来自口径混用算法同学说“GPU利用率80%”指的是单卡SM利用率平台说“集群利用率35%”指的是配额利用率。两者都对但不是同一个数。所以做调度优化的第一步是跟所有相关方确认一个统一口径我一般对外只讲“配额利用率”对内看“有效算力产出”。有效算力产出才是最扎心的指标。排队空转、节点故障、Checkpoint写入卡顿、跨机通信瓶颈都会让配额利用率很好看但有效算力产出很低。后面所有调度参数的调整都应该以提升有效算力产出为目标而不是单纯把卡填满。3.2 队列划分与优先级Slurm的fairshare参数怎么调利用率低的一个常见原因是队列策略没设计好。开发测试作业和8卡长训练作业混在同一个队列里小作业频繁插队大作业被反复抢占谁都没跑痛快。常见做法是按业务类型拆成训练、推理、开发测试三个队列队列间隔离队列内再按公平树分配优先级。Slurm环境里我一般会在slurm.conf里把多因子优先级和抢占逻辑打开PriorityTypepriority/multifactor PriorityWeightFairshare100000 PriorityWeightAge1000 PriorityWeightQOS10000 PreemptModeREQUEUE PreemptTypepreempt/qosPriorityWeightFairshare权重远高于年龄和QOS目的是让用户之间的公平性优先于排队时间避免某个组长期霸占集群。PreemptModeREQUEUE表示被抢占的作业重新排队而不是直接失败训练类作业可以配合Checkpoint续跑PreemptTypepreempt/qos则把抢占限制在QOS维度生产队列不会被开发队列抢。K8s生态没有完全对应的配置但思路一样用Volcano或Kueue定义队列和优先级核心是“生产不被打断、开发可被抢占”。这里不展开配置记住一条调度优化不是把所有作业都抢一遍而是要保证大作业的长训练能连续推进开发作业填碎片。3.3 三个必调参数分片、超卖、Backfill的边界提升利用率不等于把所有卡都填满有三个参数最常见但也最容易踩坑。第一是GPU分片。A100和A800上的MIG可以把一张80G的卡切成多个实例对小推理服务很友好。但训练任务不建议开MIG分片后单实例算力和显存都缩水跨实例通信拓扑也变复杂大规模训练反而更慢。我的原则是推理用分片训练用整卡。第二是超卖。控制面可以适度超卖比如虚拟GPU总数是物理卡的1.2到1.5倍让不占满显存的小作业挤进去但训练作业不要超卖训练对显存和算力都是持续占用超卖结果就是两个作业互相抢资源显存OOM或者训练速度双双下降。第三是Backfill。Slurm默认调度器不填碎片一个8卡作业在等8张空闲卡时哪怕集群有7个节点各剩1张卡这些卡也会闲着。打开Backfill调度器允许小作业填入大作业的等待窗口SchedulerTypesched/backfill这里有个边界要讲清楚Backfill只填“不影响大作业在预计时间启动”的空隙。填进去的小作业如果因为优先级更高而抢占了等待中的大作业那不是Backfill的锅是抢占策略没配好。所以Backfill和合理的队列优先级要同时上否则你会看到空闲率是降了但大作业的排队时间不降反升。调度参数调完之后至少观察一周的排队P95和有效算力产出。不要看平均值平均值会被长作业拉平P95才能反映用户侧的排队体验。4. 故障定位与可靠性保障从Xid错误到训练中断监控和调度做得再好故障依然会来。智算平台最难处理的还不是设备损坏而是“设备没坏但训练就是慢”“作业失败但日志正常”这类模糊问题。定位的功夫不在修在于能不能把三层数据快速对齐到同一个时间点。4.1 三分钟定位训练失败从sacct到dmesg到Xid训练任务一失败不要先翻训练日志先按照“调度器、系统内核、GPU硬件”的顺序各看一遍每步控制在三十秒内。第一步看调度器记录的失败状态sacct -j jobid \ --formatJobID,State,ExitCode,DerivedExitCode,Elapsed,AllocTRES,EndStateFAILED和ExitCode非零说明作业进程自己退出了StateCANCELLED且带抢占标记说明是调度器把作业赶走的StateTIMEOUT则是跑满时限被结束。三种状态的后续排查方向完全不同先分清再往下走。第二步看节点内核日志里有没有GPU相关的报错# 在作业运行的节点上执行过滤GPU驱动和NVIDIA相关的内核日志 dmesg -T | grep -i -E xid|nvrm|nvidia如果看到Xid 79之类的错误码说明GPU从总线上掉线是硬件级别的故障如果dmesg干干净净问题大概率不在GPU本身回到作业日志里去查。这里的关键是时间对齐把sacct里的作业结束时间、dmesg里的报错时间、应用日志里的最后一行时间放在同一张时间轴上谁在前谁在后一目了然。第三步用nvidia-smi -q看显存ECC状态、温度、功耗和时钟频率确认是不是硬件已经处于亚健康状态。这三步走完绝大多数训练失败都能定位到“硬件、调度、应用”三个桶之一剩下的就是对应的处理流程。4.2 RDMA慢节点排查别只看Active状态比故障更隐蔽的是“慢”作业一直没失败但训练速度比基线慢了一半。多机训练场景里这种慢八成出在RDMA网络上。浪潮和NVIDIA的智算集群普遍用IB或RoCE做高速互联但日常巡检中很多人只看网卡状态是Active就认为链路健康。InfiniBand网卡可以用ibstat看状态和速率但State: Active只能说明链路没断说明不了丢包和重传。更可靠的判断是看端口计数器# 在每台计算节点上查看IB端口错误计数 ibstat | grep -E State|Physical state|Rate如果Physical State是LinkUp但错误计数持续增长链路已经在大量重传训练通信效率会断崖式下降。RoCE网络则通过ethtool -S看丢包和重传计数器但不同厂商的网卡字段名不统一最好是在节点上做一个标准化巡检脚本统一采集和输出。比单点状态更重要的是一套基线数据。我习惯在集群空载时用NCCL的AllReduce测试跑一遍各节点的通信带宽把结果存成基线之后每次训练变慢把实时通信耗时和基线对比偏差超过30%就说明网络链路需要排查。这样“慢节点”就不再靠算法同学凭感觉投诉而是变成监控平台上的量化指标。4.3 断点续训与自动重启哪些故障救了也白救大模型训练必须做断点续训这件事在智算平台运维里没有讨价还价的余地。Checkpoint是训练任务的后悔药出现硬件故障、作业被抢占、节点重启时能不能快速续跑直接决定有效算力产出。我一般建议训练作业每15到30分钟保存一次Checkpoint写到并行存储而不是本地盘避免节点故障时Checkpoint也一起丢。调度器层面可以配合自动重启机制Slurm作业脚本里加--requeueK8s里配RestartPolicyOnFailure。但自动重启不是万能的要区分故障类型。硬件掉卡、网络闪断这类瞬时故障重启后大概率能恢复但OOM和显存溢出这类问题重启多少次都会立刻再失败盲目的自动重启只会让节点反复被打挂。对于硬件类故障重启前要把故障节点先排空也就是把该节点上的作业迁移走再处理硬件。否则这边重启恢复那边作业又被Xid打挂白忙一场。关键经验是自动重启必须搭配“失败原因分类”只有标记为可重试的故障才走自动重启其余一律进人工排查。5. 智算平台运维运营避坑指南五个常见问题与排查路径监控、调度、定位三条线都铺开后日常运维真正花时间的其实是一些反复出现的坑。下面五个问题是从实际经验里沉淀出来的每条按“现象、原因、解决”展开全部是配置或流程层面的问题改完立刻能看到效果。5.1 显存里藏着“看不见的债”作业没了显存还在现象新作业启动时报CUDA out of memory但节点上的GPU显存占用看着并不高监控图里也没有明显的作业在跑。原因作业进程被强杀后CUDA上下文没有完全释放残留进程占着显存不还。多见于kill -9、宿主机OOM、以及容器异常退出。调度器如果没做好进程跟踪残留进程就变成“幽灵”只有靠近看nvidia-smi才能看到它们。解决先把节点上所有GPU相关进程找出来清掉# 查看占用GPU的进程PID一列对应的就是残留进程 fuser -v /dev/nvidia* # 确认是残留后按PID清理 kill -9 pid根治方式是把Slurm的进程跟踪改成cgroup模式容器场景要确保Device Plugin正确回收设备。我一般会在节点巡检脚本里加一步对比调度器记录的作业列表和nvidia-smi里的实际进程发现对不上的就告警。5.2 超卖一时爽请求变慢火葬场现象推理服务为了省卡做了显存超卖一个GPU上跑了两个容器。平时没问题高并发一来两个服务的请求同时打满SM单请求延迟从10ms变成2秒同节点的训练作业也被拖慢。原因超卖只对“共同使用但不抢资源”的场景有效。训练和推理混部时训练持续占满显存和算力推理高峰一来两个负载互相抢双双血亏。解决训练作业一律不允许超卖推理超卖比例控制在物理资源能兜底的范围里并且要监控SM利用率而非显存占用。显存占用高不代表算力被占满反过来也成立。如果超卖无法避免用GPU分片加QOS限流而不是让两个作业裸奔式共享。5.3 Gang调度卡死小作业互相等待资源空转现象K8s集群上配置了Gang调度一个作业的所有Pod必须全部就绪才能启动结果一个大作业的Pod因为资源不够一直等其他小作业也占着位置不释放集群整体利用率掉到很低。原因Gang调度追求“要么全跑要么全等”但对Pod数很多的作业在碎片化环境下很难凑齐完整的一组等待时间一长集群被无效占用。解决把严格Gang改成部分宽松模式minMember设置成实际能启动的最小数量而不是全部Pod数。同时打开抢占策略让等待中的大作业可以回收低优先级作业的资源。智算平台里真正需要严格Gang的是多机多卡训练单机推理和开发任务完全没必要套用。5.4 升级驱动后节点集体掉卡固件版本没对上现象升级NVIDIA驱动或重启节点后一批机器的GPU全部报Xid 79掉卡机器能启动但nvidia-smi里看不到卡或者反复“fallen off the bus”。原因最常见的是驱动版本和GPU固件、IB网卡固件之间的兼容矩阵没核对。升级前不查兼容性显存ECC或UEFI设置稍有变动老固件在新型号驱动下就会出问题。解决升级前先把每台节点的GPU型号、驱动版本、固件版本导出来备份升级后跑一轮完整巡检包括nvidia-smi -q、Xid错误计数、IB端口状态和NCCL通信测试。不要一次性升级整个集群先改一台机器灰度验证再滚动升级。掉卡节点如果重置后仍不稳定优先考虑更换物理卡不要在故障卡上反复重启浪费时间。5.5 “GPU利用率”很高但训练很慢盯错指标了现象监控面板上GPU利用率显示90%算法同学却反馈训练速度比之前慢了一半。两边都觉得对方数据有问题。原因面板上的“GPU利用率”大概率是一个相对粗的统计只反映GPU在某个时间片内有没有活动而不代表SM真正在做有效计算。通信等待、显存带宽瓶颈、核间同步都会让卡“在忙但不是忙在计算上”。反过来训练脚本里频繁同步也会让SM利用率看起来不高。解决判断训练性能要看一组指标而不是单看利用率。SM利用率、显存时钟、NVLink带宽、训练日志里的吞吐值放同一张图哪个指标先掉下去瓶颈就在哪个环节。只盯一个数字的监控面板迟早会误诊。6. 把运维运营数据变成决策依据三个长期指标与碎片率计算上一章说的都是怎么排障这一章讲的是另一个方向运维数据怎么变成运营决策的依据。监控面板堆得再多不如提炼出几个能长期跟踪的指标每周看一次趋势让平台负责人能拍板“该扩容了”“该调队列了”“该换设备了”。第一个指标是有效算力产出即扣除排队、故障、等待IO之后真正跑训练的时间占比。这个指标决定要不要扩容如果配额利用率已经很高但有效算力产出上升缓慢说明瓶颈在调度和故障而非算力总量不够。第二个指标是MTTR平均故障恢复时间。每次从告警触发到业务恢复的时间都记录下来按月统计。MTTR连续上升要么是故障变多了要么是排查流程退化了数据会逼着你去优化巡检脚本和备件策略。第三个指标是资源碎片率也是最容易被忽略的。定义可以简化成当前空闲GPU卡里无法被任何作业需求整除的卡数占比。用一个简单的计算函数来跟踪def fragment_ratio(free_chunks, job_demands): # free_chunks: 每个空闲节点/空闲区域的卡数列表 # job_demands: 作业申请卡数集合例如 {1, 2, 4, 8} total_free 0 unusable_free 0 for chunk in free_chunks: total_free chunk if not any(chunk d for d in job_demands): unusable_free chunk return unusable_free / total_free if total_free else 0函数逻辑很简单每个空闲区域的卡数如果能被任意一种作业需求覆盖就算可用否则算碎片。这个指标的用途是评估是否需要调整队列的最小申请粒度是否开启Backfill以及是否要把碎片卡组成开发测试队列。如果一个集群长期只有8卡作业在跑而空闲资源都是每节点2到4张卡碎片率会居高不下此时做两个2卡队列给开发用比继续等大作业更划算。我早年做调度优化时只盯着集群峰值利用率结果峰值很好看用户侧的排队体验还是很差。后来改成每周看尾部数据排队P95、碎片率、MTTR任何一项连续一周恶化就主动去查而不是等事故来找我。运维运营不是把Grafana面板做得更花哨而是让自己每个月能回答三个问题算力用在哪、故障花多久、碎片丢多少。希望帮到你。本文还有配套的精品资源点击获取