AI Infra全景解析：从GPU调度到推理服务的六大核心模块

这两年AI技术的发展速度确实让人应接不暇。我自己的感觉是，模型算法本身当然重要，但真正让一个想法从论文变成稳定在线服务的，往往是背后那套看不见的支撑体系。身边不少朋友都在问同一个问题：AI Infra到底在解决什么问题？要做一套能支撑团队日常训练和推理的平台，到底需要掌握哪些东西？不夸张地说，这是一片知识点极其密集的领域，但多数人的认知是零散的、片段的。这篇笔记我想把自己梳理过的AI基础设施全景知识做个系统性整理，让准备入门或者已经被各种名词轰炸的读者，能有一张相对清晰的知识地图。

1. AI Infra到底是什么

1.1 从算力到服务之间的距离

先抛一个我经常用来打比方的说法：如果算法工程师是厨师，那AI Infra就是后厨的整个供水、供电、排水和冷链系统。厨师只需要打开水龙头、打开灶台就能做菜，但水从哪里来、管道怎么铺设、停电了怎么办，这些没人管的话，餐厅一天都开不下去。AI模型训练和推理也同理——数据集放在哪、GPU怎么分配、训练任务挂了怎么自动恢复、模型上线后如何扛住高并发，这些都属于AI Infra的范畴。

很多人以为AI Infra就是把服务器和显卡堆在一起，再装个Kubernetes就行了。这个理解过于简化。普通业务部署关注的是CPU、内存和网络吞吐，而AI场景多出来一个极其重要的维度：GPU。GPU有自己的显存、专用驱动、特殊的通信方式（比如NVLink、RDMA），调度和管理方式跟普通容器完全不是一回事。再加上训练任务动辄跑几小时甚至几天，中途任何一次节点故障、网络抖动都可能导致前功尽弃，所以这个领域的核心关键词实际上是三个：稳定、效率、可观测。

1.2 一个全景视角的模块划分

我在梳理学习笔记时，参考了很多社区开源项目和头部企业的技术分享，把AI Infra拆成了六个模块：算力管理层、数据流水线、训练平台、推理与模型服务、可观测与运维、资源调度与成本优化。这六个模块相互独立又彼此依赖，算力层是底座，数据是喂养模型的粮食，训练平台是工厂，推理服务是最终面向用户的门店，可观测和成本是驾驶室里的仪表盘。

搞清楚这个模块划分，对学习路径很有帮助。很多人一上来就扎进某个具体工具，比如去研究某调度器的源码，结果越钻越深，视野却越来越窄。我建议的做法是先看全景，找到自己当前工作最贴近的模块，然后再往深挖。下文我按模块逐个讲讲每个部分的重点、常用工具和设计思路，最后附上一套比较完整的实操落地路线和排障手册。

2. 算力管理层：AI系统的地基

2.1 GPU调度：独占与共享的平衡

算力管理层是整个平台的地基，它至少要做好三件事：GPU资源的抽象、容器化封装、以及多租户隔离。很多人第一步就在GPU调度上犯了难。

最简单方案是节点级别的独占——一块GPU卡只给一个任务用，互不打扰。这在团队小、任务稀疏的时候完全够用，而且排障特别容易。可一旦任务变多，GPU会有大量空闲时段，例如某个数据预处理任务根本不占显卡，但整张卡被独占，其他推理任务只能排队。这时就需要GPU共享和显存隔离能力。

常见的实现思路有两类：一类是给容器注入虚拟GPU环境，另一类基于驱动层面的MPS（多进程服务）做算力切分。虚拟化方案能细分显存，但在某些算子上的性能损耗比较明显，适合推理和小规模训练；MPS方式共享更彻底，但隔离性弱一点，一个任务显存溢出可能拖累同卡邻居。我自己的经验是：训练任务优先用整卡调度，推理任务用共享调度，混合部署时通过标签把两类任务分开，别让一个跑训练的把显存吃完导致另一边的推理服务全部OOM。

注意：开启GPU共享后，显存监控不能只看nvidia-smi。容器内看到的是虚拟显存数值，物理卡的显存占用要在宿主机侧汇总。之前某个团队排查“显存明明够用但任务起不来”的问题，就是因为平台配置的虚拟显存总额超过了物理卡实际容量。

2.2 镜像与驱动管理：最容易被忽略的坑

