SLURM实战：sbatch资源申请与任务调度优化指南

1. 从零开始：理解sbatch脚本与资源申请的核心逻辑

如果你刚开始接触SLURM，看到一堆#SBATCH开头的参数可能会有点懵。别担心，我刚开始用的时候也这样。简单来说，sbatch脚本就是一个你写给SLURM调度系统的“任务说明书”。你在这份说明书里告诉系统：“我需要几台机器（节点）、每台机器上跑几个任务、每个任务需要多少CPU和内存，还有我需要什么样的GPU。” 系统收到你的说明书后，就会去资源池里找，找到合适的资源就帮你把任务跑起来。

这里最关键的是要理解几个核心参数的“父子关系”，我把它比作一个公司组织架构：

• --nodes=N：你需要几个办公室（物理节点）。
• --ntasks-per-node=M：每个办公室里安排几个项目组（任务进程）。
• --cpus-per-task=K：每个项目组里配几个工位（CPU核心）。
• --mem-per-cpu=X或--mem=Y：每个工位配多大的办公桌（内存），或者给整个办公室定一个总预算。

比如，你写--nodes=2 --ntasks-per-node=4 --cpus-per-task=8，就相当于你要了2个办公室，每个办公室里有4个项目组，每个项目组有8个工位。总共的“工位”数（逻辑CPU）就是 2 * 4 * 8 = 64个。如果你再写上--mem-per-cpu=4G，那就是给每个工位配了4GB的“桌子”，总内存就是64 * 4G = 256GB。

最容易踩的坑就是混淆--ntasks和--cpus-per-task。我见过不少新手把MPI进程数写进了--cpus-per-task，结果程序只在一个核上跑，慢得离谱。记住：--ntasks（或-n）指的是进程的数量，典型用于MPI这种多进程并行；而--cpus-per-task指的是每个进程能使用的CPU核心数，典型用于OpenMP这种多线程并行。一个管“有多少个独立工人”，一个管“每个工人有几只手”。

2. 实战进阶：CPU/GPU混合任务的参数配置详解

现在的高性能计算，纯CPU任务和纯GPU任务都太“单纯”了，真正吃资源的是那些CPU和GPU混合运算的任务，比如用PyTorch做深度学习训练，或者用CP2K做第一性原理计算。这时候资源申请就成了一门艺术，申请少了跑不动，申请多了浪费资源还排不上队。

2.1 纯CPU任务：OpenMP与MPI的配置区别

对于纯CPU任务，首先要判断你的程序是“多线程”还是“多进程”并行。这就像装修房子，多线程（OpenMP）是请一个装修队，队里有很多工人（线程）一起干一间房的活；多进程（MPI）是请好几个独立的装修队，同时装修不同的房间。

OpenMP多线程任务的配置相对直接。你通常只需要一个进程（--ntasks=1），但给这个进程分配多个CPU核心来运行线程。关键一步是在脚本里设置环境变量OMP_NUM_THREADS，告诉程序用多少线程。我习惯把它设为$SLURM_CPUS_PER_TASK，这样脚本里申请的核心数就能自动传递给程序。

#!/bin/bash #SBATCH --job-name=openmp_demo #SBATCH --nodes=1 #SBATCH --ntasks=1 #SBATCH --cpus-per-task=16 # 这个程序可以用16个线程并行 #SBATCH --mem=32G # 总内存32GB #SBATCH --time=01:00:00 #SBATCH --partition=cpu # 提交到CPU分区 # 关键：设置OpenMP线程数，与申请的核心数一致 export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK # 加载必要的环境，比如编译器 module load gcc/11.2.0 # 运行你的OpenMP程序 ./my_openmp_simulation

MPI多进程任务的配置则不同。你需要申请多个任务（进程），并且通常每个任务只绑定一个CPU核心。如果你的程序是“纯MPI”的，那么--cpus-per-task通常就是1（或者不设置，默认为1）。重点在于--ntasks和节点分布。

#!/bin/bash #SBATCH --job-name=mpi_demo #SBATCH --nodes=4 # 用4个节点 #SBATCH --ntasks=128 # 总共启动128个MPI进程 #SBATCH --ntasks-per-node=32 # 平均每个节点跑32个进程 #SBATCH --mem-per-cpu=2G # 每个进程分配2GB内存 #SBATCH --time=02:30:00 #SBATCH --partition=high_mem module load intel-mpi/2021.5 # 使用srun启动MPI程序，-n 参数一般由SLURM自动管理，也可显式指定 srun ./my_mpi_application

