从运维到AI-Infra：GPU调度、分布式训练与基础设施的底层逻辑

1. 从“运维偏科”到“AI-Infra”—我为什么选择这个方向

说实话，两年前如果有人跟我说，你以后的工作重心会从K8s集群、容器网络、监控告警，转向GPU卡池、任务队列、分布式训练效率，我大概率会不以为然。那时候我对AI-Infra的理解很模糊，觉得它无非就是在通用云基础设施上加一层GPU调度而已，跑通了就行，细节嘛，后面再说。

真正改变我想法的是一次线上事故。业务方提交了一个大规模模型训练任务，资源配额充足、镜像也没有问题，但训练就是跑不起来。跟我一起排查平台团队的同事故了很久日志，最终发现问题出在GPU显存与任务调度器的配合上：任务A在某个节点上没退干净，显存残留占着不释放，任务B一到就被判资源不足，反复排队干瞪眼。那一刻我才意识到，AI场景下的基础设施，和传统Web业务基础设施的逻辑完全是两回事。

这个系列我会以“一线工程师”的视角，把我在AI-Infra这条路上遇到的问题、踩过的坑、沉淀下来的方案讲透。第一章先不讲高深理论，也不上架构图，就聊聊AI-Infra究竟是什么、它跟传统基础设施差在哪里、为什么值得你花时间投入。后面几章会逐步展开GPU资源池、训练任务编排、数据缓存与存储、推理服务高可用、成本治理等主题，每一章都会围绕真实场景来讲。

这个系列适合谁？我认为有三类人：

• 在传统运维或SRE岗位干了几年，想了解AI基础设施是怎么回事的工程师；
• 已经开始接触机器学习平台、GPU调度、分布式训练，但缺乏系统梳理的开发者；
• 团队里负责算法、开发、基础设施三方协作的负责人，想搞清楚AI-Infra边界到底画在哪。

如果你正处在“隐约觉得AI-Infra很火，但不知道它具体做什么”的状态，这篇文章就是为你准备的。

2. AI-Infra的边界：它到底管哪一段

2.1 一个训练任务从提交到完成，中间发生了什么

聊AI-Infra之前，我们得先统一视角：AI应用或者说Model Application的生命周期大致可以拆成数据准备、模型训练、模型评估、模型部署与推理这几个阶段。AI-Infra关心的不是模型算法本身，而是让整个生命周期能够稳定、高效地跑起来的一整套底层支撑系统。

我们以“在GPU集群上训练一个大语言模型”这个最常见的场景为例，把链路拉出来看：

• 数据侧：需要从数据湖读写样本，经过预处理、清洗、token化等操作，产出可训练的样本集；
• 资源侧：需要申请GPU节点、CPU节点、内存、存储卷，并且保证GPU驱动、CUDA版本、容器运行时都要和训练框架匹配；
• 调度侧：任务管理器负责把训练任务分配到合适的节点，处理排队、优先级、抢占、重试等逻辑；
• 训练侧：分布式训练框架（比如PyTorch、DeepSpeed、Megatron等）负责把模型切片到多张卡上，做前向、反向、梯度同步；
• 存储侧：模型中间checkpoint要频繁落盘，训练样本要反复读取，对存储带宽和时延有极高要求；
• 运维侧：监控训练进程、GPU利用率、显存占用、网络吞吐，任务异常了要自动告警、自动恢复。

传统基础设施语境里，我们通常做到“资源分配”和“进程跑起来”就算完工。但在AI-Infra语境里，“跑起来”只是及格线，更重要的是“跑得快、跑得稳、算力不浪费”。这就引出一个核心问题：AI-Infra的工作对象和传统基础设施到底有什么本质区别。

2.2 传统基础设施与AI基础设施的本质差异

差异可以从几个维度看，我用表格拉出来对比一下：

其中最关键的是“资源形态”这一行。

