集群使用指南：登录、提交与排障

各章节保留原指南中的版本、平台、操作示例与适用边界；章节日期不同，使用时按所列版本核对。全部软件分项

1. 集群简介#

ch01 提供 Intel Xeon CPU 节点以及 NVIDIA P100、V100 GPU 节点，用于第一性原理计算、分子动力学、机器学习势训练和相关数据处理。

用户在 login01 整理输入、选择软件和提交作业，计算任务通过 Slurm 分配到计算节点。不要在登录节点直接运行生产模拟或模型训练。

GPU 是否更快取决于软件实现、体系规模、k 点数量、显存和并行配置。小体系或通信占比较高的任务，不一定随显卡数量增加而加速。

2. 节点配置与分区#

2.1 计算资源#

内存列为 Slurm 配置的可调度内存，单位 MB。

CPU 软件目录中的 8173m 对应 Xeon Platinum 8173M 节点。GPU 目录中的 p100、v100 分别对应两种 GPU 架构；多数已部署软件的 V100 16GB、32GB 共用程序，但提交分区和显存容量不同。

8173m 整节点规则（管理员确认）： cpu-8173m 为独占模式，无论使用多少核心均按整节点56核计费。因此公共提交模板和新建作业必须按每节点56核配置，不能以少申请CPU来节省费用。MPI采用56进程×1线程，混合并行可采用28×2或7×8，单进程OpenMP采用1×56；不能把56个MPI进程再各开56线程。启动命令必须读取对应Slurm资源变量。串行小工具在login01按已说明范围使用，不为它单独提交不足56核的8173m任务，也不启动56份相同程序写同一输出。线程/进程配置为56核并不代表程序每个阶段都能满载。

当前公共CPU模板：ORCA为56MPI×1CPU，但由串行驱动启动MPI，不在外层mpirun/srun；CP2K/QE/ABACUS为28×2；GROMACS MPI为7×8、thread-MPI为1进程分配56CPU；MACE/LOBSTER/xTB为1×56；VASP/LAMMPS/Wannier90/WannierTools/VASPBERRY/Hefei-NAMD DEV/TDEP/SPPARKS及ATAT MPI/VASP为56×1。ATAT mcsqs使用56个带独立编号的搜索进程协作搜索，sub_mcsqs_single.sh仅保留历史文件名兼容，现也使用56个搜索进程。DP-GEN的VASP阶段每节点56CPU。

改变混合并行划分时每节点进程数×每进程线程数仍应等于56。旧验收记录中曾出现较少核心的测试，它们仅是历史实测记录，不是当前提交建议。用户先前复制到个人目录的脚本不会自动更新，请重新通过yskit复制或按此规则调整。

2.2 用户类型与资源权限#

• hs_user：核时用户脚本目录，对应获授权的 hs 分区。
• tc_user：套餐用户脚本目录，对应获授权的 tc 分区。
• cpu-8173m 的实际可用权限仍以账户配置为准。
• GPU 申请必须写明型号，不能将 --gres=gpu:1 当作本集群通用写法。
• 保留 Slurm 设置的 CUDA_VISIBLE_DEVICES，不要在提交脚本中改为整机显卡编号。

收费标准、存储额度、账户并发限制和套餐有效期，由管理员按账户说明；本文件不预设统一价格或配额。

3. 登录、目录与任务提交#

3.1 常用目录#

在自己的项目目录保存输入、脚本和输出。公共软件环境由管理员维护；需要额外 Python 包时，先确认是否应建立个人环境。

3.2 使用 yskit 复制脚本#

在准备运行的算例目录执行：

yskit

选择 (1) 复制 Slurm 脚本，依次选择用户类型、软件、版本和节点。也可以直接运行：

yskit copy
yskit list

脚本复制到当前目录；已有同名文件时不会覆盖。yskit 不会自动提交任务。(2) 初始化软件 内选择 ATAT 或 Gaussian，(3) 估算VASP显存，(9) 查看使用说明，(0) 退出主菜单。DP-GEN 在 (1) 复制 Slurm 脚本 下选择用户类型，再从软件列表选择 DP-GEN；沿用已选用户类型。复制菜单逐层读取目录，进入前不遍历全部脚本。也可执行 yskit init 进入初始化菜单。

检查输入文件、分区、进程数、CPU 线程数和 GPU 数后，再提交复制得到的脚本。

