VASP 算得太慢？先排查这 8 项

加核数是最贵的解决方案，也常常是最没用的那个。先说结论：在动手买机器之前，有八件事值得花一小时查一遍，其中至少三件的收益比换机器更大。

2026-10-17 · 约 9 分钟读完

先建立一个判断基准

不要凭"感觉慢"。打开 OUTCAR，找到每一步的时间分解：

grep -A2 "LOOP:" OUTCAR | tail -20
grep "Total CPU time used" OUTCAR

VASP 每完成一个 SCF 步会打印各阶段耗时。看两件事：哪一段占比最高（决定优化方向）、每步耗时是否稳定（突然跳变说明是内存或 IO 问题，不是算力问题）。

1. 内存够不够（最高频的原因）

如果机器在 swap，速度会掉一个数量级，而且 OUTCAR 里看不出任何异常——它只是"慢"。判定方法：

free -g          # 看 available 是否接近 0
vmstat 1 5       # 看 si/so 两列是否长期不为 0
dmesg | grep -i oom

用 内存估算器算出你这个体系的波函数体积，对照实际占用。经验值：每个 MPI 进程至少 2 GB，低于这个数基本都在换页。

2. NCORE 与 KPAR 设错了

这是 VASP 最常见的一处"配置浪费"：

• NCORE 控制每个轨道分给几个核并行。它应当是单个节点核数的因数，常见取 2～4。跨节点时不要设得比单节点核数还大。
• KPAR 控制 k 点并行。只有当 k 点数能被 KPAR 整除、且 k 点数足够多时才有收益。k 点少于 4 个却开 KPAR=4，通常更慢。

# 64 核、12 个 k 点的常见组合
NCORE = 4
KPAR  = 4

3. 核数已经超过了有效并行区

VASP 的加速比在某个核数之后会塌陷，塌陷点取决于体系大小（见 配置清单）。判定方法很简单：同一输入分别用 16 / 32 / 64 核各跑 10 个电子步，记录墙钟。如果 64 核只比 32 核快 10%，多出来的核全是浪费。

4. BLAS 线程与 MPI 抢核

MKL 默认可能给每个进程开满 OpenMP 线程，于是 64 个 MPI 进程各自再开 16 个线程，把 CPU 挤爆。常见现象是 top 里负载是核数的好几倍。

export OMP_NUM_THREADS=1
export MKL_NUM_THREADS=1

只有在"进程数 × 每进程核数 = 物理核数"的混合并行模式下才调整这个值。

5. 磁盘 IO 拖后腿

三个信号：LWAVE=.TRUE. 每个离子步都写几 GB 的 WAVECAR；scratch 放在机械盘或低 IOPS 的云盘上；结果文件写到了网络存储。iostat -x 1 看 %util 是否长期接近 100。

处理方式：非必要不开 LWAVE；WAVECAR/CHGCAR 放本地 NVMe；中间文件不要写到挂载的网络盘上。

6. k 点网格设得太密

k 点数量是最容易被"想更精确"毁掉的参数。k 点从 4×4×4 提到 8×8×8，计算量增加 8 倍，而总能量往往只差几 meV。做一次收敛性测试，选"再加密也几乎不变"的那个密度。

7. 初始结构太离谱

从实验晶格直接放松，或从别处拿来的结构没有做预优化，会让电子步数从 30 步涨到 150 步。先在低精度（EDIFF=1E-4、PREC=Normal）下粗优化，再提高精度跑最终结果，总时间常常能省一半。

8. 编译选项没匹配 CPU

用通用 -O2 编译的二进制，和用 -O3 -xHost 加 MKL 优化过的版本，速度能差 2～3 倍。云上尤其常见：直接用网盘下载的预编译包，指令集和实例 CPU 不对应。自己编译一次（步骤见 编译指南），一次性收益。注意别在 AVX512 机器上编译、拿到老机器上跑，那是非法指令。

排查完之后：什么情况才该加机器

如果排查完确认是算力不够，下一步是算钱：先用机时估算器算出总 core-hour，再对照三种租法的月成本。很多人的结论会出乎意料——一个 128 原子的优化总共只要几百元机时费，比买一台机器便宜得多。