AI 平台：批调度、分布式训练与模型服务

为什么 GPU 集群必须先排队#

上一章 GPU 与 AI 工作负载 解决的是「一张卡怎么被 Pod 用上」。当集群从 2 张卡变成 200 张卡、从一个人用变成一个部门用，问题就换了：不是「能不能用」，而是谁先用、能用多少、抢不到怎么办。

三个物理事实决定了这件事不能靠原生调度器硬扛：

• 整卡占用、不可超卖：nvidia.com/gpu 只能申请整数，一张卡不会被拆给两个 Pod。于是碎片是真实存在的：8 卡机器被 8 个单卡任务占满，下一个要 16 卡的任务就永远等不到。
• 一个训练任务是一组 Pod：数据并行要 N 个 worker 加一个 launcher。这组 Pod 只要有一个上不去，其余先起来也是白占卡——它们在等对端，谁都不干活。
• 多团队共享一台集群：有人跑长训练、有人做交互式微调、有人线上推理。没有优先级和抢占，长训练会把集群堵死；没有配额，一个团队能吃掉所有卡。

gang scheduling：要么全给，要么都不给#

上面第二条就是 gang scheduling（组调度）：把一组 Pod 当作一个整体调度，全部放得下就一起放行，否则一个都不放。它不是「更聪明的装箱」，而是避免一种死锁：

集群剩 4 卡，两个任务各要 4 卡（每任务 4 个 Pod）

不组调度：A 拿到 2 卡、B 拿到 2 卡 → 两边都在等队友 → 4 张卡被永久占住却零计算
组调度：  A 整组不放行、B 整组不放行 → 0 卡被浪费，等其中一个能整组凑齐再放行

原生调度器是逐个 Pod 决策的，它不知道 Pod3 和 Pod4 属于同一个任务，所以会做出「先给一部分」这种局部最优、全局死锁的决定。队列入场后，判断单位从 Pod 变成「整组」，问题才消失。

队列层要回答的四个问题#

ResourceQuota 和队列不是二选一：配额管「这个团队最多占多少」，队列管「什么时候能占、谁先占」。

三个关键词：队列、优先级、抢占#

• 队列（queue）：任务的入口。Kueue 里是 LocalQueue（命名空间）→ ClusterQueue（集群配额池）→ ResourceFlavor（节点池）；Volcano 里是一棵 Queue 树，安装后自带 root 与 default。
• 优先级（priority）：同一队列里谁先被放行。Volcano 用 Kubernetes 原生 PriorityClass；Kueue 有独立的 WorkloadPriorityClass（也可沿用 Pod 的 PriorityClass），别混着理解。
• 抢占（preemption）：高优先级任务插队时，把已占资源的低优先级任务驱逐掉。代价是被抢占的任务必须能从检查点恢复，否则前面几小时白跑。

批调度三件套：Kueue、Volcano 与 scheduler-plugins#

社区有三条路线，差别不在于「谁功能多」，而在于在链路的哪一层做组判断：

选型可以简化成一句话：想要「配额 + 排队」就用 Kueue，想要「复杂调度策略 + 多租户公平」才上 Volcano。 二者功能重叠，同时装在一个集群会打架（见下）。Kubernetes 原生的 gang scheduling（PodGroup / 调度组）已在 v1.35 引入 Alpha，默认关闭、不要用于生产，成熟度按最新 release 核对。

Kueue 的资源模型#

一句话记住：ResourceFlavor 说「哪种机器」，ClusterQueue 说「总共多少」，LocalQueue 说「谁能来排」。

LocalQueue(ns=team-a) ──► ClusterQueue(nominalQuota: 8 卡) ──► ResourceFlavor(H100 节点池)
LocalQueue(ns=team-b) ──►      ▲ 同一个配额池，按队列分配            ▲ 通过 nodeLabels 绑定

