AI Infra 知识全景学习笔记——这是我给自己过去半年多从零学习AI基础设施AI Infra交的一份期中作业。与其说是一篇技术教程不如说是我把踩过的坑、想通的点、验证过的方案按一条主线重新整理了一遍。为什么要写这份学习笔记因为市面上的干货虽然多但大多零散今天看一篇讲GPU调度的文章明天刷到一个讲分布式训练的PPT知识全是碎片状的很难形成体系。我也试过直接啃官方文档效率更低很多概念没有实际场景根本记不住。后来换了个思路先搭出全景图再顺着算力、数据、训练、推理、平台这条链路逐个击破。这篇文章就是这条学习路线的完整记录。如果你正在做AI Infra相关的工作或者打算入坑这个方向希望这份笔记能帮你少走一些弯路。1. 先对齐认知AI Infra到底在解决什么问题1.1 为什么这两年AI Infra这么火我身边不少改行的朋友一开始对AI Infra的理解就是给算法工程师装驱动、配GPU、搭环境。这个理解不算错但至少是不完整的。AI Infra的核心不是装环境而是解决一个根本矛盾模型越来越大算力需求越来越猛而单颗芯片的算力增长是有限的怎么把一堆芯片高效组织起来让几百甚至上千张GPU像一台机器那样协同工作。这个矛盾的直接推动力是大模型的参数规模。几年前跑一个几亿参数的模型单机四卡基本能搞定到了千亿参数这个量级单机已经完全吃不下必须拆到几十台机器上分布式的复杂性一下子全都涌出来了。神经网络结构怎么切分、梯度怎么同步、通信拓扑怎么设计、显存怎么平衡这些问题已经不是算法工程师能在代码层面解决的需要系统层专门的方案。另一个推动力是成本。GPU的价格摆在那里利用率上不去就是烧钱。很多公司的GPU集群跑大模型训练实际利用率能过50%就算不错大量算力浪费在等待、空转和通信上。AI Infra要做的就是把这些浪费挤出来让每一块GPU的每一分钟都在干活。所以我更愿意把AI Infra定义为面向AI工作负载训练、推理、数据加工的计算、存储、网络与调度系统的总称。它不是某一个开源项目也不是某一个云产品而是一整套把AI规模化落地的工程能力。1.2 AI Infra的五大核心板块我在整理学习笔记的时候把AI Infra拆成了五个板块这样学习起来不至于像无头苍蝇板块核心内容常见技术栈算力层GPU资源池化、调度、虚拟化、异构管理Kubernetes、容器运行时、GPU虚拟化方案数据层数据集存储、预处理、版本管理、数据管道对象存储、并行文件系统、数据编排工具训练层分布式训练框架、并行策略、弹性调度深度学习框架、集合通信库、任务调度器推理层模型优化、服务化部署、弹性伸缩、请求调度推理引擎、模型服务框架、网关平台层MLOps、工作流编排、可观测性、多租户管理流水线平台、监控系统、日志系统这五个板块不是孤立的它们之间有很强的依赖关系。训练层依赖算力层提供的GPU资源也依赖数据层把数据送到训练节点上推理层和训练层共享算力池但两者的调度逻辑完全不同。学习的时候顺着这条依赖链走思路会清楚很多。我的个人体会如果只记一个关键词那就是弹性。AI Infra的一切设计都在追求弹性——算力可伸缩、数据可流转、任务可调度、服务可扩缩。想清楚这一点很多方案选型就有了底层解题思路。2. 算力层GPU调度与资源池化的底层逻辑2.1 从GPU直挂到资源池化算力层是整个AI Infra的地基也是我学习时花时间最多的地方。先说一个最常见的误区很多人以为GPU调度就是把几张卡分给任务但实际上资源池化要解决的是碎片化问题。最原始的做法是GPU直挂——每台物理机插8张卡任务分配到具体机器上。这种模式最大的问题是如果某个任务只需要2张卡而机器上只有一些零散的空闲卡位这些卡就很难被充分利用。再加上不同业务对GPU型号的需求不同有的要训练卡有的要推理卡直挂模式很难做灵活的全局调度。资源池化的思路是把所有物理机的GPU抽象成一个逻辑上的大池子任务提交的时候由调度器决定它跑在哪台机器的哪些卡上。这个抽象层通常会引入Kubernetes用Device Plugin把GPU作为可调度资源暴露给集群任务以Pod的方式申请GPU资源。理解这个机制的时候可以打个比方传统模式像你把服务器整台租出去哪怕对方只用其中一小部分算力剩下的也不能给别人用了资源池化则像把服务器按CPU、内存、GPU拆成一块块积木按需组装给不同任务。还有一个绕不开的概念叫显存隔离。多任务共享同一张GPU时如果不做隔离一个任务可能把整张卡的显存打爆导致其他任务被系统杀掉。常见的隔离方式有两种一种是时间片共享多个任务轮流用GPU计算利用率高但可能引入性能波动另一种是显存隔离每个任务只用自己那部分显存互不干扰但隔离粒度有限。实际生产环境里两种方案经常混合使用需要在利用率和稳定性之间取平衡。2.2 调度器选型Kubernetes原生调度 vs 专用调度器我在做某跨平台系统模拟项目的时候卡在调度器选型上很久。用Kubernetes原生调度器优点是生态成熟、文档丰富但面对AI任务有两个痛点一是原生调度器的队列抢占能力弱大任务和小任务混跑时容易互相卡死二是对GPU拓扑感知不够无法感知同一台机器上8张卡是通过高速互联比如NVLink还是PCIe总线互连而这直接影响多卡任务的通信性能。后来我看了不少业界方案发现主要有两条路线一条是在Kubernetes之上做增强调度器支持Gang Scheduling全有或全无调度——这是训练任务的核心需求你想让8个Pod在8台机器上同时启动缺一个就全等着而不是让先启动的那几个在那里空转。另一条路线是引入独立的作业调度系统负责复杂的排队和优先级管理Kubernetes只做资源托管。这里给一个可落地的建议如果你的集群规模在几十张卡以内直接用Kubernetes原生调度器再加一个简单的配额控制就够了额外引入专用调度器的学习和运维成本都不划算到了百卡以上一定要认真考虑Gang Scheduling和任务排队机制否则你会频繁遇到大任务占着资源不动小任务排队等死的僵局。判断标准就一条你的任务是单卡就能跑的小作业多还是动不动就要求16卡、32卡的整体资源前者轻量调度够用后者必须上增强调度。2.3 异构算力调度的核心矛盾异构是算力层绕不开的话题。训练卡、推理卡、通用计算卡型号不同、架构不同、性能不同怎么统一调度这里的核心矛盾是效率优先还是灵活优先。严格按型号调度任务只能跑在特定机器上集群的灵活性就差了完全混跑性能较差的卡会拖累整个集群的吞吐。实际工程里常见做法是给GPU打标签按型号和代次分池池内共享、池间按策略调度。比如训练任务优先进入最新一代训练卡池推理任务进推理卡池某些紧急任务可以跨池调度但会做降级标记。还有一个细节经常被忽略GPU监控。一开始我以为GPU监控就是看利用率后来发现远不止。要关注显存带宽、功耗、温度、高速互联收发速率这些指标很多效率问题只有看细粒度指标才能定位。比如训练吞吐突然下降如果你只能看到GPU利用率100%你根本分不清是计算饱和还是通信等待但如果能看到NVLink的等待比例就能很快判断是通信瓶颈还是计算瓶颈。没有监控的算力池等于闭着眼睛开车。3. 数据层训练数据的流转与管理3.1 数据管道的三个环节说到数据层很多偏系统方向的同学容易忽略它但实际训练中数据往往是最大的瓶颈。数据层要解决三个环节的问题数据从哪来、怎么存、怎么送。从哪来对应数据采集和预处理。在大模型训练场景里原始数据通常是PB级的文本或图文先要经过清洗、去重、格式化变成可以直接喂给模型的样本。这一步是计算密集型的往往需要单独的预处理集群。我见过不少团队把预处理和训练混在一个集群上跑结果是预处理任务吃光了CPU和内存训练任务反而等数据整体效率反而下降。怎么存对应存储系统的选型。这里有个很关键的原则训练集和原始数据要分离。原始数据量大、访问频率低用对象存储最划算训练时需要高吞吐读要用并行文件系统或者高性能缓存层。很多团队的教训就是把训练数据丢在对象存储上直读训练速度被IO卡死。对象存储适合的是顺序读大文件而训练数据加载往往是大量小文件的随机读这两者的IO模型完全不一样。怎么送对应数据管道和缓存策略。训练节点要从远端拉取数据网络带宽和IO延迟都是瓶颈。常见的优化手段是数据预取——在GPU算力工作之前先把下一批数据在本地缓存好隐藏IO延迟。生产级框架的数据加载器都支持多线程预取这个细节对训练吞吐影响巨大。我自己实测过同一个训练任务预取线程数从默认1调到4数据加载耗时至少缩短一半。3.2 存储选型并行文件系统与对象存储的分工我整理了一个简单的选型对照基本能覆盖大多数训练场景的需求存储类型特点适用场景对象存储成本低、容量大、吞吐一般原始数据归档、备份、低频访问并行文件系统高性能、支持随机读写、元数据强训练时高频读样本、checkpoint写入本地NVMe极快、容量有限数据预取缓存、临时中间结果实际项目中数据管道的设计通常是三级原始数据放对象存储中间处理后的样本放并行文件系统训练节点本地NVMe做预取缓存。三者通过数据编排工具联动数据从一个层级流向另一个层级时由编排工具负责触发和校验。这里有一个我踩过的坑checkpoint模型检查点的写入。大模型训练每隔一段时间就要写一次checkpoint动辄几百GB如果直接写到远程存储训练要暂停很久甚至导致集群网络拥堵。后来学到的方案叫异步checkpoint先写本地NVMe再由后台线程异步推到远端存储让训练流程不阻塞。这个细节看着小但对长时间训练任务的稳定性和故障恢复效率影响非常大——写一次checkpoint如果能从5分钟压到30秒一个跑一个月的训练任务能省下好几个小时的停工时间。3.3 数据版本管理与一致性还有一个很多人不重视的问题数据版本管理。模型训练需要可复现性如果数据在训练过程中被改动跑出来的结果就说不清楚了。代码要用版本管理软件管数据同样要管理版本。业界常用做法是在数据目录上做快照或维护清单文件每次训练记录数据集的ID、哈希和路径。这样即使三个月后要重新复现当时的效果也能精确找回当时用的数据。更进一步是数据血缘。在流水线里上游数据变更要能触发下游任务的重新执行出问题时要能顺着链条快速定位是数据处理BUG还是模型代码BUG。我在搭建模拟流水线时因为没有做数据血缘一次数据清洗逻辑的变动导致模型评估指标异常排查了两天才发现是数据问题而不是模型问题。从那之后我把数据血缘当作和代码版本管理同等重要的事情来对待。4. 训练层分布式训练的关键点4.1 分布式训练的三种并行模式训练层是AI Infra最硬核的部分。分布式训练的核心问题是怎么把一个大模型拆到多张GPU上同时让它们协调一致地训练。常见的拆法有数据并行、模型并行、流水线并行三种。数据并行最好理解每张卡持有完整的模型副本喂不同的数据定期同步梯度。优点是实现简单张卡越多理论上训练越快缺点是模型必须能放进单卡显存一旦模型超过单卡显存数据并行就走不通了。模型并行是把模型按层或按算子切到多张卡上每张卡只负责一部分计算。按层切叫流水线并行各卡像工厂流水线一样依次处理一个batch的数据按算子切叫张量并行多卡共同计算同一个层的结果。实际大模型训练几乎都会混合使用这三种并行这就是常说的3D并行。具体怎么切讲究很多。张量并行为了提高计算效率通常会放在同一台物理机上——同一台机器内高速互联的带宽是跨机器的好几倍所以做张量并行的卡尽量落在同一台机器内流水线并行则相反它更需要微批量调度和负载均衡的配合避免某一段成为瓶颈。学习这部分时建议动手画一张并行切分图把一个Transformer模型具体切成块分配到卡上比死记概念有效得多。4.2 网络拓扑与集合通信如果说并行策略是训练层的软件设计那集合通信就是硬件和软件的接口。分布式训练中梯度同步、参数传播都依赖集合通信库的AllReduce、Broadcast等操作。通信效率直接决定训练加速比。我见过太多次明明加了GPU训练时长没怎么降的案例根因基本都是通信瓶颈。通信瓶颈和网络拓扑强相关同一台机器内部的高速互联和机器之间的以太网或高性能网络延迟和带宽差了一个数量级。设计集群时要尽量把通信频繁的并行组放在同一台机器内部把跨机通信量控制到最小。这里可以做一个粗略的估算。假设一次梯度同步需要传输100GB数据机器间网卡带宽是100Gbps换算成字节约12.5GB/s理论最短通信时间就是8秒如果训练一个step总耗时是16秒通信就占了50%加卡几乎不会带来线性加速。估算扩展效率的方法很简单先算出通信时间占一个step总时间的比例这个比例越小加卡越值。很多人不做这个预估盲目把任务从32卡扩到128卡结果发现吞吐没涨多少成本和复杂度倒上去了。4.3 训练任务的弹性与稳定性训练任务往往是长时任务一个小故障可能导致整个训练从头再来。所以弹性训练很重要——任务运行中某个节点掉线要被自动替换并恢复。这里涉及checkpoint机制和资源预留策略的配合。我学习时印象最深的是预占式调度调度器保留一部分冗余节点一旦主节点故障备用节点立即顶上去结合checkpoint恢复到最近的训练状态。这个设计让我意识到AI Infra其实也是可靠性工程不只是性能优化。做训练平台的同学建议从一开始就考虑故障恢复流程不要等集群规模大了再补课——到那时节点类型、存储布局、数据依赖都已经固化改起来代价非常大。5. 推理与服务化模型上线后的工程问题5.1 推理优化的几个方向训练是研发阶段推理是上线阶段两者的关注点完全不同。训练追求高吞吐和高资源利用率推理追求低延迟和高并发。推理的瓶颈往往不是计算本身而是模型体积、显存占用和请求调度。推理优化的第一件事是模型压缩。常见手段有量化把FP16模型转成INT8甚至更低精度、剪枝去掉不重要的参数、蒸馏用小模型学习大模型的能力。量化是效果最直接的手段性能提升通常是数倍。但量化也不是随便就能做的模型训练算子的动态范围、激活值分布都会影响量化后的精度。学习笔记里我特别标注了一个踩坑点量化后的模型在部分算子上的精度回退。特别是涉及动态范围和异常值较多的算子INT8量化很容易出现个别请求结果异常。后来采取的方案是混合精度量化——只对敏感性低的算子做8bit量化对关键敏感算子保留16bit精度推理速度和精度都兼顾了。这个案例很典型优化不是一刀切而是要看具体瓶颈和约束。5.2 服务化架构与弹性伸缩有了优化后的模型下一步是把它封装成服务。业界主流方案是用模型服务框架托管模型对外提供HTTP或RPC接口自动处理请求排队、动态批处理和并发。动态批处理是推理服务最核心的技巧之一把多个请求合并成一个大batch提高GPU利用率。但batch太大会让响应延迟升高所以需要根据实时流量动态调整batch大小和排队策略。服务化之后必然面对弹性伸缩问题。推理服务有明显的潮汐特征高峰期和低峰期流量差好几倍按峰值扩容浪费资源按均值扩容高峰时响应变慢。通用方案是基于GPU利用率或请求队列长度配置自动扩缩策略同时保留一定量的预热实例避免冷启动带来的超时。冷启动问题是我踩过的坑。模型加载到GPU显存需要时间新建Pod无法立即服务所以每次扩缩时都会出现几十秒的延迟毛刺。后来通过常驻模型镜像和预加载缓存解决了大部分问题——提前把常用模型加载到备用实例上流量一来就能立即响应。这个细节对线上推理服务的稳定性影响非常大很多团队只关注扩缩策略本身的配置却忽略了冷启动这个隐性成本。5.3 推理服务的高可用与发布策略推理服务直接面向线上流量高可用要求比训练更高。要注意的是推理服务的无状态化设计把模型文件、配置和运行时分离这样才能快速扩容。同时要多版本发布能力支持灰度发布和快速回滚。某次模拟项目里新版模型效果评测时出现线上效果劣化靠灰度发布快速回滚保障了线上稳定。这些工程能力看似老生常谈但AI Infra语境下的实现细节差异很大。普通服务的版本管理管的是代码和配置模型推理的版本管理要连同数据、环境、权重一起管还要对模型本身的输入输出做评测比对。也就是说模型上线不只是部署一个新容器而是要回答这个模型在真实流量下的表现是否真的更好这个问题。没有灰度评测机制模型迭代上线就是盲目的。6. MLOps与平台化把AI流程固化下来6.1 端到端流水线MLOps的核心目标是让AI流程可重复、可自动化。从数据准备、训练、评估、上线的全过程都应该变成流水线中的一个环节而不是靠人手动操作。流水线的设计逻辑是把每个环节封装成独立的组件组件间通过输入输出接口连接。这样做的好处是任何一个环节出问题可以只重跑该环节不必从头再来。我学习时尝试搭建过一个模拟流水线把数据清洗、训练、评估、推理服务几个步骤串了起来。最大的教训是流水线设计时就要考虑失败恢复而不是等失败后再补救。比如训练任务崩溃流水线应该自动从最近的checkpoint恢复而不是重新排队从零开始。这些细节如果不在设计阶段规划好后面在每个组件里临时加逻辑代码会变得一团糟。6.2 可观测性建设可观测性是我认为最容易知道但做不到的部分。GPU集群、训练任务、推理服务、数据管道每个层级都要有监控指标、日志和链路追踪。监控不只要看它挂了没有更要在它没挂但变慢了时能快速定位。学会看训练任务的时间线拆分——数据加载占比、计算占比、通信占比——是我学AI Infra以来最有收获的一个技能。有一次训练任务吞吐下降看整体监控全是绿的只有拆了时间线之后才发现通信占比从10%飙到了45%原因是另一个业务的流量占满了机器之间的网卡。这种问题如果不拆时间线基本只能靠猜。好的做法是建立统一的指标体系把GPU利用率、显存占用、网络吞吐、训练吞吐、推理延迟这些指标打到同一个监控大盘上。出问题时先看全局指标的变化趋势再逐层下钻定位根因。这套方法论跟传统运维是相通的但指标含义完全不同——比如网络吞吐高不一定是好事可能是集合通信效率低导致的无效传输。6.3 多租户与资源配额管理平台化必然要考虑多人使用的问题。不同团队、不同项目共享同一个算力池怎么避免邻居吵到自己资源配额管理和多租户隔离就是解决方案。我在学习时发现配额管理不只是给每个团队分多少卡这么简单还涉及优先级、抢占、资源预留这些策略的搭配。比如离线训任务和在线推理任务混跑在线推理的SLA要求高就需要在调度层面给推理任务更高的优先级或者让推理任务独占一部分资源。如果配额管理只做数字分配不做策略分层整个集群一旦忙起来线上服务立刻会被训练任务拖垮。7. 学习路径与踩坑实录7.1 我建议的学习顺序最后这部分是我学习AI Infra的路径总结给准备入坑的同学一个参考框架。我的建议顺序是先跑通一个小规模的深度学习训练任务亲身体会模型训练的基本流程、显存消耗和数据加载过程。再学Kubernetes基础理解Pod、调度、资源配置这些核心概念不碰AI相关内容。然后在Kubernetes上部署GPU运行环境研究设备插件的原理理解GPU是如何变成可调度资源的。尝试用多卡跑分布式训练对比不同并行策略的通信开销和加速效果。逐步深入数据管理和推理优化形成对全链路的认知。最后尝试构建端到端MLOps流水线把前面学的全部串起来。这个顺序的关键是先有深度再有广度——先把训练这条主链路跑顺再横向扩展。太多人一上来就散着学各种组件结果每个都是半吊子。我踩过的一个大坑就是顺序反了一上手就死磕Kubernetes网络插件和调度器源码结果很多概念因为没有上下文而完全无法理解。后面调整成从业务需求出发遇到什么问题就解决什么问题才真正入了门。学习AI Infra最怕只见树木不见森林先有全景图再逐块深入效率会高很多。7.2 资源清单与实践建议资料方面我学习时主要依赖几类来源官方文档特别是Kubernetes和深度学习框架的官方手册、知名公司的技术博客、开源项目的源码与Issue讨论。我的习惯是遇到问题先翻Issue而不是先搜解析文章因为Issue里往往有最真实的踩坑记录比二手转述靠谱得多。实践建议只有一个核心一定要自己动手搭一个最小闭环系统。哪怕只是单机Kubernetes 一张GPU 一个小模型训练任务的Demo也比只读几十篇文章有用。我自己是在搭某个最小演示环境时才真正弄懂了容器如何声明GPU资源、调度器如何分配显存、多Pod之间如何共享算力这些核心概念。不亲手部署一遍看再多的架构图都只是纸上谈兵。另外建议养成记录复盘的习惯。AI Infra的调试往往要跨多个子系统不把排查过程记下来下次遇到类似问题还是要从头开始。我的笔记里专门有一页记录异常现象→可能原因→排查步骤→最终根因的对照表排查效率提升非常明显。这份内部沉淀比在网上写再多的技术总结都更值钱。最后再分享一个学习心态AI Infra这个领域变化太快今天的主流方案明天可能就被新项目取代所以不要指望学完这件事更不要因为某个技术没学会而焦虑。把每次遇到的新问题当作补全自己知识图谱的机会等全景图补到一定程度你会发现解决问题的能力会有一个质的飞跃。这些内容后续如果大家感兴趣我大概率会先深入写调度器原理和推理优化的细节到时再和大家继续聊。