公共模板已按VASP的简洁风格整理：主要保留资源申请、输入设置、环境加载和启动命令。DeePMD与配套LAMMPS的重复环境初始化、参数和资源检查集中在 /public/slurm_scripts/.runtime/2026-10-05/，脚本使用绝对路径自动加载；使用yskit只需复制提交脚本即可。通常修改脚本中的 #SBATCH、INPUT、BACKEND 或 MODE，不要删除或改动公共 source 行。原有 sbatch 脚本 参数… 用法保持不变，具体参数见各软件章节。已有个人脚本不会自动更新；需要新版时先保留个人修改，再在空目录用yskit重新复制。

3.3 常用 Slurm 命令#

sinfo                                      # 查看分区与节点状态
squeue -u "$USER"                           # 查看自己的作业
sbatch submit.sh                           # 提交任务，替换为实际脚本名
scontrol show job JOBID                     # 查看任务详情
sacct -j JOBID --format=JobID,State,ExitCode,Elapsed
scancel JOBID                              # 取消指定任务

JOBID 替换为实际作业编号。作业从 squeue 消失后，使用 sacct 和计算输出确认结果。

当前公共脚本以 %j.out 保存作业输出，标准错误合并到同一文件。不要仅凭 Slurm 显示 COMPLETED 判断电子迭代、MD 或模型训练已达到预期。

3.4 首次登录与文件传输#

管理员提供登录地址、SSH 端口和账号。login01 是集群内部名称，不一定能从个人电脑直接解析。下面的 LOGIN_HOST、PORT、USERNAME 必须替换成实际信息；命令在自己的电脑终端执行。

ssh -p PORT USERNAME@LOGIN_HOST

Windows 可使用支持 SSH/SFTP 的终端工具；Linux、macOS 可使用系统 SSH。首次连接先核对管理员给出的主机指纹；密码输入时终端不显示字符是正常行为。账号认证和外网入口信息不在公共指南中统一填写。

上传一个算例目录与下载结果的示例：

# 在个人电脑上执行；先将占位符替换为实际信息
scp -P PORT -r ./case01 USERNAME@LOGIN_HOST:~/
scp -P PORT USERNAME@LOGIN_HOST:~/case01/OUTCAR ./

SSH 的端口选项是小写 -p，SCP 是大写 -P。大量文件可使用 SFTP 客户端；传输前确认远端目录，避免覆盖已完成的算例。POTCAR、波函数等文件可能很大，尽量按后续计算需求保留和传输，不要在每次查看结果时复制整个目录。

3.5 算例目录如何组织#

每次独立计算使用独立目录。同一目录同时提交两个会写同名输出的任务，会互相覆盖文件。

project/
├── README.md             # 体系、目的、软件版本、参数与作业编号
├── inputs-original/      # 原始输入副本
├── relax/                # 结构优化
├── scf/                  # 静态自洽
├── analysis/             # 后处理
└── benchmark/            # 同一输入的不同并行配置

这只是用户目录的组织示例，不要求固定名称。推荐在每个算例目录保留实际提交的脚本、输入文件和 %j.out，并记录最终使用的程序版本与路径。续算前确认旧作业已结束，识别软件所需的检查点；不要把“重新提交脚本”当成所有软件通用的续算操作。

公共 /public/software 和 /public/toolkit 存放程序，不是用户计算输出目录。集群暂未在本指南承诺公共 scratch、自动备份和统一清理周期；重要结果需要用户自行保留副本。

3.6 从零提交一次作业#

以核时用户的 ABACUS 3.10.1 P100 单卡任务为例：

# 在已准备好输入的算例目录执行
pwd
ls -l INPUT STRU KPT
cp -i /public/slurm_scripts/hs_user/abacus/3.10.1/p100/sub_abacus_3.10.1_p100-16g.sh .
cat sub_abacus_3.10.1_p100-16g.sh
bash -n sub_abacus_3.10.1_p100-16g.sh
sbatch --test-only sub_abacus_3.10.1_p100-16g.sh
sbatch sub_abacus_3.10.1_p100-16g.sh

INPUT/STRU 中引用的赝势和轨道也必须存在。cp -i 在目标已存在时询问是否覆盖。bash -n 只检查 Shell 语法；sbatch --test-only 检查调度侧可接受性，两者都不会验证科学输入是否合理。