2.2 MPI+OpenMP混合并行：榨干节点性能

这是目前超算上最主流的模式，也叫“进程内多线程”。它结合了MPI的跨节点扩展能力和OpenMP的节点内共享内存优势，特别适合现代多核CPU架构。配置起来需要仔细计算。

假设你有一个节点，有2个CPU插槽，每个插槽有16个物理核心（开启超线程后是32个逻辑CPU）。你想运行一个混合并行程序，计划用4个MPI进程（每个进程绑定一个CPU插槽），每个MPI进程内部用16个OpenMP线程（用完一个插槽的所有物理核心）。

#!/bin/bash #SBATCH --job-name=hybrid_demo #SBATCH --nodes=2 #SBATCH --ntasks=8 # 总共8个MPI进程 #SBATCH --ntasks-per-node=4 # 每个节点4个MPI进程 #SBATCH --cpus-per-task=16 # 每个MPI进程分配16个CPU核心（用于OpenMP线程） #SBATCH --mem-per-cpu=2G #SBATCH --time=04:00:00 #SBATCH --partition=hybrid module load intel-mpi gcc export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK # 一些MPI库需要额外设置，以确保进程绑定正确 export I_MPI_PIN_DOMAIN=omp:compact mpirun ./my_hybrid_program

计算资源核对：每个节点用了 4 MPI进程 * 16 核心/进程 = 64 个逻辑CPU。如果节点是32核64线程，这就刚好把超线程也利用上了。--cpus-per-task申请的是逻辑CPU（线程），如果你只想用物理核心，可能需要额外参数如--hint=nomultithread或--threads-per-core=1（取决于集群配置）。

2.3 单GPU任务：让TensorFlow/PyTorch正确识别设备

GPU任务的核心是--gres=gpu:N参数，意思是申请“通用资源”（GRES）中的GPU，数量为N。对于大多数深度学习任务，一个GPU配多个CPU核心做数据预处理是常见操作。

#!/bin/bash #SBATCH --job-name=gpu_pytorch #SBATCH --nodes=1 #SBATCH --ntasks=1 #SBATCH --cpus-per-task=8 # 为数据加载、预处理等任务准备8个CPU核心 #SBATCH --mem=32G #SBATCH --gres=gpu:1 # 申请1块GPU #SBATCH --time=12:00:00 #SBATCH --partition=gpu module load cuda/11.8 cudnn/8.6 source activate my_pytorch_env # 如果你用Conda环境 # 对于PyTorch，通常能自动识别GPU。但显式设置一下更稳妥。 python train.py --gpu-id 0

关键检查点：提交作业后，建议在作业输出日志里用nvidia-smi命令验证一下GPU是否真的被分配且被你的进程使用。我曾经遇到过因为环境变量问题，PyTorch依然跑在CPU上的情况。

2.4 单节点多GPU：数据并行训练加速

当你需要在一块主板上使用多块GPU进行数据并行训练时（例如使用PyTorch的DataParallel或DistributedDataParallel），配置如下。注意，多GPU任务通常也需要更多的CPU核心和内存来支撑数据流。

#!/bin/bash #SBATCH --job-name=multi_gpu_train #SBATCH --nodes=1 # 关键：所有GPU必须在同一个节点内 #SBATCH --ntasks=1 #SBATCH --cpus-per-task=16 # 多GPU需要更多CPU资源做协调和数据搬运 #SBATCH --mem=64G #SBATCH --gres=gpu:4 # 申请4块同节点内的GPU #SBATCH --time=24:00:00 #SBATCH --partition=gpu module load cuda/11.8 source activate my_dl_env # PyTorch DataParallel 示例 python -m torch.distributed.launch --nproc_per_node=4 train_ddp.py

2.5 指定GPU型号与使用约束

高端集群往往有不同型号的GPU（如V100, A100, H100）。如果你的代码针对特定架构优化，或者需要特定显存容量，就需要指定型号。有两种主要方式：