算力层还有一个隐形成本很高的环节：镜像管理和驱动兼容。PyTorch版本、CUDA版本、GPU驱动版本，三者一旦不匹配，跑起来全是莫名其妙的报错。比如cuDNN初始化失败、算子编译不过、CUDA driver version is insufficient，十有八九是版本组合问题。

建议团队从一开始就维护一套“AI基础镜像家族”。基础镜像按CUDA和PyTorch版本打标签，比如cuda12.1-py3.10-torch2.1，上层业务镜像从这些基础镜像衍生，锁定所有核心依赖版本。驱动层面，宿主机驱动版本最好高于容器内CUDA要求的下限，避免后期升级驱动时牵连所有存量任务。这块没有太多黑科技，核心就是克制——不要没事升级底层版本，每次升级前做兼容性矩阵验证。

3. 数据流水线：训练的血脉

3.1 数据集管理与版本化

算法团队的数据往往以“目录+文件”的形态散落在各台机器上，这是训练工程化的第一大障碍。训练脚本部署到新环境时，数据集路径对不上、样本数量不确定、数据配比变了导致效果波动，这些我都踩过。

工业级的做法是把数据集当作一等公民来管理。每个数据集有唯一ID、元信息（样本数、格式、标签分布）、版本号。数据集的存储介质可以是对象存储，也可以是并行文件系统，但在平台逻辑层要做统一抽象。为什么需要版本化？因为训练结果必须可复现。模型效果变好了，你要能说出训练数据到底用了什么版本；效果变差了，你要能快速比对是不是数据配比被悄悄改过。

训练任务和特定数据集版本绑定，代码仓库的commit也锁定下来，这样任何一个历史实验都能无缝还原。实现上可以基于现成的ML元数据管理组件，或者自己写一套轻量API包一层，核心是记录什么人在什么时间用什么数据跑出了什么模型。

3.2 数据加载与预处理加速

数据集就绪之后，另一个大头是训练过程中的数据供给。GPU计算速度快，如果数据加载跟不上，GPU就在那里空转，这种现象在监控里会呈现为很低的利用率。行业里的目标很简单：让数据管道的吞吐大于GPU的消费速度。

几个关键手段我都实测过，按投入产出比排序：一是用GPU直接解码，把JPEG/PNG解码放到GPU上做，CPU端只负责最基础的数据读取；二是预处理和训练重叠，利用PyTorch的DataLoader多进程和预取机制，让数据准备好后直接进GPU，这个过程不占用训练时间；三是在数据管道的每个环节做缓存，热数据走内存，温数据走本地NVMe盘，冷数据再落对象存储。数据流水线这个模块很考验全栈思维，需要同时用上操作系统知识、网络知识和存储知识。

实操心得：在容器里跑训练时，数据集挂载方式对性能影响极大。文件数量特别多的小文件场景下，直接把数据集放在网络文件系统上会导致严重的元数据开销。更好的做法是在训练节点本地做缓存预热，训练开始时先把当天需要的样本拉到本地盘，训练过程全程读本地。

4. 训练平台：任务的编排与控制

4.1 为什么训练要单独做一个平台

算力有了、数据也管理好了，接下来要把训练任务跑在集群上。最简单的做法是写个脚本ssh到某台机器上nohup跑，但这样做的痛点太明显：没有资源隔离、任务状态不可见、失败不能自动恢复、多任务并发时互相干扰。

训练平台要解决的核心问题是任务编排，包括资源申请、调度、执行、监控和容错。它跟普通的CI/CD流水线理念类似，差别在于任务的资源需求更加复杂，比如多机多卡任务需要同时申请多台机器的多张GPU，并且要保证机器之间网络互通。如果平台没有这个能力，人肉分配机时是很痛苦的一件事：你得先在群里喊谁有空机器，然后挨个登录配置。

工业场景通常基于Kubernetes做底座，再在其上扩展自定义资源类型，让GPU成为一类可以被调度和申请的资源对象。任务提交时声明“我要4台机器、每台8张卡”，调度器负责寻找满足条件的节点组合，分配成功后把训练进程拉起来并暴露日志和监控指标。

4.2 调度策略与容错设计

平台调度策略直接影响GPU利用率。常见的策略有两类：优先集中调度和优先分散调度。集中式调度会尽量把空闲GPU凑成一个大集合，让大任务有卡可调；分散调度则尽量把任务打散，降低单个节点故障影响面。两种策略没有绝对优劣，我建议的做法是分层：默认情况下先集中后再分散，同时允许人工给任务打标签指定调度偏好。

