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 万核以上集群。

技术路线对比（量化表）

注：表中定性评价基于公开文档与产业典型认知，无具体实测数据，仅供对比参考。

上下游

上游：

• 操作系统 & 内核：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. 算力刚需 → 调度刚需：大模型万亿参数时代的万卡集群成为标配，集群利用率每提升 1%，等效于节省数百万至千万级硬件成本。高效的 Slurm 部署与调优服务是具有刚性支付意愿的方向。
2. 混合云与 AI 工厂：越来越多的企业采用云上 Slurm 集群进行突发训练，AWS ParallelCluster 等托管服务降低了使用门槛，驱动相关的云 SLURM 镜像、咨询和自动化运维工具的商业机会。
3. 人才壁垒：精通 Slurm 架构、GPU 拓扑感知调度以及大规模并行文件系统调优的 SRE 极度稀缺，相关培训、认证和外包运维市场预期增长。
4. 生态周边增长：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，可精细控制容器资源，兼顾性能与隔离性。

学习路径

1. 搭建实验环境：使用 2 台以上 Linux 机器（或虚拟机）部署最小 Slurm 集群，理解控制节点、计算节点、数据库的角色。
2. 阅读官方文档：SchedMD 官方文档结构清晰，从快速入门到 slurm.conf 参数详解；推荐仔细阅读“Topology Guide”和“GPU Management”章节。
3. 实践 AI 作业：提交 PyTorch DDP 训练任务，验证环境变量传递；尝试使用 --gres=gpu:2 分配，观察 GPU 亲和性；配置简单的拓扑文件，测试 AllReduce 性能差异。
4. 深入源码与社区：Slurm 的 GitHub 仓库活跃，可阅读调度循环、backfill 实现源码，参与邮件列表了解实际问题设计思路。
5. 进阶探索：学习 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 项目文档
• 本次撰写未使用检索结果，前述定性技术描述基于公开文档与行业共识，具体性能数据及版本细节请以官方手册为最终依据。