AI基础设施全景图：从模型训练到推理部署的工程实践

做 AI 越久，越觉得算法只是冰山一角。以前我写模型，最关心的是结构设计和指标刷分，后来真正跑训练、做部署，才发现模型代码只是中间很小的一环。数据要喂进来，算力要调度起来，分布式训练要稳定跑几天不崩，推理服务要扛得住请求波动，一整套承载这些能力的基础设施，圈里现在统称 AI Infra。这份学习笔记，不打算堆名词，而是想把我自己从“只会写模型”到“能搭起一套可用的 AI 基础设施”过程中，真正搞懂的那些知识点、踩过的坑、反复确认过的判断依据，重新串一遍。适合刚接触 AI 工程化、准备转做机器学习平台或算法工程的读者，也适合那些已经在搞训练和推理、但一直觉得知识很零散的人。看完之后你至少能画出自己的 AI Infra 全景图，知道每一层在解决什么问题，出了问题该往哪一层去找原因。

1. AI Infra 到底在解决什么问题

1.1 从算法到可用服务之间的“最后一公里”

很多人在学习阶段都跑过模型。笔记本上加载一个小网络，喂一批数据，看着 loss 下降，觉得训练不过如此。等你真的把一个像样规模的模型放进真实环境，问题立刻不一样了：数据放在远端存储里，每次读取都慢得离谱；显卡看着很贵，实际利用率不到三成；训练到一半节点挂了，几天的进度白费；好不容易训完，线上推理请求一上来，延迟直接飙到不可接受。

这些问题的共同点，是它们都不在模型代码本身，而在于模型周围的支撑系统。我用一个厨房的类比来理解这件事：算法是菜谱，写清楚了多少食材、什么步骤、多少火候；AI Infra 则是厨房里的基础设施——水源、电力、锅具、食材供应链、传菜通道。菜谱再高级，厨房跟不上，端出来的菜照样砸招牌。放到实际场景里，AI Infra 解决的就是两个核心问题：一是让训练过程在有限资源下稳定高效地跑完，二是让训练好的模型能以可接受的延迟和成本对外提供服务。前者对应训练基础设施，后者对应推理基础设施，中间还夹着数据、存储、调度和可观测性，哪一环掉链子，整条链路都受影响。

1.2 知识全景图应该怎么画

我自己的学习过程里，画过很多版本的知识地图，后来发现最稳妥的方式是按层次拆：底层是硬件资源，中间是系统软件，上面是平台与工具，再往上是具体的 AI 应用服务。

这个分层并不是严格隔离的。实际排查问题的时候，你会发现性能瓶颈经常跨越多个层次。比如某次训练吞吐上不去，起初怀疑显卡不够，查到最后发现是存储端的元数据读取太慢，数据根本喂不进来。又比如推理接口偶发超时，表象是模型服务不够快，实际是上游排队策略没做好，再加上网络超时设置太短。所以画全景图最大的价值不是背下每个组件名字，而是建立一种“全链路视野”：当某个指标异常时，你能意识到这和数据、计算、通信、存储、调度都可能有关系，而不是一头扎进最直观的那一层。

2. 硬件层：算力、网络、存储的三角关系

2.1 算力单元怎么选，别只看“浮点峰值”一个数

硬件层最容易让人犯的错，是只看加速卡的浮点算力规格。真实场景里，“纸面参数”和“实际跑到多少”往往是两回事。我在学习时给自己列了一个选型检查清单，包含五个关键指标：峰值算力、显存容量、显存带宽、卡间互联能力、软件生态成熟度。

峰值算力要看具体精度。训练大模型时通常关注 BF16/FP16 下的算力，推理场景则经常用 INT8 甚至更低的精度来换吞吐。显存容量决定了一个模型能不能塞进单卡，也决定了 batch size 能开多大；显存不够，很多时候不是换卡能解决的，而是要考虑模型并行或量化。显存带宽容易被新手忽略，通俗讲就是显存和计算单元之间“搬数据”的速度。很多算子看起来计算量不大，但瓶颈就卡在数据搬运上，带宽不足会导致 GPU 空转等数据。卡间互联能力决定了多卡协同的效率，训练类负载尤其敏感，如果卡间带宽低，数据并行做到后期反而会越跑越慢。软件生态则决定了你用起来顺不顺手，框架支持、算子覆盖、调试工具、驱动稳定性都算在里面，调优困难带来的隐性成本比硬件差价贵得多。