容错设计是训练平台最容易在初期被忽略的部分。训练任务挂了，平台要自动重试。但这里有个陷阱：如果任务已经跑了十个小时，重试意味着一切从头开始，那损失是巨大的。所以现在的主流框架都支持训练断点恢复，需要平台具备感知和恢复断点的能力。实现上要把模型参数定期写入持久化存储，平台检测到任务异常时重新拉起容器，并从最近一个完好断点处续跑。这里面有一个我踩过的坑：断点信息如果只存在容器本地磁盘，容器一旦被销毁就什么都没了。所以必须有独立于容器生命周期的持久化存储挂载，甚至要支持跨节点读取。

5. 推理与模型服务：在线系统的最后一公里

5.1 从模型文件到在线服务

训练完的模型是一个文件，文件本身不能直接对外提供查询能力，需要有一层把它加载到GPU上，接收请求、完成计算、返回结果。这就是模型服务要解决的问题。

推理服务很大程度是传统后端服务和AI推理引擎的结合体。加载模型、批处理、流式输出、容灾扩容，这部分遵循的是后端通用逻辑；而推理引擎的选择、GPU显存占用、算子融合优化，这部分是AI特有的。之所以要单独讲，是因为在线服务的SLA要求很严格：延迟不能高、吞吐要够大、服务不能中断。一个训练任务挂了可以重新跑，一个线上推理服务挂了用户立刻体感明显。

工程上为了追求极致性能，会把“前处理+推理+后处理”串成异步管道，同时允许同一个GPU上并行驻留多个模型实例，通过动态批处理把请求攒起来喂给GPU，以提高计算吞吐。动态批处理是推理优化里性价比最高的一步，我见过不少团队靠这个手段就把吞吐提升了数倍，代码改动其实很小。

5.2 版本管理与弹性伸缩

模型服务上线后，和普通后端服务一样会面临更新迭代。但模型版本管理有个特色问题：模型还需要灰度验证效果，不只是看错误率和延迟，还要看业务指标，比如推荐点击率、问答满意率。这就需要有A/B测试能力，把一部分流量切到新模型上，持续观察一段时间后再决定是否全量。平台层至少要支持多版本共存、流量按比例分配、上线和回滚一键完成。

弹性伸缩也是模型服务的刚需。业务流量有高峰低谷，如果长期保持最大规格的副本数，成本压力很大。普通的缩扩容阈值是CPU和内存，推理服务还要额外关注GPU利用率和显存余量，否则可能流量还没上来，显存先被占满。云原生社区提供了比较成熟的自动扩缩容机制，我建议再叠加自定义指标，以QPS和GPU利用率为双信号，防止单一指标误判。

6. 可观测、成本与完整落地路线

6.1 可观测性：指标、日志、链路追踪

到了这个层面，平台的用户视角已经从“能不能跑起来”变成了“跑得好不好、出了事怎么查”。一套完整的可观测体系至少要覆盖三层：基础指标、训练过程状态和推理服务链路。

基础指标包括GPU利用率、显存占用、温度、功耗、网络带宽、磁盘I/O。训练过程状态包括当前迭代步数、损失值、学习率、数据加载耗时比、心跳时间。这些信息不但要画成图表，更要在异常时告警。推理服务链路则要把一次完整请求从前端到网关到模型服务的耗时拆开，快速定位瓶颈在哪一层。

我见过太多团队出问题时的状态：训练到半夜挂了，第二天早上才发现，因为没人部署告警；或者线上延迟升高，大家各查各的，互相甩锅。可观测不是锦上添花，而是AI平台能不能长久健康运行的底线。建议从第一天就接入统一的监控体系，宁可指标多一些，也别裸奔上线。

6.2 成本控制与调度优化

大模型训练和推理的成本非常高，很多团队在做AI平台时逃不开一个灵魂拷问：怎么在不影响效率的前提下把钱省下来？这块我总结出三个最有效的抓手。

第一是削峰填谷。训练任务不见得都要立刻跑完，允许用户设置优先级，低优先级任务在夜间或空闲时段运行，利用闲置GPU填满利用率。第二是弹性伸缩。推理服务根据流量自动扩缩容，低谷期把多余实例回收；训练任务也可以支持抢占式实例，被抢占了就等下一轮调度，配合断点续跑机制，整体成本可以下降不少。第三是异构算力匹配。不是所有任务都需要顶尖GPU，数据预处理、小模型微调、批量离线推理用中端卡足够，别所有任务一律上旗舰卡。

6.3 一份可参考的落地路线

