CPU HPL 实测：从单节点到 80 节点全流程复盘
摘要：本文是一份实测复盘，不是理论讲解。按"单节点调优 → 小规模扩展 → 全规模验收"的流程，给出每一步的 HPL.dat 配置、运行命令和真实结果，并记录全程踩过的坑。
1. 测试环境（脱敏后口径）
| 项 | 配置 |
|---|---|
| CPU | 双路，单路 52 物理核，共 104 核/节点，2.0 GHz |
| 指令集 | AVX-512（每周期 32 双精度 FLOP） |
| 内存 | 1536 GB / 节点 |
| 软件 | Intel oneAPI（MKL + MPI），HPL 2.3 |
| 互连 | 以太网 / InfiniBand 双场景 |
| 单节点理论 Rpeak | 6656 GFlops |
加载 oneAPI 环境（每次测试前必做）
bash
source /opt/intel202*/oneapi/setvars.sh intel64 --force
which mpirun # 确认能找到，否则下面全失败2. 第 0 步：锁频，让测试可复现
HPL 结果对频率抖动非常敏感，跑之前统一设置：
bash
# 所有节点执行
cpupower -c all frequency-set -g performance
# 抽查实时频率与负载
turbostat # 期望看到 Avg_MHz ≈ 2.1GHz，Busy% = 100BIOS 侧三项关键设置
- CPU Power and Performance Policy → Performance（防节能降频）
- Hyper-Threading：测试机建议 off（104 物理核跑满即可）
- Turbo Boost → Enabled
3. 单节点实测：建立基线
用 N_calculator.calculator 算好单节点规模（90% 内存利用率）：
text
N = 430746（90% 内存） Rpeak = 6656.0 GFlops单节点 HPL 运行后，91 节点批量实测结果分布（节选）：
| 节点 | 实测 GFlops | 效率 |
|---|---|---|
| 节点 01 | 6329.63 | 95.1% |
| 节点 31 | 6282.68 | 94.4% |
| 节点 35 | 6433.05 | 96.6%（最高） |
| 节点 40 | 5843.34 | 87.8% |
| 节点 53 | 5792.35 | 87.0% |
| 节点 54 | 5777.46 | 86.8%（最低） |
| 全体平均 | ~6218 | 93.4% |
单节点基线结论：93.4% 平均效率。低于 90% 的节点单独排查。
4. 36 节点实测（中规模）
4.1 HPL.dat 关键参数
text
N : 1000000
NB : 384
P : 12
Q : 6 （P × Q = 72 = 36 节点 × 2 进程/节点）4.2 运行命令
bash
# runme_intel64_dynamic 脚本内部实际执行
mpirun -perhost 2 -np 72 -hostfile hostfile ./runme_intel64_prv4.3 结果
| 项 | 数值 |
|---|---|
| 理论 Rpeak | 239616 GFlops |
| 实测 | 191494 GFlops（1.91494e+05） |
| 效率 | 79.9% |
| 运行时长 | 3481.4 s（约 58 分钟） |
| 残差校验 | PASSED |
5. 80 节点实测（全规模验收）
5.1 HPL.dat 关键参数
text
N : 3145728
NB : 384
P : 10
Q : 8 （P × Q = 80 进程，每节点 1 进程）5.2 运行脚本与命令
bash
export MPI_PROC_NUM=80
export MPI_PER_NODE=1
export NUMA_PER_MPI=2
# 以 2.txt 作为 hostfile（80 个节点地址）
mpirun -perhost ${MPI_PER_NODE} -np ${MPI_PROC_NUM} -f 2.txt ./runme_intel64_prv | tee -a 80cpulinpack.txt5.3 结果
| 项 | 数值 |
|---|---|
| 理论 Rpeak | 532480 GFlops |
| 实测 | 417170 GFlops（4.17170e+05） |
| 效率 | 78.34% |
| 运行时长 | 49746.14 s（约 13.8 小时） |
| 残差校验 | 1.84674053e-03 ...... PASSED |
5.4 完整输出片段
text
T/V N NB P Q Time Gflops
WC00C2R2 3145728 384 10 8 49746.14 4.17170e+05
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)= 1.84674053e-03 ...... PASSED6. 扩展效率曲线（实测汇总）
| 规模 | 理论 GFlops | 实测 GFlops | 效率 | 时长 |
|---|---|---|---|---|
| 1 节点（平均） | 6656 | 6218 | 93.4% | — |
| 36 节点 | 239616 | 191494 | 79.9% | 58 min |
| 80 节点 | 532480 | 417170 | 78.3% | 13.8 h |
三条规律：① 规模越大效率越低（通信开销）；② 78%~80% 是 36~80 节点规模的实际水平；③ 大规模测试时间成本高（80 节点单次约 14 小时），排期要留足。
7. 踩坑记录
7.1 坑 1：未加载 oneAPI，mpirun: command not found
text
./runme_intel64_dynamic: line 86: mpirun: command not found原因：新开的 shell 未执行 source setvars.sh。重新加载后正常：
bash
source /opt/intel202*/oneapi/setvars.sh intel64 --force7.2 坑 2：全节点目录不一致导致运行失败
所有计算节点必须挂载/同步同一份 HPL 目录（可执行文件、HPL.dat、hostfile），否则 MPI 在部分节点起不来。本集群的做法是把管理节点目录通过 NFS 共享给所有 GPU 计算节点后再统一运行。
7.3 坑 3：忽略 residual 校验行
HPL 结果以最后一行 PASSED 为准；若显示 FAILED，说明矩阵求解数值不稳定（多为 N 太大导致内存不足或 NB 不匹配），数据不可用。
8. 结论与复用建议
- 单节点 93.4% → 36 节点 79.9% → 80 节点 78.3%，这条效率曲线可直接用于同类集群的验收预估。
- 全规模测试前务必：锁频 → 加载 oneAPI → 同步目录 → 小规模验证，再跑全规模，避免 14 小时的空跑。
需要理论计算与预估方法，见前两篇：CPU 理论浮点峰值 Rpeak 计算实战、HPL 性能预估：从理论峰值到可交付效率。