集群调度

3 秒看懂

集群调度（Cluster Scheduling）是在大型分布式计算集群中，自动将任务/作业分配到合适的计算节点并安排执行顺序的决策系统。它的核心使命是：在满足资源需求与约束的前提下，最大化集群利用率、缩短作业等待与完成时间、保障服务等级（SLO）。在 AI 大模型训练等高要求场景中，调度器必须同时感知网络的拓扑结构、通信模式以及 GPU 的亲和性，才能把上千个协同的“克降训练”进程精确地排布到物理机器上，避免因通信瓶颈拖垮整个任务。

3 分钟产业解释

云、大数据和 AI 的爆发，让集群调度从 HPC 的批处理系统（如 Slurm）演变为云原生时代基础设施的“大脑”。如今，Kubernetes 调度器是容器化集群事实上的心脏，但原生调度能力在面向 AI 训练、大规模数据和在线离线混部时暴露出短板：它不理解分布式训练需要的“全员就绪再启动”（Gang Scheduling），也难以处理 GPU 直连拓扑、NVLink/NVSwitch 高速互联等异构亲和性。

为此，产业界涌现出专门化的调度层：Volcano（云原生批调度）、YuniKorn（资源公平共享）、Kubernetes 增强的拓扑管理器，以及各大云厂商自研的 AI 调度引擎。它们通过插件化、多级队列、拓扑感知等机制，让一个集群能同时跑在线微服务、批式训练、流式数据管道，并能根据业务优先级动态调整，从“尽力而为”走向“可预测、可保障”。随着千卡甚至万卡级训练集群成为标配，集群调度的效率直接转换为算力成本与模型迭代速度——最终体现为巨大的商业价值。

15 分钟专家深入

AI 训练对集群调度的挑战集中在三个层面：

作业粒度与生命周期

• 分布式训练作业由一组紧密协作的 Worker（参数服务器、计算节点）组成，它们需要同时启动、同时失败（All‑or‑Nothing）。普通的“一个个 Pod 随意调度”会导致部分 Worker 因资源不足而挂起，触发无限的等待或重复重启。
• Gang Scheduling 是解决此问题的核心机制：调度器必须一次为整个任务预留足够的资源，在所有成员均获得分配承诺后，才统一绑定并启动；过程中任何资源不足都会让整个作业排队，避免占据部分资源却没有进展。

通信拓扑感知

• 大模型训练使用 AllReduce、AllGather 等集合通信操作，数据在节点间高速流转。如果调度器只考虑 CPU/内存/GPU 卡数，而忽视节点间通信距离，很可能造成跨机架的 Ring 链路跳数过多，或使高速 NVLink 域内的 GPU 被零散分配，破坏紧耦合通信的低延迟优势。
• 高级调度策略需结合 节点拓扑树（NUMA 节点、GPU 与网卡亲和性、机架/交换机层级），尽量将同一任务的 Worker 放置在同一交换机下或同一 NVSWitch 域内，甚至精确控制 GPU 与 RDMA 网卡的 PCIe 拓扑对齐。

异构与碎片化管理

• 真实训练集群中同时存在 A100、H100、A800 等不同世代 GPU，显存、计算精度差异显著。调度器需要作业声明“需求特征”（如显存带宽、Tensor Core 代数），而不是仅仅“请求 N 块 GPU”。同时，长期运行产生的资源碎片（每个节点剩余少量资源但不满足任何大作业）会严重降低有效利用率；通过 增量式重调度、占位 Job 驱逐、碎片整理 等手段可提升可分配资源比例。

一些典型实现：

• Kubernetes 调度器引入 Topology Manager 与 Node Resource Manager 提供基础的 NUMA 对齐；
• Volcano 通过 PodGroup 实现 Gang scheduling、队列优先级、公平共享和作业顺序控制；
• 深度 AI 平台（如 Run:ai）直接重建了一层面向 GPU 调度的资源抽象，支持细粒度的 GPU 分时复用和动态配置。

技术原理（最深）

本节深入 Kubernetes 调度器与增强机制的原理，它们是目前最普遍的可扩展调度框架。

调度流水线模型

Kubernetes 调度器采用控制循环式架构，可抽象为三个阶段：