提交后记下返回的作业编号，例如 12345：

squeue -j 12345
scontrol show job 12345
# 输出文件出现后查看；Ctrl+C 只结束 tail，不取消作业
tail -f 12345.out
sacct -j 12345 --format=JobID,State,ExitCode,Elapsed,AllocCPUS

在实际使用时替换示例作业编号。需要取消任务时，先核对编号，再执行 scancel 12345。修改本地脚本不会改变已经提交的作业；不要让前一次任务仍运行时，在同一目录再提交修改版。

3.7 理解 Slurm 参数#

单节点时，CPU 需求通常按 ntasks × cpus-per-task 理解。例如 2 个 MPI 进程、每个 2 线程，合计申请 4 个 CPU；它与申请 4 张 GPU 没有直接关系。核数不能超过节点资源，还可能受到 GPU/CPU 配额关联限制。

#SBATCH 行由 Slurm 解析，不是普通 Shell 命令；不要在这些行里写 $HOME 等变量并期待 Shell 自动展开。环境变量设置、module 加载和程序启动放在指令区之后。

3.8 常见并行配置对照#

下表是现有模板的起点，不是所有体系的最优参数。

已有脚本里设置的 MPI 启动器和绑定参数属于软件运行配置，不应统一替换成另一套 mpirun 或 srun。需要多节点时，单独确认软件支持、通信路径和输入规模，不能仅把 --nodes=1 改成 2。

3.9 各软件如何从单卡改成多卡#

本节针对当前公共模板的单节点任务。先复制模板到自己的算例目录，再修改本地副本；下面的参数片段用于替换原有行，不是在脚本末尾重复追加一组SBATCH指令。核时与套餐用户采用相同的资源计算方法，但保留自己账户对应的分区、GPU型号、程序路径和运行环境。

先区分 GPU、进程和线程#

--gres申请GPU，--ntasks申请进程，--cpus-per-task申请每个进程的CPU资源。这三个参数不会自动联动。OMP_NUM_THREADS和程序选项决定申请到的CPU如何使用；它们本身不会额外申请CPU。

下文的G表示GPU数量，T表示每个计算rank的OpenMP线程数，只是说明用符号，不能直接写进SBATCH行。P100使用gpu:p100-16g:G；V100按分区使用gpu:v100-16g:G或gpu:v100-32g:G，实际替换为整数。例如：

#SBATCH --gres=gpu:p100-16g:2

保持--nodes=1。不要手工将CUDA_VISIBLE_DEVICES改成节点上的物理卡编号；由Slurm分配可见GPU。若脚本同时有--ntasks-per-node，需与单节点总进程数一致。以下配置是资源对应示例，并非所有体系的最优性能，也不表示每个版本都已验证四卡。

MPI 程序：GPU 数和进程数一起修改#

下表按每GPU一个MPI进程作为当前模板的起点，表中的CPU总数为ntasks × cpus-per-task。保留各模板原有的MPI启动器与绑定参数。

例如CP2K双卡，在原模板中修改为：

#SBATCH --nodes=1
#SBATCH --ntasks=2
#SBATCH --cpus-per-task=2
#SBATCH --gres=gpu:p100-16g:2

原模板已经用SLURM_NTASKS启动MPI、用SLURM_CPUS_PER_TASK设置OpenMP，因此运行命令无需再手改数字。此关系适用于表中已经采用这些变量的MPI模板，不适用于下一节的GROMACS thread-MPI。

**VASP：**当前OpenACC程序按每GPU一个MPI rank运行。不要沿用CPU版的NCORE分组；使用NCORE=1，清理不适合GPU路径的旧NPAR设置。KPAR不能仅凭卡数随意增大，要与MPI分组及实际k点相容；单k点任务先保留KPAR=1。VTST/NEB的IMAGES还会分组进程，需按任务单独配置，不能把普通单结构的双卡示例当作完整NEB配置。增加CPU线程时同时调整cpus-per-task，脚本会设置OMP线程。VASP GPU说明

**ABACUS：**PW按当前模板每GPU一个MPI rank，输入保持device gpu；在适用的PW k点并行任务中，双卡检查kpar 2、四卡检查kpar 4，同时核对实际k点数和程序日志。不要只增加kpar而不申请相应进程/GPU。LCAO的cusolver、elpa与PW不是同一种分解方式，不能将PW的kpar示例直接套给LCAO；当前LCAO用户先保留单卡配置，多卡需针对该3.10.1构建、求解器和输入单独验证。详见本地验收报告，不要用最新上游文档的新功能倒推已安装版本。

