分子模拟异构算力适配开发教程（16）：传统 HPC 路线——Slurm GRES 与 Apptainer 容器化

分子模拟异构算力适配开发教程16传统 HPC 路线——Slurm GRES 与 Apptainer 容器化版本声明块工具/软件SlurmGRES 官方文档Apptainer原 Singularity2021-11-30 入 Linux Foundation 改名语言/环境HPC 集群、Linux本文目标读完你能写出正确的 gres.conf 与 sbatch 脚本用 Apptainer --nv 在共享集群上跑 GPU MD并判断 Slurm/K8s 两路线的适用边界一句话结论Slurm 用 GRESGeneric RESource调度 GPU——slurm.conf里GresTypesgpu 节点Gresgpu:型号:数量gres.conf里AutoDetectnvml自动检测另有 nvidia/rsmi/nrt/oneapi作业用sbatch --gresgpu:2申请且 Slurm 自动为 job step 设置CUDA_VISIBLE_DEVICES容器化 HPC 的标准答案是 Apptainer2021-11-30 从 Singularity 改名入 Linux FoundationSIF 单文件镜像--nv支持 GPU。〇、本篇要解决的认知问题GRES 的配置链路GresTypes/Gres/gres.conf怎么串起来–gres 的语法族有哪些Slurm 怎么让作业“只看得见自己的卡”CUDA_VISIBLE_DEVICES 注入Apptainer 与 Docker 的本质差异为什么 HPC 选它–nv 做了什么Slurm 与 K8s 两条调度路线分子模拟平台怎么选一、机制解析1.1 GRESSlurm 的通用资源抽象为什么这一节对你重要国内大量超算中心与高校集群是 Slurm 体系——你的 MD 平台第 20 篇想覆盖这些算力就必须懂 Slurm 的 GPU 语义而且 GRES 的设计任意通用资源与 K8s extended resource第 14 篇是同构问题在不同调度器上的两代答案对照着学效率最高。配置链路三层官方文档原文# ① 集群级声明有哪些资源类型slurm.conf GresTypesgpu,mps,bandwidth # ② 节点级每节点有多少slurm.conf NodeNametux[0-7] Gresgpu:tesla:2,gpu:kepler:2,mps:400,bandwidth:lustre:no_consume:4G# ③ 设备级gres.conf每 GPU 的设备文件与 CPU 亲和 AutoDetectnvml # 自动检测 NVIDIA另有 nvidia / rsmi(AMD) / nrt(NVIDIA NRT) / oneapi(Intel) # 或手动声明 Namegpu Typegp100 File/dev/nvidia0 Cores0,1要点GresTypes是集群级类型声明、Gres是节点级数量声明可带型号 Type 区分同节点异构卡、File/dev/nvidiaX把 GRES 绑定到具体设备文件Cores声明 CPU 亲和——GPU 直连的 NUMA 节点slurmd -C查看检测到的 GPU、slurmd -G校验 gres 配置no_consume标记不消耗型资源如带宽 license 计数。1.2 作业提交–gres 语法族与设备可见性作业参数族官方文档salloc/sbatch/srun 通用参数语义--gresgpu:2通用格式name[:type:count]--gpus/--gpus-per-node/--gpus-per-socket/--gpus-per-taskGPU 专用糖per-node 官方注明 “Equivalent to the --gres option for GPUs”--cpus-per-gpu/--mem-per-gpu每卡配套的 CPU/内存--gpu-bind/--gpu-freq绑定与频率控制关键机制Slurm 为每个 job step 自动设置CUDA_VISIBLE_DEVICES——这是 Slurm 版的“设备可见性隔离”对照第 14 篇 device plugin 的 Allocate 注入、第 4 篇的三层可见性调度器决定分哪几张卡运行时只见这几张应用在可见集合内编号gmx-gpu_id 0/ OpenMMDeviceIndex 0。TRES 记账维度还有gres/gpumem、gres/gpuutil。官方示例sbatch --gresgpu:4 -n4 -N1-1 gres_test.bashjob step 级再细分srun --gresgpu:2 ...。1.3 Apptainer为共享系统而生的容器改名史本系列实体规范表的条目2021 年开源 Singularity 项目加入 Linux Foundation 并更名ApptainerLF 官方新闻稿 2021-11-30同期 Sylabs 公司 fork 保留 Singularity 名发布 SingularityCE——所以今天看到 “Singularity” 要先分辨指哪个本系列指 Apptainer 时一律用新名。与 Docker 的本质差异README 定位面向共享系统与 HPC——SIFSingle Interchangeable File单文件镜像格式“Integration over isolation by default”默认集成优先于隔离容器内外同一用户身份、默认不提权无 root daemon——这正是 HPC 集群管理员拒绝 Docker 而接受它的原因无守护进程权限模型、镜像即文件可直接放家目录/Lustre。GPU 支持官方 user guide gpu 页--nv选项run/shell/exec——确保/dev/nvidiaX设备可用、从宿主机绑定基础 CUDA 库、设置容器内LD_LIBRARY_PATH卡的选择用APPTAINERENV_CUDA_VISIBLE_DEVICES容器环境变量前缀语法另有实验性--nvccli调 NVIDIA 的 nvidia-container-cli与 OCI CDI 支持。典型工作流官方示例apptainer pull docker://tensorflow/tensorflow:latest-gpu# 从 Docker 源拉镜像成 SIFapptainer run--nvtensorflow_latest-gpu.sifDocker 侧的对应物nvidia-container-toolkitgithub.com/NVIDIA/nvidia-container-toolkit含 libnvidia-container——K8s/Docker 路线 GPU 容器的底层件。1.4 Slurm vs K8s两条路线的取舍维度Slurm ApptainerK8s Volcano/HAMi第 14/15 篇血统HPCMPI 并行、独占节点、计时计费云原生服务化、弹性、声明式GPU 语义GRES 整卡 CUDA_VISIBLE_DEVICES 注入extended resource/vGPU 细粒度生态契合mpirun/gmx 原生、lustre 并行文件系统容器编排、多租户治理、自动扩缩典型场景超算中心、高校集群企业平台、混合负载推理模拟实践判断你的用户在哪平台就接哪——第 18 篇的适配层设计成对上两套调度都输出标准作业描述而不是逼算力中心换调度器。GROMACS 单节点多卡thread-MPI -gputasks在 Slurm 上极顺一个作业一个节点跨节点 MPI 大体系才需要 K8sVolcano 的 gang 或 Slurm 原生 MPI。二、完整代码与逐行剖析一个生产级的 Slurm MD 作业脚本GRES 申请 Apptainer 容器 基准三件套——把本篇机制全部落到一个可提交文件#!/bin/bash#SBATCH --job-namemd-benchmem # 作业名#SBATCH --partitiongpu # 分区队列#SBATCH --nodes1 # 单节点thread-MPI 的最优载体1.4 节判断#SBATCH --gresgpu:1 # GRES1 块 GPU语法 name[:type:count]#SBATCH --cpus-per-gpu8 # 每卡 8 CPU 核官方参数族#SBATCH --mem-per-gpu16G # 每卡 16G 内存#SBATCH --time02:00:00#SBATCH --outputmd-%j.log# ── 环境自检Slurm 注入的可见性1.2 节机制的直接观察────────────echo 调度器分配 echoCUDA_VISIBLE_DEVICES$CUDA_VISIBLE_DEVICES# Slurm 为 job step 设置的可见集合echoSLURM_JOB_GPUS${SLURM_JOB_GPUS:-未设}nvidia-smi-L||echo非 NVIDIA 环境换 rocm-smi/npu-smi# ── 容器执行Apptainer --nv1.3 节机制─────────────────────────# SIF 镜像事先 apptainer pull/build 好放在共享文件系统SIF/srv/images/gromacs-2026.1-musa.sifTPR/srv/md-data/benchMEM.tpr# --nv 的三件事官方语义设备可见 宿主 CUDA 库绑定 LD_LIBRARY_PATHapptainerexec--nv$SIFbash-c set -e gmx --version | grep -E GROMACS version|GPU|Precision # 落点全家桶第 3 篇 基准三件套第 12 篇 gmx mdrun -s $TPR-deffnmmd\-nbgpu-pmegpu-pmefftgpu-bondedgpu-updategpu-gpu_id0\-resethway-noconfout-pinon-ntmpi1-ntomp$SLURM_CPUS_PER_TASK # ── 结果回传解析 ns/day第 12 篇流水线的单文件版─────────────── NSDAY$(grep -A1 (ns/day) md.log | tail -1 | awk {print$2})echo 本作业 ns/day:${NSDAY}# sbatch --parsable 输出 job id结果归档到共享目录第 12 篇档案化思想echo$(date%FT%T),job${SLURM_JOB_ID},nsday${NSDAY}/srv/md-out/perf-ledger.csv逐段剖析自检段先于一切把 Slurm 注入的 CUDA_VISIBLE_DEVICES 打出来——它是“调度器分了哪张卡”的唯一现场证据排障卡不见了/编号变了从这一行开始而不是从 gmx 报错开始。--cpus-per-gpu8-ntomp $SLURM_CPUS_PER_TASK申请与使用对齐——申请 8 核却起 16 线程是 HPC 上的“超卖作弊”挤占同节点他人配额生产脚本要把这层纪律写死。容器内单引号包裹的命令串里嵌$TPR的引号交替——Bash 经典技法外单引号保容器内语义、内双引号展开宿主变量写错一层就是“容器内变量为空”的经典事故值得逐层注释。结果写 perf-ledger.csv单作业脚本也保持档案化铁律 6——csv 攒多了就是集群的性能历史第 19/20 篇直接拿来画瓶颈趋势。Apptainer 镜像准备流水线Docker 源 → SIF配合第 9 篇 SCS 思路# 从厂商容器制作 SIF一步转换SIF 是单文件直接放家目录/共享盘apptainer pull gromacs-musa.sif\docker://registry.mthreads.com/mcconline/scientific_computing_suite:1.1.0-musa5.2.0# 运行--nv 可见性变量APPTAINERENV_CUDA_VISIBLE_DEVICES0apptainer run--nvgromacs-musa.sif\bash-csource /opt/gromacs/2026.1/bin/GMXRC gmx --version三、常见报错与排查问题 1现象——sbatch --gresgpu:1提交后作业一直 PENDINGsqueue显示 Resources 原因。根因GRES 配置链路断了调度器不认为节点有 GPUGresTypes 没声明 gpuNodeName 的 Gres 缺失或数量为 0gres.conf 的设备文件路径错File 指向不存在的 /dev/nvidiaX。解法三层排查——scontrol show node 节点 | grep -i gres看调度器视角的 GRES 数量0 即链路断管理节点上slurmd -C检测/slurmd -G校验对照 1.1 节三个配置层逐层核对。问题 2现象——作业分到了卡但容器/应用里 CUDA_VISIBLE_DEVICES 为空或看到全部卡。根因CUDA_VISIBLE_DEVICES 注入发生在job step 级——直接在作业脚本头写./myapp是 step会注入但某些包装层批处理包装器、二次 ssh、部分容器入口会丢环境。解法用srun显式起 step保证注入语义容器场景用 APPTAINERENV_ 前缀显式传递本文脚本姿势自检段打印变量是发现丢失的第一手段。问题 3现象——apptainer exec --nv容器里 gmx 报 CUDA driver/library 版本不匹配。根因–nv 从宿主机绑定 CUDA 用户态库容器内带的是编译期工具链——宿主驱动太老低于镜像 CUDA 需求时版本对不上。这是“共享集群驱动统一”与“镜像自带新工具链”的固有张力。解法镜像按集群当前驱动版本构建镜像 CUDA ≤ 驱动支持上限确实需要新 CUDA 的负载走专属节点/分区诊断用容器内nvidia-smi–nv 绑定后可见宿主驱动版本对照镜像工具链版本。问题 4现象——同事按老教程装 “Singularity”结果装到了 Sylabs 的 SingularityCE两套命令行为有差异。根因2021 年项目分裂1.3 节改名史——Sylabs fork 继续用 Singularity 名SingularityCE原项目改名 Apptainer 进 Linux Foundation两者命令大部分兼容但版本线独立。解法HPC 场景认 Apptainer社区主线文档/脚本统一术语本系列实体规范表条目跨环境脚本同时检测command -v apptainer || command -v singularity做适配。四、动手练习练习 1基础在任何 Linux 环境无 Slurm 也行练习 Apptainerpull 一个官方测试镜像、apptainer exec sif cat /etc/os-release、再以--nv尝试无 GPU 环境观察报错信息也是收获。判定成功标准SIF 文件生成且能 exec 出 os-release 内容能说出 --nv 在无 GPU 环境下的行为绑定失败/警告信息镜像文件ls -lh确认 SIF 是单文件。练习 2进阶写出你所在集群或虚构规格1 节点 4×GPU、每卡 16 核的完整三层 GRES 配置slurm.conf 两行 gres.conf与一个申请 2 卡的 sbatch 脚本头。判定成功标准配置三层的语法全部正确对照 1.1 节官方示例sbatch 头含 --gresgpu:2、–cpus-per-gpu8、–mem-per-gpu16G脚本内有 CUDA_VISIBLE_DEVICES 自检行。练习 3思考题无标准答案某高校计算中心同时面对传统 MPI 大作业教授课题组、AI 推理服务校医院影像、以及你的 MD 平台。单一 Slurm 还是 SlurmK8s 双栈思考方向验证要点① 三类负载的调度语义差异独占计时 vs 常驻服务 vs 批吞吐② 双栈的运维成本与用户学习成本③ 第 18 篇适配层的“调度器适配器”设计如何让双栈对用户透明。五、小结与下一篇预告本篇补齐了调度版图的传统侧GRES 三层配置链GresTypes→Gres→gres.conf 的 AutoDetect/File/Cores把 GPU 变成 Slurm 可调度的通用资源–gres 参数族申请、CUDA_VISIBLE_DEVICES 在 job step 级注入Slurm 版可见性隔离Apptainer2021 从 Singularity 改名SIF 单文件、Integration over isolation、–nv 三件事是 HPC 容器化的标准答案Slurm/K8s 双路线按用户生态选择、适配层对两者同构输出。作业脚本把自检、申请-使用对齐、结果档案化三条纪律固化进模板。高级篇13-16至此收官源码级调优、算力池化、批调度、传统 HPC——四篇构成“从单卡跑对到集群管好”的完整技能面。最后四篇17-20进入实战收官先把推理调度的思想continuous batching/PagedAttention迁移成 MD 批调度器再做统一多引擎适配层、故障诊断与性能工程最后把 19 篇的积累组装成完整的异构算力 MD 平台。本篇认知问题回显FAQQ1Slurm 怎么配置和申请 GPUA三层配置slurm.conf 里集群级GresTypesgpu 节点级NodeNamexxx Gresgpu:型号:数量gres.conf 里AutoDetectnvml自动检测 NVIDIA另有 nvidia/rsmi/nrt/oneapi或手动Namegpu Typegp100 File/dev/nvidia0 Cores0,1作业用sbatch --gresgpu:2通用格式 name[:type:count]或--gpus-per-node等专用参数申请配套--cpus-per-gpu/--mem-per-gpu。Q2Slurm 怎么实现 GPU 隔离作业只见自己的卡ASlurm 为每个 job step 自动设置 CUDA_VISIBLE_DEVICES 环境变量——调度器分配的 GPU 集合决定该变量的值应用gmx -gpu_id / OpenMM DeviceIndex在可见集合内编号用 srun 起的 step 保证注入语义某些包装层会丢环境变量需显式传递。Q3Apptainer 和 Singularity、Docker 是什么关系为什么 HPC 用 ApptainerAApptainer 是 2021-11-30 原 Singularity 项目加入 Linux Foundation 后的新名字Sylabs fork 保留 Singularity 名发布 SingularityCEHPC 选它因为SIF 单文件镜像可直接放共享文件系统、默认不提权Integration over isolation容器内外同一用户身份、无 root daemon——符合共享集群的安全模型GPU 用 --nv设备可见宿主 CUDA 库绑定LD_LIBRARY_PATH。Q4分子模拟平台该选 Slurm 还是 KubernetesA按用户生态选超算中心/高校集群MPI 并行、独占节点、计时计费是 SlurmApptainer 的主场GROMACS 单节点多卡thread-MPI±gputasks在 Slurm 上最顺企业平台/混合负载推理模拟、多租户、弹性适合 K8sVolcano/HAMi细粒度 vGPU 与 gang 调度第 18 篇的适配层设计为对两套调度器都输出标准作业描述用户无感。