1. 为什么会一头扎进AI-Infra这个方向1.1 一次让我印象深刻的线上事故两年前我们赶着上一版大模型推理服务模型加载完后首token延迟一直不达标A100显存看着还有40多GB空余但并发一上来就开始报CUDA OOM。那天晚上我和算法同事在Grafana前面蹲到凌晨两点最后定位到的问题既不在模型本身也不在业务代码逻辑而是藏在推理框架的显存分配策略里。从那一天起我彻底理解了AI-Infra这句话的分量。它不是HR挂在岗位描述上的一个高级词也不是RSVP嘴里那种AI时代底座式的宏大叙事而是算法落地过程中所有看不见的工程的总和GPU资源怎么调度、模型怎么加载、推理请求怎么排队、数据怎么流动、故障怎么恢复。任何一个环节掉链子算法团队的精度再高也没有意义。这个系列第一篇我先把AI-Infra的全貌、我自己实际经手过的系统以及最典型的几类事故讲清楚。后面章节再逐个深入训练调度、推理优化、数据管道和可观测性。如果你正在从业务后端转AI方向或者已经在AI公司做基础设施但总感觉自己在打杂、做的事情不成体系这篇应该能帮你把脑子里那团乱麻理出个框架。1.2 AI-Infra到底是干什么的说通俗点就是让算法工程师能安心炼丹、让模型服务能稳定赚钱的那层地基。你训练一个千亿参数模型不可能靠单机八卡跑完那GPU资源谁来按需分配训练中途有节点宕机了谁来拉起新的节点续跑模型上线后遇到流量洪峰哪个模块自动扩容这些都不是算法工程师该操心的事但必须有人操心——这就是AI-Infra。很多人问我这和传统后端基础设施有什么区别。我的体会是传统互联网的SRE关注CPU、内存、网络、磁盘单位是毫秒和QPSAI-Infra多了一样最贵也最娇气的资源——GPU。显存碎片、NVLINK拓扑、CUDA版本兼容、驱动与容器运行时匹配、Infiniband拥塞控制这些在传统后端里完全没有对应物。你调试一个容器明明没问题在GPU机器上就是起不来多半是驱动和CUDA的排列组合出了幺蛾子。所以AI-Infra工程师本质上是在做一层新的操作系统只不过这层系统的进程是训练任务和推理服务资源是GPU、HBM和互联带宽。谁把这层系统做得越透明、越稳算法团队就越能在上面专注地做自己的事。2. 一线工程师眼里的AI-Infra全景地图2.1 六大能力模块与常见组件我习惯把AI-Infra拆成六个模块分别对应模型生命周期里的不同阶段。每个模块的干法、组件和典型指标都完全不同混在一起谈会被绕晕。能力模块核心职责常见组件/方案最让工程师头疼的点资源与调度GPU资源池化、队列、配额、抢占Kubernetes、Kueue、Volcano、Slurm带宽大户任务互相抢网卡饿死小任务训练支撑分布式训练、断点续训、超参管理Ray、Horovod、Megatron-LM、Checkpoint调度大模型checkpoint动不动几个TB保存恢复极慢推理服务模型加载、并发调度、灰度、弹性Triton、vLLM、TensorRT-LLM、KServe显存碎片和动态组批一上并发就炸数据管道样本采集、清洗、特征、流批一体Kafka、Spark、Flink、Airflow数据版本和模型版本对应关系混乱可观测性指标、日志、链路、GPU监控Prometheus、Grafana、Loki、OpenTelemetry只有业务指标没有GPU内部指标出了问题盲猜平台与工具链实验管理、模型仓库、CI/CDMLflow、Hugging Face Hub、GitLab CI环境复现难测试和生产环境镜像不一致这张表我建议你贴在工位上。不是因为它全而是因为它能帮你判断一个问题该归到哪个模块去解决。比如模型上线后延迟高你第一反应不应该是改模型结构而是先看推理服务模块有没有开动态批处理、显存有没有碎片化又比如训练任务排队排到天荒地老问题大概率在资源调度模块而不是你分母上少了个什么参数。2.2 模块之间是怎么咬合在一起的这六个模块不是孤立的。数据管道产出的训练集交给训练支撑模块去跑训练产出checkpoint后送到模型仓库推理服务从仓库拉取版本并加载到GPU显存里资源调度在背后保证所有环节都有可用的卡。任何一个环节的延迟都会逐级放大。我在公司里经常画一张数据流加资源流的双层图数据从Kafka流进Spark做特征训练任务通过Kueue从K8s集群申请到8张A100训练过程实时把指标写到Prometheus推理服务从S3兼容的对象存储里拉模型权重。这张图画完之后团队里再争论谁的问题时基本就不吵了因为问题就出现在两个模块交界的地方而交界处恰恰是最容易被忽略的盲区。我最想强调的一点是资源调度不是K8s的专利。很多团队训练用K8s但离线特征跑在Yarn上两边的配额完全隔离忙闲不互补。后来我们统一到K8s Kueue这套调度体系上GPU和CPU在同一个队列模型下管理夜间的CPU富余资源可以临时借给白天高峰期加过来的GPU训练任务做数据预处理整体利用率至少提升了20%。2.3 大多数团队真正缺的不是算法而是平台这是个让我很感慨的观察。我见过不少算法团队模型代码写得赏心悦目但每次上线都要折腾环境开发环境是Python 3.10测试环境是3.8生产环境因为某些老库依赖不得不用3.7光conda环境管理就够喝一壶。再加上CUDA版本不统一模型权重文件散落在各自的网盘里别人想复现实验根本找不到数据。这不是工程师能力问题是AI-Infra缺位问题。只要把镜像构建、依赖锁定、模型版本管理和实验追踪这几件事标准化团队产能立刻翻倍。我在公司推了一套很简单的方案所有训练和推理镜像都从统一基础镜像构建代码库锁定依赖版本模型仓库只认带唯一哈希的产物。工具不复杂复杂的是让所有人养成习惯。所以如果你所在的公司还没有专职的AI-Infra团队你可以先从一个很小的点切入比如把模型部署流程做成一条CI流水线。不必一上来就搞全套那既不现实也不可持续。AI-Infra的核心不是炫技而是让整个团队能稳定地、可重复地交付。3. 我实际经手过的三个关键系统拆解3.1 训练任务的排队与抢占问题先说训练侧的痛点。我们早期在大集群里跑训练就靠人肉协调算法同学在群里喊一声我要卡运维同学手动给他们开命名空间和配额。结果就是有人申请了32张卡只跑一个小模型有人急需16张卡做实验却排不上号资源闲置和饥饿并存。后来我们上了Kueue作为调度器把集群GPU按队列分层。默认队列给日常任务高优先级队列给紧急实验再用ClusterQueue的配额限制防止少数人占满全集群。真正让我觉得好用的是它的抢占机制低优先级任务运行超过一个小时后如果高优先级任务进队列低任务会被安全地挂起腾出来的GPU让人给紧急任务。但注意抢占机制只在任务有断点续训能力时才安全。有段时间我们某框架的checkpoint频率是每两小时一次而训练任务经常被抢占后重新排队等GPU等待期间算力白白浪费。后来我们把检查点频率调到五分钟一次配合增量保存恢复代价就降到了可控范围。这个经验是文档里不会写的调度器的粒度再好也得靠训练侧的容错能力兜底。训练任务本身的故障恢复更是家常便饭。GPU机器宕机、NCCL通信超时、显存ECC错误每个都有不同的处理策略。我的原则是不要相信任何单一节点的可靠性要把整个训练过程设计成任何节点随时可以消失的形态。数据读取做冗余、通信库设置超时重连、checkpoint做到写两份这套东西建起来之后我们的周级稳定训练时长直接翻倍。3.2 推理服务从冷启动到流量洪峰推理服务是我写代码最多的一块。我们早期上线一个BERT模型用的是TorchServe流量高峰时手动加副本低谷时半夜爬起来缩容累得够呛。后来换成了KServe vLLM的组合才算松了口气。vLLM的核心能力是PagedAttention把KV cache按页管理解决了传统显存碎片导致并发上不去的问题。部署方式很简单把模型文件挂到对象存储上KServe拉起Pod时自动加载注册到Prometheus的指标来自动扩缩容。我配置了两个关键指标一个是GPU利用率超过70%就加副本另一个是排队延迟P95超过500毫秒就扩容。配置自动伸缩时要给小副本下限留buffer但别留太多。我们有次把最小副本数设成4结果半夜没流量4张A100在那儿空转了一整周电费没多少钱但算力浪费看着心疼。用Keda这类组件按请求量降到0才是合理的。另外冷启动问题不可忽视大模型权重从对象存储拉取到显存少说一分钟起步流量突然暴涨时来不及拉副本只能靠队列缓冲硬扛。我们后来做了模型预热Pod一启动就预先加载到显存配合Keda的提前扩容策略高峰期基本不会再出现临时抱佛脚的情况。3.3 数据管道的隐性瓶颈很多AI工程师对数据的印象就是收集样本、标个注、喂给模型但真实场景里数据管道是个暗坑密集的区域。我接手过一个样本流转项目数据在Kafka里积压了十几万条训练任务直到几个小时后才发出一个数据不足的预警。排查发现问题根本不在Kafka吞吐而在消费端的下游特征计算服务用了一个老旧的Python库单条处理耗时超过200毫秒而生产速率远高于消费速率。修复方式很简单把特征计算拆成Spark批处理再配合Flink做流式写入端到端延迟降到几秒。这个案例让我意识到数据管道最常见的瓶颈不是队列本身而是整个链路上最慢的一个环节。数据版本管理同样重要。我们曾经发生过一次惨痛事故实验A用的数据集是6月10日清洗的实验B用的是6月13日清洗的中间样本分布发生了变化导致两个实验的指标对比毫无意义。从那之后我强制所有数据落地都带版本号和清洗规则哈希模型训练时记录数据集的commit_id出问题能直接定位是哪份数据导致的。这种强迫症式的版本管理在AI-Infra里非常划算。4. 从零搭推理服务踩过的坑排查链路实录4.1 一张A100利用率只有10%的排查全过程这是我最想分享的一个真实的排查经历。现象很诡异GPU利用率在Grafana上只有10%左右但请求量并不小平均推理延迟却很高。第一反应是模型太深、算子效率低但换了什么优化都无效。我没有急着改代码而是按链路逐层排查。先用nvtop看GPU实时状态发现SM占用率很低但显存带宽也没有跑满说明GPU根本还没被喂饱。接着用nsys和PyTorch Profiler给一条请求做完整追踪结果发现在CPU侧的数据预处理环节耗时占了整条链路的70%以上。每一条请求都要做分词、padding和特征转换CPU在跑这些操作时GPU只能闲着等。处理方案是典型的把CPU工作挪出关键路径用多进程DataLoader预加载和变换数据把预处理结果按batch提前塞进CPU内存队列再把队列消费和GPU推理解耦。具体操作上我加了一个有界队列消费端永远从队列拿现成的batch生产端用多个num_workers并行洗数据。改动之后GPU利用率从10%拉到了70%以上单卡吞吐提升了四倍。这个案例给我的教训是GPU显得没用的时候先别怀疑GPU而是要看GPU有没有得到足够的活。大部分利用率低的根因都不是算子效率而是数据送不到卡上。CPU如果处理不过来给你一万张A100也是摆设。4.2 显存碎片不是加卡就能解决的另一个高频坑是CUDA OOM。我们的服务部署在16G显存的卡上模型权重占8G按理说还有8G可用但并发一上来请求稍微多一点就直接OOM。起初我怀疑是请求量太大于是加了副本结果加了卡也照样OOM这就不对劲了。用torch.cuda.memory_summary()查看显存分配细节后发现空闲显存虽然多但都是零散的碎片根本分配不出一个连续的大块给新请求的KV cache。这就像停车场里有20个车位都只停着自行车却停不进一辆大巴。推理请求需要的是一整块连续显存碎片多了空间再多也没用。定位到问题之后我们做了两件事。一是把推理框架从Native的PyTorch换成了vLLM它用PagedAttention把KV cache分页管理不需要连续的大块显存碎片利用率大幅提升。二是把一些本来常驻显存但只在必要时才用的临时变量挪到了CPU侧减少显存峰值。换完之后同等硬件条件下并发量从几十涨到了几百增幅让人意外。所以遇到OOM别急着申请加卡先看看显存是不是碎了。4.3 生产环境调度器和本地调试的差异这个坑我很有发言权因为踩的不只一次。在本地用python app.py跑推理一切正常但部署到K8s后同一个镜像有时候会莫名卡住几十秒甚至第一波请求全部超时。最初我怀疑是镜像拉取慢了但查下来镜像只有几百MB不存在大文件拉取问题。后来用kubectl describe pod看到Scheduling阶段耗时很高才发现问题出在资源请求的定义上我们把训练和推理混在同一个节点池推理Pod被调度到一张还残留着训练进程的GPU上显存被占了一半推理服务起是能起来但可用的KV cache空间极小处理请求时就频繁换页性能惨烈。理清原因后我们做了两处调整给推理Pod单独设节点池加nodeSelector和显存请求声明同时给每个推理Pod加resources.limits.nvidia.com/gpu: 1和显存上限声明确保调度器在选择节点时就把显存余量考虑在内。这个改动看似简单实际规避了一整类起得来但性能崩的隐蔽故障。我的习惯是本地验证通过后一定会模拟至少一天的线上流量压测不只看能不能响应还要看GPU内部指标。真实流量下暴露的调度和显存问题本地调试几乎不可能发现。这部分经验在面试和日常运维里都非常加分。4.4 限流、优雅退出与雪崩保护推理服务上线后我们遇到过比OOM更隐蔽的问题服务雪崩。现象是流量高峰时单个实例P99延迟飙升自动扩容反复增减副本系统在振荡中崩溃。根因是请求队列无界新请求继续进队列每个实例拖到超时才退出K8s不断重启流量叠加在重启中的Pod上形成恶性循环。应对雪崩有三板斧缺一不可。第一是限流每个推理实例的业务侧和网关侧都加令牌桶超过阈值直接返回429不进入队列第二是优雅退出Pod收到SIGTERM后停止接收新请求但已有请求继续处理完成再退出避免中断正在推理的请求第三是队列有界化请求队列长度固定满了直接丢弃或走降级逻辑绝不让队列无限增长。这三板斧都落地后我们的服务经历了连续两次双十一级的流量冲刺P99延迟曲线都保持稳定。我见过太多团队只看扩容策略忽略雪崩防护等真出事再调试已经来不及了。AI-Infra的很多稳定性工作本质上都是在让失败以预期的方式发生而不是被动的碰运气式救火。5. 想转AI-Infra的新人我建议按这套路练5.1 必备工具链和知识域这个方向需要的技术栈不像算法那样深但特别宽。新人不建议一上来就去啃框架源码先把基础工具链练到位。Linux和Shell是底线awk、sed、grep、jq这些文本处理工具要随手就写。Docker和K8s至少要达到能独立排查问题的程度不要求会写全套operator但kubectl logs、describe、top、get events要熟练。GPU相关的知识必须懂NVIDIA驱动、CUDA版本、NCCL通信、nvidia-smi和nvitop的输出要能看明白。性能分析工具链里PyTorch Profiler、nsys、nsight-compute至少会一个。日志、指标、追踪这三件套要熟练配置PromQL能写基本查询就够用。这些工具不是背出来的而是要在真实故障里用出来。我建议新人找一台测试GPU机分别跑一个CPU密集型任务、一个内存密集型任务、一个GPU算子密集任务然后用工具去看它们各自的特征把什么指标对应什么瓶颈在脑子里建立映射。5.2 持续追踪的开源项目清单AI-Infra最好的学习材料是开源项目。我定期看的不多但每个都值得深挖KubeFlow和KServe看的是模型服务平台的标准形态vLLM和TensorRT-LLM看的是推理引擎如何优化显存与计算Ray看的是分布式调度与并行计算的通用框架Kueue看的是多租户GPU队列的正确姿势MosaicML和DeterminedAI看的是训练平台如何把容错做到极致Prometheus和Grafana看的是可观测性的落地方式OpenTelemetry看的是全链路追踪的标准实现。看项目的正确姿势不是刷README而是看它们的Issues和Design Docs。很多设计决策背后的权衡都在文档里写得很清楚比如为什么vLLM要用PagedAttention而不是简单的连续KV cache为什么KServe默认用Serverless而不用常驻Pod。把这些决策看懂你自己的架构判断力就长出来了。5.3 90天入门计划很多人想转这个方向但面对那么多工具不知道从哪下手。我给自己设计过一个90天计划按阶段推进比较稳。前一个月搭一套本地最小训练环境一台带GPU的机器或云上的几台GPU实例装好K8s、部署NVIDIA Device Plugin用手写一个简单的PyTorch训练脚本在K8s上跑通。这个阶段不追求复杂关键是理解容器里看到GPU是怎么回事以及为什么驱动和运行时兼容性那么重要。第二个月把推理服务真正接进去选一个开源模型用KServe或vLLM部署成在线服务配置Prometheus采集GPU指标再写一个简单的HPA规则让副本数根据GPU利用率自动伸缩。这一阶段你会碰到调度、显存、冷启动、负载均衡的一大堆真问题每个问题解决一遍比读十篇博客都强。第三个月针对你所在公司的痛点做一个专项优化。如果是训练集群利用率低就研究队列和抢占如果是推理性能差就上Profiler做算子级优化。做完这一轮你基本可以声称自己是一名入门级的AI-Infra工程师了。5.4 与算法、业务团队高效协作的沟通模型最后说几句软技能。AI-Infra工程师每天都要和算法、业务、运维三拨人打交道最常见的矛盾是算法觉得平台不好用平台觉得算法不按规范来。我摸索出的一套沟通模型很简单先定义事实再对齐预期最后给可执行方案。比如算法说训练卡死了我不会马上接你代码有问题而是先让他们提供Pod日志、GPU指标和模型代码版本我们把事实数据摆出来确认是显存不足还是代码死循环。确认之后对齐预期比如这个任务该多久完成、资源够不够最后给出一个双方都认可的执行计划。还有个技巧是每个问题都留一个文档。每次线上事故处理后我都会写一篇小的Postmortem包含时间线、根因、修复方案、预防措施。这样下一次类似问题出现直接翻文档就能少走弯路。团队从靠人记变成靠文档记整个协作效率会上一个台阶。写到这里一线工程师的AI-Infra之路的第一章就差不多收尾了。我在这个方向摸爬滚打这几年最大的感受是AI-Infra永远不会缺少脏活累活但恰恰是这些不被算法论文提到的细节决定了一个模型到底是Demo还是生产力。下一章我打算专门拆解训练侧的调度与容错那部分埋着更多有意思的问题——比如Checkpoint为什么这么难做、GPU故障怎么自动绕过。如果你也在这条路上一步步踩坑欢迎带着你遇到的故障一起来聊我们一起把这层地基铺得更稳。 
长河君 · 2026/10/25 8:21:16 · 阅读 1.2k 一线工程师的AI-Infra实战：从GPU调度到推理优化
1. 为什么会一头扎进AI-Infra这个方向1.1 一次让我印象深刻的线上事故两年前我们赶着上一版大模型推理服务模型加载完后首token延迟一直不达标A100显存看着还有40多GB空余但并发一上来就开始报CUDA OOM。那天晚上我和算法同事在Grafana前面蹲到凌晨两点最后定位到的问题既不在模型本身也不在业务代码逻辑而是藏在推理框架的显存分配策略里。从那一天起我彻底理解了AI-Infra这句话的分量。它不是HR挂在岗位描述上的一个高级词也不是RSVP嘴里那种AI时代底座式的宏大叙事而是算法落地过程中所有看不见的工程的总和GPU资源怎么调度、模型怎么加载、推理请求怎么排队、数据怎么流动、故障怎么恢复。任何一个环节掉链子算法团队的精度再高也没有意义。这个系列第一篇我先把AI-Infra的全貌、我自己实际经手过的系统以及最典型的几类事故讲清楚。后面章节再逐个深入训练调度、推理优化、数据管道和可观测性。如果你正在从业务后端转AI方向或者已经在AI公司做基础设施但总感觉自己在打杂、做的事情不成体系这篇应该能帮你把脑子里那团乱麻理出个框架。1.2 AI-Infra到底是干什么的说通俗点就是让算法工程师能安心炼丹、让模型服务能稳定赚钱的那层地基。你训练一个千亿参数模型不可能靠单机八卡跑完那GPU资源谁来按需分配训练中途有节点宕机了谁来拉起新的节点续跑模型上线后遇到流量洪峰哪个模块自动扩容这些都不是算法工程师该操心的事但必须有人操心——这就是AI-Infra。很多人问我这和传统后端基础设施有什么区别。我的体会是传统互联网的SRE关注CPU、内存、网络、磁盘单位是毫秒和QPSAI-Infra多了一样最贵也最娇气的资源——GPU。显存碎片、NVLINK拓扑、CUDA版本兼容、驱动与容器运行时匹配、Infiniband拥塞控制这些在传统后端里完全没有对应物。你调试一个容器明明没问题在GPU机器上就是起不来多半是驱动和CUDA的排列组合出了幺蛾子。所以AI-Infra工程师本质上是在做一层新的操作系统只不过这层系统的进程是训练任务和推理服务资源是GPU、HBM和互联带宽。谁把这层系统做得越透明、越稳算法团队就越能在上面专注地做自己的事。2. 一线工程师眼里的AI-Infra全景地图2.1 六大能力模块与常见组件我习惯把AI-Infra拆成六个模块分别对应模型生命周期里的不同阶段。每个模块的干法、组件和典型指标都完全不同混在一起谈会被绕晕。能力模块核心职责常见组件/方案最让工程师头疼的点资源与调度GPU资源池化、队列、配额、抢占Kubernetes、Kueue、Volcano、Slurm带宽大户任务互相抢网卡饿死小任务训练支撑分布式训练、断点续训、超参管理Ray、Horovod、Megatron-LM、Checkpoint调度大模型checkpoint动不动几个TB保存恢复极慢推理服务模型加载、并发调度、灰度、弹性Triton、vLLM、TensorRT-LLM、KServe显存碎片和动态组批一上并发就炸数据管道样本采集、清洗、特征、流批一体Kafka、Spark、Flink、Airflow数据版本和模型版本对应关系混乱可观测性指标、日志、链路、GPU监控Prometheus、Grafana、Loki、OpenTelemetry只有业务指标没有GPU内部指标出了问题盲猜平台与工具链实验管理、模型仓库、CI/CDMLflow、Hugging Face Hub、GitLab CI环境复现难测试和生产环境镜像不一致这张表我建议你贴在工位上。不是因为它全而是因为它能帮你判断一个问题该归到哪个模块去解决。比如模型上线后延迟高你第一反应不应该是改模型结构而是先看推理服务模块有没有开动态批处理、显存有没有碎片化又比如训练任务排队排到天荒地老问题大概率在资源调度模块而不是你分母上少了个什么参数。2.2 模块之间是怎么咬合在一起的这六个模块不是孤立的。数据管道产出的训练集交给训练支撑模块去跑训练产出checkpoint后送到模型仓库推理服务从仓库拉取版本并加载到GPU显存里资源调度在背后保证所有环节都有可用的卡。任何一个环节的延迟都会逐级放大。我在公司里经常画一张数据流加资源流的双层图数据从Kafka流进Spark做特征训练任务通过Kueue从K8s集群申请到8张A100训练过程实时把指标写到Prometheus推理服务从S3兼容的对象存储里拉模型权重。这张图画完之后团队里再争论谁的问题时基本就不吵了因为问题就出现在两个模块交界的地方而交界处恰恰是最容易被忽略的盲区。我最想强调的一点是资源调度不是K8s的专利。很多团队训练用K8s但离线特征跑在Yarn上两边的配额完全隔离忙闲不互补。后来我们统一到K8s Kueue这套调度体系上GPU和CPU在同一个队列模型下管理夜间的CPU富余资源可以临时借给白天高峰期加过来的GPU训练任务做数据预处理整体利用率至少提升了20%。2.3 大多数团队真正缺的不是算法而是平台这是个让我很感慨的观察。我见过不少算法团队模型代码写得赏心悦目但每次上线都要折腾环境开发环境是Python 3.10测试环境是3.8生产环境因为某些老库依赖不得不用3.7光conda环境管理就够喝一壶。再加上CUDA版本不统一模型权重文件散落在各自的网盘里别人想复现实验根本找不到数据。这不是工程师能力问题是AI-Infra缺位问题。只要把镜像构建、依赖锁定、模型版本管理和实验追踪这几件事标准化团队产能立刻翻倍。我在公司推了一套很简单的方案所有训练和推理镜像都从统一基础镜像构建代码库锁定依赖版本模型仓库只认带唯一哈希的产物。工具不复杂复杂的是让所有人养成习惯。所以如果你所在的公司还没有专职的AI-Infra团队你可以先从一个很小的点切入比如把模型部署流程做成一条CI流水线。不必一上来就搞全套那既不现实也不可持续。AI-Infra的核心不是炫技而是让整个团队能稳定地、可重复地交付。3. 我实际经手过的三个关键系统拆解3.1 训练任务的排队与抢占问题先说训练侧的痛点。我们早期在大集群里跑训练就靠人肉协调算法同学在群里喊一声我要卡运维同学手动给他们开命名空间和配额。结果就是有人申请了32张卡只跑一个小模型有人急需16张卡做实验却排不上号资源闲置和饥饿并存。后来我们上了Kueue作为调度器把集群GPU按队列分层。默认队列给日常任务高优先级队列给紧急实验再用ClusterQueue的配额限制防止少数人占满全集群。真正让我觉得好用的是它的抢占机制低优先级任务运行超过一个小时后如果高优先级任务进队列低任务会被安全地挂起腾出来的GPU让人给紧急任务。但注意抢占机制只在任务有断点续训能力时才安全。有段时间我们某框架的checkpoint频率是每两小时一次而训练任务经常被抢占后重新排队等GPU等待期间算力白白浪费。后来我们把检查点频率调到五分钟一次配合增量保存恢复代价就降到了可控范围。这个经验是文档里不会写的调度器的粒度再好也得靠训练侧的容错能力兜底。训练任务本身的故障恢复更是家常便饭。GPU机器宕机、NCCL通信超时、显存ECC错误每个都有不同的处理策略。我的原则是不要相信任何单一节点的可靠性要把整个训练过程设计成任何节点随时可以消失的形态。数据读取做冗余、通信库设置超时重连、checkpoint做到写两份这套东西建起来之后我们的周级稳定训练时长直接翻倍。3.2 推理服务从冷启动到流量洪峰推理服务是我写代码最多的一块。我们早期上线一个BERT模型用的是TorchServe流量高峰时手动加副本低谷时半夜爬起来缩容累得够呛。后来换成了KServe vLLM的组合才算松了口气。vLLM的核心能力是PagedAttention把KV cache按页管理解决了传统显存碎片导致并发上不去的问题。部署方式很简单把模型文件挂到对象存储上KServe拉起Pod时自动加载注册到Prometheus的指标来自动扩缩容。我配置了两个关键指标一个是GPU利用率超过70%就加副本另一个是排队延迟P95超过500毫秒就扩容。配置自动伸缩时要给小副本下限留buffer但别留太多。我们有次把最小副本数设成4结果半夜没流量4张A100在那儿空转了一整周电费没多少钱但算力浪费看着心疼。用Keda这类组件按请求量降到0才是合理的。另外冷启动问题不可忽视大模型权重从对象存储拉取到显存少说一分钟起步流量突然暴涨时来不及拉副本只能靠队列缓冲硬扛。我们后来做了模型预热Pod一启动就预先加载到显存配合Keda的提前扩容策略高峰期基本不会再出现临时抱佛脚的情况。3.3 数据管道的隐性瓶颈很多AI工程师对数据的印象就是收集样本、标个注、喂给模型但真实场景里数据管道是个暗坑密集的区域。我接手过一个样本流转项目数据在Kafka里积压了十几万条训练任务直到几个小时后才发出一个数据不足的预警。排查发现问题根本不在Kafka吞吐而在消费端的下游特征计算服务用了一个老旧的Python库单条处理耗时超过200毫秒而生产速率远高于消费速率。修复方式很简单把特征计算拆成Spark批处理再配合Flink做流式写入端到端延迟降到几秒。这个案例让我意识到数据管道最常见的瓶颈不是队列本身而是整个链路上最慢的一个环节。数据版本管理同样重要。我们曾经发生过一次惨痛事故实验A用的数据集是6月10日清洗的实验B用的是6月13日清洗的中间样本分布发生了变化导致两个实验的指标对比毫无意义。从那之后我强制所有数据落地都带版本号和清洗规则哈希模型训练时记录数据集的commit_id出问题能直接定位是哪份数据导致的。这种强迫症式的版本管理在AI-Infra里非常划算。4. 从零搭推理服务踩过的坑排查链路实录4.1 一张A100利用率只有10%的排查全过程这是我最想分享的一个真实的排查经历。现象很诡异GPU利用率在Grafana上只有10%左右但请求量并不小平均推理延迟却很高。第一反应是模型太深、算子效率低但换了什么优化都无效。我没有急着改代码而是按链路逐层排查。先用nvtop看GPU实时状态发现SM占用率很低但显存带宽也没有跑满说明GPU根本还没被喂饱。接着用nsys和PyTorch Profiler给一条请求做完整追踪结果发现在CPU侧的数据预处理环节耗时占了整条链路的70%以上。每一条请求都要做分词、padding和特征转换CPU在跑这些操作时GPU只能闲着等。处理方案是典型的把CPU工作挪出关键路径用多进程DataLoader预加载和变换数据把预处理结果按batch提前塞进CPU内存队列再把队列消费和GPU推理解耦。具体操作上我加了一个有界队列消费端永远从队列拿现成的batch生产端用多个num_workers并行洗数据。改动之后GPU利用率从10%拉到了70%以上单卡吞吐提升了四倍。这个案例给我的教训是GPU显得没用的时候先别怀疑GPU而是要看GPU有没有得到足够的活。大部分利用率低的根因都不是算子效率而是数据送不到卡上。CPU如果处理不过来给你一万张A100也是摆设。4.2 显存碎片不是加卡就能解决的另一个高频坑是CUDA OOM。我们的服务部署在16G显存的卡上模型权重占8G按理说还有8G可用但并发一上来请求稍微多一点就直接OOM。起初我怀疑是请求量太大于是加了副本结果加了卡也照样OOM这就不对劲了。用torch.cuda.memory_summary()查看显存分配细节后发现空闲显存虽然多但都是零散的碎片根本分配不出一个连续的大块给新请求的KV cache。这就像停车场里有20个车位都只停着自行车却停不进一辆大巴。推理请求需要的是一整块连续显存碎片多了空间再多也没用。定位到问题之后我们做了两件事。一是把推理框架从Native的PyTorch换成了vLLM它用PagedAttention把KV cache分页管理不需要连续的大块显存碎片利用率大幅提升。二是把一些本来常驻显存但只在必要时才用的临时变量挪到了CPU侧减少显存峰值。换完之后同等硬件条件下并发量从几十涨到了几百增幅让人意外。所以遇到OOM别急着申请加卡先看看显存是不是碎了。4.3 生产环境调度器和本地调试的差异这个坑我很有发言权因为踩的不只一次。在本地用python app.py跑推理一切正常但部署到K8s后同一个镜像有时候会莫名卡住几十秒甚至第一波请求全部超时。最初我怀疑是镜像拉取慢了但查下来镜像只有几百MB不存在大文件拉取问题。后来用kubectl describe pod看到Scheduling阶段耗时很高才发现问题出在资源请求的定义上我们把训练和推理混在同一个节点池推理Pod被调度到一张还残留着训练进程的GPU上显存被占了一半推理服务起是能起来但可用的KV cache空间极小处理请求时就频繁换页性能惨烈。理清原因后我们做了两处调整给推理Pod单独设节点池加nodeSelector和显存请求声明同时给每个推理Pod加resources.limits.nvidia.com/gpu: 1和显存上限声明确保调度器在选择节点时就把显存余量考虑在内。这个改动看似简单实际规避了一整类起得来但性能崩的隐蔽故障。我的习惯是本地验证通过后一定会模拟至少一天的线上流量压测不只看能不能响应还要看GPU内部指标。真实流量下暴露的调度和显存问题本地调试几乎不可能发现。这部分经验在面试和日常运维里都非常加分。4.4 限流、优雅退出与雪崩保护推理服务上线后我们遇到过比OOM更隐蔽的问题服务雪崩。现象是流量高峰时单个实例P99延迟飙升自动扩容反复增减副本系统在振荡中崩溃。根因是请求队列无界新请求继续进队列每个实例拖到超时才退出K8s不断重启流量叠加在重启中的Pod上形成恶性循环。应对雪崩有三板斧缺一不可。第一是限流每个推理实例的业务侧和网关侧都加令牌桶超过阈值直接返回429不进入队列第二是优雅退出Pod收到SIGTERM后停止接收新请求但已有请求继续处理完成再退出避免中断正在推理的请求第三是队列有界化请求队列长度固定满了直接丢弃或走降级逻辑绝不让队列无限增长。这三板斧都落地后我们的服务经历了连续两次双十一级的流量冲刺P99延迟曲线都保持稳定。我见过太多团队只看扩容策略忽略雪崩防护等真出事再调试已经来不及了。AI-Infra的很多稳定性工作本质上都是在让失败以预期的方式发生而不是被动的碰运气式救火。5. 想转AI-Infra的新人我建议按这套路练5.1 必备工具链和知识域这个方向需要的技术栈不像算法那样深但特别宽。新人不建议一上来就去啃框架源码先把基础工具链练到位。Linux和Shell是底线awk、sed、grep、jq这些文本处理工具要随手就写。Docker和K8s至少要达到能独立排查问题的程度不要求会写全套operator但kubectl logs、describe、top、get events要熟练。GPU相关的知识必须懂NVIDIA驱动、CUDA版本、NCCL通信、nvidia-smi和nvitop的输出要能看明白。性能分析工具链里PyTorch Profiler、nsys、nsight-compute至少会一个。日志、指标、追踪这三件套要熟练配置PromQL能写基本查询就够用。这些工具不是背出来的而是要在真实故障里用出来。我建议新人找一台测试GPU机分别跑一个CPU密集型任务、一个内存密集型任务、一个GPU算子密集任务然后用工具去看它们各自的特征把什么指标对应什么瓶颈在脑子里建立映射。5.2 持续追踪的开源项目清单AI-Infra最好的学习材料是开源项目。我定期看的不多但每个都值得深挖KubeFlow和KServe看的是模型服务平台的标准形态vLLM和TensorRT-LLM看的是推理引擎如何优化显存与计算Ray看的是分布式调度与并行计算的通用框架Kueue看的是多租户GPU队列的正确姿势MosaicML和DeterminedAI看的是训练平台如何把容错做到极致Prometheus和Grafana看的是可观测性的落地方式OpenTelemetry看的是全链路追踪的标准实现。看项目的正确姿势不是刷README而是看它们的Issues和Design Docs。很多设计决策背后的权衡都在文档里写得很清楚比如为什么vLLM要用PagedAttention而不是简单的连续KV cache为什么KServe默认用Serverless而不用常驻Pod。把这些决策看懂你自己的架构判断力就长出来了。5.3 90天入门计划很多人想转这个方向但面对那么多工具不知道从哪下手。我给自己设计过一个90天计划按阶段推进比较稳。前一个月搭一套本地最小训练环境一台带GPU的机器或云上的几台GPU实例装好K8s、部署NVIDIA Device Plugin用手写一个简单的PyTorch训练脚本在K8s上跑通。这个阶段不追求复杂关键是理解容器里看到GPU是怎么回事以及为什么驱动和运行时兼容性那么重要。第二个月把推理服务真正接进去选一个开源模型用KServe或vLLM部署成在线服务配置Prometheus采集GPU指标再写一个简单的HPA规则让副本数根据GPU利用率自动伸缩。这一阶段你会碰到调度、显存、冷启动、负载均衡的一大堆真问题每个问题解决一遍比读十篇博客都强。第三个月针对你所在公司的痛点做一个专项优化。如果是训练集群利用率低就研究队列和抢占如果是推理性能差就上Profiler做算子级优化。做完这一轮你基本可以声称自己是一名入门级的AI-Infra工程师了。5.4 与算法、业务团队高效协作的沟通模型最后说几句软技能。AI-Infra工程师每天都要和算法、业务、运维三拨人打交道最常见的矛盾是算法觉得平台不好用平台觉得算法不按规范来。我摸索出的一套沟通模型很简单先定义事实再对齐预期最后给可执行方案。比如算法说训练卡死了我不会马上接你代码有问题而是先让他们提供Pod日志、GPU指标和模型代码版本我们把事实数据摆出来确认是显存不足还是代码死循环。确认之后对齐预期比如这个任务该多久完成、资源够不够最后给出一个双方都认可的执行计划。还有个技巧是每个问题都留一个文档。每次线上事故处理后我都会写一篇小的Postmortem包含时间线、根因、修复方案、预防措施。这样下一次类似问题出现直接翻文档就能少走弯路。团队从靠人记变成靠文档记整个协作效率会上一个台阶。写到这里一线工程师的AI-Infra之路的第一章就差不多收尾了。我在这个方向摸爬滚打这几年最大的感受是AI-Infra永远不会缺少脏活累活但恰恰是这些不被算法论文提到的细节决定了一个模型到底是Demo还是生产力。下一章我打算专门拆解训练侧的调度与容错那部分埋着更多有意思的问题——比如Checkpoint为什么这么难做、GPU故障怎么自动绕过。如果你也在这条路上一步步踩坑欢迎带着你遇到的故障一起来聊我们一起把这层地基铺得更稳。