不夸张地讲AI Infra 这个短语过去两年几乎占据了我所有技术浏览记录里的大半壁江山。但说实话这词儿看起来唬人拆开看就是个大杂烩从机房里的 GPU 裸金属到上层跑模型的推理服务中间隔着的散热、供电、网络、调度、分布式框架、指标监控、成本账单全都能塞进“AI Infra”这六个字母里。我自己的学习过程就是典型的“东一榔头西一棒槌”今天看两篇分布式训练的文章明天查几个推理引擎的文档后天又跟人争论 RDMA 和 TCP 的差别。结果就是笔记攒了一大堆脑子里的图始终是碎的。花了很长时间把知识串成一张网之后我才意识到AI Infra 根本不是某个具体技术而是一整套“让大规模模型能稳定跑起来”的工程体系。这篇文章就是我把这一整套体系整理出来的全景笔记主要讲清楚每一层在解决什么问题、各层之间怎么咬合也会穿插一些我自己踩过的坑。适合刚接触大模型工程化、想系统建立 AI Infra 知识框架的人做算法但总被基础设施问题缠住的人也应该能从这里找到一些线索。1. 先搞清楚 AI Infra 到底在解决什么问题1.1 三种最常见的困境先说个实在的观察。很多人一开始接触 AI Infra是带着具体问题来的训练跑到一半卡住不动了GPU 利用率上不去模型部署之后响应太慢账单一个月比一个月吓人。这些问题表面上看各不相同但往深了挖底层原因往往就三类。第一类是算力规模上去了但系统撑不住。单机单卡时代程序跑起来就完事了。但到了大模型时代模型参数动辄几十亿上百亿一张卡根本放不下你得把模型拆开、把数据分片、让几百上千张卡协同工作。这个“协同”的过程需要网络传输梯度、需要同步参数、需要调度任务、需要处理某张卡突然故障的情况。任何一环设计得不够好整体效率就会被拖垮。第二类是资源利用率低到让人心疼。GPU 很贵但在真实集群里平均利用率能够稳定跑到 50% 以上就已经算不错了。为什么会这样可能是数据加载太慢导致 GPU 空转可能是调度策略不合理导致资源碎片化也可能是推理服务在非高峰期根本没什么请求但实例照样占着资源。第三类是复杂度爆炸靠人肉运维已经搞不定了。几十台机器的时候手工配环境还勉强能接受。上千台机器、每天几十个训练任务、多种框架并行跑的时候环境冲突、依赖管理、版本兼容这些问题就会成倍放大。没有一套自动化的资源管理和交付体系基本寸步难行。1.2 用“食堂”来理解分层架构我后来想明白一件事AI Infra 的分层思路跟一个大型食堂的后厨管理非常像。食堂里最重要的是厨师也就是算力通常是 GPU。厨师越多理论上能做的菜越多。但光有厨师没用你得有食材、有灶台、有传菜的通道、有排队的机制。食材是数据灶台是存储和内存传菜通道就是网络排队机制是任务调度。而这套系统里最容易被忽略的角色是“食堂经理”——也就是调度系统它决定哪道菜先做、哪个厨师现在干什么、某个灶台坏了之后怎么把订单重新分配。把 AI Infra 拆解成这张图之后再去看任何一个具体技术点思路就清晰了很多。比如做分布式训练的多卡通信优化本质上是想让传菜通道更快更通畅做 KV Cache 管理本质上是想让厨师在重复做同样的菜时少花时间。每一层都在解决某一种具体的“卡脖子”问题而把这些层串起来的那条主线就是资源效率和系统稳定性。1.3 为什么算法视角看不够我自己一开始也犯过这个毛病总觉得把模型写好、把 loss 调好事情就结束了。但真正把模型放到集群上去跑才发现那只是万里长征的第一步。模型只定义了“计算逻辑”而 AI Infra 关心的是“计算效率”。同样是跑一个 70B 的模型在一个设计得当的集群上可能只需要几十小时在一个组织混乱的集群上可能跑几周都跑不完。差别在哪就在于并行策略怎么选、网络拓扑怎么规划、数据加载怎么优化、故障恢复怎么做。这些事算法岗的同学不一定会接触到但恰恰是整个大模型落地最花时间、也最考验工程能力的地方。2. 算力层从一张卡到一万张卡2.1 GPU 不只是“显存更大”学习 AI Infra绕不开的第一个硬知识就是 GPU 本身。很多人对 GPU 的理解停留在“显存大、算力强”但真要评估一张卡能不能用来训练某个模型至少要看三个指标算力FLOPS、显存容量和带宽、显存与计算之间的平衡。先说算力。FP16 下的 FLOPS 是训练最常用的参考值但要注意厂商宣传的往往是稀疏算力实际跑模型用到的基本都是稠密算力。这里有个容易被忽略的点算力利用率并不是天然的。比如一张 A 系列级别的卡理论 FLOPS 很高但如果你的小算子太多、内存访问太频繁实际能跑出来的 FLOPS 可能只有理论值的 30% 到 50%。再说显存。对于训练来说模型参数、梯度、优化器状态都要占显存尤其像 Adam 这类优化器要额外存动量和方差。这样算下来就算模型本身是 10GB 的参数实际训练时可能要吃掉 60GB 以上的显存。这就要求你不仅要看模型多大还要看训练框架怎么管理显存比如碎片整理、显存复用、激活重计算这些技术都是为了把有限的显存盘活。2.2 集群化之后冒出来的新问题单卡用得再熟到了集群层面还是会遇到几个让人头疼的新问题。第一个是故障率。很多人没概念一个上千卡规模的集群每天有几张卡出故障是非常正常的事。卡坏了不可怕可怕的是训练任务没有容错机制一张卡挂了整个任务就得从头跑。所以现在主流的训练框架都会做阶段性保存检查点Checkpoint定期把训练状态存下来出故障后从上个检查点恢复。检查点本身的存储和恢复速度也成了一个专门的优化方向。第二个是异构问题。真实集群里很少有一批卡全是同一种型号。不同型号的卡算力不同、显存不同、通信带宽也不同让它们协同工作就需要更精细的调度策略。比如把性能高的卡分给计算量大的并行组或者用通信量不同的并行策略去匹配不同的卡间拓扑。第三个是散热和功耗。GPU 高负载运行时发热量惊人机柜的散热设计、电力的冗余度、甚至机房本身的物理位置都会影响系统稳定性。我做过的性能测试里就有因为机房温度偏高导致 GPU 降频、训练速度显著变慢的情况。基础设施层面的“物理约束”是需要团队里有人持续盯着的。2.3 从裸金属走向容器化和资源池化早期做 AI 训练大家习惯直接申请几台裸金属服务器SSH 登录上去装环境。现在看起来这种方式在规模化场景下基本不可持续。环境不一致、复现困难、资源利用率低是裸金属方式的三大痛点。容器化最典型的是基于 K8s 的体系带来的第一个好处是环境一致性。把依赖、代码、运行环境都打包进镜像以后开发环境和训练环境的差异降到最低。第二个好处是资源隔离和配额管理每个任务申请多少卡、多少内存、多少显存都可以通过声明式配置来管理这给后面的调度和自动化打下了基础。但容器化也不是银弹。K8s 原生的调度器在设计之初并没有深入考虑 GPU 这种特殊资源比如显存的调度、GPU 之间的拓扑亲和性、二进制算子的兼容性这些都需要做深度改造。现在业界有很多基于 K8s 扩展出来的 AI 调度方案核心思路都是把 GPU 看成一种可切分、可组合、有拓扑属性的资源来管理。3. 分布式训练的核心并行策略不是选择题而是组合题3.1 数据并行与梯度同步如果有人问你分布式训练的第一步是什么大概率是数据并行。思路很直观每个 GPU 上都放一份完整的模型副本把训练数据切成多个批次分给不同 GPU大家各自算梯度再汇总梯度更新模型。数据并行好理解但有一个关键约束梯度同步。每个 GPU 算完自己的梯度之后必须把梯度聚合在一起得到全局梯度才能同步更新模型。这个聚合动作需要频繁的通信。模型越大梯度张量越大通信的开销就越不可忽视。这时候就需要集合通信库来帮忙了。以业界最常用的库为例它对 All-Reduce 这类集合通信操作做了大量优化用带宽最优的环状算法、把通信和计算重叠起来、根据卡间拓扑选择不同的通信路径。我在实践中发现很多人训练慢不是模型写得不好而是集合通信的配置没对准实际拓扑导致原本可以跑满的带宽只用了零头。3.2 张量并行、流水线并行与序列并行当模型大到一张卡放不下时就需要把模型本身拆开这就是模型并行。张量并行的思路是把一层网络的计算拆分到多张卡上。比如一个矩阵乘法可以按行切成几块、按列切成几块分给不同 GPU 协同算完。这个策略通信频率很高每一层计算都要做一次合并所以一般不跨机部署只是在同一台机器内用高带宽连接来完成。流水线并行不拆层内的计算而是把模型按层切段不同 GPU 负责不同层。数据像流水线一样一层算完传给下一层。这种方案通信量相对小但会出现“流水线气泡”——前一个 batch 还没传到下一段后面的人只能等待。为了减少气泡业界普遍用多微批次的策略把一个 batch 切成更小的 micro-batch让流水线尽量保持满负荷。序列并行的出现主要针对长序列场景。处理超长文本时注意力计算的中间结果特别占显存于是把序列维度也切开分发到多张卡上。它和张量并行经常搭配使用两者可以说是一对好搭档。3.3 混合并行怎么组合框架怎么支持真实训练场景里很少只用一种并行策略。比较常见的组合方式是数据并行 流水线并行 张量并行。数据并行处理多个数据批次流水线并行处理模型分层张量并行处理层内拆分各司其职。但并行策略的数量是有限制的。比如一个模型被切分的路数太多每张卡上的计算量变小通信占比反而提升效率会下降。到底选多少路数据并行、多少路张量并行、多少层流水线通常取决于两个因素模型结构的情况以及集群的卡间拓扑。我的经验是一定要先做小规模实验验证通信开销再向大规模扩展别一上来就全开。这些并行策略要能组合起来用分布式训练框架的作用就体现出来了。好的框架会把这些策略抽象成声明式的配置让用户通过几个参数就能组合出适合自己模型的并行方案。4. 能让一万张卡真正跑起来的是网络4.1 从传统以太网到 RDMA分布式训练对网络的要求很直接既要带宽大又要延迟低还要在拥塞时稳定。训练任务每迭代一步就要做一轮梯度聚合。如果网络吞吐不够GPU 算得再快也只能等数据。传统以太网在这种高吞吐、低延迟场景下会碰到瓶颈。不仅带宽受限通信的内核协议栈开销带来的延迟也不小。于是高性能计算领域很早就引入了 RDMA远程直接内存访问。RDMA 最核心的改变是绕过操作系统内核让数据可以在网卡和应用程序内存之间直接传输大幅降低延迟和 CPU 开销。4.2 两种主流方案怎么选现在搭建 AI 集群高性能网络基本是两大路线一种是专为高性能计算设计的专用网络方案另一种是基于以太网改造的 RoCE 方案。从实际部署看专用网络方案在性能和稳定性上一向表现突出但成本高、生态相对封闭RoCE 方案可以复用现有以太网设备成本友好得多但对网络配置和调优的要求更高。选择哪条路本质上是个取舍问题。如果你的业务是大规模训练为主、对稳定性要求极高、预算充足专用网络方案值得考虑。如果集群规模中等、希望兼顾成本和灵活性RoCE 方案更务实。我见过不少踩坑案例都是在 RoCE 方案下没做好无损网络的配置结果拥塞一多训练性能直接跌到不可用。4.3 集合通信与拓扑感知网络基础设施搭好之后真正决定通信性能的是集合通信库怎么利用这套网络。比如 NCCL 这类库在执行 All-Reduce 时并不是随便把数据发给所有机器而是会构建一个合理的通信拓扑把数据切分到不同链路上去传输尽量跑满全网带宽。集群的网络拓扑也对通信策略影响很大。跨交换机通信和同一交换机内通信的带宽往往差一个量级。如果集合通信的进程分派没有考虑这一点可能大量通信都走了昂贵的跨交换机链路性能自然上不去。现在主流的集合通信库都支持拓扑感知初始化尽量让通信量大的进程组落在同一交换机内或者至少让通信路径尽量短。4.4 训练和推理对网络的需求不一样这里有个容易被忽略的点训练和推理的通信模式很不一样。训练是周期性的、大规模的梯度同步属于高带宽、持续性的流量。推理则更多是请求级别的调度比如把请求分发到不同的 GPU 实例上需要的是低延迟、低抖动带宽需求不一定很高。所以一个精心设计的集群网络往往是分区的训练区用高带宽方案推理区用低延迟方案存储区再单独规划访问带宽。混在一起用容易互相干扰。我自己就有过一次经历数据加载任务把训练网络的带宽吃掉了大半结果训练速度肉眼可见下滑。后来把存储流量和训练流量做了网络隔离问题才解决。5. 推理与服务的工程细节5.1 KV Cache 和连续批处理大模型推理和传统推理不一样它是自回归式的一个 token 一个 token 往外蹦每个新 token 都要看之前所有 token 的信息。为了避免重复计算历史 token 的注意力推理引擎会把这些历史信息缓存下来这个缓存就是 KV Cache。KV Cache 很吃显存而且它的增长模式是先分配固定大小的块如果预先分配得过多显存就大量浪费如果不够又要频繁重新分配影响性能。业界目前比较主流的方法是类似分页管理的思路把 KV Cache 切成固定大小的块不连续也不要求紧挨着需要多少就分配多少。这有点像操作系统里的内存分页能明显减少碎片浪费。光有 KV Cache 还不够推理服务的吞吐量还依赖一个关键机制连续批处理。这个机制允许同一批请求各自处在生成的不同阶段有的正在生成第 1 个 token有的已经生成到第 20 个它们被统一调度谁需要计算就喂给 GPU。这样就避免了传统批处理“等待最慢请求结束”的问题GPU 利用率也会高出不少。5.2 部署形态的取舍弹性与服务等级模型的推理部署不是“一个服务挂上去就行”。按场景不同有几种典型形态。第一种是常驻服务。典型配置是固定数量的 GPU 实例常驻请求来了直接响应。好处是延迟低坏处是负载波动时要么浪费资源要么响应不过来。第二种是弹性伸缩服务。根据流量自动扩缩实例数。这里最大的挑战是冷启动问题新实例拉起后模型权重加载需要时间如果流量突发扩容的实例还没加载完模型流量已经堆积了。解决思路包括预先加载模型快照、预留一部分“热实例”作为缓冲等。第三种是 Serverless 形态。用户不感知实例的存在平台根据请求动态调用 GPU 资源。这种形态对平台的调度能力要求最高但用户体感最好按调用次数计费也比较灵活。选型思路我认为应该看两个点一个是业务对延迟的容忍度另一个是流量的波动幅度。延迟敏感且流量稳定的场景常驻服务更稳妥流量波动大、任务能容忍一定排队延迟的场景弹性方案更划算。5.3 推理性能看哪些指标做推理服务性能优化至少要把这几个指标刻在脑子里TTFT首 token 延迟用户发出请求到收到第一个 token 的时间。它极大影响交互体验。主要取决于模型大小、KV Cache 命中情况、调度等待时间。TPOT每输出一个 token 的时间生成阶段每个 token 的平均耗时。决定生成速度受显存带宽和批处理大小影响最大。吞吐量单位时间能处理的请求数或生成的 token 数。批量大小调大能让吞吐变高但单请求延迟也会涨这是一个 trade-off。我在实际调优中观察到一个规律单纯把 batch size 拉大吞吐能上去但 TTFT 和 TPOT 都会变差。真正的优化目标应该是找到“单位成本下满足延迟约束的最大吞吐量”而不是无脑跑到显存上限。6. 资源、成本与治理被低估的第四维度6.1 资源利用率为什么老是上不去很多团队算力买了、框架也上了但一看 GPU 利用率就想哭。我总结下来利用率上不去主要有三个原因。第一是数据加载瓶颈。GPU 算得飞快但如果数据从磁盘读到内存的速度跟不上GPU 就只能空转。这也是为什么数据流水线、混合缓存、预取这些技术那么重要。第二是调度碎片化。一个训练任务申请了 8 张卡但此时集群里只剩 6 张空闲剩下 2 张被另一个任务占着。这时候任务只能排队而那 6 张卡就白白空着。好的调度器应该能处理这种动态分配场景比如抢占、迁移、分时复用。第三是资源预留过度。很多团队为了不让任务因为资源不够而失败会故意多申请一些资源。结果就是大量 GPU 处于空闲状态但被“占着茅坑”。这种情况需要通过更完善的配额机制和成本意识来改善。6.2 调度策略背后的经济学调度本质上是个经济学问题。不同的任务优先级不同、可容忍的等待时间不同、消耗的资源不同调度器要做的是在有限资源上让整体收益最大化。常用的手段包括优先级队列、抢占式调度和分时复用。优先级高的任务可以占用更多资源甚至可以抢占低优先级任务的资源但需要有保护机制避免低优先级任务一直得不到机会。分时复用则是在多个任务之间轮流使用 GPU适合训练任务不饱和、推理请求波动大的场景。这里有一点值得强调调度策略再怎么优化最终还是要落在成本上。GPU 利用率高不代表成本就低。成本控制还需要做资源计量和账单归属让每个团队能看到自己的资源消耗和费用才有动力去优化自己的任务效率。6.3 可观测性没有数据就没有优化很多时候利用率上不去、性能有问题不是不想优化而是根本看不到问题在哪。AI Infra 的可观测性建设至少要覆盖三层。第一层是物理资源层GPU 温度、功耗、显存占用、网络吞吐、磁盘 IO。这一层数据可以直接用监控方案采集到。第二层是框架层训练作业的吞吐量、迭代速度、计算与通信重叠情况、梯度聚合的耗时分布。这些需要从训练框架内部埋点才能得到属于比较高级的观测能力。第三层是业务层推理服务的 TTFT、TPOT、请求失败率、排队等待时长以及训练任务从提交到开始运行的时间。把这三层数据放在一个视图里才能准确定位问题发生在哪一层。比如用户反馈推理变慢你得先看是服务层排队变长还是下层 GPU 资源被训练任务挤占了还是网络带宽出现了瓶颈。7. 学习路径与避坑建议7.1 我推荐的学习顺序如果让我重新来一遍我会按照“先能用再看懂再能调再能设计”的顺序来推进。第一阶段先把模型跑起来。找一个小规模模型在单机多卡上跑通分布式训练感受一下多卡和单卡的区别体会一下梯度同步带来的通信开销。第二阶段理解关键组件的原理。重点搞明白分布式训练并行策略的选择逻辑、集合通信的核心机制、数据流水线的运作方式。这个阶段可以不写代码但一定要看框架的架构设计文档。第三阶段尝试自己调优。把 GPU 利用率从 30% 调到 70% 以上过程中排查数据加载、通信瓶颈、资源碎片各类问题。这些排查经验非常宝贵可以说是 AI Infra 从业者最核心的竞争力。第四阶段从集群视角看问题。这时候再去读调度、网络拓扑、资源治理相关的内容就会有完全不同的感受。你不再只是优化一个任务而是在设计一套系统。7.2 必须亲手做的事看再多的文档不动手基本都是白搭。有几个实验我强烈建议自己做一遍。第一亲手部署一个训练任务观察不同 batch size 对训练吞吐和显存占用的影响。你会发现显存不仅跟模型大小有关还跟 batch size 带来的中间激活有强关系。第二亲手制造一次通信瓶颈。比如用一个小模型在两张卡上做分布式训练故意把集合通信库的拓扑配置弄错观察训练速度下降的幅度。这个实验会让你体会到通信配置的重要性比读十篇文章都有用。第三亲手压测一个推理服务。不断调整 batch size 和并发数看 TTFT 和吞吐怎么变化找到性能曲线的拐点。这种“手感”是面试和实战里都特别加分的经验。7.3 常见的认知误区最后说几个我踩过之后才明白的误区。第一个误区是“先把模型做好基础设施后面再说”。事实是基础设施的问题通常会反过来决定你能做什么样的模型、跑多大规模的数据。模型算法和基础设施要一起设计。第二个误区是“贵的就是对的”。很多团队一上来就买最贵的机器但网络配置不调、并行策略不选好再贵的机器也跑不出性能。与其盲目堆硬件不如先花时间把现有资源的潜力挖出来。第三个误区是“监控就是可观测性”。装个监控面板能看见 CPU 和 GPU 使用率离真正的可观测性还很远。你更需要关注的是任务层面的指标比如训练吞吐、通信重叠效率、队列时间这些才能真正指导优化。第四个误区是“自动化调度就能解决所有问题”。调度器只是个策略执行者策略本身要人去设计。什么时候该抢占、哪些任务该排队、资源碎片化到什么程度需要整合这些判断需要经验积累。我自己最大的体会是AI Infra 这片林子很大但核心还是平衡——平衡性能与成本平衡延时与吞吐平衡自动化与可控性。刚入门的时候很容易被某个具体技术带跑但站远一点看每个技术点最终都是为这两个字服务的效率。把这根主线握在手里学什么都有方向做什么都有抓手。