尧图网站建设 
分子模拟异构算力适配开发教程3mdrun 异构执行控制——-gputasks 位图语义与 GPU-resident 的硬前提版本声明块工具/软件GROMACS 2026.x行为演进史对照 2020–2025 各版本语言/环境Linux、MPI/thread-MPI本文目标读完你能精确控制一个 mdrun 作业里每类计算落在哪个设备上并能判断自己的体系能否进 GPU-resident 模式一句话结论gmx mdrun用六个auto/cpu/gpu枚举参数-nb、-nbfe、-pme、-pmefft、-bonded、-update控制任务落点用-gputasks如0011按位映射 PP/PME 任务到 GPUGPU-resident 模式-update gpu的硬前提是constraintsh-bonds且 dt≤2.5 fs且 2023 起-update auto已默认映射 GPU。〇、本篇要解决的认知问题mdrun 的六个任务落点参数-nb/-nbfe/-pme/-pmefft/-bonded/-update各管什么auto 的决策逻辑是什么-gpu_id 和 -gputasks 都带 “gpu” 字样为什么需要两个参数2018 年前后它们发生了什么分工变化什么是 GPU-resident 模式为什么它要求 constraintsh-bonds开了它有哪些代价多 GPU 多 rank 时rank 数和 GPU 数的配比有什么经验规律一、机制解析1.1 任务落点六个枚举参数的语义为什么这一节对你重要国产卡适配做完之后性能调优的第一现场就是这组参数——同样一块卡任务落点配置不同ns/day 可以差出一倍以上。而且这组参数是跨后端通用的接口CUDA/SYCL/HIP/MUSA 都认是适配验收时的标准控制面。一个 mdrun 步骤里的计算任务被切成六类每类可以独立指定落点值域都是auto/cpu/gpu参数管辖任务说明-nb非键相互作用NBNxM 内核最大的算力消耗项GPU 化收益最直接-nbfe非键自由能部分自由能计算FEP/RE体系的非键 FE 项-pmePME 静电网格部分长程静电的 SPME 求解-pmefftPME 的 FFT 部分可与 -pme 分开指定FFT 有独立的库路径-bonded键合相互作用键/角/二面角2021 起可 offload-update积分更新与约束GPU-resident 模式的开关见 1.3auto默认的语义让 mdrun 根据硬件拓扑与体系规模自动决策。自动决策通常已经不错但国产卡适配时必须显式指定——因为 auto 的决策依据是官方后端的经验模型厂商后端的行为可能有偏差摩尔线程官方文档的示例就是全部显式指定见第 9 篇。任务之间存在依赖-pmefft gpu依赖-pme gpuFFT 是 PME 的子步骤GPU-resident 模式要求所有力计算都在 GPU 上否则每步都要跨 PCIe 搬坐标。这类依赖是排错的线索——指定了组合法但物理上不成立的落点mdrun 会在启动时报错或回退。1.2 -gpu_id 与 -gputasks一对参数的分工演变这两个参数都用于指定 GPU初学者极易混淆。官方在线帮助的原文定义-gpu_id“List of unique GPU device IDs available to use”——本节点可用的 GPU 设备 ID 列表。-gputasks“List of GPU device IDs, mapping each task on a node to a device. Tasks include PP and PME (if present)”——任务→设备的映射每位字符按序对应一个任务PP 任务和 PME 任务。历史包袱2018 之前-gpu_id同时决定哪些卡可用和任务怎么分。之后任务分配职责移交-gputasks-gpu_id回归纯可用性声明GROMACS 2025.2 用户指南明确记录了这个分工。今天的实践单卡作业用-gpu_id 0多任务映射用-gputasks。-gputasks的位图语义举例-gputasks 0011表示这个节点上有 4 个任务如 3 个 PP 1 个 PME前两个任务给 0 号卡后两个给 1 号卡。再如-gputasks 22表示两个任务都给 2 号卡2 号卡可以被多任务共享官方允许但需自担性能风险。1.3 GPU-resident 模式把整步计算钉在 GPU 上-update gpu开启 GPU-resident 模式积分更新与约束也搬到 GPU整步计算力积分不再需要把坐标搬回 CPU消除每步的 PCIe 往返。演进史版本变化2020引入仅 CUDA默认仍在 CPU2021扩展到 FEP除质量扰动与约束 FEP允许 DD/独立 PME rank2021.2修复竞态禁止扰动质量的 SETTLE2023-update auto默认映射到 GPU2026.2现行行为auto 即 GPU条件满足时硬前提官方手册原文dt≤2.5 fs 时用constraintsh-bonds——“it is necessary in order to be able to use GPU-resident mode”。原因GPU 上的约束求解器实现要求约束模式统一为 h-bonds全键约束 LINCS 的 GPU 路径受限。配套建议增大nstcalcenergy能量计算频率、温度/压力耦合间隔 ≥50–100 步——因为这两类操作仍需要 CPU 参与频率越低GPU-resident 的收益越完整。代价面GPU-resident 模式下部分功能不可用完整的不支持功能清单位于 mdrun-performance 页 “Running mdrun with GPUs” 一节以该节为准CUDA Graphs 只在 GPU-resident 步骤下有意义第 13 篇排查性能问题时 GPU 计时行为也有差异GMX_DISABLE_GPU_TIMING/GMX_ENABLE_GPU_TIMING环境变量控制。1.4 rank/GPU 配比一条反直觉的经验官方性能页的结论“多 GPU 运行每 GPU 用 1-3 个 rank 最优GPU-resident direct GPU 通信时通常1 rank/GPU 最佳”。反直觉之处新手常以为 rank 越多越好把 CPU 核心铺满实际上过多的 rank 会让每块卡被多个 MPI 进程争抢域分解的通信开销也随 rank 数上升。避免 rank 数 物理核心数——那是 CPU-only 时代的老经验。PME 侧的不平衡则用-npmePME rank 数调节或上gmx tune_pme自动扫描第 19 篇性能工程再展开。二、完整代码与逐行剖析一个任务落点矩阵探测器——跑一组短作业系统测量不同落点组合的 ns/day为国产卡适配建立第一手性能档案#!/usr/bin/env python3任务落点矩阵探测对同一 tpr 跑多种落点组合输出 ns/day 对比。 用途国产卡适配验收的第一手性能档案铁律 6性能结论必须带上下文。 importreimportsubprocessimportsysfrompathlibimportPath# 待测落点组合。从保守到激进排序任何一步失败即停后面的组合大概率也失败。# 每个元素: (标签, 附加 mdrun 参数列表)LAYOUTS[(cpu-baseline,[-nb,cpu]),# CPU 基线一切 GPU 加速的分母(nb-only,[-nb,gpu]),# 仅非键上卡最保守的 GPU 化(nb-pme,[-nb,gpu,-pme,gpu]),# 常见生产配置(full-offload,[-nb,gpu,-pme,gpu,-pmefft,gpu,-bonded,gpu]),# 除 update 外全部上卡(gpu-resident,[-nb,gpu,-pme,gpu,-pmefft,gpu,-bonded,gpu,-update,gpu]),# GPU-resident需 constraintsh-bonds]defparse_ns_per_day(mdlog:Path)-float:从 md.log 尾部解析 Performance 行的第一列ns/day。 格式官方日志 (ns/day) (hour/ns) Performance: 144.741 0.166 textmdlog.read_text(errorsreplace)# 只匹配 Performance: 行md.log 里该行只出现一次在最后的统计段mre.search(r^Performance:\s([0-9.])\s[0-9.]\s*$,text,re.M)ifnotm:raiseValueError(f{mdlog}中未找到 Performance 行作业可能异常退出)returnfloat(m.group(1))defrun_layout(tpr:Path,label:str,extra:list[str],outdir:Path,nsteps:int5000)-float:跑一种落点组合返回 ns/day。用 -nsteps 截短作业探测不需要跑完。workoutdir/label work.mkdir(parentsTrue,exist_okTrue)cmd[gmx,mdrun,-s,str(tpr),-deffnm,str(work/md),# 所有输出文件前缀-nsteps,str(nsteps),# 截短只跑探测步数-noconfout,# 不要 confout.gro探测不需要结构输出-pin,on,# 线程绑定官方示例标配-gpu_id,0,# 单卡作业声明可用卡铁律探测期固定变量*extra,]rsubprocess.run(cmd,capture_outputTrue,textTrue,timeout3600)ifr.returncode!0:print(f[{label}] 失败:{r.stderr.strip().splitlines()[-1]ifr.stderrelseunknown})return0.0returnparse_ns_per_day(work/md.log)defmain()-None:tprPath(sys.argv[1])iflen(sys.argv)1elsePath(benchMEM.tpr)ifnottpr.exists():sys.exit(f找不到{tpr}第一参数应为 .tpr 文件路径)outdirPath(layout-probe);outdir.mkdir(exist_okTrue)print(f{组合:14}{ns/day:10}{vs-CPU:9})cpuNoneforlabel,extrainLAYOUTS:try:perfrun_layout(tpr,label,extra,outdir)exceptsubprocess.TimeoutExpired:perf0.0iflabelcpu-baseline:cpuperfor1.0ratiof{perf/cpu:.2f}xifperfelse-print(f{label:14}{perf:10.2f}{ratio:9})if__name____main__:main()逐段剖析LAYOUTS 的顺序是失败熔断设计从 CPU 基线到 GPU-resident 逐级加码。如果 “nb-only” 就失败说明 GPU 后端本身有问题构建或驱动继续测更激进的组合没有意义。这个顺序也是排错顺序。parse_ns_per_day用多行正则锚定Performance:行——注意它匹配的是第一列 ns/daymd.log 尾部还有 ms/step、Matom*steps/s 等指标后两者需GMX_DETAILED_PERF_STATS才打印第 12 篇的基准流水线会全量解析。-nsteps 5000截短作业是探测脚本的关键取舍5000 步对 2 fs 步长的体系是 10 ps足够让 PME 网格、邻区列表都进入稳态又不用等太久。但要记住短作业的 ns/day 偏乐观没有长期热效应正式基准按第 12 篇的规范跑。输出的 “vs-CPU” 列就是这份硬件的 GPU 化收益档案——第 19 篇的性能诊断决策树会直接消费这张表。GPU-resident 的完整生产命令对照参考摩尔线程官方文档同款语法gmx mdrun-smd.tpr-deffnmmd-pinon\-nbgpu-bondedgpu-pmegpu-pmefftgpu-updategpu-gpu_id0多卡任务映射示例# 2 块卡、4 个任务3 PP 1 PMEPP0/PP1/PME 给 0 号卡PP2 给 1 号卡gmx mdrun-ntmpi4-gputasks0011-nbgpu-pmegpu...三、常见报错与排查问题 1现象——-update gpu启动报错提示约束类型不支持或自动回退 CPU。根因GPU-resident 的硬前提没满足——最常见的是 .mdp 里用了constraintsall-bonds全键约束或没设 constraints而 GPU 路径要求constraintsh-bonds配合 dt≤2.5 fs。另一个可能是体系用了 GPU 约束求解器不支持的特性如扰动质量的 SETTLE2021.2 起明确禁止。解法改 mdpconstraintsh-bonds重新 grompp确认 dt≤2.5 fs要更大步长走mass-repartition-factor氢质量重分配路线第 13 篇。完整不支持功能清单以 mdrun-performance 页 “Running mdrun with GPUs” 节为准。问题 2现象——-gputasks 0011报错 “invalid gputasks input” 或任务数对不上。根因位图长度必须等于节点上的任务数PP 任务数 PME rank 数。你给的字符串位数与-ntmpi/-npme推出的任务数不一致或者混淆了-gpu_id可用卡列表与-gputasks任务映射——在-gputasks里写了重复验证不了的大数字如设备不存在。解法先算清任务数任务数 PP rank 数 PME rank 数有独立 PME rank 时。比如-ntmpi 4 -npme 1是 3 PP 1 PME 4 个任务-gputasks必须恰好 4 位每位是对应设备的合法 ID。问题 3现象——加了-update gpu之后 ns/day 反而降了。根因GPU-resident 的收益前提是所有力计算都在 GPU。如果-bonded或-pme还留在 CPU每步坐标仍要在 CPU↔GPU 间往返-update gpu反而增加了一次额外的设备同步。另一个常见原因nstcalcenergy或耦合频率太高默认值是按 CPU 模式设计的GPU-resident 下应增大nstcalcenergy、耦合间隔 ≥50–100 步。解法用本文的落点矩阵探测器跑 “full-offload” 与 “gpu-resident” 两档对比确认 mdp 里nstcalcenergy已增大官方建议值见 mdrun-performance 页。问题 4现象——-gpu_id 0,1想用两块卡但日志显示只用了一块。根因-gpu_id只是可用卡声明任务分配另需 rank 层面的拆分-ntmpi或外部 mpirun与映射-gputasks。声明两块卡但只有 1 个 rank自然只有一块卡干活。这是 2018 前老语义gpu_id 兼管分配的遗留误解。解法-ntmpi 2 -gpu_id 0,1每 rank 一卡auto 映射或显式-gputasks 01。四、动手练习练习 1基础取一个已平衡的体系 tpr如 benchMEM获取方式见第 12 篇跑本文落点矩阵探测器记录五种组合的 ns/day 与 vs-CPU 比值。判定成功标准产出五行表格cpu-baseline 的 ns/day 0full-offload 对 cpu-baseline 的加速比 ≥3xGPU 工作正常的健康信号达不到先查构建与驱动再怀疑硬件。练习 2进阶扩展探测器给 LAYOUTS 增加(nb-pme-npme, [-nb,gpu,-pme,gpu,-npme,1])与-ntmpi 2的多 rank 变体对比单 rank 与 2 rank1 rank/GPU vs 2 rank/GPU在双卡机器上的差异。判定成功标准新增两行数据能回答这块硬件上 1 rank/GPU 与 2 rank/GPU 谁更快并给出数值证据官方经验规律是 GPU-resident直连通信下 1 rank/GPU 最佳验证你的硬件是否吻合。练习 3思考题无标准答案为什么-update auto在 2023 版之后默认映射 GPU而不是更早思考方向验证要点① 2021 的 FEP 扩展与 2021.2 的竞态修复说明什么成熟度问题② auto 语义从 CPU 到 GPU 的切换对存量 mdp 文件的兼容性影响③ CUDA Graphs2023 引入第 13 篇与 GPU-resident 的依赖关系。五、小结与下一篇预告本篇解决了 mdrun 执行控制的三层问题六个任务落点枚举-nb/-nbfe/-pme/-pmefft/-bonded/-update是跨后端通用控制面-gpu_id 管可用性、-gputasks 管映射2018 后分工GPU-resident 有硬前提constraintsh-bonds、增大 nstcalcenergy且 2023 起 auto 默认开启rank/GPU 配比的经验是 GPU-resident 下 1 rank/GPU 最佳。落点矩阵探测器是这份硬件的性能档案起点。下一篇切到 OpenMM它的 Platform 抽象如何用运行期注册取代 GROMACS 的编译期绑定一个 Context 怎么在五个平台间切换平台属性Precision/DeviceIndex/Threads怎么传。第 5 篇再回 GROMACS 源码看 gpu_utils 如何支撑本篇的这些运行时控制。本篇认知问题回显FAQQ1gmx mdrun 的 -nb、-pme、-bonded、-update 参数分别控制什么A它们是任务落点枚举参数各取 auto/cpu/gpu-nb 管非键相互作用、-pme 管 PME 静电、-pmefft 管 PME 的 FFT 子步骤、-bonded 管键合相互作用、-update 管积分更新与约束即 GPU-resident 模式开关、-nbfe 管非键自由能项auto 由 mdrun 依据硬件拓扑自动决策。Q2GROMACS 的 -gpu_id 和 -gputasks 有什么区别A-gpu_id 声明本节点可用的 GPU 设备 ID 列表“List of unique GPU device IDs available to use”-gputasks 是任务到设备的映射字符串如 0011每位字符按序对应一个 PP/PME 任务。2018 年前 -gpu_id 兼管两者之后任务分配职责移交给 -gputasks。Q3GROMACS GPU-resident 模式-update gpu有什么前提条件A硬前提是 constraintsh-bondsGPU 约束求解器要求且 dt≤2.5 fs配套要求增大 nstcalcenergy、温度/压力耦合间隔 ≥50–100 步这些操作仍需 CPU 参与-update gpu 生效的前提是所有力计算-nb/-pme/-bonded都已上 GPU。2023 起 -update auto 默认映射 GPU。Q4多 GPU 运行 GROMACS 时每个 GPU 配几个 MPI rank 最优A官方经验每 GPU 1-3 个 rank 最优GPU-resident 模式配合 direct GPU 通信时通常 1 rank/GPU 最佳应避免 rank 数等于物理核心数CPU-only 时代的老经验多 rank 争抢单卡反而降速。 分子模拟异构算力适配开发教程（3）：mdrun 异构执行控制——-gputasks 位图语义与 GPU-resident 的硬前提
分子模拟异构算力适配开发教程3mdrun 异构执行控制——-gputasks 位图语义与 GPU-resident 的硬前提版本声明块工具/软件GROMACS 2026.x行为演进史对照 2020–2025 各版本语言/环境Linux、MPI/thread-MPI本文目标读完你能精确控制一个 mdrun 作业里每类计算落在哪个设备上并能判断自己的体系能否进 GPU-resident 模式一句话结论gmx mdrun用六个auto/cpu/gpu枚举参数-nb、-nbfe、-pme、-pmefft、-bonded、-update控制任务落点用-gputasks如0011按位映射 PP/PME 任务到 GPUGPU-resident 模式-update gpu的硬前提是constraintsh-bonds且 dt≤2.5 fs且 2023 起-update auto已默认映射 GPU。〇、本篇要解决的认知问题mdrun 的六个任务落点参数-nb/-nbfe/-pme/-pmefft/-bonded/-update各管什么auto 的决策逻辑是什么-gpu_id 和 -gputasks 都带 “gpu” 字样为什么需要两个参数2018 年前后它们发生了什么分工变化什么是 GPU-resident 模式为什么它要求 constraintsh-bonds开了它有哪些代价多 GPU 多 rank 时rank 数和 GPU 数的配比有什么经验规律一、机制解析1.1 任务落点六个枚举参数的语义为什么这一节对你重要国产卡适配做完之后性能调优的第一现场就是这组参数——同样一块卡任务落点配置不同ns/day 可以差出一倍以上。而且这组参数是跨后端通用的接口CUDA/SYCL/HIP/MUSA 都认是适配验收时的标准控制面。一个 mdrun 步骤里的计算任务被切成六类每类可以独立指定落点值域都是auto/cpu/gpu参数管辖任务说明-nb非键相互作用NBNxM 内核最大的算力消耗项GPU 化收益最直接-nbfe非键自由能部分自由能计算FEP/RE体系的非键 FE 项-pmePME 静电网格部分长程静电的 SPME 求解-pmefftPME 的 FFT 部分可与 -pme 分开指定FFT 有独立的库路径-bonded键合相互作用键/角/二面角2021 起可 offload-update积分更新与约束GPU-resident 模式的开关见 1.3auto默认的语义让 mdrun 根据硬件拓扑与体系规模自动决策。自动决策通常已经不错但国产卡适配时必须显式指定——因为 auto 的决策依据是官方后端的经验模型厂商后端的行为可能有偏差摩尔线程官方文档的示例就是全部显式指定见第 9 篇。任务之间存在依赖-pmefft gpu依赖-pme gpuFFT 是 PME 的子步骤GPU-resident 模式要求所有力计算都在 GPU 上否则每步都要跨 PCIe 搬坐标。这类依赖是排错的线索——指定了组合法但物理上不成立的落点mdrun 会在启动时报错或回退。1.2 -gpu_id 与 -gputasks一对参数的分工演变这两个参数都用于指定 GPU初学者极易混淆。官方在线帮助的原文定义-gpu_id“List of unique GPU device IDs available to use”——本节点可用的 GPU 设备 ID 列表。-gputasks“List of GPU device IDs, mapping each task on a node to a device. Tasks include PP and PME (if present)”——任务→设备的映射每位字符按序对应一个任务PP 任务和 PME 任务。历史包袱2018 之前-gpu_id同时决定哪些卡可用和任务怎么分。之后任务分配职责移交-gputasks-gpu_id回归纯可用性声明GROMACS 2025.2 用户指南明确记录了这个分工。今天的实践单卡作业用-gpu_id 0多任务映射用-gputasks。-gputasks的位图语义举例-gputasks 0011表示这个节点上有 4 个任务如 3 个 PP 1 个 PME前两个任务给 0 号卡后两个给 1 号卡。再如-gputasks 22表示两个任务都给 2 号卡2 号卡可以被多任务共享官方允许但需自担性能风险。1.3 GPU-resident 模式把整步计算钉在 GPU 上-update gpu开启 GPU-resident 模式积分更新与约束也搬到 GPU整步计算力积分不再需要把坐标搬回 CPU消除每步的 PCIe 往返。演进史版本变化2020引入仅 CUDA默认仍在 CPU2021扩展到 FEP除质量扰动与约束 FEP允许 DD/独立 PME rank2021.2修复竞态禁止扰动质量的 SETTLE2023-update auto默认映射到 GPU2026.2现行行为auto 即 GPU条件满足时硬前提官方手册原文dt≤2.5 fs 时用constraintsh-bonds——“it is necessary in order to be able to use GPU-resident mode”。原因GPU 上的约束求解器实现要求约束模式统一为 h-bonds全键约束 LINCS 的 GPU 路径受限。配套建议增大nstcalcenergy能量计算频率、温度/压力耦合间隔 ≥50–100 步——因为这两类操作仍需要 CPU 参与频率越低GPU-resident 的收益越完整。代价面GPU-resident 模式下部分功能不可用完整的不支持功能清单位于 mdrun-performance 页 “Running mdrun with GPUs” 一节以该节为准CUDA Graphs 只在 GPU-resident 步骤下有意义第 13 篇排查性能问题时 GPU 计时行为也有差异GMX_DISABLE_GPU_TIMING/GMX_ENABLE_GPU_TIMING环境变量控制。1.4 rank/GPU 配比一条反直觉的经验官方性能页的结论“多 GPU 运行每 GPU 用 1-3 个 rank 最优GPU-resident direct GPU 通信时通常1 rank/GPU 最佳”。反直觉之处新手常以为 rank 越多越好把 CPU 核心铺满实际上过多的 rank 会让每块卡被多个 MPI 进程争抢域分解的通信开销也随 rank 数上升。避免 rank 数 物理核心数——那是 CPU-only 时代的老经验。PME 侧的不平衡则用-npmePME rank 数调节或上gmx tune_pme自动扫描第 19 篇性能工程再展开。二、完整代码与逐行剖析一个任务落点矩阵探测器——跑一组短作业系统测量不同落点组合的 ns/day为国产卡适配建立第一手性能档案#!/usr/bin/env python3任务落点矩阵探测对同一 tpr 跑多种落点组合输出 ns/day 对比。 用途国产卡适配验收的第一手性能档案铁律 6性能结论必须带上下文。 importreimportsubprocessimportsysfrompathlibimportPath# 待测落点组合。从保守到激进排序任何一步失败即停后面的组合大概率也失败。# 每个元素: (标签, 附加 mdrun 参数列表)LAYOUTS[(cpu-baseline,[-nb,cpu]),# CPU 基线一切 GPU 加速的分母(nb-only,[-nb,gpu]),# 仅非键上卡最保守的 GPU 化(nb-pme,[-nb,gpu,-pme,gpu]),# 常见生产配置(full-offload,[-nb,gpu,-pme,gpu,-pmefft,gpu,-bonded,gpu]),# 除 update 外全部上卡(gpu-resident,[-nb,gpu,-pme,gpu,-pmefft,gpu,-bonded,gpu,-update,gpu]),# GPU-resident需 constraintsh-bonds]defparse_ns_per_day(mdlog:Path)-float:从 md.log 尾部解析 Performance 行的第一列ns/day。 格式官方日志 (ns/day) (hour/ns) Performance: 144.741 0.166 textmdlog.read_text(errorsreplace)# 只匹配 Performance: 行md.log 里该行只出现一次在最后的统计段mre.search(r^Performance:\s([0-9.])\s[0-9.]\s*$,text,re.M)ifnotm:raiseValueError(f{mdlog}中未找到 Performance 行作业可能异常退出)returnfloat(m.group(1))defrun_layout(tpr:Path,label:str,extra:list[str],outdir:Path,nsteps:int5000)-float:跑一种落点组合返回 ns/day。用 -nsteps 截短作业探测不需要跑完。workoutdir/label work.mkdir(parentsTrue,exist_okTrue)cmd[gmx,mdrun,-s,str(tpr),-deffnm,str(work/md),# 所有输出文件前缀-nsteps,str(nsteps),# 截短只跑探测步数-noconfout,# 不要 confout.gro探测不需要结构输出-pin,on,# 线程绑定官方示例标配-gpu_id,0,# 单卡作业声明可用卡铁律探测期固定变量*extra,]rsubprocess.run(cmd,capture_outputTrue,textTrue,timeout3600)ifr.returncode!0:print(f[{label}] 失败:{r.stderr.strip().splitlines()[-1]ifr.stderrelseunknown})return0.0returnparse_ns_per_day(work/md.log)defmain()-None:tprPath(sys.argv[1])iflen(sys.argv)1elsePath(benchMEM.tpr)ifnottpr.exists():sys.exit(f找不到{tpr}第一参数应为 .tpr 文件路径)outdirPath(layout-probe);outdir.mkdir(exist_okTrue)print(f{组合:14}{ns/day:10}{vs-CPU:9})cpuNoneforlabel,extrainLAYOUTS:try:perfrun_layout(tpr,label,extra,outdir)exceptsubprocess.TimeoutExpired:perf0.0iflabelcpu-baseline:cpuperfor1.0ratiof{perf/cpu:.2f}xifperfelse-print(f{label:14}{perf:10.2f}{ratio:9})if__name____main__:main()逐段剖析LAYOUTS 的顺序是失败熔断设计从 CPU 基线到 GPU-resident 逐级加码。如果 “nb-only” 就失败说明 GPU 后端本身有问题构建或驱动继续测更激进的组合没有意义。这个顺序也是排错顺序。parse_ns_per_day用多行正则锚定Performance:行——注意它匹配的是第一列 ns/daymd.log 尾部还有 ms/step、Matom*steps/s 等指标后两者需GMX_DETAILED_PERF_STATS才打印第 12 篇的基准流水线会全量解析。-nsteps 5000截短作业是探测脚本的关键取舍5000 步对 2 fs 步长的体系是 10 ps足够让 PME 网格、邻区列表都进入稳态又不用等太久。但要记住短作业的 ns/day 偏乐观没有长期热效应正式基准按第 12 篇的规范跑。输出的 “vs-CPU” 列就是这份硬件的 GPU 化收益档案——第 19 篇的性能诊断决策树会直接消费这张表。GPU-resident 的完整生产命令对照参考摩尔线程官方文档同款语法gmx mdrun-smd.tpr-deffnmmd-pinon\-nbgpu-bondedgpu-pmegpu-pmefftgpu-updategpu-gpu_id0多卡任务映射示例# 2 块卡、4 个任务3 PP 1 PMEPP0/PP1/PME 给 0 号卡PP2 给 1 号卡gmx mdrun-ntmpi4-gputasks0011-nbgpu-pmegpu...三、常见报错与排查问题 1现象——-update gpu启动报错提示约束类型不支持或自动回退 CPU。根因GPU-resident 的硬前提没满足——最常见的是 .mdp 里用了constraintsall-bonds全键约束或没设 constraints而 GPU 路径要求constraintsh-bonds配合 dt≤2.5 fs。另一个可能是体系用了 GPU 约束求解器不支持的特性如扰动质量的 SETTLE2021.2 起明确禁止。解法改 mdpconstraintsh-bonds重新 grompp确认 dt≤2.5 fs要更大步长走mass-repartition-factor氢质量重分配路线第 13 篇。完整不支持功能清单以 mdrun-performance 页 “Running mdrun with GPUs” 节为准。问题 2现象——-gputasks 0011报错 “invalid gputasks input” 或任务数对不上。根因位图长度必须等于节点上的任务数PP 任务数 PME rank 数。你给的字符串位数与-ntmpi/-npme推出的任务数不一致或者混淆了-gpu_id可用卡列表与-gputasks任务映射——在-gputasks里写了重复验证不了的大数字如设备不存在。解法先算清任务数任务数 PP rank 数 PME rank 数有独立 PME rank 时。比如-ntmpi 4 -npme 1是 3 PP 1 PME 4 个任务-gputasks必须恰好 4 位每位是对应设备的合法 ID。问题 3现象——加了-update gpu之后 ns/day 反而降了。根因GPU-resident 的收益前提是所有力计算都在 GPU。如果-bonded或-pme还留在 CPU每步坐标仍要在 CPU↔GPU 间往返-update gpu反而增加了一次额外的设备同步。另一个常见原因nstcalcenergy或耦合频率太高默认值是按 CPU 模式设计的GPU-resident 下应增大nstcalcenergy、耦合间隔 ≥50–100 步。解法用本文的落点矩阵探测器跑 “full-offload” 与 “gpu-resident” 两档对比确认 mdp 里nstcalcenergy已增大官方建议值见 mdrun-performance 页。问题 4现象——-gpu_id 0,1想用两块卡但日志显示只用了一块。根因-gpu_id只是可用卡声明任务分配另需 rank 层面的拆分-ntmpi或外部 mpirun与映射-gputasks。声明两块卡但只有 1 个 rank自然只有一块卡干活。这是 2018 前老语义gpu_id 兼管分配的遗留误解。解法-ntmpi 2 -gpu_id 0,1每 rank 一卡auto 映射或显式-gputasks 01。四、动手练习练习 1基础取一个已平衡的体系 tpr如 benchMEM获取方式见第 12 篇跑本文落点矩阵探测器记录五种组合的 ns/day 与 vs-CPU 比值。判定成功标准产出五行表格cpu-baseline 的 ns/day 0full-offload 对 cpu-baseline 的加速比 ≥3xGPU 工作正常的健康信号达不到先查构建与驱动再怀疑硬件。练习 2进阶扩展探测器给 LAYOUTS 增加(nb-pme-npme, [-nb,gpu,-pme,gpu,-npme,1])与-ntmpi 2的多 rank 变体对比单 rank 与 2 rank1 rank/GPU vs 2 rank/GPU在双卡机器上的差异。判定成功标准新增两行数据能回答这块硬件上 1 rank/GPU 与 2 rank/GPU 谁更快并给出数值证据官方经验规律是 GPU-resident直连通信下 1 rank/GPU 最佳验证你的硬件是否吻合。练习 3思考题无标准答案为什么-update auto在 2023 版之后默认映射 GPU而不是更早思考方向验证要点① 2021 的 FEP 扩展与 2021.2 的竞态修复说明什么成熟度问题② auto 语义从 CPU 到 GPU 的切换对存量 mdp 文件的兼容性影响③ CUDA Graphs2023 引入第 13 篇与 GPU-resident 的依赖关系。五、小结与下一篇预告本篇解决了 mdrun 执行控制的三层问题六个任务落点枚举-nb/-nbfe/-pme/-pmefft/-bonded/-update是跨后端通用控制面-gpu_id 管可用性、-gputasks 管映射2018 后分工GPU-resident 有硬前提constraintsh-bonds、增大 nstcalcenergy且 2023 起 auto 默认开启rank/GPU 配比的经验是 GPU-resident 下 1 rank/GPU 最佳。落点矩阵探测器是这份硬件的性能档案起点。下一篇切到 OpenMM它的 Platform 抽象如何用运行期注册取代 GROMACS 的编译期绑定一个 Context 怎么在五个平台间切换平台属性Precision/DeviceIndex/Threads怎么传。第 5 篇再回 GROMACS 源码看 gpu_utils 如何支撑本篇的这些运行时控制。本篇认知问题回显FAQQ1gmx mdrun 的 -nb、-pme、-bonded、-update 参数分别控制什么A它们是任务落点枚举参数各取 auto/cpu/gpu-nb 管非键相互作用、-pme 管 PME 静电、-pmefft 管 PME 的 FFT 子步骤、-bonded 管键合相互作用、-update 管积分更新与约束即 GPU-resident 模式开关、-nbfe 管非键自由能项auto 由 mdrun 依据硬件拓扑自动决策。Q2GROMACS 的 -gpu_id 和 -gputasks 有什么区别A-gpu_id 声明本节点可用的 GPU 设备 ID 列表“List of unique GPU device IDs available to use”-gputasks 是任务到设备的映射字符串如 0011每位字符按序对应一个 PP/PME 任务。2018 年前 -gpu_id 兼管两者之后任务分配职责移交给 -gputasks。Q3GROMACS GPU-resident 模式-update gpu有什么前提条件A硬前提是 constraintsh-bondsGPU 约束求解器要求且 dt≤2.5 fs配套要求增大 nstcalcenergy、温度/压力耦合间隔 ≥50–100 步这些操作仍需 CPU 参与-update gpu 生效的前提是所有力计算-nb/-pme/-bonded都已上 GPU。2023 起 -update auto 默认映射 GPU。Q4多 GPU 运行 GROMACS 时每个 GPU 配几个 MPI rank 最优A官方经验每 GPU 1-3 个 rank 最优GPU-resident 模式配合 direct GPU 通信时通常 1 rank/GPU 最佳应避免 rank 数等于物理核心数CPU-only 时代的老经验多 rank 争抢单卡反而降速。