分子模拟异构算力适配开发教程（3）：mdrun 异构执行控制——-gputasks 位图语义与 GPU-resident 的硬前提

分子模拟异构算力适配开发教程（3）：mdrun 异构执行控制——-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 任务到 GPU；GPU-resident 模式（-update gpu）的硬前提是constraints=h-bonds且 dt≤2.5 fs，且 2023 起-update auto已默认映射 GPU。

〇、本篇要解决的认知问题

1. mdrun 的六个任务落点参数（-nb/-nbfe/-pme/-pmefft/-bonded/-update）各管什么？auto 的决策逻辑是什么？
2. -gpu_id 和 -gputasks 都带 “gpu” 字样，为什么需要两个参数？2018 年前后它们发生了什么分工变化？
3. 什么是 GPU-resident 模式？为什么它要求 constraints=h-bonds？开了它有哪些代价？
4. 多 GPU 多 rank 时，rank 数和 GPU 数的配比有什么经验规律？

一、机制解析

1.1 任务落点：六个枚举参数的语义

为什么这一节对你重要：国产卡适配做完之后，性能调优的第一现场就是这组参数——同样一块卡，任务落点配置不同，ns/day 可以差出一倍以上。而且这组参数是跨后端通用的接口（CUDA/SYCL/HIP/MUSA 都认），是适配验收时的标准控制面。

一个 mdrun 步骤里的计算任务被切成六类，每类可以独立指定落点（值域都是auto/cpu/gpu）：

auto（默认）的语义：让 mdrun 根据硬件拓扑与体系规模自动决策。自动决策通常已经不错，但国产卡适配时必须显式指定——因为 auto 的决策依据是官方后端的经验模型，厂商后端的行为可能有偏差（摩尔线程官方文档的示例就是全部显式指定，见第 9 篇）。

任务之间存在依赖：-pmefft gpu依赖-pme gpu（FFT 是 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 往返。演进史：

硬前提（官方手册原文）：dt≤2.5 fs 时用constraints=h-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 侧的不平衡则用-npme（PME 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（需 constraints=h-bonds）]defparse_ns_per_day(mdlog:Path)->float:"""从 md.log 尾部解析 Performance 行的第一列（ns/day）。 格式（官方日志）： (ns/day) (hour/ns) Performance: 144.741 0.166 """text=mdlog.read_text(errors="replace")# 只匹配 Performance: 行；md.log 里该行只出现一次（在最后的统计段）m=re.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:int=5000)->float:"""跑一种落点组合，返回 ns/day。用 -nsteps 截短作业（探测不需要跑完）。"""work=outdir/label work.mkdir(parents=True,exist_ok=True)cmd=["gmx","mdrun","-s",str(tpr),"-deffnm",str(work/"md"),# 所有输出文件前缀"-nsteps",str(nsteps),# 截短：只跑探测步数"-noconfout",# 不要 confout.gro（探测不需要结构输出）"-pin","on",# 线程绑定（官方示例标配）"-gpu_id","0",# 单卡作业：声明可用卡（铁律：探测期固定变量）*extra,]r=subprocess.run(cmd,capture_output=True,text=True,timeout=3600)ifr.returncode!=0:print(f"[{label}] 失败:{r.stderr.strip().splitlines()[-1]ifr.stderrelse'unknown'}")return0.0returnparse_ns_per_day(work/"md.log")defmain()->None:tpr=Path(sys.argv[1])iflen(sys.argv)>1elsePath("benchMEM.tpr")ifnottpr.exists():sys.exit(f"找不到{tpr}（第一参数应为 .tpr 文件路径）")outdir=Path("layout-probe");outdir.mkdir(exist_ok=True)print(f"{'组合':<14}{'ns/day':>10}{'vs-CPU':>9}")cpu=Noneforlabel,extrainLAYOUTS:try:perf=run_layout(tpr,label,extra,outdir)exceptsubprocess.TimeoutExpired:perf=0.0iflabel=="cpu-baseline":cpu=perfor1.0ratio=f"{perf/cpu:.2f}x"ifperfelse"-"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/day；md.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 PME）：PP0/PP1/PME 给 0 号卡，PP2 给 1 号卡gmx mdrun-ntmpi4-gputasks0011-nbgpu-pmegpu...

三、常见报错与排查

问题 1：现象——-update gpu启动报错，提示约束类型不支持或自动回退 CPU。

根因：GPU-resident 的硬前提没满足——最常见的是 .mdp 里用了constraints=all-bonds（全键约束）或没设 constraints，而 GPU 路径要求constraints=h-bonds（配合 dt≤2.5 fs）。另一个可能是体系用了 GPU 约束求解器不支持的特性（如扰动质量的 SETTLE，2021.2 起明确禁止）。

解法：改 mdpconstraints=h-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 > 0；full-offload 对 cpu-baseline 的加速比 ≥3x（GPU 工作正常的健康信号；达不到先查构建与驱动再怀疑硬件）。

练习 2（进阶）：扩展探测器，给 LAYOUTS 增加("nb-pme-npme", ["-nb","gpu","-pme","gpu","-npme","1"])与-ntmpi 2的多 rank 变体，对比单 rank 与 2 rank（1 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 Graphs（2023 引入，第 13 篇）与 GPU-resident 的依赖关系。

五、小结与下一篇预告

本篇解决了 mdrun 执行控制的三层问题：六个任务落点枚举（-nb/-nbfe/-pme/-pmefft/-bonded/-update）是跨后端通用控制面；-gpu_id 管可用性、-gputasks 管映射（2018 后分工）；GPU-resident 有硬前提（constraints=h-bonds、增大 nstcalcenergy）且 2023 起 auto 默认开启；rank/GPU 配比的经验是 GPU-resident 下 1 rank/GPU 最佳。落点矩阵探测器是这份硬件的性能档案起点。

下一篇切到 OpenMM：它的 Platform 抽象如何用运行期注册取代 GROMACS 的编译期绑定，一个 Context 怎么在五个平台间切换，平台属性（Precision/DeviceIndex/Threads）怎么传。第 5 篇再回 GROMACS 源码，看 gpu_utils 如何支撑本篇的这些运行时控制。

本篇认知问题回显（FAQ）

Q1：gmx mdrun 的 -nb、-pme、-bonded、-update 参数分别控制什么？

A：它们是任务落点枚举参数（各取 auto/cpu/gpu）：-nb 管非键相互作用、-pme 管 PME 静电、-pmefft 管 PME 的 FFT 子步骤、-bonded 管键合相互作用、-update 管积分更新与约束（即 GPU-resident 模式开关）、-nbfe 管非键自由能项；auto 由 mdrun 依据硬件拓扑自动决策。

Q2：GROMACS 的 -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。

Q3：GROMACS GPU-resident 模式（-update gpu）有什么前提条件？

A：硬前提是 constraints=h-bonds（GPU 约束求解器要求）且 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 争抢单卡反而降速）。