如果你所在的团队现在还是脚本满天飞的状态，想逐步搭建一套正式的AI基础设施，我建议按下面这个阶段逐步推进，每一步都能独立产生价值：

第一周先在某一批机器上部署好容器集群，把GPU通过插件接入资源池。同时搭好基础镜像仓库和监控大盘，GPU利用率、节点状态做到可视化。第二阶段把训练任务接入容器平台，先支持单机单卡和单机多卡，命令统一走平台提交。这一步的收益是所有人不用再抢机器。第三阶段上模型管理和推理服务，把训练产物统一入库，提供标准的模型上线接口。第四阶段再逐步支持多机多卡训练、断点续跑、自动弹性伸缩和成本报表。这个顺序能够避免一上来就陷入复杂分布式训练的泥潭。

重要提醒：落地过程中最常见的拦路虎是权限和网络策略。平台要做多租户隔离，数据权限、GPU资源配额、网络策略一样都不能少。我见过有团队功能都做好了，结果因为网络策略没放开，分布式训练跨机通信直接超时，排查了两天才发现是安全策略挡了路。

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

AI Infra的日常工作有很大一部分是处理各种环境性和系统性问题。从一线实战角度，我整理了一份高频问题速查表：

再分享一个让我印象特别深刻的实战案例。某个推理服务在流量高峰期频繁报OOM，一开始大家怀疑是代码泄漏，查了很久没结果。后来我在宿主机上发现，相邻的另一个训练任务把整张卡的显存都申请走了，推理服务的显存是虚拟化出来的，超过物理总量后不断触发重新申请和调度。最后通过给训练和推理划分不同的节点组，并设置显存上限，问题才彻底解决。这类跨任务的资源竞争问题，在纯业务后端几乎不会遇到，但在GPU共享环境里非常普遍。

另外还有一个很隐晦的问题值得提醒：文件句柄和内存回收。长时运行的训练容器里，加载数据集的句柄如果没有正确管理，最终会导致系统级报错。排查这个问题时不要只盯日志，可以在容器内执行系统级命令观察句柄数和内存碎片，很多时候日志文件只是二手证据，现场一手数据才能定位问题。

8. 学习路径与进阶资源方向

8.1 按角色分层规划学习

AI Infra知识面太宽，不同背景的人适合的学习切入点是不同的。如果是后端工程师，建议先补GPU的基础知识——CUDA编程模型、显存管理、GPU通信方式，再上手容器集群和调度系统，最后结合实际项目加深对分布式训练的理解。如果是算法工程师想做工程化，路径刚好反过来：先弄懂训练脚本和推理代码的性能瓶颈在哪，再学容器打包和平台使用，先会用好，再理解实现原理。

如果你想走得更深，需要啃的三块硬骨头分别是：分布式训练框架底层通信原理、GPU虚拟化与调度实现、以及高性能推理引擎的算子优化。这三个方向每一个都够研究很长时间，但一旦通了，你对整个领域的理解会高一个层次。我的观点是：不必一开始就追所有新技术点，把前述六大模块的基础做扎实，遇到场景时再深入对应模块。

8.2 从做笔记到做系统的建议

很多人学AI Infra容易陷入“笔记收藏党”的状态，网课买了不少，文档收藏了一堆，最后遇到实际问题还是不会排查。我的建议是刻意做“问题驱动式学习”：先在自己服务的平台上找一个真实的痛点，比如任务调度不均、模型上线流程太原始，围绕它去检索资料、设计改造方案、动手实现。把每一个问题和对应的解决办法沉淀到自己的知识库里，才能真正内化成能力。

学习过程中一定要关注成本思维。很多方案在理论上很完美，但工程投入和维护成本高到团队无法承接。请记得，一个复杂度高到没有人愿意维护的系统，长期看价值是负的。AI Infra做得好不好，不在于用了多少炫酷的技术，而在于它有没有让算法团队更专注、让资源更高效、让线上服务更稳定。

做这套全景梳理的时候，我自己的一个很深的体会是：AI Infra的复杂度是逐步叠加的，每个模块单独看都不算特别难，难的是把它们组合在一起，还要在每一次环境变更、版本升级、流量波动的冲击下保持稳定。写这篇笔记的目的，是希望给已经在这条路上或者准备进这条路的读者一张清晰的地图。有了全景视角之后再回头看那些具体工具和源码，你会发现自己真正缺的其实不是某条命令怎么敲，而是对整条链路运行逻辑的理解。这个逻辑通了，剩下的技术点都是时间问题。