Slurm：集群调度

为什么需要 Slurm：从手工分发任务到统一调度

在没有调度器的集群里，管理员的日常工作是在每个节点上手动执行训练脚本：先 ssh node1 "nohup python train.py &"，再逐台重复同样的操作；用户想知道哪些机器空闲，只能靠口头询问或 Excel 表格记录。这种方式有三个无法回避的问题：一是资源视图不透明，GPU 被谁占了、占多久完全不可知；二是多用户同时抢机器时没有排队机制，冲突只能靠人工协调；三是完全没有资源限额与记账，无法回答「这个项目一个月用了多少卡时」这类成本问题。

Slurm 把这些问题收敛为一个「资源池 + 队列」模型：所有计算节点统一注册进集群，节点按用途划分为分区（Partition）；用户通过 sbatch 把作业投递到分区排队，调度器依据优先级、公平共享与回填策略决定作业何时何地运行；slurmctld 负责全局决策，slurmd 在每个节点上执行任务。记账层 slurmdbd 把每次作业的资源使用量写入数据库，让「谁用的、用多少」有据可查。对 AI 训练场景，Slurm 还通过 GRES（通用资源）机制原生支持 GPU 的申请、隔离与绑定，使得「申请 2 张 A100、独占单卡、绑定 NUMA」这类需求可以直接写进作业脚本。

与 OpenPBS、LSF 等同类工具相比，Slurm 的插件化架构是其特征：调度算法、记账后端、任务启动方式、认证机制都以插件形式加载，同一套二进制可以适配从小型 GPU 工作站到 Top500 超算的不同规模。也正因如此，Slurm 的初始配置比 PBS 略繁琐，但换来的是一致的行为模型与大规模验证的稳定性。

安装与环境配置：完成 MUNGE 认证与单节点集群

安装 Slurm 前先理解两个基础概念：slurmctld 是集群的控制守护进程，负责作业调度与资源状态管理；slurmd 是计算节点的执行守护进程，负责在本机启动和监控任务；MUNGE 是 Slurm 默认的认证机制，为节点间通信提供一致性凭证。以下步骤在单台机器上搭建一个最小的四 CPU「伪集群」，跑通后再横向扩展到多节点。

第一步，安装依赖与 MUNGE，并让 MUNGE 在开机自启。第二步，从官方下载站拉取源码包，编译并安装 Slurm。第三步，创建运行时目录与最小配置文件 slurm.conf，其中 NodeName 必须与机器主机名一致。第四步，依次启动 slurmctld 与 slurmd，通过 sinfo 验证节点进入 idle 状态。

# 第一步：安装 MUNGE 与编译工具（以 RHEL/CentOS 系为例）sudo dnf install -y munge munge-libs munge-devel gcc make rpm-build openssl-develsudo systemctl enable --now munge # 第二步：编译安装 Slurm（以 24.11 为例）wget https://download.schedmd.com/slurm/slurm-24.11.0.tar.bz2tar xjf slurm-24.11.0.tar.bz2 && cd slurm-24.11.0./configure --prefix=/usr --sysconfdir=/etc/slurmmake -j$(nproc) && sudo make install # 第三步：准备目录并写入最小配置（NodeName 替换为当前主机名）sudo mkdir -p /etc/slurm /var/spool/slurmctld /var/spool/slurmdsudo chown -R $(whoami) /var/spool/slurmctld /var/spool/slurmdcat <<'EOF' | sudo tee /etc/slurm/slurm.confClusterName=localclusterSlurmctldHost=$(hostname)ProctrackType=proctrack/linuxprocReturnToService=2SlurmctldPidFile=/var/run/slurmctld.pidSlurmdPidFile=/var/run/slurmd.pidSlurmdSpoolDir=/var/spool/slurmdStateSaveLocation=/var/spool/slurmctldSwitchType=switch/noneTaskPlugin=task/noneSchedulerType=sched/backfillSelectType=select/cons_resSelectTypeParameters=CR_CoreNodeName=$(hostname) CPUs=4 State=UNKNOWNPartitionName=debug Nodes=$(hostname) Default=YES MaxTime=01:00:00 State=UPEOF # 第四步：启动并验证sudo slurmctld -c && sudo slurmd -csinfo

快速上手：30 分钟跑通第一个批处理作业

最小可行流程的思路：用 sbatch 提交一个打印主机名与任务序号的脚本，通过 squeue 观察作业从排队（PD）到运行（R）再到完成的过程，最后在输出文件里看到结果。sbatch 与后面要讲的 srun 的核心区别在于：sbatch 提交后立即返回、作业由调度器在后台找资源执行，适合训练、仿真这类耗时任务。

1. 在工作目录创建 hello.sh，文件内以 #SBATCH 开头的行是资源声明，写到 #!/bin/bash 之后：

2. 提交脚本：sbatch hello.sh，终端会打印 job id（例如 Submitted batch job 42）。

3. 立即执行 squeue 查看队列，此时作业状态为 R（运行中），ST 列下方还有 PD（排队）等状态码含义可在 man squeue 中查询。

4. 等待脚本结束，查看同目录下的 slurm-42.out，其中包含输出文本；用 sacct -j 42 查看该作业的 CPU 使用量与结束码（ExitCode 为 0:0 表示成功）。

进阶技巧：给 sbatch 增加 --gres=gpu:1 即可在配置了 GPU 的分区中申请单卡；需要调整脚本参数时不必改文件，sbatch --cpus-per-task=4 hello.sh 会覆盖脚本内的同名声明。批量运行不同超参数组合时，使用 --array=0-9 让同一个脚本并行跑 10 个副本，用环境变量 $SLURM_ARRAY_TASK_ID 区分任务序号。

   #!/bin/bash   #SBATCH --job-name=hello   #SBATCH --partition=debug   #SBATCH --nodes=1   #SBATCH --ntasks=1   #SBATCH --time=00:05:00   echo "Hello from $SLURMD_NODENAME"   sleep 30

