经常有人问我你是做AI的吗我点点头对方下一句通常是“那你是不是天天调模型、写算法、跑实验”我得花好长一段话解释不是我做的是大模型底层的AI Infra更直白一点讲每天打交道最多的是算子、加速卡驱动、分布式通信、集群调度这些听起来一点都不“智能”的东西。但恰恰是这群人决定了同一个模型在同样的硬件上能跑多快、能省多少钱、能不能十天十夜不出岔子跑完一次训练。这篇文章就是想把这个群体的日常工作摊开来讲。不管你是在做上层业务、刚转行入门还是和AI Infra团队经常打交道的算法同学看完应该能建立一张完整的地图从最底层的算子到分布式训练框架再到集群调度和数据管道这群“看不见的人”到底在忙什么以及如果你想入局应该从哪里开始练手。1. 先从一句话说起为什么大模型逼近了物理设备的极限很多人以为“大模型很厉害”是因为算法巧妙这话只对了一半。真正让GPT这类模型跑起来的是几千张加速卡并行运转、几十台存储服务器持续喂数据、复杂调度系统把每个计算单元压榨到极限的一套底层工程系统。做AI Infra的人本质上是在和物理设备的极限讨价还价。1.1 “算力不够”不是一句抱怨而是一串数字我先给你算一笔账你就能理解为什么底层工程如此重要。假设要训练一个700亿参数规模的模型用常见的BF16精度存储参数每个参数占2字节。光是把这700亿个参数放到显存里就需要700亿 × 2字节 ≈ 140GB这还只是参数本身。训练过程中每个参数至少还要存一份梯度140GB以及优化器状态。主流的Adam优化器对每个参数要维护两个状态量一阶动量和二阶方差每个又是140GB。也就是说仅参数、梯度、优化器状态这三样加起来就已经超过560GB了。一张主流加速卡目前也就80GB显存。所以“单卡装不下大模型”这件事不是一个抽象概念而是一个非常具体的数学约束。你把560GB除以80GB至少需要7张卡才塞得下静态数据。可还没算上中间产生的激活值、注意力机制的KVCache、通信缓冲区这些额外占用往往又翻一两倍。所以实践中训练一个700B模型起步就是几百张卡。几百张卡意味着什么意味着通信开销、故障概率、调度复杂度全部指数级上升。做AI Infra的人天天就是在和这套“卡多了反而变慢、变脆”的物理现实作斗争。1.2 显存墙与通信墙每天和物理极限讨价还价AI Infra这个领域有两个绕不过去的墙几乎所有技术细节都在这两堵墙上展开。第一堵墙显存墙。加速卡计算速度在过去十几年涨了成千上万倍但显存大小和显存带宽的增长却慢得多。一个很尴尬的事实计算单元吃数据的速度比显存“端菜”的速度快了几十倍。很多时候算子跑不快不是因为算得慢而是因为数据在显存和计算单元之间来回搬运的时间占了绝对大头。你可以把这个想象成一位顶级厨师配了一个手脚很慢的传菜员厨师一天下来真正炒菜的时间没多少大部分时候在等菜。第二堵墙通信墙。当几百张卡协同训练一个模型卡与卡之间要不断同步计算结果。卡内数据交换速度极快但跨卡走的是另一套物理通道速度可能差一个数量级。于是系统经常陷入一种尴尬状态每张卡算得飞快但大部分时间都在那互相等数据。通信墙决定了并行扩展是有天花板的——不是你加一倍卡速度就能快一倍。这堵墙解释了为什么这个领域需要专门的算子开发和框架工程师把显存搬运量降到最低把通信数据量压到最小把可并行计算和通信尽量重叠起来。1.3 AI Infra这个名词到底收纳了哪些职责AI Infra是个大杂烩。我梳理了一下至少可以拆成五层层级核心职责典型问题算子层让每个计算单元以最高效率执行矩阵乘、归一化、注意力等底层操作为什么这个算子只用到50%算力能不能做算子融合框架层把计算图拆到多张卡上编排执行顺序管理自动微分分布式并行策略怎么选显存如何节省调度层把不同训练任务的资源需求合理分配到GPU集群上怎么排队怎么避免碎片谁的任务优先级更高数据层保证数据高速、稳定、有序地送进训练管道数据读取是不是瓶颈数据分布是否正确监控与稳定性让一个可能跑十天十夜的训练任务不中断、不回滚物理故障怎么容错损失变成NaN怎么快速定位这五层之间边界模糊不同团队划分方法也不一样但核心目标是一致的让模型训练跑得更快、更稳、更省钱。这就是AI Infra的完整定义。接下来我按从底向上的顺序逐层拆解这群人到底在日常忙什么。2. 算子层的日常把计算图塞进硬件是一件精细活算子这个词很多人天天听但没细想过。它在不同语境里有微妙区别我先花一小段把这个概念钉死否则后面聊优化会乱。2.1 先搞清楚算子、内核、计算图三者是什么关系在深度学习框架里计算图描述了整个模型的计算流程输入数据进来经过哪些节点做矩阵乘、加偏置、做激活、做归一化、算损失。每个计算节点就是一个算子比如矩阵乘算子、LayerNorm算子、注意力算子。而内核Kernel是算子落在具体硬件上的实现代码。同一个“矩阵乘算子”在不同加速卡上有不同内核实现。通用厂商提供的算子库覆盖了90%以上常见场景但总有长尾需求——新型激活函数、变形注意力结构、混合精度数值修复——需要团队自己写内核。这就是算子开发的起点。换句话说模型团队用计算图表达“我要算什么”算子团队负责回答“怎么算才能榨干硬件”。这个“怎么算”的过程远比外人想象的琐碎。2.2 三层优化思路访存、计算与融合我入行这么多年把算子优化的思路压缩成三层几乎可以套用到任何问题上第一层优化访存模式。前面说过显存带宽是稀缺资源。一个算子如果反复把中间结果写到显存、再读回来性能一定拉胯。优化的核心思路就是减少显存读写次数尽量让数据在高速缓存或片上缓存里多待一会儿。第二层优化计算过程。有些算子的浮点运算次数太高可以数学等价改写。比如把矩阵乘的循环顺序做分块让缓存命中率提高或者把两个可分离的卷积拆成两步小卷积运算量直接减半。这一层偏数学和算法设计了。第三层算子融合。把多个相邻算子合并成一个一次性算完所有东西。常见融合场景是“矩阵乘偏置激活残差连接”——常规做法是这四个算子依次执行每一步都把结果写回显存。融合之后中间结果只存在于片上缓存直接在最后一步写回一次。对带宽敏感的算子这一招能把端到端时间压缩到三分之一甚至更少。兼通这三层的人才算真正入了算子开发的门。2.3 一个典型的性能优化案例Attention从“能跑”到“快跑”注意力机制是理解算子开发最生动的例子。早期大模型训练慢很大一部分原因就出在注意力算子的实现方式上。标准的注意力计算流程是先让Q和K做矩阵乘得到注意力分数矩阵S对S做softmax归一化得到概率矩阵P再用P和V做矩阵乘得到最终输出O。另外还需要做dropout、缩放、掩码等一系列辅助操作。在朴素实现里这个流程被拆成好几个独立内核。S矩阵得先完整写到显存里然后下一个内核把它从显存读出来做softmax得出的P又写回显存再用第三个内核把P和V相乘。如果是长序列场景序列长度达到几千甚至上万S和P矩阵的尺寸会爆炸式增长——这些中间矩阵的全部读写操作全都在浪费宝贵的显存带宽。后来的优化方向很直接能不能在片上缓存里把S算出来、做完softmax、再和V相乘全程不往显存里写答案是能但引入两个工程难点片上缓存空间有限存不下超大矩阵需要把计算分块处理softmax依赖全局最大值和求和分块后没法一次性算完于是需要一种叫“在线softmax”的小技巧先局部近似再逐步修正保证数学上和全局softmax完全一致。这个融合方案做出来后效果非常夸张——长序列场景下注意力算子的耗时直接砍掉一个数量级。这就是为什么同等硬件规模下后来的模型可以比早期模型训练得更快很大一部分功劳不在算法结构而在算子的工程实现。2.4 运算符优化什么时候该停手算子开发容易上头因为总有更巧妙的融合方式、更精细的访存策略。但成熟的AI Infra工程师都知道一个道理优化是有边界的。首先任何算子在硬件上都存在理论下界。比如矩阵乘的浮点运算量是固定的算力用到接近峰值后就没什么可挤的了。这时候继续抠微调一小时省不了几秒投入产出比很差。其次优化是有收益递减规律的——前几次优化可能带来数倍提升后面的优化往往只有百分之几甚至更少。这时候该做的是收手把精力投到其他瓶颈上。最后每个融合算子都得经过充分测试。算子越复杂踩到的数值边界越邪门一个融合后的算子如果某个边界条件下数值稳定性不如旧实现那它再快也不能上线。我会和模型团队这样对齐你们只管把模型结构定好算子层保证性能达标且数值稳定。什么时候该优化、优化到什么程度用事实和数字说话而不是感觉。3. 往上走一步分布式训练框架的隐性工程债算子解决了“单张卡怎么算得快”的问题但大模型训练根本不是单张卡的问题。下一步是把计算拆分到几百张卡上这就是分布式训练框架的活。这一层藏着的工程债比大多数人想象的多得多。3.1 三种并行策略先有分工才有通信把模型拆到多张卡上主要有三种并行策略我分别用一个生活化类比解释数据并行相当于复印机模式。每张卡都放一份完整的模型副本只分配不同的数据片段。每个step结束时所有卡把各自算好的梯度汇总平均再拿平均后的梯度去更新权重。这是最简单、最常用的并行方式但它对显存的节省为零——每张卡都要装下一整个模型。张量并行相当于把一个大蛋糕切开每人负责一块。把一个层内部的矩阵计算按行列方向切开分到多块卡上协同算出结果。这种方式可以显著降低单卡显存占用但是卡与卡之间需要频繁交换中间结果通信开销极大。流水线并行相当于工厂流水线。把模型的几十上百层按顺序切成几段每张卡负责其中一段。数据像半成品一样从前一段传到后一段。训练时卡1算完一批数据马上丢给卡2自己回头算下一批保持流水线尽量满。但流水线天然有气泡——在某些切换点部分卡会空转效率打折扣。这三种策略各有优缺点实际训练中往往叠加使用先用张量并行把超大模型拆小再用流水线并行按层切段最后每一段内部套数据并行。这样组合出来的拓扑结构极其复杂通信路径交叉纵横哪一个环节没设计好性能就会雪崩。并行策略显存节省效果通信开销典型适用场景数据并行无中模型能放进单卡追求吞吐张量并行高高单层计算量巨大的大模型流水线并行高低网络层数很深的模型框架的职责就是把这三种策略组合成一个稳定高效的编排方案。而组合爆炸的排布空间让分布式方案的调优永远有故事可讲。3.2 Ring AllReduce为什么绕圈传递反而更省带宽分布式训练里最频繁的操作是梯度同步。每张卡算出一份梯度得汇总平均后再分发回去。这里最常用的通信算法叫Ring AllReduce这也是理解通信墙的关键入口。最笨的办法是“中心汇聚”所有卡把梯度发给主卡主卡汇总完再广播给所有人。缺点是主卡带宽被塞满显卡多了直接瘫痪。Ring AllReduce的做法完全不同把所有卡首尾相连成一个环每张卡只和相邻卡交换数据。数据被切分成一块块的在环上传递每张卡收到相邻数据后立刻做局部相加再传给下一张卡。最后所有数据都在环上转了一圈每张卡都拿到了完整的聚合结果。这个算法的精巧之处在于通信量假设有P张卡总数据量是G环形算法下每张卡实际传输的数据量约为2×(P-1)/P个G。当卡数很多时这个比例趋近于2G。而中心汇聚方案下主卡要接收(P-1)×G的数据再加G的广播总体通信量是前者的好几倍。卡越多Ring AllReduce的优势越大。你会问为什么非要绕一圈不能直接两两配对传因为这涉及到带宽利用率。环形算法能让所有卡在整个同步过程中都保持传输状态几乎没有空闲。通信芯片是很贵的资源让它一直有活干就是算法设计的意义所在。在真实集群里一张卡卡内交换数据的速度和跨机走网络的速度差了可能接近一个数量级。设计并行方案时要尽量让通信只发生在高速链路内一旦计算任务被迫跨越低速链路通信时间占比瞬间从10%飙到50%。这就是为什么框架工程师总说“拓扑感知调度”有多重要——你不但要知道数据在哪还要知道卡在哪、连线带宽是多少。3.3 断点续训是对心理素质的最好测试分布式训练还有一个隐性工程债容错。你可能觉得程序而已挂了重启不就行了但一次大模型训练常常要跑几百个小时中途任何一张卡发生硬件故障、任何一台机器网络闪断、任何一段存储内容损坏整个训练就可能中断。重启后如果只能从最开始跑起那几百小时直接清零。所以框架要设计断点保存机制定期把模型权重、优化器状态、训练步数这些快照保存下来。但这里有一个坑很多人没意识到仅仅保存模型状态远远不够。训练过程中数据读取顺序由随机数生成器控制如果不能把随机数生成器的种子状态一并保存作业恢复后读到的数据就和断点之前的数据顺序对不上。轻则影响收敛重则模型在小batch上重复学习评估指标出现诡异波动。我踩过最惨的一次坑是训练跑到第90小时物理机突然掉电使尽了浑身解数恢复训练过程看着也没报错但接下来几天loss曲线异常平缓。排查了一天半原因就是数据读取的随机种子没有随checkpoint一起恢复训练落到了固定的重复数据片段上。这类问题日志看起来全是正常的但结果就是不对劲。框架层的容错工程远比一般人想象的更需要敬畏。3.4 扩容和缩容里藏着框架工程师的噩梦还有一个非常隐蔽的坑训练任务刚开始时的规模和后期的规模经常不一样。任务一开始用64张卡跑跑到一半集群腾出更多资源想扩到128张卡加速。这时框架要动态改变并行策略做数据重切、通信拓扑重建、学习率调整。你以为只是加卡实际是把整个并行体系重新编排了一遍。有一次做扩容实验从64卡扩到128卡理想情况吞吐应该接近翻倍结果只涨了30%甚至出现部分算子比扩容前更慢的诡异现象。后来逐层排查才发现新增的64张卡和原有的卡在物理机架上跨了网段通信走低速链路直接把通信占比从8%拉到了30%。硬件资源到位了物理拓扑条件不到位扩卡就是花钱买罪受。这类问题的难处在于日志里没有“错误”一切指标都是正常的只有性能不符合预期。框架工程师的价值就是能在这种“说不出哪里坏了”的混乱状态里找到那根最碍事的线头。4. AI Infra的完整拼图数据流水线、稳定性与成本账算子开发和分布式框架是最吸引人的部分但AI Infra团队真正的日常大头常常落在最不性感的三个地方数据管道、集群调度、稳定性值守。这些工作像下水管道平时看不见堵了才知道要命。4.1 数据管道GPU再快也怕“断粮”训练数据流水线的重要性经常被低估到离谱。很多模型团队第一次跑大规模训练以为GPU利用率跑到99%就说明系统高效了。真正的AI Infra工程师会告诉你那99%里有多少时间是在空转等数据才是问题的关键。GPU就是个吃得很快的消化系统喂饭速度跟不上它只能干瞪眼。传统的数据读取方式是CPU先从磁盘读数据解压、预处理、做随机增强然后才能送给GPU。如果数据读取和预处理是同步进行的抱歉GPU的利用率能掉到50%以下。业界标准解法是异步预取加多级缓冲用独立的CPU进程提前把下一批数据读好、处理干净放在缓冲队列里GPU算完当前这一批下一批立刻顶上。另外样本数据如果事先做了格式改写和重排让读取跨度变小IO效率还能翻倍。有一段时间我们的数据存储方案特别不合理一个1TB规模的数据集零散分布在上万个碎片文件里训练时每读完一个batch都要发生多次随机小IO。把这些数据重写成连续的大块文件之后读取速度提升了近五倍训练端到端吞吐涨了将近40%。没人改任何模型代码也没换任何硬件就改了数据摆放方式。这类优化在AI Infra里就是常规操作。4.2 集群调度GPU稀缺时代的排队经济学训练算力昂贵集群里的上千张卡不可能只跑一个任务。不同团队有不同业务线、不同优先级怎么分配GPU资源就成了一个复杂的编排问题。调度系统要处理的核心矛盾是任务来的时间不固定、要的资源大小不固定、训练时长不固定但物理卡总数是固定的。这就像机场调度飞机起降既不能让跑道闲着也不能让航班互相撞车。调度系统要决定优先级、排队顺序、资源碎片整理还要防止高优任务堵死低优任务。更麻烦的是资源碎片问题。假设集群里有100张卡任务A申请了40张任务B申请了40张剩下20张。一个需要64张卡的任务C无论如何排不进来这20张在地上躺到天荒地老也建不了机。调度系统需要支持一批任务“打包”分布在碎片资源上或者提供任务迁移机制把碎片动态重组。有一次我们上线了新版本的调度策略没做足够灰度就全量发布结果因为新策略对任务亲和性的判断有误导致某些任务被打散到通信拓扑很差的卡上训练速度直接掉了30%。挨了一整天的投诉之后长记性了调度系统做的任何改动都要先在低风险任务上跑满一轮验证再逐渐扩大范围。调度层的错误往往不是进程崩溃而是让所有人变慢的慢性毒药。4.3 稳定性值守寻找训练日志里的“第一根稻草”AI Infra团队最考验功力的场景是训练过程中的异常排查。训练任务动辄跑几天几周中途某个节点loss突然飙到无限大、吞吐突然下降、某张卡默默开始报错——这些都是值班工程师的午夜噩梦。有一次训练在第八天出现了loss变成NaN的现象表面看起来像训练不稳定。排查过程大致是这样第一步把NaN出现前最近一次正常checkpoint拉出来验证模型本身是否正常收敛第二步从正常checkpoint恢复训练在干净环境下单独重放确认问题是否可复现——如果复现路径清晰说明是数据或环境问题第三步扫描训练日志里所有worker节点是否有异常比如某张卡温度过高、某条网络链路丢包率上升甚至某条存储路径的IO延迟抖动。最终真相是我完全没预想到的某个数据预处理脚本在处理一个边缘case时返回了空张量这个空张量顺着数据流进入了一个算子把一个局部梯度炸成了NaN。这类问题模型团队从算法层面看一百遍也看不出毛病因为问题发生在工程细节里。但AI Infra团队的价值就在这里——我们不负责写模型我们负责守护模型训练过程中的每一层工程防线。排查完成后做两件事第一在数据入口处加校验规则让空张量在进入训练管道前就被拦下第二把这次排查的时间线、判断依据、修复手段写成一份完整复盘文档下次任何人遇到同类现象照着文档走一遍能省三小时。4.4 成本账一个小优化如何省下一年的算力预算最后说说AI Infra最容易被业务线记住的贡献省成本。大模型训练的算力开支说白了一分一秒都在烧钱。每一张卡每小时都对应着真金白银的成本一个训练任务占几百张卡跑十几天成本是普通人无法想象的天文数字。算一笔简单的账假设集群中有100张卡满负荷训练一周每张卡每小时成本按某个量级算一周下来的总成本就很吓人了。如果AI Infra团队通过优化让训练吞吐提升5%——注意只有5%——意味着同样的训练时间缩短了一大截。放到年维度看可能给公司省下一整年的算力预算。这就是为什么很多公司对AI Infra岗位的投入如此果断这个团队做的一次性能优化回报率远超烧在算法调参上的钱。我还记得一个特别简单的优化案例某次训练任务里日志系统每个step都同步flush一次磁盘部分worker因为日志写入慢拖慢了整个训练步长。改成异步写入、批量flush之后端到端训练吞吐直接提升了5%一行模型代码没改。这种“小小的优化”看起来不起眼但做成十次、二十次系统的整体效率就在不知不觉中甩开了别人一大截。5. 入局AI Infra的路径与几项容易被低估的能力聊完这些人在忙什么肯定有人会问那我也想往这个方向走应该学什么、从哪里开始练手最后我用一些实际经验给一张相对务实的路径图。5.1 这个方向需要什么基础从体系结构到CUDAAI Infra是个“地基型”岗位技术栈铺得很宽。最核心的知识底座是计算机体系结构和操作系统你必须理解CPU怎么执行指令、缓存怎么做层级管理、内存带宽和计算吞吐的关系、GPU这种并行加速器的执行模型。不懂这些看性能数据就像看天书。然后是并行计算和网络的基础。要理解分布式系统里的一致性问题、通信模型、同步与异步的区别还要知道真实网络里的带宽和延迟概念。做框架层工作这部分是逃不掉的。最后就是在实际加速卡上写内核的能力。掌握一种加速卡的编程模型和性能分析方法论能从profiler报告里看出访存瓶颈还是计算瓶颈。这些能力都不需要你立刻精通但至少要能在排查问题时一路往下钻从应用层到框架层再到驱动层和硬件特性。5.2 从三个由浅入深的小项目开始练手纸上谈兵没用AI Infra能力必须靠动手练。我建议按顺序做三个难度递增的小项目每一步都能积攒可迁移的经验。第一个项目写一个自定义融合算子。选一个简单的计算模式比如把两个相邻的逐元素算子融合成一个内核对比融合前后的耗时差异。做完这个你就算入门了“访存优化”和“内核开发”的门道。第二个项目做一次分布式通信基准测试。搭一个几卡的小实验环境跑一下AllReduce通信基准观察不同消息大小下的带宽和延迟。再对比单机多卡与跨机通信的差异。做完这个你对“通信墙”会有非常直观的体感。第三个项目搭建一套端到端训练编排。写出一个能提交训练任务、监控状态、自动失败重启的小调度系统哪怕功能粗糙也要跑通闭环。做完这个你对AI Infra全流程的理解就立体了。这三个项目做完你至少已经积累了“亲手踩坑”的原始经验。这些经验也许不够让你立刻成为专家但足够让你在面试、协作、诊断问题时不至于对着一个profiler报告发呆。5.3 被低估的三项能力防守式开发、文档复盘的职业习惯、灰度意识最后一个部分谈点通常没人讲但极其重要的软性能力。AI Infra做的都是底层基础设施一个错误可能影响整个组织的训练任务所以这个岗位特别考验“防守意识”。第一项能力叫防守式开发永远假设自己的修改会出问题。上线前先想清楚最坏情况是什么能不能在5分钟内回滚灰度范围怎么控制。宁可慢一点也要保证爆炸半径最小。第二项能力是文档和复盘。AI Infra的故障往往跨系统、跨团队口口相传没意义。每次疑难杂症解决后写一份时间线回溯文档把触发条件、判断依据、修复方案写清楚。这些东西是你和团队最值钱的资产。第三项能力是沟通和预期管理。AI Infra团队是服务型团队需求方多优先级难定容易陷入谁的活都得接的局面。做这个岗位要习惯用数据和事实沟通讲清楚“这个优化能带来多少收益”“那个风险概率有多高”而不是凭感觉拍脑袋。5.4 我的一点个人体会我在AI Infra方向待了一些年头最大的体会是这个领域几乎天天在“看不见的地方”做事情。你优化的一个算子别人根本不知道它的存在你守护的一次训练未必有人记得是谁保证它没中断你设计的调度策略永远只有在出问题时才会被想起。但恰恰是这些看不见的部分决定了一个大模型是真能高效训练还是卡死在物理极限里。那种“系统稳稳跑完一次训练检查点成功保存指标平稳收敛”的感觉是任何浮夸的PPT都无法替代的满足感。如果你也喜欢这种踏踏实实和物理世界打交道、在底层做出真实价值的工作AI Infra值得认真一试。
