做AI项目做了几年我一直有个很尴尬的处境模型结构、损失函数、调参技巧这些聊起来头头是道可一旦扯到GPU集群怎么规划、数据管线为什么卡住、推理服务为什么线上长尾延迟爆炸就有点心虚。直到有一次亲手把一个训练任务搞挂折腾两天才发现问题是存储带宽和网络拓扑——那一刻我才意识到AI Infra 不是运维该管的事而是每个做AI的人迟早要补上的必修课。这篇笔记是我自己系统梳理 AI Infra 知识全景的总结从最底层的算力、网络到数据管线、训练工程、推理服务再到云原生平台和自动化治理把每一层真正要解决的问题、常用的技术选型思路、以及我踩过的坑和判断逻辑都过了一遍。适合那些模型调得还不错、但对底层基础设施一知半解的算法工程师也适合刚转岗做ML平台、AI平台的后端同学当作一张地图来用——不追求每个分支都深入但起码看到问题的时候知道该往哪一层去查。1. 先拆一张全景图AI Infra 的边界到底划在哪1.1 一次训练事故让我重新理解基础设施事情其实很简单某个模拟项目X的数据集比较大训练脚本本机跑没问题一上集群就报错时断时续日志里全是奇怪的超时。我第一反应是代码有问题检查了半天 PyTorch DataLoader 的设置结果该坏的还是坏。后来某位前辈提醒了一句你看看存储节点到计算节点的带宽是不是被打满了。一查果然当时多台机器同时从同一个存储桶读数据这套存储网关根本没做过带宽规划几百兆的吞吐直接成了瓶颈。那一刻我很受触动我一直把注意力放在模型代码这一层但真正拖垮训练的是底层的存储管线。这其实是一个非常典型的AI Infra问题——它不是某个单一的组件而是从数据到模型中间所有支撑性系统的总和。也是从那次之后我开始有意识地把基础设施这个词拆开搞清楚它究竟覆盖哪些范围哪些是我需要主动去了解的。1.2 五层视角从硬件到工具的完整链路我建议把AI Infra看成五个层次每个层次解决不同的问题层与层之间有清晰的接口关系层核心问题典型技术对象算力层用谁的算力怎么选怎么调度GPU/TPU、CPU、内存、网络设备存储与数据层数据放哪、怎么高效读写、如何管理版本对象存储、并行文件系统、数据湖训练工程层大模型怎么在分布式环境里跑稳分布式训练框架、断点续训、实验管理推理与服务层模型如何高效响应线上请求推理引擎、服务化框架、弹性扩缩容平台与自动化层以上所有层怎么统一编排和运维Kubernetes、MLOps平台、可观测性这五层并不是严格独立的。存储层和数据层实际经常被合并算力层和训练层也界限模糊但作为学习地图五层分开看更容易定位问题。每次遇到一个奇怪的现象我会先问自己这个问题发生在哪一层是算力不够还是安排不合理是存储带宽瓶颈还是网络拓扑问题是框架本身的坑还是我代码用得不对不要小看这个分层提问的过程。很多AI项目推进不下去不是模型效果不行而是你根本不知道该去哪里找原因——我见过太多人拿着模型代码层面的问题去排查底层网络或者拿着网络问题去魔改模型方向完全反了。2. 算力层买的、租的、省下来的2.1 GPU 选型别只看算力要看组合拳很多人一聊GPU就只盯着FLOPS这是最容易犯的错误。实际上对绝大多数训练任务决定你任务快慢的往往是另外两个指标显存容量和卡间互联带宽。显存决定你单卡能塞多大模型、多大的batch size。模型参数超过显存要么模型并行要么梯度累积都是额外工程成本。互联带宽则决定了多卡协同的效率——两张卡之间通信慢分布式训练的性能会直线下降。我的经验是先做一轮简单的需求拆解而不是一上来就比参数表你要跑的模型有多大按参数和激活值估算显存需求训练数据规模多大数据加载是否会成为瓶颈单卡能忍还是必须多卡多卡通信会成为瓶颈吗这些问题的答案往往比一张理论算力表更接近真实需求。关于显存估算有个粗略公式训练时的显存占用通常是模型参数的内存占用的6到12倍因为除了参数本身还有梯度、优化器状态、激活值等。例如一个100亿参数的模型如果按FP16加载参数内存约20GB加上梯度和优化器状态单卡至少需要150GB以上这样算下来基本就不是一张卡能搞定的事。2.2 集群网络的拥塞不亲眼见到很难相信另一个很容易被低估的是网络。多机训练时数据要在不同节点之间传来传去网络带宽和拓扑设计直接影响整体训练效率。我在某个跨平台系统项目里见过一次典型事故运维觉得网卡和交换机是够用的结果大模型训练一跑起来数据并行产生的通信量远超预算多个训练任务共享同一段网络直接拥塞。训练速度肉眼可见地掉谁的任务都跑不快。后来把训练流量和常规业务流量做了网络隔离问题才缓解。网络这块我建议至少搞懂几个概念数据并行下梯度聚合是周期性的大流量突发参数服务器架构和全规约架构的通信模式差异叶脊网络拓扑下跨交换机通信会走更远路径延迟更高不需要成为网络专家但要对通信瓶颈可能出现在哪有数。2.3 资源调度GPU 排队背后其实在权衡算力层的最后一个问题是调度。算力资源总是有限的谁来用、用多少、用多久需要一套机制来管理。业界常见的做法是引入资源排队系统训练任务提交后进入队列调度器根据优先级、资源需求量、当前空闲节点情况来分配。不要觉得自己只是排队等卡调度策略背后有很多权衡比如优先保障在线推理服务的稳定性还是优先保证训练任务吞吐多个小任务填满碎片资源还是让一个大任务独占一批节点用户提交的任务挂了一小时还没开始是扩容还是排队策略该调我个人的建议是调度策略不要做得太复杂先把优先级和配额这两件事抓好再考虑Fairness、抢占等高级特性。排队的本质是资源共享而资源治理的第一步是搞清楚谁能用、能用多少、用完了怎么回收。3. 数据侧AI 项目里最容易被低估的隐性工程3.1 存储不是硬盘而是从数据到 GPU 的整条管道存数据这件事看起来很简单——文件夹里放一堆文件模型训练时按路径读取。但训练数据灌到GPU里中间要经过很多环节存储节点、网络传输、读取进程、数据预处理、缓存、加载器。任何一个环节慢GPU都会饿肚子。我遇到过一个经典问题把数据放在普通网络存储上几千张小图片读取特别慢训练速度怎么调都上不去。后来先在本机加了缓存又换成分布式存储的并行读取接口训练吞吐立刻翻倍。很多时候你以为是显存不够其实只是数据压根送不到GPU里。常规选型逻辑大概是这样小规模实验本地SSD就够了没必要上复杂存储数据量大但访问模式简单对象存储配合数据缓存降低成本需要频繁随机读写、高吞吐高性能并行文件系统更合适数据规模巨大且需要管理数据湖统一存储原始数据和特征数据存储这个环节没有万能的方案不同的数据特性适合不同的存储引擎。3.2 数据集版本你再也不能说我改了点数据算法同学普遍不太在意数据版本管理直到某一天模型指标突然变化你想知道是不是数据变了结果所有人都说不清上次数据是什么时候改的、改了什么。那一刻你会理解代码要版本管理、数据同样要版本管理。数据集不是一个静态文件它是一个会进化的实体。标注改了、采样逻辑换了、某个字段清洗规则变了都会改变数据集的内容。使用不可变的对象存储每次数据变更生成新版本训练任务记录它使用的数据版本这样一个链路上就很容易定位问题。我习惯在数据版本管理上做三件事数据的每一次变更都生成新的版本标识不在原文件上修改训练脚本、实验记录里明确记录数据集版本号关键实验保留数据、代码、配置的快照保证可复现3.3 数据管线的瓶颈排查思路数据管线出问题时现象可能各式各样训练时每个step很慢、CPU使用率居高不下、网络周期性打满。排查思路建议从数据从源端到GPU的路径入手每一步都检查耗时。我在实践中常用这样的排查顺序先看GPU利用率如果非常低说明计算侧在等数据再看CPU进程是满负荷还是空转空转说明数据还没拉到内存然后检查网络吞吐和存储的IO延迟判断是读取慢还是传输慢最后看预处理是否成为瓶颈比如图像解码、数据增强是否拖慢了整个流程每个环节的耗时可以通过简单的打点分析看出来。很多人遇到训练慢第一反应是调模型、调超参数其实数据的输入管线往往才是真正的墙。4. 训练工程从单卡到多卡的认知转折4.1 单卡跑通只是开始分布式训练的核心矛盾模型在单卡上能跑通和能大规模训练之间隔着一个分布式训练的理解鸿沟。我自己最大的转变是从把代码丢到多卡上跑到理解多卡之间怎么协作的转变。分布式训练最核心的矛盾是每个进程算出一部分梯度大家都需要对全部梯度做汇总后才能更新参数。数据并行中这个汇总就是通信量的大头。随着卡数增加通信时间会越来越长可能抵消掉多卡带来的计算加速这也是为什么常见的经验法则是小模型不推荐大规模数据并行通信开销大、收益低。百亿甚至千亿参数规模下单纯的张量并行或者管线并行效率也会降低这时候往往需要组合多种并行策略。不要害怕这几个名词数据并行、张量并行、流水线并行。它们的本质是回答同一个问题大模型塞不下、算太慢怎么把它切开分配到多张卡上4.2 断点续训不是存个checkpoint那么简单我以前天真地以为训练中断后恢复只需要加载模型权重重新跑就行。实际踩过坑才知道分布式训练发生故障恢复不仅要恢复模型参数还要恢复优化器状态、学习率调度器的进度、数据加载器的位置以及随机数生成器的状态。我见过一个很可惜的案例某次大模型训练跑了几天中途节点故障重启后只加载了模型权重优化器状态和调度器进度全丢了学习率重新从初始值开始——结果是后续几天的训练质量明显下降浪费了大量算力。如果当时有完整的训练快照机制就不会有这些损失。所以现在我做断点续训时至少关注这几件事模型权重、优化器状态、学习率、随机数序列是否一起保存RNG状态要不要恢复以及它是否需要和真实故障场景对得上故障检测的粒度是整机重启还是自动拉起新节点这些细节如果没想清楚所谓的断点续训很可能只是假象恢复之后训练行为已经悄悄变了最后还可能归结到模型问题上排查半天才发现是训练环境的问题。4.3 实验管理是我见过最普遍的隐形浪费很多人把实验管理理解为记录一下loss曲线但实际更关键的是把实验的参数、代码版本、数据版本、环境配置都关联起来形成可追溯、可复现的链路。没有这套东西你跑了几十个实验最后根本说不清哪个最好、为什么最好、怎么复现它。我的习惯是每次实验都保存以下信息完整代码快照包括依赖库版本超参数配置和启动命令数据版本标识关键日志和指标曲线这件事的价值在数月后才会体现当你想复用某次实验的配置或者同事问起你这个效果是怎么跑出来的如果每次都记录完整那就是复制粘贴一样的容易否则还需要重新填坑。5. 推理服务模型上线之后故事才刚开始5.1 从训练思维切换到服务思维训练和推理服务的心态完全不同。训练追求的是吞吐和利用率要尽可能把算力跑满推理服务在乎的是延迟和稳定性需要在满足响应时间要求的前提下尽量提高吞吐。做推理服务的第一道坎就是别把训练代码直接拿来起服务。训练框架和推理引擎在显存管理、算子优化、批处理策略上差异很大。单纯把训练好的模型加载到某个Python服务里处理请求显存管理会很粗糙并发上来之后会发生显存碎片化、超时雪崩。实践中通常需要用推理优化引擎做计算图优化、算子融合这些手段训练阶段几乎用不到。5.2 推理优化的三板斧量化、批处理、缓存推理服务的优化手段绕不开这三类降低单请求计算量、提高单位时间吞吐、减少重复计算。量化是把模型的FP16权重压缩成INT8或更低精度换来更小的显存占用和更快的算子执行。批处理是在服务端把多个请求攒起来一起推理摊薄算子调度开销。缓存则是把高频重复的计算结果存下来直接返回而不重新推理。我自己做推理服务的时候有个很深的体会批处理的运维心智远比想象中重要。推理请求天然不均匀高峰期和低谷期差异极大。如果服务端不支持动态批处理突发流量一来排队延迟会迅速拉高配置max batch和max latency要反复试找到那个兼顾吞吐和延迟的平衡点。5.3 容量规划为什么你的 GPU 显存够用还是超时很多人设置最大并发的时候只看显存一张卡能装下4个推理实例那就设个4并发结果线上请求稍多就开始大面积超时。原因在于并发增加之后显存占用的确没超但GPU的计算能力已经被打满请求排队时间剧增。容量规划的正确姿势是同时看几个指标单请求的延迟、单卡并发数和端到端延迟之间的关系。我建议做压测在逐步增加并发的同时记录延迟曲线找到延迟分位数开始跳变的临界点然后把服务上限设置在临界点以下留一些缓冲。另外一个很容易被忽略的点是显存分配是动态的预留空间太小服务启动后处理几个请求就可能出现OOM。6. 平台化与自动化从脚本到系统最后拼的是运维6.1 容器化和编排一套标准化交付方式当你要在10台机器上跑同样的训练任务或者在集群里部署不同的推理服务脚本一次性执行的模式很快会崩溃。用容器把环境打包配合编排系统做调度、扩缩容和服务发现是目前最主流的做法。我对容器化的理解一直有一个很朴素的比喻它把AI项目里最麻烦的环境一致性问题解决了。以前是在我电脑上能跑呀现在大家都跑在同一个镜像里跑不跑得通是确定性的。镜像里面锁好CUDA版本、Python依赖、系统库一旦确认可以运行就不需要重复排查环境问题。编排系统的功能远不止容器调度。服务的滚动升级、故障自动重启、节点资源管理都可以通过声明式配置实现。但我不建议一上来就搞一大套平台系统。从简单的容器化部署开始先把服务标准化这件事做好再考虑要不要引入更多编排能力。6.2 可观测性没有数据一切优化都是盲人摸象做过线上服务的人都有这种体验用户在群里反馈服务变慢了你打开后台看到的是一堆没有关联的日志、指标和追踪完全不知道从哪查起。可观测性差的系统排查问题基本靠猜。我自己实践下来至少需要这几类数据每个训练任务和推理服务的资源使用率曲线请求延迟的分位数统计看长尾而不是只看平均层与层之间的链路追踪请求从网关到推理服务的每一跳耗时训练任务的关键指标吞吐、通信时间占比、GPU利用率有了这些数据你才能回答那些最难的问题为什么延迟变高了是网络、存储、模型还是并发的问题没有任何监控数据的时候讨论这些都只是猜测。6.3 成本治理算力账单的隐形黑洞使用云资源的话AI项目的成本大头通常是算力。但成本浪费很少发生在单价贵上更多的是资源开得太多却闲置、任务挂了机器没回收、存储数据只增不删。某次排查一个项目发现季度成本里超过三成是没有被任何任务使用的闲置节点。成本治理的思路也很朴素所有机器都要绑定用途和归属没有人认领的资源一律释放训练任务结束自动回收节点不依赖人工手动清理定期盘点存储成本数据和镜像都有生命周期不要以为成本治理是财务的事。基础设施的浪费往往是工程设计问题可以通过自动化流程收敛。7. 全自学有一点意见从问题出发不要从名词出发7.1 学习顺序先广后深以主线带动分支AI Infra涉及的内容确实很多如果想着先从操作系统、计算机网络、存储原理、分布式系统都学一遍再开始大概率没学完就放弃了。我的建议是先搭主干再填细节。主线就是一条一个真实的AI任务从数据到模型从训练到推理完整跑通一遍。过程中一定会遇到存储、网络、GPU、调度、服务化的问题每一个问题都是一个学习入口顺着问题往下挖往往比顺教材往下读要深刻得多。我第一次接触Kubernetes的时候不是被容器编排这个概念吸引而是因为不想再用脚本去管理一堆机器的部署了。带着解决实际问题的目的去学很快就有了框架。7.2 动手练什么才能最有效纸上谈兵在基础设施领域尤其致命。我建议找几个能快速搭建的小项目练手例如用几台机器搭一个简单的分布式训练环境观察不同并行策略的吞吐变化把一份公开数据集放到对象存储里对比不同读数据方式对训练速度的影响把一个公开模型封装成推理服务压测并发找到延迟拐点这些练习规模不大但每个都能让你亲手碰到真实瓶颈。同样的故障在文档里只是文字实操撞上一次印象会深很多。说一点更实际的体会AI Infra这条线很少有人系统教你大家都是在事故中成长的。但正因如此谁先建立起完整的地图谁就能在问题发生时更从容。我自己的习惯是每隔一段时间把AI Infra全景图重新画一遍每画一次都会发现原来有些模糊的位置现在清晰了很多。你不需要一下子掌握所有细节先把地图铺开剩下的交给时间和具体问题就好。 
长河君 · 2026/10/20 20:10:33 · 阅读 1.2k 一文梳理AI Infra知识全景：算力、存储、训练、推理与平台
做AI项目做了几年我一直有个很尴尬的处境模型结构、损失函数、调参技巧这些聊起来头头是道可一旦扯到GPU集群怎么规划、数据管线为什么卡住、推理服务为什么线上长尾延迟爆炸就有点心虚。直到有一次亲手把一个训练任务搞挂折腾两天才发现问题是存储带宽和网络拓扑——那一刻我才意识到AI Infra 不是运维该管的事而是每个做AI的人迟早要补上的必修课。这篇笔记是我自己系统梳理 AI Infra 知识全景的总结从最底层的算力、网络到数据管线、训练工程、推理服务再到云原生平台和自动化治理把每一层真正要解决的问题、常用的技术选型思路、以及我踩过的坑和判断逻辑都过了一遍。适合那些模型调得还不错、但对底层基础设施一知半解的算法工程师也适合刚转岗做ML平台、AI平台的后端同学当作一张地图来用——不追求每个分支都深入但起码看到问题的时候知道该往哪一层去查。1. 先拆一张全景图AI Infra 的边界到底划在哪1.1 一次训练事故让我重新理解基础设施事情其实很简单某个模拟项目X的数据集比较大训练脚本本机跑没问题一上集群就报错时断时续日志里全是奇怪的超时。我第一反应是代码有问题检查了半天 PyTorch DataLoader 的设置结果该坏的还是坏。后来某位前辈提醒了一句你看看存储节点到计算节点的带宽是不是被打满了。一查果然当时多台机器同时从同一个存储桶读数据这套存储网关根本没做过带宽规划几百兆的吞吐直接成了瓶颈。那一刻我很受触动我一直把注意力放在模型代码这一层但真正拖垮训练的是底层的存储管线。这其实是一个非常典型的AI Infra问题——它不是某个单一的组件而是从数据到模型中间所有支撑性系统的总和。也是从那次之后我开始有意识地把基础设施这个词拆开搞清楚它究竟覆盖哪些范围哪些是我需要主动去了解的。1.2 五层视角从硬件到工具的完整链路我建议把AI Infra看成五个层次每个层次解决不同的问题层与层之间有清晰的接口关系层核心问题典型技术对象算力层用谁的算力怎么选怎么调度GPU/TPU、CPU、内存、网络设备存储与数据层数据放哪、怎么高效读写、如何管理版本对象存储、并行文件系统、数据湖训练工程层大模型怎么在分布式环境里跑稳分布式训练框架、断点续训、实验管理推理与服务层模型如何高效响应线上请求推理引擎、服务化框架、弹性扩缩容平台与自动化层以上所有层怎么统一编排和运维Kubernetes、MLOps平台、可观测性这五层并不是严格独立的。存储层和数据层实际经常被合并算力层和训练层也界限模糊但作为学习地图五层分开看更容易定位问题。每次遇到一个奇怪的现象我会先问自己这个问题发生在哪一层是算力不够还是安排不合理是存储带宽瓶颈还是网络拓扑问题是框架本身的坑还是我代码用得不对不要小看这个分层提问的过程。很多AI项目推进不下去不是模型效果不行而是你根本不知道该去哪里找原因——我见过太多人拿着模型代码层面的问题去排查底层网络或者拿着网络问题去魔改模型方向完全反了。2. 算力层买的、租的、省下来的2.1 GPU 选型别只看算力要看组合拳很多人一聊GPU就只盯着FLOPS这是最容易犯的错误。实际上对绝大多数训练任务决定你任务快慢的往往是另外两个指标显存容量和卡间互联带宽。显存决定你单卡能塞多大模型、多大的batch size。模型参数超过显存要么模型并行要么梯度累积都是额外工程成本。互联带宽则决定了多卡协同的效率——两张卡之间通信慢分布式训练的性能会直线下降。我的经验是先做一轮简单的需求拆解而不是一上来就比参数表你要跑的模型有多大按参数和激活值估算显存需求训练数据规模多大数据加载是否会成为瓶颈单卡能忍还是必须多卡多卡通信会成为瓶颈吗这些问题的答案往往比一张理论算力表更接近真实需求。关于显存估算有个粗略公式训练时的显存占用通常是模型参数的内存占用的6到12倍因为除了参数本身还有梯度、优化器状态、激活值等。例如一个100亿参数的模型如果按FP16加载参数内存约20GB加上梯度和优化器状态单卡至少需要150GB以上这样算下来基本就不是一张卡能搞定的事。2.2 集群网络的拥塞不亲眼见到很难相信另一个很容易被低估的是网络。多机训练时数据要在不同节点之间传来传去网络带宽和拓扑设计直接影响整体训练效率。我在某个跨平台系统项目里见过一次典型事故运维觉得网卡和交换机是够用的结果大模型训练一跑起来数据并行产生的通信量远超预算多个训练任务共享同一段网络直接拥塞。训练速度肉眼可见地掉谁的任务都跑不快。后来把训练流量和常规业务流量做了网络隔离问题才缓解。网络这块我建议至少搞懂几个概念数据并行下梯度聚合是周期性的大流量突发参数服务器架构和全规约架构的通信模式差异叶脊网络拓扑下跨交换机通信会走更远路径延迟更高不需要成为网络专家但要对通信瓶颈可能出现在哪有数。2.3 资源调度GPU 排队背后其实在权衡算力层的最后一个问题是调度。算力资源总是有限的谁来用、用多少、用多久需要一套机制来管理。业界常见的做法是引入资源排队系统训练任务提交后进入队列调度器根据优先级、资源需求量、当前空闲节点情况来分配。不要觉得自己只是排队等卡调度策略背后有很多权衡比如优先保障在线推理服务的稳定性还是优先保证训练任务吞吐多个小任务填满碎片资源还是让一个大任务独占一批节点用户提交的任务挂了一小时还没开始是扩容还是排队策略该调我个人的建议是调度策略不要做得太复杂先把优先级和配额这两件事抓好再考虑Fairness、抢占等高级特性。排队的本质是资源共享而资源治理的第一步是搞清楚谁能用、能用多少、用完了怎么回收。3. 数据侧AI 项目里最容易被低估的隐性工程3.1 存储不是硬盘而是从数据到 GPU 的整条管道存数据这件事看起来很简单——文件夹里放一堆文件模型训练时按路径读取。但训练数据灌到GPU里中间要经过很多环节存储节点、网络传输、读取进程、数据预处理、缓存、加载器。任何一个环节慢GPU都会饿肚子。我遇到过一个经典问题把数据放在普通网络存储上几千张小图片读取特别慢训练速度怎么调都上不去。后来先在本机加了缓存又换成分布式存储的并行读取接口训练吞吐立刻翻倍。很多时候你以为是显存不够其实只是数据压根送不到GPU里。常规选型逻辑大概是这样小规模实验本地SSD就够了没必要上复杂存储数据量大但访问模式简单对象存储配合数据缓存降低成本需要频繁随机读写、高吞吐高性能并行文件系统更合适数据规模巨大且需要管理数据湖统一存储原始数据和特征数据存储这个环节没有万能的方案不同的数据特性适合不同的存储引擎。3.2 数据集版本你再也不能说我改了点数据算法同学普遍不太在意数据版本管理直到某一天模型指标突然变化你想知道是不是数据变了结果所有人都说不清上次数据是什么时候改的、改了什么。那一刻你会理解代码要版本管理、数据同样要版本管理。数据集不是一个静态文件它是一个会进化的实体。标注改了、采样逻辑换了、某个字段清洗规则变了都会改变数据集的内容。使用不可变的对象存储每次数据变更生成新版本训练任务记录它使用的数据版本这样一个链路上就很容易定位问题。我习惯在数据版本管理上做三件事数据的每一次变更都生成新的版本标识不在原文件上修改训练脚本、实验记录里明确记录数据集版本号关键实验保留数据、代码、配置的快照保证可复现3.3 数据管线的瓶颈排查思路数据管线出问题时现象可能各式各样训练时每个step很慢、CPU使用率居高不下、网络周期性打满。排查思路建议从数据从源端到GPU的路径入手每一步都检查耗时。我在实践中常用这样的排查顺序先看GPU利用率如果非常低说明计算侧在等数据再看CPU进程是满负荷还是空转空转说明数据还没拉到内存然后检查网络吞吐和存储的IO延迟判断是读取慢还是传输慢最后看预处理是否成为瓶颈比如图像解码、数据增强是否拖慢了整个流程每个环节的耗时可以通过简单的打点分析看出来。很多人遇到训练慢第一反应是调模型、调超参数其实数据的输入管线往往才是真正的墙。4. 训练工程从单卡到多卡的认知转折4.1 单卡跑通只是开始分布式训练的核心矛盾模型在单卡上能跑通和能大规模训练之间隔着一个分布式训练的理解鸿沟。我自己最大的转变是从把代码丢到多卡上跑到理解多卡之间怎么协作的转变。分布式训练最核心的矛盾是每个进程算出一部分梯度大家都需要对全部梯度做汇总后才能更新参数。数据并行中这个汇总就是通信量的大头。随着卡数增加通信时间会越来越长可能抵消掉多卡带来的计算加速这也是为什么常见的经验法则是小模型不推荐大规模数据并行通信开销大、收益低。百亿甚至千亿参数规模下单纯的张量并行或者管线并行效率也会降低这时候往往需要组合多种并行策略。不要害怕这几个名词数据并行、张量并行、流水线并行。它们的本质是回答同一个问题大模型塞不下、算太慢怎么把它切开分配到多张卡上4.2 断点续训不是存个checkpoint那么简单我以前天真地以为训练中断后恢复只需要加载模型权重重新跑就行。实际踩过坑才知道分布式训练发生故障恢复不仅要恢复模型参数还要恢复优化器状态、学习率调度器的进度、数据加载器的位置以及随机数生成器的状态。我见过一个很可惜的案例某次大模型训练跑了几天中途节点故障重启后只加载了模型权重优化器状态和调度器进度全丢了学习率重新从初始值开始——结果是后续几天的训练质量明显下降浪费了大量算力。如果当时有完整的训练快照机制就不会有这些损失。所以现在我做断点续训时至少关注这几件事模型权重、优化器状态、学习率、随机数序列是否一起保存RNG状态要不要恢复以及它是否需要和真实故障场景对得上故障检测的粒度是整机重启还是自动拉起新节点这些细节如果没想清楚所谓的断点续训很可能只是假象恢复之后训练行为已经悄悄变了最后还可能归结到模型问题上排查半天才发现是训练环境的问题。4.3 实验管理是我见过最普遍的隐形浪费很多人把实验管理理解为记录一下loss曲线但实际更关键的是把实验的参数、代码版本、数据版本、环境配置都关联起来形成可追溯、可复现的链路。没有这套东西你跑了几十个实验最后根本说不清哪个最好、为什么最好、怎么复现它。我的习惯是每次实验都保存以下信息完整代码快照包括依赖库版本超参数配置和启动命令数据版本标识关键日志和指标曲线这件事的价值在数月后才会体现当你想复用某次实验的配置或者同事问起你这个效果是怎么跑出来的如果每次都记录完整那就是复制粘贴一样的容易否则还需要重新填坑。5. 推理服务模型上线之后故事才刚开始5.1 从训练思维切换到服务思维训练和推理服务的心态完全不同。训练追求的是吞吐和利用率要尽可能把算力跑满推理服务在乎的是延迟和稳定性需要在满足响应时间要求的前提下尽量提高吞吐。做推理服务的第一道坎就是别把训练代码直接拿来起服务。训练框架和推理引擎在显存管理、算子优化、批处理策略上差异很大。单纯把训练好的模型加载到某个Python服务里处理请求显存管理会很粗糙并发上来之后会发生显存碎片化、超时雪崩。实践中通常需要用推理优化引擎做计算图优化、算子融合这些手段训练阶段几乎用不到。5.2 推理优化的三板斧量化、批处理、缓存推理服务的优化手段绕不开这三类降低单请求计算量、提高单位时间吞吐、减少重复计算。量化是把模型的FP16权重压缩成INT8或更低精度换来更小的显存占用和更快的算子执行。批处理是在服务端把多个请求攒起来一起推理摊薄算子调度开销。缓存则是把高频重复的计算结果存下来直接返回而不重新推理。我自己做推理服务的时候有个很深的体会批处理的运维心智远比想象中重要。推理请求天然不均匀高峰期和低谷期差异极大。如果服务端不支持动态批处理突发流量一来排队延迟会迅速拉高配置max batch和max latency要反复试找到那个兼顾吞吐和延迟的平衡点。5.3 容量规划为什么你的 GPU 显存够用还是超时很多人设置最大并发的时候只看显存一张卡能装下4个推理实例那就设个4并发结果线上请求稍多就开始大面积超时。原因在于并发增加之后显存占用的确没超但GPU的计算能力已经被打满请求排队时间剧增。容量规划的正确姿势是同时看几个指标单请求的延迟、单卡并发数和端到端延迟之间的关系。我建议做压测在逐步增加并发的同时记录延迟曲线找到延迟分位数开始跳变的临界点然后把服务上限设置在临界点以下留一些缓冲。另外一个很容易被忽略的点是显存分配是动态的预留空间太小服务启动后处理几个请求就可能出现OOM。6. 平台化与自动化从脚本到系统最后拼的是运维6.1 容器化和编排一套标准化交付方式当你要在10台机器上跑同样的训练任务或者在集群里部署不同的推理服务脚本一次性执行的模式很快会崩溃。用容器把环境打包配合编排系统做调度、扩缩容和服务发现是目前最主流的做法。我对容器化的理解一直有一个很朴素的比喻它把AI项目里最麻烦的环境一致性问题解决了。以前是在我电脑上能跑呀现在大家都跑在同一个镜像里跑不跑得通是确定性的。镜像里面锁好CUDA版本、Python依赖、系统库一旦确认可以运行就不需要重复排查环境问题。编排系统的功能远不止容器调度。服务的滚动升级、故障自动重启、节点资源管理都可以通过声明式配置实现。但我不建议一上来就搞一大套平台系统。从简单的容器化部署开始先把服务标准化这件事做好再考虑要不要引入更多编排能力。6.2 可观测性没有数据一切优化都是盲人摸象做过线上服务的人都有这种体验用户在群里反馈服务变慢了你打开后台看到的是一堆没有关联的日志、指标和追踪完全不知道从哪查起。可观测性差的系统排查问题基本靠猜。我自己实践下来至少需要这几类数据每个训练任务和推理服务的资源使用率曲线请求延迟的分位数统计看长尾而不是只看平均层与层之间的链路追踪请求从网关到推理服务的每一跳耗时训练任务的关键指标吞吐、通信时间占比、GPU利用率有了这些数据你才能回答那些最难的问题为什么延迟变高了是网络、存储、模型还是并发的问题没有任何监控数据的时候讨论这些都只是猜测。6.3 成本治理算力账单的隐形黑洞使用云资源的话AI项目的成本大头通常是算力。但成本浪费很少发生在单价贵上更多的是资源开得太多却闲置、任务挂了机器没回收、存储数据只增不删。某次排查一个项目发现季度成本里超过三成是没有被任何任务使用的闲置节点。成本治理的思路也很朴素所有机器都要绑定用途和归属没有人认领的资源一律释放训练任务结束自动回收节点不依赖人工手动清理定期盘点存储成本数据和镜像都有生命周期不要以为成本治理是财务的事。基础设施的浪费往往是工程设计问题可以通过自动化流程收敛。7. 全自学有一点意见从问题出发不要从名词出发7.1 学习顺序先广后深以主线带动分支AI Infra涉及的内容确实很多如果想着先从操作系统、计算机网络、存储原理、分布式系统都学一遍再开始大概率没学完就放弃了。我的建议是先搭主干再填细节。主线就是一条一个真实的AI任务从数据到模型从训练到推理完整跑通一遍。过程中一定会遇到存储、网络、GPU、调度、服务化的问题每一个问题都是一个学习入口顺着问题往下挖往往比顺教材往下读要深刻得多。我第一次接触Kubernetes的时候不是被容器编排这个概念吸引而是因为不想再用脚本去管理一堆机器的部署了。带着解决实际问题的目的去学很快就有了框架。7.2 动手练什么才能最有效纸上谈兵在基础设施领域尤其致命。我建议找几个能快速搭建的小项目练手例如用几台机器搭一个简单的分布式训练环境观察不同并行策略的吞吐变化把一份公开数据集放到对象存储里对比不同读数据方式对训练速度的影响把一个公开模型封装成推理服务压测并发找到延迟拐点这些练习规模不大但每个都能让你亲手碰到真实瓶颈。同样的故障在文档里只是文字实操撞上一次印象会深很多。说一点更实际的体会AI Infra这条线很少有人系统教你大家都是在事故中成长的。但正因如此谁先建立起完整的地图谁就能在问题发生时更从容。我自己的习惯是每隔一段时间把AI Infra全景图重新画一遍每画一次都会发现原来有些模糊的位置现在清晰了很多。你不需要一下子掌握所有细节先把地图铺开剩下的交给时间和具体问题就好。