**LAMMPS：**先看具体脚本的启动命令，当前存在以下不同写法：

例如旧GPU包模板双卡改为-pk gpu 2，旧KOKKOS模板双卡改为-k on g 2；四卡分别改成4。不要给普通DeePMD势擅自增加-sf kk，也不要改变模板对deepmd、classic、deepmd-kk的区分。输入中若写了processors或partition，还需与新的进程布局匹配。上述一进程一卡是本集群模板约定，不表示LAMMPS所有构建都只允许这种布局。

**CP2K：**MPI进程数与GPU数一起改，cpus-per-task控制每rank的OpenMP线程。保留模板的MPICH -bind-to core:<线程数>和数学库单线程设置；不要改成OpenMPI的绑定参数。增加卡数不会自动让所有计算转移到GPU，Libint/libGint等输入选择仍按CP2K章节处理。

**FourPhonon：**当前GPU版只支持单卡无采样RTA，保持gres=1与ntasks=1；不能采用本节其他MPI软件的多卡配置。CPU线程可按个人输入调整，同时修改cpus-per-task，详见FourPhonon。

GROMACS thread-MPI：一个进程内部增加 rank#

普通threadmpi构建只启动一个操作系统进程，Slurm的--ntasks保持1。内部rank数由-ntmpi指定，--cpus-per-task则要覆盖整个进程中所有rank的OpenMP线程：

申请CPU总数 = 内部rank数 × 每rank线程数

当前2025.5、2026.3公共模板仍为单卡写法：-ntmpi 1，并将SLURM_CPUS_PER_TASK直接传给-ntomp。要按上表改成双卡，除了修改SBATCH资源，还必须替换原来的OMP设置与mdrun命令；只把CPU申请改成8，会得到每rank8线程，并不是目标的每rank4线程。

以下片段用于替换个人副本中的对应内容，保留原模板的环境加载以及INPUT、OUTPUT、GMX_BIN定义：

#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --gres=gpu:p100-16g:2

# 放在原模板环境加载之后、mdrun之前。
NTMPI=2
CPU_TOTAL=${SLURM_CPUS_PER_TASK:?}
if (( CPU_TOTAL < NTMPI || CPU_TOTAL % NTMPI != 0 )); then
    echo "CPU核数必须是内部rank数的正整数倍" >&2
    exit 2
fi
export OMP_NUM_THREADS=$((CPU_TOTAL / NTMPI))
"$GMX_BIN" mdrun -s "$INPUT" -deffnm "$OUTPUT" \
    -ntmpi "$NTMPI" -ntomp "$OMP_NUM_THREADS" \
    -pin auto -nb gpu -pme auto -update auto

四卡时把gres数量改4、cpus-per-task改16、NTMPI改4。不能把这里的NTMPI简单替换为SLURM_NTASKS，因为Slurm仍只分配一个进程。当前公共脚本也尚未改成自动读取GPU数；本节是个人脚本的明确修改方法。

mpi-plumed版使用上方MPI表，双卡为2进程×4线程，四卡为4进程×4线程；它的mpirun -np "$SLURM_NTASKS"和-ntomp "$OMP_NUM_THREADS"已经读取资源变量，不加-ntmpi。保留-plumed及-update cpu。两种构建均应检查md.log的PP/PME分配、GPU任务映射和实际吞吐，不能保证每增加一张卡就等比例加速。8卡×4线程需要32CPU，超过本集群V100节点24CPU配置，不能机械沿用。GROMACS并行说明

DeePMD-kit：现有单卡训练模板不能直接扩成多卡#

当前各版本公共训练脚本保留单节点、单task、单GPU。申请两张GPU不会自动把dp train变成分布式训练；也不能简单加mpirun -np 2，否则可能启动两个互相覆盖输出的训练任务。

单个模型的分布式训练需要按版本、TF/PT后端确认启动器及依赖，并专门准备和验证脚本；当前指南不把未交付的启动方式当作可用模板。DeePMD2.2.11仅TF，3.x的TF/PT训练不能混用启动配置。多个独立模型可以各用一个单卡作业、独立目录同时运行；这是任务并发，不是同一个模型的多卡训练。