传统业务里，一个服务崩了，再拉起一个副本就行，负载均衡自动重试；但一个训练任务跑了10个小时后节点故障，如果checkpoint频率不够，可能白跑几个小时甚至十几个小时。GPU不像CPU那样可以随意共享和抢占，显存一旦被占，其他任务只能等着。GPU互联拓扑（比如NVLink连接、PCIe Switch位置）直接影响多卡训练效率，不是把所有卡塞到一个节点就万事大吉。

这些差异决定了AI-Infra的每一个设计决策，都必须回到“算力”和“效率”两个关键词上。我后面几章遇到的几乎所有坑，都能从这个维度找到根源。

2.3 AI-Infra的五大核心板块

如果要对AI-Infra做一个范围界定，我会把它拆成五个核心板块。这也是我之后几章会逐个展开的主题：

1. 算力平台层：GPU资源池化、节点管理、驱动与运行时环境、多租户隔离、配额管理；
2. 调度编排层：训练任务调度器、排队策略、优先级抢占、弹性伸缩、故障驱逐与重调度；
3. 数据与存储层：高速缓存、数据集版本管理、checkpoint生命周期管理、分布式文件系统的选型与调优；
4. 训练接入层：面向算法工程师的接口面，提交训练任务的SDK/CLI、日志、Debug环境、实验追踪；
5. 推理服务层：模型部署、GPU推理加速、动态批处理（Dynamic Batching）、自动扩缩容、在线与离线推理的隔离。

这五个板块不是孤立存在的，它们之间的衔接往往就是故障爆发的地方。比如算力平台层的K8s调度器不知道“某张GPU卡的显存已被残留进程占住”，就会把任务调度上去，然后抛出“CUDA Out Of Memory”。这类问题的本质不是某一块没做好，而是板块交界处的信息没有打通。

这一章不追求让读者把每个板块都弄懂，而是希望先建立一个认知框架：AI-Infra不是某一种具体系统，而是横跨算力、调度、数据、训练、推理的完整链路。

3. AI-Infra工程师的一天：效率与故障的拉锯战

3.1 上午十点的GPU利用率告警，远不是“重启一下”那么简单

想理解AI-Infra的工作内容，看一天流程比看架构图更直观。我拿自己某一天的工作来举例，你会发现大部分时间不是在“建设”系统，而是在“协调资源”和“排查问题”。

早上刚到工位，大概十点出头，监控告警响了：某个训练集群的份额利用率降到了20%。打开面板一看，有30多个任务处于Pending状态。按经验，先看是否有节点异常，再看是否有大任务占用了独占资源。结果节点都正常，GPU也有空闲，这就更奇怪了。

往上追查队列状态和调度策略，终于发现问题：团队A一个分布式训练任务一次性申请了64张卡，而且设置了“若无法完整申请则继续等待”的AllOrNothing分配策略。团队B的任务虽然只申请8卡，却排在后面被长队阻塞。而GPU集群总卡数是96，团队A的64卡任务一直凑不齐，团队B的8卡任务也被卡住，大量时间白白浪费。

这种回复往往只能从调度策略上做文章。后来我们做了两项改动：支持任务先到先得的抢占策略，并用Backfill机制让小任务在关键时暂用空闲卡位。这里的细节，我放在“训练任务如何排队才算合理”当章详述。但从这一天你能看出，AI-Infra工程师的工作不是纯粹的“系统开发”，而是一场持续的资源博弈。

3.2 下午排查显存碎片：不止看占用率

下午这个问题更典型。有同事反馈，某台8卡节点明明只有2个训练任务在跑，nvidia-smi显示显存占用量并不高，但第三个任务就是启动失败，报错CUDA_OUT_OF_MEMORY。直觉告诉我，这是碎片化残留。

排查过程是这样来的：先在节点上用nvidia-smi查看进程表，发现有个已退出容器的残留进程，占着第2张和第4张卡各4GB显存。该进程既不在K8s的Pod列表里，也不在任何健康检查逻辑里，是之前某次重启失败留下的孤儿进程。于是我们处理掉它，再让任务启动，问题迎刃而解。

