Volcano：批处理语义与 AI 作业调度

草稿

真正可治理的 GPU 平台，必须让“资源单位”与“作业秩序”协同演进。Volcano 补齐了原生 Kubernetes 在 AI 训练和批处理场景下的调度语义缺口，让平台从“能跑”走向“可运营”。

Volcano 解决的是“秩序”，不是“资源单位”

在 GPU 场景下，Volcano 的核心价值在于为一组 Pods 提供作业级别的调度、排队、抢占、配额与公平治理能力，而不是实现 GPU 的共享或切分（这属于数据平面，如 MIG、HAMi、驱动与运行时等）。具体来说：

  • 数据平面决定：你能把一张卡变成什么“资源单位”（整卡 / MIG / vGPU / time-slicing 等），以及隔离、干扰、可观测的下限。
  • 控制面（Volcano） 决定：当资源紧张、队列拥塞、多个团队竞争、作业有拓扑与同步约束时，系统如何做准入、排序、成组调度、抢占与公平。

这两者正交但可组合。真正可交付的 GPU 平台，通常必须同时具备二者。

原生 Kubernetes 的调度语义缺口

AI 训练和分布式作业对调度有特殊需求。原生 Kubernetes 调度目标偏向“尽快把单个 Pod 放进去”，而 AI 训练常常要求“一个作业的一组 Pods 必须一起满足条件”。典型缺口包括：

  • Gang / All-or-nothing：分布式训练需要 N 个 worker/ps/launcher 同时就绪，否则要么空转，要么失败重试。
  • 队列与配额：训练是典型的突发与长尾资源消耗，必须先排队、再准入，而不是无限制地把 Pending 堆在集群里。
  • 优先级与抢占：同一集群既跑训练也跑推理/评测时，需要可解释的优先级与抢占策略。
  • 公平性与组织边界：以团队、项目、租户维度做公平分享与“可审计”的资源承诺。
  • 作业级生命周期：失败策略、重试、扩缩容、最小可运行规模等是作业语义，而不是 Pod 语义。

Volcano 的核心就是补齐这些“批处理语义”，并将其变成可运营的控制面能力。

Volcano 的控制面抽象：从 Pod 到 Job/Queue

Volcano 将调度对象从单 Pod 提升为“作业与队列”，常用抽象可以理解为三层：

Job / Task（作业与任务组）

在 Volcano 中，Job 描述一个批处理作业，由多个 Task 组成。Task 通常是一组同构 Pod（如 worker x 8），可配置最小副本数、重试策略等。

对于 AI 场景，Task 往往映射为 launcher、worker、parameter server、evaluator 等角色。

PodGroup（成组调度的原子单元）

PodGroup（或等价的 gang 语义）是 Volcano 区别于原生调度的关键。只有当满足 PodGroup 的最小资源、最小成员条件时，才会整体进入运行态，否则保持等待，避免“部分启动导致集群空转”。

这对 GPU 尤其关键。例如，8 卡训练只拿到 2 卡就先跑起来，往往会在 NCCL 或同步点反复超时。

Queue / Quota / Priority（秩序的三要素）

  • Queue：显式排队与准入的边界，通常映射为团队、项目或环境。
  • Quota：队列的资源上限、保证与借用规则（不同部署会有不同实现深度）。
  • Priority：在队列内与队列间做排序，并通过抢占将优先级落到执行层。

你可以把它们视为一个"资源市场"的规则集：谁先用、谁能借、谁必须让。

下图展示从单个 Pod 调度到作业级别调度的演进。队列与配额层（Queue/Quota/Priority）提供资源市场的规则集，决定谁先用、谁能借、谁必须让；成组调度层（PodGroup/Gang Scheduling）确保满足最小条件才整体运行，避免部分启动导致集群空转；作业与任务层（Job/Task）将分布式训练等作业描述为多个 Task 组（如 worker、launcher、parameter server）。Volcano 通过这三层抽象，实现了从能跑到可运营的治理能力升级。

图 1: Volcano 的控制面抽象：从 Pod 到 Job/Queue
图 1: Volcano 的控制面抽象：从 Pod 到 Job/Queue

Volcano 的调度能力：策略与插件化

Volcano 的调度能力通常以策略和插件组合呈现，常见能力包括：

  • Gang scheduling：满足最小规模才准入，否则持续等待。
  • Backfill：在不破坏高优先级作业可启动性的前提下，用小作业填空，提升整体利用率。
  • Preemption（抢占）：当高优作业需要资源时，按策略驱逐低优作业。
  • DRF/公平分享：以多资源维度（CPU、内存、GPU）做相对公平。
  • 拓扑/亲和性协同：与 node/pod affinity、拓扑约束结合，尽量把通信密集型训练放到更优拓扑上。

需要强调边界：Volcano 不理解 GPU 干扰与隔离细节，只消费 K8s 资源模型中暴露的资源单位与约束。因此，数据平面暴露的资源单位越可声明、越可计量，Volcano 的控制面治理就越可验证。

下图展示 Volcano 的 5 大核心调度能力。Gang Scheduling（成组调度）确保满足最小规模才准入，避免部分启动；Backfill（填空调度）用小作业填缝提升整体利用率；Preemption（抢占）按策略驱逐低优作业；DRF/Fair Share（公平分享）提供多资源维度的相对公平；Topology Affinity（拓扑亲和性）优化通信密集型训练拓扑。图中特别强调了 Volcano 的能力边界：它不理解 GPU 干扰与隔离细节，只消费 K8s 资源模型，需要与数据平面协同才能实现端到端闭环。

图 2: Volcano 的核心调度能力
图 2: Volcano 的核心调度能力

与 GPU 数据平面的组合方式

将 Volcano 放回本书的体系中，它需要与数据平面协作才能形成端到端闭环。以下是三种典型组合方式：

