AI基础设施复盘：从GPU资源到故障排查的实战指南

在正式开始写这个系列之前我想先说清楚为什么第一篇的标题叫“【infra 复盘】0”。这个“0”有两层意思一是第零篇、系列开篇先把思路理清二是回到原点把基础设施的底层逻辑重新捋一遍。最近圈子里高频出现ai infra、agent infra这些词做平台和SRE的朋友应该都有同感——infra在AI时代已经不是“服务器和网络”那么简单了它变成了算力调度、数据管道、模型生命周期、Agent运行时的综合体。这篇复盘我想聊的就是这种新形态infra在真实业务场景里怎么落地、怎么踩坑、怎么排障。适合正在搭AI平台、做GPU集群管理、或者被训练任务稳定性折磨的同学参考。做一个infra复盘最难的不是写报告而是不知道从哪里下手。因为基础设施的问题往往是慢性的、系统性的不像业务bug那样有清晰触发条件。本文我用自己的真实经历为蓝本把复盘思路、故障定位过程、后续整理动作都展开讲一遍尽量让这套方法论可以直接迁移到你的工作里。1. 这次复盘我要复盘什么1.1 为什么从第0篇开始先说个背景。我最近半年主要精力都扑在一套AI训练和推理基础设施上从GPU资源池、任务编排、数据缓存到上线后的可观测性建设差不多把能踩的坑都踩了一遍。这个系列我打算陆续整理成文字既是对自己工作的阶段性梳理也希望给同行一些可对照的参考。第0篇不写具体某次事故而是先把复盘的框架定下来。做infra复盘最怕一件事看见什么写什么。比如集群某天CPU飙到90%你查了一通发现是某个离线任务在跑大批量数据清洗然后你把它挪到低峰期完事了。这类“头痛医头”的复盘没有太多价值因为问题大概率还会以别的形态回来。真正的infra复盘必须从“系统整体设计是否合理”这个层面去审视而不是停留在单点事件上。我把infra复盘拆成四个层面资源层、编排层、应用层、组织层。资源层看的是GPU、CPU、内存、存储够不够用、用得好不好编排层看的是调度策略、队列优先级、弹性伸缩是不是合理应用层看的是训练推理任务本身的稳定性、性能瓶颈在哪组织层看的是知识沉淀、告警响应、协作机制有没有形成闭环。这四个层面是层层递进的单看任何一层都会得出片面结论。1.2 复盘的核心维度从现象到机制我给自己定了一条原则复盘必须穿过现象找到机制。所谓机制就是“为什么会出现这个现象”的系统性原因。举一个常见例子训练任务频繁OOM。表层原因是模型显存占用超出单卡容量但往下挖你会发现可能是节点资源碎片化导致任务被调度到显存较小的卡上再往深挖可能是调度器没有感知拓扑约束没有把同类任务聚集到同一台物理机。所以我整理了一个“现象-机制-根因”三层分析表每次复盘先填现象再分析机制最后定位根因。这个过程很花时间尤其当多个故障交织在一起时但它是排查问题唯一可靠的路径。如果只停留在第一层你的告警和预案做得再多也只是在给表象打补丁。还要补充一个容易被忽略的维度数据。在AI infra里数据不同于传统业务的日志和数据库它还有数据集版本、标注质量、数据管道延迟这些特殊指标。数据管道出问题往往不以“故障”形式出现而是表现为模型效果变差、训练loss曲线异常这比服务宕机更难发现。复盘时如果只看资源指标很可能会漏掉这一环。2. 先把基础设施的“家底”盘清楚2.1 算力资源的四本账做infra复盘第一步一定是盘清楚自己手里有什么。我把这步叫“算力四本账”存量账、增量账、容量账、利用率账。很多团队连这四本账都没算明白就急着上Kubernetes、搞GPU池化最后往往事倍功半。存量账指的是当前有多少台机器、多少张卡、什么型号、分布在哪些机房、有没有故障机和闲置机。这一步看似简单实际执行时很容易混乱因为资产信息分散在不同系统里财务一套、运维一套、算法自己又记一套。增量账指的是未来三个月到半年会到货多少资源、什么时候到、有没有被其他团队预订。容量账是指按照当前业务增速资源什么时候会打满、哪个池子会先饱和。利用率账是最核心的要算清每张卡的实际使用率而不是只看分配率。我见过不少团队账面上GPU分配率接近100%但实际利用率只有三四成。原因很简单很多训练任务是串行申请的一个任务跑完之前它占用的资源就空在那边或者模型推理服务按照流量峰值预留了资源但大部分时间流量根本到不了峰值。这类浪费在资源紧张的时候会直接引发“假性资源不足”导致新的任务排不进去但老任务又在空转。2.2 集群环境的隐性成本资源碎片与拓扑约束资源碎片化是Kubernetes环境下最阴险的问题之一。GPU显存型号不统一比如一部分节点是A100 80G一部分是A100 40G还有少量消费级卡。调度器默认按“可调度数量”来匹配结果一个需要单卡40G显存的任务拒不拒绝它不会拒绝而是直接调度到80G的卡上把大卡占了小卡那边又被另一个任务占着。时间一长集群里会出现大量“明明有卡但哪张都不合适”的碎片状态。拓扑约束更是个隐形坑。多机多卡训练对GPU之间的通信带宽极其敏感如果调度器没有把同一任务的8张卡分配到同一台物理机或者同一个NVLink域跨机通信的延迟会拖慢整体训练速度。我实测过一个数据并行训练任务如果8张卡分布在8台不同机器上训练吞吐能掉30%到50%。这种性能损失特别隐蔽因为任务本身是正常的没有任何报错只有看训练速度曲线才能发现问题。我建议在复盘时专门做一次“资源分布体检”把集群里每台节点的卡型号、显存、当前占用、网络拓扑全部拉出来画一张资源地图。这张地图能帮你快速定位碎片化热点也能为后续的调度策略配置提供依据。具体做法是用kubectl和节点标签信息写一个巡检脚本把节点信息定期采集到监控系统里而不是每次需要时才手动去查。2.3 数据与存储的常见盲区数据层的盘点经常被infra团队忽略但它对AI业务的影响不亚于算力。我遇到过的典型问题包括数据集分散在不同机器上、版本管理混乱、模型训练到一半发现数据读取瓶颈。数据读取瓶颈的表现是GPU利用率周期性掉坑很多人会误以为是代码问题或者框架问题查半天才发现是存储IO跟不上、数据加载卡住了训练流水线。存储这块要区分热数据和冷数据。频繁访问的训练数据集应该放在高性能存储上最好是本地NVMe或者高速并行文件系统不常用的历史数据可以放到低成本冷存储。如果没做这个区分热数据可能在老旧的机械硬盘上跑拖慢整个训练冷数据却占着昂贵的闪存存储浪费成本。我遇到过最夸张的情况是一个团队把三年的历史数据全部堆在高速存储上存储成本占了整个基础设施预算的四成。数据版本管理也是个大坑。算法同学经常手动拷贝数据集副本用“dataset_final_v2_new”这类命名方式时间一长根本分不清哪个是当前训练真正在用的版本。这个问题不解决就算infra做得再好模型产出也无法稳定复现。复盘时一定要检查数据版本管理机制是否到位至少要做到数据集元数据登记、变更记录可追溯、训练任务显式声明使用的数据版本。3. 一次真实故障的全部复盘过程3.1 现象与第一反应别急着重启说一个我最近经历的比较典型的故障。某天上午算法团队反馈说一个重要的模型训练任务频繁中断每次运行两三个小时就报错看日志是某个节点的GPU显存OOM。最开始同组的人第一反应是“手动重启任务试试”我拦住了。在infra场景里“先重启再说”是最常见的错误动作它会让你失去第一手现场信息。我让值班同学先做了三件事保留现场信息把出问题的节点和Pod日志全部留存记录任务失败的时间规律是固定时间点还是与训练进度有关查看监控面板确认故障前后集群整体状态有没有变化。这三件事做完之后我们才发现这个任务不是“偶尔OOM”而是每次跑到第三个训练step时就会挂掉而且出问题的节点集中在某一批旧机器上。这个发现直接缩小了排查范围大概率是这批机器的问题而不是模型代码的问题。如果一上来就重启任务运气好可能跑两个小时再挂问题依旧存在现场证据却被覆盖了。所谓故障复盘第一步不是“修”而是“保”——保护现场、保留证据。3.2 排查链条从监控告警到根因定位我当时梳理了排查链条按“监控指标-节点状态-调度事件-代码堆栈”四层递进。第一层先看监控指标。出问题的节点在OOM之前显存利用率曲线是阶梯式上升的每跑完一个训练批次就涨一截涨到接近单卡上限时突然归零这是典型的显存泄漏信号。但问题是代码是算法团队自己的他们之前跑过同样的模型没有OOM为什么这次会泄漏第二层看节点状态。这批机器是半年前采购的型号较老驱动版本也偏低。我怀疑是不是驱动和CUDA版本的兼容性问题导致显存释放不干净。我查了这批节点上的驱动版本又对比了新批次机器的版本发现确实差了三个小版本。这个发现让排查方向进一步收窄。第三层看调度事件。从Kubernetes事件流里我看到这个任务在OOM前被kubelet执行过一次驱逐eviction原因是节点内存压力过大。也就是说问题不只是显存OOM还伴随着宿主机的内存争抢。一个训练Pod既用了大量显存又吃掉了不少宿主机内存把系统内存逼到警戒线触发了驱逐机制。第四层看代码堆栈。我请算法同学把训练代码里的数据加载部分重新过了一遍最终定位到一个数据加载器没有正确关闭文件句柄导致每个step都累积一部分内存和显存碎片。这个问题在旧驱动上暴露得尤其明显新驱动的显存回收机制更好掩盖了这个缺陷。到这里根因才算真正浮出水面。3.3 修复与验证临时方案与长期治理定位根因之后修复分两条线并行。临时方案是对训练代码打补丁修复文件句柄泄漏同时把该训练任务优先调度到新版本驱动的节点上保证训练先恢复。长期方案则是把这批旧节点的驱动统一升级并且在镜像构建阶段加入显存监控探针当进程的显存占用超过阈值时提前告警。这里我想强调一个观点修复不是终点验证才是。很多团队把代码补丁合入就跑路了没有做回归验证也没有观察一段时间确认问题不再复发。我要求算法团队在修复后连续跑满48小时期间记录显存曲线和吞吐指标确认曲线平稳且无阶梯式上升。同时我在监控系统里加了一条自定义告警单进程显存占用超过卡容量的95%持续5分钟就触发通知。这个告警后来真的救过一次某天凌晨一个新的实验脚本也出现了类似泄漏告警把我从睡梦中叫起来避免了第二天早上的大规模失败。这个案例给我们的最大教训是显存泄漏这类问题往往不是单一原因造成的。代码、驱动、调度、资源争抢多因素叠加才最终导致故障。复盘时不能只看最显眼的那个错误必须把整条链路摸一遍。4. 复盘之后要落地的事4.1 监控补课与告警治理复盘这个案例之后我做的第一件事是补齐监控盲区。复盘之前我们的监控体系主要看节点层面的CPU、内存和GPU利用率对单进程级别的显存占用、内存增长趋势、文件句柄数量这些指标基本没有覆盖。没有这些指标很多慢性的资源泄漏问题根本无从发现只会等到它们演变成硬故障才暴露。我把指标分成了三级一级是“服务存活”类比如训练任务是否还在跑、是否在预期时间内产出checkpoint二级是“资源容量”类比如节点GPU显存余量、内存余量、磁盘IO延迟三级是“应用健康”类比如loss曲线是否有异常波动、是否出现连续NaN、模型吞吐是否下降。每一级指标都配置对应的告警策略级别越高的指标告警阈值越保守、响应等级越高。告警治理里有个容易被忽视的动作告警必须分级不能一视同仁。一开始我们图省事把所有异常统统发到同一个钉钉群结果一晚上告警几百条值班同学直接把这个群消息屏蔽了。后来我按P0到P3分四级P0是训练集群大规模不可用必须电话通知P1是训练任务中断需要30分钟内响应P2是单项指标异常但业务未受损白天处理即可P3是消息性通知比如任务自动恢复仅仅记录。分级之后告警的有效性提升了很多值班同学也不用时刻提心吊胆。4.2 容量规划与成本核算复盘结束后我还做了一次容量规划推演。推演的输入很简单未来三个月的训练任务量预估、推理服务流量预估、每类任务的平均资源占用和运行时长。输出是一张“资源水位预测表”按周显示各类资源的使用预测和实际对比。这个表的精度一开始并不高需要根据两周以上的实际数据不断调整但它的意义在于让扩容决策从“拍脑袋”变成了“有依据”。成本核算是容量规划的延伸。AI基础设施的成本大头是GPU和存储这两块如果失控整个团队的预算都会被吃掉。我引入了两个关键指标单位训练成本每训练一个checkpoint的算力费用和资源闲置率已分配但实际未使用的资源比例。单位训练成本可以横向对比不同团队、不同项目的资源使用效率资源闲置率则直接指向可以优化的空间。优化闲置率的手段有很多最直接的两个是合理配置弹性伸缩触发条件让推理服务在低峰期自动缩容建立任务优先级和抢占机制让空闲的高优资源池可以被低优的离线任务临时借用。这些手段不是技术难题但需要和算法团队、业务团队反复协商因为涉及到资源“优先权”的分配问题。实操中我的建议是从最容易出成效的小池子开始试点跑两周对比数据用数据说服大家而不是硬推。4.3 复盘文档怎么写才不白写很多团队也做复盘但做完之后文档躺在Wiki里吃灰下一次遇到类似问题还是从头查起。问题出在复盘文档写成了“流水账”没有形成可复用的知识资产。我写复盘文档有一个固定模板故障概述、时间线、排查过程、根因分析、修复动作、后续改进、checklist检查项。核心是最后两个部分——后续改进里必须列出具体的、有负责人的、有截止时间的行动项checklist则把本次踩坑总结成几条固化的检查规则。举个例子这个OOM案例的checklist里有一条“训练任务上线前必须确认数据加载器的文件句柄正确关闭并在镜像中启用显存监控探针”。这条checklist会进入团队的上线评审模板后续所有新模型上线都要过一遍。这样写复盘下一次即便遇到不同的故障checklist里的经验也能被复用。复盘文档的另一个作用是新人培训材料。我带过不少刚入行的平台工程师他们看教科书式的架构文档往往一头雾水但一份真实的、带排查过程细节的复盘文档能让他们快速理解系统的脆弱点和边界。所以我建议做infra的同学养成一个习惯每次故障处理完趁热打铁当天写复盘时间拖久了细节就丢了写出来的东西也失去了现场感。5. 几个反复踩坑后的心里话5.1 不要把临时方案当长期方案我在这个项目里最痛的领悟之一是临时方案的生命力比想象中顽强。驱动不升级先加个调度偏好代码先跑通再修这类临时方案一旦上线大概率会变成一个没人负责的“历史遗留设计”。每次出问题都会有人说“当初不是先这样顶着嘛”然后就继续顶着。做infra需要有一种“洁癖”临时方案必须带过期时间在文档和系统里明确标注到期不清理就自动触发告警提醒。这个机制我很推荐把临时方案记录成技术债条目每个条目带上负责人和过期时间。到期后由负责人决定是转正为正式方案还是安排专门时间去清理。我见过太多团队的技术债就是“大家都知道的烂摊子”但从来没有被排上日程原因就是没有显式的记录和到期机制。5.2 数据比感觉可靠每次做资源容量分析都会有人凭“感觉”下结论“我觉得这个集群挺空闲的”、“我感觉最近存储很慢”。感觉这东西在基础设施场景里是最大的敌人。我在这半年里养成了一个习惯不管讨论什么问题先看数据面板先把监控拉出来先看趋势图。没有数据支撑的讨论最后都会变成情绪博弈谁声大听谁的这非常不infra。具体到复盘场景我要求所有参与复盘的同学只能引用监控数据、日志证据、代码提交记录这类客观材料禁止使用“我记得”“好像”“应该”这类模糊表述。这个规则一开始执行起来阻力很大因为大家都不习惯翻数据但坚持两三次之后就形成了肌肉记忆讨论效率反而高了。5.3 基础设施也是产品最后一个想说的是“基础设施也是产品”这个概念。平台团队容易把自己定位成“后勤部门”算法的同学提需求我们就实现机器出了问题我们就修。这个定位会让infra团队永远处于被动救火的状态。更好的方式是主动把基础设施当做一个产品来运营定义SLA、规划版本迭代、输出使用文档、沉淀最佳实践。我最近在推动的一个小项目是把集群使用指南和故障自查手册做成一个内部站点算法同学遇到问题可以先自查解决不了的再走工单。运行一个月后工单量下降了20%左右算法同学的处理效率也上来了。这个结果说明用户不是不愿意自助而是缺少一个顺手的有质量的自助工具。把基础设施做得更好用其实是在降低整个组织协同的成本。如前面所说这类复盘我会陆续整理成一个系列。下一篇计划写一写GPU集群调度策略的具体踩坑包括抢占、排队、优先级这些细节。写之前我会先把数据跑一遍确保每个结论都有实际环境支撑。