关键点：nominalQuota 是手工配额，Kueue 不会自动去数集群有多少卡。填多了会绕过兜底，填少了会让任务白排队。经验做法是填该节点池 allocatable 的汇总（注意是 allocatable，不是 capacity）。

不能把 Kueue 和 Volcano 装在一起（除非你改配置）#

这是实际踩过的最坑：Kueue 的 Pod mutating webhook 会拦截 Pod 创建，如果 Pod 没带 kueue.x-k8s.io/queue-name label，它会注入 `suspended=true` 并覆盖 `schedulerName`。Volcano 的 Pod 正好不带这个 label，于是全部被改回默认调度器并挂起，Volcano 直接瘫痪。规避方式只有一条：非要共存就把 Kueue 的 integrations.frameworks 限制成只处理 Job 类资源（如 batch/job、trainer.kubeflow.org/trainjob），绝对不要包含 `pod` 和 `deployment`。对多数集群来说，二选一更省事。

参考：reference/k8s-in-action/ai/scheduling-comparison.md、reference/k8s-in-action/ai/kueue/README.md、reference/k8s-in-action/ai/volcano/README.md

任务从提交到落卡：一张全景图#

  用户 / 提交入口
   │  kubectl apply TrainJob / Job / RayJob / InferenceService
   ▼
┌───────────────────────────────────────────────────────────────┐
│ 队列与准入层（Kueue 准入 / Volcano 调度）                     │
│  LocalQueue(ns) ──► ClusterQueue(配额池) ──► ResourceFlavor   │
│    ├── 资源够 ──► Admit ──► 创建 Pod                          │
│    ├── 资源不够 ──► 排队（Kueue: 0 Pod / Volcano: Pending）   │
│    └── 更高优先级 ──► 抢占（驱逐低优先级 Workload）           │
└───────────────────────────────────────────────────────────────┘
   ▼
  工作负载层：训练 TrainJob / RayJob / LWS · 推理 Deployment / InferenceService
   ▼
  GPU 节点池：Device Plugin 分配整卡 ──► 容器内可见 /dev/nvidia*

  训练任务生命周期：
  提交 ──► 排队(suspend) ──► 准入(Admit) ──► 拉镜像/加载数据 ──► 运行
   ▲                                        ├─► 定期写 checkpoint ─► 成功
   └── 失败重试 / 被抢占后从最近 checkpoint 恢复 ◄── 节点故障、OOM、超时

分布式训练：从单卡到多机多卡#

单卡放不下模型、或者单卡跑得太慢，就要并行：数据并行（每卡一份模型、分数据）、张量并行（一层拆到多卡）、流水线并行（不同层放不同卡）。无论哪种，跨卡跨机通信都会成为瓶颈——同节点走 NVLink/NVSwitch，跨节点走 RDMA（InfiniBand 或 RoCE）。网络没配好，加卡只会更慢。

MPI Operator 与 Kubeflow Trainer#

MPI Operator 提供 MPIJob CRD，把作业展开成 1 个 launcher Pod 加 N 个 worker Pod，用 SSH 打通后用 mpirun 启动各个 rank；它要求镜像里有一个能跑的 sshd（这一点比想象中更容易漏）。定位是「以 MPI 为进程启动器」的 HPC 风格训练，NCCL 测试也常走这条路。

Kubeflow Trainer 是目前更推荐的统一入口：TrainJob + TrainingRuntime 屏蔽 PyTorchJob/MPIJob 等底层差异，自动注入 rank / world_size / master_addr，基于 JobSet 管理 launcher 与 worker 多副本，并原生对接 Kueue / Volcano 做 gang 调度。想少写胶水代码，从这里开始。

用 NCCL 测试验证多卡通信#

训练慢，先别改模型——先证明通信达标。nccl-tests 的 all_reduce_perf 是标准做法，一次正确性扫描加一次持续压测：

# 提交测试任务后看 launcher 日志
kubectl logs -l trainer.kubeflow.org/replicated-job-name=launcher -f --tail=-1