训练和推理选型思路还有明显差异。训练追求“把大模型装进显存 + 尽快算完”，所以通常优先考虑大显存和互联带宽；推理追求“稳定的低延迟 + 高吞吐 + 可控成本”，所以往往愿意牺牲一点精度，换取更小的显存占用和更低的单请求成本。我见过不少团队把训练卡直接拿去做推理，结果吞吐提不上去，成本还高得吓人。正确做法是按工作负载分开评估，哪怕初期共用资源，也要在设计阶段就想清楚隔离策略。

2.2 网络：从一台机器到一群机器的分水岭

如果说单卡训练是开一辆车，那分布式训练就是组织一支车队。车队能不能跑起来，看的不是每辆车多快，而是车队之间通信是否顺畅。AI Infra 里的网络，主要管的就是节点和节点、卡和卡之间怎么交换数据。

分布式训练里最常见的通信场景是梯度同步：每个卡算完自己那一批数据后，需要把梯度汇总起来，更新模型参数。想想看，如果模型有 10 亿个参数，每个参数用 2 字节表示，一次梯度同步就有约 2GB 数据在集群里流动。网速不够，训练就变成了“大部分时间在等数据搬完”。这也是为什么现在高性能 AI 集群都很看重 RDMA 这类低延迟网络技术——它绕过了传统协议栈的大量软件开销，让数据可以更快地从一张卡的显存搬到另一张卡的显存。跨机通信还会涉及拓扑结构，比如机架内和跨机架的带宽往往差好几倍，分布式算法的设计如果没考虑拓扑，通信效率就会大打折扣。

我给自己的判断原则很朴素：做单机多卡，可以先不纠结网络；一旦计划上多机分布式，网络方案的预算和精力投入必须跟上，否则买了再贵的卡，集群也跑不出线性扩展的效果。这不是危言耸听，我见过有团队把几十张卡堆在一起，训练吞吐不仅没翻倍，反而因为通信开销和资源竞争变得更慢，最后定位到的问题，就是网络拥塞和拓扑设计不合理。

2.3 存储：给数据一个合理的分层“仓库”

数据也是硬件基础设施里的大头。很多模型跑不好，不是算力不够，而是数据加载管线把整个训练拖住了。AI 数据通常要分温冷热来存放：最热的数据是当前训练频繁读取的样本，最好放在本地高速盘或内存缓存里；温数据是规模很大的训练集，适合放在能高并发读的并行文件系统中；冷数据则是历史数据、备份和归档，放到容量大、成本低的对象存储里就够用了。

我学到的一个重要经验是：数据加载优化永远应该发生在扩大模型规模之前。先用性能分析工具看一眼训练循环里数据等待的占比。如果 GPU 经常闲着等数据，那么不管换多快的卡都没用。常见的优化手段包括数据预取、IO 直通、格式统一化，以及用分布式缓存缓解热点数据的高频读取。还有一个容易被忽略的点是大模型的 checkpoint 存储。多机训练时，每过一段时间就要保存一次模型状态，如果存储写入速度太慢，checkpoint 过程会阻塞整个训练；更夸张的是集群规模大的时候，checkpoint 存储本身就可能成为性能瓶颈。对这些场景，简单把 checkpoint 丢到普通盘上是不行的，需要专门规划高带宽的存储空间和写入策略，比如异步保存、分片写入、只保存可恢复的最小状态集。

3. 软件层：调度、框架、推理引擎

3.1 训练侧：分布式训练的基本功与选型逻辑

深入学习 AI Infra，绕不开分布式训练。我在学习时把它分成三个台阶：数据并行、模型并行、混合并行。

数据并行最容易理解：每张卡上都放一份完整的模型，训练数据切分成多份，每张卡分别算自己的梯度，最后汇总更新。它的优点是简单，缺点是模型大到一张卡放不下时就直接失效。模型并行则是把模型的不同部分切到不同卡上，每张卡只负责一部分，适合解决“显存放不下”的问题。张量并行是一种模型并行，把某一层的矩阵运算切到多卡上协同完成；流水线并行是另一种，把网络按层划分成段，不同段在不同卡上执行，数据像流水线一样流过各段。实际工程里很少只用一种并行策略，而是组合起来用，比如先张量并行，再数据并行，甚至多层嵌套。

