从业务后端转向AI-Infra说实话并不在我原本的职业规划里。2023年下半年团队第一次认真做行业模型微调算法同学每天在群里喊“谁占了卡”“这张卡给我留一下”任务排队纯靠口头协调。我接到的第一个相关需求是“把GPU利用率提上去”。当时真觉得这事不难写个脚本按显存占用排序清理闲置进程配个定时任务自动执行搞定。结果上线当天就误杀了一个跑了一整天的训练任务checkpoint没存上几万块算力直接打水漂。从那个下午起我才真正意识到AI-Infra不是简单的资源清理和进程管理它是一个影响算法团队研发效率、决定模型能不能按时交付的完整基础设施工程。这篇算是我这个系列的第一章核心是把我在起步阶段理解的AI-Infra讲清楚它到底解决什么问题、一线工程师该从哪里切入、第一轮工程实践怎么落地以及第一批坑是怎么踩出来的。适合刚接触大模型训练平台、准备从业务后端转过来的工程师也适合想搞清楚“训练平台背后到底在做什么”的算法同学。1. AI-Infra到底在解决什么问题1.1 从一句“任务跑不完”说起先还原一个我在无数团队里见过的场景。算法团队手里有几台GPU服务器训练脚本能跑通单卡实验没问题。可一旦同时跑几个实验局面就开始失控有人占了卡忘了释放有人跑着跑着把另一人的进程kill了还有人的环境变量和集群默认配置不一致同一个镜像在不同节点上报错完全不同的错。这些小问题单拎出来都不算大事但叠加在一起团队每天的有效工作时间被大量消耗在“协调”和“排障”上。AI-Infra要解决的本质上就是这三类问题算力资源怎么高效分配、机器学习任务怎么稳定运行、模型怎么低成本变成服务。它不像算法那样直接产出精度指标也不像普通后端那样面向C端用户它是夹在模型和硬件之间的那层基础设施。这层不给力上面的一切都无从谈起——算法写再好卡不够、环境不对、任务总失败还是交付不了。1.2 先给AI-Infra画个边界很多刚开始接触这个概念的人会把AI-Infra约等于“GPU服务器加驱动加环境变量”。这只是其中最底层的一小块。我根据自己的实践和业界共识把AI-Infra大致分成五层计算资源层GPU/NPU驱动、容器运行时、显存管理、设备健康检查与故障自愈。调度层任务排队与优先级、多训练任务的资源分配、训练和推理任务的共存策略、多租户隔离。数据与存储层数据集读取、checkpoint管理、镜像分发、缓存分层。网络层单机多卡和多机多卡的通信优化、NCCL性能保障、拓扑感知调度。平台与可观测层监控告警、日志、账单、配额、任务生命周期管理、算法工程师的自助入口。这五层每一层单拎出来都够写几十篇深度文章。但做一线工程时最强烈的体感是各层之间高度耦合。你在调度层做的一个小改动可能会在数据层引入额外延迟也可能在网络层制造新的瓶颈。所以真正难的不是理解某一个知识点而是理解这些层互相作用的方式。1.3 为什么不能照搬云原生那套经验我过去做业务后端时习惯是服务无状态化、挂了就重启、流量上来了就横向扩容。这套思路在常规Web服务里非常成熟但搬到训练任务上会出大问题。训练任务是不能随便重启的。一个跑了好几天的训练任务被调度器重新调度意味着之前几万块的算力费用全部清零。分布式训练的多个进程之间存在状态关联更不能像无状态服务那样搞滚动重启。推理服务对延迟极其敏感又和训练任务共享GPU时会互相抢占资源。所以AI-Infra的优先级不是“能容忍故障”而是“尽量减少故障”并在故障发生时通过checkpoint、任务恢复、快速回滚等手段把损失控制在最小。2. 第一章的关键知识地图2.1 计算层不是“有卡就能跑”第一周我做的事情特别不高级到处救火式地解决环境问题。同一个训练镜像在开发机上跑得好好的一上集群就报“CUDA driver version is insufficient”。原因说穿了很简单——节点上的GPU驱动版本和镜像里编译的CUDA版本不匹配。这个坑在单机开发时几乎不存在因为开发机和本机驱动天然一致一旦上了集群多台机器驱动版本有差异镜像里却只有一套CUDA各种诡异报错就批量出现了。我的对策是建立兼容性矩阵GPU驱动版本、CUDA版本、镜像tag、PyTorch版本全部固化对应关系新节点上线必须匹配。同时在镜像规范里禁止算法同学直接改CUDA相关环境变量真有特殊需求就走标准流程生成新基线镜像。这个习惯看起来不起眼但后来帮我省掉了大量半夜的告警电话。2.2 调度层K8s之上别只盯着默认调度训练任务调度现在基本都是K8s但核心问题不是“能不能调度”而是“怎么调度才算合理”。普通Web Pod的调度只看CPU内存够不够训练Pod还要考虑几件事任务需要的多张GPU是否落在同一个节点上节点之间是否有高速网络推理任务和训练任务放在一起是否会互相干扰特殊机型是否应该留给高优任务。我第一章的做法是先把资源声明和调度约束标准化节点打上gpu-type、topology-rack这类标签训练任务通过模板声明nvidia.com/gpu数量再用Volcano或Kueue做队列和优先级管理。调度这种能力一开始真的不需要自己写调度器先站在框架的肩膀上跑起来等团队规模确实大到有独特需求时再考虑二次开发都来得及。2.3 网络层NCCL与拓扑最容易被忽视的大变量分布式训练里NCCL负责多卡之间的集合通信梯度汇总、参数同步全靠它。如果训练Pod被随机分布在不同交换机下面跨节点通信走到普通以太网带宽会从几百Gbps掉到几十Gbps训练一次迭代的时间可能暴涨好几倍。我在第一步就做了两件事在所有节点上配置NCCL相关环境变量利用K8s节点亲和性让同一个训练作业尽量落在同一拓扑域内。容器网络尽量使用宿主机网络模式减少额外封装带来的性能损耗。判断网络是不是瓶颈我通常会在容器里跑一次nccl-tests用all_reduce_perf测不同节点间的真实带宽。数字不会骗人日志里的“卡住”往往根本不是卡住而是通信慢得像在爬。2.4 存储与数据层数据要追得上算力训练时GPU算得飞快但数据如果从远端存储慢吞吞地拉GPU就只能在显存里空等。我遇到过一个特别典型的场景所有人从同一台NFS挂载读数据一个数据集几十GB几个任务同时读磁盘IO直接打满训练速度掉到正常情况的三分之一。看监控的时候GPU-Util和显存都正常但Loss更新就是慢定位了半天才发现是存储问题。后续的思路是数据本地化节点本地加NVMe做缓存训练启动前把数据集从对象存储拉到本地checkpoint先写本地临时目录再异步同步回持久存储日志和临时文件单独挂盘避免和系统盘抢空间。这种让数据离GPU更近一步的设计比单纯调大缓存参数要有效得多。2.5 可观测与成本层指标要能被业务听懂很多工程师沉迷于监控各种技术指标但算法负责人和管理者更关心的是这周烧了多少算力、哪个实验最贵、为什么某个项目资源总是不够。我搭监控时除了标准GPU利用率还特别做了几个业务视角的指标任务排队耗时、有效训练占比GPU实际计算时间除以总占用时间、单位模型训练成本、按团队和项目的资源账单。这些指标上线后算法同事第一次直观看到自己每个实验消耗了多少真金白银很多浪费资源的习惯自然就改了。做AI-Infra有一个被低估的能力沟通能力。你给出的指标必须让业务方听得懂、愿意行动不然再漂亮的可视化看板都只是自嗨。3. 我实操过的三个关键环节3.1 搭一个最小可用训练平台我最初给自己的目标很实在让算法团队能自助提交训练任务不需要找我来人工分配资源。技术选型不复杂K8s集群加GPU节点加Volcano队列再加一套标准化任务模板。算法同学提交一个YAML写明镜像、GPU数量、启动命令和checkpoint路径就能自动排队、调度、运行、查看日志。当时卡得最久的一个点是怎么让K8s“认识”GPU资源。原生K8s不认识GPU社区的标准做法是部署Device Plugin把GPU作为可调度资源上报给Kubelet。插件部署好之后在节点容量里能看到nvidia.com/gpu这个资源项Pod里声明请求数量才能触发调度。apiVersion: v1 kind: Pod metadata: name: train-job-001 spec: nodeSelector: gpu-type: a100 containers: - name: trainer image: registry.local/training/torch:2.1-cuda12.1 resources: limits: nvidia.com/gpu: 4这个阶段最关键的不是功能丰富而是提交、排队、运行、日志、结果回传这条链路能跑通。很多团队想一步到位做“全功能AI平台”结果半年过去算法团队还在用最原始的方式跑模型。小步快跑先把主线打通再慢慢加功能是更务实的选择。3.2 推理服务化三个容易被忽略的细节训练链路稳定之后下一步就是推理服务化。这里有几个坑踩过之后我觉得必须写出来。第一是模型加载预热。大模型加载到显存要几十秒如果Pod刚启动就接流量前几个请求大概率超时。我的做法是在启动脚本里加一步自检推理模型加载完成后先跑一次最小输入推理确认返回结果正常再对外发布服务地址。这一步多花十几秒但能避免大量线上超时告警。第二是显存和并发不是线性关系。很多人以为模型占20G显存并发翻倍显存就翻倍实际上完全不是。模型权重占一部分显存剩下的空间会被KV cache和推理中间态占用并发越高KV cache占用越大。所以设置并发上限不能只看模型体积必须在真实负载下用压测工具测出安全值再留出20%到30%的余量。第三是扩缩容要克制。常规Web服务扩容是秒级但推理Pod拉起、加载模型、完成预热可能要30到60秒。如果自动扩缩容阈值设得太紧流量突增的那一刻扩容根本来不及用户已经超时走了。我后来宁可预留一些闲置副本把扩容阈值放宽也不为了省一点算力把线上SLA打穿。3.3 全链路监控怎么埋点刚开始做监控时我盯着GPU利用率这一个指标结果很多问题定位不了。后来把视角拉成全链路任务提交、排队等待、分配节点、拉取镜像、初始化环境、加载数据、开始训练、checkpoint落盘、训练结束、结果回收每一环节都记录开始时间和耗时。这样所有事件汇总到统一监控系统后可以一眼看出任务到底卡在哪个环节。具体选型参考Prometheus做指标存储Grafana做可视化GPU指标用DCGM Exporter。任务状态、排队时长、checkpoint耗时这类业务指标用一个轻量自定义Exporter上报。日志分级别采集训练日志全量保留但debug级别不采避免日志系统本身吃太多资源。告警规则我建议先覆盖三个核心排队超过15分钟、GPU故障、checkpoint失败后续再按真实事故慢慢补充长尾场景。4. 踩坑记录与排查思路4.1 显存申请了很多利用率还是上不去平台第一轮上线后有算法同学反馈任务申请了40G显存但GPU利用率一直只有10%。我第一反应是资源没绑对去看了部署配置发现显存确实申请了调度也确实给了卡。于是我在节点上跑nvidia-smi dmon盯实时GPU-Util发现计算单元大部分时间都是空的而数据加载队列一直在积压。和算法同学一起看代码后确认瓶颈在Dataset读取和预处理每次迭代都在等磁盘IO和CPU预处理GPU自然空转。这个经历让我学会一件事AI-Infra工程师要能分清“平台瓶颈”和“模型瓶颈”。GPU显存高但利用率低大概率不是卡不够而是代码里有什么东西在等。我后来排查问题时习惯同时看GPU-Util、显存占用、磁盘IO、网络流量四个指标组合起来基本能判断瓶颈在哪一层不会一看到GPU利用率低就急着加卡。4.2 多机训练卡死在一个通信步骤第一次做多机分布式训练时只有2台4卡的机器。任务日志一直停在NCCL初始化阶段等了一小时也没动静。我用nccl-tests重新测跨机带宽发现只有几百MB/s而单机内的GPU通信带宽要高好几个数量级。进一步检查发现容器没开宿主机网络模式跨机通信走了overlay网络额外的封装修饰消耗巨大。我第一时间把训练类容器的网络切到hostNetwork同时给节点打上机架和交换机拓扑标签保证同一个训练Pod尽量被调度进同一个拓扑域。这个改动之后训练速度直接提升了接近5倍。通信问题的排查不能在日志里干等一定要用实测数据定位。4.3 数据读取成了整个集群的瓶颈有段时间所有训练任务都慢得离谱而且不是某一台机器的问题。逐个节点排查发现每台节点的存储IO都处于高水位但因为任务分布在不同机器上单看任何一台都无法发现异常。最后所有任务都在从同一个NFS挂载读取数据训练前反复拉取几十GB的数据集IO自然被打满。改法是数据本地化每个节点加一块NVMe盘做缓存训练启动前把数据集从对象存储同步到本地checkpoint先写本地临时目录训练完成后再异步回传。也就是说让读路径上最热的数据永远在离GPU最近的地方。改造后整体训练速度提升了大概50%后续也再没出现过因为NFS抖动导致的任务集体失败。4.4 监控系统本身把集群拖垮了给集群加了完整监控的一周后出了个让人哭笑不得的事监控采集器把资源吃掉了不少。GPU指标采集、日志采集、进程监控再加上Prometheus抓取频率过高一些小节点的系统组件CPU占用超过20%在GPU密集节点上已经直接影响训练速度。解决办法有三条降低采集频率GPU指标从每秒改成30秒一次日志分级别采集WARN以上和符合规则的业务日志才保留把监控组件单独调度到几个低配置管理节点不和训练任务抢资源。做AI-Infra观测系统的工具本身就是系统的一部分设计时一定要考虑它的资源代价。5. 给想入坑AI-Infra的工程师的建议5.1 先做最小闭环别一上来就奔“大平台”很多团队看到市面上的AI平台功能很全就想着一步到位登录、配额、多租户、模型仓库、一键训练、自动扩缩容、审计全都要。现实是几个月过去算法团队最常用的操作都还没覆盖。我的建议是先做最小闭环让一个算法同学从提交任务开始能看到排队状态、运行日志、资源指标、最终输出结果。这个闭环跑通后再往上面加多租户、配额、自动扩缩容这些复杂能力。先完成一条主链路永远比铺开一堆半成品有价值。5.2 把Linux、网络、存储这些“旧知识”补扎实AI-Infra表面上全是新名词但实际工作中最常出问题的地方恰恰是网络命名空间、磁盘挂载、文件系统权限、宿主机内核参数这些偏底层的“老知识”。NCCL通信对内核缓冲区参数有要求数据缓存要选对文件系统和挂载选项任务日志采集要处理日志轮转。这些问题追到根因都是传统后端和运维的基本功只是出现在了新场景里。所以对想转型的工程师我有一句特别现实的话不要只盯着K8s和GPU把RDMA、文件系统、TCP/IP调优这些偏底层的内容也补起来。在一线救火时扎实的网络和存储基础比会写多少页面管用得多。5.3 常见工具组合参考最后整理一份我在第一章实际用到或调研过的工具清单仅代表个人选型偏好层面工具用途和第一印象资源监控nvidia-smi、DCGM ExporterGPU基础指标和利用率追踪必装任务调度Volcano / Kueue队列、优先级、批量调度比自己写脚本强太多平台底座K8s GPU Device Plugin集群标准化资源声明与调度模型推理vLLM / Triton Inference Server大模型推理引擎参数调节有讲究数据加速JuiceFS / Alluxio 或本地NVMe缓存把数据拉近GPU解决存储瓶颈监控体系Prometheus、Grafana、Loki指标、看板、日志上手成本低成本分析KubeCost 或自研账单让资源消耗可视化推动业务改变习惯工具不在于多在于和你的场景匹配。比如小团队没有专门的存储运维力量直接上JuiceFS可能维护成本很高反而不如本地SSD缓存加对象存储的组合轻量。选型标准永远是用最小的维护成本解决当前团队最疼的问题。写完这一章我自己最深的体会是AI-Infra这个方向听起来“硬核”但做的事其实非常朴素——把算力、数据、模型之间的距离拉近把不确定性尽量赶出去。它不像写算法那样有惊艳的突破感更像是在给一座城市铺设水电管网出问题时所有人都会抱怨你修好了却未必有人记得。如果让我给刚走上这条路的人一句建议我会说不要急着造轮子也别迷信大平台。先把最小闭环跑通把监控和失败预案做扎实把数据链路理顺你的工作就已经产生了巨大价值。路还很长我也是边烧算力边学第一章就到这里下一章我们聊更深一点的调度和推理优化。
