做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全景图"重新画一遍，每画一次都会发现原来有些模糊的位置现在清晰了很多。你不需要一下子掌握所有细节，先把地图铺开，剩下的交给时间和具体问题就好。
做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全景图"重新画一遍，每画一次都会发现原来有些模糊的位置现在清晰了很多。你不需要一下子掌握所有细节，先把地图铺开，剩下的交给时间和具体问题就好。