说点实话这两年AI圈最热闹的永远是模型层——今天这个开源、明天那个刷榜。但我自己从后端基础平台转向AI Infra这一年多最大的感受是真正决定一个团队能不能把模型跑起来的往往是那些没人愿意聊的底层脏活。集群调度、数据流水线、断点续训、GPU利用率这些词听起来不性感但每一样都能让一个几十人的算法团队卡在原地。这篇AI Infra知识全景学习笔记是我从GPU集群搭建、分布式训练、推理服务到MLOps的完整梳理。它不是一个框架的手册而是一张地图告诉你基础设施有哪些层、每层在解决什么问题、哪些坑在等你。适合正在做后端、运维、平台研发想往AI工程方向转的读者也适合算法同学补一点工程侧的常识。1. AI Infra全景地图先看清棋盘再落子1.1 为什么有了框架还不够很多人觉得有了主流深度学习框架AI工程就没什么可做的了。这是一个很大的误解。训练框架只是把模型定义和反向传播抽象好了但分布式通信、数据加载、故障恢复、资源调度这些真正决定系统好不好的东西它一概不管。打个比方训练框架是菜谱AI Infra是厨房本身。菜谱写得再好燃气不通、食材没到、洗碗机坏了菜还是出不来。AI Infra就是要让燃气、水管、食材供应链、洗碗工一起顺畅运转还得稳定出菜。一件事足以看出Infra的重要性数据加载没做流水线GPU利用率可能从90%掉到30%一次训练中断没有断点续训可能白白烧掉几百卡时。这些都不是模型结构决定的是Infra决定的。所以做AI Infra的人工作的本质是把训练和推理这件事的稳定性、效率、成本同时管起来。1.2 六层结构一张表看清我把AI Infra拆成六个层次这个分层不一定权威但足够在脑子里建立坐标系层次解决什么问题核心组件与技术常见开源方案算力层提供算力、管理硬件故障GPU/NPU、高速网络、驱动与CUDA、健康检查厂商驱动工具、容器资源监控组件调度层分配GPU资源、编排训练任务Kubernetes、GPU虚拟化、队列与抢占K8s、Volcano数据层存储、加载、版本管理训练数据对象存储、并行文件系统、缓存、数据管线MinIO、JuiceFS、WebDataset训练工程层大规模分布式训练、checkpoint、容错数据并行/张量并行/流水线并行、显存优化DeepSpeed、Megatron推理服务层模型部署、低延迟高吞吐推理量化、KV Cache、动态批处理、推理引擎vLLM、Triton、TGIMLOps层实验追踪、模型版本、监控告警、CI/CD实验管理、模型注册、可观测性MLflow、Prometheus、Grafana各层之间有依赖关系算力层是最底层的底座调度层决定算力怎么分配数据层决定算力有没有东西可算训练工程层让大规模训练能落地推理服务层让模型能上线MLOps层把整个过程管起来并形成闭环。六个层都摸过一遍才算对AI Infra有全景认知。学习路径上我自己是自底向上先折腾GPU机器再碰调度和训练最后才补MLOps。原因很简单不懂底层驱动和硬件报错上层调度的一句告警你可能都看不懂。但如果时间紧、目标是把服务先跑起来从推理服务层切入也行跑通之后自然会知道该往哪个底层补课。2. 算力层实践GPU集群是地基中的地基2.1 选卡和容量估算的粗算法AI Infra的一切都从算力开始但选卡这件事很多人一开始就想错了。训练场景和推理场景对卡的需求并不一样训练更看显存容量和卡间通信带宽推理更看单卡吞吐和时延。显存不够参数放不下再快的算力都用不上网络带宽不够多卡通信会直接把训练拖成龟速。做容量估算时我习惯先粗算显存。以7B参数模型全参数训练为例混合精度下参数按BF16大约占14GB梯度再占14GBAdamW的动量状态一般按FP32算要28GB这三项加起来就56GB了。还没算激活值、中间变量和通信缓冲区通常再乘1.5到2。所以全参数训练至少按120GB显存去规划如果你手里只有80GB显存的卡硬塞就是挤牙膏要么上模型并行要么改用LoRA这类参数高效微调。推理侧的估算简单一些7B模型BF16权重约14GB加上KV Cache和预留buffer80GB单卡基本能塞下。真正要算的是吞吐目标QPS乘以每条请求的平均生成token数得到每秒需要的总token数再和单卡实测吞吐一除就知道需要几张卡。记住一个原则先粗算再用真实压测校准永远不要拿纸面数字直接下单买卡。2.2 集群部署最容易翻车的三个地方GPU集群最磨人的不是模型代码是底层环境。我踩过的、也看别人踩过最多的坑有三个。第一个是驱动和CUDA版本不匹配。报错千奇百怪有的程序直接崩有的慢到你怀疑人生。别浪费时间猜按这套顺序查先看驱动状态再用nvidia-smi确认驱动版本然后确认容器镜像里的CUDA版本最后看框架要求的最低版本四者对齐。补一句我的习惯是把CUDA和驱动固化进镜像环境漂移问题会少很多。第二个是卡间拓扑和网络。多卡训练对卡间通信极其敏感如果卡互联走的是PCIe而不是内部高速互联数据并行训练慢几个量级很正常。上机第一件事就用拓扑检查命令看一眼卡间互联拓扑。遇到跨机训练高速网络交换机也逃不掉时延和带宽不达标分布式训练照样起不来。第三个是静默错误。某些故障卡不会报错但会产生错误计算结果表现是训练到一半loss突然掉点或出现NaN排查很久都找不到模型层面原因。所以新集群投用前我强烈建议做一遍全卡通信压测和稳定性测试让集群至少稳定跑24小时再正式跑任务。这24小时不亏它能帮你过滤掉绝大多数硬件暗病。2.3 成本思维GPU是资产不是电脑很多团队用GPU还停留在“这是个电脑”的思维这是比较大的误区。GPU是资产而且是整个AI成本里最贵的一项一定要算利用率、算账。我见过一个典型的场景某公司买了一堆高端卡但训练任务每天只跑几小时剩余时间全空着。与其这样不如把弹性做起来空闲时跑其他任务或者直接租用外部算力。对于训练任务如果断点续训已经做好甚至可以接受被抢占重启因为成本能降一大截。推理服务则恰恰相反在线延迟敏感弹性要保守很多底层资源必须留够冗余。另一个经验是不要盲目堆旗舰卡。很多场景卡在显存而不是算力和带宽。把现有的卡用好把集群调度做公平让GPU利用率稳定在70%以上比无脑加卡更能解决问题。利用率长期低于50%先别买卡先去查数据管线。3. 数据管线与存储喂不饱算力才是最大的浪费3.1 数据管线先于训练存在如果让我在AI Infra里排优先级数据层的优先级其实比分布式训练还高。算力再强数据喂不进去一切都是空转。很多团队训练慢第一嫌疑就是数据管线。数据管线不等于写一个数据集加载器而是一条从数据获取、质检、清洗、去重、切分、打标到最终喂进模型的完整流水线。这里有一个容易被忽略的工程问题数据版本管理。代码有Git管版本数据同样要有。我在实际项目里的做法是用数据内容的哈希值作为版本号训练实验里记录的是数据版本和代码版本这样任何一个结果都能追溯到用了哪一份数据。加载部分也要做流水线设计。CPU负责读盘、解码、增强GPU负责计算两者应该重叠进行而不是等GPU把上一批算完再开始加载下一批。成熟的框架能自动做预取但shuffle的时机、缓存的大小、加载线程数量都要调。观察到GPU利用率高但单步训练时间很长大概率就是加载流水线堵住了。3.2 存储选型的“三明治”结构训练数据的存储很多人直接一股脑丢对象存储然后祈祷一切顺利。对象存储便宜、容量大但它对小文件的随机读并不友好。训练数据恰恰是海量小文件和若干大文件的混合体直接从对象存储读IO会成为新的瓶颈。我推荐的结构是“三明治”冷数据放对象存储容量大成本低温数据放分布式缓存命中率高、访问快热数据尽量放到计算节点的本地NVMe SSD上。训练时先把数据集打包成tar或WebDataset这类顺序读取格式再缓存到本地这样大部分读盘都是顺序IO吞吐能提升好几倍。判断数据加载是否拖后腿方法并不复杂训练日志里观察CPU等待时间和数据加载耗时占比然后看IO使用率再看GPU空闲率。如果GPU平均利用率低而IO很忙问题基本就出在存储和管线配置上。先本地缓存再调加载线程数量最后才是换更强的存储设备。3.3 数据质量决定模型上限数据质量这个坑比存储更隐蔽。模型训练界有句话叫垃圾进垃圾出不是开玩笑。网上爬来的数据重复样本、低质量文本、标签噪声全混在里面不处理就训练模型效果必然受到很大影响。我亲历过的一次事故模型过拟合极其严重验证集指标一直上不去团队里算法同学从模型结构找到优化器折腾了快一周。最后发现是数据管线在某个环节重复抽取样本一份数据被喂了多次。训练侧查模型策略是对的但那段时间全浪费了。现在我的习惯是在做任何模型分析之前先把数据分布和样本检查过一遍确保数据本身没有问题。数据工程还有很多细活儿去重不能用太简单的方法语义相似样本也要考虑类别不均衡直接影响训练结果清洗规则要写成可审计的代码而不是一次性脚本。这些都是数据层工程师的日常但很多人把它当成边缘工作恰恰是这里决定了模型训练上限的一半。4. 分布式训练设计与框架选型4.1 三种并行模式先画图理解分布式训练绕不开三种并行方式数据并行、张量并行、流水线并行。很多新手上手就套DeepSpeed遇到问题一脸懵根本原因是对这三种模式没有直观理解。数据并行最直观每张卡都放一份完整的模型喂不同的数据梯度做全局聚合更新。它适合模型能塞进单卡的情况通信量是梯度大小通常还能接受。张量并行则是把一层网络的参数拆到多张卡上每张卡只算一部分通信量很大所以更适合在单机内配合高速互联使用跨机使用要谨慎。流水线并行按层切分不同卡负责不同层通信量适中但会出现流水线气泡利用率不一定高。实际的大规模训练几乎都是混合并行先看模型能不能塞进单卡要塞不下就设备并行再挂上数据并行。以几十B参数模型常见配置为例可能是张量并行等于2或4、流水线并行等于4或8数据并行再乘一个大数。DeepSpeed等框架把这些并行策略封装得很好但你还是要知道自己在用哪一种否则出了问题根本无从下手。4.2 断点续训、慢节点与卡死排查分布式训练跑起来之后真正考验工程能力的时刻来了某张卡挂了任务要不要从头跑答案是不要前提是checkpoint设计到位。保存checkpoint时不仅要存模型权重还要存优化器状态、随机数状态、数据加载进度。这样恢复任务才能回到之前的训练状态而不是从零开始。慢节点是分布式训练另一个鬼见愁。如果集群里有一张卡因为散热、故障或者其他任务干扰变慢整个训练都会被它拖住。排查思路是先做一次全集群通信压测找出明显变慢的卡再看温度是否过高导致降频最后确认该卡上有没有其他负载抢资源。慢节点在训练里的影响就是木桶效应一张卡掉速全局跟着遭殃。训练卡死hang住是最让人头疼的。排查时我建议先看日志最后几十行定位是哪个rank先卡住然后打开NCCL调试模式把通信日志打出来再看是不是有某个进程OOM导致其他rank在通信上无限等待。解决卡死问题没有银弹但养成记录每次故障日志的习惯会让下一次排查快得多。5. 推理服务化把模型变成可用接口5.1 推理优化三板斧模型训练完之后还需要跨过推理服务这道坎才能真正用起来。推理优化的核心三板斧是量化、KV Cache和动态批处理。量化讲的是用更低精度的数值保存和计算模型权重BF16/INT8/INT4依次压缩体积、提升速度代价是精度损失。具体用哪种要看任务对精度的敏感程度我的习惯是先跑离线评测量化后的效果损失在可接受范围内再上线。KV Cache是生成类模型推理的关键优化。每次生成新token要依赖前面所有token的上下文把这部分缓存下来就不用一遍遍重新计算。显存里缓存越大能支持的上下文越长但缓存也是显存开销需要和模型权重一起规划。动态批处理更直接多个请求在GPU上同时算一次算一批吞吐成倍提升。现代开源推理引擎已经把这套做到很成熟我强烈建议直接用成熟方案而不是自己写推理引擎。自己写一版demo容易但要做到生产级稳定、支持各种模型结构周期太长性价比太低。5.2 容量规划实测值比纸面值更靠谱推理服务的容量规划网上有各种公式但我的经验是公式只能给出初始值最终一定要压测校准。举个简化例子。假设目标QPS是100每条请求平均生成200个token那每秒需要生成的总token数就是2万。如果单卡实测吞吐是5000 tokens每秒理论上需要4张卡。但实际还有请求到达的波动、长尾延迟、模型输入的差异我一般再乘1.5到2倍的buffer所以可能是8张卡。这里的关键词是“实测”。不同模型、不同输入长度分布、不同量化级别单卡吞吐差别很大。开一台卡跑真实的请求负载测出几个关键指标首token延迟、生成速度、并发上限。用这套数据去做容量规划比任何理论公式都靠谱。6. MLOps贯穿全生命周期的秩序6.1 实验管理与模型版本化AI项目规模一大没有有序的实验管理就像没有目录的图书馆想找什么全靠记忆。某个实验用了哪份数据、哪个代码版本、什么超参数随随便便就丢失或记错。我的原则是把代码版本、数据版本、超参数、随机种子、环境镜像全部作为实验元数据记录一个实验对应一条记录。实验追踪工具或平台能自动采集这些信息哪怕只是一个小团队也建议从一开始就用起来。人工在表格里记也可以规模大了必然出错。模型版本化同样重要。训练产物不只是权重文件还包括tokenizer配置、预处理逻辑、评测指标。上线什么版本、回滚到哪个版本都要有据可查。把模型注册这一步做成部署的必经环节后发布和回滚都变得可控而不是靠人肉记忆。6.2 可观测性什么该盯什么不用盯Infra运维的基本原则是可观测性但AI领域的指标和传统后端有些不同。传统后端盯的是QPS、错误率、延迟AI训练侧还要盯GPU利用率、显存、温度、功耗、网络收发、单步训练时间、loss和梯度范数。不要试图监控所有指标那样只会让告警变得毫无区分度。训练侧真正值得重点盯的是GPU利用率骤降大概率数据或通信出问题、loss发散可能数据或者学习率异常、训练中断可能硬件或网络问题。推理侧则盯首token延迟、生成吞吐、错误率和排队长度。告警策略也要做减法宁可少告警不要狼来了。我在团队里有个习惯每次故障处理完都写一份复盘把排查链路沉淀成值守手册。下一次同类问题出现直接照着手册走能省一半时间。6.3 从训练到上线的全链路把这套流程串起来就是一个完整交付链路实验训练阶段记录元数据评测通过后把模型注册为指定版本构建推理镜像部署到K8s集群接入监控和告警保留版本回滚能力。这条链路里每个环节都可能出问题但正是MLOps让这些问题可追溯、可恢复。团队大了之后这套流程不是效率负担而是协作基础。它保证任何一个新成员都能看懂一个模型是怎么从实验走到上线的。7. 从传统运维到AI Infra工程师技能栈与思维转变7.1 硬技能清单想转AI Infra不用一上来就啃机器学习数学。我列一份实用性优先的技能清单Linux、操作系统、TCP/IP网络和RDMA概念容器和K8s调度shell和Python脚本分布式系统常识故障恢复、一致性、消息队列以及机器学习基础过一遍训练流程、优化器、loss怎么理解。这些技能的重要性排序是Linux和shell是敲门砖K8s是日常工作的中心分布式系统常识决定你能不能在故障时快速定位机器学习基础决定你能不能和算法同学有效沟通。缺了最后一项你会连他们说的“loss炸了”到底是好事还是坏事都分不清。7.2 三种思维转变从传统运维到AI Infra思维上也要转过弯来。第一是从“保证在线率”到“保证训练连续性和利用率”。训练任务不是常驻服务它是一次性的大规模计算恢复能力和检查点设计比在线率更重要。第二是成本思维GPU是最大的成本项每一项容量决策都要有量化依据。第三是面向故障设计训练的断点续训、推理的优雅降级都要提前设计好不要等故障发生了再救火。在协作沟通过程中还有一点容易被忽略算法同学和平台同学对资源的认知经常不在一个频道。你看到的是GPU空闲他看到的是实验排队你算的是成本他算的是效果。好的AI Infra工程师很大程度上是翻译官和文化桥梁能把两边的诉求对齐成一条可执行的路径。最后说一句掏心窝的话AI Infra的笔记越写越厚但核心永远没变——把最好的算力利用率、最短的故障恢复时间、最顺滑的研发体验交给那些真正创造模型价值的人。入门时别追求大而全先在自己手头的小集群上把数据管线、一次中小规模分布式训练、一个推理服务的完整链路跑通哪怕全套只有两台机器也比刷十篇架构文章有用。这套经验一旦有了往上扩展只是时间和踩坑的累积。下一篇等我再被某个存储或网络专题折磨过之后再和大家细聊某个深水区。