聊聊我为什么整理这份AI Infra知识全景学习笔记先说说包含哪些内容、对谁有帮助——它本质上是把AI基础设施从硬件到平台的知识点梳理成一条完整的学习路径覆盖GPU集群、分布式训练、推理服务、资源调度、MLOps这几个核心板块。如果你正在从普通后端开发转向AI平台方向或者是算法工程师想搞懂底层支撑逻辑再或者是刚入行的运维想理解AI集群怎么管这份笔记都能帮你建立一张可复用的知识地图。我的目标是不堆概念、不抄文档而是把每个技术点背后“为什么这么设计”的问题讲清楚。在整理这份笔记之前我先花了两个星期把市面上的相关资料、开源项目文档、论文翻了一遍然后又用两个月时间在自己的项目里逐个验证那些关键配置和方案。整个过程踩了不少坑有的坑是资料的坑很多博客写得太粗参数都不给全有的坑是实践的坑理论看着没问题一跑就崩。这篇文章不是简单的目录汇总而是把思考过程、选型逻辑、实操经验一并记录下来希望能让你少走我走过的弯路。1. 先画地图AI Infra到底是什么边界在哪里AI Infra这个名词近几年被频繁提及但没有一个公认的准确定义。我的理解是这样从一张GPU显卡到一套能支撑大模型训练的平台中间所有这些“让AI跑得更高效”的工程环节都属于AI Infra的范畴。它不是某一个开源组件也不是某一个云产品而是一个横向的工程学科。业界经常把AI Infra的组成拆成几层我习惯用这样的分层思路硬件资源层GPU/加速卡、服务器、高速网络如InfiniBand、存储系统。这是物理底座。资源管理层任务调度如各调度器、GPU虚拟化/共享、队列管理。这一层解决“怎么把芯片分给谁用”。训练/推理框架层分布式训练框架如DeepSpeed、Megatron、推理引擎如FasterTransformer系列、算子库如flash-attention。平台与工具链层MLOps平台、模型仓库、数据管道、监控与告警、CI/CD for ML。这个分层最大的好处是当你遇到一个具体问题比如训练慢、显存溢出、卡利用率低你能快速定位它发生在哪一层然后对症下药。很多人学AI Infra容易陷入“什么都看、什么都浅”的困境根本原因就是没有先把地图画出来知识点像散落的碎片一样无法串联成体系。1.1 为什么AI Infra值得专门学先把一个容易混淆的概念理清楚AI Infra不是“会用几个框架跑通Demo”就行。会调用现成训练代码是一回事能设计一个在64张卡上稳定跑一个月训练任务不崩的集群系统是另一回事。两者的差距就是工程能力的差距也是AI Infra知识的含金量所在。具体来说AI Infra要解决的核心矛盾至少有三个一是性能矛盾。现代加速卡的计算速度已经非常快但数据传输、同步开销往往成为瓶颈。一个典型的例子在大规模多卡训练中每步迭代都要做模型参数的梯度同步如果网络拓扑不合理通信时间可能超过计算时间导致加速卡大部分时间是空闲的。二是效率矛盾。单张顶尖加速卡价值不菲数据中心里的资源如果闲置或利用率低成本压力巨大。AI Infra的很多技术共享、弹性调度、多租户隔离本质上都是在做“资源复用”这件事。三是规模矛盾。从单机多卡到千卡集群系统复杂度和故障概率不是线性增长而是指数增长。训练过程中任何一张卡掉线、任何一条网络链路抖动都可能导致整个任务中断。如何保证大训练的稳定性、如何自动恢复这是普通后台系统不需要面对、但AI Infra必须解决的问题。理解了这三个矛盾再看那些技术点你就知道每个技术是在解哪道题了。这份笔记的整个框架也是围绕这三个矛盾来展开的。2. 硬件与集群拓扑读懂算力底座的关键参数我见过一些开发者在软件层折腾很久最后发现瓶颈其实在网络带宽或者存储IO上。所以学习AI Infra的第一站建议先认识硬件。只有对硬件的关键指标有直觉才能在做方案设计时选对路。2.1 GPU核心参数不止看显存和算力挑选加速卡时大家最先盯着的肯定是显存大小和算力比如FP16的TFLOPS但从Infra视角看还有两个参数容易被忽略却极其关键。第一是卡间通信带宽。以经典的两代加速卡为例主流服务器的NVLink带宽有明显代际差异。如果跨节点通信靠的是高速网卡这个数字决定了大模型训练中张量并行的效率。通信带宽不够算力再高也发挥不出来。关键参数作用场景看它做什么判断显存容量模型权重、激活值、优化器状态能跑多大的模型、是否要重计算FP16/BF16算力训练/推理的计算吞吐单卡算力上限在哪卡间互联带宽单机内多卡通信张量/流水线并行是否可行跨节点网络带宽集群规模扩展数据并行效率、梯度同步成本这个表和上面的具体型号的数据只是举例实际选型时需要以当前在售产品的最新官方参数为准。核心是想强调显存决定模型规模上限互联带宽决定并行策略的选择空间网络带宽决定集群扩展的性价比。第二是显存带宽。很多人忽略这个指标但它对推理性能影响非常大。因为推理过程中有大量的权重读取和KV Cache读写显存带宽往往比计算吞吐更早成为瓶颈。这也是为什么有的卡算力看着高实际跑推理却不如预期——算力在等数据。2.2 集群网络拓扑为什么100G网卡依然可能瓶颈单机内部的互联带宽再高跨机器通信依然要依赖外部网络。大模型训练集群最常用的是RDMA网络比如InfiniBand或者RoCE。这两者的核心区别可以这样简单理解InfiniBand是专用的无损网络协议栈为高性能计算而生RoCE是把RDMA能力跑在传统以太网上成本更低但配置调优更复杂。我见过不少团队在训练性能不佳时先怀疑代码结果查了一圈发现是网络配置问题比如拥塞控制策略没调、缓冲区设置不合理导致乱序重传严重。训练集群网络不是插上线就能跑的要做无损网络配置、拥塞控制调优、拓扑设计。这里有个很实用的经验在评估集群规模的性价比时要比较“计算时间”和“通信时间”。举个例子如果每次迭代计算需要2秒而梯度同步需要1.5秒那么即使算力提升一倍总迭代时间也只减少约30%左右因为通信时间被固定住了。这就是所谓的通信占比过高问题也是设计集群时要考虑的关键指标。2.3 存储系统AI场景下的三类数据存储是AI Infra里最容易“临时凑合”的部分但最值得认真设计。按访问模式可以把AI场景的数据分三类第一类是训练样本数据。特点是文件多、单文件大、读多写少需要高吞吐的并行文件系统。很多团队直接用一个NFS挂载点扛所有训练数据结果多个训练任务同时读数据时IO成为瓶颈GPU都在空转等数据。第二类是检查点Checkpoint。大模型训练每几个小时就要保存一次模型状态一次检查点可能就有几十到几百GB。这类数据需要高带宽写入同时对一致性有要求。业界在做检查点优化时有个常用思路是异步保存加分层存储即内存→本地盘→远端存储逐级落盘。第三类是日志与指标。数量极大但对性能要求相对低可以用对象存储或时序数据库来承载。我踩过的坑是训练数据所在文件系统的元数据性能差导致数据加载器在遍历文件列表时耗时巨大。后来用并行文件系统并且把数据做成预打包格式如TFRecord类方案才算把数据加载时间压下来。3. 训练基础设施从单卡到千卡规模的必备技术训练侧的Infra技术是大模型工程的重头戏。这一节我按“并行策略 → 显存优化 → 作业管理”三个层次来梳理每层对应不同的问题。3.1 分布式并行策略四个基本维度多卡训练有四种基本并行方式很多人被这些概念绕晕其实记住每种解决什么问题就够了数据并行每张卡都保存一份完整模型副本喂不同的数据定期同步梯度。实现最简单。缺点是大模型的参数放不下一张卡时就没法用。张量并行把模型的每一层按维度切分到多张卡。Transfomer里常用的拆分方式是按注意力头数和矩阵列切分。缺点是通信量很大所以只适合单机内卡间高速互联的场景。流水线并行按层切分把网络的不同层部署到不同卡上数据在层间流动。优点是通信量相对小缺点是存在流水线气泡利用率会有损失。序列并行专门针对序列维度切分主要用于长序列场景配合注意力机制优化使用。实际的大规模训练很少只用一种并行策略。主流方案是把多种并行方式组合成三维混合并行。举个真实案例某团队训练一个百亿参数模型使用64张加速卡采用了8路张量并行乘以8路流水线并行再叠加数据并行的组合方式。这个配置下每个数据并行组的模型被切到8张卡上利用单机内的NVLink高速互联做张量并行跨机之间走数据并行做梯度同步。3.2 显存优化三板斧重计算、混合精度、Offload显存不够是大模型训练最常见的痛点。优化手段很多但核心就三板斧第一板斧是激活重计算。训练过程中前向传播会保存大量中间激活值用于反向传播。重计算的思想是“不存这些值反向传播时再算一遍”。这个策略用约30%~40%的额外计算量换来显存占用的大幅下降是训练超大模型时的标配。我实测下来开启重计算后一个原本显存不够的模型不仅能跑起来了batch size还能增大不少。第二板斧是混合精度训练。简单说就是对权重和梯度用高精度FP32做累积更新但对前向反向计算用半精度FP16或BF16来加速。BF16相比FP16有个好处动态范围和FP32一致不容易出现下溢问题在大模型训练中更常用。第三板斧是优化器状态卸载。大模型训练时Adam优化器需要保存梯度一阶矩和二阶矩这些状态占的显存可能比模型本身还大。ZeRO方案把这个负担分摊到数据并行组的所有卡上或者卸载到CPU内存甚至硬盘。以业界常用的ZeRO三个阶段来看阶段1优化器状态切分到多卡 阶段2 梯度切分训练64B模型时显存峰值下降明显 阶段3 参数切分按需全收集通信开销最大实际使用中阶段2是很多团队的首选因为它显存收益大、通信开销增加有限。阶段3由于通信量上升明显需要谨慎评估。3.3 作业调度与容错训练任务的最后一公里当一个训练任务需要几十张卡连跑数天时作业调度与容错就成了硬需求。这个层面有两个主流方向一是原生调度器流派像各类高性能计算调度器它们在超算和传统科学计算领域非常成熟支持队列优先级、节点隔离、作业依赖但对GPU资源缺乏细粒度感知。二是云原生调度流派基于Kubernetes改造配合专门为GPU场景设计的调度插件。这类方案的思路是把训练任务打包成工作负载由调度器根据GPU资源、亲和性、队列配额进行调度和排队。我个人的实践体会是如果是自建稳定的AI训练平台长期来看值得考虑云原生流派但要做好学习投入的准备。训练任务的容错则靠定期保存检查点实现。检查点不光在任务失败时有用训练过程中如果想调整超参数比如改学习率、换batch size也可以从最近的检查点热恢复省去从头训练的时间。4. 推理与模型服务上线之后才是真的考验训练做得好只代表模型有潜力真正面向用户提供服务时又会遇到一批全新问题。推理侧Infra和训练侧有很大不同核心关注点是延迟、吞吐、成本。4.1 推理引擎选型连续批处理是分水岭传统推理服务往往借用训练框架来加载模型然后逐条处理请求。这种方式对在线服务来说太慢了吞吐也很低。业界后来发现一条关键优化路径动态批处理Continuous Batching。简单解释就是传统的一次等一批请求到齐再处理动态批处理则是“来一个处理一个”某个请求处理完立即释放资源接下一条。这让单实例吞吐提升数倍成为现代推理引擎的标配能力。选推理引擎时要重点关注几个指标支持的模型架构覆盖度、算子的极致优化程度、动态批处理实现的好坏、对量化格式的支持。比较成熟的开源方案之间性能差距有时很大关键差在算子上是否适配了特定型号的加速卡。4.2 推理优化三板斧量化、KV Cache、前缀复用动态批处理之上还有三个高频使用的优化手段一是权重量化。把模型权重从FP16压到INT8或INT4显存占用直接减半甚至减到四分之一。代价是精度略有损失。对追求低延迟的场景量化几乎是必选项。实际项目里我常用先量化再评估精度的流程如果偏差在可接受范围就直接上线。二是KV Cache。自回归生成的过程里每个token要读取之前所有token的上下文信息这些中间状态被缓存起来避免重复计算。KV Cache的显存占用和序列长度成正比长序列场景下可能占据推理显存的大头。控制它的大小、做KV Cache的量化压缩是长文本推理的核心话题。三是前缀复用。当多个请求共享相同的上下文前缀比如同一条系统提示词可以缓存前缀部分的计算结果只对新增内容做计算。这在聊天场景中效果非常明显能大幅降低首个token的延迟。推理服务还有一个容易忽略的指标首Token延迟和Token间延迟要分开衡量。前者决定用户“第一次看到回应”的体验后者决定整体流畅度。这两项对应的优化手段不同不能用同一个指标掩盖问题。4.3 在线服务的弹性与成本服务编排的进阶话题推理服务上线后流量通常是有波峰的。提前准备固定数量的实例低峰期浪费严重高峰期又容易超载。弹性的思路是让实例数跟随指标如GPU利用率、队列深度自动伸缩。这里我建议把伸缩逻辑建立在训练的指标采集上比如利用GPU自身的利用率指标和自定义的队列指标而不是只靠外部流量。多模型服务还有个成本优化思路模型分片混合部署。把不同模型的副本部署在同一个GPU上通过时间片或显存隔离方式共享硬件。这样可以提升资源利用率。我自己采用过的替代方案是先把不同模型的规格、流量、时延要求列成表然后做容量规划。同时建议关注显存碎片问题。推理引擎反复加载和卸载模型后显存碎片化会越来越严重最终导致明明看着还有空间却分配失败。定期重启或采用更积极的内存整理机制能缓解这个问题。5. 平台化与MLOps把AI工程能力沉淀成产品如果上面这些技术点都打通了最后一步就是把这些能力平台化让团队里的算法工程师、数据工程师、运维都能自助使用。平台化能力是一个组织AI工程成熟度的分水岭。5.1 我把AI平台拆成六个模块平台化不是把工具堆在一起而是把流程打通。我梳理出的六件套依次是数据管理、训练平台、模型管理、推理服务、监控告警、CI/CD。每个模块都有自己的关键设计决策数据管理要解决样本版本管理和数据质量监控。训练平台要解决资源申请、配额、优先级的自动化。模型管理要解决模型版本、指标、对应代码和参数的追溯。推理服务要解决灰度发布、流控和弹性。监控告警要覆盖硬件、框架、业务三层指标。CI/CD解决“代码合并后自动跑训练、自动评估、自动提审”的流水线。这六个模块不一定一次性都做齐但架构设计上要预留扩展性。我建议先做训练平台加模型管理跑通一条最小的闭环再逐步扩展。5.2 资源配额与多租户平台公平性的艺术多团队共用一个AI平台时“资源怎么分”是最敏感的话题。平台的资源配额设计直接影响团队间的信任度。我总结了三个原则第一配额必须显式化。每个团队应该能清楚看到自己的配额、已用量、排队任务。最忌讳的是平台“暗箱操作”会引发大量内部矛盾。第二要区分保障配额和弹性配额。给每个团队一个基础保障额度保证其核心业务不被挤占再设置一个弹性池空闲时大家都能抢占忙时按优先级回收。第三抢占策略要可解释。被抢占的任务应该收到明确的通知并且系统要支持自动重新排队甚至自动从检查点恢复。否则一次抢占可能导致团队多个小时的训练进度丢失。5.3 可观测性AI平台最容易烂尾的部分很多AI平台的监控做得很浅只采集硬件的CPU、内存、GPU利用率这种基础指标。但真正定位问题时这些指标往往不够。我在实践中发现有三层监控缺一不可系统层GPU的温度、功耗、卡间通信带宽、网络重传率。这层帮助判断硬件是否健康。框架层数据加载耗时占比、计算耗时占比、通信耗时占比、显存分配曲线。这层帮助判断瓶颈在哪。业务层模型训练的损失曲线趋势、吞吐变化、推理的延迟分位数和成功率。这层帮助判断实验进展和服务质量。这三层要串联成一个统一视图。比如数据加载耗时占比突然升高时系统层可能恰好能看到存储IO延迟飙升从而快速定位是存储问题还是网络问题。我强烈建议从一开始就做好指标打点和看板设计。补做监控的代价通常比想象中高出很多。6. 学习路径与实操心得从零搭建你的AI Infra知识体系最后这部分是我总结的学习路径和一些个人实践经验也是我觉得这份笔记最有价值的部分。6.1 我的推荐路线和环境准备如果从零开始学AI Infra我推荐按这个顺序推进每步设置一个验收目标打牢分布式基础2周搞懂并行策略、通信原语、一致性模型。验收标准是能手绘出数据并行和流水线并行的数据流图。单机多卡实践1个月在自己能接触到的环境上跑通一个中型模型的训练和推理。验收标准是会用工具查看显存分配、定位性能瓶颈。集群级能力建设1~2个月学习调度、存储、网络。验收标准是能设计并解释一个8节点集群的训练任务部署方案。平台化与产品化持续研究MLOps平台设计与开源方案。验收标准是能画出整体平台架构并说清模块之间的数据流。环境准备方面如果预算有限可以在云上按小时租用单个实例来练手先跑通训练链路再逐步增加规模。6.2 一些实际项目中的经验最后分享几段我个人的实操经验。先说性能分析。当训练速度不符合预期时我会按照“数据加载 → CPU计算 → 设备计算 → 通信同步”这条流水线逐步排查先看哪个环节占比异常再深挖原因。最经典的一次是分析显示计算利用率极低最后定位到是CPU端的batch拼接逻辑阻塞了数据供给加速卡大部分时间在等待。遇到突发的显存溢出错误时我建议先开激活重计算再降batch size都不行再考虑梯度累积或者卸载优化器状态。这套组合基本能覆盖九成以上的情况。最后是容错设计。训练任务里所有关键步骤都要有重试机制。但重试不是简单重新跑一遍要结合检查点做断点续训。同时对故障要做记录和分析看是硬件fail还是代码问题针对性地改配置。说到底AI Infra的知识量很大而且技术栈更新节奏非常快。但底层思路是稳定的先确认瓶颈在哪再选合适的优化手段最后把流程产品化沉淀下来。希望这份学习笔记能成为你建立自己知识体系的一个起点。后续我也在不断更新这个主题的实践经验欢迎同行一起交流踩坑心得。 
长河君 · 2026/10/20 19:01:10 · 阅读 1.2k AI Infra知识全景学习笔记：从GPU集群到MLOps的完整路径
聊聊我为什么整理这份AI Infra知识全景学习笔记先说说包含哪些内容、对谁有帮助——它本质上是把AI基础设施从硬件到平台的知识点梳理成一条完整的学习路径覆盖GPU集群、分布式训练、推理服务、资源调度、MLOps这几个核心板块。如果你正在从普通后端开发转向AI平台方向或者是算法工程师想搞懂底层支撑逻辑再或者是刚入行的运维想理解AI集群怎么管这份笔记都能帮你建立一张可复用的知识地图。我的目标是不堆概念、不抄文档而是把每个技术点背后“为什么这么设计”的问题讲清楚。在整理这份笔记之前我先花了两个星期把市面上的相关资料、开源项目文档、论文翻了一遍然后又用两个月时间在自己的项目里逐个验证那些关键配置和方案。整个过程踩了不少坑有的坑是资料的坑很多博客写得太粗参数都不给全有的坑是实践的坑理论看着没问题一跑就崩。这篇文章不是简单的目录汇总而是把思考过程、选型逻辑、实操经验一并记录下来希望能让你少走我走过的弯路。1. 先画地图AI Infra到底是什么边界在哪里AI Infra这个名词近几年被频繁提及但没有一个公认的准确定义。我的理解是这样从一张GPU显卡到一套能支撑大模型训练的平台中间所有这些“让AI跑得更高效”的工程环节都属于AI Infra的范畴。它不是某一个开源组件也不是某一个云产品而是一个横向的工程学科。业界经常把AI Infra的组成拆成几层我习惯用这样的分层思路硬件资源层GPU/加速卡、服务器、高速网络如InfiniBand、存储系统。这是物理底座。资源管理层任务调度如各调度器、GPU虚拟化/共享、队列管理。这一层解决“怎么把芯片分给谁用”。训练/推理框架层分布式训练框架如DeepSpeed、Megatron、推理引擎如FasterTransformer系列、算子库如flash-attention。平台与工具链层MLOps平台、模型仓库、数据管道、监控与告警、CI/CD for ML。这个分层最大的好处是当你遇到一个具体问题比如训练慢、显存溢出、卡利用率低你能快速定位它发生在哪一层然后对症下药。很多人学AI Infra容易陷入“什么都看、什么都浅”的困境根本原因就是没有先把地图画出来知识点像散落的碎片一样无法串联成体系。1.1 为什么AI Infra值得专门学先把一个容易混淆的概念理清楚AI Infra不是“会用几个框架跑通Demo”就行。会调用现成训练代码是一回事能设计一个在64张卡上稳定跑一个月训练任务不崩的集群系统是另一回事。两者的差距就是工程能力的差距也是AI Infra知识的含金量所在。具体来说AI Infra要解决的核心矛盾至少有三个一是性能矛盾。现代加速卡的计算速度已经非常快但数据传输、同步开销往往成为瓶颈。一个典型的例子在大规模多卡训练中每步迭代都要做模型参数的梯度同步如果网络拓扑不合理通信时间可能超过计算时间导致加速卡大部分时间是空闲的。二是效率矛盾。单张顶尖加速卡价值不菲数据中心里的资源如果闲置或利用率低成本压力巨大。AI Infra的很多技术共享、弹性调度、多租户隔离本质上都是在做“资源复用”这件事。三是规模矛盾。从单机多卡到千卡集群系统复杂度和故障概率不是线性增长而是指数增长。训练过程中任何一张卡掉线、任何一条网络链路抖动都可能导致整个任务中断。如何保证大训练的稳定性、如何自动恢复这是普通后台系统不需要面对、但AI Infra必须解决的问题。理解了这三个矛盾再看那些技术点你就知道每个技术是在解哪道题了。这份笔记的整个框架也是围绕这三个矛盾来展开的。2. 硬件与集群拓扑读懂算力底座的关键参数我见过一些开发者在软件层折腾很久最后发现瓶颈其实在网络带宽或者存储IO上。所以学习AI Infra的第一站建议先认识硬件。只有对硬件的关键指标有直觉才能在做方案设计时选对路。2.1 GPU核心参数不止看显存和算力挑选加速卡时大家最先盯着的肯定是显存大小和算力比如FP16的TFLOPS但从Infra视角看还有两个参数容易被忽略却极其关键。第一是卡间通信带宽。以经典的两代加速卡为例主流服务器的NVLink带宽有明显代际差异。如果跨节点通信靠的是高速网卡这个数字决定了大模型训练中张量并行的效率。通信带宽不够算力再高也发挥不出来。关键参数作用场景看它做什么判断显存容量模型权重、激活值、优化器状态能跑多大的模型、是否要重计算FP16/BF16算力训练/推理的计算吞吐单卡算力上限在哪卡间互联带宽单机内多卡通信张量/流水线并行是否可行跨节点网络带宽集群规模扩展数据并行效率、梯度同步成本这个表和上面的具体型号的数据只是举例实际选型时需要以当前在售产品的最新官方参数为准。核心是想强调显存决定模型规模上限互联带宽决定并行策略的选择空间网络带宽决定集群扩展的性价比。第二是显存带宽。很多人忽略这个指标但它对推理性能影响非常大。因为推理过程中有大量的权重读取和KV Cache读写显存带宽往往比计算吞吐更早成为瓶颈。这也是为什么有的卡算力看着高实际跑推理却不如预期——算力在等数据。2.2 集群网络拓扑为什么100G网卡依然可能瓶颈单机内部的互联带宽再高跨机器通信依然要依赖外部网络。大模型训练集群最常用的是RDMA网络比如InfiniBand或者RoCE。这两者的核心区别可以这样简单理解InfiniBand是专用的无损网络协议栈为高性能计算而生RoCE是把RDMA能力跑在传统以太网上成本更低但配置调优更复杂。我见过不少团队在训练性能不佳时先怀疑代码结果查了一圈发现是网络配置问题比如拥塞控制策略没调、缓冲区设置不合理导致乱序重传严重。训练集群网络不是插上线就能跑的要做无损网络配置、拥塞控制调优、拓扑设计。这里有个很实用的经验在评估集群规模的性价比时要比较“计算时间”和“通信时间”。举个例子如果每次迭代计算需要2秒而梯度同步需要1.5秒那么即使算力提升一倍总迭代时间也只减少约30%左右因为通信时间被固定住了。这就是所谓的通信占比过高问题也是设计集群时要考虑的关键指标。2.3 存储系统AI场景下的三类数据存储是AI Infra里最容易“临时凑合”的部分但最值得认真设计。按访问模式可以把AI场景的数据分三类第一类是训练样本数据。特点是文件多、单文件大、读多写少需要高吞吐的并行文件系统。很多团队直接用一个NFS挂载点扛所有训练数据结果多个训练任务同时读数据时IO成为瓶颈GPU都在空转等数据。第二类是检查点Checkpoint。大模型训练每几个小时就要保存一次模型状态一次检查点可能就有几十到几百GB。这类数据需要高带宽写入同时对一致性有要求。业界在做检查点优化时有个常用思路是异步保存加分层存储即内存→本地盘→远端存储逐级落盘。第三类是日志与指标。数量极大但对性能要求相对低可以用对象存储或时序数据库来承载。我踩过的坑是训练数据所在文件系统的元数据性能差导致数据加载器在遍历文件列表时耗时巨大。后来用并行文件系统并且把数据做成预打包格式如TFRecord类方案才算把数据加载时间压下来。3. 训练基础设施从单卡到千卡规模的必备技术训练侧的Infra技术是大模型工程的重头戏。这一节我按“并行策略 → 显存优化 → 作业管理”三个层次来梳理每层对应不同的问题。3.1 分布式并行策略四个基本维度多卡训练有四种基本并行方式很多人被这些概念绕晕其实记住每种解决什么问题就够了数据并行每张卡都保存一份完整模型副本喂不同的数据定期同步梯度。实现最简单。缺点是大模型的参数放不下一张卡时就没法用。张量并行把模型的每一层按维度切分到多张卡。Transfomer里常用的拆分方式是按注意力头数和矩阵列切分。缺点是通信量很大所以只适合单机内卡间高速互联的场景。流水线并行按层切分把网络的不同层部署到不同卡上数据在层间流动。优点是通信量相对小缺点是存在流水线气泡利用率会有损失。序列并行专门针对序列维度切分主要用于长序列场景配合注意力机制优化使用。实际的大规模训练很少只用一种并行策略。主流方案是把多种并行方式组合成三维混合并行。举个真实案例某团队训练一个百亿参数模型使用64张加速卡采用了8路张量并行乘以8路流水线并行再叠加数据并行的组合方式。这个配置下每个数据并行组的模型被切到8张卡上利用单机内的NVLink高速互联做张量并行跨机之间走数据并行做梯度同步。3.2 显存优化三板斧重计算、混合精度、Offload显存不够是大模型训练最常见的痛点。优化手段很多但核心就三板斧第一板斧是激活重计算。训练过程中前向传播会保存大量中间激活值用于反向传播。重计算的思想是“不存这些值反向传播时再算一遍”。这个策略用约30%~40%的额外计算量换来显存占用的大幅下降是训练超大模型时的标配。我实测下来开启重计算后一个原本显存不够的模型不仅能跑起来了batch size还能增大不少。第二板斧是混合精度训练。简单说就是对权重和梯度用高精度FP32做累积更新但对前向反向计算用半精度FP16或BF16来加速。BF16相比FP16有个好处动态范围和FP32一致不容易出现下溢问题在大模型训练中更常用。第三板斧是优化器状态卸载。大模型训练时Adam优化器需要保存梯度一阶矩和二阶矩这些状态占的显存可能比模型本身还大。ZeRO方案把这个负担分摊到数据并行组的所有卡上或者卸载到CPU内存甚至硬盘。以业界常用的ZeRO三个阶段来看阶段1优化器状态切分到多卡 阶段2 梯度切分训练64B模型时显存峰值下降明显 阶段3 参数切分按需全收集通信开销最大实际使用中阶段2是很多团队的首选因为它显存收益大、通信开销增加有限。阶段3由于通信量上升明显需要谨慎评估。3.3 作业调度与容错训练任务的最后一公里当一个训练任务需要几十张卡连跑数天时作业调度与容错就成了硬需求。这个层面有两个主流方向一是原生调度器流派像各类高性能计算调度器它们在超算和传统科学计算领域非常成熟支持队列优先级、节点隔离、作业依赖但对GPU资源缺乏细粒度感知。二是云原生调度流派基于Kubernetes改造配合专门为GPU场景设计的调度插件。这类方案的思路是把训练任务打包成工作负载由调度器根据GPU资源、亲和性、队列配额进行调度和排队。我个人的实践体会是如果是自建稳定的AI训练平台长期来看值得考虑云原生流派但要做好学习投入的准备。训练任务的容错则靠定期保存检查点实现。检查点不光在任务失败时有用训练过程中如果想调整超参数比如改学习率、换batch size也可以从最近的检查点热恢复省去从头训练的时间。4. 推理与模型服务上线之后才是真的考验训练做得好只代表模型有潜力真正面向用户提供服务时又会遇到一批全新问题。推理侧Infra和训练侧有很大不同核心关注点是延迟、吞吐、成本。4.1 推理引擎选型连续批处理是分水岭传统推理服务往往借用训练框架来加载模型然后逐条处理请求。这种方式对在线服务来说太慢了吞吐也很低。业界后来发现一条关键优化路径动态批处理Continuous Batching。简单解释就是传统的一次等一批请求到齐再处理动态批处理则是“来一个处理一个”某个请求处理完立即释放资源接下一条。这让单实例吞吐提升数倍成为现代推理引擎的标配能力。选推理引擎时要重点关注几个指标支持的模型架构覆盖度、算子的极致优化程度、动态批处理实现的好坏、对量化格式的支持。比较成熟的开源方案之间性能差距有时很大关键差在算子上是否适配了特定型号的加速卡。4.2 推理优化三板斧量化、KV Cache、前缀复用动态批处理之上还有三个高频使用的优化手段一是权重量化。把模型权重从FP16压到INT8或INT4显存占用直接减半甚至减到四分之一。代价是精度略有损失。对追求低延迟的场景量化几乎是必选项。实际项目里我常用先量化再评估精度的流程如果偏差在可接受范围就直接上线。二是KV Cache。自回归生成的过程里每个token要读取之前所有token的上下文信息这些中间状态被缓存起来避免重复计算。KV Cache的显存占用和序列长度成正比长序列场景下可能占据推理显存的大头。控制它的大小、做KV Cache的量化压缩是长文本推理的核心话题。三是前缀复用。当多个请求共享相同的上下文前缀比如同一条系统提示词可以缓存前缀部分的计算结果只对新增内容做计算。这在聊天场景中效果非常明显能大幅降低首个token的延迟。推理服务还有一个容易忽略的指标首Token延迟和Token间延迟要分开衡量。前者决定用户“第一次看到回应”的体验后者决定整体流畅度。这两项对应的优化手段不同不能用同一个指标掩盖问题。4.3 在线服务的弹性与成本服务编排的进阶话题推理服务上线后流量通常是有波峰的。提前准备固定数量的实例低峰期浪费严重高峰期又容易超载。弹性的思路是让实例数跟随指标如GPU利用率、队列深度自动伸缩。这里我建议把伸缩逻辑建立在训练的指标采集上比如利用GPU自身的利用率指标和自定义的队列指标而不是只靠外部流量。多模型服务还有个成本优化思路模型分片混合部署。把不同模型的副本部署在同一个GPU上通过时间片或显存隔离方式共享硬件。这样可以提升资源利用率。我自己采用过的替代方案是先把不同模型的规格、流量、时延要求列成表然后做容量规划。同时建议关注显存碎片问题。推理引擎反复加载和卸载模型后显存碎片化会越来越严重最终导致明明看着还有空间却分配失败。定期重启或采用更积极的内存整理机制能缓解这个问题。5. 平台化与MLOps把AI工程能力沉淀成产品如果上面这些技术点都打通了最后一步就是把这些能力平台化让团队里的算法工程师、数据工程师、运维都能自助使用。平台化能力是一个组织AI工程成熟度的分水岭。5.1 我把AI平台拆成六个模块平台化不是把工具堆在一起而是把流程打通。我梳理出的六件套依次是数据管理、训练平台、模型管理、推理服务、监控告警、CI/CD。每个模块都有自己的关键设计决策数据管理要解决样本版本管理和数据质量监控。训练平台要解决资源申请、配额、优先级的自动化。模型管理要解决模型版本、指标、对应代码和参数的追溯。推理服务要解决灰度发布、流控和弹性。监控告警要覆盖硬件、框架、业务三层指标。CI/CD解决“代码合并后自动跑训练、自动评估、自动提审”的流水线。这六个模块不一定一次性都做齐但架构设计上要预留扩展性。我建议先做训练平台加模型管理跑通一条最小的闭环再逐步扩展。5.2 资源配额与多租户平台公平性的艺术多团队共用一个AI平台时“资源怎么分”是最敏感的话题。平台的资源配额设计直接影响团队间的信任度。我总结了三个原则第一配额必须显式化。每个团队应该能清楚看到自己的配额、已用量、排队任务。最忌讳的是平台“暗箱操作”会引发大量内部矛盾。第二要区分保障配额和弹性配额。给每个团队一个基础保障额度保证其核心业务不被挤占再设置一个弹性池空闲时大家都能抢占忙时按优先级回收。第三抢占策略要可解释。被抢占的任务应该收到明确的通知并且系统要支持自动重新排队甚至自动从检查点恢复。否则一次抢占可能导致团队多个小时的训练进度丢失。5.3 可观测性AI平台最容易烂尾的部分很多AI平台的监控做得很浅只采集硬件的CPU、内存、GPU利用率这种基础指标。但真正定位问题时这些指标往往不够。我在实践中发现有三层监控缺一不可系统层GPU的温度、功耗、卡间通信带宽、网络重传率。这层帮助判断硬件是否健康。框架层数据加载耗时占比、计算耗时占比、通信耗时占比、显存分配曲线。这层帮助判断瓶颈在哪。业务层模型训练的损失曲线趋势、吞吐变化、推理的延迟分位数和成功率。这层帮助判断实验进展和服务质量。这三层要串联成一个统一视图。比如数据加载耗时占比突然升高时系统层可能恰好能看到存储IO延迟飙升从而快速定位是存储问题还是网络问题。我强烈建议从一开始就做好指标打点和看板设计。补做监控的代价通常比想象中高出很多。6. 学习路径与实操心得从零搭建你的AI Infra知识体系最后这部分是我总结的学习路径和一些个人实践经验也是我觉得这份笔记最有价值的部分。6.1 我的推荐路线和环境准备如果从零开始学AI Infra我推荐按这个顺序推进每步设置一个验收目标打牢分布式基础2周搞懂并行策略、通信原语、一致性模型。验收标准是能手绘出数据并行和流水线并行的数据流图。单机多卡实践1个月在自己能接触到的环境上跑通一个中型模型的训练和推理。验收标准是会用工具查看显存分配、定位性能瓶颈。集群级能力建设1~2个月学习调度、存储、网络。验收标准是能设计并解释一个8节点集群的训练任务部署方案。平台化与产品化持续研究MLOps平台设计与开源方案。验收标准是能画出整体平台架构并说清模块之间的数据流。环境准备方面如果预算有限可以在云上按小时租用单个实例来练手先跑通训练链路再逐步增加规模。6.2 一些实际项目中的经验最后分享几段我个人的实操经验。先说性能分析。当训练速度不符合预期时我会按照“数据加载 → CPU计算 → 设备计算 → 通信同步”这条流水线逐步排查先看哪个环节占比异常再深挖原因。最经典的一次是分析显示计算利用率极低最后定位到是CPU端的batch拼接逻辑阻塞了数据供给加速卡大部分时间在等待。遇到突发的显存溢出错误时我建议先开激活重计算再降batch size都不行再考虑梯度累积或者卸载优化器状态。这套组合基本能覆盖九成以上的情况。最后是容错设计。训练任务里所有关键步骤都要有重试机制。但重试不是简单重新跑一遍要结合检查点做断点续训。同时对故障要做记录和分析看是硬件fail还是代码问题针对性地改配置。说到底AI Infra的知识量很大而且技术栈更新节奏非常快。但底层思路是稳定的先确认瓶颈在哪再选合适的优化手段最后把流程产品化沉淀下来。希望这份学习笔记能成为你建立自己知识体系的一个起点。后续我也在不断更新这个主题的实践经验欢迎同行一起交流踩坑心得。