核心能力详解：五大支柱

支柱一：分区与节点管理。节点按用途分组为分区（Partition），例如 debug 分区用于短时测试、gpu 分区挂载 GPU 节点、fat 分区挂载大内存节点。sinfo 展示分区与节点状态，scontrol show node 查看单节点详细资源（CPU、内存、GPU、空闲与分配情况）。分区支持 Priority、MaxTime、QOS 等约束，从入口控制作业的准入条件。

支柱二：作业调度与回填。Slurm 默认使用 sched/backfill 调度器：在保证高优先级作业按序运行的前提下，把低优先级的短作业「回填」进高优先级作业尚未占用的时间窗口，显著提升集群利用率。作业生命周期由状态机管理，从 PD（排队）到 R（运行）再到 CG（完成中）的每一次迁移都可通过 squeue -l 追溯。多因子优先级（priority/multifactor）综合 Age、Fairshare、QOS、Partition 等维度计算分数，兼顾公平与吞吐。

支柱三：作业依赖与阵列。--dependency=afterok:123 表示等待作业 123 成功后才启动，适用于数据生产、模型训练、结果评估的流水线编排；afterany、afternotok、singleton 分别覆盖其他失败/并发场景。作业阵列（--array=1-100%5）一次提交 100 个任务、并发不超过 5 个，是超参数搜索的标准姿势；任务间通过 $SLURM_ARRAY_TASK_ID 区分。

支柱四：GPU 与异构资源调度。GRES（Generic Resource）机制将 GPU 建模为可申请资源：--gres=gpu:2 申请 2 张卡，--gpus-per-node=a100:1 指定每节点 1 张 A100。配合 SelectTypeParameters=CR_Core 与 cgroup 插件，任务获得与申请一致的 CPU/GPU 隔离，避免「申请了 2 卡却跑 4 卡」的超卖问题。

支柱五：记账与配额。slurmdbd 配合 MySQL/MariaDB 记录每次作业的 submit time、run time、CPU 消耗与卡时；sacct 按作业、用户或项目维度查询历史用量，sshare 查看 Fairshare 配额与使用情况。多集群场景下通过 AccountingStorageHost 统一接入同一个数据库，实现跨集群的一体化成本核算。

生产部署与监控：从上线到运维

部署方式一：主备控制节点 HA。slurmctld 是整个集群的中枢，生产环境必须做高可用。在 slurm.conf 中配置 BackupController= 与 BackupAddr= 后，主节点宕机时备用节点自动接管；常见做法是主备节点各跑一个 slurmd，配合 keepalived 或 Pacemaker 管理虚拟 IP，实现秒级切换。数据库层 slurmdbd 同样需做主备或使用云 RDS，避免记账单点。

部署方式二：多节点扩容。新计算节点加入集群只需三步：安装相同版本的 Slurm 与 MUNGE；将主节点的 /etc/munge/munge.key 拷贝到新节点并重启 munge 服务；在 slurm.conf 的 NodeName 行追加新节点并执行 scontrol reconfigure。节点启动后自动向 slurmctld 注册，sinfo 显示 idle 即就绪。需注意所有节点的 Slurm 版本必须一致或保持兼容，否则注册会被拒绝。

可观测性。日常排障入口：sinfo -R 查看节点 DOWN/DRAIN 原因，squeue -l -u 用户名 查看用户作业详情，sacct -j 作业号 -l 查看完整记账记录，sstat -j 作业号 --format=MaxRSS,MaxVMSize 查看运行中作业的内存峰值。进监控系统层面，官方维护的 Prometheus exporter（SchedMD/slurm_exporter）周期抓取 sinfo、squeue、sacct 数据，可把队列深度、节点状态、GPU 利用率接入 Grafana 告警。

<p class=“para-label“>避坑清单：</p><ul class=”dash-list”><li>MUNGE 密钥不一致：所有节点必须共享完全相同的 /etc/munge/munge.key；密钥不匹配时 slurmd 反复向 slurmctld 注册失败，节点显示 DOWN。先验证 munge -n | munge -w 在两端输出一致再排查其他原因。</li><li>NodeName 与主机名不匹配：slurm.conf 中的 NodeName 必须与 hostname 输出一致，否则节点始终无法从 DRAIN 恢复，sinfo 报 NodeNotResponding。</li><li>slurmctld 无状态目录权限：StateSaveLocation 指向的目录若属主错误，主备切换或重启会丢失作业状态；保持该目录仅由运行 slurmctld 的用户可写。</li><li>--mem 是调度承诺而非强制限制：未启用 cgroup 插件时任务实际内存超限不会被杀掉，会拖垮同节点其他作业；生产环境务必配置 proctrack/cgroup 并开启 ConstrainRAMSpace。</li><li>手动 scancel 时把数组作业 ID 当普通作业：取消数组作业需 scancel 数组的 JobID，或加 --array 参数精确到某子任务；直接按子任务号逐个取消易遗漏。</li></ul>

版本迭代

Slurm 自 2002 年发布以来，从单一调度器演化为高度插件化的架构，SchedMD 约每半年发布一个功能版本，代号随日期命名（如 23.11 即 2023 年 11 月版），每年末的版本通常承担长期维护角色。下文列表覆盖 21.08 至 24.11 的功能版本线。（截至训练数据，SchedMD 可能已发布 25.05 等更新版本）

AI 应用场景

常见误区

面试题

参考来源

• webpageSchedMD 官网发行版公告、商业支持与案例信息