AI Infra全称 AI Infrastructure也就是AI基础设施。这几年但凡是做大模型训练、或者做AI业务落地的团队几乎都被这个词反复轰炸过。我个人的理解AI Infra 是一整套把算法想法变成线上可用服务的支撑系统它包含的不只是几块GPU而是从硬件资源、集群调度、训练推理框架、数据管道到模型上线后的监控运维一条完整的链路。这个方向有意思的地方在于它不像模型算法那样能发论文、出成果但所有算法效果都要靠它兜底。我自己这几年在几个项目里陆陆续续踩过不少坑从几十张卡的训练集群到多机多卡推理服务都碰过所以想把整理过的 AI Infra 全景学习笔记分享出来给正在入门这个方向、或者在边缘试探的开发者做一个参考。1. 先搭好框架AI Infra 到底包含哪些东西1.1 为什么 AI 需要自己的基础设施很多人问过我一个问题普通服务的后端基础设施就不能直接给 AI 用吗为什么非要单独谈 AI Infra还真不能直接用。传统的后端系统处理的是请求、交易、日志这类结构化业务逻辑压力模型是短请求、高并发、低延时。而 AI 负载是另一种脾气训练任务一跑就是几天几周数据吞吐以GB甚至TB级别计算资源的需求不是平滑的而是阶梯式的模型迭代一次要动辄上千卡小时。这两种模式挤在同一个基础设施里互相都难受。我习惯用一个类比来想这件事普通基础设施就像小区楼下的快餐店一个灶台一个锅高峰时期排队点单出餐是顺着的。AI Infra 更像是中央厨房它要考虑大批量食材的统一采购、预处理、冷藏、多档口配送还要应对突然爆单的峰值压力。没有这套体系你让每个算法工程师自己买锅买菜做出来口味千奇百怪出餐效率还极其低下。具体到 AI 场景基础设施要回答的问题很明确几千张卡同时训练一个模型网络带宽够不够会不会卡在通信上训练环境能不能一键复现昨天跑的代码今天还跑得出同样的结果资源利用率怎么提上去一堆卡闲置却有人排队等着跑任务模型训练完怎么安全地发布到线上出问题了怎么快速回滚这三四个问题如果解决不好算法团队再强也白搭。1.2 五大板块算力、调度、框架、数据、运维我自己的知识框架里把 AI Infra 拆成五个板块基本能覆盖一个 AI 团队的全部底层诉求板块解决的核心问题典型组件算力资源层提供计算、存储、网络的物理底座GPU、高速互联、高性能存储、冷热数据分层集群调度层把物理资源抽象成可申请、可分配的统一资源池容器编排系统、GPU调度插件、队列管理训练与推理框架让算法工程师专注于模型本身不用管底层细节分布式训练框架、推理加速引擎、模型服务框架数据管道层保证训练数据、特征、标签的稳定供给和一致性数据版本管理、特征平台、离线在线一致性校验MLOps 层管理模型实验、版本、发布和线上监控实验追踪、模型仓库、灰度发布、漂移检测这五个板块不是独立的是一条流水线。数据管道把处理好的数据喂给训练框架训练框架跑在调度层分配的算力上训练出来的模型通过 MLOps 流程发布成推理服务推理服务又要靠数据管道提供的特征做预测而底层的算力资源能不能扛住线上流量取决于调度和监控是否到位。任何一个环节掉链子整个体系都会崩。所以聊 AI Infra绝对不能只看某一个点。这也是为什么我把笔记叫全景学习笔记——不从全景切入学到最后很容易一直在某一个局部死磕却不知道它在整体图景中的位置。2. 算力底座异构硬件与集群组网2.1 计算硬件选型背后的那些参数大多数人认识 AI Infra 是从 GPU 开始的这没问题算力确实是底座中的底座。但选硬件不能只看卡多卡少要看几组关键参数。第一组是算力和显存。每一张卡的峰值算力一般以 TFLOPS 计决定了单位时间能跑多少次浮点运算而显存大小决定了你能不能装下大模型。前几年大家都在卷 FP16 算力后来大模型把显存容量和带宽也卷成了核心指标。我之前参与过一个模拟项目X当时拿到一批旧卡FP16 算力不够但显存很大跑大 batch 非常勉强最后只能降低批次大小吞吐上不去不说显存利用率也惨不忍睹。选型之前一定要先估算你的模型规模、数据精度和训练吞吐需求再反推卡型别被卡多就是爷带偏。第二组是卡间互联。单卡算力再强如果卡和卡之间通信带宽低分布式训练一样跑不快。这里要关注每张卡的互联带宽比如某头部厂商的高速互联协议能够提供远超同行的卡间带宽。实践中的感受是卡间互联对通信密集型算子比如 AllReduce的影响是决定性的。我见过一个团队训练效率一直上不去排查半天发现是网卡配置问题卡间互联走的是低速链路带宽整整降了一个量级。这种问题你不实测真的发现不了。第三组是生态成熟度。硬件不是只跑一版代码就完事后面还有调试、优化、新算子开发。选择硬件一定要看软件栈成熟不成熟驱动、编译器、深度学习框架的适配程度。某个硬件 FP16 理论算力标得很高但主流框架不支持和算子覆盖不全实际用起来性能差一大截。生态成熟度往往比纸面参数更重要。硬件的几个选型经验我一直记在笔记里训练场景优先看显存容量和卡间互联推理场景优先看算力密度和功耗同一个集群尽量保证硬件型号一致异构虽可行但调度和通信都会复杂很多一定要预留扩展位电源、散热、机柜空间这些运维细节比卡贵多了2.2 集群组网和高性能存储决定训练效率的隐形天花板单机多卡和集群训练有一个最大的区别通信开销。数据并行训练中每迭代一步都要把梯度同步一次假设模型参数量是 70B700亿一个梯度张量的体量就有几百GB。如果节点间通信带宽不够整个训练过程的大部分时间都花在等梯度上算力再强也没用。这里有一个基本概念叫集合通信Collective Communication常见的原语包括 Broadcast、AllReduce、AllGather 等。训练框架在不同节点之间同步参数时用的就是这些原语。选型时集群内部的交换机架构、网卡协议比如某高速以太网还是某专用互联协议、拓扑结构是胖树还是 Torus都要仔细了解。之前某训练集群出现过莫名其妙的性能抖动最终定位结果是几个节点跨交换机通信时走了绕路拓扑光改一段路由配置训练吞吐就恢复了将近一半。存储同样是隐形瓶颈。训练时数据读取是持续不断的如果存储系统扛不住高并发读GPU 就饿肚子。生产级的方案通常会用并行文件系统如某开源并行文件系统或高性能对象存储缓存把热数据放在 NVMe 层把冷数据下沉到廉价存储。数据管道的经验是训练数据的首次预处理一定要充分转成高效二进制格式如 TFRecord 这类概念别让训练时每步做格式转换把数据预读取和数据增强放到独立的数据加载进程里用预取流水线掩盖 IO 延迟缓存策略要有同一个 epoch 的数据不重复从远端拉取这一层看似是纯运维的事但它是整个 AI Infra 的地基。地基塌了上面的一切都没意义。3. 集群管理从裸机到容器化调度3.1 容器化为什么成了 AI 集群的标配最早做训练大家是直接在裸机上装环境。后来发现太痛苦了A 同学在 Python 3.10 配了新版依赖B 同学还是旧版有的任务依赖 CUDA 某个小版本升级一下驱动整个集群都炸。环境冲突和依赖地狱能把团队沟通成本拖垮。容器化解决的正是环境一致性问题。把代码、依赖、运行环境打包成一个镜像不管拆到哪台机器上跑行为都是一样的。现在容器编排系统已经是事实标准它能统一管理集群里所有机器的资源把任务Job调度到合适的节点上并且做好故障恢复和资源隔离。容器编排系统里有几个核心概念我用自己的话梳理一遍Pod调度和运行的最小单元一个 Pod 可以包含一个或多个容器共享网络和存储Job负责运行一个一次性任务训练任务就是典型的 Job 形态Namespace资源配额和权限的隔离维度不同团队可以各占一个空间设备插件机制让异构加速卡能够被编排系统感知和分配在 AI 集群里GPU 的调度是特殊需求。普通容器编排系统默认将 GPU 视为一个可计数的资源单位但这远远不够。现在主流方案是通过设备插件把 GPU 的设备信息注册给调度器让它可以感知每张卡的显存、剩余算力甚至同一张卡上可以切片出多个计算实例供多个任务共享。我看过一些团队的内部实践他们甚至做了一个自定义调度器扩展专门处理多实例 GPU的分配和回收。3.2 调度策略排队、抢占与资源碎片整理有了容器化只是第一步更大的挑战是资源怎么分。训练任务分两种一种是一次性批跑任务跑完就结束另一种是常驻服务比如在线推理它会长期占用资源。混合部署在调度上很容易打架。这里就涉及调度器的设计取舍优先级、配额、抢占、排队。优先级不同任务可以设置不同优先级重要训练任务可以插队配额按团队或项目划分资源上限避免某个团队把资源全部吃光抢占高优先级任务可以抢占低优先级任务的资源但要做好抢占后的任务恢复队列把任务按照权重进行排队类似操作系统的进程调度我的实际经验是GPU 资源的碎片化最让人头疼。假设集群里有 8 张卡的节点如果一个小任务申请了 2 张卡、一个大任务要 6 张卡调度器怎么安排都会造成资源浪费。跑了很多年集群的朋友应该都有这种体会明明统计下来 GPU 利用率不到 50%但每个人申请卡时都觉得自己缺卡。问题的根源就是资源碎片没能被有效合并。解决思路大致有三类把大任务拆小提高资源申请成功率利用 GPU 共享技术把多个小负载塞进同一张卡提高单卡利用率调度器的 bin packing 策略尽量把负载聚拢到部分节点上腾出完整节点给大任务这层调度逻辑做得好不好直接决定了集群的实际效率。如果团队里有人说集群扩展到了几千张卡但效率上不去十有八九是这层出了问题。4. 框架与工具链训练、推理、服务化4.1 分布式训练的并行策略数据、模型、混合训练框架是算法工程师接触最多的层次。单机单卡训练的时代已经过去现在只要模型一上规模就必须考虑分布式训练。业内常用的并行策略有四种数据并行是最容易理解的把训练数据切成多份每张卡拿到其中一份每个卡上保存一份完整模型副本每轮迭代后把梯度做 AllReduce 同步。它的优点是实现简单、扩展性好缺点是对显存要求高——模型必须能装进单卡。模型并行把模型本身切成多份分配到不同卡上每张卡只负责一部分模型的计算。适合单卡装不下的超大模型。但它对通信要求极高层与层之间需要频繁传输中间激活值。流水线并行是模型并行的一种优化形态它把模型按层切分到不同设备上同时让多个微批次micro-batch在不同设备之间流水式执行。好处是设备间通信压力低于纯模型并行坏处是存在流水线气泡设备空闲等待的时间段需要用好的调度策略去填充。混合并行就是同时使用以上多种策略。对于千亿参数级别的模型通常会结合数据并行、张量并行、流水线并行再加上专家并行之类的更细粒度策略。实操中的建议是先跑通数据并行再逐步加入其他并行策略每一步都做性能基准测试别一上来就上最复杂的配置。我之前在一个模拟项目里调分布式训练刚开始用数据并行收敛速度总是上不来后来用 Profiler 工具一测发现通信占比超过 60%也就是说大部分时间卡都在等同步。后来把 AllReduce 改成梯度压缩加延迟同步通信开销降了一大截训练吞吐直接翻倍。这个优化思路对很多大规模训练场景都有效。4.2 推理优化延迟、吞吐、成本的三角博弈训练完成后模型要上线对外服务这就进入推理优化和服务化阶段。推理和训练的需求是两回事训练看重吞吐量推理看重延迟和稳定性。线上推理的优化手段我整理了从模型侧到系统侧的几条线模型侧最常用的是量化。把 FP32 的权重压缩成 FP16、INT8甚至更低精度。量化能带来显存减半、推理加速近一倍的效果但要注意精度损失。可以先做 PTQ训练后量化效果不够再用 QAT量化感知训练。系统侧推理引擎优化很关键。主流的推理加速引擎会做算子融合把多个算子合并成一个内核、内存复用和计算图优化减少 GPU 的空闲等待时间。启用这类引擎后同一模型在延迟上经常能提升一个数量级。服务化侧动态批处理和缓存是提升吞吐的秘密武器。在线推理请求是稀疏到达的如果每个请求来了就立刻算GPU 占用率很低。把短时间窗口内的多个请求聚合成一个批次一起推理单位时间处理的请求数能大幅提升。再加上结果缓存重复的请求直接走缓存不用真正计算。这里有个平衡要把握动态批处理不是越大越好要设置最大延迟预算否则请求等待时间会超标。线上服务的 SLOService Level Objective服务水平目标通常会给一个延迟上限如 P99 200ms你要在这个约束下去调自己想要的批次大小。成本和体验永远是一对需要调和的需求。5. 数据管道与 MLOps让模型持续可迭代5.1 数据管道特征一致性是一个大坑很多人跟模型打交道时会忽略一个环节——数据管道。但根据我的经验线上模型效果崩掉十有八九不是模型代码的问题而是训练数据和线上数据对不上了。这句话怎么理解训练时你从离线数仓里取数据做特征工程然后喂给模型。上线后线上推理服务也是实时算特征喂给同一套模型。如果离线特征的计算逻辑和线上特征的计算逻辑不完全一致——比如排序方式不同、某个字段的空值处理逻辑不同、特征归一化参数不同——就会导致训练和推理的特征分布发生偏移这在行业里叫 train/serve skew。解决方案是建立一套特征平台统一特征计算逻辑。离线训练和在线推理共用同一套特征定义或者至少保证特征逻辑的单一来源。更严格的做法是线上推理时会记录特征快照定期用线上特征回放离线训练流程对比两者效果。很多团队在这上面栽过跟头某团队曾经发布了一版新模型A/B 测试效果一直异常最后排查发现是线上特征平台某字段的取值变了而离线训练用的还是旧逻辑。这种问题隐蔽性极高。数据版本化也很重要。训练数据不是一成不变的今天一批数据下周又追加一批。如果没有版本管理你根本无法复现上周那个模型为什么效果不错。数据版本管理要记录数据的来源、生成时间、处理逻辑、样本分布统计这样每次实验都有据可查。5.2 MLOps模型上线只是开始不是结束模型上线之后工作才完成一半。没有可靠的 MLOps 体系模型线上运行期就是裸奔。MLOps 的核心内容包括实验追踪、模型仓库、发布策略、线上监控四个环节。实验追踪解决的是这次实验用了什么配置、什么数据、什么代码的问题。所有训练的日志、指标、超参数、模型权重都记录在一个实验追踪系统里很多团队会自研这样后续要做模型对比、问题回溯都有依据。很多团队一开始不重视等到模型迭代了几十版之后想找一个之前效果最好的模型发现完全找不到了只能重跑。浪费时间也磨人心态。模型仓库把训练好的模型统一管理起来可以做版本登记、审批、上线前评估。一个模型从训练到上线至少要经过离线评测、影子测试shadow mode、金丝雀发布canary、全量发布这几个阶段。影子测试是把新模型和线上老模型同时跑只记录输出不改变真实决策用来观察差异。金丝雀发布则是只让一小部分流量走新模型观察指标没问题后再逐步放量。线上监控是整个 MLOps 里最容易被偷懒的部分。除了常规的 CPU、内存、延迟、错误率监控外模型特有的监控还包括输入特征分布漂移检测模型看到的输入是不是和训练时一致、输出分布漂移检测、以及业务指标监控。一旦发现指标异常要有自动回滚机制。我见过一个线上事故因为数据处理逻辑变更导致模型预测分布整体偏移监控系统一直没有告警等到业务方反馈时已经影响了几小时流量。如果当时有特征分布漂移检测这种事故完全可以提前拦截。6. 学习路径与避坑实录6.1 给入门者的学习顺序建议AI Infra 涉及的知识面非常广很多人一上来就蒙了不知道从哪里开始。我推荐的学习顺序不是从头读理论而是倒着学。第一步先亲手跑一次完整的模型训练和推理。用最简单的方式在一台机器上跑通一个图像分类或文本生成任务了解模型从训练到保存、再到加载推理的完整流程。这一步的目的是建立整体的肌肉记忆知道每个环节在做什么。第二步拆掉单机环境改成单机多卡训练。体验数据并行看看加了后性能提升了多少学会观察 GPU 利用率、训练吞吐这些指标。这一步会让你第一次意识到通信、数据加载这些非模型因素有多重要。第三步把训练任务放到容器里再上集群调度。学习容器编排系统的基本操作提交一个训练任务、查看日志、扩容缩容、设置资源限制。这个阶段可以把任务跑到多个节点上体会分布式训练的通信开销。第四步开始研究模型的推理优化。把训练好的模型做量化、加速引擎优化部署成在线服务压测一下延迟和吞吐。这一步能让你理解性能工程的价值。第五步再回头补理论。这个时候你对分布式并行、调度策略、存储这些概念已经有了具体感知再看论文、源码、架构文档都不再是空中楼阁。我特别推荐去读一些大厂公开的架构设计文档看他们是怎么在真实场景中取舍的。这个路径的核心逻辑是先建立体感再补理论。如果倒过来先啃理论很容易学了一个月还在概念的沼泽里爬不出来。6.2 我踩过的那些坑这几年实际操作下来我踩过不少坑挑几个典型的记录下来希望你别再踩常见问题现象排查思路与解决建议GPU 显存 OOM模型跑到一半任务崩溃检查 batch size 和模型参数量 是否匹配用显存分析工具看峰值显存消耗考虑梯度累积或混合精度训练训练吞吐上不去GPU 利用率很低但没人知道为什么用 Profiler 工具分析 数据加载、计算、通信三个阶段的时间占比定位瓶颈后针对性优化环境依赖不一致A 同学能跑、B 同学跑不了尽早全面容器化代码、依赖、系统版本都固化为镜像镜像要打版本标签集群出现性能神秘波动同一任务有时快有时慢检查网络拓扑、存储并发、其他任务干扰搭好监控大盘用数据复盘不要凭感觉排查模型上线后效果不如预期离线评测很好线上指标崩了检查训练与推理的特征一致性做影子测试对比新旧模型看特征漂移监控最想强调的一个教训是AI Infra 的排查永远要优先看数据而不是凭直觉。很多问题表面上是模型问题、代码问题实际往下一查是存储并发过高、网络路由异常、或者调度器配置不合理。没有一整套监控和日志体系排查这些问题就像在黑屋子里找一只黑猫。我第一次做大集群调优的时候调一个性能问题调了整整两天各种怀疑分布式框架的毛病最后发现只是某个节点的驱动版本和集群其他节点不一致导致通信超时频繁重试。从那以后我学乖了在任何深入排查之前先把环境一致性检查一遍再上监控大盘看指标这至少能筛掉一半的幽灵问题。另外想提一句心态上的经验AI Infra 是一个非常慢的方向不像算法领域几行代码就能看到一个提升效果。它需要你耐得住性子在日志、指标、配置这些琐碎细节里反复琢磨。但恰恰是这些琐碎细节构成了 AI 系统稳定运行的底盘。最后分享一个小技巧学习 AI Infra 阶段一定要多做对比实验。比如同一个训练任务分别用裸机、容器、共享 GPU 三种方式跑记录下延迟和吞吐你会发现自己的理解会从概念层面落到数值层面很多东西一下子就通了。这个习惯我一直保持到现在也是我学习速度比较快的原因。 
长河君 · 2026/10/20 15:55:09 · 阅读 1.2k AI基础设施全景学习笔记：从算力调度到MLOps实践
AI Infra全称 AI Infrastructure也就是AI基础设施。这几年但凡是做大模型训练、或者做AI业务落地的团队几乎都被这个词反复轰炸过。我个人的理解AI Infra 是一整套把算法想法变成线上可用服务的支撑系统它包含的不只是几块GPU而是从硬件资源、集群调度、训练推理框架、数据管道到模型上线后的监控运维一条完整的链路。这个方向有意思的地方在于它不像模型算法那样能发论文、出成果但所有算法效果都要靠它兜底。我自己这几年在几个项目里陆陆续续踩过不少坑从几十张卡的训练集群到多机多卡推理服务都碰过所以想把整理过的 AI Infra 全景学习笔记分享出来给正在入门这个方向、或者在边缘试探的开发者做一个参考。1. 先搭好框架AI Infra 到底包含哪些东西1.1 为什么 AI 需要自己的基础设施很多人问过我一个问题普通服务的后端基础设施就不能直接给 AI 用吗为什么非要单独谈 AI Infra还真不能直接用。传统的后端系统处理的是请求、交易、日志这类结构化业务逻辑压力模型是短请求、高并发、低延时。而 AI 负载是另一种脾气训练任务一跑就是几天几周数据吞吐以GB甚至TB级别计算资源的需求不是平滑的而是阶梯式的模型迭代一次要动辄上千卡小时。这两种模式挤在同一个基础设施里互相都难受。我习惯用一个类比来想这件事普通基础设施就像小区楼下的快餐店一个灶台一个锅高峰时期排队点单出餐是顺着的。AI Infra 更像是中央厨房它要考虑大批量食材的统一采购、预处理、冷藏、多档口配送还要应对突然爆单的峰值压力。没有这套体系你让每个算法工程师自己买锅买菜做出来口味千奇百怪出餐效率还极其低下。具体到 AI 场景基础设施要回答的问题很明确几千张卡同时训练一个模型网络带宽够不够会不会卡在通信上训练环境能不能一键复现昨天跑的代码今天还跑得出同样的结果资源利用率怎么提上去一堆卡闲置却有人排队等着跑任务模型训练完怎么安全地发布到线上出问题了怎么快速回滚这三四个问题如果解决不好算法团队再强也白搭。1.2 五大板块算力、调度、框架、数据、运维我自己的知识框架里把 AI Infra 拆成五个板块基本能覆盖一个 AI 团队的全部底层诉求板块解决的核心问题典型组件算力资源层提供计算、存储、网络的物理底座GPU、高速互联、高性能存储、冷热数据分层集群调度层把物理资源抽象成可申请、可分配的统一资源池容器编排系统、GPU调度插件、队列管理训练与推理框架让算法工程师专注于模型本身不用管底层细节分布式训练框架、推理加速引擎、模型服务框架数据管道层保证训练数据、特征、标签的稳定供给和一致性数据版本管理、特征平台、离线在线一致性校验MLOps 层管理模型实验、版本、发布和线上监控实验追踪、模型仓库、灰度发布、漂移检测这五个板块不是独立的是一条流水线。数据管道把处理好的数据喂给训练框架训练框架跑在调度层分配的算力上训练出来的模型通过 MLOps 流程发布成推理服务推理服务又要靠数据管道提供的特征做预测而底层的算力资源能不能扛住线上流量取决于调度和监控是否到位。任何一个环节掉链子整个体系都会崩。所以聊 AI Infra绝对不能只看某一个点。这也是为什么我把笔记叫全景学习笔记——不从全景切入学到最后很容易一直在某一个局部死磕却不知道它在整体图景中的位置。2. 算力底座异构硬件与集群组网2.1 计算硬件选型背后的那些参数大多数人认识 AI Infra 是从 GPU 开始的这没问题算力确实是底座中的底座。但选硬件不能只看卡多卡少要看几组关键参数。第一组是算力和显存。每一张卡的峰值算力一般以 TFLOPS 计决定了单位时间能跑多少次浮点运算而显存大小决定了你能不能装下大模型。前几年大家都在卷 FP16 算力后来大模型把显存容量和带宽也卷成了核心指标。我之前参与过一个模拟项目X当时拿到一批旧卡FP16 算力不够但显存很大跑大 batch 非常勉强最后只能降低批次大小吞吐上不去不说显存利用率也惨不忍睹。选型之前一定要先估算你的模型规模、数据精度和训练吞吐需求再反推卡型别被卡多就是爷带偏。第二组是卡间互联。单卡算力再强如果卡和卡之间通信带宽低分布式训练一样跑不快。这里要关注每张卡的互联带宽比如某头部厂商的高速互联协议能够提供远超同行的卡间带宽。实践中的感受是卡间互联对通信密集型算子比如 AllReduce的影响是决定性的。我见过一个团队训练效率一直上不去排查半天发现是网卡配置问题卡间互联走的是低速链路带宽整整降了一个量级。这种问题你不实测真的发现不了。第三组是生态成熟度。硬件不是只跑一版代码就完事后面还有调试、优化、新算子开发。选择硬件一定要看软件栈成熟不成熟驱动、编译器、深度学习框架的适配程度。某个硬件 FP16 理论算力标得很高但主流框架不支持和算子覆盖不全实际用起来性能差一大截。生态成熟度往往比纸面参数更重要。硬件的几个选型经验我一直记在笔记里训练场景优先看显存容量和卡间互联推理场景优先看算力密度和功耗同一个集群尽量保证硬件型号一致异构虽可行但调度和通信都会复杂很多一定要预留扩展位电源、散热、机柜空间这些运维细节比卡贵多了2.2 集群组网和高性能存储决定训练效率的隐形天花板单机多卡和集群训练有一个最大的区别通信开销。数据并行训练中每迭代一步都要把梯度同步一次假设模型参数量是 70B700亿一个梯度张量的体量就有几百GB。如果节点间通信带宽不够整个训练过程的大部分时间都花在等梯度上算力再强也没用。这里有一个基本概念叫集合通信Collective Communication常见的原语包括 Broadcast、AllReduce、AllGather 等。训练框架在不同节点之间同步参数时用的就是这些原语。选型时集群内部的交换机架构、网卡协议比如某高速以太网还是某专用互联协议、拓扑结构是胖树还是 Torus都要仔细了解。之前某训练集群出现过莫名其妙的性能抖动最终定位结果是几个节点跨交换机通信时走了绕路拓扑光改一段路由配置训练吞吐就恢复了将近一半。存储同样是隐形瓶颈。训练时数据读取是持续不断的如果存储系统扛不住高并发读GPU 就饿肚子。生产级的方案通常会用并行文件系统如某开源并行文件系统或高性能对象存储缓存把热数据放在 NVMe 层把冷数据下沉到廉价存储。数据管道的经验是训练数据的首次预处理一定要充分转成高效二进制格式如 TFRecord 这类概念别让训练时每步做格式转换把数据预读取和数据增强放到独立的数据加载进程里用预取流水线掩盖 IO 延迟缓存策略要有同一个 epoch 的数据不重复从远端拉取这一层看似是纯运维的事但它是整个 AI Infra 的地基。地基塌了上面的一切都没意义。3. 集群管理从裸机到容器化调度3.1 容器化为什么成了 AI 集群的标配最早做训练大家是直接在裸机上装环境。后来发现太痛苦了A 同学在 Python 3.10 配了新版依赖B 同学还是旧版有的任务依赖 CUDA 某个小版本升级一下驱动整个集群都炸。环境冲突和依赖地狱能把团队沟通成本拖垮。容器化解决的正是环境一致性问题。把代码、依赖、运行环境打包成一个镜像不管拆到哪台机器上跑行为都是一样的。现在容器编排系统已经是事实标准它能统一管理集群里所有机器的资源把任务Job调度到合适的节点上并且做好故障恢复和资源隔离。容器编排系统里有几个核心概念我用自己的话梳理一遍Pod调度和运行的最小单元一个 Pod 可以包含一个或多个容器共享网络和存储Job负责运行一个一次性任务训练任务就是典型的 Job 形态Namespace资源配额和权限的隔离维度不同团队可以各占一个空间设备插件机制让异构加速卡能够被编排系统感知和分配在 AI 集群里GPU 的调度是特殊需求。普通容器编排系统默认将 GPU 视为一个可计数的资源单位但这远远不够。现在主流方案是通过设备插件把 GPU 的设备信息注册给调度器让它可以感知每张卡的显存、剩余算力甚至同一张卡上可以切片出多个计算实例供多个任务共享。我看过一些团队的内部实践他们甚至做了一个自定义调度器扩展专门处理多实例 GPU的分配和回收。3.2 调度策略排队、抢占与资源碎片整理有了容器化只是第一步更大的挑战是资源怎么分。训练任务分两种一种是一次性批跑任务跑完就结束另一种是常驻服务比如在线推理它会长期占用资源。混合部署在调度上很容易打架。这里就涉及调度器的设计取舍优先级、配额、抢占、排队。优先级不同任务可以设置不同优先级重要训练任务可以插队配额按团队或项目划分资源上限避免某个团队把资源全部吃光抢占高优先级任务可以抢占低优先级任务的资源但要做好抢占后的任务恢复队列把任务按照权重进行排队类似操作系统的进程调度我的实际经验是GPU 资源的碎片化最让人头疼。假设集群里有 8 张卡的节点如果一个小任务申请了 2 张卡、一个大任务要 6 张卡调度器怎么安排都会造成资源浪费。跑了很多年集群的朋友应该都有这种体会明明统计下来 GPU 利用率不到 50%但每个人申请卡时都觉得自己缺卡。问题的根源就是资源碎片没能被有效合并。解决思路大致有三类把大任务拆小提高资源申请成功率利用 GPU 共享技术把多个小负载塞进同一张卡提高单卡利用率调度器的 bin packing 策略尽量把负载聚拢到部分节点上腾出完整节点给大任务这层调度逻辑做得好不好直接决定了集群的实际效率。如果团队里有人说集群扩展到了几千张卡但效率上不去十有八九是这层出了问题。4. 框架与工具链训练、推理、服务化4.1 分布式训练的并行策略数据、模型、混合训练框架是算法工程师接触最多的层次。单机单卡训练的时代已经过去现在只要模型一上规模就必须考虑分布式训练。业内常用的并行策略有四种数据并行是最容易理解的把训练数据切成多份每张卡拿到其中一份每个卡上保存一份完整模型副本每轮迭代后把梯度做 AllReduce 同步。它的优点是实现简单、扩展性好缺点是对显存要求高——模型必须能装进单卡。模型并行把模型本身切成多份分配到不同卡上每张卡只负责一部分模型的计算。适合单卡装不下的超大模型。但它对通信要求极高层与层之间需要频繁传输中间激活值。流水线并行是模型并行的一种优化形态它把模型按层切分到不同设备上同时让多个微批次micro-batch在不同设备之间流水式执行。好处是设备间通信压力低于纯模型并行坏处是存在流水线气泡设备空闲等待的时间段需要用好的调度策略去填充。混合并行就是同时使用以上多种策略。对于千亿参数级别的模型通常会结合数据并行、张量并行、流水线并行再加上专家并行之类的更细粒度策略。实操中的建议是先跑通数据并行再逐步加入其他并行策略每一步都做性能基准测试别一上来就上最复杂的配置。我之前在一个模拟项目里调分布式训练刚开始用数据并行收敛速度总是上不来后来用 Profiler 工具一测发现通信占比超过 60%也就是说大部分时间卡都在等同步。后来把 AllReduce 改成梯度压缩加延迟同步通信开销降了一大截训练吞吐直接翻倍。这个优化思路对很多大规模训练场景都有效。4.2 推理优化延迟、吞吐、成本的三角博弈训练完成后模型要上线对外服务这就进入推理优化和服务化阶段。推理和训练的需求是两回事训练看重吞吐量推理看重延迟和稳定性。线上推理的优化手段我整理了从模型侧到系统侧的几条线模型侧最常用的是量化。把 FP32 的权重压缩成 FP16、INT8甚至更低精度。量化能带来显存减半、推理加速近一倍的效果但要注意精度损失。可以先做 PTQ训练后量化效果不够再用 QAT量化感知训练。系统侧推理引擎优化很关键。主流的推理加速引擎会做算子融合把多个算子合并成一个内核、内存复用和计算图优化减少 GPU 的空闲等待时间。启用这类引擎后同一模型在延迟上经常能提升一个数量级。服务化侧动态批处理和缓存是提升吞吐的秘密武器。在线推理请求是稀疏到达的如果每个请求来了就立刻算GPU 占用率很低。把短时间窗口内的多个请求聚合成一个批次一起推理单位时间处理的请求数能大幅提升。再加上结果缓存重复的请求直接走缓存不用真正计算。这里有个平衡要把握动态批处理不是越大越好要设置最大延迟预算否则请求等待时间会超标。线上服务的 SLOService Level Objective服务水平目标通常会给一个延迟上限如 P99 200ms你要在这个约束下去调自己想要的批次大小。成本和体验永远是一对需要调和的需求。5. 数据管道与 MLOps让模型持续可迭代5.1 数据管道特征一致性是一个大坑很多人跟模型打交道时会忽略一个环节——数据管道。但根据我的经验线上模型效果崩掉十有八九不是模型代码的问题而是训练数据和线上数据对不上了。这句话怎么理解训练时你从离线数仓里取数据做特征工程然后喂给模型。上线后线上推理服务也是实时算特征喂给同一套模型。如果离线特征的计算逻辑和线上特征的计算逻辑不完全一致——比如排序方式不同、某个字段的空值处理逻辑不同、特征归一化参数不同——就会导致训练和推理的特征分布发生偏移这在行业里叫 train/serve skew。解决方案是建立一套特征平台统一特征计算逻辑。离线训练和在线推理共用同一套特征定义或者至少保证特征逻辑的单一来源。更严格的做法是线上推理时会记录特征快照定期用线上特征回放离线训练流程对比两者效果。很多团队在这上面栽过跟头某团队曾经发布了一版新模型A/B 测试效果一直异常最后排查发现是线上特征平台某字段的取值变了而离线训练用的还是旧逻辑。这种问题隐蔽性极高。数据版本化也很重要。训练数据不是一成不变的今天一批数据下周又追加一批。如果没有版本管理你根本无法复现上周那个模型为什么效果不错。数据版本管理要记录数据的来源、生成时间、处理逻辑、样本分布统计这样每次实验都有据可查。5.2 MLOps模型上线只是开始不是结束模型上线之后工作才完成一半。没有可靠的 MLOps 体系模型线上运行期就是裸奔。MLOps 的核心内容包括实验追踪、模型仓库、发布策略、线上监控四个环节。实验追踪解决的是这次实验用了什么配置、什么数据、什么代码的问题。所有训练的日志、指标、超参数、模型权重都记录在一个实验追踪系统里很多团队会自研这样后续要做模型对比、问题回溯都有依据。很多团队一开始不重视等到模型迭代了几十版之后想找一个之前效果最好的模型发现完全找不到了只能重跑。浪费时间也磨人心态。模型仓库把训练好的模型统一管理起来可以做版本登记、审批、上线前评估。一个模型从训练到上线至少要经过离线评测、影子测试shadow mode、金丝雀发布canary、全量发布这几个阶段。影子测试是把新模型和线上老模型同时跑只记录输出不改变真实决策用来观察差异。金丝雀发布则是只让一小部分流量走新模型观察指标没问题后再逐步放量。线上监控是整个 MLOps 里最容易被偷懒的部分。除了常规的 CPU、内存、延迟、错误率监控外模型特有的监控还包括输入特征分布漂移检测模型看到的输入是不是和训练时一致、输出分布漂移检测、以及业务指标监控。一旦发现指标异常要有自动回滚机制。我见过一个线上事故因为数据处理逻辑变更导致模型预测分布整体偏移监控系统一直没有告警等到业务方反馈时已经影响了几小时流量。如果当时有特征分布漂移检测这种事故完全可以提前拦截。6. 学习路径与避坑实录6.1 给入门者的学习顺序建议AI Infra 涉及的知识面非常广很多人一上来就蒙了不知道从哪里开始。我推荐的学习顺序不是从头读理论而是倒着学。第一步先亲手跑一次完整的模型训练和推理。用最简单的方式在一台机器上跑通一个图像分类或文本生成任务了解模型从训练到保存、再到加载推理的完整流程。这一步的目的是建立整体的肌肉记忆知道每个环节在做什么。第二步拆掉单机环境改成单机多卡训练。体验数据并行看看加了后性能提升了多少学会观察 GPU 利用率、训练吞吐这些指标。这一步会让你第一次意识到通信、数据加载这些非模型因素有多重要。第三步把训练任务放到容器里再上集群调度。学习容器编排系统的基本操作提交一个训练任务、查看日志、扩容缩容、设置资源限制。这个阶段可以把任务跑到多个节点上体会分布式训练的通信开销。第四步开始研究模型的推理优化。把训练好的模型做量化、加速引擎优化部署成在线服务压测一下延迟和吞吐。这一步能让你理解性能工程的价值。第五步再回头补理论。这个时候你对分布式并行、调度策略、存储这些概念已经有了具体感知再看论文、源码、架构文档都不再是空中楼阁。我特别推荐去读一些大厂公开的架构设计文档看他们是怎么在真实场景中取舍的。这个路径的核心逻辑是先建立体感再补理论。如果倒过来先啃理论很容易学了一个月还在概念的沼泽里爬不出来。6.2 我踩过的那些坑这几年实际操作下来我踩过不少坑挑几个典型的记录下来希望你别再踩常见问题现象排查思路与解决建议GPU 显存 OOM模型跑到一半任务崩溃检查 batch size 和模型参数量 是否匹配用显存分析工具看峰值显存消耗考虑梯度累积或混合精度训练训练吞吐上不去GPU 利用率很低但没人知道为什么用 Profiler 工具分析 数据加载、计算、通信三个阶段的时间占比定位瓶颈后针对性优化环境依赖不一致A 同学能跑、B 同学跑不了尽早全面容器化代码、依赖、系统版本都固化为镜像镜像要打版本标签集群出现性能神秘波动同一任务有时快有时慢检查网络拓扑、存储并发、其他任务干扰搭好监控大盘用数据复盘不要凭感觉排查模型上线后效果不如预期离线评测很好线上指标崩了检查训练与推理的特征一致性做影子测试对比新旧模型看特征漂移监控最想强调的一个教训是AI Infra 的排查永远要优先看数据而不是凭直觉。很多问题表面上是模型问题、代码问题实际往下一查是存储并发过高、网络路由异常、或者调度器配置不合理。没有一整套监控和日志体系排查这些问题就像在黑屋子里找一只黑猫。我第一次做大集群调优的时候调一个性能问题调了整整两天各种怀疑分布式框架的毛病最后发现只是某个节点的驱动版本和集群其他节点不一致导致通信超时频繁重试。从那以后我学乖了在任何深入排查之前先把环境一致性检查一遍再上监控大盘看指标这至少能筛掉一半的幽灵问题。另外想提一句心态上的经验AI Infra 是一个非常慢的方向不像算法领域几行代码就能看到一个提升效果。它需要你耐得住性子在日志、指标、配置这些琐碎细节里反复琢磨。但恰恰是这些琐碎细节构成了 AI 系统稳定运行的底盘。最后分享一个小技巧学习 AI Infra 阶段一定要多做对比实验。比如同一个训练任务分别用裸机、容器、共享 GPU 三种方式跑记录下延迟和吞吐你会发现自己的理解会从概念层面落到数值层面很多东西一下子就通了。这个习惯我一直保持到现在也是我学习速度比较快的原因。