2.1 AI 负载特性与 Kubernetes 适配挑战

文档摘要

2.1 AI 负载特性与 Kubernetes 适配挑战 Kubernetes 是为「跑一堆 nginx、随便重启无所谓」的无状态 Web 服务设计的；但 AI 负载是「跑一个 8 卡训练，挂了等于一周白干」的有状态重负载——把后者塞进前者的框架，挑战天然存在。 2.1.1 三类 AI 负载与它们的「脾气」云原生 AI 集群里通常混跑着三类性质截然不同的负载，对 K8s 的诉求也各不相同。理解这三类负载的差异，是设计 AI 集群的第一步。

2.1 AI 负载特性与 Kubernetes 适配挑战

Kubernetes 是为「跑一堆 nginx、随便重启无所谓」的无状态 Web 服务设计的；但 AI 负载是「跑一个 8 卡训练，挂了等于一周白干」的有状态重负载——把后者塞进前者的框架，挑战天然存在。

2.1.1 三类 AI 负载与它们的「脾气」

云原生 AI 集群里通常混跑着三类性质截然不同的负载，对 K8s 的诉求也各不相同。理解这三类负载的差异，是设计 AI 集群的第一步。

三类负载的特性对比：

维度	在线推理	分布式训练	批处理评估
生命周期	常驻（周/月）	临时（小时/天）	临时（分钟/小时）
GPU 使用	利用率随流量波动	长时间接近满载	偶尔使用或不用
关键指标	延迟（P99）	吞吐（samples/s）	完成时间
容错性	单实例可重启	全组绑定、一损俱损	可中断重跑
资源需求	GPU + 内存	GPU + 大带宽网络	CPU + IO
典型 K8s 对象	Deployment / InferenceService	Job 群（Operator 管理）	Job

💡 判读：在线推理像「客服坐席」，要常驻、要快、可以替换；分布式训练像「合唱团」，必须同时在场、一个人掉队全团重来；批处理像「外卖骑手」，临时来、跑完走、可以中断重派。K8s 默认的 Deployment 与 Job 适合前者和后者，但中间的「合唱团」需要专门的 Operator 来管理。

2.1.2 挑战一：长时训练与 Pod 驱逐

K8s 默认假设 Pod 是「廉价、可重启」的。但当一个分布式训练跑了 5 天，第 6 天节点被驱逐，等于一周白干。Pod 驱逐（Eviction）的常见触发点有几个：

节点资源压力：节点内存/磁盘紧张时，K8s 会按优先级驱逐 Pod。训练 Pod 如果没设高优先级，容易被清掉。
节点维护：集群升级、节点重启时，所有 Pod 被驱逐。
抢占（Preemption）：高优先级任务到来时，低优先级任务被抢占。

应对长时训练的工程实践：

实践	说明
检查点（Checkpoint）	定期保存训练状态到持久存储，重启后从断点恢复
PodDisruptionBudget	限制自愿驱逐（如节点维护）的最大并发数
优先级与抢占	给训练任务设高优先级，避免被低优先级任务挤掉
亲和与污点	把训练任务调度到专用节点池，避免与其他负载混部

⚠️ 现实代价：一个 8 卡训练跑一周，若未做检查点，中途崩溃的成本是 8 卡 × 7 天的算力 + 重启后再跑一周的等待。检查点不是可选项，而是必需品。第 3 章会讲弹性训练与断点续训的工程实现。

2.1.3 挑战二：GPU 这种「特殊资源」

CPU 和内存是「连续可分」的资源——一个 Pod 申请 0.5 核 CPU，K8s 能精确分配。但 GPU 是「离散且昂贵」的异构资源，K8s 默认并不知道它的存在，需要额外的机制来：

发现与上报：让 K8s 知道这台节点上有几张 GPU、什么型号。
调度与分配：让 Pod 能声明「我要 1 张 GPU」，并由调度器分配。
隔离与挂载：把分配到的 GPU 设备文件、驱动库挂载进容器。

这套机制最早是 Device Plugin，后来演进到 CDI。2.2 节会详细讲。

GPU 调度的另一个特殊性是它默认不可切分——一张 GPU 要么给一个 Pod，要么不给。这导致独占模式下 GPU 利用率极低（详见 1.1 节）。如何让一张 GPU 被多个 Pod 共享，是第 3 章的核心议题。

2.1.4 挑战三：有状态性与检查点管理

在线推理是无状态的（任何副本都能处理任何请求），但训练是有状态的——训练状态（模型权重、优化器状态、学习率调度）必须跨重启保留。这要求：