DP-GEN：修改各阶段资源和启动器，不改主控GPU数#

DP-GEN主控不因多申请GPU而加速。实际资源配置位于个人工作流目录的machine.json，分别检查train、model_devi、fp条目；configure.py重新生成配置可能覆盖手工修改，修改后保留个人备份并检查实际生成的Slurm脚本。

当前安装的DPDispatcher1.1.0 Slurm后端将resources.cpu_per_node写成--ntasks-per-node，线程数另由custom_flags中的--cpus-per-task指定；所以不能把这里的cpu_per_node直接当作“进程×线程”的总核数。另外，kwargs.custom_gpu_line会覆盖由gpu_per_node生成的GPU行，两处应保持一致。

以已有的单节点、普通DeePMD势LAMMPS探索启动器为例，双卡资源片段为：

{
  "number_node": 1,
  "cpu_per_node": 2,
  "gpu_per_node": 2,
  "queue_name": "gpu-8v100-16g-hs",
  "group_size": 1,
  "para_deg": 1,
  "custom_flags": ["#SBATCH --cpus-per-task=2"],
  "kwargs": {"custom_gpu_line": "#SBATCH --gres=gpu:v100-16g:2"}
}

这是model_devi中resources对象的示例，四卡时将cpu_per_node、gpu_per_node及gres数量都改4；保持原machine、command、路径和其他配置。示例双卡申请2进程×2线程，共4CPU；运行器必须像现有run-lammps.sh一样读取SLURM_NTASKS。若换用固定GPU包/KOKKOS参数的启动器，还要按LAMMPS规则检查命令中的卡数。

train阶段当前run-dp.sh直接执行dp，仍按单GPU任务配置，不能照搬上述探索资源片段。fp若选GPU VASP，可按VASP规则联动资源并核对启动器；选择8173m CPU VASP时gpu_per_node保持0。group_size和para_deg涉及任务打包/并发，不等于GPU数，也不会自动实现分布式训练；先保持模板值，不让多个并发任务争用同一组GPU。

GPUMD、NEP、GNEP：单进程管理可见 GPU#

三个程序均不通过MPI启动，支持的任务可使用进程可见的多张GPU，Slurm的ntasks始终为1。当前模板以2个CPU线程作为起点，可先保持不变：

这类模板可以先只改GPU申请数，但前提是具体势与功能支持多卡。GPUMD标准NEP需满足前述盒子尺寸要求，不适用的势或DFT-D3组合不能靠增加gres解决。NEP训练数据会复制到各卡，显存不会自动合并；GNEP的global batch中要有足够构型，否则部分GPU没有工作。按同一batch比较性能，不要为追求加速悄悄改变训练语义。验证范围见GPUMD章节。

CPU 软件与辅助工具#

Phonopy2.43.6大计算同样为1进程×56CPU、OMP56/BLAS1，无RAYON；Phonopy4.7.2大计算为1进程×56CPU，Rust的RAYON_NUM_THREADS和C的OMP_NUM_THREADS随cpus-per-task设置56，内层BLAS1；无MPI/GPU构建。小准备/绘图可login01单线程。详见5.18节。

当前SPPARKS、ATAT、Wannier90独立程序、LOBSTER，以及各软件明确标为8173m CPU的构建，都不能通过增加gres变成GPU程序。CPU MPI程序调整进程数；LOBSTER等单进程线程程序调整cpus-per-task及OMP；ATAT普通程序与MPI工具分别按对应模板使用。VASPKIT、yskit、dpdata、tqdm等辅助工具也不因申请GPU而获得对应加速。PLUMED随宿主软件运行，本身不是一份通用GPU数扩展模板；gpu-burn是管理员压力测试工具，不用于套用以上生产作业配置。

新增phono3py、AMSET、CREST、ALAMODE、hiPhive、Multiwfn、OVITO和critic2均为本次CPU部署，不能增加gres自动变为GPU程序。ALAMODE anphon为56MPI×1线程，alm为1×56；AMSET为56工作进程且内层BLAS1，其余按各自56核线程模板。Bader串行，ASE/pymatgen小型预处理可login01使用。

修改后如何确认真的用了多卡#

提交后先查看作业分配的GPU数及进程/线程数，再查应用日志中的设备和任务映射。保留原始单卡输入，用相同模型、步数和收敛条件做短对照；检查能量、力等结果，再比较每步耗时、ns/day或训练吞吐。增加资源却没有提速时，先检查体系规模、分区方式、CPU供给和通信，不继续机械增加卡数。不要用不同物理输入的耗时来证明加速。

