![开头引言] 这几年跟人聊起我的工作最麻烦的就是解释头衔。说自己是“搞AI Infra的”对方大概率会礼貌地点头然后补一句“那你们是不是天天调大模型”。其实不是。我们既不写算法也不怎么发论文日常打交道最多的是显存、带宽、OS、网络拓扑、任务调度器、数据管线还有无数个凌晨三点的告警页面。AI Infra全称叫AI基础设施是介于算法和硬件之间的一层工程体系。算子、框架、分布式训练、推理引擎、集群调度、数据处理、监控预警这些都是它的地盘。学术圈和业务线关注的是模型多强、效果多好而AI Infra关心的是一件事这一切在真实的生产环境里能不能跑得起来跑得够快成本还能不能压下去。这篇文章想帮你看清大模型背后这批人到底在忙什么。我把整个工作拆成五层来讲从最底层的算子到训练框架里的并行策略到推理侧的工程细节再到调度、数据、集群运维这些“看不见的地基”最后聊聊AI Infra工程师的日常边界和真实工作状态。文里的例子大多来自我亲身踩过的坑包括一些具体数字和排查思路希望能让不同背景的读者都有收获。1. 算子一切性能的起点都藏在这一层1.1 什么是“算子”为什么它会成为兵家必争之地所谓算子直接理解就是“一个可执行的计算函数”例如矩阵乘法、卷积、注意力计算都可以算子化。大模型训练的关键路径本质上就是一串算子的串并联。性能好不好第一步就取决于这些算子到底跑多快而不是算法的数学是否完美。这点我印象很深。刚入行那会儿我认为优化模型性能应该是算法工程师的工作后来发现根本不是。模型的Transformer结构再精巧如果它依赖的几个矩阵乘法和注意力算子在GPU上执行效率只有理论峰值的五成那就意味着整个训练吞吐直接打了对折。算法是路线算子是引擎引擎不给力路线再正确也跑不出速度。最典型的例子是矩阵乘法算子GEMM。它对显存带宽的需求不算极端但对计算单元的利用率要求极高。要打满CUDA Core就得处理好数据切分、寄存器调度、访存复用、指令流水线。NV的cuBLAS库做了大量打磨但在很多特定形状和硬件配置下原厂库未必是最优解。我们曾经在某个7B模型的LLaMA类结构上做评测发现一部分小Batch尺寸的场景下手写kernel能比cuBLAS快15%到25%。别小看这个差距放在几千万个token的训练周期里省下的就是几十万元的卡时成本。1.2 GPU算子优化的三个主战场第一是访存优化。GPU算得快但如果数据喂不过来计算单元只能空转这就是常见的“访存密集”问题。比如LayerNorm、激活函数这些元素级算子算术强度非常低拉满算力也用不了多少计算量所以要把重心放在读写合并、向量化访问和尽可能减少冗余搬运上。过去我常用CUDA里常见的手段float4向量化读取、共享内存复用、Grid-Stride循环这些看着“老土”的办法普遍能让访存型算子提速一到两倍。第二是融合。算子的上游结果如果只是为下游提供输入没必要写回显存再读一遍。把两个算子合成一个除了省掉一次访存开销还能减少一次kernel launch的延迟。FlashAttention为什么快除了分块计算降低复杂度更关键的是把attention里的多个碎片计算融合、在线softmax一次算完整条链路上读写全都被压到最低。我做过一个LayerNormResidualDropout三合一融合吞吐提升了大概30%听着数值一般但它是每个step都会运行的基础算子积少成多就厉害了。第三是自动调优。现在的矩阵乘法和卷积需要针对不同的M、N、K形状选不同的分块策略。手动为每一种形状调参不现实所以业界普遍用Auto-tuning在若干预设的tiling大小、流水线阶段数、双缓冲策略之间做benchmark搜索。我常用Triton来实现这类调优它能以接近Python的语法编写高性能GPU kernel实测下来可维护性比手写CUDA强很多。注意算子优化很容易陷入局部最优。如果一个算子已经占了整体运行时间不到2%花两周时把它的效率翻倍在全局看可能毫无意义。正确做法是先做profile用数据说事把时间花在热点算子上。2. 训练框架从单卡到千卡的那一跃2.1 显存是怎么被吃掉的选并行策略前先算这笔账单卡跑不动大模型根本原因是显存太有限。以一张80GB显存的加速卡为例训练一个7B的模型参数本身用FP16存储就要约14GB但这只是开始。优化器状态要额外消耗大量显存Adam状态在混合精度下每个参数大致还需要12到16字节梯度又是一份。这意味着7B模型的常规训练光状态就轻松超过40GB再叠加激活值单卡训练根本放不下。显存是谁吃掉的选并行策略前必须先算清这笔账。这时候并行策略就登场了。数据并行DDP最直觉——每张卡放一份模型和优化器只分数据。但模型一大就放不下。于是出现混合并行最常见的是3D并行张量并行把一层参数拆到多卡流水线并行按层切成多段放到不同设备数据并行在每个副本之间做数据切分。我拿一个经典配置举例8台机器共16卡训7B模型。比较稳的方案是先用2卡做张量并行组内显存共享再在每组内做数据并行。如果你用FSDP那么核心思想是分片参数、梯度、优化器到各卡在forward和backward时按需All-gather回收参数。FSDP的显存占用与数据并行相比可以按卡数线性下降代价是通信量上升。具体怎么权衡取决于集群的NVLink还是InfiniBand拓扑。2.2 通信开销的残酷现实带宽决定了你的上限并行策略讲得再多通信才是关键瓶颈。数据并行每步要AllReduce梯度张量并行在每层前后要AllReduce激活流水线并行需要来回传输中间激活。通信一旦堵住再多计算卡也只是增加排队时间。一次我在200卡集群上做评估单机8卡NVLink很畅通但机间用了较常见的RoCE网络。结果发现只要在数据并行维度上频繁做AllReduce跨机通信把单步耗时拉高了三倍。后来怎么解决的加大Batch size减少通信频率同时在通信计算重叠上做调整把梯度切成若干小块算完一小块就发一小块让通信和计算在时间上交叠最终单步耗时缩回到原来的约1.6倍吞吐提升明显。关于通信的一个核心经验是先去读集群拓扑图再决定并行策略。NVLink带宽可以到几百GB/s但机间网卡通常只有几十GB/s这里差着一个数量级。从不看拓扑就拍脑袋定并行方案的人一定会在峰值训练期付出代价。2.3 训练稳定性挂在Key上的坑永远比挂在loss上的多训练跑崩是AI Infra工程师的日常。常见的问题包括loss变成NaN、loss震荡不降、显存OOM等。很多算法同学看到这些问题会去调学习率、调初始化但其实大概率是底层工程出了问题。我印象最深的是一次7B模型的训练loss在某个step突然变成NaN。查了半天不是数学问题而是某个自定义算子里的中间变量在极端值场景下发生了溢出。后来我们引入了一种折中的检测策略在global_norm和loss层面加监控一旦出现异常就把特征点dump出来送检。工具的健全比背锅的智商更有价值。训练稳定性还有个大坑数据管线的波动会连带影响模型收敛。我见过某团队把数据读取和转换放到了CPU主线程上结果一旦缓存没命中IO抖动就造成每个step间隔相差好几秒。优化数据管线之后训练稳定性和耗时都大幅改观。训练速度不只是kernel的事数据准备链路往往是隐藏瓶颈。3. 推理侧把成本从“论亿计”压到“论万计”的角斗场3.1 推理和训练是完全不同的工程题训练看重吞吐可以容忍较高的Latency但推理是另一套逻辑。面向用户的推理服务关心的是首Token延迟、总延迟、并发承载能力还有最关键的单次请求成本。先说解码方式。最传统的Batch推断是每次走一步decode然后拼接效率很低。现在普遍用连续批处理Continuous Batching把不同请求动态塞进同一个Step里计算GPU的空闲缝隙被填满。我在某个对话模型上实测过同等并发下连续批处理能把QPS拉高数倍而且延迟降低。但连续批处理带来的调度复杂度也上去了请求进出、显存预留、抢占式调度都要精细设计。KV Cache也值得单说。Transformer推理时每个Token的Key和Value都要缓存防止重复计算但它吃显存极快。一次我做7B模型的推理服务压测8卡集群并发1024路请求结果发现KV Cache占了接近一半的显存。于是考虑引入PagedAttention思路把KV Cache分页管理按需分配并允许跨请求复用物理块。这样一改并发容量直接上了个台阶而且显存碎片率下降明显。3.2 量化与投机解码靠工程“赚”时间推理算力瓶颈不像训练那么尖锐但显存带宽往往更致命。每生成一个Token7B模型要把几十亿参数从头到尾读一遍这耗费的是显存带宽。解决思路就是量化用更低精度如INT8或INT4存储权重参数体积缩小访存量同步降低。不过量化不是免费的午餐。INT4会让模型效果明显掉点尤其在小模型上INT8相对安全但也要做Per-token和Per-layer的校准。我试过用GPTQ或AWQ做INT4量化7B模型掉点可控推理速度提升了将近2倍。如果对效果敏感谨慎用INT4最好先做评测集上的纵横对比。另一个有意思的方向是投机解码Speculative Decoding。用一个小模型先草拟一串Token大模型只做验证。因为验证是一个并行过程可以在不牺牲效果的前提下把生成速度拉高1.5到2倍。做投机解码的关键是草稿模型要和目标模型行为足够接近不然收效甚微。3.3 推理服务的高并发与弹性伸缩大模型上线后往往要应对突发的流量变化。推理服务的弹性伸缩比普通Web服务更难因为显存资源是硬约束新副本调度和模型加载都很重。我习惯的做法是准备一个常驻小队承载基本流量再预留一部分空闲节点应对规划内的增长突发流量则依赖排队机制来削峰宁可让用户排队也不能让所有请求互相拖垮延迟。注意推理服务的高并发并不等于越多副本越好。模型常驻内存占据大量显存副本一多GPU内存就是成本大头。我见过公司为了峰值多租了50%的推理节点结果流量波峰过去后闲置一个月账单吓人。弹性伸缩策略必须和业务曲线紧密挂钩细粒度更省钱。4. 看不见的底座数据管线、调度和集群运维4.1 数据是训练质量和稳定性的双重地基AI Infra包含的范围很广但数据管线常被低估。训练不收敛有时候恰恰是数据源出了问题比如预处理顺序混乱、混入重复样本、tokenizer切分后长度分布异常都会直接动摇训练效果。我处理过一次真实事故数据管道里加入了去重逻辑但因为线程安全写错导致一批样本被反复复制大模型在连续数小时内反复“背诵”同一小段语料表现为验证集上的震惊式掉点。排查了很久最后通过给每条样本生成哈希指纹并按序抽样比对才发现数据问题了。数据校验工具和数据版本管理应该是每支训练团队的标配。另外数据管线也需要和训练并行跑。常见架构是数据预处理独立服务化通过分布式缓存和内存缓冲层把处理后的样本直接喂给训练集群。这样训练不用等数据数据生成也不会被打断。4.2 集群调度像操作系统管理进程一样管理层层的训练任务训练集群的调度是整个AI Infra的中枢。Kubernetes价格便宜可及但直接在K8s里跑大规模分布式训练的人都知道Pod启动后卡在一个端口上等对端就绪、任务之间互相抢GPU导致超时等等都是家常便饭。调度器选型需要非常慎重。我个人用过Volcano和Kueue这类面向批处理和公平调度的方案。它们能按队列优先级分配资源并且在深度学习任务依赖关系上做了支持。比如任务排队、抢占恢复、gang scheduling这些特性在普通K8s里很难天然做到。特别是长时间占用资源的大模型训练和突发的轻量级推理服务混跑时没有靠谱的调度策略很容易互相拖垮。4.3 监控与故障自愈白天不觉得坏的时候命都是它给的训练跑到一半节点挂了、网络闪断、PCIe链路修复、显存ECC报错这些都是低频但致命的事故。没有监控和自愈机制就得靠人肉盯屏盯到天亮。失败的代价可能是几天算力全部白费。我们的监控体系基本围绕三个层次节点级温度、功耗、显卡状态、网络丢包率、进程级利用率、Step耗时、loss曲线、显存使用、数据级样本吞吐、队列积压、延迟分布。出现问题要有告警但告警比监控更难。告警必须精准到“什么事情该找谁、紧急程度如何”否则大家天天被噪音打扰真正出事时反而不看了。故障自愈方面我的习惯是把能自动处理的全部自动掉节点异常自动下线并迁移任务训练断点自动触发Checkpoint回滚重跑推理实例崩溃自动拉起新Pod。人的价值在于处理自愈搞不定的事而不是重复点鼠标。5. AI Infra的边界与日常我们到底算什么角色5.1 岗位的边界算法、工程、系统三者挤出来的夹缝AI Infra工程师的定位比较特别。算法工程师关心模型效果平台工程师关心微服务和资源调度AI Infra则是横跨在这两者之间的人。需要看懂模型的架构和分布式训练原理也要熟悉操作系统、虚拟化、网络存储这些经典底层能力。经常有人问AI Infra和SRE有什么区别我的看法是SRE更多是保障现有系统的稳定性与效率AI Infra则要主动去改造框架、优化算子、设计并行策略研究老系统没做过的事情。它更像是算法和系统之间的“翻译官”和“施工队”。5.2 AI Infra工程师的一天一半靠脑子一半靠手感要说日常工作状态可以总结为四件事看监控、试优化、查故障、写工具。早晨确认夜间训练任务是否健康检查loss曲线和集群利用率是否有节点掉线。白天花大量时间做实验换个并行策略对比吞吐调整流水线切分跑一下算子融合的benchmark。遇到线上问题随时进排查模式定位是框架层、网络层还是数据管道。排查过程中多半要和生产集群斗智斗勇操作前备份是底线。剩下的工时用来写内部工具任务提交命令行、监控面板、一键诊断脚本、Checkpoint diff工具等好工具能把团队成员的返工时间一次次省回来。见过很多人觉得AI Infra很“苦”确实苦因为问题集中在训练扑街、延迟飙升、账单爆炸这些危情时刻。但它的乐趣在于每次把一个训练管线从龟速调到接近理论峰值那种“亲手打开性能瓶颈”的满足感非常强。5.3 和算法同学打好配合别只看指标要看需求做AI Infra时间长了最大的成长不是技术而是沟通。算法同学的诉求往往不是“把算子优化到极致”而是“我想验证一个新想法能不能尽快帮我跑起来”。理解了这一点就别上来丢一堆并行策略让他头疼而是该判断哪种方案最贴近他的实验需求先把链路走通再谈优化。提示算法与基建的协作有个很实用的原则——“先稳后快”。一个能跑通但慢的训练管线好过一个只有优化计划但还没落地的管线。很多改进都要等第一个结果出来以后再谈方向。5.4 未来自动驾驶式的基建是团队级的演化方向做久了AI Infra我们的目标会越来越像一个“向往的方向”让训练和推理像用车一样简单——不用关心引擎怎么转、维修什么时候做只需打开车门点火就走。目前我们团队正在做两件事一是把故障自愈能力从“检测和重启”推进到“预防和自动规避”比如在任务调度前自动筛查节点健康度避开有隐患的设备二是把性能优化方法论沉淀为知识库和自动化工具让新来的同学也有机会做出接近资深工程师水平的优化决策。这还不是完全成熟的状态但方向是明确的让底层复杂度向体验转移把维护成本降下去让人更专注于创新本身。做AI Infra最大的魅力就是永远在为“未来更复杂的事情”提前打地基。写到这里回头再看AI Infra这批人其实他们忙的无非四件事让训练更高效让推理更便宜让成本更可控让系统更难挂。因为有了这些人大模型才不只是在论文里跑分亮眼而是真正到了生产手里、变成面对用户的产品。我个人的建议是如果你也想入这行先把算子、框架、网络、存储、调度这些硬功夫搞扎实再刻意练习“站在算法视角看问题”的能力。毕竟这行最缺的从来不是堆机器的操作工而是真正能理解模型与系统两侧语言的工程师。