📚 课程目录第3章 HPC硬件与集群架构认知

3. HPC硬件与集群架构认知

HFSS 的大规模电磁模型一旦超过单机内存与核数上限，求解过程就不再是“软件设置问题”，而是硬件与集群架构问题。理解 HPC 架构的目的，是让每一次求解任务都能被放到合适的计算资源上：CPU 负责通用稀疏矩阵组装与迭代，GPU 负责高吞吐的稠密代数与频域扫描，内存决定能否装下整个模型，存储决定读写网格与结果的速度，InfiniBand 决定多节点并行时通信是否成为瓶颈，作业调度系统则决定这些资源如何被公平、可复现地分配。

CPU/GPU 异构计算：谁做什么

HFSS 的求解器以 CPU 为主，典型并行方式是 MPI 多进程 + 共享内存多线程。CPU 的优势在于大容量内存寻址、复杂逻辑控制和稀疏矩阵的间接寻址；GPU 的优势在于规则的高吞吐浮点运算。在 HFSS 中，GPU 加速主要作用于频域求解中的稠密矩阵运算和部分直接求解阶段，对参数扫描、频点扫描这类“同一模型多次求解”的场景收益明显。

一个可参考的异构配置示例（示例参数，非实测）：单节点 2 路 32 核 CPU（共 64 物理核）、512 GB DDR5、2 块数据中心 GPU、本地 NVMe 3.2 TB。此时建议 MPI 进程数不超过物理核数，通常取 32～64；每个 MPI 进程绑定到物理核，避免超线程争抢。GPU 数量与 MPI 进程的映射关系需要按求解器版本确认，常见做法是每块 GPU 服务一组进程，而不是让所有进程争用同一块 GPU。

判断是否需要 GPU：若求解时间主要消耗在矩阵求解且模型能放入显存，GPU 收益高；若瓶颈在网格生成、端口扫描或磁盘 I/O，加 GPU 几乎无效。

内存与存储：决定“能不能算”和“算得多快”

内存容量是 HFSS 能否启动求解的硬门槛。经验上，直接求解的内存需求随未知量增长很快，粗略估算可按“未知量 × 每未知量字节数”判断，但更可靠的方法是先用小规模模型试算，记录求解器日志中的峰值内存，再按未知量比例外推。若峰值内存接近物理内存上限，系统会使用交换分区，速度骤降，因此必须预留 20%～30% 余量。

存储分三层：本地 NVMe 用于临时文件与求解中间结果，并行文件系统（如 Lustre、GPFS）用于多节点共享的工程与结果，网络存储用于归档。HFSS 求解过程中会频繁读写临时文件，若临时目录指向慢速网络盘，整体时间会被 I/O 拖垮。建议将 Temp 与 Scratch 目录指向本地 NVMe，结果文件再统一回写到共享存储。

InfiniBand 网络：多节点并行的通信骨架

当模型无法放入单节点内存时，需要用 MPI 跨节点并行。此时节点间通信量随进程数增加而上升，普通千兆以太网的延迟和带宽都无法支撑，必须使用 InfiniBand（IB）。IB 的关键指标是带宽（如 HDR 200 Gb/s、NDR 400 Gb/s）和延迟（微秒级）。HFSS 的 MPI 通信以消息传递为主，对延迟敏感，因此 IB 的 RDMA 能力比单纯带宽更重要。

拓扑上，小集群可用胖树（Fat-Tree），大集群常用 Dragonfly+。对 HFSS 而言，最重要的是让参与同一求解任务的进程尽量落在同一交换机域内，减少跨层跳数。若作业跨多个机架，通信延迟上升，扩展效率会明显下降。可用 ibstat 检查链路速率，用 ib_write_bw 做节点间带宽测试，确认实际带宽达到标称值的 70% 以上再投入生产。

作业调度系统：让资源分配可复现

集群上不能手动登录节点跑 HFSS，必须通过调度系统提交。常见的是 Slurm、PBS Pro、LSF。调度系统的核心作用是：按队列和资源请求分配节点、限制单用户资源、记录作业日志、支持作业数组做参数扫描。提交 HFSS 作业时，需要声明节点数、每节点进程数、内存、GPU 数和运行时限。

# Slurm 提交示例（示例参数）
#SBATCH --job-name=hfss_patch
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=32
#SBATCH --mem=0
#SBATCH --gres=gpu:2
#SBATCH --time=24:00:00
#SBATCH --partition=hpc_gpu

module load ansys/2024R2
ansysedt -ng -batchsolve -distributed \
  -machinefile $SLURM_JOB_NODELIST \
  patch_antenna.aedt

其中 --mem=0 表示使用节点全部内存，--gres=gpu:2 申请两块 GPU。提交后用 squeue 查看状态，用 sacct 查看历史作业的耗时与内存峰值。若作业因内存不足被杀死，日志中会出现 OOM 或求解器异常退出，此时应减少进程数或申请更大内存节点。

把架构认知落到一次求解任务上

假设一个 8 端口阵列天线模型，未知量约 1200 万。先在小模型上测得每百万未知量峰值内存约 6 GB，则总内存需求约 72 GB，单节点 512 GB 足够，无需跨节点。此时优先用单节点 32 个 MPI 进程 + 2 GPU，临时目录指向本地 NVMe。若未知量升到 5000 万，内存需求约 300 GB，仍可单节点，但需把进程数提高到 48～64 并确认内存余量。若未知量超过 1 亿，内存需求超过 600 GB，必须跨节点，此时启用 InfiniBand，用 2 节点 × 32 进程，并观察 MPI 通信占比是否超过 30%。

判断扩展效率的简单方法：记录 1 节点、2 节点、4 节点的求解时间，计算加速比。若 2 节点加速比低于 1.6，说明通信或内存带宽已成为瓶颈，应减少进程数、检查 IB 链路，或改用 GPU 加速替代部分 CPU 进程。作业完成后，用 sacct -j <jobid> --format=JobID,Elapsed,MaxRSS,State 查看实际内存峰值与状态，作为下一次资源申请的参考。

常见误区：把 MPI 进程数设成逻辑核数（含超线程），导致物理核争抢，求解反而变慢；或把临时目录放在网络盘，I/O 等待时间远超计算时间。这两类问题在日志中通常表现为 CPU 利用率低、I/O 等待高。

掌握这四层——CPU/GPU 分工、内存与存储分层、InfiniBand 通信、作业调度——之后，面对任何 HFSS 大规模模型，都能先估算资源需求，再选择单节点还是多节点、是否启用 GPU、临时文件放哪里、如何提交与验证，从而把“能不能算”变成“稳定、可复现地算完”。