Slurm
3 秒看懂
Slurm（Simple Linux Utility for Resource Management）是一款開源、高度可擴充套件的作業排程器與資源管理器，專為 Linux 叢集設計。它負責將大規模的 GPU/CPU 計算資源按需分配給成千上萬個並行任務，是 HPC 與 AI 訓練叢集的“作業系統級”排程中樞。
3 分鐘產業解釋
在 AI 大型模型競賽中，千卡乃至萬卡 GPU 叢集是核心生產工具。Slurm 解決的正是最稀缺問題的之一——如何讓昂貴的算力不閒置、不爭搶，且按正確的拓撲執行。它提供作業佇列、優先順序搶佔、節點獨佔、拓撲感知排程等機制，能將訓練任務的排隊延遲最小化，同時把 GPU 利用率維持在高位。與 Kubernetes 等容器排程器不同，Slurm 更貼近裸金屬高效能運算：它直接管理程序和資源 cgroup，原生支援 MPI 和高速互聯（InfiniBand/NVLink），通訊開銷更低，因此仍是大多數前沿 AI 實驗室和傳統超算中心排程 GPU 叢集的首選。目前，AWS ParallelCluster、Azure CycleCloud 等雲端 HPC 方案均提供原生 Slurm 整合，使其成為混合雲端 AI 基礎設施的事實標準之一。
15 分鐘專家深入
Slurm 的核心架構由一箇中央控制器守護程序（slurmctld）、每個計算節點上執行的守護程序（slurmd）以及可選的資料庫（slurmdbd，通常使用 MySQL/MariaDB）組成。控制器維護全叢集的資源和作業狀態，節點守護程序負責啟動、監控和清理任務，資料庫持久化儲存計費、作業歷史等資訊。
對於 AI 工作負載，Slurm 的關鍵能力體現在：
- GPU 管理：通過通用資源排程（Generic Resource Scheduling, GRES）機制，Slurm 能夠自動檢測每節點的 GPU 數量、型號甚至 MIG 例項，並以
--gpus=<數量>或--gres=gpu:<型別>:<數量>的方式分配。結合 NVIDIA NVML 庫，可定製 GPU 頻率、功耗限制等。 - 拓撲感知排程：現代 AI 叢集常採用多層次網路拓撲（例如同一機架內用 NVSwitch 全互聯，跨機架用 InfiniBand）。Slurm 的
topology.conf可定義葉子、交換器、機架等層級關係，使排程器將作業優先放置在通訊直徑最小的節點組內，大幅降低 AllReduce 等集體通訊的延遲。 - 異構作業與多工協同：PyTorch 分散式訓練通常通過
srun或sbatch提交。Slurm 會自動設定SLURM_PROCID、SLURM_NTASKS等環境變數（MASTER_ADDR通常需使用者指令碼根據SLURM_NODELIST等變數自行匯出，或由上層啟動器如torchrun配合環境生成），訓練指令碼可直接利用它們初始化torch.distributed，無需手動指定 IP 地址。此外，作業陣列（Job Array）可用於超引數搜尋，輕鬆啟動數百個獨立訓練任務。 - 容錯與回填：節點故障時，Slurm 能將作業自動重新排隊（需配合
--requeue選項）。回填（Backfill）排程允許小作業在保留大作業資源的前提下前移執行，進一步提高叢集利用效率。
在實際部署中，AI 叢集通常會將 Slurm 與 Pyxis/Enroot 外掛結合，實現容器化的訓練環境；或用 cgroups v2 嚴格隔離 CPU、記憶體和 GPU 的共享。整套體系使運維團隊能以極低的效能開銷，管理數千節點上的動態工作負載。
技術原理（最深）
Slurm 排程模型的核心是一個事件驅動的資源匹配引擎。每個節點被抽象為一組資源槽（如 CPU 核心、記憶體、GPU、高速網路介面），作業提交時宣告所需資源。控制器週期性地執行排程迴圈，從優先順序佇列中嘗試為作業分配資源。
關鍵機制與引數
- 多因子優先順序：優先順序由多因子加權計算，典型因子包括公平分享值（Fairshare）、作業等待時長、佇列質量（QOS）、作業大小和使用者指定的優先順序。管理員可通過
PriorityType=priority/multifactor配置權重，使得大作業在排隊一段時間後能自然獲得高優先順序，避免飢餓。 - 回填排程（Backfill）：維護一張未來資源預留的時間表。當高優先順序作業因節點不足而等待時，其所需資源的預期可用時刻被“鎖定”。此時，排程器遍歷佇列中排序較低的小作業，若某作業可在該預留時刻之前完成，則立即分配資源執行。這種演算法顯著提升了碎片化資源利用率，典型實施為 Slack backfill 或最早預留優先。
- 拓撲感知分配：基於
topology.conf建置的樹狀結構，排程器在分配節點時傾向於最小化所有分配節點之間的共同祖先層次（即最遠交換器距離）。例如，對於要求 8 節點的作業，排程器優先嚐試從同一葉子交換器內分配，次選同一機架，儘量避免跨機架分配，除非使用者通過--switches明確指定可接受的交換器數量。這種策略可將 AllReduce 的 hotspot 限於高層交換器，整體訓練吞吐量可改善 10%–30%（依網路拓撲而定，此為定性估算，具體收益因叢集設計而不同）。 - GPU 與網路耦合：Slurm 通過
gres.conf記錄各 GPU 的 PCIe 拓撲關係（例如哪些 GPU 共享同一 PCIe 交換器或與同一 InfiniBand HCA 緊鄰），並以此最佳化分配。例如，配合 NCCL 的 PXN（PCIe/NVLink）親和性，可使通訊效能最優。 - 作業流程示意（ASCII）：
┌────────────┐ ┌─────────────┐ ┌──────────┐
│ sbatch/ │────▶│ slurmctld │────▶│ slurmd │
│ srun │ │ 排程 + 記帳 │ │ 節點執行 │
└────────────┘ └─────┬───────┘ └─────┬────┘
│ │
│ 資源/狀態更新 │
▼ ▼
┌─────────────┐ ┌──────────┐
│ slurmdbd │ │ GPU/NIC │
│ (MySQL) │ │ 拓撲報告 │
└─────────────┘ └──────────┘控制器節點上的 slurmctld 與所有 slurmd 保持長連線，定期收集節點與作業狀態（節點狀態更新頻率由多項引數控制，如 SlurmdTimeout 用於判定節點失效，預設 300 秒，並非等同定時心跳）。
技術演進史
Slurm 最初於 2001 年左右由勞倫斯·利弗莫爾國家實驗室（LLNL）開發，目標是替代老舊的 PBS，成為 Linux 叢集簡潔、可靠的資源管理器。早期版本僅支援 CPU 和記憶體排程。
- 初步成型期（2000 年代後期）：加入多因子優先順序、公平分享、作業計費功能和回填排程，逐步成為 TeraGrid 等大型基礎設施的排程層。社群與商業公司 SchedMD 開始合作維護。
- GPU 與異構時代（2010 年代中期—2020 年代）：隨著 GPU 計算崛起，Slurm 引入 GRES 抽象，能識別並分配 GPU、FPGA 等硬體。同時支援 cgroups 隔離，實現記憶體/CPU 硬限制。NVML 外掛提供 GPU 健康監控與頻率調整。
- 雲端原生與容器化：近年，Pyxis/Enroot 等外部外掛使 Slurm 可直接提交容器化作業，映象由節點本地快取，減少拉取開銷。Slurm 的面向雲端場景的“彈性計算”（Elastic Computing）功能允許動態新增/刪除節點，助力混合雲端 AI 叢集。
- AI 大規模叢集適配：對萬卡級叢集的極限壓力進行最佳化，如改進控制器的內部鎖粒度、減少 RPC 延遲、支援異構 GPU 混合叢集排程等。與此同時，社群與 NVIDIA 等廠商合作，增強了 NVSwitch、CX-7 等最新硬體的拓撲感知能力。
目前 Slurm 版本已演進至二代數位版本（以年份命名），持續最佳化至 10 萬核以上叢集。
技術路線對比（量化表）
| 特性 | Slurm | PBS Professional | IBM Spectrum LSF | Kubernetes + Volcano |
|---|---|---|---|---|
| 排程規模 | 極高（數萬節點） | 高（數千至萬級） | 高（數千至萬級） | 中高（依賴排程器最佳化） |
| GPU 原生支援 | GRES，拓撲感知 | 通過 hooks 實現 | 通過 ELIM 及自定義資源 | Device Plugin + Gang 排程 |
| 裸金屬通訊 | 本地程序，MPI 一等公民 | 本地程序，MPI 支援 | 本地程序，MPI 支援 | 容器化，需額外 overhead |
| 容器支援 | 通過 Pyxis/Enroot 外掛 | 部分支援 | 支援容器化作業 | 核心原生 |
| 雲端整合 | 豐富（EC2/Compute Engine/Azure） | 部分雲端方案 | 通過 LSF Connector | 雲端原生，整合度最高 |
| 開源/商業 | GPL v2 開源，SchedMD 商業服務 | 商業授權 | 商業授權 | Apache 2.0 開源，廠商商業版 |
| 社群與生態 | 活躍，Top500/MLPerf 使用者多 | 傳統 HPC 市場專用 | 工業界 EDA/CAE 領域專用 | CNCF 社群爆發式增長 |
注：表中定性評價基於公開文件與產業典型認知，無具體實測資料，僅供對比參考。
上下游
上游：
- 作業系統 & 核心：Linux 發行版（RHEL/Rocky/Ubuntu），cgroups v2，systemd。
- 驅動與庫：NVIDIA 驅動 + CUDA、AMD ROCm、NCCL、NVML，負責暴露 GPU 硬體特性供 Slurm 排程。
- 容器執行時與外掛：Docker/Enroot/Podman 用於封裝訓練環境；Pyxis 外掛將
srun請求翻譯為容器啟動指令；cgroup-v2外掛做資源隔離。 - 網際網路絡：InfiniBand（Mellanox OFED）、NVSwitch、Slingshot 等高速互聯廠商提供拓撲發現工具和 MPI 庫。
下游：
- AI 訓練架構：PyTorch、TensorFlow、DeepSpeed、Megatron-LM 等分散式訓練程式碼通過
SLURM_*環境變數初始化通訊組。 - 科學計算應用：GROMACS、VASP、WRF 等傳統 HPC 應用。
- 叢集管理平台：如 Bright Cluster Manager、Warewulf、xCAT 負責無盤節點部署後移交 Slurm 排程。
- 雲端服務：AWS ParallelCluster、Azure CycleCloud、Google Cloud Cluster Toolkit 均提供一鍵部署 Slurm 叢集的模板。
關鍵指標
評價 Slurm 在生產 AI 叢集中的表現，通常關注以下維度（具體數值因叢集規模、硬體和配置而異）：
- 排程吞吐量：每秒可處理的作業提交數，高吞吐對引數掃描等大量小作業場景至關重要。控制節點硬體效能、資料庫和配置（如
MessageTimeout）有決定性影響。 - 最大管理規模：單一控制器穩定管理的最大節點數。大型部署常通過多叢集聯合或層次化配置突破單控制器瓶頸。
- 作業啟動延遲：從排程決策到所有程序就緒的耗時。包含
slurmd轉發、程序 fork、容器初始化等步驟，大規模 MPI 作業通常需要數秒到數十秒。 - 資源利用率：整體 GPU/CPU 的有效使用比例。優良的 backfill 策略和拓撲感知可使利用率提升 5–20 個百分點（[產業估算，未充分揭露]）。
- 故障恢復速度：主控制器切換時間、作業 requeue 後重新排程並啟動的時間。高可用配置通常可將切換控制在分鐘級。
供需與市場資料
由於 Slurm 為開源軟體，其市場規模難以直接衡量，但可通過其部署廣度側面反映：
- 超算領域：根據 Top500 列表歷史上多次統計，Slurm 被大量新上榜系統採用，是使用率最高的排程系統之一（定性結論，近幾年前三位中佔據顯著份額，[參考 Top500 歷年統計]）。
- AI 叢集：主流 AI 企業（如 NVIDIA 內部研發叢集、部分頭部雲端廠商的裸金屬 GPU 服務）公開資料顯示其排程層普遍採用或相容 Slurm。隨著規模化的生成式 AI 訓練擴張，對 Slurm 的熟練運維能力和商業支援需求正在增加。
- 供應商：核心維護公司 SchedMD 提供企業級支援、培訓和定製開發；HP Cray、Atos、Lenovo 等系統整合商在交付超算系統時預設整合 Slurm 並附帶服務，形成了穩定的下游服務市場。
代表公司與資本對映
- SchedMD：Slurm 的首席維護者和商業支援公司，掌控程式碼主線和發展方向，是核心受益實體。雖未上市，但其許可證與支援合同構成了直接商業回報。
- 主流雲端廠商（AWS、Azure、Google Cloud）：通過各自的 HPC 服務交付 Slurm 叢集，將其作為雲端上 AI 基礎設施的重要組成部分，間接擴大了對 Slurm 生態的鎖定。
- 硬體巨頭（NVIDIA、AMD、Intel）：其 GPU/加速器在 AI 叢集中的高效排程離不開 Slurm 的最佳化，因此通過開源社群貢獻、聯合最佳化文件等方式深度繫結。輝達的 DGX 系統及基座命令常直接與 Slurm 整合。
- AI 實驗室與初創：大量未上市的 AI 研究機構（如 Anthropic、Inflection 等[來源：公開報道]，以及國內頭部大型模型公司）自建 GPU 叢集，多數依賴 Slurm 開源版本或定製衍生版，構成了人才與服務需求池。
從資本視角看，雖然無法直接投資 Slurm，但投資於提供大規模叢集管理服務、自研排程器與 Slurm 聯用或高速互聯硬體的企業，間接受益於 AI 叢集排程需求的大盤增長。
投資邏輯
- 算力剛需 → 排程剛需：大型模型萬億引數時代的萬卡叢集成為標配，叢集利用率每提升 1%，等效於節省數百萬至千萬級硬體成本。高效的 Slurm 部署與調優服務是具有剛性支付意願的方向。
- 混合雲端與 AI 工廠：越來越多的企業採用雲端上 Slurm 叢集進行突發訓練，AWS ParallelCluster 等託管服務降低了使用門檻，驅動相關的雲端 SLURM 映象、諮詢和自動化運維工具的商業機會。
- 人才壁壘：精通 Slurm 架構、GPU 拓撲感知排程以及大規模並行檔案系統調優的 SRE 極度稀缺，相關培訓、認證和外包運維市場預期增長。
- 生態周邊增長：Enroot/Pyxis 容器加速、叢集監控（如 Prometheus Slurm 匯出器）、工作流引擎（如 Nextflow、Snakemake）與 Slurm 的整合等，構成可投資的細分軟體層。
常見誤讀糾偏
-
誤讀 1：“Slurm 過於古老，不適合 AI 雲端原生時代” 糾偏：Slurm 在處理大規模 MPI 作業和裸金屬 GPU 排程的低延遲、高粒度方面仍優於大多數容器排程器。許多最頂尖的千卡/萬卡 AI 訓練叢集（包括公有雲端 GPU 叢集）仍用 Slurm 作為底層排程器，Kubernetes 則部署於其上的管理層，或兩者並行。兩者不存在簡單的替代關係。
-
誤讀 2：“Slurm 無法管理 GPU 或動態資源” 糾偏：Slurm 的 GRES 機制原生支援 GPU 發現、分配和隔離，並可通過
gres.conf精確指定 MIG 分割槽、GPU 與 NIC 親和性。其拓撲排程能有效將訓練作業壓縮至最高頻寬域內，這一點恰是多數架構排程器所缺乏的。 -
誤讀 3：“Slurm 只能執行在物理機上” 糾偏：使用 Pyxis/Enroot 等外掛，Slurm 能夠無縫啟動容器化作業，且通過本地映象快取和掛載技術，避免每次拉取映象的開銷。結合
cgroups v2，可精細控制容器資源，兼顧效能與隔離性。
學習路徑
- 搭建實驗環境：使用 2 臺以上 Linux 機器（或虛擬機器）部署最小 Slurm 叢集，理解控制節點、計算節點、資料庫的角色。
- 閱讀官方文件：SchedMD 官方文件結構清晰，從快速入門到
slurm.conf引數詳解；推薦仔細閱讀“Topology Guide”和“GPU Management”章節。 - 實踐 AI 作業：提交 PyTorch DDP 訓練任務，驗證環境變數傳遞；嘗試使用
--gres=gpu:2分配，觀察 GPU 親和性；配置簡單的拓撲檔案，測試 AllReduce 效能差異。 - 深入原始碼與社群：Slurm 的 GitHub 倉庫活躍，可閱讀排程迴圈、backfill 實現原始碼，參與郵件列表瞭解實際問題設計思路。
- 進階探索：學習 Pyxis/Enroot 容器整合、HA 配置、會計與計費、QOS 高階策略，以及雲端上自動伸縮編排方案。
一句話總結
在千卡萬卡級 AI 叢集中，Slurm 就是那個默默把每一張 GPU 都用在該用的地方、讓價值數億美元的算力暢通無阻的排程中樞。
延伸閱讀與來源
- Slurm 官方網站與文件：https://slurm.schedmd.com
- SchedMD GitHub：https://github.com/SchedMD/slurm
- Pyxis+Enroot 容器支援：NVIDIA/enroot 及 NVIDIA/pyxis
- 公開叢集排程對比：HPCwire、insideHPC 等媒體對 Top500 排程器使用的分析文章（需求時自行檢索）
- 雲端廠商參考部署：AWS ParallelCluster、Azure CycleCloud Slurm 專案文件
- 本次撰寫未使用檢索結果，前述定性技術描述基於公開文件與行業共識，具體效能資料及版本細節請以官方手冊為最終依據。