做 AI 训练和部署这大半年我最大的一个感受是能把模型的 loss 训下去的人很多但能把一张训练卡的算力用好、把几千张卡组织成一个不空转的整体、把推理服务的延迟压进 SLA 的人是另一种稀缺。这个领域有一个很宽泛的名字叫 AI Infra。我最初以为它只是“搭环境、装驱动、调框架”真正深入以后才发现它是一整条从芯片到业务的链路算力硬件、集群网络、资源调度、分布式训练、推理引擎、存储访问、性能剖析……每一环都是独立的深水区。这篇 AI Infra 知识全景学习笔记就是我把这条链路里绕不开的知识点整理成的一份地图式提纲从底层到上层逐层拆解同时把我实际踩过的坑和算过的账一并写出来。无论你是刚要从算法转向工程还是已经在维护训练集群这份笔记都能帮你快速建立起全局坐标系。1. AI Infra 全景认知先给这个领域画张地图1.1 AI Infra 不是什么而是什么很多人有一个惯性思维觉得做 AI 最核心的是模型结构。在大模型出现之前这个想法问题不大单卡训练、单机推理瓶颈主要在算法本身。但到了大模型阶段问题彻底变了模型参数动辄几十 B、上百 B单卡放不下就要切切了就要通信通信就要组网组网就要调度调度就要考虑资源隔离和利用率跑起来还要监控、评测、优化。这一整条链路就是 AI Infra。举一个很直观的例子你向大模型问一个问题表面上只是输入一句文本收到一段回答但背后实际发生了至少四段工作请求进入网关被调度到某个实例实例从存储里读取模型权重和数据GPU 完成数千次矩阵运算中间还要通过网络同步多个设备的计算结果。任何一个环节慢用户感受到的就是“转圈圈”。所以 AI Infra 不是某一台机器或某一个软件而是让“输入-计算-输出”这条链条高效运转的全部工程手段。这也是我把它称为“知识全景”的原因。它不像某个算法可以用一个公式讲清楚而是一个横跨硬件、网络、系统软件、并行计算、服务架构的交叉学科。要理解它必须先有一张地图。1.2 七个层次的知识框架我按自己的理解把 AI Infra 从上到下拆成七个层级。这个分层不一定是标准定义但用来建立知识体系非常顺手层级解决的核心问题典型概念与工具算力硬件层提供计算和显存资源GPU/NPU、HBM 显存、高速互联总线集群网络层让多卡高效交换数据RDMA、拥塞控制、集合通信资源管理层把算力按需分配给多个任务Kubernetes、GPU 虚拟化、调度策略分布式训练层把大模型拆到多卡上训练数据并行、张量并行、流水线并行、ZeRO推理服务层把训练好的模型变成可用服务连续批处理、KV Cache、推理引擎存储与数据层让数据/检查点读写不拖后腿分布式文件系统、缓存、预取可观测与性能层定位瓶颈、优化成本Profiling、利用率监控、成本模型这张表的顺序就是知识依赖的方向。底层决定上层的可能性上层则反过来影响底层的选型。比如你推理引擎的批处理策略直接决定了你要买多少卡你的调度策略又决定了训练任务的利用率。我在学习时的一个心得是不要一上来就扎进分布式训练的源码里而是先按这七个层级各看三篇有分量的文章脑海里有了“哪一环对应什么问题”的索引再往后学效率会高出很多。接下来我会按从底层到上层的顺序把每一层的关键知识点展开讲。2. 算力与集群网络AI Infra 的地基2.1 为什么算力瓶颈不是“算”而是“搬”很多刚接触 AI Infra 的人会以为GPU 越快训练越快。这句话只对了一半。真正决定大模型训练和推理上限的往往不是计算峰值而是数据搬运速度。大模型的两个核心阶段能很清楚地说明这个问题。训练阶段每一轮迭代都要把权重和梯度在显存里来回读写推理阶段自回归生成是逐 token 解码的前一个 token 的结果必须参与后一个 token 的计算本质上是串行的访存密集操作算力的利用率天然受限。我常用一个“食堂打饭”的类比来理解这件事算力就是厨师的炒菜速度显存带宽就是窗口递菜的速度。如果厨师一分钟能炒十盘菜但窗口一分钟只能递出三盘整个食堂的效率就是三盘/分钟。你换一个厨师更强的算力效率依然不变。AI Infra 大量优化的本质都是让“递菜速度”追上“炒菜速度”。实测来看目前主流训练加速卡的显存带宽通常在 2TB/s 到 3TB/s 之间而计算峰值已经到每秒几百甚至上千 TFLOPS。大模型的核心算子基本都是访存密集型很多时候显存带宽直接决定了你的训练吞吐上限。2.2 显存与 I/OHBM 与缓存的作用显存带宽之所以能做到这么高靠的是 HBM高带宽内存技术。HBM 的逻辑和传统 GDDR 显存不一样它通过 3D 堆叠的方式把多个 DRAM 层叠在一起用硅通孔连接从而获得远超平面布线的数据通道宽度。简单说通道更宽一次能并行搬的数据就更多。但 HBM 容量相对有限单卡主流是 80GB 左右。这就是矛盾所在一个 7B 参数的模型光权重用 BF16 存储就要 14GB再加上梯度和 Adam 优化器状态单卡根本装不下。所以必须把模型切到多张卡上切了之后就要通信这就引出了集群网络。在实际调优时还要注意算子库的选择和缓存利用。一个卷积或者矩阵乘法会被拆成很多 tile 放到片上缓存里计算如果 tile 切得不够合理缓存命中率低算力就会被白白浪费。这也是为什么同样的模型有人能跑到高利用率、有人只能跑到一半的原因。我通常在排查一个算子慢的问题时会先去确认是不是显存访问模式问题而不是急着怀疑硬件坏了。2.3 集群网络高速互联、RDMA 与集合通信单机多卡之间目前主流方案是高速 NVLink 全互联或类似的高带宽总线带宽能到数百 GB/s延迟极低。跨节点之间则要用 RDMA 网络如 InfiniBand 或 RoCE带宽通常在 200Gbps 到 400Gbps 级别。注意单位差异节点内是 GB/s跨节点是 Gbps两者有 8 倍的单位换算关系算峰值时很多人会在这一点上被绕晕。有了网络之后就要考虑怎么组织通信。分布式训练中最常见的通信原语是 AllReduce也就是把所有卡的梯度做一个求和再广播给所有卡。业界最常用的集合通信库 NCCL 对这个操作做了大量优化包括分块传输、流水线重叠、拓扑感知等能够把通信量压到接近理论上限。但网络拥塞会成为隐形的杀手。我遇到过一种情况4 机 8 卡训练时明明单卡之间的通信测试带宽都正常整个训练吞吐却只有预期的 60%。排查到最后发现是网络交换机上的拥塞控制策略没有开启多卡并发传输时大量数据包排队丢弃触发重传通信效率被拉低了一个量级。这个坑告诉我AI Infra 的学习不能只停留在代码层交换机配置、网卡参数这些“硬件晦涩区”同样是性能的重要组成部分。3. 资源管理与调度把算力当成稀缺资源对待3.1 从单机到集群为什么 Kubernetes 管理 GPU 这么重要当集群里有几十台机器、每台机器多张卡问题就变成了谁来决定一个训练任务跑到哪张卡上如果只靠人工分配不仅效率低而且容易造成严重的资源碎片。所以绝大多数 AI 集群都会引入 Kubernetes 这类容器编排平台把底层的异构机器抽象成统一的资源池。但 Kubernetes 对 GPU 的管理逻辑很特别。CPU 是用完即释放的而 GPU 一旦被容器独占除非任务结束否则就会一直占用显存和计算资源。所以 GPU 调度不能只看“有没有空闲卡”还要看显存余量、算力配额、是否支持在卡间做紧耦合通信。这就催生了 GPU 虚拟化和分时复用技术比如对物理 GPU 做硬件切分或者在时间片上把一张卡分给多个推理任务从而提升整体利用率。我在实际维护集群时的一个体会是调度的根本目标不是“把任务塞进机器”而是“把任务放到能完成它且让整体利用率最高的位置”。比如两个训练任务分别需要 60GB 和 20GB 显存物理卡是 80GB如果调度器把它们错开放到同一张卡就能省下另一张卡去跑别人如果调度器没有碎片感知能力就会各占一张卡白白浪费 20GB 空间。3.2 调度策略组合优化与权衡资源调度本质上是一个组合优化问题最简单的两类策略是“装箱”Binpack和“打散”Spread。Binpack把任务尽量集中到少数节点上空出整块节点。好处是省电坏处是单点故障影响面大并且把多个大型训练任务放在同一机架可能造成网络拥塞。Spread把任务均匀打散到各个节点。好处是容错性好坏处是容易产生碎片并且训练任务之间的通信可能因为位置分散而变慢。在大规模训练场景通常还要考虑拓扑。同一个训练任务里的多张卡最好落在同一个交换机下最好是一个物理机箱内因为 NVLink 带宽比跨节点网络高一个量级。很多调度器会做拓扑亲和性计算就像订机票时优先安排同航站楼转机一样需要为“通信密集”的任务预留“同一机架”的位置。我踩过一个很典型的坑某团队 A 同学反馈 GPU 利用率只有 30%我看了一下任务分布发现调度器为了“均匀”把一个 8 卡训练任务拆到 8 个不同节点上每张卡之间都通过网络通信。结果模型的张量并行频繁跨节点同步通信开销把计算时间完全吃掉。后来改成把 8 卡全部调度到同一台多卡机器上利用率直接回到 85% 以上。这充分说明调度策略不是拍脑袋决定的必须结合任务的通信模式。3.3 层级调度与排队别让大任务饿死小任务除了位置选择调度还要处理优先级和排队。一个动辄占用上百张卡的大型训练任务如果和小型推理任务混跑可能会长期占据共享资源。比较成熟的调度器会设计两级结构先按优先级和高层策略决定哪一类任务可以进入再在内部做具体的放置。训练任务往往长期霸占推理任务则偏向延迟敏感两者混部实际上是另一个大的研究课题。学习这一层知识我的建议是先把 Kubernetes 的资源模型Requests/Limits和调度器扩展机制看懂再去看主流的 AI 调度器是怎么做 GPU 分配和队列管理的。这里很多经验都无法从文档里学到只能靠真实集群的“性价比”来感知。4. 分布式训练的核心逻辑并行策略与显存优化4.1 单卡装不下四种并行怎么选分布式训练就是解决“模型太大”和“数据太多”两个问题业界形成了四种基本并行策略策略切什么显存收益通信开销适用场景数据并行DP复制模型切数据无每卡都要完整模型每步同步梯度通信量与模型大小成正比单卡能装下模型时张量并行TP切分矩阵运算的维度每卡只存一部分权重每层多次集合通信极高单卡装不下、且节点内高带宽场景流水线并行PP按层切分网络每卡只存部分层通信量小但产生流水线气泡超深网络、跨节点场景序列并行SP切分序列长度维度减少激活值显存依赖注意力机制的重计算长序列场景常与 TP 组合数据并行的逻辑最好理解每张卡复制一份完整模型喂不同的数据算完梯度后在卡间做 AllReduce 求平均再同步更新。它的显存开销最大但通信结构最简单是工程上最容易被框架封装好的选择。张量并行则直接把一个矩阵乘法拆开到多张卡上做比如把权重矩阵按行切给卡 A、按列切给卡 B每张卡只持有模型的一部分。通信频率很高因为它作用于模型内部每一层的计算每处理一个层就要做数据同步。所以张量并行几乎只在高带宽的节点内使用跨节点用张量并行基本是灾难。流水线并行是另一个极端它把几十层网络切成多段每张卡负责一段输入数据像流水线一样经过所有段。通信量小但会产生气泡——即某些卡在等上游输出时是空闲的。这两种策略之间的选择本质上是在“通信成本”和“空闲成本”之间做权衡。4.2 一个必须算的账ZeRO 到底省了什么在真正上多机多卡之前建议先把 ZeRO 这套优化思路搞懂。它解决的问题是即使单卡装不下模型也不一定非要切模型可以把模型状态“分片并行”地放在多张卡上。先算一笔账7B 模型用 BF16 存储是 14GB训练通常需要 FP32 主权重、一阶动量、二阶动量三者加起来每参数 12 字节也就是说优化器状态就要 84GB再加上梯度和权重总量超过 110GB。单卡 80GB 根本放不下。ZeRO 的解决思路是分阶段把状态切到各卡上ZeRO-1只把优化器状态切分到各卡每卡显存从 110GB 降至约 40GBZeRO-2把优化器状态和梯度都切分每卡约 25GBZeRO-3把参数、梯度、优化器状态全部分片每卡约 14GB。代价是通信量上升。ZeRO-3 每一步都需要从别的卡拉取参数通信量大约是数据并行的 1.5 到 2 倍。所以 ZeRO 不是无脑最优而是用一部分通信开销换取显存空间。配置时常用的经验值是先看单卡能不能放下 FP16 权重和梯度放得下就用 ZeRO-2放不下才升到 ZeRO-3。4.3 流水线气泡与微批次调优如果用流水线并行就要立刻面对“气泡”这个概念。假设把模型切成 8 段8 个 stage一次只喂一个 micro-batch那么整条流水线只有第一个 batch 进入时是满负荷后面每个 stage 都是串行执行大量时间在等待上游——这就是气泡。解决办法是引入多个 micro-batch微批次让流水线里的每个 stage 同时都在干活。气泡比例近似等于 (stage 数 - 1) / (micro-batch 数 stage 数 - 1)。stage 越深需要越多 micro-batch 才能填满流水线。我实际调参时会先按这个公式算再结合显存余量决定 micro-batch 数量通常调到气泡占比低于 10% 才会认为参数合理。还有一个容易忽略的点micro-batch 数量增大每张卡上的激活值显存也会增加。所以微批次调优本质上是在“气泡”和“激活显存”之间找平衡。遇到峰值显存 OOM优先减小 micro-batch而不是盲目换并行策略这是成本最低的调整方式。4.4 一个真实的选型场景模拟项目 X给一个具体的决策示例。模拟项目 X 要训练一个 30B 参数的模型集群是 4 台机器、每台 8 张 80GB 卡共 32 卡。BF16 权重 60GB单卡装不下ZeRO-2 可以把优化器状态分片每卡权重 60GB 梯度 60GB 优化器状态约 30GB合计约 150GB算出来其实仍超单卡。这时正确的组合是把模型切成 4 份张量并行并用 ZeRO-2 处理优化器状态。每个 TP 组内用高带宽互联通信组间再通过数据并行同步梯度是典型的“TP ZeRO DP”组合。这种决策树的推导逻辑是先看单卡能否容纳权重和梯度 → 不能则选择 TP 切分 → 再看优化器状态是否超过单卡剩余显存 → 仍超则加 ZeRO-2 → 如果模型层数很深可进一步加入 PP用跨节点连接。整个过程中每一步都涉及显存账和通信账只有把两张账都算清楚才能得到可靠的配置。5. 推理服务层让模型真正跑起来5.1 训练和推理的思路为什么完全不同训练追求的是“吞吐”单位时间处理多少 token、梯度更新多快推理追求的首要是“延迟”用户发出请求到收到第一个 token 要多久。这导致技术选型完全不同。大模型推理可以拆成两个阶段prefill预填充处理用户输入的整段 prompt属于计算密集型GPU 算力利用率很高decode解码阶段逐 token 生成答案属于访存密集型每生成一个 token 都要把当前所有缓存权重读一遍算力利用率通常很低。很多人第一次看到推理卡的 GPU 利用率只有 20% 到 30%就是这个原因不是卡不行而是 decode 阶段天然受带宽限制。这带来一个关键结论推理性能优化的重点是尽量减少 decode 阶段的访存量而不是盲目堆算力。5.2 连续批处理与 KV Cache 管理最早期的推理服务采用静态批处理一批请求同时到达、同时算完、同时离开。这种模式的问题在于decode 阶段批内的每个请求长度不同短的请求会等长的请求大量算力白白浪费。于是出现了连续批处理每个 step 动态地从队列里捞入新请求同时把已经结束的请求移出批次。因为 decode 阶段每个请求只是顺序读取自己的缓存新旧请求可以互相穿插而不干扰所以吞吐能提升数倍。这是目前主流推理引擎的标准做法。还有一个绕不开的概念是 KV Cache。自回归生成时模型需要把之前所有 token 的 Key 和 Value 缓存下来避免每步重新计算。KV Cache 的大小非常惊人以 7B 模型为例每个 token 约产生 0.5MB 缓存4096 token 长度就是 2GB。如果显存只有 80GB留给权重约 14GBKV Cache 能容纳的并发请求数非常有限。主流引擎采用分页管理的方式优化 KV Cache 的显存利用率核心思想是显存按页分配像操作系统虚拟内存一样减少碎片和浪费。这也是我在配置推理服务时最喜欢调的一项它直接决定了并发能力和延迟表现。如果你观察到服务排队严重先别急着加卡看看 KV Cache 的使用率和显存碎片率。5.3 推理引擎的量化与硬件选型有感推理场景还有一个和训练截然不同的点量化技术对性能影响极大。把权重从 FP16 降到 INT8KV Cache 也做量化显存和带宽需求几乎减半decode 吞吐能翻倍。所以推理服务的性能优化往往是从“省内存”入手的。在硬件选型上我学到一个重要指标“算力与带宽比”。如果一款卡算力极高但带宽一般它跑 decode 任务时算力会被严重浪费反之如果带宽高但算力一般反而能在实际推理中表现更好。这个比值可以作为判断推理场景卡型适配度的第一参考就像选车型时不只看马力还要看变速箱匹配。具体的卡型选择我不过多展开因为会牵涉到成本模型建议结合自己的 token 吞吐目标来算。6. 存储、数据与可观测性容易被忽视的隐形成本6.1 检查点与数据读取训练被“饿死”的现象很多团队把精力全放在并行配置上结果 GPU 利用率还是上不去最后发现是磁盘读取慢导致数据供不上。训练任务可以类比成一条生产线GPU 是终端装配工数据加载环节就是原料输送带。输送带一旦断料再快的装配工也只能等。大模型的检查点checkpoint保存非常可怕一个百亿级模型的全量权重和优化器状态可能有数百 GB全靠训练结束一次性写出写盘期间整批 GPU 都要停下来等。常用方案是异步 checkpoint把写盘交给后台线程让训练迭代替换继续进行同时用内存缓存或高性能分布式文件系统避免每次读卡前访问慢速磁盘。我测试过的一个案例里开启异步保存后训练吞吐从每分钟 12 个 step 提升到 19 个 step提升接近 60%只是简单地把同步写盘改为后台异步完成。这说明存储层的优化是性价比极高的投资学习 AI Infra 时千万别只看“计算”。6.2 性能剖析与慢任务定位当训练或推理性能不达标时第一件事不是改超参而是定位瓶颈在哪一层。我归纳了一个排查顺序表每次按表执行就能很快缩小范围现象优先排查对象可能原因GPU 利用率低且波动大数据加载链路磁盘读慢、预处理没做、队列太小GPU 利用率低但 CPU 忙数据预处理训练线程在等数据转换完成多卡通信时吞吐骤降网络层拥塞控制未开、交换机降速、网卡拓扑不对单个节点明显比同集群慢硬件层GPU 降频、HBM 出现错误、散热问题显存频繁 OOM并行/缓存配置激活值过大、KV Cache 碎片、micro-batch 过大在实际观测中我会同时关注 GPU 利用率、显存带宽利用率、网络吞吐三个指标。如果 GPU 利用率 90% 但显存带宽跑满说明是该卡的访存极限加卡不一定有用如果网络吞吐打到线速则是通信瓶颈又要回头调整并行策略。这种综合分析能力是 AI Infra 学习者最核心的一项修炼。7. 学习路线与常见坑写给后来者的实践建议7.1 我推荐的学习顺序如果从零开始建议按“单卡训练 → 多机多卡 → 集群调度 → 推理部署 → 性能剖析”的顺序走每个阶段都动手做一个小实验而不是只读文档。第一步先把一个开源对话模型的微调跑通观察显存占用和单卡利用率。第二步到两台机器上做数据并行看看梯度同步带来的性能损耗。第三步尝试把模型切成张量并行或流水线并行体验通信开销的巨大差异。第四步部署推理服务调整批处理和 KV Cache 配置观察并发和延迟变化。这个过程走下来你会对每个概念的“手感”非常清晰。遇到问题时不至于在概念之间打转。我认识的不少人都会跳步一上来就学多机多卡结果连单卡的显存账都不会算最后还是得回头补基础。7.2 高频问题速查把几个经常遇到的问题整理成速查表方便直接对照模型训练时 loss 一直是 NaN先查学习率和混合精度配置再看数据里有没有异常值最后查梯度累计和 loss scaling。多卡训练时某张卡“掉队”导致整体等待。这类问题多半是慢节点需要检查该卡的时钟频率、散热和 HBM 错误。推理服务响应慢但 GPU 利用率不高优先级最高的是检查 KV Cache 命中率和批处理是否生效很多情况下是并发队列配置不对。集群利用率统计虚高注意有的监控把“已分配但空闲”也算成被使用看真实利用率一定要看算力采样数据而不是分配比例。7.3 一点个人体会说到最后我想分享一个这段时间学 AI Infra 最深的感触它不是一个靠“多看几篇论文”就能掌握的知识而是一门靠“算账”和“试错”积累的手艺。显存账、带宽账、延迟账、成本账每一步都在做权衡而真正的优化往往发生在交叉地带。我在实际维护集群时发现最花时间的不是把任务跑起来而是让任务跑得快且稳。每一次利用率提升的背后可能只是一行调度配置的改动或者一次网络参数的调优但它需要你对整条链路都有清晰的认知。这也是我整理这份 AI Infra 知识全景学习笔记的原因把地图先画好后面的路才不容易走偏。如果让我再给一条具体建议那就是把“成本模型”刻在脑子里。无论是选并行策略、买卡、调显存还是配网络都先估算单位 token 或单位样本的成本再决定优化方向。这个习惯一旦养成你会发现所有技术的选择都变得清晰起来。