CP2K GPU性能实测:单卡到多卡
用P100与V100各三次正式运行比较96原子PBE和9原子HF的墙钟时间,提供逐次数据与完整命令。
阅读本篇目录
申请更多显卡不一定更快。本篇固定物理输入与每卡1个MPI、2个OpenMP线程,比较两种小体系的卡数变化。数据来自2026年10月22日,反映这些输入及当时环境,不作为任意生产任务的速度承诺。
1. 下载与重新画图#
下载CP2K GPU输入、实际输出、CSV与绘图资料包,保存为example.zip:
python3 -m zipfile -e example.zip .
cd cp2k-gpu-practical-data
bash results.sh
bash read.sh
bash plot.sh
资料来自2026年10月22日实际Slurm计算;本次复用结果,不重新跑性能任务。data/是逐次数据,reference-results/保存原生输出,figures/为可重画图片。

每个配置先预热1次,再运行3次;预热不参加中位数。这里记录的是驱动脚本测得的完整墙钟,包含启动与收尾开销,不能与程序内部某一计时项混为一谈。
2. 两个模型#
| 模型 | 实际设置 |
|---|---|
| pbe32 | 32水、96原子,PBE/TZV2P-GTH,280/30 Ry,SCF 1E-7 |
| hfx3 | 3水、9原子,HF与TRUNCATED势,libGint,80/40 Ry,SCF 1E-9、Schwarz 1E-10 |
两者都是功能和操作小例,不用于确定生产网格或基组收敛。特别是HF3的低网格设置不能当作精确交换计算的一般推荐。
3. 实测表#
| 平台 | 模型 | GPU | 中位秒 | 最小–最大秒 |
|---|---|---|---|---|
| P100 | pbe32 | 1 | 102.564 | 102.122–102.597 |
| P100 | pbe32 | 2 | 81.314 | 72.912–81.663 |
| P100 | pbe32 | 4 | 57.756 | 57.662–58.004 |
| P100 | pbe32 | 8 | 56.560 | 56.498–56.642 |
| P100 | hfx3 | 1 | 29.550 | 29.399–29.650 |
| P100 | hfx3 | 2 | 24.303 | 24.166–25.041 |
| V100 | pbe32 | 1 | 68.843 | 68.778–70.038 |
| V100 | pbe32 | 2 | 65.168 | 64.763–65.368 |
| V100 | pbe32 | 4 | 47.518 | 47.356–47.562 |
| V100 | pbe32 | 8 | 56.056 | 55.855–56.107 |
| V100 | hfx3 | 1 | 21.937 | 21.936–21.988 |
| V100 | hfx3 | 2 | 19.631 | 19.466–19.681 |
PBE32中,V100四卡约47.52秒,八卡约56.06秒;P100四卡约57.76秒,八卡约56.56秒。这个小模型继续加卡没有线性收益。HF3只测1、2卡,没有四卡或八卡数据。
cat data/CP2K-GPU-timing-memory-summary.csv
head data/CP2K-GPU-actual-runs.csv
逐次表同时保留SCF步数,卡数变化可能影响迭代过程,比较的是最终完整任务耗时,不是固定迭代的单核函数吞吐。
4. 复现一个配置#
先在新解压目录选择与账号资源相符的提交脚本,例如P100单卡或V100 16GB单卡:
sbatch p100-pbe32-1g.slurm
或:
sbatch v100-pbe32-1g.slurm
这是核时GPU分区的示例脚本。套餐账号应使用yskit中对应账号、平台的CP2K模板,并保持本例MPI/OMP与GPU申请匹配。每个作业只跑一个配置,先预热一次,再正式运行三次;不会自动提交全部配置。新结果可以这样读取:
python3 read-one.py work/p100-pbe32-1g/r1
完整历史比较仍用bash read.sh。不要把Slurm脚本直接改成在登录节点执行,也不要把P100模块用于V100任务。
想比较四卡,可选择对应p100-pbe32-4g.slurm或v100-pbe32-4g.slurm,每次只选择要测的配置。改变卡数时同步修改Slurm的MPI任务数、GPU数和脚本传入值,保持每rank两核与每卡一rank。
5. 怎么理解资源成本#
这个GPU批次没有同条件CPU性能参考,因此不生成新的CPU/GPU加速比。最快配置与最省资源配置也可能不同;应结合账号实际资源与计费方式,看整个Slurm任务的用量。CP2K某段内部时间、脚本墙钟与最终计费时间不能互相冒充。