AI Infra全景学习笔记：从GPU集群到MLOps的六层架构与实战路径

说点实话，这两年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拆成六个层次，这个分层不一定权威，但足够在脑子里建立坐标系：

各层之间有依赖关系：算力层是最底层的底座；调度层决定算力怎么分配；数据层决定算力有没有东西可算；训练工程层让大规模训练能落地；推理服务层让模型能上线；MLOps层把整个过程管起来并形成闭环。六个层都摸过一遍，才算对AI Infra有全景认知。

学习路径上，我自己是自底向上，先折腾GPU机器，再碰调度和训练，最后才补MLOps。原因很简单：不懂底层驱动和硬件报错，上层调度的一句告警你可能都看不懂。但如果时间紧、目标是把服务先跑起来，从推理服务层切入也行，跑通之后，自然会知道该往哪个底层补课。

2. 算力层实践：GPU集群是地基中的地基

2.1 选卡和容量估算的粗算法

AI Infra的一切都从算力开始，但选卡这件事很多人一开始就想错了。训练场景和推理场景对卡的需求并不一样：训练更看显存容量和卡间通信带宽，推理更看单卡吞吐和时延。显存不够，参数放不下，再快的算力都用不上；网络带宽不够，多卡通信会直接把训练拖成龟速。

做容量估算时我习惯先粗算显存。以7B参数模型全参数训练为例，混合精度下，参数按BF16大约占14GB，梯度再占14GB，AdamW的动量状态一般按FP32算要28GB，这三项加起来就56GB了。还没算激活值、中间变量和通信缓冲区，通常再乘1.5到2。所以全参数训练至少按120GB显存去规划，如果你手里只有80GB显存的卡，硬塞就是挤牙膏，要么上模型并行，要么改用LoRA这类参数高效微调。

推理侧的估算简单一些：7B模型BF16权重约14GB，加上KV Cache和预留buffer，80GB单卡基本能塞下。真正要算的是吞吐：目标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的笔记越写越厚，但核心永远没变——把最好的算力利用率、最短的故障恢复时间、最顺滑的研发体验，交给那些真正创造模型价值的人。入门时别追求大而全，先在自己手头的小集群上把数据管线、一次中小规模分布式训练、一个推理服务的完整链路跑通，哪怕全套只有两台机器，也比刷十篇架构文章有用。这套经验一旦有了，往上扩展只是时间和踩坑的累积。下一篇等我再被某个存储或网络专题折磨过之后，再和大家细聊某个深水区。