从算子到AI Infra大模型背后看不见的那群人在忙什么先说个近期让我挺有感触的现场。某次大模型上线前夜算法同学反馈推理延迟暴涨模型在线上卡死了一分多钟。业务方急着要结论算法列了一堆怀疑对象从模型权重到推理参数都翻了个遍。最后排查下来问题出在GPU显存碎片化导致的算子申请显存超时而不是模型本身。这事情让我想到一个被反复提起但很少被真正讲透的话题在算法工程师写好网络结构、数据管道跑通、Loss正常下降这些看得见的里程碑背后到底是谁在保证这一切真的能稳定、高效、低成本地跑起来那群人做的事情今天有了个正式的名字——AI InfraAI基础设施。它既不是一个具体岗位也不只是一套工具链而是大模型从实验室能跑走向生产环境能用之间那一整片看不见的土壤。这篇内容不打算讲那种AI Infra很重要的正确废话而是想从一个常被忽略的视角切入算子层面究竟在解决什么问题AI Infra工程师日常到底在忙什么以及为什么说他们是大模型项目里最容易被遗忘、但又最不该被遗忘的角色。这个问题我在不同场合被问过很多次包括团队里的新人、跨部门协作的业务同学甚至一些刚入行的算法工程师。每次回答完我都会觉得这个领域的信息差比想象中大得多。借这篇内容把我观察到的、经历过的、拆解过的东西完整梳理一遍。1. AI Infra到底管什么从能跑到跑得划算中间的所有事很多人第一次接触AI Infra这个概念是在招聘JD上。搜大模型相关的岗位除了算法工程师、数据工程师频繁出现的还有AI Infra工程师大模型训练框架工程师推理引擎工程师。但点进去看职责描述会发现范围很广有人负责训练框架有人做集群调度有人搞推理优化还有人专门写算子。这些工作彼此关联但又不是同一个方向。所以第一个问题其实是AI Infra的边界到底在哪里我习惯用一个三层模型来理解这件事。最顶层是算法同学最熟悉的深度学习框架层比如PyTorch、MindSpore或者基于它们二次开发的分布式训练框架。中间层是运行引擎和编译优化层包括算子调度、图优化、内存管理、通信优化这类看不见的工作。最底层则是硬件抽象层比如GPU上的CUDA/cuDNN/TensorRT以及各类自研芯片的加速库这一层的工作重点是把算力硬件的能力真正榨出来。对应的AI Infra关注的核心问题也可以拆成三句话第一跑得起来——框架不发生OOM、不崩、不挂第二跑得快——同样的模型用更少的时间训练完同样的请求用更低的延迟返回第三跑得划算——在GPU这么贵的硬件上把每一T算力都花在刀刃上不要出现GPU空转、显存浪费、通信等待这些富贵病。这三句话看着简单每一条背后都有一大堆工程细节。单说跑得起来就不是小事。一条训练作业涉及上百张GPU卡的并行任何一张卡出现故障、任何一个通信链路断开都可能导致整个训练任务中断。算法的同学通常关注的是丢了多少个step需要恢复而Infra同学关注的是如何做到故障自动感知、任务自动拉起、断点自动续训让不可控的分布式故障尽量变成无感的偶发事件。再看跑得快。同样一个Transformer模块算法模型定了之后性能差距可能有几倍甚至一个数量级来源就在于算子的实现、kernel的融合程度、显存访问的通路、通信拓扑的设计是否合理。这些工作在模型代码的commit里看不出区别但会直接反映在训练速度和推理成本上。最后是跑得划算。做过大规模训练的人都有体验GPU集群的利用率不是靠口号喊上去的。它依赖的是细粒度的资源分配、动态的弹性伸缩、空闲资源的利旧调度甚至要给不同优先级的任务做合理抢占。AI Infra在这层的工作很多时候像是在经营一家算力酒店——既要把每间房都住满又不能因为超售导致客人打架。所以回到AI Infra包含什么这个问题我的答案很朴素所有让模型训练、模型推理、算力集群运转得更稳定、更高效、更省钱的工程技术都属于AI Infra的范畴。它不是一个固定职位名称而是一个能力集合。这也是为什么这个领域的人背景五花八门有做高性能计算的有做分布式系统的有搞编译器出身的也有从算法转工程转过来的。补充一个个人观察这个领域和普通软件工程最大的区别在于它的用户不是面对人类操作者而是面对算法代码和模型本身。用户体验好不好要看GPU的利用率曲线是否平滑、训练日志里是否有频繁的warning、推理服务的P99延迟是否达标。这种目标让AI Infra工程师的工作方式非常硬核——不好凭感觉全部看数据。2. 为什么算子是理解整个AI Infra体系的钥匙如果要在这个庞大的体系里挑一个最原子的东西那就是算子。这个词对不搞底层的人来说有点抽象。我举个例子神经网络本质上是数学运算的组合加法、乘法、矩阵乘、卷积、归一化、激活函数每个基础运算在底层实现里的实体就叫做算子。PyTorch里你调用的torch.matmul背后对应的就是CUDA里的一个算子实现。大模型训练里90%以上的计算量都可以归结为大量算子的反复调用和组合执行。理解了算子的定位之后算子优化的意义就显而易见了。一张GPU卡的算力是固定的比如A100的FP16算力是312 TFLOPS但实际能跑到多少取决于算子能不能把这个理论峰值发挥出来。如果算子的实现效率只有30%那么一台8卡的机器实际你相当于只用了不到3张卡。算子优化里最常见的手段是算子融合Kernel Fusion。传统上一个深度学习模型的计算图里每个算子都会被单独执行矩阵乘算完把中间结果写进显存接着ReLU算子从显存读出来算完再写回后面如果还有别的操作继续重复读写。这个过程的瓶颈早就不是计算本身而是显存读写。GPU的计算速度比显存带宽速度快得多大量时间都耗在数据在算子和显存之间搬运上。算子融合的思路就是把多个算子合并成一个kernel让数据尽量留在片上寄存器或共享内存里完成整条链路计算避免反复访问全局显存。举一个最典型的融合案例把矩阵乘、偏置添加、激活函数融合成一个算子在算子内部完成全流程。这个看似简单的改动性能收益往往在2到3倍以上。训练和推理里常用的folded normalization把归一化层的参数在推理时预先折叠进卷积或全连接层也是类似思维不过那个更偏图优化层面。另一个大方向是算子实现本身的调优。以矩阵乘为例要在GPU上写出一个快的矩阵乘算子需要用到分块Tiling、向量化加载Vectorized Load、共享内存乒乓缓冲Double Buffering、寄存器重组Register Rotation、指令级流水Instruction Pipeline等一整套技巧。很多工程师刚开始看高性能计算的代码会觉得这不就是在堆砌各种奇技淫巧吗但真正深入之后会发现每一个看起来繁琐的细节背后都是对硬件架构的深刻理解。Tensor Core的使用又是一个经典话题。从Volta架构开始NVIDIA GPU上引入了Tensor Core这种专门为AI计算设计的硬件单元它的矩阵乘算力远超普通CUDA Core。但问题是Tensor Core对数据类型和数据排布有特殊要求开发者需要手动保证数据以特定格式放在显存里或者使用特定的指令来调用它。很多做算子的人核心工作之一就是把各种业务算子的计算抠成Tensor Core能高效执行的形态。举一个比较新鲜的具体案例FlashAttention系列。这个工作为什么在业界引发这么大的震动因为它彻底改变了注意力机制算子在GPU上的执行方式。传统实现需要把完整的注意力矩阵尤其是在长序列场景下写进显存再反复读取显存开销和访存延迟都非常高。FlashAttention的核心思路是把注意力计算分块让每个计算块尽量在SRAM片上高速缓存里完成整个softmax计算过程论文里只用了一个很简单的数学技巧在线上softmax计算过程中维护关键的统计量从而在不牺牲精度的情况下彻底解决访存瓶颈。这个工作带给业界的启发不只是注意力算子本身而是大家都意识到算子层面的创新空间远没有被挖掘干净。很多之前被认为框架已经写好了没法再快的模块其实都有再优化甚至重构的可能性。如果说上面这些还停留在把算子的计算速度提上去那么算子工程还有一个同样重要的维度内存。GPU显存是有限的而大模型的参数、梯度、中间激活都是显存大户。算子工程师需要关注每个算子运行时占用多少临时显存、这些显存的生命周期有多长、能否复用。经常出现的情况是一个算子本身的算力优化已经很到位但因为临时缓冲申请频繁导致显存碎片化进而拖慢整个过程甚至诱发OOM。很多线上事故的根因最后都定位到某几个算子的显存占用模式上。在深度学习编译器领域Triton、MLIR、TVM这些工具之所以被重视本质上是想把算子优化的经验从手写CUDA代码变成半自动或自动化的编译优化。但这并不意味着手写kernel的工作会消失。现实情况是对于固定的、高频的、计算量集中的大算子——比如矩阵乘、卷积、FlashAttention这种级别的重操作——手写或者精细调优过的实现依旧是最优解编译器在自动融合和通用场景优化上更有优势。两者是互补关系。我给新人的建议通常是不要只盯着怎么写一个快的kernel要从系统角度理解算子在整条链路上的位置。算得快但数据喂不过来没用单个算子算得快但kernel间切换又引入巨大的调度开销总体还是慢。能看清楚瓶颈到底在算力、带宽、还是延迟比埋头优化一个算子要重要得多。3. AI Infra工程师的日常训练、推理、集群三条线各忙什么聊完了算子这个微观视角再拉回到更宏观的工作场景。一个AI Infra团队通常会有三条工作线训练、推理、集群与资源调度。每条线面对的挑战不一样日常画风也差别很大。训练这条线忙的是让大模型能高效地训练出来。算法同学更多关心模型结构改了什么、数据怎么喂、收敛效果怎么样而训练侧的Infra工程师关心的是用ZeRO、FSDP这类分布式策略把参数切分到多卡上时通信开销是否可接受梯度同步用All-Reduce还是Reduce-Scatter更划算序列长度变化时显存能不能稳住checkpoint保存和恢复机制是否足够可靠。训练卡片久了会有一种强烈的感觉分布式训练这件事7分在通信3分在算力。GPU算得快但卡间通信带宽和同步延迟很容易成为瓶颈。几百张卡一起训练每几个step就要同步一次梯度任何一张卡的慢同步都会拖慢整体节奏这就是木桶效应的极致体现。通信开销是训练优化里最值得花功夫的点。以一个192卡规模的训练任务为例计算梯度后的AllReduce通信数据量约为模型参数量的2倍前向和反向各一份梯度实际还有额外开销每周期的通信时间与网络拓扑、带宽、通信库实现直接相关。如果在通信实现上做压缩、分层、int8量化或者在流水线并行阶段合理切分省下来的时间非常可观。另外当模型规模大到单卡装不下时张量并行、流水线并行、数据并行如何组合搭配也是训练工程师的日常课题。张量并行把网络层切到多卡上流水线并行按层做切分数据并行则复制模型各自训练。这三者各有各的通信模式和显存特性组合起来状况又完全不同。关键不是选一个“最先进”的方案而是根据模型结构、集群拓扑、显存预算找出综合开销最小的一种组合。推理这条线忙的是让训练好的模型在服务场景里跑得又快又稳。它和训练的感受很不一样训练追求的是一个能持续压满GPU的吞吐推理面对的则是动态变化的在线请求需要同时关注延迟、吞吐和成本。推理优化里几个常见手段我简单列一下模型量化FP16转INT8甚至更低精度用精度换速度但要做好校准避免大幅掉点、KV Cache优化通过缓存历史token的key和value来避免重复计算但KV Cache内存管理是否高效直接决定服务能支持多长的上下文并发、动态批处理把不同时刻到达的token请求动态拼到一个batch里提升GPU利用率和整体吞吐。除此之外Continuous Batching、PagedAttention这类技术本质上都是在显存布局上做文章把稀疏的KV占用变成可管理的物理分页从而大幅提升长上下文场景下的批处理效率。各家推理引擎在这块的白热化竞争真的是把推理优化这件事推向了一个新的高度。深度学习编译器也是在这个阶段被大量使用把性能优化经验固化到自动调优流程里。不过现实情况是编译器对于稳定的、结构固定的模型优化效果很好但模型的迭代速度快、结构频繁变化时真正压轴靠的还是针对高频模块做的定制化手工优化。所以推理侧的Infra工程师常常会面临一个经典选择题这版模型又快上线了是直接用现成引擎开箱即用、省事但性能可能差两成还是花几天换一个定制实现、省GPU但要多花人力在这个领域不一定存在绝对正确的答案多数时候是在算力成本与人力成本之间做取舍。集群与调度这条线忙的是底层物理资源的分配与容量管理。这个岗位的气质和前两者差异很大它更像是传统的运维平台工程但又被GPU的特殊性框定了边界。GPU是异构、昂贵、容易故障的设备用量大而且任务类型多样离线训练任务、在线推理服务、临时跑实验的Job、数据预处理的CPU任务它们的资源需求和优先级都不同。调度器的设计既要做合理的优先级策略又要做业务容器的动态伸缩还得考虑任务之间的干扰和资源碎片的问题。这里有一个容易被忽略的细节GPU显存和算力是绑定关系。调度的核心对象实际上是整卡但因为单卡显存有限例如80GB一台8卡机器上不同进程共享资源时会互相干扰显存和算力利用频率很难完全解耦。任务调度时如果两张卡上的进程申请了虚拟显存但实际每个step的算力需求波动很大就会形成有人占了茅坑不拉屎、其他人排队憋着的尴尬局面。所以集群调度做得好的团队往往会搞一整套算力画像系统用历史数据预测每个任务在每个step的显存需求与计算密度再决定怎么排布最划算。我接触到的很多AI Infra工程师都有一种共性他们不直接产出模型指标但他们产出的系统每一个数字都直接决定模型能不能在预算范围内按期落地。这种角色不显眼但一旦出问题影响范围往往是全局的。4. 从会调包到会造轮子算子工程的实操方法论上面聊了很多面上的东西接下来说点点上的。算子工程这个方向算是AI Infra里最硬核、也最适合作为技术切入点去积累经验的子领域。如果一个人是算法背景想往AI Infra转从算子优化入手是最有效的路径因为它的反馈闭环最短写完一个算子立刻能测出快还是慢不需要等整个分布式系统跑起来。算子工程的基本功首先是能看懂性能profiling数据。很多新人拿到一个慢算子第一反应是我猜瓶颈在共享内存冲突。这是错误姿势。正确的做法是先用量化工具看清楚这个算子的理论计算量是多少实际耗时多少访存量多大计算能否被访存掩盖得到profiling数据之后再针对性地分析瓶颈是算力受限Compute Bound还是访存受限Memory Bound还是延迟受限Latency Bound。打个比方这就跟医生看病一样先做检查、拿指标再开药方。没有数据支撑的优化都是玄学。我自己经历过的例子一个看起来计算量巨大的算子一profiling发现实际算力利用率只有个位数绝大部分时间都在等显存数据。这时候优化的方向就不再是抠指令而是精简访存路径可能顺手把某个中间结果的算子融合进来性能直接翻倍。第二个基本功是理解并善用硬件的存储层级。GPU的存储体系从快到慢大体是寄存器、共享内存Shared Memory、L1/L2 Cache、全局显存Global Memory和主机端内存。这是整个算子优化最底层的物理约束。所有高性能kernel的设计核心逻辑都可以归纳为一句话让最频繁访问的数据待在最快的地方。这就是为什么矩阵乘要分块Tiling——因为分块之后每个计算块的数据可以被搬到共享内存里反复复用而不是每次计算都去访问全局显存。第三个基本功是把这些优化变成一看便知的直觉。比如看到一个大矩阵乘第一反应是维度多大、切片方式哪种合适、用不用Tensor Core、要不要double buffering做流水。看到elementwise运算的kernel第一反应是访存带宽是不是瓶颈能不能把一连串elementwise算子融合成一个pass。看到convolution就得考虑有没有Winograd变换空间或者能不能转化成矩阵乘im2colGEMM。这些直觉不是天生的是需要大量阅读、动手实验、复盘踩坑慢慢养成的。实操层面我给一个通用的优化流程参考这也是我自己带新人时会用的SOP先用profiling工具NVIDIA Nsight Compute / nsys等拿到算子热点和瓶颈类型确定方向。这步占整个任务20%的时间但决定80%的效果。确认优化目标是让单个算子变快还是消除它在整条链路里的瓶颈影响两者解法常常不同。写一个基础版本Baseline跑出初始数据明确时间基准。按访存优化→计算优化→并行度优化→指令级优化的顺序迭代先保证数据流合理再谈计算密度最后才抠指令细节。每做一步优化立刻跑基准测试记录变化。优化没有做着看这个说法每一步都要有数值回报。最后验证正确性拿优化后的算子输出与标准实现做数值对比设置合理的误差阈值例如fp32下余弦相似度0.9999且最大绝对误差在可接受范围。这部分在训练链路里尤其重要很多优化翻车的事故都发生在验证不充分的环节。再补充一点关于取舍思维。算子优化很忌讳追求没有瓶颈的状态。GPU上很多算子的瓶颈是物理不可消除的——访存带宽再优化也不能突破硬件极限计算密度再高也不能让FP16卡跑出FP8的速度。所以做算子优化的目标不是完美而是在当前约束下找到最合适的工作点。比如一个算子在线上跑得快和它在离线benchmark里跑得快可能要求就不一样。线上要考虑占用率是否影响多路并行推理离线则可以更极限地占满一张卡。理解需求边界比理解硬件手册更关键。5. 大模型时代AI Infra的头号命题为什么是可观测性如果说前几年大家关注AI Infra的重点是怎么把性能调上去那近一年来我最大的感受是怎么把系统看明白正在变成一个比调快更紧迫的命题。这背后有个很直接的原因大模型的训练和推理链路复杂度已经超出了任何单个人靠直觉就能掌控的范围。训练一条千亿参数模型涉及上千张卡、几十个分布式并行策略的组合、TB级别的数据流、持续数周到数月的运行周期。任何一个环节出问题都可能导致训练中断或者产出一份看起来正常但其实悄悄变差的模型。可观测性要解决的问题不仅仅是出问题时找到根因而是在问题发生之前发出预警在问题潜伏期就把线索暴露出来。类似这样显存碎片化的比例是不是在持续上升某张卡的通信时长是不是比其他卡高了几个毫秒梯度范数是不是突然出现尖刺这些信号单独看都不是故障但合并在一起往往是更大问题的先行指标。在工程上可观测性通常包含三大支柱日志、指标、链路追踪。这三者在AI Infra场景里有完全不同于传统后端的形态。日志这块训练任务的日志量极其恐怖——每秒钟每个进程都会有训练日志输出如何采样、如何聚合、如何建立关键事件的告警规则需要专门设计。指标这块除了常规的CPU/内存/网络还要重点盯GPU利用率、显存使用量、Tensor Core活跃度、NVLink通信带宽、PCIe吞吐等一系列定制化指标。链路追踪则要覆盖一个数据batch从加载到完成一次反向传播的完整生命周期知道它经过了哪些算子、每个算子耗时多久、在哪个阶段产生了阻塞。具体落地时很多团队会做一个训练/推理任务大脑之类的内部平台把某次训练任务的所有数据汇总到一个面板上从集群资源、分布式拓扑、算力利用率、Loss收敛曲线到错误日志全部打通成一条时间线。这样做最大的价值在于缩短mean time to recovery平均恢复时间。以前出问题靠老师傅拍脑袋现在直接看面板定位——是显存不够、通信超时、还是某个算子数值溢出一目了然。传统的debug问题可能半天有了系统化的可观测性可能压缩到一小时内。推理侧的可观测性同样重要只是关注点略有不同。在线服务的核心指标有三个时延分布P50/P99/最大、吞吐量和饱和时的表现行为。推理服务里一个比较隐蔽的坑就是“偶发慢请求”——大部分请求都很快但极小比例的请求会出现几百毫秒甚至秒级延迟拉高整体P99。这种问题的根因经常不是模型本身而是底层某个资源竞争或内核调度抖动。如果观测系统只做平均值统计这类问题完全会淹没在数据里。所以做推理可观测性的底线要求是要有分位数统计和长尾请求的追踪能力。最后说一个从实践里得到的教训可观测性建设最大的敌人不是技术门槛而是上线了但没有被用起来。很多时候系统做了面板也有了但算法同学不习惯看Infra同学又只盯着自己那一段数据在内部分裂问题跨团队定位时依然靠拉群和开会。真正有效的可观测性一定是从用户视角出发的——让算法同学打开面板就能回答我的训练任务现在健康吗而不是让ta花一小时学习怎么看懂一项指标。把系统做傻瓜化比把系统做功能丰富重要得多。6. AI Infra工程师的自我修养做那个消失但必要的角色聊完技术再聊聊人。标题里说看不见的那群人这个状态其实是AI Infra工程师的日常事情做成了是算法的功劳因为模型指标又涨了事情搞砸了是Infra的锅因为训练断了、服务慢了、卡吐了。长期处在这种语境里人多少会有点心态上的考验。我有一次和一个做了五年系统工作的朋友聊他说的一句话让我印象很深做Infra的人要接受一个事实——你的成功在大多数时候是无声的。但反过来看AI Infra工程师的成长路径也恰恰得益于这种无声。因为这个岗位迫使你建立系统化思维你看一个问题不能只看单点要看整条链路的平衡不能只看当前要看未来三个月的扩展性不能只看技术还要看成本和资源约束。这种视角的宽度是纯算法岗位短期内很难获得的。从技能储备的角度给想进入这个领域的同学一些参考。下面几条按照重要性排序扎实的计算机系统基础操作系统、内存管理、并发模型、网络协议栈。这些是理解GPU工作方式和分布式系统底层行为的前提绕不过去。并行计算和高性能计算基础了解各类处理器的并行模型学会使用性能分析工具懂一点CUDA或至少跑过相关课程实验能够读懂主流kernel的代码。深度学习框架原理不是停留在调API的层面而是清楚一个张量的数据流是如何在框架里流转的算子是怎么被调度执行的。最好的方式是复现一个最简版的自动微分引擎。分布式系统工程能力包括但不限于容错、一致性、负载均衡、调度策略。大模型训练的基础设施本质就是一个大型分布式系统这套知识是骨架。动手排查问题的野路子能力这可能是最难速成的。它来自大量半夜三更被线上告警叫醒的经历来自一张又一张profile报告的分析来自一次次把不可能的问题最终定位到一个几行代码的bug的成就感。这些经验没法背出来只能在真实的崩溃现场中长出来。也不得不提一个现实问题AI Infra领域的技术栈迭代非常快几乎每半年就有新的优化思路、新的框架版本、新的硬件特性出现。这听起来很累但我反而觉得是一个优势——因为经验壁垒在这个领域没那么容易固化新人如果能保持持续学习的习惯完全可以凭借一股钻研劲儿在比较短的时间内追平甚至超过一些按部就班写了很多年业务的工程师。这个领域不看资历看的是解决问题的底牌够不够硬。最后还想说一点关于职业感受的东西。AI Infra工程师确实常常隐身但这个岗位带来的正反馈出现在另一些时刻比如把一个训练任务从三天压缩到一天半GPU集群的利用率从35%拉到70%推理服务的成本直接下降40%再比如某个深夜线上服务在流量峰值安然度过而你知道它去年的同一时刻正频繁宕机限流。这种我亲手把不可能变成了常规的确认感是支撑很多人持续做下去的核心动力。大模型赛道发展这么快看到越来越多的资源涌向芯片、框架、引擎这些底层方向其实是一件很值得高兴的事情。这说明行业正在从追热点转向做基建。而那些真正在基础设施上日复一日较劲的人也许不会频繁出现在文章头条里但他们扎实做出来的东西会一直承托着上层所有光鲜的模型和产品。如果这篇内容能让你对这些看不见的工作多一分理解或者哪怕只是让你产生一丝要不我也去试试看底层的念头那就很有价值了。