爬一手好线杆1. 项目概述与核心思路
1.1 这个部署要解决什么问题
这年头装一个分子动力学环境，听起来就是几条命令的事，真上手才明白坑都在细节里。AMBER 24 的部署正好赶上 RTX 5090 这类 Blackwell 架构显卡普及，很多人在这一步栽跟头：要么是编译的时候 CUDA 架构不认识，要么是容器里拿不到 GPU，要么是跑起来之后性能还不如旧卡。这篇文章要解决的问题，就是让你在一台装了 Ubuntu 24.04 的机器上，把 AMBER 24 做成一个可以长期稳定跑生产任务的完整环境，并且保证 5090 能真正吃到 GPU 加速。
AMBER 24 是目前分子动力学模拟领域非常主流的一套软件，包含 AmberTools 工具包和 PMEMD 分子动力学引擎。它适合做蛋白质、核酸、小分子配体这些体系的显式水模型模拟，也能跑隐式溶剂模型、自由能计算、增强采样这类任务。无论你是做计算化学、结构生物学还是药物设计，只要涉及微观体系的动态过程，AMBER 24 基本上都在候选名单里。生产环境部署这个词听起来有点重，但放在实际场景中就是：这段环境不能只在你自己的笔记本上能跑，还必须能在服务器上被多个人、多批次任务稳定调用，数据不能随便丢，日志要能查，GPU 要能分。
适合看这篇内容的人，我大概分三类。第一类是刚接触 AMBER 的新手，想快速在一张 5090 上把官方示例跑起来；第二类是有一定经验，但准备把原来 AMBER 20 或 AMBER 22 迁移到 AMBER 24，顺便换到 Blackwell 显卡；第三类是实验室或者小团队的运维角色，需要把 AMBER 24 容器化，接入现有调度系统，让使用者不用关心底层编译问题。下面内容我会按这三类需求铺开。
1.2 为什么用 Docker 而不是直接在裸机编译
很多老的 Amber 用户有个习惯，拿到源码后直接在这台机器上 ./configure、make，一路装到 /opt/amber24，然后所有作业都靠环境变量去切换。这种方式不是不能用，但到了生产环境、尤其是有多张 5090 的服务器上，会暴露几个很现实的问题。
第一是编译器版本漂移。AMBER 24 对 C、C++、Fortran 编译器的要求比较具体，GCC 版本太新或太老都可能触发奇怪的问题。服务器上往往还要跑别的项目，比如 PyTorch、GROMACS、OpenMM，各自的依赖千差万别。如果你今天为了满足 AMBER 把系统 GCC 升级了，明天另一个项目可能就编不过了。Docker 的好处是把这个版本依赖性锁在镜像里，宿主机的环境再怎么变，容器内部始终是同一个工具链。
第二是 CUDA 和驱动的关系。5090 属于 Blackwell 架构，Compute Capability 是 12.0，需要新版本 CUDA Toolkit 和驱动才能支持。AMBER 24 里的 CUDA 加速代码如果要生成 sm_120 的 SASS，必须用支持 Blackwell 的 CUDA 版本。直接在宿主机上装新版 CUDA 很容易污染现有环境，尤其是那些已经装过 CUDA 11 的机器。容器把 CUDA Toolkit 放在镜像里，宿主机只提供 NVIDIA 驱动和运行时入口，两边互不干扰。
第三是复现性。生产环境最怕的是“昨天还能跑，今天突然不行了”。裸机环境依赖是隐性的，系统更新、apt 升级、另一个用户改了个库路径，都可能导致 AMBER 行为异常。容器镜像可以打 tag，哪个版本能稳定产出，就固定用哪个 tag。出了问题，直接回滚镜像比回滚系统简单得多。
这不是说裸机安装毫无价值。如果你只是单机自用、不需要考虑多用户隔离，裸机有时更省事。但本文面向的是生产环境，所以下面的流程默认采用 Docker 方案，同时我也会解释每一步在裸机上对应的等价操作。
1.3 硬件选型与 5090 的特殊性
RTX 5090 是目前消费级显卡里算力很猛的一张卡，显存 32GB，理论上跑中小型蛋白质体系的水盒子模型没有太大压力。但它的特殊性不只是快，而是架构变了。Blackwell 对应的 Compute Capability 是 sm_120，这意味着老的、仅为 Ampere 或 Ada 架构编译的 CUDA 二进制文件，在 5090 上是跑不了的，必须重新编译并显式指定架构。
我见过一种典型错误：在 4090 上装好的 AMBER 24，把整个环境复制到 5090 机器之后，pmemd.cuda 一启动就报 no kernel image is available for execution on the device。原因就是运行时内核镜像里没有 sm_120。所以“5090 可用”不是一句虚话，而是要在编译、容器运行时、驱动版本三个层面同时满足要求。
另外要提醒的是，消费级显卡虽然算力不差，但显存带宽和 ECC 等特性跟专业计算卡不一样。如果你们组的任务是很长时间的大规模生产模拟，预算允许还是建议上 H 系列或 RTX 专业卡。但如果你手里正好只有 5090，这篇文章里的方案完全够用。需要注意 5090 的功耗高，多卡机器一定要确认电源余量和散热条件，否则跑起来的性能会很不稳定。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与基础依赖
2.1 宿主机系统和 NVIDIA 驱动
我推荐宿主机系统用 Ubuntu 24.04 LTS。原因是 24.04 对 Docker、NVIDIA Container Toolkit 和 Blackwell 显卡的驱动支持都比较到位，而且用户基数大，出问题容易搜到答案。系统装好之后，第一件事是更新内核和相关包，然后安装 NVIDIA 驱动。
关于驱动版本，这里有个非常关键的判断：AMBER 容器里装的 CUDA Toolkit 版本，不能高于宿主机驱动对应支持的最高 CUDA 版本。一般来说，CUDA 12.8 或更高版本对 Blackwell 支持比较完整，所以驱动至少要选 570 或更新的分支。为了避免出错，我建议直接用 Ubuntu 官方源里带的最新驱动，并同时安装 nvidia-driver-570 这一类明确版本号的包。
bash复制sudo apt update
sudo apt upgrade -y
sudo apt install -y nvidia-driver-570
sudo reboot
重启后运行 nvidia-smi，如果能正常列出 5090 的信息，说明驱动没问题。这里还要注意，不要随便从 NVIDIA 官网下载一个 .run 安装包直接装，除非你很清楚自己在干什么。.run 包和系统自带的开源驱动容易打架，最后经常是花半天排查一个本来很简单的环境。
驱动验证通过之后，建议顺手装一下这几个基础工具，后面排查问题会用到：
bash复制sudo apt install -y build-essential git wget curl
2.2 安装 Docker 与 NVIDIA Container Toolkit
Ubuntu 24.04 上安装 Docker 有两种常见方式。一种是直接用官方 apt 仓库，另一种是安装 Docker Desktop。生产环境我建议用前者，因为更加轻量，也更容易被脚本化。下面是一套我实测稳定的安装流程。
bash复制sudo apt update
sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
然后添加 Docker 软件源。Ubuntu 24.04 的代号是 noble，所以源里要用 noble 这个版本标识：
bash复制echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
noble stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
接着安装 Docker 本体，并把当前用户加入 docker 组：
bash复制sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER
newgrp docker
验证 Docker 是否正常工作：
bash复制docker run --rm hello-world
GPU 要让容器访问，光有 Docker 还不够，必须安装 NVIDIA Container Toolkit。这个工具负责在容器启动时注入 GPU 设备、驱动库和运行时环境。安装流程如下：
bash复制curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
安装完成后配置 Docker 运行时默认使用 NVIDIA Container Runtime：
bash复制sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
验证 GPU 能否在容器里使用，直接跑一个基础 CUDA 镜像：
bash复制docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi
如果输出里能看到 5090 和驱动版本，说明 Docker、NVIDIA Container Toolkit、GPU 驱动这条链路已经通了。这个验证很重要，很多 AMBER 容器内无法使用 GPU 的问题，其实在这一步就已经埋下了。
2.3 镜像选择：基于 NVIDIA CUDA 镜像构建
AMBER 24 没有官方 Docker 镜像，至少我目前没看到维护完善的版本。所以我们需要自己构建，推荐的基础镜像是 nvidia/cuda:12.8.0-devel-ubuntu24.04。这个镜像自带 CUDA 编译器 nvcc、完整头文件、Fortran 和 C/C++ 工具链，省去很多手工安装的麻烦。
为什么用 devel 而不是 runtime？因为 AMBER 编译时需要 CUDA 的头文件和 nvcc，runtime 镜像里没有这些。如果只是跑编译好的二进制，可以用 runtime，但我们这里要自己编译 sm_120 支持，所以必须用 devel 镜像。
不推荐直接用 conda 的 ambertools 包作为生产环境主引擎。conda 的 AmberTools 确实能装，但 pmemd 的 CUDA 版本、OpenMPI 配置可能不适合你的具体集群环境。用 conda 做辅助工具链可以，比如跑 antechamber、parmchk2 这类预处理命令，但真正的生产模拟我还是建议用源码编译的 PMEMD。
3. AMBER 24 安装与编译细节
3.1 从源码编译：拿到源码包后先看这两个文件
AMBER 24 的完整版本需要商业授权，源码包解压后一般叫 amber24_src.tar.bz2。如果你是 AmberTools 用户，也可以单独获取 AmberTools 24 的源码。生产环境里我强烈建议直接用完整版源码编译，而不是依赖别人打包好的二进制。
解压后不要急着跑配置命令，先花五分钟看 README.md 和 configure2 里的说明。AMBER 24 的构建系统虽然比老版本友好，但不同版本之间的编译选项仍有变化。比较关键的是确认它默认支持的 CUDA 架构列表里有没有 sm_120。如果没有，就说明你拿到的版本需要打补丁或手动指定架构。
bash复制tar xjf amber24_src.tar.bz2
cd amber24
less README.md
grep -rn "sm_120" ./cmake ./configure2 2>/dev/null | head -20
如果 grep 结果为空，也不用慌，可以先检查 configure2 里的 CUDA_ARCH 相关变量是不是支持外部传入。AMBER 24 的配置系统一般允许通过环境变量或 -DCUDA_ARCH=sm_120 这样的方式覆盖默认架构列表。
3.2 编译器、CUDA 和 GCC 的版本匹配
这是整个部署中最容易出问题的一环。AMBER 24 需要 C、C++ 和 Fortran 编译器，编译器版本必须和 CUDA Toolkit 兼容。CUDA 12.8 官方支持 GCC 最高到 13.x，Ubuntu 24.04 默认的 GCC 13 正好在范围内。如果你系统里默认 GCC 是 14 或更高，建议先用 update-alternatives 切到 GCC 13，避免编译到一半出现莫名其妙的模板报错。
可以用下面命令安装并切换 GCC 版本：
bash复制sudo apt install -y gcc-13 g++-13 gfortran-13
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-13 130
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-13 130
sudo update-alternatives --install /usr/bin/gfortran gfortran /usr/bin/gfortran-13 130
Fortran 编译器在 AMBER 编译里很重要，因为很多数值核心是 Fortran 写的。gfortran 版本不匹配会导致链接阶段报一堆 undefined reference。所以这一步不要偷懒。
3.3 配置编译选项：重点指定 sm_120
AMBER 24 的配置命令大概是这样的形式：
bash复制cd amber24
export AMBERHOME=$(pwd)
./configure --help | less
不同的分支选项很多，但生产环境核心是这几个：
-cuda或-cuda_arch表示启用 CUDA。-mpi表示启用 MPI 并行。-noX11表示不依赖 X11 图形库。-rhel8或类似的发行版选项，用于兼容 RedHat 系库路径。
如果你用的 AMBER 24 版本已经支持外部架构覆盖，可以这样配置：
bash复制./configure -mpi -cuda -noX11 gnu -DCUDA_ARCH="sm_120"
如果你的版本不接受 -DCUDA_ARCH，可以试着在 configure 之前设置环境变量：
bash复制export CUDA_ARCH="sm_120"
./configure -mpi -cuda -noX11 gnu
配置成功后会提示你接下来运行 make 和 make install。这一步耗时比较长，视机器性能可能在 20 分钟到两个小时之间。建议用 make -j$(nproc) 并行编译，但如果你内存不够，-j 数值不要太大，否则很容易 OOM。
编译完成后，可以检查二进制是否真的包含 Blackwell 架构的 kernel：
bash复制cuobjdump --list-elf $AMBERHOME/bin/pmemd.cuda | grep sm_120
如果输出里有 sm_120，说明 5090 可用的前提已经满足。
3.4 安装后的功能测试
编译安装完成不等于环境就绪，必须先跑 AMBER 官方测试集。完整测试要跑很久，生产环境可以先跑 GPU 相关的几个关键测试。进入 $AMBERHOME/test 目录，选择 pmemd 下的 GPU 测试：
bash复制cd $AMBERHOME/test
make test.pmemd.gpu
注意看最后的 PASS/FAIL 统计，失败的 case 一定要追踪原因。最常见的问题是 MPI 环境没配对，或者 CUDA 架构覆盖导致某些 case 走了错误分支。测试通过后，再拿自己的体系做一次短时间模拟，确认能量和温度没有异常，才算真正进入可用状态。
4. 生产环境配置与性能调优
4.1 容器化：Dockerfile 与实践
编译好的 AMBER 24 是在一个临时容器里完成的，但如果这个容器本身不保留，下次又要重新编译，那就没有什么“生产环境”可言。正确的做法是把编译过程和运行依赖固化进一个 Dockerfile，做成可重复构建的镜像。
下面是一个最小化的 Dockerfile 思路，用多阶段构建来减小最终镜像体积：
dockerfile复制FROM nvidia/cuda:12.8.0-devel-ubuntu24.04 AS builder
ARG AMBER_SRC=amber24_src.tar.bz2
COPY ${AMBER_SRC} /opt/
RUN apt-get update && apt-get install -y bzip2 gcc-13 g++-13 gfortran-13 \
&& cd /opt \
&& tar xjf ${AMBER_SRC} \
&& export AMBERHOME=/opt/amber24 \
&& cd $AMBERHOME \
&& ./configure -mpi -cuda -noX11 -DCUDA_ARCH="sm_120" gnu \
&& make -j$(nproc) \
&& make install
FROM nvidia/cuda:12.8.0-runtime-ubuntu24.04
COPY --from=builder /opt/amber24 /opt/amber24
ENV AMBERHOME=/opt/amber24
ENV PATH="$AMBERHOME/bin:$PATH"
实际使用中，构建阶段还要处理一个问题：make install 会调用 perl 脚本，而基础镜像里可能没有 perl 和 make，别忘记在 builder 里安装 make perl python3 这些基础依赖。另外，Dockerfile 里的 COPY 命令会引入权限变化，最后建议把 $AMBERHOME 的属主改成容器内的非 root 用户。
4.2 运行容器：镜像 tag 和挂载目录
镜像构建好后，建议按照语义化版本打 tag，比如 amber24-cuda12.8-sm120:1.0.0。不要只打 latest，因为时间一长你就不记得当前镜像是基于哪个代码版本、哪个测试结果构建的。生产环境最怕“看起来没问题，但不知道具体版本”的状态。
运行一个交互式容器，可以这样：
bash复制mkdir -p /data/amber_projects
docker run -it --rm \
--gpus all \
--name amber24_prod \
-v /data/amber_projects:/data/workspace \
-w /data/workspace \
--user $(id -u):$(id -g) \
amber24-cuda12.8-sm120:1.0.0 \
bash
参数解释一下。--gpus all 让容器访问所有 GPU，也可以写成 --gpus '"device=0,1"' 来控制具体哪几张卡。-v 把宿主机数据目录挂到容器里，这是生产环境最关键的一步，所有输入输出文件应该放在宿主机统一管理，容器本身只负责运行，这样即使容器删了数据也不会丢。--user 用当前用户运行，避免容器内 root 生成的文件让宿主机无法处理。
在容器内可以用这样的命令确认 GPU 可见性：
bash复制nvidia-smi
$AMBERHOME/bin/pmemd.cuda -O \
-i md.in -p complex.prmtop -c complex.inpcrd -o md.out -x md.nc -r md.rst
如果输入文件路径都在挂载目录下，输出也会直接写到宿主机，之后交给其他流程分析就行了。
4.3 多卡并行与 MPI 配置
AMBER 24 支持多个 GPU 并行跑同一个体系，常见用法是 pmemd.cuda.MPI 配合 mpirun。生产环境里需要特别注意 MPI 和 CUDA-Aware MPI 之间的配合。如果只拿 OpenMPI 默认编译，多卡访问容易变成数据在 CPU 内存拷贝，性能会很差。
在 configure 的时候，可以额外加上 -mpi，并确认 mpirun 路径来自 AMBER 自带或系统里与 InfiniBand/网卡兼容较好的实现。对于单机多卡，最稳的方案是用 mpirun -np 2 pmemd.cuda.MPI，并限制每个进程绑定到一张卡：
bash复制mpirun -np 2 --bind-to none $AMBERHOME/bin/pmemd.cuda.MPI \
-O -i md.in -p complex.prmtop -c complex.inpcrd -o md.out -x md.nc -r md.rst
--bind-to none 可以在部分 MPI 实现里避免 CPU 绑定导致的不必要切换。真正要优化 CPU affinity，应该根据 NUMA topology 仔细设置，而不是一刀切用 none。
4.4 作业调度和资源限制
如果团队超过三个人用 AMBER，手工开容器管理任务会失控。生产环境建议接入 SLURM 或 PBS 这类调度器。思路是让调度器负责分配 GPU 资源，Docker 负责隔离运行环境。
在 SLURM 节点配置里，最好把 GPU 资源用 Gres 暴露出来，再通过 --gres=gpu:1 或者指定卡号来提交作业。用户拿到节点资源后，再由 wrapper 脚本启动 Docker 容器。这个 wrapper 可以包含以下内容：
bash复制#!/bin/bash
#SBATCH --gres=gpu:1
#SBATCH --mem=16G
export CUDA_VISIBLE_DEVICES=$SLURM_JOB_GPUS
docker run --rm \
--gpus "\"device=$CUDA_VISIBLE_DEVICES\"" \
-v /data/amber_projects:/data/workspace \
amber24-cuda12.8-sm120:1.0.0 \
bash -c "source $AMBERHOME/amber.sh && pmemd.cuda -O -i md.in -p complex.prmtop -c complex.inpcrd -o md.out"
CUDA_VISIBLE_DEVICES 这个环境变量非常重要。即使 Docker 把物理 GPU 都暴露给容器，AMBER 也会根据 CUDA_VISIBLE_DEVICES 来决定用哪张卡。调度器分配了两张卡，就只让这个任务看见两张卡，避免互相争抢显存。
4.5 数据备份与文件系统
AMBER 生产任务的输出绝大多数是轨迹文件，体积动辄几十 GB，备份策略必须提前设计好。不能只靠 docker cp 这种临时手段，应该让容器直接写到挂载的共享存储里，再由定时任务做增量备份。
对于关键输入文件（拓扑、初坐标、参数文件），建议用 restic 或 rsync 每天增量同步到备份盘。对轨迹这类大文件，可以只保留最近三天的原始文件，更早的转成压缩格式或直接归档。不要贪心到把所有轨迹都留到本地，否则磁盘迟早会被塞满。
还有一个容易被忽略的点：Docker 容器之间的临时文件如果写在镜像可写层，容器一删就没了。生产环境一定要在容器启动时设置 --tmpfs /tmp 或挂载独立 tmp 目录，避免大矩阵临时文件把镜像层撑大。
5. 常见问题与排查技巧实录
5.1 “no kernel image is available on the device”
这个报错是 5090 用户最常碰到的。它本质上是编译产物里没有包含适合当前 GPU 的 SASS 或 PTX。解决思路很直接，重新编译并显式携带 sm_120。但要注意，重新编译前需要清掉之前的构建缓存，否则编译系统可能认为没变化而跳过核心 CUDA 代码。
bash复制cd $AMBERHOME
make clean
make uninstall 2>/dev/null || true
./configure -mpi -cuda -noX11 -DCUDA_ARCH="sm_120" gnu
make -j$(nproc)
make install
我用 -DCUDA_ARCH="sm_120" 这种写法，是因为 AMBER 24 较新版本支持从外部传入 CMake 定义。如果你的版本不识别这个参数，可以反过来在 configure 脚本里搜索 CUDA_ARCH 相关的帮助文档，不一定只有一个写法。还有一种做法是同时写上 sm_120 和低阶架构：
bash复制-DCUDA_ARCH="sm_120 sm_100 sm_90"
这样才能保证同一份编译产物既能在 5090 上跑，也能在 A100/H100 这类旧架构专业卡上跑。
5.2 容器无法识别 GPU
如果 Docker 里 nvidia-smi 报错说找不到 GPU，八成不是 AMBER 的问题，而是容器运行时没有配置对。先看宿主机 nvidia-smi 是否正常，再看 Docker 运行时是否已经注册了 NVIDIA Container Runtime：
bash复制docker info | grep -i runtime
如果 runtime 列表里没有 nvidia，说明 nvidia-ctk runtime configure 没生效，需要重新执行一次，并重启 Docker。如果是 rootless Docker 模式，配置方式略有不同，需要在用户态重新配置 runtime。
还有一个容易踩的坑：只装了 nvidia-container-toolkit 但没装 nvidia-driver，或者驱动版本太老。容器内的 CUDA 库会尝试和宿主机驱动通信，驱动版本不够新就会拒绝启动。这时看 dmesg 或 journalctl 通常会留下 NVRM 相关的提示，按驱动版本升级即可。
5.3 编译过程中 Fortran 链接报错
我见过不少人在 make 阶段卡在类似 undefined reference to __kmpc_for_collapse 的串并行混合代码上。这个问题多是因为 OpenMP 运行库没有正确链接。解决方法是确保 configure 时统一使用同一个编译器系列，比如都用 GNU 的 gcc/g++/gfortran，不要出现 C 文件用 GCC、Fortran 文件用 Intel 的情况。
另外，如果机器上装了 Anaconda 并把它加进了 PATH，编译时可能误用 conda 里的旧版库，导致链接冲突。建议在 configure 和 make 之前先把 conda 的 PATH 临时去掉：
bash复制export PATH=$(echo "$PATH" | sed 's#/path/to/conda/bin:##')
这种环境变量污染在 Linux 服务器上非常常见，尤其是那些用 Miniconda 管理 Python 环境的团队。
5.4 5090 性能反而比 4090 低
如果部署完成后跑 benchmark，发现 5090 耗时比 4090 还长，先不要怀疑卡的问题，多半是跑在了错误的状态里。第一种可能是 AMBER 的二进制里没有 sm_120，走的可能是 PTX 的即时编译路径，性能会打折扣。第二种可能是 GPU 没有跑在正确的功耗档位上，查看 nvidia-smi -q -d POWER 可以确认。
最常见的原因其实是 ECC、功耗限制或散热。5090 在满载时发热很猛，如果机箱风道不够，它会自行降频。用 nvidia-smi dmon -s pucvmet 监控一段时间，观察 GPU 利用率、温度和功耗是否保持稳定。如果温度超过 85 度并且功耗震荡厉害，就要从散热下手，而不是怀疑软件配置。
第三种可能是 AMBER 的输入体系太小，不足以并行填满整个 GPU。小蛋白配体体系在 5090 上可能不如一两张老中端卡快，这是并行效率问题，不代表卡不行。生产环境判断性能，建议用官方 benchmark：在 AMBER 的 benchmarks 目录下选择 GPU 相关的体系，至少跑 100 步然后比较 ns/day，别用自己随意凑的输入文件当唯一标准。
5.5 避坑速查表
| 问题 | 排查方向 | 解决方案 |
|---|---|---|
| PMEMD 启动报 no kernel image | 二进制内是否有 sm_120 | 重新编译并指定 CUDA_ARCH |
| 容器里 nvidia-smi 失败 | Docker runtime 配置 | 重跑 nvidia-ctk runtime configure |
| 编译链接 undefined reference | 编译器不统一或 PATH 污染 | 统一 gcc/g++/gfortran，清理 conda PATH |
| 性能远低于预期 | GPU 功耗/温度/核心占用 | 监控温度和功耗，检查是否满载 |
| 多卡任务只能用到一张卡 | CUDA_VISIBLE_DEVICES 没设置 | 调度器里显式传给容器 |
| 任务跑一半容器被删数据丢失 | 数据没挂载或写在容器层 | 使用 -v 挂载数据目录 |
| 用 Xshell 连不上虚拟机 | IP 地址和 SSH 服务状态 | 确认 ip addr 网段和 systemctl status ssh |
关于 Xshell 连不上 Ubuntu 虚拟机这条，虽然它不影响 AMBER 本身，但很多人在部署初期就卡在这。最常见的不是密码错，而是虚拟机里根本没有启用 SSH 服务。Ubuntu 24.04 默认不一定装了 openssh-server，先执行 sudo apt install -y openssh-server，再确认 ip addr 里的地址是不是和你在同一网段。如果虚拟机用的是 NAT 网络，宿主机也要保证端口转发配置正确。
最后再分享一个小技巧
我在实际部署 AMBER 24 的时候，习惯先把整个 PMEMD 二进制和 sm_120 的检查命令写进一个脚本，每次构建完成后自动跑一遍。这样后来任何一次镜像重建或者环境升级，我都能在几分钟内确认核心 GPU 路径没被破坏。你不需要等到用户报错才动手，一个小脚本能省掉很多半夜排查的时间。
另外，5090 的部署环境变化很快，驱动、CUDA、AMBER 三者之间的版本匹配可能在你看到这篇文章的时候已经更新。建议把“以 AMBER 源码包里的 release notes 为准”当成第一原则，网上任何博客包括这篇，都只能帮你缩短排查时间，不能替代官方说明。祝你的 AMBER 24 一次编译通过，5090 稳定满载。