1. 使用--gres详细指定：--gres=gpu:a100:2。这明确要求2块A100 GPU。这是最直接的方式。
2. 使用--constraint约束节点类型：--constraint=a100。这要求分配到的节点必须包含A100 GPU（可能节点里还有其他型号，但你只保证有A100可用）。

#!/bin/bash # 方式一：精确请求资源 #SBATCH --gres=gpu:a100:2 # 方式二：约束节点特征（具体语法取决于集群设置） #SBATCH --constraint="a100|v100" # 请求有A100或V100的节点 #SBATCH --gres=gpu:2 # 再申请2块GPU（可能是A100或V100）

重要提示：--constraint的用法高度依赖集群管理员的设置。有些集群用--features，有些用自定义的--constraint值。提交前最好用sinfo -o "%20N %10c %10m %20G %10p"命令查看节点拥有的GRES资源，或用scontrol show node <节点名>查看详细信息。

3. 调度优化策略：让你的作业更快开始运行

资源申请对了只是第一步，如何让作业在繁忙的集群中尽快被调度执行，才是老手和新手的真正分水岭。这里分享几个我踩过坑才总结出来的策略。

3.1 精准预估作业时间：--time参数的双刃剑

--time参数可能是影响调度优先级和成功率的最重要参数之一。SLURM调度器在背地里会进行“回填调度”，也就是如果一个大作业需要的资源暂时不够，但有一个很短的小作业可以插空先跑完，调度器就会先调度这个小作业。

• 策略：尽可能准确地预估并设置--time。如果你知道作业大概跑3小时，就设--time=3:00:00，而不是图省事设个--time=7-00:00:00（一周）。更准确的运行时间估计，能让你的作业有更多“插空”运行的机会，从而更快开始。
• 风险：如果作业运行时间超过了--time的限制，SLURM会强制终止作业。所以最好留出10%-20%的余量。
• 查看历史：用sacct -j <旧作业ID> --format=JobID,JobName,Elapsed,State可以查看自己过去类似作业的实际运行时间，作为参考。

3.2 理解分区与QOS：找到你的快车道

集群通常将节点划分为不同的partition，并为不同用户组设置不同的QOS。这就像机场的安检通道，有“头等舱通道”、“会员通道”和“普通通道”。

• --partition：根据作业类型选择。例如cpu、gpu、bigmem（大内存）、debug（调试，时间短，优先级可能高）。
• --qos：服务质量。通常有normal、high、low等。highqos的作业排队优先级更高，但可能消耗更多的“计费点”或受到更严格的总资源限制。
• --account：计费账户。如果你的账号关联多个项目，需要用这个参数指定从哪个项目扣费。

行动建议：提交作业前，运行sacctmgr show ass user=$USER format=account,partition,qos命令，查看你的账号在哪些分区、有哪些QOS可用。优先使用debug分区/QOS进行短时间测试，用normal运行正式作业。

3.3 数组作业：参数扫掠的利器

如果你需要运行大量相似的任务，只是输入参数不同（比如不同的随机数种子、不同的数据文件），那么数组作业是你的最佳选择。它只需要提交一个脚本，就能生成一系列子任务，极大地简化了管理。

#!/bin/bash #SBATCH --job-name=array_demo #SBATCH --ntasks=1 #SBATCH --cpus-per-task=4 #SBATCH --time=01:00:00 #SBATCH --array=0-49 # 创建50个子任务，索引从0到49 # 根据数组索引获取不同的输入文件或参数 INPUT_FILE="data_${SLURM_ARRAY_TASK_ID}.txt" PARAM_VALUE=$(( SLURM_ARRAY_TASK_ID * 10 )) python my_script.py --input $INPUT_FILE --param $PARAM_VALUE

环境变量：在数组作业脚本中，你可以使用$SLURM_ARRAY_TASK_ID来获取当前子任务的唯一索引，用$SLURM_ARRAY_JOB_ID获取数组作业的主ID。输出文件可以使用%A（主作业ID）和%a（数组索引）来区分，例如--output=result_%A_%a.out。

3.4 作业依赖：构建自动化工作流

复杂的科学计算往往分多个步骤，比如先预处理数据，再训练模型，最后分析结果。你可以使用--dependency参数来设置作业间的依赖关系，实现自动化流水线。