整卡分配（最小集成，最强确定性）

  • 数据平面：NVIDIA device plugin 暴露整卡资源（nvidia.com/gpu）。
  • 控制面：Volcano 提供队列、gang、抢占能力。
  • 适用场景：训练集群起步期、多租户边界强、对干扰容忍度低。

MIG（硬切分：强隔离但单位离散）

  • 数据平面：将 GPU 切成离散 MIG profile，暴露为多种资源（如不同 profile 的资源名或标签）。
  • 控制面：Volcano 负责“作业整体满足 N 个 profile”与队列治理，调度目标变成“匹配离散资源池”。
  • 适用场景：在线推理或多租户训练需要强隔离，但需接受碎片化与重配置运维成本。

HAMi / 共享型虚拟化（可声明共享，治理难度上升）

  • 数据平面：将共享从“能跑”升级到“可声明、可计量、可隔离（至少部分）”。
  • 控制面：Volcano 仍负责队列、优先级、作业语义，但需要依赖数据平面提供的计量与隔离信号，否则抢占与公平会变成“不可验证的承诺”。
  • 适用场景：推理、评测、轻量训练的高密度混部，但必须直面 P99 干扰、噪声邻居与观测闭环。

一句话总结：Volcano 决定"谁先跑、跑多少、能不能一起跑"；数据平面决定"跑起来之后会不会互相影响、影响能否被观测与治理"。

下图展示 Volcano 与不同数据平面技术的三种典型组合。方案 A（整卡分配）：NVIDIA device plugin 暴露整卡 + Volcano 提供队列/gang/抢占，适合训练集群起步期、多租户边界强、对干扰容忍度低的场景；方案 B（MIG）：GPU 切成离散 MIG profile + Volcano 负责作业整体满足 N 个 profile，适合在线推理或多租户训练需要强隔离的场景；方案 C（HAMi/共享型虚拟化）：将共享升级为可声明、可计量、可隔离 + Volcano 提供队列/优先级，适合推理、评测、轻量训练的高密度混部场景。三种方案的核心差异在于数据平面的隔离能力与 Volcano 的治理能力的协同程度。

图 3: Volcano 与 GPU 数据平面的三种组合方式
图 3: Volcano 与 GPU 数据平面的三种组合方式

典型 AI 场景下的使用模式

在实际 AI 平台中，Volcano 的应用模式主要包括以下几类：

分布式训练

分布式训练是最典型的应用场景。常见做法包括：

  • 用 PodGroup/Job 把 worker、launcher 绑定成一个调度原子。
  • 用 Queue 把团队、项目隔离，配合 Priority 处理紧急训练与回归任务。
  • 配合 backfill 提升利用率：小作业填缝，但不阻塞大作业。

关键验收点：

  • “最小可运行规模”是否被严格执行，避免部分启动。
  • 抢占是否可解释、可回溯（谁被抢、为什么、代价是什么）。
  • 训练失败重试是否造成队列震荡与资源抖动。

评测/批量推理

评测通常是大量短作业，最怕排队开销大、抢占导致尾部变差。常见策略：

  • 优先选择 backfill 与更温和的抢占。
  • 在队列里设置更细的优先级层级，避免大规模短作业把长作业“饿死”。

与在线推理共存（混部集群）

这是最容易“概念上想得通，现实里翻车”的场景：

  • Volcano 可以把推理视为高优先级队列或作业，必要时抢占训练。
  • 但如果数据平面没有足够隔离与计量，推理的 P99 抖动往往不是靠“抢占语义”能彻底解决的。

因此更推荐：在线推理优先靠隔离与资源单位保证（如 MIG、强隔离或专用池），Volcano 主要用于训练与批处理域。

运维与落地：让“策略”变成“可运营的规则”

在落地 Volcano 时，建议关注“规则是否可验证”，而不是功能是否齐全。具体包括：

  • 准入与队列治理：是否有明确的队列边界，默认队列是否会成为黑洞。
  • 资源承诺模型：Quota 是硬上限、软保证还是可借用？对应的 SLO、成本模型是什么？
  • 抢占策略：抢占的触发条件、优先级边界、被抢作业的恢复成本（checkpoint、重跑）是否可接受。
  • 观测闭环：至少要能回答三类问题：
    • 为什么某作业排队这么久（准入、资源不足、拓扑约束、配额）？
    • 为什么被抢占（优先级、队列规则、资源回收）？
    • 真正的 GPU 利用率是否提升，还是只是在“排队层面看起来更有秩序”？

如果这些问题回答不清楚，Volcano 只会把复杂性从“调度器的 Pending”搬到“平台团队的工单”。

Volcano 在 GPU 平台体系中的位置

  • Volcano 是控制面：提供批处理语义（队列、优先级、公平、准入、成组调度、抢占）。
  • 它不解决 GPU 的切分、虚拟化、隔离，但决定这些能力如何被组织起来交付。
  • 在端到端体系中，Volcano 与 MIG、HAMi 等数据平面能力组合后，才可能形成“既能跑、又可治理、还能验收”的 GPU 平台。

下一章将对比 Kueue：当你更希望“沿用原生 K8s API 与生态”时，控制面该如何演进，以及 Volcano、Kueue 在不同组织与平台路径下的取舍边界。

总结

Volcano 通过补齐原生 Kubernetes 在 AI 训练和批处理场景下的调度语义缺口，使平台具备了队列、优先级、公平、准入、成组调度、抢占等可运营的控制面能力。它与数据平面能力协同，帮助构建真正可治理、可观测、可交付的 GPU 平台。实际落地时，需关注规则的可验证性和治理闭环，才能实现平台的高效与可持续运营。

创建于 2025/12/30 更新于 2026/01/02 3906 字 阅读约 8 分钟