HPC

AWS Parallel Computing Service (PCS)

它是托管的 HPC 集群服务 —— AWS 帮用户运行和管理 Slurm 调度器及集群控制面，用户只管提交作业。

PCS可以理解为 “HPC 界的 EKS”：EKS 托管 Kubernetes 控制面，PCS 托管 Slurm 控制面。

为什么不直接用 EC2 自建 HPC？

自建的痛点：

• Slurm 运维负担重：调度器安装、高可用、升级、打补丁、故障恢复全要自己搞。HPC 管理员是稀缺岗位，很多科研团队根本没有专职人员

• 集群生命周期管理复杂：节点扩缩容、失败节点替换、登录节点/计算节点/共享存储的编排，自己写脚本很快变成一坨胶水

• 升级是高风险操作：自建 Slurm 集群升级经常要停机、迁移作业队列；PCS 支持滚动更新控制面

• 和 AWS 组件的集成要手工做：EFA 网络、placement group、FSx for Lustre 挂载、Spot/多实例类型混部，每样都要自己调

PCS 解决的方式：

• Slurm 控制面全托管（含 HA、补丁、升级），按控制面 + 节点计费

• 原生 API/CloudFormation 管理集群、队列、计算节点组

• 自动处理节点健康检查和替换

• 保留原生 Slurm 体验 —— 用户 sbatch/squeue 照旧，现有 HPC 作业脚本零改动迁移

和 ParallelCluster 的区别（常见混淆点）：ParallelCluster 是开源自助工具，集群还是跑在你自己手里，AWS 不管运行时；PCS 是正经的 managed service，有 SLA、有 API、控制面 AWS 负责。可以理解成 ParallelCluster 的"服务化升级版”。

Slurm

Slurm（Simple Linux Utility for Resource Management）是 HPC 领域事实标准的开源作业调度器 / 资源管理器。全球 Top500 超算里超过一半都在用它。它干三件事：

  1. 资源管理：追踪集群里所有节点的 CPU/GPU/内存，谁空闲谁在忙
  2. 作业排队与调度：用户用 sbatch 提交作业，Slurm 根据优先级、资源需求、公平共享策略决定谁先跑、跑在哪些节点上
  3. 作业执行：把任务分发到节点上启动（尤其是 MPI 多节点并行作业），监控运行、处理失败

类比：它之于超算，就像 Kubernetes 之于容器 —— 都是"把一堆机器变成一个可调度的资源池”。区别在于 Slurm 面向批处理作业（跑完即结束的仿真/训练任务），K8s 面向长期运行的服务。

典型使用场景：科研人员写个脚本 sbatch –nodes=64 –gpus=8 run_cfd.sh，Slurm 排队等 64 个节点凑齐后一起启动，跑完释放资源给下一个人。

层次关系：

• EC2 = 裸算力

• Slurm = 把算力组织成集群的调度大脑

• PCS = AWS 帮你托管这个大脑