看末尾的 busbw（总线带宽）：理论峰值约等于「网卡数 × 单口带宽 ÷ 8」，90% 以上算优秀，80~90% 可接受，低于 80% 就是异常。异常时按顺序查：NCCL_SOCKET_IFNAME 是否选对网卡、NCCL_IB_HCA 是否命中 RDMA 设备、MTU 与 GID index 是否正确、两个 Pod 之间能否互相解析与连通。RoCE 用 hostNetwork 时别忘 hostNetwork: true。

Ray 与 LeaderWorkerSet：两种编排路线#

• KubeRay（Ray）：RayCluster / RayJob / RayService 三个 CRD，覆盖创建集群、提交作业、无停机升级。Ray 的定位是通用分布式计算引擎（Task/Actor/Object + Train/Tune/Serve 库），适合 Python 生态、超参搜索、需要弹性的训练与在线服务；代价是引入一整套运行时，调试栈变长。
• LeaderWorkerSet（LWS）：更轻的抽象——一个 leader 加一组 worker 视为一个整体，整组扩缩、整组滚动更新，天然提供 gang 语义和稳定序号。它不关心框架是 vLLM 还是 SGLang，只负责「把这组 Pod 一起管起来」，因此特别适合跨节点大模型推理（例如需要 2 台机器 16 张卡才装得下的 671B 模型）。

参考：reference/k8s-in-action/ai/kuberay/README.md、reference/k8s-in-action/ai/lws/README.md

检查点与失败重试#

在「队列 + 抢占」的集群里，任务被中断是常态而不是事故：被高优先级任务抢占、节点故障、OOM、超过 activeDeadlineSeconds。所以训练任务的设计原则和普通 Job 不同：

• 定期写 checkpoint 到持久卷：本地盘随 Pod 消失，必须写到 存储与 PVC 或对象存储；除了权重还要保存 optimizer 状态与当前 step，否则恢复后学习率调度会错乱。
• 恢复要幂等：启动时先找最近 checkpoint，找到就续训，找不到才从头开始。写成代码逻辑，别指望人工干预。
• 重试要有限度：restartPolicy: Never 配合 backoffLimit，让「代码有 bug」的任务尽快失败退出，而不是无限循环烧卡。
• 检查点本身也要能备份：卷坏了、误删了怎么办，见备份与恢复。

模型服务与平台周边#

训练产出的模型最终要变成服务。裸的 Deployment + Service 就能跑推理，但一旦要管理几十个模型、灰度发布、按流量伸缩，就需要控制面。

副本与显存：先算清楚再扩容#

推理副本数不是想加就加，它受显存硬约束：副本数 × 单副本显存 ≤ 卡容量。单副本显存大致是「模型权重 + KV cache + 框架开销」，其中 KV cache 随并发请求线性增长，所以并发上限约等于「（可用显存 − 权重 − 预留）÷ 每请求 KV」。显存不够时先降 max_model_len 或调低框架的显存占用比例，而不是盲目加副本——两个副本挤一张卡只会互相 OOM。张量并行需要多卡同节点（走 NVLink）甚至跨节点（走 RDMA），这时要用 LWS 这类能把一组 Pod 一起管的编排方式。

冷启动与模型缓存#

大模型权重几十 GB，冷启动是推理服务最容易被低估的一环：

• 权重放镜像里：镜像巨大、拉取慢，每个节点都存一份，升级一次全量重拉。
• 权重放 PVC 或对象存储：镜像小，但每个副本启动都要读一遍几十 GB，首字节延迟高。
• 预热到节点本地盘 + 多副本共享只读模型：目前最优解，配合 initContainer 在节点空闲时提前把权重拉到本地缓存。
• 探针必须配合：加载期间用 startupProbe 圈出启动期，livenessProbe 不要查下游依赖，否则模型没加载完就被重启，陷入 CrashLoopBackOff（见探针与资源管理）。
• Serverless 缩到 0 要谨慎：冷启动几十秒到几分钟，缩到 0 省钱但会让第一个请求超时，线上服务通常至少保 1 个副本。

