每年年底都是GROMACS新版本的活跃期，今年情况比较特殊——2026 Beta不仅带着新算法改进，还要面对一批新硬件的适配压力。尤其是RTX 5090，作为Blackwell架构进入工作站市场的第一张卡，很多集群管理员拿到手之后的第一反应不是跑分，而是怎么把它塞进现有的GROMACS环境里正常编译、稳定跑完一个体系。我最近刚好在一套异构集群上完整过了一遍GROMACS 2026 Beta的部署流程，踩了不少坑，也整理出了一套可以照着抄的步骤。这篇手册就把整个过程拆开讲清楚，从工具链版本核对到CMake配置、从Slurm调度到常见编译运行报错，尽量把每个环节的“为什么这么做”也讲明白。
这年头做分子动力学模拟，已经很少有人能在纯CPU环境里等完一个像样的生产算例了。GROMACS的高性能路线基本绑死在GPU加速上，而异构集群的核心问题就是：不同节点CPU架构不同、GPU型号不同，有的节点插着A100，有的节点混着4090，现在又多了一批5090。编译一次、处处跑，这个目标听起来简单，实际配置起来比想象中复杂得多。加上2026 Beta版本对CUDA版本的要求比之前更严格，5090又要求CUDA 12.8以上，老环境不做升级直接编译大概率会挂。
下面这几十个小节是我这几天在实际部署中逐步确认下来的完整方案。适用于已经有一定集群使用经验的读者，也尽量照顾到第一次自己编译GROMACS的新手。核心思路是：不求花哨，只求能稳定复现。
1. 部署前先认清现状：2026 Beta与Blackwell的适配背景
1.1 为什么Beta版本值得提前上车
GROMACS 2026 Beta目前在官方仓库处于功能冻结阶段，也就是说主要算法特性已经定型，剩下的工作集中在修bug和稳定性优化。对于做应用支持的人来说，这个时间点反而是了解新版本特性的最佳时机。新版在GPU端PME、非 bonded 计算调度、混合精度路径上都有明显调整，尤其是在新硬件上，老版本GROMACS 2024其实是没法直接发挥5090全部算力的，因为编译期根本不认识SM 120架构。
很多人会问：既然还在Beta，为什么不能等正式版？这个问题要分场景看。如果是生产集群、跑着长期项目，我完全理解先等等；但如果你是做评测、做适配、给课题组探路，那Beta版必须早部署早摸底。原因很简单：等正式版发出来再开始适配，拿到第一手基准数据的时间又往后推了几周，等反馈到上层决策时，硬件采购评估已经结束了。提前把Beta跑通，正式版发布后基本就是换个版本号重新编译一遍的事。
1.2 异构集群与5090带来的核心挑战
“异构集群”这个词在不同人口中含义差别很大。这里特指多计算节点混合硬件环境：一部分节点是纯CPU，一部分节点是老的Ampere架构GPU，一部分是Ada架构（4090），现在又插入了Blackwell架构（5090）。这种环境下，GROMACS部署要解决三个层面的问题。
第一层是编译层面。GROMACS本身是支持CUDA架构列表的，你可以一次编译同时支持多个SM版本，但前提是CUDA Toolkit版本必须高于最老架构和最新架构各自的门槛。5090要求CUDA 12.8+，老卡则要求最低CUDA版本不能过高，否则编译产物在旧卡上跑不了。第二层是运行时层面。mdrun在启动时要自动检测GPU并选择计算设备，如果一台机器上插着不同型号的卡，驱动、显存、PCIe带宽都不同，GROMACS的自动任务分配未必合理，需要人工干预绑定。第三层是调度层面。Slurm或者PBS需要给任务正确分配GRES资源，否则GPU可能被多个任务抢占，跑出来的性能数据完全不可信。
5090这块卡的具体情况，我再多说几句。它用的是GB202芯片（完整版为GB202，5090为GB202-400），Compute Capability是12.0，也就是编译期要用CMAKE_CUDA_ARCHITECTURES=120或者-DGMX_GPU_CUDA_ARCH（假设老版本配置方式）。显存32GB GDDR7，带宽比4090高了约55%，FP32算力也有明显提升。对GROMACS来说，比较受益的是GPU端PME和bonded计算，因为这两块对双精度和混合精度的吞吐非常敏感。但要注意一点：5090的PCIe接口是5.0 x16，在不同主板上实际跑在5.0还是4.0，对CPU-GPU传输密集型任务影响很大。跑基准之前先确认nvidia-smi里的总线速率，别让硬件配置白瞎了好卡。
2. 部署开始前必须核对的环境版本与工具链
2.1 驱动、CUDA与编译器版本匹配原则
在动手编译之前，我强烈建议先把环境版本的匹配关系确认清楚，这是整个部署过程中最省时间的投资。5090需要515以上的驱动，但生产环境我建议直接用最新的稳定驱动，比如560系列或更新。注意一个细节：很多集群机器升级驱动后，旧版本的CUDA runtime会不兼容，GROMACS编译时会报cuda.h与驱动版本不匹配之类的错误，先统一驱动版本再处理CUDA。
CUDA Toolkit建议使用12.8或12.9，这两个版本对Compute Capability 12.0（SM 120）提供了正式支持。如果你还在用CUDA 12.4，编译时指定CMAKE_CUDA_ARCHITECTURES=120会直接被拒绝，因为老版CUDA根本不认识Blackwell的架构号。这是一个硬门槛，没有技巧可绕，只能升级Toolkit。
编译器方面没有太多悬念，GCC 12.3或者13.2都是稳妥选择，重点要确认两件事：一是gcc版本与CUDA Toolkit的nvcc版本兼容性对照表——直接看CUDA安装目录下的README或者NVIDIA官方文档；二是MPI库的选择。OpenMPI 4.1.6或5.0.3在目前阶段最稳定，不建议用老旧版本，否则在多节点场景下会出现莫名其妙的超时和通信错误。GROMACS 2026 Beta的编译系统对CMake版本也有要求，建议CMake 3.27以上，低于这个版本处理CUDA架构列表时容易出幺蛾子。
2.2 工具链核心组件：TCE v3.10.11 与 tcs-core 版本核对
这里单独说一个要点。在我们内部的集群环境里，软件栈管理不是直接用系统自带的编译器，而是通过一套自定义的工具链环境来切换。最近一次部署中，我们用的工具链版本是tce v3.10.11，对应的核心运行组件是tcs-core。这个组合对GROMACS 2026 Beta的影响不在于GROMACS本身，而在于它决定了MPI、FFTW、CUDA这些依赖库的ABI一致性。
经验是：部署GROMACS之前，先加载工具链，然后在同一个环境下编译所有依赖，不要混着用不同版本的编译器。tcs-core里通常包含了一系列修补过的数学库和运行库，如果版本和GROMACS编译期间用到的依赖不匹配，运行时会报一些很隐蔽的错误，比如undefined symbol或者libgfortran.so.5找不到。这属于那种“编译全通过、运行秒报错”的经典坑，排查起来相当浪费时间。所以一定在部署最开始就确认tce v3.10.11对应的tcs-core精确版本，并把它写进部署文档里。
2.3 FFTW与数学库的编译细节
GROMACS在做PME计算时需要FFT库。2026 Beta继续支持FFTW3和内部FFT两种方式。我个人的建议是：如果你没有特殊需求，直接使用GROMACS自带的内部FFT实现，也就是在CMake中不显式指定外部FFTW，或者使用-DGMX_FFT_LIBRARY=fftw3并事先编译好FFTW 3.3.10。
在生产集群上我更推荐手动编译FFTW，因为可以针对当前CPU架构开启SIMD优化。命令很直接：
./configure --prefix=/opt/fftw/3.3.10 --enable-avx2 --enable-avx512 --enable-mpi make -j 32 make install如果集群里的CPU是Intel Sapphire Rapids或者AMD Zen4，--enable-avx512带来的性能提升值得多花这些编译时间。编译好之后，GROMACS的CMake配置里会通过FFTW3_ROOT或CMAKE_PREFIX_PATH自动找到它。对纯CPU节点来说，FFTW的优化直接关系到PME性能，别在这步偷懒。
3. GROMACS 2026 Beta 编译安装全程实录
3.1 获取源码与构建目录规划
GROMACS 2026 Beta可以从官方GitLab仓库拉取，也可以从发布页面下载tar包。我建议使用git clone的方式，因为Beta阶段修bug很频繁，你很可能今天编译完，后天官方推了个fix commit，拉源码方便增量更新。
git clone https://gitlab.com/gromacs/gromacs.git cd gromacs git checkout release-2026-beta mkdir build cd build然后规划安装路径，这里有个经验技巧：不要直接装到/usr/local，建议装到独立路径，比如/opt/gromacs/2026-beta，方便后续多版本共存。集群管理员都知道，GROMACS升级时如果直接覆盖旧版本，出问题回滚很痛苦。独立的安装路径加Lmod模块系统，可以做到多版本无缝切换。
3.2 CMake配置命令详解
CMake配置是部署中最核心的环节。先给出一份实测可用的完整配置命令，然后逐项解释含义。
cmake .. \ -DCMAKE_INSTALL_PREFIX=/opt/gromacs/2026-beta \ -DGMX_BUILD_OWN_FFTW=OFF \ -DGMX_FFT_LIBRARY=fftw3 \ -DGMX_GPU=CUDA \ -DGMX_MPI=ON \ -DGMX_DOUBLE=OFF \ -DGMXAPI=ON \ -DCMAKE_CUDA_ARCHITECTURES=120 \ -DCMAKE_C_COMPILER=mpicc \ -DCMAKE_CXX_COMPILER=mpicxx \ -DGMX_OPENMP=ON \ -DGMX_SIMD=AVX2_512逐项拆开说。
-DGMX_GPU=CUDA是开启NVIDIA GPU支持，如果集群里有AMD GPU的节点，你可能需要看GMX_GPU=HIP或者SYCL的选项，但本文场景以NVIDIA为主，不做展开。
-DGMX_MPI=ON是我们在异构集群上的必选项。启用MPI后，GROMACS才能跨节点并行跑多副本或者单算例大规模并行。如果你只有单机多卡，-DGMX_MPI=OFF也能把thread-MPI用起来，但那只是yaksa替代方案，没有跨节点能力。
-DGMX_DOUBLE=OFF对应混合精度。这是GROMACS的默认模式，也是性能最好的模式，把坐标计算用双精度、力与能量用单精度混合处理。除非你做严格的能量计算或需要验证数值精度，否则不要开GMX_DOUBLE=ON。开了之后性能下降是很明显的。
-DGMXAPI=ON这个选项可能新手不太熟。它是GROMACS的C和C++ API接口层，作用相当于把GROMACS的核心库封装成可被外部程序调用的形态，相当于一套中间件。比如你要用gmxapi去做自适应采样或者外部Python脚本控制模拟，就必须开启它。在2026 Beta上，这个选项的默认值可能已经是ON，但显式指定更稳妥。
-DCMAKE_CUDA_ARCHITECTURES=120这个参数指代Blackwell架构。这里有个细节需要讲清楚：如果你想让编译好的GROMACS同时兼容老的A100（SM 80）、4090（SM 89）和5090（SM 120），可以写成-DCMAKE_CUDA_ARCHITECTURES="80;89;120"。这样生成的可执行文件会包含多个GPU分支，运行时根据实际硬件自动选择。代价是编译时间和二进制体积变大，但对异构集群来说这是最合理的选择。
-DGMX_SIMD=AVX2_512是CPU端的SIMD指令集优化。这个值要参考集群里最老CPU的指令集。如果集群里有Skylake时代的CPU，开AVX2_512可能会编译不通过或运行崩溃。更稳妥的做法是以所有节点共有的指令集为准，或者干脆用-DGMX_SIMD=AVX2_256。我在这套集群上用的是AVX2_512，因为节点之间处理器代差不大。如果不确定，就先不开这个选项，让GROMACS自动检测。
3.3 编译与安装执行
配置成功后，编译是个相对机械的过程。
make -j 32 make install-j后面的数字取决于每个编译节点的CPU核心数。在大型编译任务中，我遇到过make -j 64直接OOM的情况，因为GROMACS编译过程中有些文件特别吃内存。经验法则是：如果每个编译任务吃2-3GB内存，-j数字乘以单个任务内存不要超过节点内存的80%。
编译完成后，检查一下gmx二进制是否能正常识别GPU：
/opt/gromacs/2026-beta/bin/gmx -version关键是看CUDA 12.8、GPU support: yes这样的输出。如果你配置了多架构支持，这里还会显示支持的GPU架构号。之后可以跑一个自带的benchmark：
/opt/gromacs/2026-beta/bin/gmx mdrun -s /path/to/test.tpr -nb gpu -pme gpu -update gpu这也是最快验证部署是否成功的方式。
4. 异构集群中的任务调度与运行配置
4.1 Slurm中GPU资源的申请方式
编译安装之后，真正到跑生产算例的阶段，调度配置就成了关键。在包含5090的异构集群上，Slurm调度器（或其兼容分支）通常有两种方式管理GPU资源。
一种是通用GRES模式。你在任务脚本里写--gres=gpu:1，Slurm负责分配任意一个可用GPU。这种方式简单，但无法区分卡型。在异构混布环境里风险很大——你的任务可能被分到一台只有老卡的关键节点上，性能完全不达预期。
第二种是类型化GRES模式。通过GresTypes和NodeSet配合，给不同节点打上GPU型号标签，然后在提交脚本里指定--gres=gpu:5090:2这种方式。这样调度器只会把任务放在满足GPU型号和数量要求的节点上。
这里有一个实际执行过程的模板脚本：
#SBATCH --job-name=gmx-5090-test #SBATCH --nodes=2 #SBATCH --ntasks-per-node=2 #SBATCH --cpus-per-task=16 #SBATCH --gres=gpu:5090:2 #SBATCH --gres-flags=enable-binding module purge module load tce/3.10.11 module load tcs-core module load cuda/12.8 module load gromacs/2026-beta export OMP_NUM_THREADS=16 mpirun -np 4 gmx_mpi mdrun -deffnm md \ -nb gpu -pme gpu -update gpu -bonded gpu \ -pmefft gpu -npme 1 -ntomp 16 -pin on -pinoffset 0注意--gres-flags=enable-binding这个参数，它会告诉Slurm为每个任务绑定对应的GPU设备。如果不加，多个MPI进程可能同时映射到同一张卡上，导致性能断崖式下跌。
4.2 CPU-GPU绑定策略与MPI进程映射
异构集群上最常见的性能陷阱，不是GPU算力不够，而是PCIe带宽和CPU-NUMA亲和性。我自己调试的时候经常遇到这样的情况：nvidia-smi显示GPU利用率99%，但整体模拟速度远低于单机测试结果。这通常是任务的MPI rank和GPU绑定没有做对。
GROMACS 2026的mdrun在GPU识别方面做得很细，但集群管理员还是要理解底层逻辑。默认情况下，MPI进程会按顺序绑定到可见的GPU设备，但在多节点多卡环境下，CUDA_VISIBLE_DEVICES环境变量可能会把设备顺序打乱。一个有效的做法是显式将MPI rank与GPU索引一一对应：
export CUDA_VISIBLE_DEVICES=${SLURM_LOCID}或者在mpirun中通过--map-by和--bind-to配合，确保rank和硬件位置对齐。这里没有万能公式，因为调度器、MPI实现和硬件拓扑都可能不同。最靠谱的方法是用mpirun -np 4 --report-bindings跑一个小测试，先看清楚实际绑定情况，再调整策略。
在NUMA层面还有一个容易被忽视的细节：把-ntomp线程数设置成与CPU socket内的物理核心数一致，而不是总逻辑核心数。开超线程的机器如果-ntomp等于逻辑核心总数，-pin on时会因为核心争抢产生明显的性能回退。
4.3 混合精度、PME负载分配与性能预期校正
异构集群部署完成后，最难回答的一个问题往往是：5090到底比4090快多少？我的建议是不要看厂商PPT，不要看别人的benchmark，一定要跑自己的体系。
用GROMACS自带的benchPEP或benchMEM做标准化测试时，要注意把PME计算负载放在哪个设备上。对于2026 Beta来说，-nb gpu -pme gpu -update gpu -bonded gpu已经是比较激进的配置，所有主要计算全部交给GPU。但前提是你的体系足够大，能够把GPU喂饱。对小体系（几万原子以内），过度的GPU分配反而会因为H2D传输产生瓶颈，这个时候-bonded cpu或者把PME放在CPU上反而更快。
关于参数选择，具体可以这样操作：先用一组中等规模体系做基线测试，比如一个10万原子的膜蛋白体系。分别跑三组参数组合：
# 组合一：全部GPU gmx_mpi mdrun -nb gpu -pme gpu -update gpu -bonded gpu # 组合二：PME在CPU gmx_mpi mdrun -nb gpu -pme cpu -update gpu -bonded gpu # 组合三：保守模式 gmx_mpi mdrun -nb gpu -pme cpu -update cpu -bonded cpu记录每组配置下的ns/day数值。5090的32GB显存意味着你可以在显存里放更大的PME网格，对于大体系来说-pme gpu配合高精度FFT的优势更明显。小体系就别全用GPU了。
另外提醒一点：在Beta版本中，-update gpu（GPU端状态更新）对于大规模并行仍然有一些稳定性问题。如果你跑1000万原子级别以上的体系，建议先用-update cpu把生产任务跑起来，避免新特性带来的潜在数值异常，等跑完一个完整算例后再逐步尝试-update gpu。
4.4 多版本GROMACS共存的Module管理
异构集群通常不会只用一套GROMACS版本。正式版GROMACS 2024.3还承担着既有的生产任务，2026 Beta只是测试通道。这种情况下，Lmod环境模块系统就非常有用。
在/opt/modulefiles/gromacs/2026-beta里写一个简单的modulefile：
#%Module1.0 prepend-path PATH /opt/gromacs/2026-beta/bin prepend-path LD_LIBRARY_PATH /opt/gromacs/2026-beta/lib64 prepend-path MANPATH /opt/gromacs/2026-beta/share/man这样用户在提交作业时根据需求module load gromacs/2026-beta或module load gromacs/2024.3，互不干扰。对于集群级部署，强烈建议从一开始就建立规范的module体系，而不是把路径写死在每个人的.bashrc里。多个用户各自维护环境变量，等出问题时排查成本极高。
5. 常见问题与排查技巧实录
5.1 编译期经典报错与处理方案
部署过程中难免要跟编译错误打交道，我把这几天遇到的和身边同事常见的问题整理成一个速查表。
报错一：fatal error: cuda_runtime.h: No such file or directory
原因通常不是CUDA没装，而是CMake没有找到CUDA Toolkit路径。解决办法是显式指定：
cmake .. -DCUDAToolkit_ROOT=/usr/local/cuda-12.8报错二：Unsupported gpu architecture 'compute_120'
这个报错说明CUDA版本过旧，升级到CUDA 12.8或更高。如果无法升级，还能怎么做？那就只能退而求其次用5090跑在兼容模式下（实际不可行，因为SM 120是必须识别的架构）。所以这个场景下没有捷径，必须升级Toolkit。
报错三：编译中途Internal compiler error
这通常和GCC版本有关。GCC 11在编译某些CUDA相关文件时偶发ICE，换用GCC 12.3或降级到GCC 10都可以。另外检查内存是否充足，make -j数量过大会导致内存耗尽引发各种莫名其妙的错误。
报错四：Could NOT find MPI_C (missing: MPI_C_LIBRARIES)
这一般是OpenMPI环境变量没设好。先确认mpirun路径，然后重新加载MPI模块后再重新配置。注意，重新配置之前删除CMakeCache.txt，因为CMake会缓存旧路径。
5.2 运行时问题与性能排查
问题一：程序启动后GPU利用率低
先看绑定。跑nvidia-smi确认每个进程对应哪张卡。如果发现多个rank挤在同一张卡上，重新检查CUDA_VISIBLE_DEVICES和mpirun映射。其次看是不是体系太小，计算量喂不满显卡。
问题二：报错No such file or directory但文件明明存在
这经常发生在MPI模式下的动态库依赖问题。新版GROMACS在mpi模式下编译出的gmx_mpi二进制依赖若干共享库，比如libgromacs.so.12。如果LD_LIBRARY_PATH没包含GROMACS的lib目录，就会出现这种诡异现象。解决：
export LD_LIBRARY_PATH=/opt/gromacs/2026-beta/lib64:$LD_LIBRARY_PATH问题三：5090显卡单卡性能跑不满理论值
这大概率不是GROMACS配置问题，而是PCIe链路速率不对。用nvidia-smi -q -d BUS查看当前速率。如果显示PCIe: 4.0 x16而你的主板支持5.0，看看是不是插槽插错了位置或者主板BIOS设置问题。另外，电源供应不足会导致GPU降频，5090的峰值功耗比4090更高，电源余量不够的话会看到Performance State反复跳动。
问题四：多节点运行时网络通信成为瓶颈
GROMACS在大规模并行时特别依赖MPI通信。如果确认GPU、绑定都正常但扩展性不理想，检查使用的MPI是否支持RDMA网络。用mpirun --mca pml ucx（OpenMPI）或--mca btl ^tcp来启用高性能传输。部分旧集群的InfiniBand设置需要额外模块加载，比如ucx，这些细节都会直接反映在并行效率上。
问题五：5090与老GPU混跑时有一个卡明显慢
异构混跑是目前部署里最棘手的问题。当4090和5090在同一节点时，GROMACS默认按设备序号分配负载，但算力和显存差异会导致负载不均。目前推荐的解决策略是：尽量不在同一节点混插不同代际的GPU，物理隔离是最彻底的办法。如果确实无法避免，就需要在mdrun前通过CUDA_VISIBLE_DEVICES限定每个任务只有同型号GPU，比如5号卡至7号卡跑任务A，8号卡至10号卡跑任务B。
6. 经验之谈：部署GROMACS 2026 Beta的真正顺序
这套流程走下来，我个人最深的体会是：部署GROMACS 2026 Beta这件事，真正的技术难点不在于GROMACS本身，而在于你是否能把工具链版本、编译器ABI、CUDA门槛、调度器类型识别、硬件绑定性这几件事按顺序理顺。很多人编译失败，追溯到最后都是环境版本错位导致的连锁反应。与其四处搜报错信息，不如在最开始就做一次严格的版本核对，把所有依赖的版本号写下来，在干净的模块环境里一步到位。
另外再分享一个小技巧：Beta版本编译前，在集群上先跑一遍gmx -version记录的编译配置输出，把它存成文本。后续排查兼容性问题时，这份记录能帮你快速判断是编译参数问题还是运行时环境差异。还有，记得保留当时使用的CMakeCache.txt，这是官方支持排查问题时最想看到的东西。很多集群管理员删了它，等到出问题需要对比编译参数时，只能凭记忆，效率差太多了。
最后说回5090本身。这张卡的性能潜力在GROMACS上确实很大，但前提是部署的每一步都稳扎稳打。CUDA 12.8是硬门槛，调度器要能识别GPU类型，运行时绑定要做对。把这几点做到位，2026 Beta跑出来的性能会让你觉得前期踩的坑都很值得。等正式版发布后，更换版本号再编译一轮，整条流程我已经验证过是顺滑的，也祝你在自己的异构集群上一遍过。