如果就此打住，下次还会踩同样的坑。我们随后在节点上部署了GPU状态采集Agent，每隔30秒抓一次显存分配、进程数、显存残留数，如果检测到异常进程残留，就把节点自动标记为“待维护”，等新任务调度时尽量跳过，并触发告警引导人工处理。这个方案的核心思路是：把“看不见的GPU内部状态”纳入到基础的资源管理逻辑中。

3.3 深夜的checkpoint恢复：验证你的备份策略是否可靠

晚上快下班时，又有训练任务因硬件故障中断了，跑了两小时的模型几乎全丢。其实我们的训练框架本身支持断点续训，但前提是设置合理的Epoch间checkpoint。问题出在业务方没有配置checkpoint的保存路径——默认路径写在了临时目录里，容器重建后文件直接消失。

那一天，我们又补了几个自动化细节：为每个训练任务注入默认checkpoint保存目录，在任务启动时自动检查“最近一次的持久化检查点是否成功”；在一个企业内部，挂掉了不叫大事，让人崩溃的是发现“挂了之后找不回状态”。

这大概是AI-Infra工作最真实的一天：你以为自己在做平台，实际上在做“解除各类意外的手工活”。不过，正因如此，设计出来的系统才真正贴近实际场景。

4. 为什么训练任务跑得慢：三个最容易忽略的瓶颈

4.1 卡间通信拓扑：GPU不总是“平等”的

很多人第一次接触分布式训练，以为只要把batch拆到多张卡上，速度就线性增长。现实远非如此。GPU之间的通信能力差异非常大，NVLink互联的两张卡通信带宽能达到600GB/s以上，而走PCIe或者QPI总线跨Socket通信，往往只剩几十GB/s。这个差距直接影响梯度同步的速度。

举个实际案例。我们曾经在一个8卡节点上跑模型训练，发现速度不及预期的60%。排查下来，第0到3号卡和第4到7号卡分属两个不同的PCIe Switch域，梯度同步大量走了CPU内存中转。把任务绑定到同一通信域内的卡之后，训练吞吐立刻提升了一大截。这个经验告诉我们：在AI-Infra层面，评估“可用GPU”不能只看“有多少张卡空闲”，还要看卡间拓扑是否匹配训练框架的单机多卡通信模式。把这套信息做成调度器可感知的Label，是一线工程师早晚要面对的事。

4.2 数据读取比GPU计算慢：Bounds在哪里，一切优化都白搭

第二个瓶颈常常出现在数据管道。

不少训练任务前期都跑得稀疏平常，但当数据集变大后，数据加载变成了真正的限制。举个简单的数字：1张A100的FP16算力大约能达到312 TFLOPS，理论上一分钟可以处理海量数据。若池中数据放在普通NFS共享盘上，每秒只能读几百MB，训练就会长期处于“等着数据搬运”的状态。

这里需要补充的是衡量标准：“GPU利用率”高并不等于“有效计算”高。实际场景里我们见过类似CPU频繁等待数据的案例。可以让数据管线使用数据集缓存与异步预取机制，提前把样本从远端存储读到本地NVMe，训练进程直接消费本地数据。改进后端到端吞吐提升了大概30%。

所以AI-Infra工程师不做算法调优，却能凭这套数据策略影响训练效率——这个角色价值，值得被看见。

4.3 容器退出后的资源残留与不完整清理

前面提过的显存残留，其实还可以再往下挖一层。

在K8s默认调度里，Pod生命周期结束后，容器释放，CPU内存都被回收；但GPU显存的释放动作并不一定可靠，尤其是使用CUDA的进程被强制杀掉时，显存映射可能未完全清理，即使进程不存在，nvidia-smi也可能看到“残留”的已用显存，这便会在新任务调度时造成混淆。

我们的做法是，在节点GPU监控Agent中增加定期抓取显存状态与残留判断的能力，检测到异常时顺手触发节点标签的禁用动作。这套机制有效防止了“不可见残留”拖垮整个集群的调度效率。

这三个瓶颈，单靠“加机器”解决不了。它们需要你重新审视拓扑、重构数据路径、补全状态管理。这就是AI-Infra的日常复杂度，也是它的魅力所在。