llm-d 这类推理网关解决的正是上面剩下的问题：把请求按 KV cache 命中和负载路由到合适的副本，并把 prefill 与 decode 拆到不同实例上调度，从而提高整集群吞吐。它需要 Gateway API Inference Extension 等上游组件配合，具体能力与版本按上游最新 release 核对，这里只做定位。

周边组件一句话定位#

参考：reference/k8s-in-action/ai/kubeflow/README.md、reference/k8s-in-action/ai/llm-d/README.md、reference/k8s-in-action/ai/llm/README.md

动手：用 Kueue 建队列并提交一个 1 卡任务#

这个练习的目标不是跑出模型，而是看见排队本身：配额只有 1 卡，两个各要 1 卡的任务，第二个必然要等第一个结束。先装 Kueue（版本按最新 release 替换）：

helm repo add kueue https://kubernetes-sigs.github.io/kueue/charts
helm repo update
helm install kueue kueue/kueue -n kueue-system --create-namespace --version 0.11.0
kubectl -n kueue-system get pods        # controller-manager 应为 Running

# apiVersion 以集群实际提供的版本为准：kubectl api-resources --api-group=kueue.x-k8s.io
# 较新版本（v0.13+）会提供 v1beta2，换成它即可，字段结构一致。
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: gpu-flavor
spec: {}
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: gpu-cluster-queue
spec:
  namespaceSelector: {}
  resourceGroups:
    - coveredResources: ["nvidia.com/gpu"]
      flavors:
        - name: gpu-flavor
          resources:
            - name: nvidia.com/gpu
              nominalQuota: 1        # 手工填写，Kueue 不会自动发现集群容量
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  name: gpu-local-queue
  namespace: default
spec:
  clusterQueue: gpu-cluster-queue

kubectl apply -f kueue-queue.yaml
kubectl get clusterqueue gpu-cluster-queue     # ACTIVE 列应为 True
kubectl get localqueue -n default              # 应看到 gpu-local-queue

apiVersion: batch/v1
kind: Job
metadata:
  name: gpu-batch-demo
  labels:
    kueue.x-k8s.io/queue-name: gpu-local-queue
spec:
  suspend: true                  # Kueue 准入后会自动改成 false
  backoffLimit: 1
  template:
    spec:
      restartPolicy: Never
      # GPU 节点有污点时补上，否则 Kueue 放行了 Pod 也上不去
      # tolerations:
      #   - key: nvidia.com/gpu
      #     operator: Exists
      #     effect: NoSchedule
      containers:
        - name: train
          image: nvcr.io/nvidia/cuda:12.6.2-base-ubuntu24.04
          command: ["bash", "-c", "nvidia-smi -L && sleep 60"]
          resources:
            requests:
              nvidia.com/gpu: 1
            limits:
              nvidia.com/gpu: 1

kubectl apply -f gpu-batch-demo.yaml
kubectl get workloads -n default                                   # ① ADMITTED 列：True 表示已准入
kubectl describe workload -n default job-gpu-batch-demo | grep -A5 "Conditions:"
# Workload 名字形如 job-gpu-batch-demo（Kueue 在属主名前加类型前缀，以 get 的输出为准）
kubectl get job gpu-batch-demo -o jsonpath='{.spec.suspend}{"\n"}' # ② 应为 false
kubectl get pods -n default -l job-name=gpu-batch-demo             # ③ Pod 真的起来了
kubectl logs job/gpu-batch-demo                                    # 容器里看得见卡

sed 's/gpu-batch-demo/gpu-batch-demo-2/' gpu-batch-demo.yaml | kubectl apply -f -
kubectl get workloads -n default                                       # 第二个的 ADMITTED 应为 False
kubectl get job gpu-batch-demo-2 -o jsonpath='{.spec.suspend}{"\n"}'   # 仍为 true
kubectl get pods -n default -l job-name=gpu-batch-demo-2               # 0 个 Pod

