高性能智算基础
高性能智算（High-Performance Intelligent Computing）是面向人工智能模型训练、微调、推理和科学智能任务，综合使用 CPU、GPU 或其他加速器、高速网络、共享存储与资源调度系统的一套计算技术体系。
这篇文档沿用高性能计算基础的思路，重点回答四个问题：智算系统由什么组成、不同任务需要什么资源、如何衡量真实性能，以及怎样把一次实验稳定地运行和复现起来。
智算性能不能只看芯片宣传中的峰值数字。实际结果通常同时受计算精度、显存容量、显存带宽、节点间通信、数据读取速度、并行方式和软件实现影响。
1. 从 HPC 到高性能智算
传统高性能计算主要解决数值模拟、工程仿真、科学计算和大规模数据处理问题；智算则更多面向机器学习和深度学习任务。二者在硬件和系统层面有大量共通之处，都依赖并行计算、作业调度、高速互联和共享存储。
可以把 HPC 看作一套通用的基础设施和方法，把智算看作在这套基础设施上运行的一类重要工作负载。天气预测、材料设计和基因组分析等任务，可能同时包含数值模拟、数据处理和机器学习模型，需要在同一个集群中混合使用 CPU 与 GPU 资源。
| 对比维度 | 传统 HPC 任务 | 智算任务 |
|---|---|---|
| 常见目标 | 数值模拟、工程仿真、科学计算 | 模型训练、微调、推理、向量计算 |
| 主要计算 | 浮点运算、线性代数、偏微分方程 | 矩阵乘法、卷积、注意力、张量运算 |
| 常用精度 | FP64、FP32 | FP32、TF32、FP16、BF16、INT8 等 |
| 并行方式 | MPI、多线程、向量化 | 数据并行、模型并行、流水线并行 |
| 关注资源 | CPU、内存、网络、存储 | 加速器、显存、互联、存储和调度 |
2. 智算系统架构
智算平台不只是 GPU 服务器。一次训练任务需要数据、软件、资源和计算设备形成完整流水线：
数据集 / 模型 / 配置
│
▼
数据准备与缓存 ── 环境与软件栈 ── 作业调度与配额
│ │ │
└──────────────┼───────────────┘
▼
计算节点（CPU + GPU + 内存）
│ │
节点内互联 节点间高速网络
└──────┬───────┘
▼
日志、检查点、评估与结果
| 层次 | 主要组成 | 需要回答的问题 |
|---|---|---|
| 数据层 | 原始数据、预处理数据、数据集索引 | 数据是否完整、格式是否适合高并发读取 |
| 软件层 | 驱动、CUDA/运行时、框架、通信库、容器或模块 | 版本是否匹配、算子和加速器是否可用 |
| 调度层 | 分区、队列、账户、配额和作业系统 | 需要多少设备、内存和运行时间 |
| 计算层 | CPU、GPU/加速器、内存、显存、本地临时盘 | 模型和 batch 能否放入设备、计算是否充分 |
| 通信层 | PCIe/NVLink 等节点内互联、节点间网络 | 多卡同步和参数交换是否成为瓶颈 |
| 存储层 | 家目录、项目目录、共享并行存储、缓存盘 | 数据、检查点和日志放在哪里最合适 |
| 结果层 | 指标、日志、模型、检查点和版本记录 | 结果能否验证、恢复和复现 |
2.1 计算节点
计算节点通常包含 CPU、系统内存、一个或多个 GPU 或其他加速器，以及本地磁盘和高速网络接口：
- CPU：负责任务控制、数据预处理、系统调用和部分计算；
- GPU/加速器：擅长大规模并行的向量和矩阵运算，是深度学习训练的主要计算设备；
- 内存：保存数据集、程序、缓存和 CPU 侧中间结果；
- 显存或设备内存：保存模型参数、输入张量、梯度和中间激活值；
- 本地盘：适合缓存数据和临时文件，但不应默认当作永久存储。
模型参数、梯度、优化器状态和中间激活值会共同占用显存。估算资源时不能只看参数量，还要考虑 batch size、序列长度、训练精度和是否保存激活用于反向传播。
2.2 高速互联
单卡任务主要受设备自身性能影响；多卡和多节点任务还需要频繁交换梯度、参数或中间结果。分析多卡任务时，需要同时关注设备之间的互联、节点之间的网络、通信拓扑以及通信与计算能否重叠。
GPU 利用率不高时，原因可能不是算力不足，而是数据搬运、梯度同步、网络拥塞或进程绑定不合理。扩展任务前，应先用小规模基准确认通信开销。
2.3 存储与数据通路
智算平台通常同时提供家目录、项目目录、共享并行文件系统和节点本地临时目录。训练任务需要持续读取数据和写入检查点，存储吞吐不足会让加速器等待数据。
建议将原始数据、预处理数据、模型检查点和日志分开管理，并根据平台说明选择合适的存储路径。不要把大量小文件直接堆在高并发共享目录中，必要时可以先打包、索引或转换为更适合顺序读取的数据格式。
2.4 软件栈
智算软件通常从底层到上层依次包括驱动、加速器运行时、通信库、数学库、深度学习框架、模型代码和任务脚本。任一层版本不匹配，都可能导致程序无法启动、设备不可见或性能异常。
环境排查时应记录并核对：
- 加速器驱动与运行时版本；
- Python、PyTorch 或其他框架版本；
- NCCL、MPI 等通信库版本与网络配置；
- 容器、模块或虚拟环境的来源；
- 模型代码、配置文件和数据处理脚本的版本。
3. 工作负载与资源画像
不同阶段的资源重点不同，申请资源时应先明确任务属于哪一类：
| 工作负载 | 主要特征 | 优先关注的资源 | 常用指标 |
|---|---|---|---|
| 预训练 | 数据量大、运行时间长、通信频繁 | 多卡/多节点、显存、网络、检查点存储 | 每秒 token、扩展效率、故障恢复时间 |
| 微调 | 模型和数据规模相对可控，实验次数多 | 单卡或少量 GPU、显存、数据读取 | 单步耗时、收敛速度、实验吞吐 |
| 推理 | 需要稳定服务和可预测响应 | 显存、批处理、并发、CPU 与网络 | 吞吐量、首 token 延迟、P95/P99 延迟 |
| 向量与检索 | 数据预处理和索引构建较重 | CPU、内存、存储吞吐和容量 | 构建耗时、查询延迟、并发量 |
| 科学智能 | 模拟、数据处理和模型混合 | CPU/GPU 组合、I/O、跨节点通信 | 单个样本耗时、端到端时间、结果误差 |
训练关注收敛速度和最终效果，推理还要关注并发能力、首 token 延迟、平均响应时间和显存占用。二者不能用同一套指标简单判断。
4. 如何衡量智算性能
4.1 算力与精度
FLOPS 表示每秒可执行的浮点运算次数，常见单位包括 GFLOPS、TFLOPS 和 PFLOPS。不同精度下的峰值算力不能直接横向比较：同一设备的 FP32、FP16、BF16 和 INT8 性能可能存在明显差异。
理论峰值可以粗略表示为：
理论峰值 = 设备数量 × 每设备并行单元数 × 工作频率 × 每周期操作数
理论峰值只代表理想上限。真实任务还会受到模型结构、批大小、显存带宽、通信、数据加载和算子实现影响。
4.2 显存、内存与带宽
- 显存容量决定单卡能够容纳多大的模型、批次和中间结果；
- 显存带宽决定数据在设备内部移动的速度，内存访问密集型模型可能受其限制；
- 主机内存影响数据预取、缓存和 CPU 侧预处理能力；
- 数据通路带宽决定数据从共享存储、CPU 内存到设备显存的供给速度。
显存不足时，任务可能直接报错，也可能通过 CPU 内存或磁盘交换数据而显著变慢。增加计算单元不一定带来同比例加速，需要结合带宽、缓存命中率和数据布局分析。
4.3 实际指标
常见的实际指标包括：
- 吞吐量：单位时间处理的样本数、token 数或请求数；
- 单步耗时：训练一个 step 或处理一个 batch 所需的时间；
- 端到端延迟：从请求进入到结果返回的总时间；
- 扩展效率：增加设备后，性能提升与理想线性提升的比例；
- 设备利用率：计算设备处于有效工作的时间比例；
- 能耗效率：每瓦特能够完成的有效计算量。
比较性能时必须固定数据集、模型版本、精度、批大小、并行策略和软件环境，否则结果不具备可比性。建议先建立单卡或单节点基线，再进行多卡和多节点对比。
5. 数据类型与混合精度
深度学习通常不需要所有计算都使用最高精度。混合精度会让部分计算使用 FP16、BF16 或 TF32，同时保留关键步骤的更高精度，以平衡速度、显存占用和数值稳定性。
| 类型 | 常见用途 | 主要特点 |
|---|---|---|
| FP64 | 高精度科学计算、部分数值验证 | 精度高，计算和存储成本较大 |
| FP32 | 通用训练、基准和数值稳定步骤 | 兼顾范围、精度与兼容性 |
| TF32 | 部分设备上的矩阵计算 | 在兼容框架中提升吞吐，需确认精度要求 |
| FP16/BF16 | 混合精度训练和推理 | 节省显存、提高吞吐，需要关注溢出和收敛 |
| INT8 及更低精度 | 推理量化 | 降低资源占用，但可能影响模型效果 |
选择精度时要关注模型和算子支持情况、损失值和梯度是否溢出、训练结果是否满足准确率要求，以及推理任务是否接受量化带来的精度变化。应先建立可复现的基准，再逐步尝试混合精度或量化，并记录速度、显存和效果变化。
6. 智算中的并行方式
6.1 数据并行
每个设备持有一份模型副本，处理不同的数据切片，再同步梯度。数据并行实现相对直观，适合模型能够放入单卡显存的场景；设备数量增加后，梯度同步和全局 batch size 会影响扩展效率与收敛行为。
6.2 模型并行
将模型的不同层或不同模块放在不同设备上，适合单卡无法容纳的大模型。模型并行会增加设备之间的数据传输，需要合理安排层之间的通信，并关注显存是否均衡。
6.3 流水线并行
将模型划分为多个阶段，让不同设备同时处理不同的 mini-batch。流水线可以提高设备利用率，但需要处理阶段之间的等待、气泡和批次调度。
6.4 混合并行
大规模训练通常组合使用数据并行、模型并行和流水线并行。并行度提高后，通信、同步和故障处理都会变得更复杂，应从单卡、单节点开始验证，再逐步扩大资源。
7. 训练、微调与推理生命周期
一个可复用、可审计的智算任务通常包含以下阶段：
- 数据准备：清洗、去重、切分和格式转换，并记录数据版本；
- 环境准备：确认驱动、运行时、深度学习框架和依赖版本；
- 资源申请：根据模型规模、数据量和并行方式申请 CPU、GPU、内存和运行时间；
- 小规模验证：用小数据、单卡或短时间任务检查代码、路径和结果格式；
- 训练或微调：记录配置、随机种子、日志、检查点和中断恢复信息；
- 验证与评估：使用独立数据集检查效果、稳定性和资源消耗；
- 推理部署：选择合适的批处理、并发度、精度和服务方式；
- 结果归档：保存模型、配置、指标、日志和依赖信息，保证后续能够复现。
把“能运行”与“能复现”区分开：前者只要求任务完成，后者还要求别人能够根据同样的代码、数据、环境和参数得到可比较的结果。
8. 作业调度与资源使用
在共享智算集群中，通常通过 Slurm 等作业调度系统申请资源。提交前应确认：
- GPU 型号、数量和显存是否满足任务要求；
- CPU 核数、内存、临时空间和运行时间是否合理；
- 是否需要单节点多卡或跨节点通信；
- 数据和输出目录是否具有正确的读写权限；
- 训练日志和检查点是否会持续占满共享存储。
不要在登录节点直接运行训练或推理服务。登录节点适合编辑脚本、准备环境、查看队列和提交作业；实际计算应在调度系统分配的计算节点上执行。HPC 平台的通用资源和作业流程可参考高性能计算基础与 Slurm 使用指南。
示例中的分区、节点数、GPU 数量、运行时间和路径均需按当前平台及账号权限修改。长时间训练应配置日志、检查点和失败恢复方案。
9. 性能调优与常见问题
9.1 GPU 利用率低
先检查数据加载、CPU 预处理、batch 大小、显存占用和设备间通信。GPU 利用率低可能意味着输入数据供应不上，也可能是模型本身计算量小或同步频繁。可通过增加预取、合并小文件、调整 batch 或优化数据处理流水线验证原因。
9.2 显存不足
可以尝试减小 batch size、使用梯度累积、启用混合精度、缩短序列长度或采用模型并行。不要只通过增加 CPU 内存解决显存不足，因为数据在不同存储层之间搬运会产生额外开销。
9.3 多卡扩展不理想
检查通信时间、梯度同步、数据划分、节点拓扑和 I/O 是否成为瓶颈。设备数量翻倍并不保证训练时间减半，扩展效率需要通过固定模型、数据和配置的基准测试验证。
9.4 任务无法复现
记录代码版本、数据版本、容器或环境文件、框架版本、启动参数、随机种子和硬件信息。只保存模型权重通常不足以完整复现实验结果，还应保存评估脚本和关键指标。
9.5 检查点和日志拖慢训练
减少不必要的保存频率，将大文件写入适合的项目或并行存储，避免多个进程同时创建大量小文件。长任务应保留最近检查点，并在任务结束后再归档不常访问的历史版本。
10. 入门实践清单
第一次运行智算任务时，建议按以下顺序推进：
- 先用小数据集和单卡任务验证代码、环境和输出路径；
- 逐步增加 batch size，观察显存、吞吐量和训练稳定性；
- 使用固定配置进行单卡、多卡和多节点基准测试；
- 确认性能瓶颈后，再选择混合精度、并行策略或数据格式优化；
- 最后提交长时间任务，并配置日志、检查点和失败恢复方案；
- 归档代码、数据、环境、配置和评估结果，为下一轮实验留下可复用基线。
智算平台的核心目标不是单纯追求设备数量，而是在正确的资源、数据、软件和并行策略之间取得平衡。