前阵子和一位刚入行的算法工程师聊天他说自己费了好大劲把模型代码写好、调通、跑出结果结果转头一看训练账单差点没背过气——同样的模型结构别人跑完只要十天他跑了快一个月GPU利用率还没过一半。他问我你们搞AI Infra的人到底在忙什么为什么同样的卡、同样的模型差距能这么大这个问题问得特别好。因为大多数人看到的是模型效果排行榜上的数字、Demo演示里的流畅对话却很少有人关注支撑这些效果背后的计算系统。算子融合、显存优化、分布式并行、推理加速这些词听起来离普通开发者很远但它们恰恰决定了你的模型能不能训练出来、训练一次烧多少钱、上线后并发来了扛不扛得住。这篇文章就聊聊大模型时代“AI Infra”这群人到底在做什么为什么他们的工作常被忽略却又无比重要。不管你是算法工程师、在校学生还是想转做AI基础架构的开发者希望这篇内容能帮你理解大模型“背后”的技术栈也算给想入行的人画一张粗略的地图。1. 从“算子”说起为什么大模型离不开它1.1 算子是什么先讲清楚“算子”这个词翻译自Operator在深度学习里它指的是一个基础的计算单元。卷积、矩阵乘、ReLU激活、LayerNorm、Softmax全都是算子。你写模型的时候用的那些torch.matmul、F.softmax、nn.Linear底层执行的就是一个又一个算子。大模型为什么对算子特别敏感因为规模。BERT时代模型参数一个亿GPT-3到了一千多亿现在更大规模模型也不罕见了。参数量上去了计算量也跟着暴涨。而计算量暴涨之后你随便用一个基础算子去执行性能可能差出一倍甚至更多。举个例子矩阵乘法。同样是一个A B直接调一个通用实现和经过精心调优的实现在A100上的吞吐能差好几倍。原因在于GPU是个高度并行的处理器你如果不能让它的计算单元和显存带宽都吃饱算力就白白浪费了。1.2 算子和AI Infra到底什么关系“AI Infra”这个词英文全称是AI Infrastructure中文可以说“AI基础设施”。它覆盖的范畴包括芯片驱动、编译优化、训练框架、分布式调度、推理引擎、数据管道、集群运维等等。本质上它是让AI模型“跑得快、跑得稳、跑得省”的那层技术底座。而算子是这层底座里最小也最核心的积木。不夸张地说一个训练任务或者推理服务最终快不快很大程度上取决于算子层处理得好不好。你优化一百个算子每个快10%整体性能可能就翻倍你只优化一个关键算子在某些场景下甚至也能带来显著的端到端收益。所以做AI Infra的人干的第一件大事就是跟算子死磕。1.3 算子优化的常见思路纯PyTorch怎么写大家都会。但到了AI Infra工程师手里他们还会做以下几件事算子融合把多个算子的计算步骤合并减少读写显存的次数。一个典型的例子是FlashAttention。它把Attention里的矩阵乘法、Softmax、Dropout融合到一起还通过分块计算避免把完整的注意力矩阵驻留在显存里既省显存又变快。手写CUDA Kernel针对某些固定shape的算子绕过框架直接用CUDA写一套针对性的实现性能往往能远超通用库。选择更优的数学库路径同样是矩阵乘cuBLAS里有多种算法可供选择有些更快有些不稳定需要根据shape和硬件选。更细的还会涉及到MMA指令、Tensor Core利用率之类的东西。编译器自动优化通过编译手段做自动融合、自动向量化代表技术有TorchInductor、Triton等让开发者写Python也能拿到接近手写CUDA的性能。提示算子优化是有优先级的。别一上手就优化所有算子先做性能剖析找出消耗时间最长的几个热点把热点的性能提上去再谈别的。2. AI Infra拆解大模型背后到底有几层活2.1 训练侧把模型练出来是门系统工程训练一个超大模型绝不是“一台GPU服务器插上电开跑”那么简单。你至少要解决以下几个层面的问题数据管道训练数据要经过清洗、去重、分词、打batch然后喂给GPU。这个环节看起来简单但一旦数据供给速度跟不上GPU消费速度GPU就在空转整个训练成本会显著上升。做AI Infra的人会把数据加载、预处理、缓存、分布式样本分发做成一条流水线确保每张卡都能“不断粮”。分布式训练框架单卡放不下模型怎么办多卡一起训练梯度怎么同步模型参数分片放还是每卡放一套这些问题由分布式训练框架来解决。常见的并行策略有数据并行、张量并行、流水线并行、序列并行。大模型训练通常不只是用其中一种而是多种策略混着用。选什么组合、每张卡分多少层、切分点在哪都需要根据模型结构、集群拓扑、显存大小反复试和调。训练稳定性大模型训练一跑就是几十天其中任何一步出现显存溢出、通信超时、反传梯度异常都可能让整个任务崩溃。AI Infra团队要做的就是加各种“护栏”定时存checkpoint、监控loss曲线、自动告警、异常自动重启。不然你就等着半夜被电话从床上叫起来吧——这是过来人的真实体验。2.2 推理侧让模型好用又省钱模型训练出来只是第一步真正让用户能用上推理侧的挑战一点也不少。推理和训练不一样。训练是海量数据跑很多遍但推理是用户来一个请求你要快速给一个回答。对延迟极其敏感尤其对话场景用户等待超过两秒体验就会明显变差。推理侧的核心工作包括模型压缩量化、剪枝、蒸馏把模型变小变快。最常用的是量化比如把FP16换成INT8在某些硬件上速度能翻一倍显存还能降一半。KV Cache管理生成每个token都要用到之前所有的Key和Value这些缓存怎么存、什么时候清、怎么复用直接影响推理吞吐。并行解码策略比如连续批处理Continuous Batching让同一个GPU上同时跑多个用户的请求动态调度谁先算谁后算这样GPU利用率会比“攒够一个batch再一起算”高很多。在线服务框架把模型包装成高可用的服务承担流量路由、负载均衡、扩容缩容的职责。2.3 集群调度让资源不浪费公司里GPU是稀缺资源。算法工程师提了个需求说要40张卡跑两周。AI Infra团队得去协调集群里现在有多少卡是空的哪些节点网络有问题任务排队排多久调度策略怎么定能保证既不饿死小任务也不让大任务等太久这个问题有点像一个多租户系统。好的调度器能根据任务优先级、资源配额、当前集群负载自动分配GPU还支持弹性伸缩。遇到优先级更高的任务该抢占就抢占但得保证被抢占的任务能恢复不能白白浪费之前的训练进度。3. 这群人每天都在忙什么一个典型工作日实录写了这么多抽象概念我来还原一下一个AI Infra工程师的日常。这样你能更直观地感受到他们到底在“忙什么”。3.1 早上的第一件事看告警AI Infra团队一般都有On-Call机制。早上第一件事是看告警平台昨晚有没有任务因为OOM挂掉哪台机器掉线了某个推理服务的P99延迟是不是飙了别小看这一步。大模型训练任务跑了一周结果因为某张显卡的显存被其他任务占用中途崩掉重跑成本非常高。AI Infra团队做的事情之一就是把这类风险提前拦截掉或者在出事后快速恢复。3.2 白天的主旋律性能分析和排障一个算法工程师过来说“我的训练速度上不去也不知道是数据的问题还是代码的问题。”这时候AI Infra的人会做profile分析——看一下GPU利用率是多少、数据加载有没有卡点、通信占比高不高。通常查完之后发现问题不在模型代码本身而在“木桶效应”的某个短板比如机器之间用的是千兆网梯度同步在通信上浪费了太多时间。这种问题从算法同学的视角很难发现但AI Infra同学一眼就看到瓶颈了。3.3 下午经常是优化一个算子某个算子慢会直接影响线上推理服务的吞吐量。优化它的步骤大致是先用Nsight或PyTorch Profiler定位热点再查看底层汇编或Tensor Core使用情况然后尝试改实现方式。有时会写Triton Kernel有时直接写CUDA Kernel然后在特定硬件上调优。这个过程可能持续几天。性能调优这种事付出的时间不少收益也直观——一个热门算子的优化往往能让整个服务少用一半的GPU卡省下的成本非常可观。3.4 傍晚可能会做评审架构方案大模型发展速度太快GPU型号也在换。新的训练框架要不要引入推理引擎要不要升级这些决策都需要做技术选型和架构评审。AI Infra的人要给出对比数据场景是什么、利弊是什么、迁移要花多少人力、老系统怎么平滑过渡。所以这个岗位不只是“写代码”还要做判断、做规划、做跨团队协调。专业技能之外沟通表达和优先级判断能力同样重要。4. 训练、推理、调度的几个关键参数与选择逻辑讲了这么多“大面上的事”下面选几个实操中的细节聊一聊这些往往才是决定你从“能用”到“好用”的差距所在。4.1 显存不够怎么办混合精度训练与显存估算大模型显存占用大头包括模型参数、梯度、优化器状态、中间激活值。以7B模型为例单精度FP32训练时13B模型都未必放得下一张80G的卡。所以训练几乎必须用混合精度。混合精度下模型参数和梯度用FP16或BF16存储优化器状态用FP32显存占用比FP32省一半还多。补充一个简单估算公式——大批量混合精度下7B模型单卡显存需求约为参数量乘以16到20字节。7B模型约需要112GB到140GB显存单卡A100放不下所以必须配分布式并行。这也是为什么“显存估算”是AI Infra的基本功。4.2 通信开销不能忽略网络选型分布式训练中梯度要跨卡聚合通信量非常大。如果GPU之间走PCIe速度上限可能在16GB/s左右换成NVLink能到几百GB/s跨机器走InfiniBand或RoCE速度又不一样了。举个例子数据并行训练中每轮梯度同步的通信量等于模型参数量乘2再乘4字节。7B模型就是56GB的通信量100Gbps的网络下一秒钟都未必传完一轮。所以规模一大分布式并行策略必须兼顾通信量。张量并行通信频率高但数据量小适合机器内部用NVLink流水线并行通信频率低但单次数据量大适合走更高速的跨机网络。4.3 推理引擎怎么选吞吐优先还是延迟优先推理服务分两种场景在线交互和离线批量。在线交互要求首字延迟低通常用TensorRT-LLM或vLLM这类优化引擎配合各种PagedAttention技巧离线批量任务更在意吞吐量可以适当放宽延迟要求用更大的batch把GPU塞满把单位时间的处理量拉上去。我见过一些团队的踩坑案例一上来就追求极致的首字延迟结果吞吐量上不去GPU一片一片地闲着成本高得吓人。后来调整思路按场景分流对延迟敏感的用户走低延迟专用副本对延迟不敏感的走大batch高吞吐服务整体资源占用反而下来一大截。4.4 一个容易被忽视的指标有效算力利用率很多人看GPU利用率是看nvidia-smi显示的百分比。但这其实只是“显存和计算单元有没有在动”不直接代表算力利用效率。两个任务GPU利用率都是90%实际吞吐可能差一倍。更靠谱的指标是MFUModel FLOPs Utilization模型实际算力除以硬件理论峰值算力。业界比较优秀的训练任务MFU能到40%到50%但大多数没调过的任务MFU只有20%甚至更低。AI Infra的工作很大一部分就是在拉高这个数字。5. 从零上手AI Infra想进这个方向需要补什么5.1 硬件与系统基础AI Infra绕不开底层的硬件知识。CPU、GPU、显存、NVLink、PCIe、RDMA网络每个组件的原理、性能特征、瓶颈位置都要大致清楚。一个完全不了解硬件特性的工程师在排查性能问题时往往无从下手。要补这方面知识可以多看硬件白皮书和实测文章自己试着跑一些benchmark比如用不同算子在不同硬件上的耗时对比直观感受“什么样的工作负载在什么样的硬件上会快”。5.2 系统与并行知识分布式训练最核心的四个并行策略——数据并行、张量并行、流水线并行、序列并行——一定要吃透。建议先把原理搞清楚再用框架手动跑一个小模型分别用不同并行方式去分词、分配、聚合看训练速度和显存变化。很多训练框架的文档和示例代码都适合作为入门材料。5.3 代码能力C和CUDA要不要学如果目标是做算子优化、推理引擎这类偏底层的工作C和CUDA基本上是躲不开的。至少要能读懂CUDA代码能自己写一个简单的Kernel理解线程块、共享内存、同步这些概念。如果目标是做训练平台、资源调度这类偏集群侧的工作那更看重的是工程编码能力尤其是Go或Python以及Kubernetes、容器、监控系统这些基础设施组件的使用经验。5.4 从“用”到“造”的几个练习我自己给新人推荐过一套入门路线第一步用PyTorch训练一个小的CV模型监控训练全过程的GPU利用率和显存变化第二步改成分布式训练对比不同并行策略的效果差异第三步对线上模型做量化压缩压到原来四分之一精度看精度和速度变化第四步尝试用Triton写一个融合算子替换掉某个PyTorch自带算子测性能提升多少。这四个练习做完大概率能判断自己更喜欢哪一块算子方向、并行方向、还是推理方向。6. 常见误区和踩坑实录6.1 误区一算子优化就是要手写CUDA我见过不少新人上来就想写非常复杂的Kernel结果效能不升反降。实际上很多算子的性能瓶颈在显存带宽不在计算本身。此时核心思路是减少数据搬运次数和增加访存局部性不一定非用手写CUDA。Triton、TorchInductor这些高层工具往往已经能给你带来不错的收益手写CUDA应该是最后手段而不是第一步。6.2 误区二四条并行策略一起上并行策略每多一层通信开销和工程复杂度都会上升。能数据并行解决的就不上张量并行能训得动就别强行流水线并行。多个并行维度一起上时调试复杂度可能指数级上升到后期排错的时间比训练本身还长。6.3 误区三追求单卡极致性能忽视端到端成本有一种倾向是花大量时间把某个核心算子性能调到极致但端到端效果甚微。正确的做法是先用profiler抓出全部的耗时分布把时间花在占比最高的几个热点上。记住性能优化永远是“木桶效应”先补齐短板再考虑加长板。6.4 踩坑实录存储和网络也会成为瓶颈有一次我帮一个团队排查离线推理慢的问题。GPU利用率不高算子也没问题最后发现是存储系统扛不住高并发读取GPU全部在等数据。搞AI Infra经常要把视野从GPU本身移开看看CPU、内存、硬盘、网络任何一环都可能成为瓶颈。还有一个高频坑跨机通信时没有设置好网络拓扑感知。训练任务里的通信调度依赖于节点间网络结构如果框架不知道两张卡其实不在同一个交换机下多走一层网络转发延迟就可能明显增加。7. 把视野拉高一点AI Infra的技术趋势与个人思考7.1 大模型时代AI Infra发生了什么变化以前的深度学习框架大家关心的是易用性调API、写模型训练流程相对简单。大模型出现后模型规模和集群规模同时暴涨单机训练问题变成了大规模分布式系统问题AI Infra的重心也随之转移。一个明显趋势是系统设计正在跟模型结构绑定。为了优化大规模Transformer的训练与推理开发者对Attention、MoE这些特定结构的优化越来越多。算子融合、KV Cache管理、投机解码、推测解码这类系统级优化正在成为通用基础设施的一部分。在业界这意味着AI Infra工程师不能只懂系统还要对模型结构敏感。好的AI Infra工程师往往能读懂模型论文也能从模型结构里预判性能瓶颈。7.2 开源生态的助推作用整个AI Infra方向的快速成长很大程度上靠开源生态。比如PyTorch本身、分布式通信框架、推理引擎、各种CUDA Kernel仓库都有大量高质量源码可以学习。对于想入行的人来说读优秀开源代码可能比读教科书更有用。我自己的习惯是遇到一个性能问题先去搜业界有没有开源实现。别人在公司里踩过坑、把性能调到很优的代码是会说话的。在开源社区里提问、看issue、刷PR能学到很多文档里没有的经验也能建立一个行业人脉网络。7.3 一个常常被忽略的能力成本意识AI Infra工作的终极目标不只是“快”还有“省”。GPU资源不便宜同样的业务别人用100张卡你用120张卡一年下来差别不小。所以AI Infra工程师做方案的时候一定要会算账。算账不复杂模型训练一次需要多少GPU卡时成本是多少换成更优的并行方案能节省多少卡时要付出多少人力成本。这个投入产出比如果算不明白方案在老板那里基本通不过。AI Infra岗位之所以吃香恰恰是因为它在“技术”和“成本”之间搭了座桥。7.4 AI Infra会不会被自动化替代很多人担心随着工具越来越智能未来是不是不需要专门的AI Infra工程师了。我的看法是工具会越来越强但系统的复杂度也在持续提升。你可以用一句话让推理引擎自动调优但出了问题、到了瓶颈还是需要懂原理的人去解决。更何况模型结构一直推陈出新新结构往往带来新的性能特征和新的优化空间。只要模型还在发展AI Infra就不会消失只会水涨船高。8. 给想转型做AI Infra的人几句踩过坑之后的实在话模型本身是“看得见的成果”而AI Infra像是“看不见的地基”。说实话有时候会觉得自己的工作不如算法同学那么有成就感——你没有发布模型没有做Demo但你的工作一旦做不好整个系统就崩了。所以做AI Infra的人要有长期主义的心态能坐冷板凳。如果说有什么建议给想入行的人我会说三件事一是把底层原理学扎实哪怕现在用不上未来也会用到二是一定要动手做实验纸面推演一百遍不如跑一个benchmark三是多跟做模型的同学交流——你以为的“性能问题”在对方眼里可能是“产品需求问题”只有理解了真实的业务场景才能把技术用在刀刃上。大模型这股浪潮给AI领域带来了巨大的关注度而AI Infra是这股浪潮底下那个看不见的发动机。希望这篇内容能帮你看清这个方向的全貌也能给正在考虑入行的你提供一张还算靠谱的路线图。