SLURM数组作业为何未在同一节点并行运行？

核心原因：内存配额不足导致调度阻塞 #

你的SLURM集群使用select/cons_tres调度器，且参数为CR_CORE_MEMORY——这种配置下，SLURM会以CPU核心+对应内存配额作为资源分配的核心判断维度。

默认情况下，SLURM会用节点总内存除以总核心数得到mem-per-cpu的默认值，单个任务的内存需求会按核心数 × mem-per-cpu计算。你的节点总内存固定，当第一个任务占用了45 × mem-per-cpu的内存后，剩余内存可能不足以支撑第二个任务的同等内存需求，即使CPU核心（96-45=51≥45）和GPU（4-1=3≥1）还有剩余，SLURM也会因为内存维度不满足而阻塞第二个任务的调度。

你观察到“降低每核内存使用量时任务可并行”，正好验证了这一点：降低每核内存配额后，两个任务的总内存需求（45×2×新mem-per-cpu）落在节点总内存范围内，SLURM就允许并行调度。

为什么和GPU内存无关？ #

你的作业配置中没有指定GPU内存限制（SLURM默认不会强制GPU内存配额，除非集群额外配置了GRES_MEMORY参数），且CR_CORE_MEMORY的资源跟踪维度仅包含CPU核心和内存，GPU是独立的附加资源。因此问题根源不是GPU内存不匹配，完全是CPU核心对应的内存配额计算导致的。

解决方案 #

针对这个问题，有几种直接的解决方式：

• 指定任务总内存：用--mem <数值>参数明确单个任务的总内存需求（例如#SBATCH --mem 64G），代替依赖默认的mem-per-cpu计算。只要两个任务的总内存不超过节点总内存，SLURM就会允许并行调度。
• 降低每核内存配额：用--mem-per-cpu <数值>指定实际需要的每核内存（例如#SBATCH --mem-per-cpu 1024M），确保45×2×该数值不超过节点总内存。
• 验证节点内存配置：执行以下命令查看节点的内存相关参数：

  scontrol show node <你的节点名称>
  

  重点查看RealMemory（节点总内存）、MemPerCPU（默认每核内存）、AllocMem（已分配内存），确认内存配额的计算是否符合预期。

补充说明 #

虽然你的集群设置为“分配节点后用户独占”，但SLURM的资源调度逻辑依然会检查每个任务的资源请求是否能被节点剩余资源满足。select/cons_tres是基于资源消耗的调度器，不会因为节点独占就忽略资源维度的限制。

内容的提问来源于stack exchange，提问作者Josh.K