kubectl delete -f gpu-batch-demo.yaml
kubectl delete job gpu-batch-demo-2
kubectl delete -f kueue-queue.yaml

如果集群装的是 Volcano，同一件事换成 PodGroup（spec.minMember 必须等于工作负载的 Pod 数）+ Pod 上指定 schedulerName: volcano 并加 scheduling.k8s.io/group-name annotation。注意顺序陷阱：Job/TrainJob 不会自动创建 PodGroup，必须先 apply PodGroup 再提交负载，否则永远匹配不到 Gang。验证用 kubectl get podgroups.scheduling.volcano.sh -A，若集群只剩 1 张空卡，你会看到两个 Pod 都 Pending——这就是 gang scheduling 的直观表现。参考：reference/k8s-in-action/ai/volcano/README.md。

常见错误速查表#

排 AI 平台的问题，先分清是没被放行、放行了上不去，还是跑起来才出问题：

自测题#

小结#

• GPU 集群的问题不是「有没有卡」，而是整卡不可超卖 + 一组 Pod 必须一起起 + 多团队要公平；队列层负责回答「何时创建、谁先跑、谁被抢」。
• gang scheduling 把调度单位从 Pod 换成整组，避免「各占一半、谁也跑不动」的死锁；Kueue 在准入层做（零 Pod），Volcano 在调度层做（整组 Pending）。
• 选型上 Kueue 优先、Volcano 备选、Coscheduling 不要上生产；两者共存必须先处理 Kueue 的 Pod webhook，否则 Volcano 会被覆盖 schedulerName。
• 分布式训练先验证通信：用 NCCL `all_reduce_perf` 看 0 OK 与 busbw 是否达到理论峰值的 90%；编排上 Kubeflow Trainer 是统一入口，Ray 适合弹性与 Python 生态，LWS 适合把一组 Pod 整体管理的多节点推理。
• 训练任务必须能续训：定期 checkpoint 落持久卷，重试有限度，把「被抢占」当成设计前提而不是意外。
• 推理服务受显存硬约束，副本数 × 单副本显存 ≤ 卡容量；冷启动靠模型预热与探针配合；KServe 负责把部署标准化，Kubeflow 是更大的平台套件，llm-d 这类推理网关解决请求路由与 PD 分离。

相关章节：GPU 资源模型、共享与探针细节见 GPU 与 AI 工作负载；标签、污点与优先级抢占的基础见调度入门；检查点落盘与共享存储见存储与 PVC；被抢占后的数据保护见备份与恢复；GPU 指标与告警见可观测性；命名空间配额与多租户见命名空间与 RBAC；模型与镜像的分发缓存见镜像与缓存。

练习#

1. 你的集群有 3 台 8 卡节点，一个团队要跑「每次 16 卡、单次 6 小时」的训练，另一个团队要跑「随时提交、每次 1 卡、5 分钟」的微调。请写出你会怎么划分 ClusterQueue 配额、怎么设置两个 WorkloadPriorityClass，并说明长训练被抢占后靠什么恢复。
2. 用 nccl-tests 的 all_reduce_perf 在你环境里跑一次单机 2 卡测试，记录最大 size 那一行的 busbw，对照网卡理论峰值算出百分比。如果低于 80%，列出你会依次检查的三个环境变量和一条连通性命令。
3. 假设要部署一个 70B 模型：权重约 140GB（FP16），单卡 80GB。请判断需要几张卡、用哪种并行方式（TP/PP 还是量化后单卡）、用 Deployment 还是 LWS，并说明冷启动时你会怎么让 startupProbe 与模型预热配合。

到这里，平台化模块就收尾了：把 GPU 变成队列、把训练变成可重试的作业、把模型变成可交付的服务。回到可观测性和备份与恢复把这条链路的「看得见」和「回得来」补上，再回到综合实战用一套完整集群把它们串起来。