叢集排程

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 建置更智慧的拓撲感知和碎片整理排程，進入“決策最佳化”深水區。

技術路線對比

下表基於定性分析對比幾種代表性排程方案（均無檢索資料，基於公開文件與社群描述）：

特性	K8s 預設排程器	Volcano	Slurm (w/容器支援)	YARN Capacity/Fair Scheduler
排程粒度	Pod	PodGroup (Job 級)	作業（分配節點）	Container/Application Master
Gang Scheduling	無原生支援	內建（通過 PodGroup）	原生支援（節點分配模型）	無原生支援，需上層實現
拓撲感知	Topology Manager (有限)	支援 NUMA/task 拓撲	強大（SWITCH/拓撲外掛）	僅機架感知（Rack awareness）
多租戶/多佇列	僅優先順序類	多層次佇列+公平共享	分割槽（Partition）+ QoS	佇列層次/權重的公平排程
GPU/異構支援	Device Plugin+NodeSelector	增強 GPU 拓撲/sharing	通過 GRES 外掛，較基礎	通過 Node Label，粗粒度
排程架構可擴充套件性	高（外掛架構）	基於 K8s 排程外掛擴充套件	外掛式（SPANK）	通過資源管理器與排程器介面
典型使用場景	線上服務/通用容器	AI 訓練/大數據批處理	傳統 HPC、科研	大數據平台（Hadoop/Spark）

上下游

• 上游

  • 物理硬體層：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 整合白皮書。