★ FEATURED ARTICLE AI Infra 这个词我第一次听到的时候其实是有点不以为然的。当时有位 A 同学跟我说他跳槽去做 AI Infra 了我第一反应是这不就是运维换了个马甲吗直到后来我自己接了 GPU 集群的维护和大模型训练任务才意识到这个领域的复杂度远超想象。它既不是单纯的运维也不是纯粹的算法而是一整套介于硬件、系统软件、分布式计算和数据之间的工程体系。这篇笔记是我从零开始梳理 AI Infra 知识全景的记录把硬件、调度、训练、推理、成本这几个大块串成一张地图希望它能帮到刚接触这个方向的人也能给正在和集群问题搏斗的同行一点参考。1. 先把边界画清楚AI Infra 到底管到哪一层AI InfraAI 基础设施这个名词这几年已经从职位头衔变成了一个独立的技术方向。我自己的体会是它的内核一句话就能说完用工程手段让 AI 模型的开发、训练、部署和持续服务变得稳定、高效、可运维。听起来和传统基础设施差不多但如果你真把一个 AI 训练集群当普通微服务集群去维护很快会被各种意料之外打脸。1.1 四层模型硬件、系统软件、调度、应用支撑传统基础设施里我们考虑的是 CPU 核数、内存、磁盘 IO、网络吞吐、服务可用性负载单元是请求和实例。AI 基础设施里负载单元换成了训练任务显存GPU 卡集合通信带宽检查点文件资源形态完全不同故障模式也不同。一个训练任务跑不动可能是卡坏了、驱动崩了、网络丢包、存储慢、数据加载卡住、框架死锁、模型代码有 bug……任何一个环节出问题表现都是训练变慢或者卡在某个 epoch定位难度比普通服务高一个量级。所以我学习这个领域做的第一件事不是去背工具用法而是先把层次画出来。我习惯把 AI Infra 拆成四层硬件层计算加速卡、节点内部的卡间互连、跨节点网络、存储系统。系统软件层驱动程序、GPU 运行时、通信库、加速器抽象层这是硬件和我们写的代码之间真正打交道的地方。集群调度层容器编排、GPU 设备分配、资源配额、任务排队、优先级与抢占解决一群人怎么共用一批卡。应用支撑层训练框架的分布式组件、数据管线、检查点与恢复机制、推理引擎与服务化组件。1.2 分层的价值定位问题先在层间找这个分层的意义不只是画图好看而是决定了排查问题的思路和责任边界。真实发生过好几次某个训练任务莫名其妙变慢算法同学说是环境问题负责集群的同学说是代码问题两边对着屏幕叹气。后来我们发现绝大多数悬案都发生在两层之间的接口上——驱动和通信库的版本组合不对、容器编排平台分配的拓扑和通信库的默认假设不一致、框架的检查点逻辑和存储性能不匹配。所以我在笔记里反复给自己强调一个排查习惯出了妖事先定位它在哪两层之间再往具体组件里钻。另外我平时被问到的问题也大都落在 AI Infra 范围内训练一跑就显存不足是加卡还是换卡两个团队抢同一批 GPU怎么分才算公平模型上线后响应很慢是该加机器还是该做量化每个问题看来是各自领域的事但它们都需要在一个统一的资源约束和调度逻辑下求解——这正是用全景视角看 AI Infra 的价值所在。2. 硬件底座卡、网、存这三样锁死了成本天花板在 AI 集群里硬件不是单纯选型问题而是预算问题。一张训练卡的单价决定了整个集群的下限而网络和存储决定你能把这批卡用得多好。做 AI Infra 的人先把这三样东西的指标与权衡搞透后面所有调度和优化都不过是在这个约束下做文章。2.1 计算卡别只看算力显存和带宽才是命门挑选训练卡时大部分人的第一反应是看算力比如 FP16/BF16 下的 TFLOPS。这个指标当然重要但对大模型训练来说另外两个参数更致命显存容量和显存带宽。显存容量决定了你能装下多大的模型。训练一个百亿参数模型光参数就要几十 GB加上优化器状态、梯度、激活值显存需求通常是参数量的好几倍。显存不够你就只能做各种状态卸载、重计算、梯度压缩速度会指数级下降。显存带宽则决定了加速器读写参数的速度——训练的本质就是不停地读权重、算梯度、写回权重如果带宽跟不上算力再高也是在白等。还有一个容易被低估的是卡间互联。同节点的卡有 NVLink 这类高速互连通道跨节点则要走网络。对数据并行训练来说每个 step 结束都要把各卡上的梯度汇总一遍通信量相当可观。我见过一个典型的踩坑案例有同学在做多机训练时发现扩展效率上不去换了更贵的卡反而更慢最后定位到原因是卡间和节点间通信成了瓶颈算力提升完全被通信等待吃掉。选硬件时把单卡性能和集群聚合性能分开看后者才是真实训练吞吐的关键。2.2 跨节点网络训练的每个 step 都在跟它讨价还价GPU 集群的网络和普通机房不一样核心诉求是极低延迟、极高吞吐的低损耗通信。单卡显存的读取带宽是一两百 GB/s 的量级单机内部互连也有几百 GB/s但跨节点的网络哪怕用 RDMA 也通常只有 100~400Gbps换算下来是 12.5~50GB/s。这个差距意味着一旦模型需要频繁跨机通信网络就是最短的那块板。大模型分布式训练里最核心的通信模式是集合通信常见的有 AllReduce、AllGather。你可以把 AllReduce 理解为每个 step 结束时所有卡把自己的梯度拿出来两两交换、逐层合并最后每张卡都拿到全体总和。它的通信量大致和模型参数量成正比和并行度也有关。这也是为什么业界把通信计算比挂在嘴边——一次正向反向计算时间很短而通信时间很长整个流水线就在空转。网络拓扑也要懂一点。大规模集群普遍用胖树或类似的分层结构核心问题在收敛比如果从接入层往核心层带宽逐层缩水跨远端节点的通信就会变慢。做 AI Infra 的人至少要学会看组网文档搞清楚任务跑在远端节点和本地节点的带宽差异这对调度是个重要约束。2.3 存储检查点和数据集其实是两种病人存储是 AI Infra 里最容易被忽略、但出事最狠的一层。我把它拆成两种完全不同的负载第一种是检查点文件。训练跑到一半定期把模型权重、优化器状态写下来出故障时从这里恢复。这类负载的特点是单文件很大几十到几百 GB写操作频繁且集中对带宽要求高。最忌讳把检查点放到普通网络盘或者默认目录下因为多个训练任务同时写的时候整个存储会被打爆表现就是训练到 checkpoint 阶段卡死几分钟。第二种是数据集。图像、文本、视频样本通常是海量小文件训练进程会不停随机读取。这类负载的核心指标是 IOPS 和随机读性能而不是顺序读带宽。常见解法是缓存把高频样本放到本地 NVMe 盘或者内存缓存里避免每次训练都去打对象存储。我在自己的环境里习惯做一套分层冷数据放容量型存储热数据放高性能缓存检查点单独走一条高吞吐通道。这个设计不复杂但能省掉的故障排查时间非常可观。3. 算力调度GPU 从独占走向共享中间隔着一整套排队逻辑硬件买好了问题马上就来了怎么把一批卡分给一群人用既不让任务互相饿死又尽量别让卡闲着。这就是 AI Infra 里的调度层也是我花时间最多、踩坑最多的部分。3.1 为什么 GPU 调度比 CPU 调度难CPU 任务可以随时被抢占、迁移一个进程的暂停对另一个进程几乎没有影响。GPU 训练任务完全不同一个分布式训练任务往往要同时占用多张卡少一张都跑不起来。比如一个任务申请 8 张卡调度器必须保证 8 张卡同时空闲才能启动它——如果只剩 7 张那 7 张卡就得陪它一起等。这种要么全给、要么不给的资源需求术语叫 gang scheduling。它直接导致 CPU 世界里那套排队等单个资源的思路失效。更麻烦的是 GPU 资源一旦分配给任务中途很难切走。训练跑一半不能像进程一样随便迁移所以调度器做一次性决策时必须考虑到未来的任务组合。这就是调度策略的博弈追求高利用率把任务尽量塞满和追求公平人人都有卡用常常是对着干的。3.2 容器编排平台里的 GPU 分配设备插件只是第一步用容器编排平台管理 GPU技术上最基础的一步是用设备插件把 GPU 暴露成可分配的资源让平台知道每台机器有几张卡、每张卡多大显存。这层做完只是能识别真正难的是调度策略和多租户隔离。我见过的第一个大坑是节点碎片化。举个例子集群有三台机器A 机器剩 2 张卡、B 机器剩 2 张卡、C 机器剩 4 张卡。现在来了一个需要 4 张卡的任务按优先填满的策略它会落到 C没问题。但如果不做拓扑感知任务可能被分散到多台机器跨节点通信一下子把训练性能拉垮。反过来如果一直追求把空闲卡集中起来又会牺牲调度延迟。所以好的调度器至少要会做三件事感知 GPU 拓扑同节点优先、做预选满足 gang 需求、在 bin-packing 和 spread 之间做权衡防止碎片化。在隔离方面整卡分配最简单但浪费也最大。一个推理服务只需要半张卡的算力给它一整张就是浪费。于是有了算力切片方案从显存隔离到算力分片比如 MIG/MPS 这类技术再到真正的 GPU 虚拟化。切得越细利用率和隔离性之间的平衡就越难维护。我自己的建议是训练任务尽量整卡分配推理任务再考虑切片混布要谨慎。3.3 多租户排队配额、优先级和占着茅坑问题当一群人共享一个集群时调度就变成了排队系统问题。首先要有配额每个团队最多能用多少卡防止一个任务把集群吃光。其次要有优先级重要任务的紧急训练应该能插队但不能无限制地挤占别人已分配的资源。这两条说起来简单真实现场经常变成团队之间的博弈。最容易出问题的现象是队列里排着好几个大任务但因为每个任务的资源需求都超过目前最大空闲块导致集群明明有卡却一个任务都跑不起来。用前面碎片化的例子三台机器各有 224如果排在前面的两个任务各要 6 张卡它们都在等而那块 4 张卡的空闲块始终凑不齐——这时就需要一个叫 backfill 的机制让调度器把空闲卡先给能满足的小任务而不是死等大任务。我在实际运营集群时会专门配一个监控项盯空闲但不可分配的卡数这个数字越接近 0说明调度的碎片化控制得越好。4. 训练系统的幕后机制并行策略、检查点与失败恢复调度把卡分到了任务手里接下来就是训练系统内部的事。这一层对使用者来说最熟悉也最容易忽略因为框架帮你封装了太多细节。但如果你想排查慢训练、写高效的分布式代码这些机制必须搞清楚。4.1 为什么一定要分布式单卡装不下也跑不动一个模型能不能在单卡上训练首先看显存。假设一个 7B 参数模型用 BF16 存权重光参数就是 14GB加上梯度、优化器状态通常要用 FP32还有前向中间激活值单卡几十 GB 显存根本装不下。就算装得下单卡算力也不够——大模型训练想在合理时间内完成必须把计算分到多张卡上。为此出现的第一个标准化方案是数据并行每张卡放一份完整模型副本喂不同数据每个 step 结束交换梯度保证所有副本同步更新。优点是实现简单缺点是模型太大时单卡放不下而且每 step 通信量很大。后续演进出的策略逐渐把模型本身也切开。4.2 并行策略对比什么时候选哪种我把主流的并行手段列了一张表方便对照策略核心思想显存压力通信开销适用场景数据并行DP每卡一份完整模型切数据每卡都要放下完整模型每 step 全量梯度通信模型能放进单卡时张量并行TP把算子内矩阵切块到多卡每卡只存一部分权重每层前向/反向多次小包通信单卡放不下、卡间互连快流水线并行PP按层切分卡与卡串行执行每卡存一部分层边界处传激活与梯度大模型、网络带宽一般分片数据并行ZeRO/FSDP权重、梯度、优化器状态分片存储大幅降低单卡显存通信量随分片策略变化大模型且通信带宽较好选型没有银弹。一般来说如果卡间互连很快比如同节点张量并行很有优势如果跨节点带宽一般就适合流水线加数据并行尽量只在节点边界做少量通信。我的经验是先把通信量算一算再决定策略组合别凭感觉选。4.3 通信与计算重叠看懂训练循环的气泡分布式训练的时间大致等于计算、通信、等待三者之和。理想情况下通信应该与计算重叠让 GPU 在等梯度时别闲着。但实际做到很难因为梯度是反向传播到最后一步才齐的先反向的层只能等后面层的梯度。这就是所谓的通信气泡也是优化训练框架性能的关键。我建议刚接触分布式训练的人先学会做 profiling把一次 step 拆成前向、反向、集合通信、参数更新、数据加载几段看每段各占多少时间。如果通信占比超过三成优先怀疑并行策略和网络带宽如果数据加载占了大比例问题在数据管线而不是模型只有 profiling 之后你才知道该往哪个方向优化而不是瞎调超参数。4.4 检查点与失败恢复大模型训练是熬出来的大模型训练动不动跑几周甚至几个月但大规模 GPU 集群里的硬件故障率并不低训练任务本身也可能因为显存溢出、驱动 bug、网络抖动而崩溃。没有容错机制任何一个小时级的故障都会让整个训练回到起点。所以检查点不是可选项而是训练系统的基础设施。检查点有两种思路一是定期全量保存简单可靠但开销大——每次保存要花几分钟如果特别频繁训练吞吐会被明显拖慢二是异步保存把保存动作放到后台线程前台继续训练这是目前大模型训练的标配。恢复的时候从最近检查点加载全部状态权重、优化器、学习率调度器、数据位置重新起任务。真正考验人的是检查点的存储设计。分布式训练里每张卡的检查点其实是分片保存的恢复时要求所有分片能对上。如果存储系统掉链子、写一半失败检查点可能整个作废。我在实战中会额外做一件事保存完成之后马上做一次文件完整性和长度校验宁可慢几秒也不要等到训练崩溃恢复时才发现检查点坏了。4.5 数据管线GPU 等你还是你等 GPU最后是数据加载。很多人性能优化到后面才发现 50% 的训练时间花在 CPU 读数据上。数据管线优化的核心思路只有一条让数据永远比 GPU 快一步。具体手段包括多进程预取、把随机读取变成顺序读取、预处理放到训练节点提前完成、用内存缓存热门样本。判断标准很简单看 GPU 利用率曲线如果周期性掉到接近 0多半是数据管线在拖后腿。5. 推理服务化从离线评估到线上 SLO中间全是细节训练只是模型生命周期的一半。模型训完要上线服务而这个阶段的工程复杂度很多人是在被线上事故教育之后才意识到的。推理和训练最大的区别在于训练追求整体吞吐推理却要同时照顾延迟和吞吐还要应对不可预测的请求流量。5.1 连续批处理为什么一条一条推理又慢又贵早期做推理最常见做法是把请求攒成固定大小的 batch一起喂给 GPU。问题是短请求先到长请求后到大家都要等最慢的而且显存分配给整个 batch 的中间结果一旦 batch 结束就一次性释放利用率很糟。现在主流的推理引擎普遍采用连续批处理每一轮只把当前时刻已到达、且显存放得下的请求放进 batch一个请求生成几个 token 就马上返回空出来的位置立刻让给新请求。这就把显存利用率从按整批分配变成按需动态分配吞吐能翻好几倍。理解这个机制你就理解为什么推理引擎要费劲设计分页式的缓存内存管理——本质上是把显存当成一个精细管理的小仓库而不是一个大仓库。5.2 量化用精度换速度但要算明白账推理侧另一个绕不开的话题是量化把模型权重和激活从 FP16/BF16 压到 FP8、INT8 甚至更低。量化的收益很直接显存占用减半、带宽需求减半、延迟下降。但代价是精度损失尤其在长上下文、复杂推理任务上质量退化可能肉眼可见。我自己的做法是分场景决策对延迟敏感且质量要求不那么苛刻的场景大胆量化对高质量对话、代码生成这类对输出质量极敏感的场景先做评估再决定不要为了省一点点延迟牺牲用户体验。量化粒度也有讲究常见做法是权重用低精度、激活保留高精度这样损失最小、收益最大。5.3 推理服务的架构网关、副本数和 SLO推理服务上线后一般不是单引擎裸奔而是由网关、推理引擎、自动扩缩容组成。网关负责路由、鉴权、限流、超时控制引擎负责实际推理扩缩容根据队列长度或延迟指标动态调副本数。一个常被忽视的点是并发和副本数的关系。GPU 推理引擎有内部并发度可以同时批处理多少个请求所以把 GPU 当成单线程服务按 QPS 简单乘法算副本数是错的。正确做法是先压测出单副本在目标延迟下的最大吞吐比如 p99 50ms 时最多 100 QPS再根据线上流量和冗余需求反推副本数。另外冷启动和大模型加载特别慢扩容时延要有心理预期最好预留一个实例在池子里。还要养成看 SLO 的习惯你承诺的指标是 p50、p95 还是 p99 延迟多长的超时并发超限时是排队还是快速失败我在上线一个模型服务时会固定检查几项压测数据单副本在目标延迟下的吞吐、显存余量峰值并发下不超警戒线、最大并发与降级方案超时、过载、排队上限分别怎么处理、峰值流量估算含突发活动场景。这一套检查下来能挡掉八成线上事故。6. 可观测性与单位成本利用率、排队与每 Token 成本AI Infra 做得好不好最终要落到两个数字资源和钱有没有被浪费以及每个单位产出花了多少钱。可观测性和成本治理是同一个问题的一体两面。6.1 GPU 利用率到底该怎么看警惕假忙很多人看 GPU 利用率就是看一个百分比其实那个数极容易被误解。常见的利用率指标是计算单元活跃度只要内核在跑它就偏高但内核可能一直在等显存数据这时候计算单元并没有真正干活。真正要看的指标是组合的计算单元占用、显存带宽利用率、卡间互连利用率、内核等待占比以及更宏观的任务排队耗时。我见过最典型的假忙案例GPU 利用率显示 90% 以上但训练吞吐就是上不去。后来做了核级 profiling发现绝大多数时间卡在显存带宽或通信等待上计算单元只是在空转等数据。只看利用率你会以为没有问题看了带宽和等待你才会知道瓶颈在哪。所以我在集群监控面板上利用率只是辅助核心是训练吞吐、通信占比、数据加载耗时三个数。6.2 训练成本拆解一小时卡费便宜不代表训练便宜成本治理的起点是知道钱花在哪。我习惯把一次训练任务的总成本拆成几部分卡时费用GPU 数量×运行时长×单价、存储费用检查点和数据集、网络费用多机训练里的跨节点流量、以及因为排队和故障浪费掉的空闲卡时。这里特别提一下空闲卡时——这是最容易漏掉的隐性成本。一个任务因为等待资源、因为恢复检查点、因为数据加载慢而多跑一小时这一小时的卡费就是纯浪费。把训练任务的平均有效计算时间GPU 真正干活的时间占比算出来你会很惊讶很多集群连 50% 都不到。提升 10 个百分点的有效计算时间省下的钱可能比换个便宜的云资源还多。6.3 弹性与缩容省钱的真正手段成本治理的另一个抓手是弹性把不需要的资源交回去。训练任务是长任务弹性空间有限但推理服务完全可以根据流量自动伸缩。夜间低峰期把副本数降下来高峰期提前扩容配合请求排队深度的监控能省一笔不小的开销。另外我在用公有云租卡时习惯做两步保护一是给训练任务加自动保存检查点确保被回收或故障后能在 15 分钟内恢复二是对空闲超过阈值的实例做自动提醒甚至自动关机。这两步在第一眼看起来多此一举但长期跑下来你会发现绝大多数费用超标都是这类小地方积累出来的。7. 给新人一条能落地的学习路径最后分享一点学习路线上的经验。AI Infra 的知识面很宽如果一上来就啃各种源码和论文容易被淹没。我建议按由小到大、从能跑到能优化的顺序走。7.1 五个阶段第一阶段先在一张卡上把训练跑明白。选一个经典小模型自己写数据管线、训练循环、评估代码学会用 profiling 工具看单卡时间花在哪。这个阶段的目标不是调出好模型而是理解一条训练数据从磁盘到 GPU 再到反向传播的完整链路。第二阶段在单机多卡上做数据并行。用分布式框架的现成接口观察多卡训练的通信过程对比 1 卡、2 卡、4 卡、8 卡的扩展效率。你会发现通信开销不是线性的这为理解更复杂的并行策略打底。第三阶段上多机集群。这时候开始接触节点间网络、共享存储、任务队列。我建议自己搭一个最小的实验环境两台机器、几张卡手动配置容器编排平台和 GPU 调度再提交一个两节点的训练任务。只有亲手把环境搭出来你才能体会到硬件、驱动、网络、调度之间环环相扣的感觉。第四阶段回到推理。用训练好的模型做推理服务压测不同并发下的延迟和吞吐尝试量化、批处理优化和服务化架构。这个阶段会反过来帮你理解训练时那些为什么。7.2 一个工作习惯最后想说做 AI Infra 最稀缺的能力不是记住某个工具而是建立一套度量—假设—验证的工作习惯。看到一个问题先量化它是带宽问题、等待问题还是配置问题再提出假设用小实验验证而不是凭经验瞎猜。我踩过的所有大坑几乎都是因为最初少做了一步度量。
阅读完成 · 觉得有帮助？