选型逻辑我总结成一句话：能数据并行尽量数据并行，显存放不下再考虑模型并行，模型并行优先考虑通信代价小的方案。因为模型并行往往意味着更多的通信同步，如果卡间互联不行，训练速度会很难看。另外一个很实用的概念是混合精度训练。简单说就是用 FP16/BF16 做大部分计算，用 FP32 做部分敏感操作，既省显存又快。初学者常常忽略精度溢出问题，直接开混合精度训练导致训练不稳定，然后怪框架不行。实际上大多数情况下，只要做好梯度缩放和关键层精度保持，混合精度是既能提速度又省显存的高收益操作。

3.2 推理侧：模型部署本质上是个“排队系统”

训练和推理的思维模式很不一样。训练关心的是吞吐和收敛速度，推理关心的是延迟、吞吐、成本和稳定性。把模型部署上线后，它就是一个实时服务系统，请求随时会来，延迟必须可控。这让我意识到，推理优化本质上是在和一个排队系统打交道。

推理的核心指标是 P99 延迟，也就是 99% 的请求在多少毫秒内完成。很多人只看平均延迟，结果线上偶尔抖动一下，平均延迟没变，用户体验却已经崩了。为了降低 P99，你需要关注几个关键点：一是排队环节，如果请求在服务入口堆积，后续优化模型速度都没用；二是推理本身的算子效率，比如有没有做图优化、算子融合、推理专用内核；三是显存带宽，推理阶段大量操作是“读权重 + 算注意力”，很多时候带宽比算力更稀缺；四是动态批处理，把同时到的多个请求攒成一批处理，可以大幅提升吞吐，但要注意不能让某个请求等太久，需要设计合理的最大等待时间。

量化也是推理优化里常见的手段。把模型权重从 FP16 压到 INT8 或更低，模型体积变小、推理更快，代价是精度损失。我自己的经验是：动手量化之前，先建立好评测集和可量化的指标，否则你根本说不清精度损失到底能不能接受。此外，大模型推理中有一个很关键的概念是 KV Cache，也就是缓存历史 token 对应的中间状态，避免每生成一个 token 都把整段历史重新算一遍。KV Cache 非常吃显存，也是很多大模型服务显存爆掉的重要原因，理解它就理解了大模型部署的核心成本结构。

3.3 资源调度与编排：把算力变成“可分配的公共资源”

单机跑模型不需要调度，多用户共用集群就必须有调度。为什么需要容器和容器编排系统？因为不同任务对算力、内存、网络、存储的需求都不一样，而且环境依赖容易冲突。容器把环境隔离问题解决了，编排系统则负责“谁跑在哪些资源上、什么时候跑、资源不够时怎么排队”。

AI 场景和普通微服务场景对调度的要求还有差异。普通服务追求快速扩容，AI 训练往往需要一整组 GPU 同时到位才能启动，如果只分到一半，任务就只能干等。这在大集群里是个常见低效点：明明 GPU 够多，但因为调度策略不合理，部分任务占着资源等配对，整体利用率上不去。所以现在很多平台会做 GPU 共享、虚拟化、细粒度切分，把一张卡的算力分给多个小需求，减少碎片化浪费。同时还会设计优先级和抢占策略，让高优任务能及时拿到资源，同时避免低优任务一直饿死。

如果把这部分抽象成配置，其实核心就是资源声明和调度策略。比如下面这段描述，就是让任务声明自己需要多少算力资源，调度器据此分配：

resources: requests: cpu: "8" memory: "64Gi" gpu: "4" limits: gpu: "4"

看起来简单，实际难点在于怎么让“请求的资源”和“真实负载特征”匹配上。不少团队在调度层做了定制：根据任务预估时长、显存需求、网络拓扑偏好等因素决定放置位置。学习这部分时，最好带着一个场景去理解：如果给你 100 张卡、三个团队、几十个任务，你怎么制定一套分配规则让整体利用率最高、等待时间最短。这个思考过程比记住任何配置项都有价值。

4. 数据与工具链：容易被忽视的另一半

4.1 数据管线：为什么训练老是“卡”在读取上

模型训练里一个常见怪现象：显卡利用率低，但 CPU 居高不下。十有八九是数据管线没做好。数据管线是从存储系统读取原始数据、做解码、预处理、增强、打包成 batch，再送到 GPU 的一整套流程。任何一个环节慢，GPU 都会饿肚子。