1. 入队：待调度 Pod 按优先级进入队列；高优先级 Pod 总是优先尝试调度。
2. 过滤（Filter）：遍历所有 Node，快速排除不满足硬约束的节点（资源不足、污点/容忍、端口冲突、volume zone 限制等）。
3. 打分（Score）：对通过过滤的每个节点计算一个加权分数；最终选择分数最高的节点进行绑定（Bind）。

原生调度器支持多级扩展点（Scheduling Framework），允许外部插件在过滤前、过滤后、打分前、绑定前等 10+ 个扩展点介入决策，极大降低了定制调度器的开发成本。

  ┌───────────┐    ┌───────────────┐    ┌───────────────┐
  │  Scheduler │    │   Filter Phase │    │   Score Phase  │
  │   Queue    │───▶│  (hard filters) │───▶│ (soft ranking) │───▶ Bind
  └───────────┘    └───────────────┘    └───────────────┘

过滤插件示例

• NodeResourcesFit：检查 CPU、内存、暂态存储等是否满足 Request；
• NodeAffinity / PodAffinity：依据标签与拓扑键选择或排斥节点/可用区；
• Taint/Toleration：节点上的污点排斥未声明容忍的 Pod；
• VolumeBinding：确保 PV 所在 Zone 与节点可挂载区域一致。

打分插件示例

• LeastRequestedPriority：倾向于已分配资源较少的节点，让负载更均匀；
• BalancedResourceAllocation：防止 CPU 与内存比例极度失衡（减少碎片）；
• ImageLocality：给予已缓存容器镜像的节点更高分，减少拉取延迟。

AI 调度增强的核心机制

Gang Scheduling 流程（以 Volcano 为例）

1. 用户提交作业创建一个 PodGroup 最小单位，设定 minMember 参数；
2. Volcano 的会话级调度器在分配空余资源前，会检查是否能够一次性满足整个 PodGroup 所有成员的资源请求；
3. 若可以，则一次性为所有 Pod 预定资源并触发绑定；若不够，则整个 PodGroup 留在队列中，不会分配部分 Pod 而浪费资源。
4. 队列内有优先级和公平份额算法（DRF），保证多租户下资源不被饥饿。

拓扑感知分配示意 考虑一个双路服务器，每个 NUMA 节点下挂载 4 块 GPU、一个 InfiniBand HCA。理想调度下，作业的一个 Worker 所需的 8 块 GPU 应全部从同一 NUMA 节点或同一个 PCIe Switch 下分配，以避免跨 QPI/UPI 瓶颈；同时该 Worker 的 RDMA 通信设备应选取与 GPU 在同一 PCIe 域内的 HCA。 调度器通过读取节点 Topology Manager 报告的一系列 “资源域”（resource zones）与 “拓扑提示”，在过滤阶段将无法满足拓扑约束的节点排除，打分阶段为紧密放置的节点倾向更高分。

技术演进史

• 主机时代：操作系统将多任务调度在单机 CPU 核上，满足批处理需求；不具备集群视角。
• HPC 批调度：PBS、SGE、Slurm 统治超算与科研集群，支持 MPI 并行任务、节点独占、网络拓扑感知，但配置静态，动态扩展和容器化支持薄弱。
• 大数据时代的资源统一管理：Apache Hadoop YARN 将计算资源与数据调度分离，支持多种计算框架混跑；Apache Mesos 提供两级调度模型，让不同框架（Spark、Hadoop、Kubernetes）共享集群。二者都让集群利用率大幅提升，但缺乏细粒度的应用感知和弹性策略。
• 云原生的标准化崛起：Google 凭 Borg 系统的经验设计出 Kubernetes，将容器作为一等公民，调度器内嵌为控制平面核心。Kubernetes 调度器的可扩展框架让社区迅速衍生出自定义调度方案。
• AI/ML 负载驱动的专用调度：随着 GPU 集群规模突破千卡，Kubernetes 原生调度瓶颈显现。Volcano、YuniKorn、Kubeflow 等补充了 Gang Scheduling、队列管理、动态资源配额，并与 Slurm 形成竞争/互补。云厂商进一步基于内核+硬件 telemetry 构建更智能的拓扑感知和碎片整理调度，进入“决策优化”深水区。

技术路线对比

下表基于定性分析对比几种代表性调度方案（均无检索数据，基于公开文档与社区描述）：

上下游

