1. 为什么 AI Infra 值得系统学一遍这两年“AI Infra”这个词被提得越来越多但很多人对它的理解还停留在“搞 GPU 的”“训模型的”“做推理加速的”这种碎片化印象里。我刚开始接触这块的时候也一样觉得会装个 CUDA、能跑通 PyTorch 分布式训练就算入门了结果真到了要优化一个线上推理服务的吞吐、要排查一个多机多卡训练任务为什么卡在某个 step 不动、要算清楚一套集群到底该配多少显存和带宽的时候才发现自己缺的不是某一个知识点而是一整条从底层硬件到上层落地的认知链路。AI Infra拆开看就是“支撑 AI 工作负载的基础设施”。它不是一个单点技术而是一套贯穿硬件、系统、框架、平台、运维的完整体系。往底层走它涉及 GPU/NPU 的架构、显存层级、互联拓扑、通信原语往中间走它涉及深度学习框架的执行机制、算子调度、内存管理、并行策略往上层走它涉及训练平台、推理服务、模型压缩、资源调度、监控告警。你很难只懂其中一层就把事情做好因为真实场景里的问题往往是跨层的——比如一个推理延迟抖动可能是算子实现的问题也可能是显存分配碎片化还可能是请求调度策略不合理。这篇文章想做的事情很明确给出一条从底层到落地的系统学习路径把 AI Infra 拆成几个可以逐个攻克的模块讲清楚每个模块该学什么、为什么这么学、学到什么程度算够用以及在实际操作中有哪些坑。适合谁看如果你是刚转方向的后端/算法工程师想补齐基础设施这块的能力如果你是在做训练/推理平台但总觉得知识零散、不成体系如果你是团队里被安排去搭一套 AI 环境但不知道从哪下手的人那这篇内容应该能帮你少走不少弯路。我不会把它写成教科书而是按一个从业者真实的学习和踩坑顺序来讲尽量让你看完就能动手。2. 先把 AI Infra 的知识地图画清楚2.1 从一次真实故障反推知识分层我先讲一个自己遇到过的真实问题用它来引出整个知识地图。之前有个多机训练任务8 台机器、每台 8 张卡跑一个中等规模的模型。现象是单机 8 卡跑得好好的一上多机吞吐不升反降而且 GPU 利用率忽高忽低。当时团队里有人说是网络问题有人说是数据加载瓶颈有人说是并行策略没配好。最后排查下来是三个问题叠加一是通信拓扑没对齐跨机通信走了低带宽路径二是数据加载的 worker 数不够喂不饱计算三是梯度同步的 bucket 设置不合理导致通信和计算没有重叠好。这个问题如果只懂一层根本解不了。它同时涉及硬件互联拓扑、系统配置worker 数、框架机制梯度 bucket 与通信重叠。这就是为什么我说 AI Infra 必须系统学——它的知识是分层的但问题是跨层的。我把整个 AI Infra 的知识体系分成五层从下往上依次是硬件与系统层GPU/NPU 架构、显存层级、互联技术、驱动与运行时、操作系统调优通信与并行层集合通信原语、通信库、数据并行/模型并行/流水并行、混合并行策略框架与执行层深度学习框架的执行机制、计算图、算子、内存管理、自动微分、编译优化平台与调度层训练平台、推理服务、资源调度、弹性伸缩、任务编排应用与落地层模型压缩、量化、蒸馏、服务化部署、性能监控、成本优化这五层不是孤立的越往上越贴近业务越往下越贴近物理极限。学习顺序上我建议从下往上打基础但不必等下面全学透再往上走可以交叉进行。比如你先了解 GPU 的基本架构和显存模型就可以去看框架是怎么管理显存的你先搞懂集合通信就可以去理解数据并行为什么会有通信开销。2.2 每层该学到什么程度很多人学 AI Infra 容易陷入两个极端要么只学上层调包遇到底层问题就抓瞎要么一头扎进硬件手册学了半天不知道有什么用。我的经验是每一层都有一个“够用线”到了这条线就可以往上走后面需要时再回来补深。层级够用线必须掌握进阶线按需深入硬件与系统GPU 显存层级、SM 概念、常见互联方式、驱动/CUDA 版本关系具体架构的 warp 调度、Tensor Core 细节、NVLink 拓扑优化通信与并行集合通信原语语义、数据并行原理、通信开销来源混合并行策略设计、通信压缩、拓扑感知调度框架与执行计算图执行流程、显存分配机制、算子调用链图编译优化、自定义算子、内存池实现平台与调度训练/推理平台基本组件、资源调度逻辑弹性训练、多租户隔离、异构资源调度应用与落地量化/蒸馏基本概念、服务化部署流程极致性能调优、成本模型、SLA 保障这张表不是让你背而是让你心里有数学到哪算阶段性完成哪些是后面遇到问题再补的。我见过太多人卡在硬件层出不来其实对大多数落地场景来说你不需要懂到电路级别够用就行。2.3 学习路径的节奏建议系统学习最怕的是“线性推进”因为 AI Infra 的知识密度不均匀有些地方很陡有些地方很平。我的建议是分三个阶段第一阶段建立全局认知大概两到三周。这个阶段不要抠细节目标是知道每一层大概在干什么、层与层之间怎么交互。可以看一些综述性的文章、框架的官方架构文档动手跑通一个单机训练和一个简单推理服务。第二阶段逐层深入大概两到三个月。按硬件、通信、框架、平台、应用的顺序每层花一到两周重点是把每层的核心机制搞懂并且动手做小实验验证。比如学通信就自己写个 all-reduce 的测试学显存管理就自己打印显存分配日志。第三阶段项目驱动长期。找一个真实的问题去解决比如优化一个模型的推理吞吐或者搭一个小型训练平台。这个阶段不再按层学而是遇到什么问题补什么知识会自然串联起来。提示不要试图把每一层都学到专家级别再动手AI Infra 的很多理解是在动手过程中形成的。先跑起来再优化再深入原理这个顺序比反过来高效得多。3. 底层硬件与系统别急着往上跑3.1 GPU 显存层级与访问代价学 AI Infra 绕不开 GPU而 GPU 最核心的概念之一就是显存层级。你可以把它想象成一个金字塔最上面是寄存器容量最小但最快往下是共享内存/一级缓存速度稍慢但容量大一些再往下是二级缓存最底下是全局显存容量最大但访问最慢。不同层级之间的带宽差距可能是几十倍甚至上百倍。为什么这个重要因为很多性能问题本质上是“数据放错了地方”。比如一个算子频繁访问全局显存那它大概率是访存瓶颈如果能把数据复用放在共享内存里性能可能提升好几倍。你在做推理优化时听到的“算子融合”“内存复用”本质上都是在减少对全局显存的访问。实际操作中你不需要手动管理这些层级框架和编译器会帮你做。但你需要能看懂现象当 GPU 利用率低但显存带宽打满时说明是访存瓶颈当计算单元利用率高但吞吐上不去时可能是指令依赖或调度问题。这些判断能力来自你对显存层级的理解。3.2 互联拓扑多卡多机为什么慢单卡时代你只需要关心一张卡自己的事。一旦上了多卡多机互联就成了关键。卡与卡之间、机与机之间的通信带宽和延迟差异巨大。同一台机器内卡之间可能通过高速互联连接带宽很高跨机器走网络带宽和延迟都差一个量级。这就解释了一个常见现象为什么有些并行策略在单机多卡上效果很好一到多机就崩。因为通信模式变了原本走高速互联的通信现在要走网络开销完全不一样。你在设计并行策略时必须考虑通信发生在哪一层是卡内、机内还是机间。能放在卡内的不要放到机间能机内解决的不要跨机。我自己的经验是做多机训练前先搞清楚你的集群拓扑哪些卡在同一台机器、机器之间怎么连、带宽各是多少。然后根据拓扑来切分模型和分配并行策略。很多“调参调不出来”的问题其实是拓扑没对齐。3.3 驱动、运行时与版本管理这一块听起来很无聊但它是无数人踩坑的地方。GPU 驱动、CUDA 运行时、深度学习框架、通信库这四者之间有严格的版本兼容关系。你随便升级其中一个可能整个环境就跑不起来了。我的做法是把整个软件栈的版本固定下来写成一个环境清单任何变更都走测试流程。具体来说记录驱动版本、CUDA 版本、cuDNN 版本、框架版本、通信库版本以及它们之间的兼容矩阵。不要相信“最新版就是最好的”在 AI Infra 里稳定比新更重要。注意环境问题占 AI Infra 实际排障时间的很大比例。与其出了问题再救火不如一开始就把版本管理做规范。容器化是一个好办法把整个环境打包避免“在我机器上能跑”的尴尬。4. 通信与并行多卡训练的命门4.1 集合通信原语的语义与代价多卡训练的核心是通信而通信的核心是集合通信原语。最常见的几个是 broadcast、all-reduce、all-gather、reduce-scatter。你不需要会手写这些原语的底层实现但必须理解它们的语义和代价。以 all-reduce 为例它的作用是把所有卡上的数据规约比如求和后再分发回所有卡。数据并行训练里梯度同步用的就是 all-reduce。它的通信量跟参数量成正比所以模型越大通信开销越大。理解这一点你就能明白为什么大模型训练需要各种通信优化梯度压缩、通信重叠、分层 all-reduce。这里有个容易混淆的点all-reduce 的通信量并不是简单地等于数据量。在 ring all-reduce 这类算法里通信量大约是数据量的两倍一轮 reduce-scatter 加一轮 all-gather。这个细节在你估算通信时间时很关键。4.2 数据并行、模型并行与混合并行数据并行是最容易理解的每张卡有一份完整模型喂不同的数据算完梯度后同步。它的优点是实现简单缺点是显存占用高因为每张卡都要存完整模型和优化器状态。模型大到单卡放不下时数据并行就不够了。模型并行是把模型切开放到不同卡上。切法有两种按层切流水并行和按张量切张量并行。流水并行把不同层放到不同卡数据像流水线一样流过张量并行把单个算子切开比如一个矩阵乘切成几块分别算。两者各有优劣流水并行通信少但有气泡张量并行通信多但并行度高。实际的大模型训练基本都是混合并行数据并行加张量并行加流水并行再配合各种优化。这里的关键不是记住有哪几种并行而是理解每种并行的通信模式、显存收益和适用场景然后根据你的模型大小、集群规模、带宽条件来组合。4.3 通信与计算的重叠这是多卡训练优化的核心技巧之一。理想情况下通信应该和计算重叠进行而不是串行等待。比如在反向传播算梯度的时候已经算好的梯度可以同时开始通信不用等全部算完。实现重叠的关键是分桶bucketing把梯度分成若干桶一个桶算完就触发通信同时继续算下一个桶。桶的大小很讲究太小了通信次数多、启动开销大太大了重叠效果差、等待时间长。这个参数没有万能值需要根据模型和硬件实测调整。我踩过的坑是一开始把 bucket 设得很大以为能减少通信次数结果重叠几乎没效果因为要等很久才凑满一个桶。后来调小 bucket通信和计算重叠明显改善但通信启动开销上来了。最后是通过实测找到一个平衡点。这个过程没有捷径就是多试几组参数看 profiling 结果。5. 框架与执行理解你每天用的工具5.1 计算图的执行流程深度学习框架的核心是计算图。你写的模型代码最终会被转换成一张图图里的节点是算子边是数据依赖。框架的执行引擎会按照依赖关系调度算子分配显存执行计算。理解这个流程的价值在于当性能出问题时你能定位到是图的问题还是算子的问题。比如你发现某个模型推理慢用 profiling 工具一看发现图里有很多小算子每个算子启动开销都不小那优化方向就是算子融合把小算子合并成大算子减少启动次数。动态图和静态图的区别也在这里。动态图灵活但每次执行都要重新构建图有额外开销静态图执行效率高但调试麻烦。现在很多框架走的是“动态图开发、静态图执行”的路线兼顾两者。你不需要纠结用哪种但要理解它们的取舍。5.2 显存管理机制显存是 AI Infra 里最稀缺的资源之一。框架的显存管理机制直接决定了你能跑多大的模型。核心概念是显存池框架不会每次分配都向系统申请而是预先申请一大块自己管理分配和回收。这样做的好处是减少系统调用开销坏处是容易产生碎片。碎片化是显存问题的常见原因。你可能会遇到明明总显存够但就是分配不出来因为碎片太多没有连续的大块。解决办法通常是调整分配策略或者用更激进的显存复用。有些框架提供了显存碎片整理的功能但会带来额外开销需要权衡。另一个关键概念是激活值重计算activation checkpointing。训练时前向传播的中间结果激活值需要保存下来供反向传播用这占大量显存。重计算的做法是不保存反向传播时重新算一遍。用计算换显存是大模型训练的常用手段。代价是训练变慢所以要选择性地重计算只对显存占用大的层做。5.3 算子与自定义算子算子是最小的计算单元。框架自带大量算子但总有覆盖不到的场景这时候就需要自定义算子。写自定义算子有两种方式一种是用框架提供的接口写简单但性能一般一种是用底层语言写性能好但开发成本高。我的建议是优先用框架自带算子实在不行再自定义。因为自定义算子的维护成本很高框架升级、硬件换代都可能要重写。如果非要写先确认瓶颈真的在算子上而不是在别的地方。我见过有人花大力气写了个自定义算子结果性能提升微乎其微因为真正的瓶颈在数据加载。6. 平台与调度从能跑到跑得好6.1 训练平台的核心组件当你从单机训练走向团队协作就需要训练平台。一个基本的训练平台包含几个部分任务提交与管理、资源调度、环境管理、日志与监控、模型存储。听起来简单但每个部分都有坑。任务提交这块关键是让用户用最简单的方式描述需求平台负责翻译成底层配置。比如用户说“我要 4 机 32 卡跑这个模型”平台要能自动分配资源、配置通信、拉起任务。资源调度要考虑公平性和效率既要防止有人占着资源不用又要让大任务能拿到足够资源。环境管理是容易被忽视但极其重要的一环。不同任务可能需要不同的框架版本、不同的依赖。容器化是主流方案但容器镜像的管理、分发、更新都是学问。镜像太大拉取慢镜像太小依赖不全。我的经验是分层构建镜像基础层放通用依赖应用层放任务特定依赖这样复用率高。6.2 推理服务的部署要点训练和推理是两回事。训练关注吞吐和收敛推理关注延迟和成本。推理服务部署要考虑几个问题模型加载、请求调度、批处理、弹性伸缩。批处理是推理优化的关键。单个请求可能用不满 GPU把多个请求攒成一批一起算能大幅提升利用率。但批处理会增加延迟因为要等请求攒够。这里有个权衡批越大吞吐越高但延迟越大。实际中常用动态批处理根据请求到达情况动态调整批大小。弹性伸缩是成本优化的关键。推理负载往往有波峰波谷固定资源要么浪费要么不够。弹性伸缩根据负载自动调整实例数但要注意冷启动问题新实例拉起需要时间模型加载也需要时间。如果伸缩太慢高峰期会扛不住如果太激进频繁伸缩又浪费资源。6.3 资源调度与多租户隔离多租户环境下资源调度和隔离是核心挑战。调度要解决“谁先用、用多少、用多久”的问题隔离要保证一个任务不会影响另一个任务。调度策略有很多种先来先服务、公平调度、优先级调度、抢占式调度。没有最好的只有最适合你场景的。研究团队可能更看重公平生产任务可能更看重优先级。关键是让策略透明用户知道自己的任务大概什么时候能跑。隔离这块GPU 的隔离比 CPU 难。CPU 有成熟的 cgroup 机制GPU 的隔离还在发展中。常见做法是整卡分配一张卡只给一个任务用简单但利用率低。更细粒度的共享需要硬件和软件支持目前还在演进。我的建议是如果对隔离要求高就整卡分配如果追求利用率就接受一定程度的共享风险。7. 应用与落地把技术变成价值7.1 模型压缩的三种手段模型压缩是落地的关键因为原始模型往往太大太慢。三种主要手段是量化、剪枝、蒸馏。量化是把高精度数值如 FP32转成低精度如 INT8。好处是显存占用小、计算快坏处是精度可能下降。量化分训练后量化和量化感知训练前者简单但精度损失大后者复杂但精度保持好。实际中常用混合精度关键层保持高精度其他层用低精度。剪枝是去掉模型中不重要的部分。结构化剪枝去掉整个通道或层硬件友好非结构化剪枝去掉单个权重压缩率高但硬件不友好。剪枝的难点是判断哪些部分不重要通常需要基于重要性评分。蒸馏是用大模型教小模型。大模型提供软标签小模型学习这些软标签往往比直接学硬标签效果好。蒸馏的关键是设计好损失函数平衡软标签和硬标签的权重。7.2 性能监控与瓶颈定位没有监控就没有优化。AI Infra 的监控要覆盖几个层面硬件层GPU 利用率、显存、温度、功耗、系统层CPU、内存、网络、磁盘、框架层算子耗时、通信耗时、显存分配、应用层吞吐、延迟、错误率。瓶颈定位的核心方法是 profiling。通过 profiling 工具你能看到时间花在哪里。常见的瓶颈有几类计算瓶颈GPU 算力打满、访存瓶颈显存带宽打满、通信瓶颈网络或互联打满、数据瓶颈数据加载跟不上、调度瓶颈GPU 空转等任务。定位到瓶颈后优化方向就明确了。计算瓶颈考虑算子优化或降低精度访存瓶颈考虑算子融合或数据复用通信瓶颈考虑通信压缩或重叠数据瓶颈考虑增加 worker 或优化数据格式调度瓶颈考虑调整批处理或调度策略。7.3 成本模型与优化取舍AI Infra 最终要算经济账。成本主要来自硬件GPU 采购或租用、电力、人力。优化目标是在满足 SLA 的前提下降低成本。一个实用的成本模型是总成本等于资源成本乘以使用时间再除以有效吞吐。要降成本要么减少资源要么缩短时间要么提升吞吐。这三者往往互相制约减少资源可能延长时间提升吞吐可能需要更多资源。我的经验是先找到成本大头再针对性优化。如果 GPU 成本占主导就优化 GPU 利用率如果人力成本占主导就提升自动化程度。不要盲目追求极致性能因为边际收益递减而复杂度上升。找到一个性价比平衡点比追求理论最优更实际。8. 常见问题与排查技巧实录8.1 训练类问题速查现象可能原因排查方向多机训练吞吐不升反降通信拓扑未对齐、通信开销过大检查拓扑、通信 profiling、调整并行策略GPU 利用率忽高忽低数据加载瓶颈、通信等待检查数据 pipeline、增加 worker、通信重叠训练卡在某个 step通信死锁、数据异常、显存溢出检查日志、单步调试、显存监控loss 不收敛或震荡学习率、批大小、并行策略影响调整超参、检查梯度同步、小规模复现显存溢出但总显存够显存碎片、激活值占用大显存 profiling、激活重计算、调整分配策略8.2 推理类问题速查现象可能原因排查方向推理延迟高批处理不当、算子未优化调整批策略、算子融合、量化吞吐上不去GPU 利用率低、请求调度差profiling、动态批处理、多实例延迟抖动大资源竞争、GC、批处理波动隔离资源、稳定批大小、监控精度下降量化损失、算子精度问题混合精度、量化感知训练、逐层验证8.3 几个独家避坑技巧第一个技巧任何环境变更前先做基线测试。记录当前环境的性能指标变更后再测对比差异。这样能快速判断变更是否引入问题。我见过太多人改了一堆配置出问题后不知道是哪个改动导致的。第二个技巧多机训练前先做通信基准测试。用简单的 all-reduce 测试实际带宽和延迟跟理论值对比。如果差距大先解决通信问题再跑训练否则后面所有优化都是白费。第三个技巧显存问题优先用工具看不要猜。框架通常提供显存快照功能能看到每个时刻的显存分配情况。很多“显存泄漏”其实是碎片或缓存看快照一目了然。第四个技巧性能优化要一次只改一个变量。同时改多个参数即使性能提升了你也不知道是哪个起的作用无法复现和推广。科学实验的方法在 AI Infra 里同样适用。9. 我自己的学习节奏和一些实在建议回过头看我学 AI Infra 最大的体会是这是一门实践性极强的学问光看书看文档远远不够。你可以把原理背得滚瓜烂熟但遇到真实问题还是可能懵。因为真实问题往往是多因素叠加的需要你有一套系统的排查方法而不是单点知识。我的学习节奏是这样的先花时间建立全局认知知道每一层在干什么然后挑一个最贴近当前工作的方向深入比如你主要做推理就先把推理相关的硬件、框架、服务化搞透最后在项目中不断遇到问题、解决问题知识自然就串起来了。不要追求一次学完AI Infra 太大没人能全懂关键是建立自己的知识框架遇到新问题能快速定位到框架的哪个位置。另外动手实验的价值远大于读文章。我学通信的时候自己写了个小程序测不同数据量下的 all-reduce 耗时画了条曲线对通信开销的理解一下子就具体了。学显存管理的时候自己打印显存分配日志看碎片是怎么产生的。这些实验花不了多少时间但理解深度完全不一样。最后分享一个小技巧建一个自己的“问题-排查-解决”笔记。每次遇到问题记录现象、排查过程、最终原因和解决办法。时间长了这就是你自己的知识库比任何教程都贴合你的实际场景。AI Infra 的问题有很多共性你踩过的坑下次大概率还会遇到有笔记就能快速定位。这个方向后续还可以往几个方向扩展一是异构计算除了 GPU 还有各种加速器怎么统一管理和调度二是绿色计算怎么在保证性能的同时降低能耗三是自动化怎么让调优和运维更智能。每一个都是大话题等基础打牢了再深入也不迟。