很多新人踩过小文件地狱的坑：几百万张小图片，每张单独一个文件存在磁盘上，每次读取都要经过一次元数据操作，速度极慢。解决的思路通常是两大方向：一是把大量小文件打包成少量大文件，让读取方式更适配存储系统；二是做多级缓存，让高频数据尽量留在内存或本地高速盘里。另一个常见问题是数据增强算得太慢，预处理阶段成了瓶颈；这时候一般会把预处理放到独立进程里并行执行，提前把增强后的数据准备好，训练时候直接从队列里取。

我的建议是：任何一次大数据集训练，先做一次简单的数据加载基准测试。单独跑一遍数据迭代，看看每秒能产出多少个 batch。如果数据迭代速度远低于训练时间，先解决数据再上大规模训练，否则后面 Debug 会让你怀疑人生。这个过程花几个小时，但能省下几天的浪费时间。

4.2 MLOps 工具链：让实验“可复现、可追踪、可回滚”

当模型开始迭代，训练不再是一次性任务，而是一条流水线。实验管理负责记录每次训练的超参、代码版本、数据版本和指标结果；模型仓库负责管理训练好的模型包和版本；CI/CD 负责把代码变更自动变成训练任务或部署任务；监控告警则负责持续观察线上服务的健康状态。

我踩过的一个大坑是不重视实验记录。曾经有一段时期，我改了好几个版本的数据预处理逻辑，却只改了代码没有记录数据版本，结果模型指标提升后，完全说不清是数据变了还是模型结构变了。后来我痛苦地养成一个习惯：每个实验运行前，先把代码 commit 号、数据快照、关键超参全部打成一个固定的实验环境，跑完后强制登记结果。这个习惯看起来很笨，但它是做任何严肃 ML 工程的起点。

工具链不需要一步到位。我建议的最小闭环是：实验管理 + 模型版本管理 + 基础监控。先把“跑出来的结果可追踪”这件事做到位，再逐步加自动化训练流水线和弹性发布策略。工具多了反而容易变成摆设，关键是把数据流动串起来：代码变更产生实验，实验产生模型版本，模型版本发布成服务，服务产生监控指标，指标再反馈到下一轮实验。

5. 学习路线与实操建议

5.1 从单机到集群，按五个阶段走

学习 AI Infra 最容易劝退的是想一步到位，上来就搭一个平台级的东西。我的建议是按阶段走，每个阶段都设定一个“验收标准”，过了再往下走。

阶段一是单卡训练跑通一个小模型。注意不只是训练完成，还要学会看资源利用率和性能数据。阶段二是数据管线优化。把一个真实数据集在小模型上跑熟，观察数据读取和 GPU 等待的比例，尝试不同预处理策略并量化前后差异。阶段三是分布式训练。先把数据并行跑通，再逐步接触模型并行和混合并行，重点关注扩展效率。阶段四是推理部署。训练好模型后，设计一个 HTTP 服务接口，测延迟和吞吐，尝试批处理和量化等优化。阶段五是调度和平台化。把多个训练任务和推理服务放进同一个资源池，设计排队和优先级策略，思考利用率与公平性之间的平衡。

这个顺序背后的逻辑是层层递进的：不先理解单卡训练的过程，就没法判断分布式训练中哪些开销是正常的；不理解数据管线的瓶颈，就很容易把存储问题误判成算力问题；不理解训练，就不可能做好推理部署。每一步的核心都是建立“用数据判断问题”而不是“凭感觉猜问题”的习惯。

5.2 预算有限时，练什么最有性价比

不是人人都有一整机柜的 GPU。我练手时用的是能租到的单机多卡或小规模集群，哪怕只有两张卡，也能把很多核心概念跑明白。单机双卡可以练的东西很多：跑一个需要大显存的模型，试出数据并行和模型并行的显存差异；观察两张卡的通信流量，理解梯度同步的开销；把推理服务部署起来，用压测工具打满它，看 P99 延迟的变化；还可以模拟一个任务排队场景，体会调度器的行为。

如果连 GPU 都没有，也不是不能学。资源调度、存储分层、MLOps 工具链、推理服务的部分内容，都可以用纯 CPU 环境或几台普通云主机来练。关键是不要停留在“看书”的层面，AI Infra 是一门实践性很强的领域，很多经验必须亲手操作过才知道。哪怕只有一个很简陋的实验环境，只要有测量、有对比、有反思，学到的东西比看一百篇文章都管用。