• 上游

  • 物理硬件层：GPU/CPU 服务器、InfiniBand/RoCE 交换网络、NVSwitch 拓扑 —— 这些硬件的连接关系直接成为调度器需要感知的“拓扑图”。
  • 系统软件层：Linux 内核（cgroup、NUMA 信息导出）、容器运行时（containerd）、网络插件（Calico，确保 Pod 网络连通）、设备插件（NVIDIA GPU device plugin，上报 GPU 型号和健康状态）。
  • 集群基础设施层：Kubernetes 控制面（API Server、Scheduler、Controller Manager）、节点监控（Prometheus 采集各类资源指标）。

• 下游

  • AI 训练框架：PyTorch DDP、DeepSpeed、Megatron-LM 用 torchrun 或 mpirun 启动分布式的进程组；调度器需要把每个进程（Pod）从容地放置好并提供通信环境变量。
  • 推理服务：Triton Inference Server、TensorFlow Serving 的模型加载副本需要弹性伸缩，调度器按流量压力分配新实例。
  • 大数据与流处理：Spark on K8s、Flink 需要批量生成 Executor Pod，调度器需要高效处理大批量 Pod 创建请求，减少排队延迟。
  • 在线微服务：长期运行的业务 Pod，对资源稳定性和中断容忍度低，调度器需小心处理抢占和驱逐策略。

关键指标

评估集群调度方案时，业内（大厂混部与云服务）关注的定性指标包括：

• 调度延迟：从 Pod 创建到绑定节点的端到端时间（P50/P95）。AI 训练反复启动/失败时，过长的延迟会显著拉长实验周期。
• 调度吞吐：单位时间内能完成调度的 Pod/作业数量；大规模启动时（如 2000 个 Worker）必须具备线性或次线性扩展能力，否则成为瓶颈。
• 资源利用率：CPU/内存/GPU 的平均分配率与瞬时实际使用率之间的差距；通过混部、碎片整理可将利用率从 3040% 提升到 6080% 以上。
• 作业排队时间：作业在队列中等待调度的时间分布；公平调度算法需要在吞吐量与饿死概率间平衡。
• 调度正确性/公平性：是否严格遵守亲和/反亲和、资源份额、优先级约束；在高资源竞争场景下，低优先级作业的等待时间是否可控。
• 故障恢复时间：节点或作业失败后，重调度的时延（包括检查点恢复所需的资源重分配）。

供需与市场数据

（因特定检索不可用，以下为基于行业趋势的定性总结，无引用可验证数据，请视为经验性描述。）

• 供给侧：以 Kubernetes 为基础的容器编排已成为公有云、私有云标杆。各云厂商均提供托管的 Kubernetes 服务，并将自研的调度增强（如 GKE 的拓扑管理、ACK 的 Co‑Scheduling 能力）作为差异化卖点。开源领域，Volcano 成为云原生计算基金会（CNCF）项目，生态地位上升。
• 需求侧：AI 训练集群规模爆发式增长（数千到上万卡），企业对资源利用率优化的需求无比迫切。传统企业也在将大数据和 AI 工作负载统一上 K8s，需要更智能的批调度。边缘计算场景的延伸催生了多集群、跨地域调度需求。
• 市场动态：云原生市场仍保持较高增长率，调度相关初创公司（如 Run:ai，专注 GPU 细粒度调度与共享）获得资本关注；大型科技公司内部自研调度器的技术外溢也为开源社区持续注入创新动力。整体看，高效集群调度已成为算力即服务的核心底层资产。

代表公司与资本映射

（以下提及的公司和项目均基于公开领域认知，回报与估值数据未检索，不予量化。）

• 云服务巨头：Amazon EKS、Azure AKS、Google GKE、阿里云 ACK、腾讯云 TKE 等，它们提供托管 K8s 并内置不同程度的增强调度能力。其对调度的投入直接影响云算力业务的成本结构与客户黏性。
• 开源商业化公司：Red Hat（OpenShift）在企业级 K8s 调度管理上深耕；SUSE（Rancher）提供简化的多集群管理；VMware（Tanzu）已在调度上有投入。
• AI 训练调度创新企业：Run:ai 提供 K8s 上的 GPU 虚拟化与动态调度，由 Insight Partners 等资本支持；Anyscale（Ray 的商用公司）解决 Python 分布式作业的调度问题，在 LLM 推理调度上有布局。
• 开源调度器项目背后的推动力量：Volcano 由华为云发起，YuniKorn 起源于 Apple 并捐赠给 Apache 基金会，两者都吸引了多家企业参与贡献，形成生态护城河。

