超级计算与高性能计算基础
高性能计算（High-Performance Computing，HPC）不是某一台机器或某一个软件，而是一套把计算、网络、存储、调度和应用软件组织起来的方法。本篇按“认识系统 → 选择资源 → 提交作业 → 分析性能 → 优化应用”的顺序，帮助初次接触 HPC 的用户建立整体认识。
比较性能时必须同时确认浮点精度、测试方法和工作负载。理论峰值或单一基准成绩不能直接代表实际应用速度。
1. 什么是超级计算与 HPC
超级计算（supercomputing）通常指利用大规模、高性能计算资源，解决普通计算机难以在可接受时间内完成的问题。超级计算机一般由大量计算节点组成；节点内可以包含 CPU、GPU 或其他加速器，节点之间通过高速网络互连，并配合并行文件系统和作业调度系统共同工作。
高性能计算是实现这类计算的一整套技术与方法，包括并行算法、计算机体系结构、高速网络、存储、系统软件和性能优化等。HPC 不等于“同时使用多台超级计算机”：一台多核服务器、一个计算集群、云端计算资源或一台大型超级计算机，都可以用于 HPC。
“超级计算”和“HPC”在日常表达中经常互换，但侧重点略有不同：前者更常指规模领先的计算系统及其使用，后者更强调完成高性能计算所需的技术体系。
2. 系统架构：从用户到结果
一个 HPC 平台可以理解为由多个层次组成的协作系统。用户在访问层准备代码和数据，通过调度层申请资源，计算层执行任务，网络与存储层负责数据交换，最后在观测与结果层检查任务并保存产物。
用户 / 开发环境
│ SSH、门户或客户端
▼
登录与文件服务 ───── 作业调度与配额
│ │
└──────────┬──────────┘
▼
计算节点（CPU / GPU / 内存）
│ │
高速互联网络 共享存储 / 本地临时盘
└──────┬───────┘
▼
日志、检查点与计算结果
| 层次 | 主要职责 | 用户需要关注的内容 |
|---|---|---|
| 访问层 | 提供 VPN、SSH、门户或客户端入口 | 账号、权限、登录节点用途 |
| 调度层 | 统一分配 CPU、GPU、内存、节点和运行时间 | 分区、队列、配额、优先级、作业状态 |
| 计算层 | 实际运行程序和并行任务 | 核心数、加速器、内存、进程绑定 |
| 通信层 | 支持节点内和节点间的数据交换 | MPI、集合通信、带宽、延迟、拓扑 |
| 存储层 | 保存输入、临时文件、检查点和结果 | 家目录、项目目录、并行文件系统、容量与吞吐 |
| 观测层 | 提供日志、资源使用率和性能数据 | 标准输出、错误日志、作业记账、监控指标 |
登录节点适合编辑脚本、准备环境、查看队列和提交作业，不适合直接运行长时间或高负载计算。实际计算应由调度系统分配到计算节点执行。
3. 工作负载与资源画像
申请资源前，先判断任务的主要瓶颈。一个任务可能同时包含多种特征，但通常会有一个最需要优先解决的部分。
| 工作负载类型 | 典型特征 | 资源选择与优化方向 |
|---|---|---|
| 计算密集型 | 浮点运算占主导，数据复用较好 | 增加合适的 CPU/GPU，优化向量化和并行度 |
| 内存带宽密集型 | 大量读写数组，计算单元经常等待数据 | 关注内存带宽、缓存命中率和数据布局 |
| 通信密集型 | MPI 或多卡同步频繁 | 选择低延迟、高带宽网络，减少同步和通信量 |
| I/O 密集型 | 频繁读取小文件或写入大量结果 | 合理组织文件、批量读写，使用合适的存储层 |
| 参数扫描型 | 多个相互独立的参数组合 | 使用作业数组或批量任务，控制并发数量 |
天气与气候模拟、工程仿真、材料计算、基因组学、数据分析和人工智能训练，都可能在同一平台上运行，但它们对 CPU、GPU、内存、网络和存储的比例要求不同。
4. 如何衡量计算性能
4.1 完成时间与有效吞吐
对大多数科研任务，最直接的目标是缩短从输入准备到结果生成的总时间（time-to-solution）。批处理和数据分析还需要关注单位时间处理的样本、网格、文件或参数组合数量。只有在结果一致的前提下，缩短时间或提高吞吐才算有效加速。
4.2 FLOPS 与理论峰值
FLOPS（Floating-Point Operations Per Second，每秒浮点运算次数）是衡量浮点计算能力的常用单位：
| 单位 | 每秒浮点运算次数 |
|---|---|
| GFLOPS | 10⁹ |
| TFLOPS | 10¹² |
| PFLOPS | 10¹⁵ |
| EFLOPS | 10¹⁸ |
对于结构一致的处理器，可以用下面的简化公式估算理论峰值：
理论峰值 = 处理器数量 × 每颗处理器核心数 × 工作频率 × 每核心每周期浮点操作数
其中，每周期浮点操作数取决于向量宽度、执行单元数量、数据精度和指令类型。一次融合乘加（FMA）包含一次乘法和一次加法，通常按 2 次浮点运算计数。
理论峰值只是理想上限。实际应用还会受到内存带宽、缓存命中率、网络通信、I/O、负载均衡、算法向量化程度和功耗限制等因素影响。现代处理器的频率也会随负载、温度和指令类型动态变化，估算时应注明采用的频率口径。
4.3 内存、网络与 I/O
- 内存带宽决定数据从内存送到处理器的速度，访问密集型程序可能受它限制；
- 网络带宽与延迟决定跨进程、跨节点交换数据的成本，通信密集型程序尤其敏感；
- 存储吞吐与元数据性能决定数据集、检查点和结果能否持续供给计算节点；
- 显存容量与带宽是 GPU 任务能否容纳模型和数据、以及设备是否空等的重要因素。
因此，选择资源时不能只比较核心数量或 FLOPS，还要匹配数据规模、通信模式和 I/O 行为。
4.4 扩展效率
强扩展是在问题规模不变时增加资源，观察完成时间是否下降；弱扩展是在资源增加时同步扩大问题规模，观察单位资源的处理时间是否稳定。常用的强扩展效率可以写成：
扩展效率 = 单资源完成时间 ÷（资源数量 × 多资源完成时间）
当并行度继续增加而效率明显下降时，通常需要检查通信、同步、负载不均衡或 I/O 是否成为瓶颈，而不是继续盲目增加节点。
4.5 HPL 与 TOP500
TOP500 使用 High Performance Linpack（HPL）测试对全球已知的高性能计算系统进行排名。HPL 求解稠密线性方程组，主要反映系统的双精度浮点计算能力：
- Rmax：HPL 测得的最大性能；
- Rpeak：系统的理论峰值性能；
- 效率：通常用
Rmax / Rpeak表示。
HPL 便于跨系统比较，但不能代表所有真实应用的性能。内存访问密集、通信密集、稀疏计算或 I/O 密集型程序可能呈现完全不同的结果，评估系统时还应结合 HPCG、I/O 测试以及目标应用基准。
截至 2026 年 6 月发布的 TOP500 榜单，位列前三的系统是中国深圳的 LineShine（HPL Rmax 2.1984 EFLOPS）、美国劳伦斯利弗莫尔国家实验室的 El Capitan（1.809 EFLOPS）和美国橡树岭国家实验室的 Frontier（1.353 EFLOPS）。榜单每年更新两次，最新排名和数据请以 TOP500 当前榜单 为准。
5. 并行计算模型
并行计算是把一个问题拆分成多个可同时执行的任务。拆分方式需要和算法的数据依赖、通信模式以及平台硬件相匹配。
5.1 共享内存并行
多个线程共享同一节点的内存，常见实现包括 OpenMP、线程池和向量化指令。它适合节点内循环、矩阵运算和预处理任务，但线程数过多可能产生锁竞争、内存带宽争用和线程迁移。
5.2 分布式内存并行
每个进程拥有独立地址空间，通过 MPI 等机制交换消息。它可以扩展到多个节点，但需要处理数据划分、通信、同步和负载均衡。进程数增加后，应重点观察通信时间与计算时间的比例。
5.3 加速器并行
GPU 或其他加速器擅长大量独立、规则的向量和矩阵运算。CPU 负责任务控制和数据准备，加速器负责热点计算；主机与设备之间的数据搬运、显存容量和 kernel 的并行度会影响最终收益。
5.4 独立任务并行
当多个参数组合、样本或文件之间互不依赖时，可以把它们拆成多个独立作业。作业数组通常比在一个作业中串行运行更易于管理，但要控制并发量，避免占满队列或产生大量小文件。
6. 在 HPC 平台上完成一次任务
推荐把任务拆成以下阶段，每一阶段都保留可检查的产物：
- 定义问题：明确输入、输出、精度、可接受误差和目标完成时间；
- 分析资源：估算 CPU/GPU、内存、节点数、存储空间和通信需求；
- 准备环境：确认编译器、MPI、数学库、容器或模块版本；
- 小规模验证：用小数据和短时间测试路径、依赖、结果格式和资源申请；
- 提交作业：通过 Slurm 等调度系统申请最小可行资源；
- 监控运行：查看队列、日志、退出码和 CPU/GPU/内存使用情况；
- 验证结果：检查数值正确性、收敛性、完整性和性能是否达标；
- 归档复现：保存脚本、配置、环境、输入版本、日志、检查点和结果说明。
Slurm 的具体命令和脚本示例请参考 Slurm 使用指南。下面是一个仅用于理解结构的通用示例：
示例中的分区、核心数、运行时间、模块名和路径均为占位内容。提交前必须按当前平台的资源名称、账号权限和实际算例修改。
#!/bin/bash
#SBATCH --job-name=demo
#SBATCH --partition=<partition>
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=<tasks>
#SBATCH --time=00:30:00
#SBATCH --output=logs/%x-%j.out
module load <compiler-or-runtime>
srun ./your_program input.dat
7. 资源选择清单
| 任务情况 | 建议的起点 | 进一步验证 |
|---|---|---|
| 单进程或串行程序 | 1 个计算节点、少量 CPU 核 | 检查是否存在可并行的热点 |
| 单节点多线程 | 1 个节点、匹配线程数和内存 | 检查线程绑定和内存带宽 |
| 多节点 MPI | 少量节点、与进程数匹配的网络资源 | 测试强扩展和通信比例 |
| GPU 加速程序 | 1 张 GPU 起步，确认显存和驱动环境 | 比较 CPU/GPU、单卡/多卡吞吐 |
| 大量独立参数 | 作业数组或批量作业 | 控制并发数并汇总结果 |
| 大数据或高频检查点 | 先确认存储层和 I/O 限制 | 测试顺序读写、文件数量和恢复速度 |
先用小规模资源建立基准，再根据测量结果扩大规模，通常比一次性申请大量节点更容易定位问题。
8. 常见问题与判断思路
8.1 资源申请过大但速度没有提升
可能原因包括程序本身不可并行、通信和同步开销过大、内存带宽不足或负载划分不均。先做单节点和少量节点的基准，再查看扩展效率。
8.2 CPU 或 GPU 利用率偏低
检查输入数据是否及时到达、线程是否绑定、批大小是否合适、进程是否在等待同步，以及是否有频繁的小 I/O。利用率低不一定是硬件故障，可能是流水线中其他环节成为瓶颈。
8.3 作业排队时间过长
申请的节点数、内存或运行时越大，满足条件的空闲资源可能越少。可以根据基准结果拆分任务、缩短单次运行时间、使用作业数组，或咨询管理员了解分区和配额规则。
8.4 结果无法复现
仅保存可执行文件通常不够。应记录代码版本、输入数据版本、编译器和库、启动参数、随机种子、硬件信息以及结果校验方式。
9. HPC 与高性能智算
人工智能是高性能计算的重要应用方向之一，但二者不是同义词。超级计算长期服务于建模与仿真、数据分析和工程计算；人工智能工作负载也可以运行在个人设备、边缘设备或普通云服务器上。
如果任务包含 GPU 训练、模型微调、推理服务或混合精度等内容，可继续阅读高性能智算基础。该文档沿用本篇的“系统架构—性能指标—任务流程”框架，进一步说明加速器、显存、并行训练和模型生命周期。