5.3 进阶方向：往哪走才算真的“通了”

基础链路跑通之后，有几个方向值得深入。一个是异构调度，管理混合架构的计算资源，让任务能聪明地选择最合适的硬件。另一个是自动并行，让框架根据模型结构和集群拓扑自动决定采用哪种并行策略，减少人工参数调整。还有一个是大规模集群的稳定性工程，包括故障恢复、容灾、自动扩缩容和成本控制。以及模型服务的高性能优化，比如更优的批处理策略、推测解码、结构化输出等方向。

进阶阶段我开始特别关注“全链路可观测性”。以前学 AI Infra，总以为每个组件单独看都没问题，整体就没问题。后来发现分布式系统里的故障和性能问题，经常是跨组件、跨层次的。没有统一的指标、日志、链路追踪体系，排查问题就像在黑屋子里找一根掉落的针。可观测性是连接所有基础设施层的“仪表盘”，也是判断你系统健康度的第一依赖。

6. 常见问题与排查技巧实录

6.1 训练阶段最常见的四个问题

我在学习和带项目过程中，反复遇到四类问题，几乎适用于所有训练任务。显存爆炸是最容易遇到的。报错说 OOM，第一反应不该是去买更多显存，而是先检查 batch size、模型并行设置、混合精度开关。很多显存问题通过降精度、换梯度策略、开显存优化就能解决。

训练吞吐低是第二类问题。我排查的一贯顺序是：先看 GPU 利用率，再看数据加载是否有阻塞，再看通信占比。如果 GPU 利用率低，多半是数据没跟上；如果利用率还可以但训练速度仍慢，就要怀疑计算效率和通信效率。第三类是训练不稳定，loss 突然变成 NaN 或大幅抖动，常见原因是学习率过大、数据存在异常样本、混合精度溢出。第四类是训练中断，节点故障或网络抖动导致任务失败。处理思路是断点续训、定时 checkpoint、以及保证存储写入的可靠性。

6.2 推理延迟高的排查顺序

推理接口变慢，先别急着改模型。我的排查顺序是：第一步排除“请求根本没到服务”的可能，比如网络、DNS、负载均衡；第二步看服务的排队情况，请求是不是在队列里堆积了，如果是，说明容量不够或并发控制不合理；第三步看单次推理耗时，借助监控拆解 prefill 和生成阶段分别花了多久；第四步再去看是不是模型本身太重，该量化还是该剪枝。

有一次我负责的服务 P99 一直下不来，直觉以为是模型太大、推理太慢。后来拆开看，发现单次推理很快，但请求排队时间占了总延迟的绝大部分。问题出在入口线程池太小，很多请求就是在排队等线程。我不改任何模型逻辑，只调整了并发和队列策略，P99 直接降了一截。这类经验说明一个道理：在 AI Infra 里，很多瓶颈不在 AI 本身，而在基础设施的细节里。

6.3 我总结的六个避坑习惯

首先是不要只看平均值。训练看平均吞吐、推理看平均延迟，都会掩盖大量问题。要习惯看分布和长尾。第二是不要跳过监控直接调优。没有监控就跑优化，等于蒙眼开车。第三是不要一上来就做大改动，每次只改一个变量，记录前后差异。第四是不要把 GPU 利用率当成唯一指标。利用率高也可能是在低效地在计算。第五是不要忽略存储和网络，它们常常才是隐藏瓶颈。第六是永远给故障留预案。训练跑三天不出问题不代表第四天不会出，checkpoint 要勤，发布要能回滚。

这些习惯听起来很基础，但每一条背后都有真实教训。我是在一次次把线上问题折腾到凌晨之后，才真正把它们刻进脑子里的。

最后分享一个很受用的心态：AI Infra 不像算法那样有一个“改结构就能刷点”的即时反馈，它的反馈周期很长，而且很多优化只有到大规模场景下才能体现价值。刚开始学的时候，你可能做了很多事却看不到什么明显收益，这种时候别急着怀疑方向。把基础链路一步步跑扎实，把数据和指标体系建起来，等规模上来之后，你会发现自己前期积累的判断力，比任何单一技巧都值钱。