# 第一步：数据预处理 JOBID1=$(sbatch --parsable preprocess.slurm) # 第二步：训练模型，依赖第一步完成 # 依赖类型：afterok 表示前一个作业成功完成后才开始 JOBID2=$(sbatch --parsable --dependency=afterok:$JOBID1 train.slurm) # 第三步：分析结果，依赖第二步完成 sbatch --dependency=afterok:$JOBID2 analyze.slurm

常用的依赖类型：

• afterany：前一个作业结束后（无论成功失败）开始。
• afterok：前一个作业成功完成后开始。
• afternotok：前一个作业失败后开始。
• singleton：同一时间只允许一个具有相同名称的作业运行。

4. 高级调优与排错指南

当基础操作都掌握后，这些高级技巧能帮你进一步提升效率和解决疑难杂症。

4.1 超线程与CPU绑定的性能玄学

现代CPU都支持超线程（Hyper-Threading），一个物理核心表现为两个逻辑CPU。SLURM默认调度的是逻辑CPU。对于计算密集型任务，使用超线程有时能提升性能（更好地利用CPU流水线），有时反而会因资源争抢导致下降。

• 查看CPU信息：在计算节点上运行lscpu，查看Thread(s) per core。如果是2，说明开启了超线程。
• 禁用超线程效果：在sbatch脚本中加入--hint=nomultithread或--threads-per-core=1（如果集群支持），可以让SLURM按物理核心分配资源，并将任务绑定到物理核心上。
• 精细绑定：对于性能极其敏感的应用，可以使用--cpu-bind参数进行手动绑定。例如--cpu-bind=cores将任务绑定到物理核心，--cpu-bind=threads绑定到逻辑CPU。这通常需要结合numactl等工具进行深度优化。

4.2 内存申请策略：--memvs--mem-per-cpu

内存申请不足会导致作业被系统“OOM Killer”杀死，申请过多则浪费资源，影响其他作业调度。

• --mem-per-cpu：为每个申请的CPU核心分配固定内存。适合任务内存需求与核心数成正比的情况（很多科学计算程序属于此类）。例如--cpus-per-task=16 --mem-per-cpu=4G，总内存就是64GB。
• --mem：为整个节点或整个作业申请一个总内存量。适合任务有固定的、与核心数无关的基础内存开销。例如--nodes=1 --mem=120G，不管用多少核心，这个节点作业总共用120GB内存。
• 混合使用：在某些配置下，--mem和--mem-per-cpu是互斥的，具体需查阅集群文档。最稳妥的方法是先小规模测试，用sacct -j <作业ID> --format=JobID,MaxRSS,AveRSS查看作业实际的最大内存消耗（MaxRSS），在此基础上增加20%-30%的安全余量作为申请值。

4.3 利用scontrol进行作业实时管理

scontrol命令是管理已提交作业的瑞士军刀。

• 查看作业详情：scontrol show job <作业ID>。这里的信息比squeue详细得多，包括申请的资源、实际分配的节点、工作目录等。
• 挂起与释放作业：如果你临时想暂停一个排队中的作业（比如发现参数设错了，想修改后重提），可以用scontrol hold <作业ID>。修改后，用scontrol release <作业ID>释放它继续排队。
• 更新作业参数：部分作业参数可以在作业排队时修改，例如运行时间：scontrol update jobid=<作业ID> TimeLimit=2-00:00:00。这在你发现作业预估时间不足时非常有用。

4.4 监控与诊断：读懂调度器的“心思”

作业一直在排队（PD状态）？看NODELIST(REASON)字段。

• Resources：资源不足，等资源释放。
• Priority：有其他更高优先级的作业在排队。
• QOSGrpCpuLimit：你所属的QOS/账户的CPU使用总量达到上限。
• ReqNodeNotAvail：你要求的特定节点不可用（可能用了--nodelist）。

使用squeue --start可以预估你的作业可能开始运行的时间（如果调度器能计算的话）。这对于规划工作非常有帮助。

最后，养成查看输出日志的习惯。SLURM默认将标准输出和标准错误重定向到slurm-<作业ID>.out文件。作业一开始运行，就可以用tail -f slurm-<作业ID>.out实时跟踪进度和错误信息。很多初级错误，如模块未加载、文件路径错误、权限问题，都能在这里第一时间发现。