对投资者而言，掌握差异化调度能力是云和 AI 平台构建壁垒的核心手段之一。能实现 GPU 利用率大幅提升并将碎片率降到极低的方案，可直接影响基础设施 TCO，具有明确的商业转换价值。

投资逻辑

1. 降本增效刚需：当 GPU 集群数以亿计的资本支出成为现实，调度优化率每提升 10 个百分点，可节省千万级成本，使得能提供高级调度方案的公司（无论是独立软件或集成于云平台）具备极强的客户拉动力。
2. 生态锁定效应：一旦客户的训练管道、自动化流程与特定调度器的 API/定制插件深度绑定，迁移成本高昂，这为先行建立企业级调度标准的公司带来订阅式收入和高留存。
3. 技术演进方向：关注具备 拓扑感知+碎片整理+多元算力混部 全链路能力的项目；边缘场景的轻量级调度（K3s、MicroK8s 增强）也因 5G+IoT 打开新空间。
4. 风险提示：云原生调度层本身有被大厂托管服务“内置化”以至独立软件市场受限的可能；开源项目商业模式仍需验证，过度依赖单一社区贡献者可能导致路线摇摆。

常见误读纠偏

误读 1：“Kubernetes 调度器只能跑无状态微服务，做 AI 训练不行。”

事实：通过 StatefulSet 管理节点身份、使用拓扑约束保持 GPU 与 RDMA 网卡亲和、再结合 Volcano 等插件提供 Gang Scheduling 与队列优先级，Kubernetes 已能稳定支撑数千 GPU 卡的分布式训练。各大科技公司内部及云上的训练平台广泛基于 K8s+Volcano 架构，并非“不能”而是“原生不够，插件补齐”。

误读 2：“调度只是找一台有足够资源的机器，越简单越好。”

事实：在现代异构集群中，“有足够资源”只是第一步。还需考虑跨机架通信带宽、GPU 连接拓扑（NVLink 域）、内存带宽 NUMA 就近访问、网卡亲和等约束。粗放的调度会导致 AllReduce 性能下降数十个百分点，扩大作业完成时间，无谓消耗昂贵的算力。调度已从“空间装箱”演进为“性能感知的优化决策”。

学习路径

• 入门：阅读 Kubernetes 官方文档《Scheduling, Preemption and Eviction》；实操用 Kind 或 Minikube 部署一个自定义调度器插件（使用 Scheduling Framework 的 Sample）。
• 加深：研究 Borg 经典论文《Large‑scale cluster management at Google with Borg》；阅读《Omega: flexible, scalable schedulers for large compute clusters》理解共享状态调度；分析 Volcano 源码中的 Session 和 Action 设计。
• 专题：学习 NVIDIA 的 GPU Operator 与 Topology Manager 集成；阅读 Run:ai 公开的技术博客，理解 GPU Dynamic Fractional Share；在实验环境中用 PyTorch DDP + MPI Operator 启动多节点训练，观察 Pod 放置与 NCCL 通信性能的关系。
• 社区：关注 KubeCon + CloudNativeCon 的调度相关演讲，CNCF 的 Scheduling 工作组，以及 Volcano、YuniKorn 的社区会议。

一句话总结

集群调度是分布式系统的“中央交通大脑”，从简单的装箱问题演进为深度耦合网络拓扑与通信模式的智能决策引擎，直接定义着千卡万卡 AI 集群的效率与成本底线。

延伸阅读与来源

（鉴于检索受阻，以下仅列出该领域公认的经典资源，供进一步参考，但不代表本应答直接引用其具体数据。）

1. Borg 论文：《Large‑scale cluster management at Google with Borg》，详细阐述大规模集群调度与资源管理的设计取舍。
2. Omega 论文：《Omega: flexible, scalable schedulers for large compute clusters》，比较单体、两阶段与共享状态调度器架构。
3. Kubernetes 调度框架：Kubernetes Scheduling 官方文档 及框架设计提案。
4. Volcano：Volcano 项目 与《Volcano: A Cloud Native Batch Scheduling System for AI, Big Data and HPC》论文。
5. YuniKorn：Apache YuniKorn 文档 阐述公平调度与多层次队列。
6. Slurm：Slurm 工作负载管理 及其拓扑插件文档。
7. NVIDIA 拓扑与调度：NVIDIA GPU Operator 与 K8s Topology Manager 集成白皮书。