持久化存储：检查点要写到持久卷（PVC）或对象存储（S3/OSS），不能只放本地盘。
跨节点恢复：节点崩溃后，新 Pod 可能在另一台节点上重启，要能读到原检查点。
版本管理：检查点是带版本的，要能回溯到任意一次保存点。

K8s 的 PersistentVolume、StorageClass、对象存储 CSI 提供了基础设施，但训练框架侧的检查点逻辑（如 PyTorch 的 torch.save、DeepSpeed 的检查点格式）需要与 K8s 的卷管理配合。

2.1.5 挑战四：批处理与在线混部的资源博弈

把训练与推理放在同一个集群，可以显著提升 GPU 整体利用率——白天推理高峰用一部分卡，夜间推理低谷把卡给训练。但这种混部（Colocation）带来两类冲突：

资源冲突：训练任务要 8 张卡，但节点上还有 2 张被推理占用，训练任务无法启动（除非等推理缩容）。
性能干扰：即使资源够，训练与推理共享同一张 GPU 或同一网络时，可能互相拖慢。

混部的工程实践涉及：

节点池划分：把训练专用节点与推理专用节点物理隔离，或用污点标记。
优先级与抢占：定义清楚哪类任务可以让位哪类任务。
批处理调度器：用 Volcano、Kueue 等做队列与配额管理（第 3 章）。
弹性 AllReduce：训练能容忍节点数量变化，让训练「填满」空闲资源（第 3 章）。

2.1.6 挑战五：网络与存储 IO 的爆发

分布式训练对网络与存储的要求远超 Web 服务：

网络：AllReduce 等集合通信原语对带宽与延迟极敏感（详见第 5 章），常需要 InfiniBand 或 RDMA over Converged Ethernet（RoCE）。通用 K8s 网络的 CNI（如 Calico、Flannel）往往满足不了。
存储：训练数据集动辄 TB 级，检查点也是 GB 级，对存储吞吐要求高。需要高性能分布式文件系统（如 Lustre、CPFS）或缓存层（如 Alluxio）。

IO 类型	Web 服务需求	AI 训练需求	典型方案
网络	几 Gbps、毫秒级延迟	几百 Gbps、微秒级延迟	InfiniBand、RoCE、SR-IOV
存储	GB 级、随机读	TB 级、顺序大块读 + 写检查点	对象存储 + 缓存、Lustre
内存	几 GB	几百 GB（KV Cache、激活值）	大内存节点、HBM

💡 判读：在 AI 集群里，「网络与存储往往比 GPU 本身更难搞」。许多团队把精力都放在 GPU 调度上，结果上线后发现 AllReduce 通信慢一倍、检查点写入瓶颈，训练吞吐远低于预期。第 3 章的拓扑感知调度会专门讲网络拓扑对训练的影响。

2.1.7 一张表收束：K8s 默认能力 vs AI 需求

把上述五大挑战与 K8s 默认能力的差距汇总，这是本章及后续章节要补齐的全部内容：

AI 需求	K8s 默认能力	差距	补齐方式（章节）
GPU 资源管理	不识别 GPU	大	Device Plugin / CDI（2.2）
长时训练不被驱逐	默认可驱逐	中	PDB + 优先级 + 检查点（2.1、3.4）
一张 GPU 共享	不可切分	大	MIG / MPS（3.1）
分布式训练拓扑对齐	不感知拓扑	大	拓扑感知调度（3.2）
训练任务编排	通用 Job 不够用	中	Training Operator（2.4、5.2）
训练-推理混部	无队列与配额	中	Volcano / Kueue（3.3）
高性能网络/存储	默认 CNI 与存储	大	InfiniBand + 缓存层（3.2、5.x）

这张表的右列，正是第 2-3 章的完整路线图。

本节小结

云原生 AI 集群混跑三类负载：在线推理（常驻、低延迟）、分布式训练（临时、高吞吐、强绑定）、批处理（临时、可中断），对 K8s 的诉求各不相同。
长时训练对 Pod 驱逐极敏感，必须配检查点、PodDisruptionBudget、高优先级来保障。
GPU 是离散且昂贵的异构资源，K8s 默认不识别，需要 Device Plugin / CDI 机制来发现、上报、调度、隔离。
训练-推理混部能提升利用率，但需要节点池划分、优先级、批处理调度器、弹性训练来化解冲突。
网络与存储 IO 在 AI 集群中往往比 GPU 本身更难，InfiniBand/RoCE 与缓存层是基础设施关键。
K8s 默认能力与 AI 需求的七大差距，正是第 2-3 章要补齐的全部内容。

下一节《2.2 GPU 资源建模：Device Plugin、CDI 与 Extended Resource》将讲清 GPU 如何被 K8s 识别、上报与调度。