1. 从“调参侠”到AI-Infra一个一线工程师的转型起点如果你现在打开招聘软件搜“AI工程师”会发现一个很有意思的现象算法岗的JD职位描述里越来越多地出现“熟悉分布式训练”“了解CUDA编程”“有大规模集群调优经验”这样的要求。而另一边基础架构岗的JD里也开始要求“理解Transformer结构”“熟悉PyTorch底层机制”。这两个方向正在快速融合融合出来的那个交叉地带就是现在圈子里讨论越来越热的AI-Infra。我自己就是在这个交叉地带里摸爬滚打过来的一线工程师。几年前我还在做传统的后端服务开发后来因为项目需要被拉去搞模型训练平台。刚开始那段时间我连NCCL是什么都不知道看到torch.distributed的文档一头雾水GPU利用率上不去只能干瞪眼。踩了无数坑之后我慢慢摸清了AI-Infra这条路的脉络——它不像纯算法那样有明确的论文可以跟也不像传统运维那样有成熟的体系可以套很多东西需要你自己去试、去调、去总结。这篇文章是我个人对AI-Infra这个方向的一次系统性梳理也是“一线工程师的AI-Infra之路”系列的第一章。我打算从最基础的问题讲起AI-Infra到底在做什么它和传统的MLOps、DevOps有什么区别一个从零开始的工程师需要掌握哪些核心能力以及在实际工作中那些文档里不会写、但每天都会遇到的真实问题该怎么处理。不管你是刚入行的新人还是从其他方向转过来的老兵希望这些内容能帮你少走一些弯路。2. AI-Infra到底在解决什么问题拆开“模型训练”这层皮2.1 从单卡到千卡规模带来的不是线性增长很多人对AI-Infra的理解停留在“帮算法同学配环境”这个层面这其实是个很大的误解。配环境只是最表层的活儿AI-Infra真正要解决的核心问题是当模型规模、数据规模、集群规模同时膨胀时如何让整个训练和推理系统保持高效、稳定、可扩展。我举个具体的例子。你在单卡上训练一个BERT-base模型batch size设成32跑一个epoch大概几十分钟整个过程很顺畅。现在你把模型换成GPT-3级别的1750亿参数数据量放大到几百GB单卡显存放不下模型你不得不做模型并行单卡训练时间从几十分钟变成几个月你不得不做数据并行加流水线并行几百张卡同时跑通信开销指数级上升你不得不优化集合通信策略。这时候你会发现原来单卡上那些理所当然的事情——比如梯度同步、参数更新、checkpoint保存——全都变成了需要重新设计的工程问题。这就是AI-Infra存在的意义。它要处理的是系统层面的复杂度而不是模型层面的创新。算法工程师关心的是“这个结构能不能提升准确率”AI-Infra工程师关心的是“这个结构在512张A100上跑起来MFUModel FLOPs Utilization能不能到50%以上”。2.2 AI-Infra和MLOps、DevOps的边界在哪里这三个概念经常被混在一起说但它们的侧重点完全不同。我用一个表格来对比维度DevOpsMLOpsAI-Infra核心目标加速软件交付管理模型生命周期优化训练/推理系统性能主要对象代码、服务模型、数据、实验GPU集群、通信、存储关键指标部署频率、故障恢复时间模型迭代速度、复现性吞吐量、延迟、MFU、显存利用率典型工具Jenkins、K8s、TerraformMLflow、Kubeflow、DVCNCCL、DeepSpeed、Megatron、vLLM技能栈脚本、容器、云平台数据工程、实验管理分布式系统、CUDA、网络、存储简单来说DevOps管的是“代码怎么上线”MLOps管的是“模型怎么迭代”AI-Infra管的是“模型跑得快不快、稳不稳、省不省”。三者有交集但核心关注点截然不同。一个成熟的AI团队这三个角色往往都需要只是在不同阶段侧重点不一样。2.3 为什么现在AI-Infra变得这么重要原因很直接模型规模的增长速度远远超过了硬件性能的增长速度。根据公开的数据过去几年里大模型的参数数量每年增长一个数量级以上而单卡GPU的显存和算力增长大概每两年翻一倍。这个剪刀差意味着你不可能靠单卡解决问题必须走分布式路线。而分布式系统天生就复杂——通信、同步、容错、调度每一个环节都可能成为瓶颈。另一个原因是成本压力。一张A100或者H100的卡云上按需价格每小时几十块钱一个千卡集群跑一天就是几十万的成本。如果MFU只有20%意味着80%的钱白花了。AI-Infra工程师的核心价值之一就是把这80%的浪费尽可能地压下去。我见过一个真实的案例某团队通过优化数据加载和通信重叠把训练吞吐提升了40%一年下来省下的算力成本够养一个小组。3. 一个AI-Infra工程师的能力地图我踩过的坑和补过的课3.1 底层基础CUDA、通信库和操作系统刚转过来的时候我以为自己Linux玩得挺溜结果第一次上机就懵了。nvidia-smi显示的显存占用和torch.cuda.memory_allocated()对不上训练过程中突然OOM但不知道是谁占的内存多卡跑起来GPU利用率忽高忽低。这些问题逼着我去补底层知识。CUDA层面你不需要会写kernel但必须理解几个核心概念显存分配机制为什么PyTorch的缓存分配器会导致“假OOM”、流和事件怎么用CUDA Stream做通信计算重叠、以及SM占用率为什么你的kernel跑不满GPU。我自己的经验是把CUDA的编程模型过一遍再回头看PyTorch的torch.cuda模块很多之前看不懂的API就豁然开朗了。通信层面NCCL是绕不过去的。你需要知道AllReduce、AllGather、ReduceScatter这些集合通信操作的区别知道Ring AllReduce和Tree AllReduce的适用场景知道NVLink和InfiniBand的带宽差异对训练的影响。我踩过的一个坑是在一个跨节点的训练任务里没有设置NCCL_SOCKET_IFNAME结果NCCL走了一个慢速的管理网口通信时间占了整个迭代的60%以上。后来指定了正确的网卡吞吐直接翻倍。操作系统层面你需要关注的是CPU亲和性设置避免进程在NUMA节点间乱跳、共享内存配置/dev/shm太小会导致DataLoader卡死、以及文件描述符限制大规模训练时打开的文件数可能上万。这些都是小细节但每一个都能让你debug半天。3.2 框架层PyTorch的“隐藏面”PyTorch用起来简单但要用好、用快需要理解它背后的机制。我总结下来AI-Infra工程师需要特别关注的PyTorch知识点有这么几个Autograd的计算图构建和释放为什么你的显存占用在backward之后没有下降可能是计算图没有被释放或者有引用残留。DataLoader的num_workers和pin_memory这两个参数设不对GPU就会饿着等数据。我一般会先用nvidia-smi看GPU利用率如果低于80%且波动大大概率是数据加载的问题。DistributedDataParallelDDP的通信钩子DDP默认在backward时触发AllReduce但你可以通过register_comm_hook自定义通信策略比如做梯度压缩或者异步通信。混合精度训练AMP的scale机制loss scaling不是越大越好动态loss scaling的初始值和增长策略需要根据模型调整。这些知识在PyTorch官方文档里都有但比较分散。我的建议是不要只读文档要动手写一些最小复现脚本。比如写一个简单的DDP训练脚本然后故意把bucket_cap_mb调大调小观察通信时间的变化。这种实验做多了直觉就出来了。3.3 分布式训练从数据并行到3D并行分布式训练是AI-Infra的核心战场。我把它分成几个层次来理解第一层数据并行DP/DDP。这是最常用的方式每张卡持有完整的模型副本数据切分到不同卡上梯度通过AllReduce同步。DDP比DP快很多因为DDP只在梯度同步时通信而DP每个iteration都要广播参数。但DDP的显存开销是O(模型大小)当模型大到单卡放不下时就需要下一层。第二层模型并行MP。把模型的不同层放到不同卡上比如前几层在GPU0后几层在GPU1。这种方式的问题是GPU利用率低因为同一时间只有一张卡在计算。后来发展出了流水线并行PP把数据切成micro-batch让不同卡可以同时处理不同micro-batch提高了利用率。但PP需要仔细设计micro-batch的数量和调度策略否则会出现“气泡”bubble浪费算力。第三层张量并行TP。把单个矩阵运算切分到多张卡上比如把一个大矩阵乘法拆成多个小矩阵乘法并行计算。这种方式通信频繁适合NVLink这种高带宽互联的场景。Megatron-LM是这方面的代表工作。第四层3D并行。把DP、PP、TP组合起来形成三维并行策略。这是目前训练千亿级以上模型的主流方案。但组合起来之后通信模式变得非常复杂需要仔细调优。我自己的学习路径是先把DDP吃透然后手动实现一个简单的流水线并行再去看Megatron和DeepSpeed的源码。不要一上来就啃3D并行容易劝退。3.4 推理优化训练只是上半场很多人以为模型训练完就万事大吉了其实推理优化是另一个深坑。训练关注的是吞吐量每秒处理多少样本推理关注的是延迟单个请求多长时间返回和吞吐的平衡。推理优化的核心手段包括量化把FP16降到INT8甚至INT4减少显存占用和计算量。但量化会带来精度损失需要做校准。KV Cache优化自回归生成时Key和Value矩阵需要缓存。PagedAttentionvLLM的核心技术把KV Cache分页管理大幅减少了显存碎片。连续批处理Continuous Batching传统批处理要等一个batch里所有请求都完成才能开始下一个batch连续批处理可以动态加入新请求提高了GPU利用率。算子融合把多个小算子合并成一个大算子减少kernel launch开销。TensorRT和TVM在这方面做得很好。我做过一个对比测试同一个LLaMA-7B模型用HuggingFace的默认推理吞吐是每秒8个token换成vLLM之后吞吐提升到每秒120个token。这个差距在线上服务里就是能不能扛住流量的问题。4. 真实工作场景那些文档里不会写的日常4.1 集群调度当K8s遇上GPU大部分公司的训练集群都是用Kubernetes管理的。但K8s原生对GPU的支持比较基础你需要装NVIDIA Device Plugin还需要考虑GPU共享、拓扑感知调度、故障隔离等问题。我遇到过一个很典型的问题两个训练任务被调度到了同一台物理机的两张GPU上但这两张GPU之间没有NVLink只有PCIe。结果跨GPU通信走了PCIe带宽只有NVLink的几分之一训练速度直接腰斩。后来我们引入了拓扑感知调度确保需要频繁通信的任务被分配到NVLink互联的GPU上。另一个坑是GPU内存碎片。K8s的device plugin只报告GPU数量不报告显存使用情况。有时候一个任务申请了一张GPU但只用了10%的显存另一张卡上的任务却因为显存不足被OOM kill。解决方案是用MIGMulti-Instance GPU或者时间片共享但这又带来了隔离性和性能的问题。4.2 存储与数据加载最容易被忽视的瓶颈训练一个大规模模型数据加载往往是第一个瓶颈。我见过太多团队花大价钱买了A100结果GPU利用率只有30%原因是数据从远程存储读取太慢。解决这个问题的思路是分层缓存第一层本地NVMe SSD。把当前epoch的数据预先缓存到本地盘读取速度可以达到几GB/s。第二层节点内共享内存。如果多个进程在同一节点上训练可以用/dev/shm做进程间数据共享避免重复读取。第三层分布式文件系统。比如Lustre、GPFS或者云上的对象存储。这一层容量大但延迟高适合做冷数据存储。另外数据格式也很关键。把原始图片或文本预处理成WebDataset或者TFRecord格式比每次训练时实时解码要快得多。我做过测试同样的数据用WebDataset比用原始文件读取DataLoader的吞吐提升了3倍以上。4.3 故障排查当训练突然变慢或崩溃分布式训练最让人头疼的就是故障排查。一个千卡任务挂了你不可能一张卡一张卡去查。我的经验是建立一套分层排查流程第一步看全局指标。用PrometheusGrafana监控整个集群的GPU利用率、显存、温度、功耗、网络带宽。如果发现某张卡的利用率明显低于其他卡那问题大概率出在那张卡或者它的通信链路上。第二步看单任务日志。NCCL会输出通信初始化的详细信息包括用了哪些网卡、带宽是多少、有没有超时。PyTorch的DDP也会在初始化时打印一些信息。这些日志里往往藏着线索。第三步用工具定位。py-spy可以dump出Python进程的调用栈看看是不是卡在某个函数上。nsys和ncu可以分析CUDA kernel的执行情况。nccl-tests可以单独测试通信性能。第四步最小复现。如果问题只在特定配置下出现尝试缩小规模复现。比如从千卡缩到8卡看看问题是否还在。如果在8卡上能复现排查起来就简单多了。我印象最深的一次故障一个训练任务跑了三天突然变慢GPU利用率从90%掉到40%。查了半天发现是某个节点的网卡出现了间歇性丢包导致NCCL重传。换掉那块网卡之后恢复正常。这种硬件层面的问题没有监控数据根本无从下手。5. 给刚上路的同行几条实在的建议5.1 不要只盯着算法系统能力才是护城河现在算法岗卷得厉害但AI-Infra岗的人才缺口还很大。原因很简单算法可以速成但系统能力需要时间积累。你花三个月学完Transformer和Diffusion但你可能需要一年才能真正搞懂分布式训练里的各种坑。我的建议是如果你对系统感兴趣不要犹豫往AI-Infra方向走。这个方向的天花板很高而且随着模型规模继续增长需求只会越来越大。5.2 动手比看书重要但要有方向地动手AI-Infra是个实践性极强的领域。你看十篇讲流水线并行的文章不如自己写一个简单的流水线调度器。但动手也要有方向不要盲目地造轮子。我的做法是先跑通一个开源框架比如DeepSpeed或Megatron然后尝试修改它的某个模块观察性能变化。比如把AllReduce换成AllGather看看吞吐和显存有什么变化。这种“改-测-分析”的循环是成长最快的方式。5.3 建立自己的性能分析工具箱每个AI-Infra工程师都应该有一套自己的性能分析工具。我常用的包括nvidia-smi和nvitop看GPU整体状态nsys和ncu分析CUDA kernel和通信py-spy分析Python进程nccl-tests测试通信性能iperf和ibstat测试网络带宽dcgmGPU集群监控这些工具不需要全部精通但要知道在什么场景下用哪个。比如GPU利用率低先用nvidia-smi看是不是有卡在等数据然后用py-spy看Python进程在干什么最后用nsys看kernel执行有没有问题。5.4 保持对硬件的敏感度AI-Infra和硬件结合得非常紧密。你需要关注每一代GPU的架构变化比如Hopper的Transformer Engine、Blackwell的FP4支持关注互联技术的演进NVLink的带宽、InfiniBand的速率关注存储介质的更新NVMe SSD的IOPS、CXL内存扩展。这些硬件特性直接决定了你的优化空间。我自己的习惯是每出一代新卡就去读它的白皮书看看有哪些新特性可以利用。比如Hopper的TMATensor Memory Accelerator可以大幅提升数据搬运效率如果你不知道这个特性就白白浪费了优化机会。5.5 多和算法同学聊天理解他们的痛点AI-Infra是服务于算法和业务的。如果你不了解算法同学在做什么你的优化可能根本用不上。我经常和算法同事一起看训练日志听他们抱怨“这个模型跑得太慢了”“显存又不够了”“这个实验复现不出来”。这些抱怨里藏着真实的优化需求。比如有一次算法同学说他们做超参搜索时每个实验都要重新加载数据很浪费时间。我后来帮他们做了一个数据预加载服务把常用数据集缓存在内存里实验启动时间从几分钟缩短到几秒。这种优化不需要多高深的技术但需要你理解他们的工作流程。6. 这一章先聊到这里AI-Infra这条路不好走但走通了之后你会发现自己看问题的视角完全不一样了。你不再只是关注“这个模型准不准”而是会去想“这个模型在真实系统里跑起来会是什么样”“瓶颈会在哪里”“怎么用有限的算力做更多的事”。这种系统思维是AI-Infra工程师最核心的竞争力。后面几章我打算具体展开讲几个方向分布式训练的通信优化、推理服务的性能调优、以及GPU集群的监控和故障排查。每一块都会结合我实际踩过的坑和用过的方案来写尽量做到看完就能上手试。如果你也在走这条路或者正准备走欢迎一起交流。这个领域变化太快一个人闷头搞容易走偏多听听同行的经验总没坏处。
