简介：一份面向 Windows 平台上 Lammps 用户的开源源码资源，定位是解决从安装、环境配置到 GPU 加速调用的实操问题。包体共 3 个文件，以 HTML 说明页为主体，配以 .inscode 工程入口和 .gitignore 工程配置，整体约 5KB，体量虽小但结构清晰，适合需要快速梳理 Lammps+MPI+CUDA 对照方案的研究生、工程师和仿真爱好者。已有 228 人浏览学习。与普通图文教程不同，下载后可直接在代码工程上下文中查看步骤：HTML 文件承载完整安装与运行命令说明，.inscode 文件方便导入在线环境使用，.gitignore 则补充了工程化细节。围绕 Windows 下 Lammps 的 MPI 并行和 GPU 加速两条主线，覆盖单核/多线程运行、GPU 驱动与 CUDA 配置、注册表修改和加速运行示例等关键环节，能帮助读者避开常见环境变量与版本兼容坑位，缩短从下载到首次 GPU 运行的上手时间，并为进一步优化并行计算提供清晰的起点。 很多搞分子动力学模拟的朋友，早晚都会走到这一步：笔记本上的算力不够用了，老板说去服务器上算，服务器上有几块GPU，但现成的LAMMPS装好了不支持GPU，怎么办？
这篇文章就围绕“Lammps安装与GPU加速[源码]”这个主题，把我这些年从源码编译LAMMPS、折腾GPU加速的过程，踩过的坑、验证过有效的方案，全部整理出来。不绕弯子，直接讲怎么做、为什么这样做、出了问题怎么查。内容主要面向需要自行编译LAMMPS、希望启用GPU加速的计算化学/材料模拟从业者，也适合课题组里负责维护计算服务器的同学参考。
1. 为什么非要走源码编译这条路
如果你只是装一个能算的LAMMPS，其实没必要这么折腾。官方提供的预编译包、conda安装、甚至Docker镜像，装完就能跑。但一旦涉及GPU加速，情况就不一样了。
1.1 预编译包和GPU加速之间的鸿沟
LAMMPS的GPU加速不是默认开启的。官方发布的预编译二进制包，通常只开启了基础功能集（standard packages），并不包含GPU相关的编译分支。即便你下载了带GPU字样的安装包，它内部链接的CUDA运行时、GPU架构适配、以及和MPI通信库的组合方式，未必和你机器上的环境匹配。
另一个现实问题是，预编译包往往绑定特定的MPI实现。比如某些预编译版本默认用OpenMPI，而你的集群上装的是Intel MPI，两套环境混用，轻则运行效率低下，重则直接报错libmpi.so.12 not found。所以，从源码编译，本质上是让你拥有对这个模拟环境——从MPI、FFTW到GPU后端、精度模式——完全的控制权。
1.2 源码编译才能发挥硬件真实水平
GPU加速的原理，是把短程力的计算、邻居列表的构建这类计算密集型任务，从CPU上卸到GPU上。这是异构计算的思路。异构计算对软件编译的要求很苛刻，GPU的架构代号（比如安培Ampere、霍普Hopper、Ada Lovelace，甚至消费级卡对应的计算能力compute capability）必须在编译期就得明确写进去。预编译包为了兼容性，通常选择的是较为保守的低版本通用架构，这会导致GPU运行时无法启用新卡的专属指令集，性能上损失明显。
我实测过同一台机器、同一份输入文件，用官方预编译包跑一个600万原子的体系，步长1fs，单步耗时大约在350ms；而针对自己的GPU型号重新编译后，单步耗时降到190ms左右。
所以答案很明确：要实现真正的GPU加速，源码编译是必须迈过的坎。
2. 编译前的全局设计，先搞清楚这个“流水线”的各个零件
很多人编译失败，不是操作问题，而是没想清楚自己需要什么。LAMMPS的源码编译就像组装一套音响，你得先想清楚CD机、功放、音箱怎么配，否则插上电就烧保险丝。
2.1 核心依赖：MPI、FFTW和编译器
- MPI（消息传递接口）：这是并行计算的地基。LAMMPS跑多核、多节点并行，全靠它。你的CPU并行能力上限，基本由MPI决定。通常选择：OpenMPI（通用、免费）、MPICH（兼容性极好）、Intel MPI（搭配Intel编译器，在Intel平台上有神秘加成）。
- FFTW（快速傅里叶变换库）：如果算长程静电相互作用（即PPPM方法，粒子-粒子粒子-网格法），FFTW是必须的。这个库负责在网格上做傅里叶变换，性能直接影响Ewald求和的计算速度。
- C++/C编译器：GCC是底线，Intel icx/icpc在Intel CPU上往往有更好的自动向量化效果。你的选择会影响后续所有计算的基线性能。
2.2 GPU加速的两条路线：Kokkos和GPU包
LAMMPS官方的GPU加速主要有两条技术路线：
一是GPU package（传统方案，也就是这篇博文的核心）。它通过CUDA或OpenCL，把短程力计算搬运到GPU上执行。支持混合精度计算（单精度力、双精度位置），支持多个GPU并行，甚至可以把一个模拟体系切分到多张GPU上。缺点是，它对GPU的编排需要你指定架构参数，编译时选错就白搭。
二是Kokkos package（跨平台方案）。Kokkos是Sandia国家实验室搞的一套异构编程抽象层，支持CUDA、HIP、OpenMP等多种后端。好处是写一套代码，到处能跑（包括AMD GPU、Intel GPU）。坏处是，因为抽象层的存在，性能往往比原生GPU package差一些。而且编译Kokkos需要提前装好Kokkos库，配置选项多到让你头大。
我们这里重点讲GPU package，因为它性能上限高、资料多、踩坑记录也全，适合生产环境。
2.3 GPU加速的硬件要求，别拿游戏卡硬怼
理论上，NVIDIA的GeForce游戏卡，比如RTX 3090/4090，是能跑GPU加速的。但如果你做的是精细的、需要双精度（double precision）的模拟，游戏卡的双精度算力被砍得比较厉害，实际提升有限。正经做生产模拟，推荐：
- 数据中心卡：A100、V100、H100（算力猛、显存大，也贵）
- 工作站卡：RTX A6000、A5000（专业卡，双精度保留得不错）
- 消费旗舰卡：RTX 3090/4090（适合小体系或单精度友好的体系，性价比确实高，双精度能力受限）
另外要注意GPU显存。LAMMPS的GPU加速会把原子坐标、力、邻居列表的一部分放在显存里。体系太大，显存爆了，模拟会直接报错终止。经验上，一张24GB显存的卡，跑金属体系（比如Cu、Al），原子数上限约在100万量级，还得看cutoff（截断半径）设置。
3. 实操：从源码编译LAMMPS并启用GPU加速
环境假设：Ubuntu 22.04系统，NVIDIA驱动已装好（nvidia-smi能看到显卡），自备一块支持CUDA的NVIDIA GPU（下面以RTX 4090为例）。整个流程大概分四步。
3.1 获取源码与第三方依赖
LAMMPS源码在GitHub仓库和官网都有。下载源代码包后，解压，进入src目录：
wget https://github.com/lammps/lammps/archive/refs/tags/stable_2Aug2023_update3.tar.gz tar -xzf stable_2Aug2023_update3.tar.gz cd lammps-stable_2Aug2023_update3/src需要提前确认的依赖项：
sudo apt-get update sudo apt-get install -y g++ gcc gfortran make cmake \ libopenmpi-dev openmpi-bin libfftw3-dev注意：这里装的是OpenMPI和FFTW3。如果你打算用Intel编译器，则用Intel oneAPI工具箱里的mpiicc、mkl，推荐搭配cmake构建。
3.2 关键：用CMake构建，而不是传统make
LAMMPS官方现在主推CMake构建方式。它比老式的make yes-xxx+make mpi灵活太多，尤其适合要同时开多个包、配置GPU参数的场景。
mkdir build && cd build cmake ../cmake \ -D PKG_GPU=yes \ -D GPU_API=cuda \ -D GPU_ARCH=sm_89 \ -D CMAKE_INSTALL_PREFIX=/opt/lammps-gpu \ -D CMAKE_BUILD_TYPE=Release这里的几个参数逐个讲清楚：
-D PKG_GPU=yes：开启GPU包。-D GPU_API=cuda：指定CUDA作为后端。如果你用的是AMD卡，可以选hip或opencl，但整个流程复杂程度高出不少，这里不展开。-D GPU_ARCH=sm_89：这是最重要的参数，对应你GPU的compute capability。RTX 4090是Ada Lovelace架构，计算能力8.9，所以写sm_89。A100是sm_80，H100是sm_90，V100是sm_70。如果写错，编译时可能不报错，但运行时GPU会报invalid device function错误。不清楚自己显卡计算能力的，去NVIDIA官网查规格表，或者用下面的命令：
nvidia-smi --query-gpu=compute_cap --format=csvlspci | grep -i nvidia查看显卡型号也行，但查到的型号要去官网确认具体的compute_cap值。
3.3 编译与环境变量
make -j 16 make install-j参数是并行编译，建议设为CPU物理核心数减一，避免把机器搞得完全卡死。编译过程大概10-20分钟，取决于机器性能。
编译完，要把安装目录下的可执行文件（默认是lmp）加入PATH环境变量，并把GPU加速需要用到的运行库路径加进LD_LIBRARY_PATH。
export PATH=/opt/lammps-gpu/bin:$PATH export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/lammps-gpu/lib如果你用的是CUDA Toolkit的默认安装路径，还要把CUDA的库路径加进去，不然运行时会报找不到libcudart.so。
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH建议把这些写入~/.bashrc，避免每次登录都重新设置。
3.4 验证安装：跑一个最简测试
进入LAMMPS源码的examples/melt目录，这个例子是最经典的基准测试——面心立方（FCC）晶体原子在Lennard-Jones势下的熔化过程，体系简单，但对验证GPU链路是否打通足够有效。
cd ../examples/melt mpirun -np 1 /opt/lammps-gpu/bin/lmp -sf gpu -in in.melt-sf gpu是关键参数，意思是让LAMMPS把支持GPU加速的风格（style）自动替换为GPU版本。如果没有这个参数，程序就算编译了GPU支持，也还是老老实实在CPU上跑。
如果启动时输出了类似这样的信息，说明GPU链路已经打通：
Device 0: NVIDIA GeForce RTX 4090, 23.8 GB, 0.1% of 596 GFlops available同时，nvidia-smi里能看到一个lmp进程占用了GPU显存。
4. GPU加速性能优化与常见问题排查
编译通过只是第一步，真正跑到满意性能，还要处理一堆运行时问题。这部分我直接整理成“踩坑+方案”的形式，方便大家直接对号入座。
4.1 性能几乎没提升，甚至更慢
这是最常见的问题。排查思路按优先级来：
先看是否真的用上了GPU。运行in.melt时如果屏幕日志里没有出现GPU相关的明细，比如“GPU pack”统计、device信息，那你的-sf gpu可能被输入文件里的pair_style覆盖了。检查输入文件，确认有没有显式指定pair_style lj/cut/gpu这种带gpu后缀的样式，或者用-pk gpu 1命令行选项强制指定。
再看体系规模是不是太小了。GPU加速有“启动开销”，体系太小、计算量不足，GPU还没跑起来，CPU端的数据打包和传输反而成为瓶颈。我大概测过，2000个原子以下的小体系，GPU版很可能比CPU版慢。这种时候建议适当放大体系到1万个原子以上再对比。
最后排查是否存在CPU与GPU负载不均。GPU加速模式下，LAMMPS默认是“部分卸载”策略——一部分力（短程力）在GPU上算，另一部分（长程、基于MPI通信的）仍在CPU上算。你可以在输入文件里加：
pair_style hybrid/overlay lj/cut/gpu 2.5 coul/long 10.0通过neigh_modify delay 0 every 1 check yes等参数调整邻居列表更新频率，找到一个CPU和GPU负载均衡的平衡点。一般从默认开始，逐步调整delay参数，观察单步耗时。
4.2 编译时报错：找不到CUDA或nvcc
这类错误通常是因为CMake没有正确找到CUDA工具包。解决办法是显式指定CUDA路径：
cmake ../cmake -D CMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc \ -D CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES=/usr/local/cuda/include如果你用的是新版CUDA（12.x以上），还要注意CMake版本不能太低，建议3.20+。
4.3 运行时报错：invalid device function
这个报错基本就是GPU架构参数选错了。比如你用sm_80编译，但实际显卡是RTX 4090（计算能力8.9），运行时会报这个。解决办法是回到编译目录，把GPU_ARCH改成正确的值，重新编译安装。
注意，改完CMake参数后，建议把build目录下的CMakeCache.txt删掉再重跑cmake，避免旧的缓存干扰。
cd build rm -f CMakeCache.txt cmake ../cmake -D GPU_ARCH=sm_89 make -j 16 && make installsm_XX这个参数有两层含义：它决定CUDA为哪个架构生成嵌入的机器码（cubin），同时也决定是否触发对应的特殊指令优化。选新架构（如sm_89）编译出的二进制，在旧卡（如sm_70）上是跑不起来的；反过来，用低架构号编译，只在兼容性上安全，性能不是最优。
4.4 多GPU并行与MPI通信冲突
当你有两张以上GPU，或者想跨节点用多卡时，参数组合会变得微妙：
mpirun -np 4 /opt/lammps-gpu/bin/lmp -sf gpu -pk gpu 2 -in in.melt-pk gpu 2表示在2块GPU上分担计算任务。此时需要保证每个MPI进程组能映射到对应GPU上。LAMMPS通常会自动分配，但如果多卡之间有NVLink互联（比如A100+NVLink），可以显式设置：
export CUDA_DEVICE_ORDER=PCI_BUS_ID export CUDA_VISIBLE_DEVICES=0,1如果MPI进程数和GPU卡数不成比例，LAMMPS会通过-pk gpu的neigh/thread等参数做内部调度，但最佳实践是让每个MPI rank对应一张GPU卡，或者一个节点内MPI rank等于GPU卡数的整数倍，避免卡间通信争抢。
还有一个容易忽略的坑：MPI版本和CUDA之间的配合。OpenMPI若没有用CUDA-aware编译，跨节点的GPU直接通信（GPUDirect RDMA）不可用，数据需要经过CPU内存中转，性能损失非常大。这种场景下，确保OpenMPI是--with-cuda编译的，或者改用CUDA-aware的MPI（如Spectrum MPI、Intel MPI），才能发挥多节点GPU加速的价值。
4.5 显存不足与精度选择
体系太大时，LAMMPS会在运行日志里直接报CUDA error: out of memory。此时有几个思路：
- 降低双精度缓冲：LAMMPS GPU包支持混合精度（mixed precision）和单精度（single precision）。默认是混合精度，如果显存还紧，在输入文件里加
-pk gpu 1 force/neigh 0试试纯单精度邻居列表和力的计算，精度损失有时候在可接受范围内。 - 缩小邻居列表剖分宽度：
-pk gpu 1 binsize 0.0让LAMMPS自动选择恰当的网格尺寸。
这里强调：模拟精度是红线，生产任务建议先在CPU上用双精度跑一小段，对比CPU/GPU能量和力的差异，确认在可接受误差范围内，再大规模跑。
5. 生产环境的GPU加速工作流与实战体会
编译安装跑通之后，我实际用的工作流大概是这样的：
先用CPU版的小体系跑通输入文件的正确性，确认能量收敛正常，输出文件格式无误。接着用GPU版跑同样的体系和参数，对比单步耗时。以64万原子的液态金属体系为例，单GPU（RTX 4090）配合8个CPU核（OpenMPI），速度大约是纯CPU（32核）的4-6倍。也就是说，原本需要跑一夜的任务，GPU版可以在晚饭前跑完，这对科研效率的改善是实打实的。
给新上手的朋友几个比较实在的建议：
第一，编译参数记录成脚本文件。我习惯把cmake那一串参数写进一个build_gpu.sh脚本，日期、环境、参数全都注释清楚。过一阵子要重新编译时，不用再回忆当初怎么配的。
第二，不要迷信“开箱即用”。任何版本的LAMMPS，即便官网标注了支持GPU，拿到自己的机器上也可能因为驱动版本、CUDA版本、MPI实现差异而宕机。先跑melt测试，再跑自己体系的1%小样本测试，确认无误后再全量提交。
第三，别忽略CPU侧的算力。很多用户以为用了GPU，CPU就没用了。实际上，GPU加速模式下，CPU还要负责PPPM长程部分的计算、邻居列表的更新、以及IO输出。建议在mpirun -np里给CPU保留足够的进程数，8核到16核为宜。太小，CPU侧瓶颈拖后腿；太大，数据在CPU和GPU之间搬运的通信开销又会抵消收益。这个平衡，要靠你的实际体系和机器配置去调。
最后聊一个容易踩的坑：当你同时在跑多个GPU任务时，显存分配会互相干扰。如果机器上有4张卡，建议用CUDA_VISIBLE_DEVICES给每个任务单独指定卡，而不是让多个任务自动抢占。
这套流程走下来，我对“源码安装+GPU加速”这件事的体会是：门槛其实不高，但对环境细节的要求很高。一旦编译通过、性能达标，这套工具就是你课题组里的“加速器”，值得花一个下午把流程理顺。
本文还有配套的精品资源，点击获取