5. 算力成本治理：GPU不总是“越多越好”

5.1 “排队抢占”与“空闲浪费”，先想清楚谁更重要

在很多公司，GPU资源池是比云上EC2更贵的存在。如果你把GPU当成通用CPU资源来管理，就会出现善恶两个极端：空闲排队无尽，资源利用率却低得可怜。

AI-Infra的算力治理核心，是明确资源分配策略：

• 优先级抢占：大模型训练任务优先级高，小实验任务可以被挤掉，但要保证小任务的checkpoint可靠，避免占用浪费；
• 弹性配额：团队配额不总是固定值，可以设置波峰波谷，给突发需求留出缓冲；
• 任务级超时回收：有些跑偏的任务长期挂起，占着GPU不做事，需要有超时回收机制，或者设置意向反馈上下线。

“GPU利用率和任务完成时间”本身就是一对矛盾体，优先保证谁，取决于业务目标和组织阶段。刚起步时，大家更关心“能不能跑”；扩展到规模化后，成本才浮出水面。不要指望一套策略通吃所有阶段，治理是一个循序渐进的过程。

5.2 按卡时计量：让每个算法团队都感受到成本压力

我们早期踩过一个坑，就是GPU随便申请，项目组感受不到成本压力，结果不少人把A100当远程CPU用，跑一些本该在CPU上完成的任务。

后来平台上线了“卡时计量与账单透视”功能，用户可以在提交任务前预估花费，任务完成之后能看成本报表，GPU空闲比例和团队使用率透明可见。效果不是立刻变好，但一段时间后，明显有团队开始主动清理不需要的模型实例，开始思考到底怎么优化训练频率。“让成本可见”这件事，和制定调度策略同样重要。如果使用GPU的人看不到真实成本，所有资源优化的努力都是隔靴搔痒。

6. 第一章的收尾：AI-Infra的“第一性原理”与先行者的三个建议

6.1 第一性原理：算力不裸奔，效率是生命线

如果这一章能留下一个核心观点，我给它的定义是：AI-Infra的第一性原理是用任何手段，让昂贵的AI计算资源人尽其用、物尽其力。

它不是某一个工具，也不只是一套K8s插件，而是以目标导向设计基础设施的思路。从以前“把服务跑起来就结束”，到如今“把计算过程优化顺畅”，这中间横跨的是认知升级。

内存分配失败、GPU驱动不兼容、数据读取阻塞、断点恢复失效、任务调度死锁，这些问题在AI场景中，比传统Web场景出现的频率高得多、影响大得多。有了第一性原理的思维方式，你在面对陌生故障时至少知道往哪里假设、从哪里排查，不会陷入盲目重启的循环。

6.2 给正在入局这条路的工程师三句实在话

第一，先动手搭一个最小链路。哪怕是在一台有GPU的开发机上，从零开始跑一次“提交训练任务—监控资源—读取日志—调整参数—再次提交”的循环。切身感受一次“资源申请到真正执行之间延迟到底卡在哪”，你对AI-Infra的理解会比读十篇文章都深。

第二，把传统运维能力迁移到AI场景，而不是丢弃。Linux系统、K8s调度、监控告警、网络与存储的基础能力在AI-Infra这里依然是地基。你缺的只是新对象：GPU、CUDA、分布式训练框架、显存拓扑。把这些新对象像老朋友一样熟悉起来，能力模型就成形了。

第三，学会和算法工程师对话。AI-Infra必须服务算法团队，了解他们提交任务时最痛的点（排队太久、启动报错、环境不一致、日志难查），把这些痛点当作功能设计的起点。技术再深，如果方向不对，价值就有限。

这一章到这里停下。下一章我会把“GPU资源池”打开来聊：从设备插件编写、虚拟化切分、显存管理、到多租户配额与计费打通，全程都有具体工程细节和故障复盘。

如果你现在正站在AI-Infra的门口，我希望这一章能成为你的第一块铺路石。后续的每一章，我都尽量讲得比这一章更具体、更硬核一些。