7. 常见问题#

如何选择 P100 或 V100？#

先确认账户允许的分区，再根据软件支持、显存和实际性能选择。需要超过单卡 16GB 显存的任务可评估 V100 32GB；多卡不自动等于显存可任意合并。

申请两张 GPU 是否只修改 gres？#

不一定。逐软件的修改位置、双卡/四卡参数及限制见3.9节。MPI模板通常同步改ntasks和gres；GROMACS thread-MPI要另改内部rank及线程分配；GPUMD保持一个task；DeePMD现有训练模板不能直接扩卡。

为什么仍需保留 VASP 的 HCOLL 设置？#

当前 GPU VASP 模板保留 OMPI_MCA_coll_hcoll_enable=0。已有测试表明升级 R580 小版本并没有消除旧通信栈的 HCOLL 初始化钩子报错。删除单独 err 文件只会改变输出位置，不能修复或消除错误。

单精度是否总是更划算？#

单精度可能降低耗时和显存，但需要检查科学结果。ABACUS 已提供运行时精度选择，默认仍为 double；能量接近也不代表力和应力已足够准确。

为什么不能只根据软件目录判断支持哪些功能？#

目录可能包含历史构建、实验程序或未完整验证的版本。优先使用公共提交模板及对应交付记录。比如旧式 vasp/vasp.6.4.2 路径不作为本指南正式 GPU VASP 的默认入口。

任务一直排队，怎么判断原因？#

squeue -u "$USER" -o '%.18i %.12P %.20j %.2t %.10M %.6D %R'
scontrol show job JOBID

排队时长受其他作业和调度策略影响。sinfo 显示节点有空闲资源，不代表当前账号或当前资源组合一定可以马上启动。

作业启动后立即结束，怎么查？#

按“调度状态 → 作业日志 → 应用输出 → 环境与输入”的顺序检查：

sacct -j JOBID --format=JobID,State,ExitCode,Elapsed,AllocCPUS
scontrol show job JOBID
tail -n 80 JOBID.out

ExitCode 通常显示为 退出码:信号。非零值有助于定位问题，但 0:0 不证明科学结果合格。例如 LOBSTER 在缺少输入时可能输出错误后返回 0。

GPU 报错是否都是驱动问题？#

不是。输入、显存、编译器生成代码、动态库混用、MPI 通信和硬件都可能导致 GPU 错误。先保存完整错误和作业环境，再判断所属层次。

HCOLL 初始化报错与 CUDA illegal address 不是同一种错误。现有 VASP 模板关闭 HCOLL 是针对已确认的通信组件问题，不能保证修复程序内部的非法内存访问。NO_STOP_MESSAGE=1 也不修复数值或内存错误。

不要通过删除日志、降低 UCX 日志级别或更换驱动来代替定位。普通用户发现疑似节点故障时，把作业编号、节点、时间和完整错误交给管理员；不要自行在整机显卡上运行压力测试。

怎样做一次有意义的性能对比？#

1. 固定软件版本、输入、初始状态与收敛条件，每种配置用独立目录。
2. 先验证单配置可以正确完成，再比较 CPU、单卡和多卡。
3. 同时记录总耗时与程序主要计算阶段耗时，避免启动开销主导结论。
4. 记录 MPI 数、线程数、GPU 数、节点和是否存在其他负载。
5. 对短任务重复测试，关注差异是否超过波动，并检查结果精度。

如果 4 卡比 2 卡只快很少，增加资源未必划算。对训练数据、结构优化或高精度能量差，还要把力、应力及收敛表现纳入判断，不能只比较总能量。

提问或报障时提供哪些信息？#

建议按下面格式提供，能减少反复确认：

软件及版本：
功能分支 / 后端：
任务目录：
提交脚本与提交命令：
Slurm 作业编号：
节点及 CPU / GPU 数：
首次出现问题的时间：
预期结果与实际现象：
完整错误所在日志及行附近内容：
同输入是否在其他版本或单卡成功：

保留实际提交的脚本与日志；不要只发最后一句 MPI_ABORT，前面的第一处错误通常更有价值。不要在公开渠道粘贴账号密码、密钥或受限制的完整势文件。