莱夢1. HPC集群到底是什么：从一次失败的部署经历说起
几年前我接手了一个高校实验室的高性能计算集群部署项目，机器是42台双路服务器，网络是千兆（预算有限），存储是一台老旧的NAS。甲方说得很简单："你们把Linux装好，装个管理软件，能提交任务就行。"我当时觉得这活儿太简单了，结果从第一台机器开始就不断翻车：MPI程序跑起来只有单节点性能、作业排队逻辑混乱、共享存储挂载后I/O卡死、GPU节点驱动冲突把系统搞崩……足足折腾了两周才跑通一个勉强能用的版本。
后来我复盘这些坑，发现绝大多数问题都出在同一个地方：对HPC集群的架构理解不够，把集群部署当成了"装系统+装软件"，而忽略了它本质上是一套多节点协同的分布式系统工程。
所以这篇文章我不打算只给步骤清单，而是想从架构拆解、硬件选型、软件栈搭建、AI工作负载适配、运维监控、排错经验六个角度，把高性能计算集群部署这件事讲透。无论你是在搭一套传统的CPU计算集群，还是准备做一个融合GPU的AI训练/推理集群，这篇都适用。
先说几个容易混淆的概念。高性能计算集群（HPC Cluster）通常指的是通过高速网络把多台服务器连接起来，配合管理调度软件，让用户能以"提交作业"的方式使用整体计算资源。它和大家常说的"高可用集群""负载均衡集群""大数据集群"不是一回事：高可用集群解决的是服务不中断，负载均衡集群解决的是流量分发，大数据集群解决的是海量数据分布式存储与计算，而HPC集群的核心目标是把多节点的计算能力聚合起来，跑大规模并行计算任务（比如科学仿真、分子动力学、气象预报、深度学习训练）。
理解了这层区别，后面所有架构设计和软件选型就有了判断依据。你不会为了让MySQL不宕机去买IB交换机，也不会为了跑MPI任务去搭一套K8s（虽然现在事情正在起变化，后面我会单独讲）。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 集群硬件选型与互连网络：决定性能天花板的环节
很多人部署集群时把大量时间花在软件上，硬件随随便便，这是本末倒置。HPC集群的性能上限其实在部署之前就已经被硬件选型固定了，软件只是在逼近这个上限而已。
2.1 节点角色划分：不要把所有机器都当"计算节点"
标准HPC集群一般有几类角色，虽然物理机器可以复用，但逻辑角色必须分开：
- 登录节点：用户接入的入口，负责身份认证、作业提交、文件编辑。配置要求CPU不用太多，但要稳定的磁盘I/O和足够的网络吞吐。通常1-2台就够，跑管理服务。
- 管理节点：运行调度器（Slurm/ PBS）、集群管理工具、许可证服务。对CPU要求不高，但对稳定性要求极高，建议做双机热备。
- 计算节点：真正干活的机器，分为CPU计算节点和GPU计算节点。CPU节点看重核心数、内存带宽、缓存；GPU节点还要看PCIe通道数和GPU间互联方式。
- 存储节点：提供共享存储，独立部署或和登录节点合并。HPC场景强烈建议独立存储，因为计算节点的本地磁盘不能作为共享文件系统使用。
我见过不少小团队把一台机器又当登录节点又当管理节点又当存储节点，跑起来之后调度器一忙，用户登录操作卡成幻灯片。功能耦合是"看起来省钱，实际上烧时间"的典型。
2.2 互连网络：HPC性能的一半藏在网络里
传统数据中心里，1Gbps/10Gbps以太网就能应付大多数业务，但HPC集群不一样。如果你需要跑并行计算（MPI、GPU集合通信），网络就是命脉。
主流的HPC互连方案有三类：
| 方案 | 带宽（典型值） | 延迟 | 成本 | 适用场景 |
|---|---|---|---|---|
| 千兆/万兆以太网 | 1-10Gbps | 100-300微秒 | 低 | 小规模教学实验、I/O密集型但不依赖通信的任务 |
| RoCE（RDMA over Converged Ethernet） | 25-400Gbps | 1-5微秒 | 中 | 多数中小型HPC、GPU集群、存储后端互联 |
| InfiniBand（IB） | 200-400Gbps | 0.5-2微秒 | 高 | 科学计算、大规模GPU训练、超算中心 |
很多人第一次搭集群时会问：我用万兆网不行吗？我用普通网卡跑MPI不行吗？答案是：能跑，但别指望它有"高性能"。一个简单的MPI Allreduce操作，在千兆网环境下可能比在IB环境下慢两个数量级，而且这个差距会随着节点数量增加急剧放大。原因在于MPI库的通信模式非常依赖低延迟，普通TCP协议栈的处理开销（中断、拷贝、内核协议栈）会在每次小消息通信时吃掉大量时间。
实操建议：如果预算有限，优先保证以下几点——计算节点用25Gbps起跳的RoCE网卡（支持RDMA），交换机选用支持PFC流控的机型，GPU节点之间最好有NVLink/InfiniBand直连。对于纯教学用途的小集群（16节点以内），万兆加好好调优的MPI也能跑，不要过度纠结。
2.3 存储选型：共享存储是集群的心脏
HPC集群里的存储不是给每个节点配个大硬盘那么简单。你的代码、数据集、二进制文件需要让所有节点在同一路径下看到同一份内容，这就是共享存储的价值。它决定了任务是"秒级启动"还是"漫长等待"。
推荐方案是Lustre、BeeGFS、GPFS（IBM Storage Scale）这类并行文件系统。其中Lustre是超算主流，BeeGFS在小规模集群（几十到几百节点）里更友好，部署和维护成本低很多。小集群（<32节点）也可以用NFS搭配高性能NAS，但要注意NFS的元数据性能瓶颈，并发高时会明显卡顿。
我自己在32节点集群上测过：用了BeeGFS之后，原先NFS环境下动辄几十秒的作业启动时间直接降到2-3秒，尤其是在大量小文件读写场景（加载模型权重、读取配置文件时）优势非常明显。如果你打算在集群上跑AI训练，共享存储的带宽直接决定数据加载是否成为瓶颈，这块值得投入预算。
3. 软件栈搭建：作业调度、共享存储与统一认证
硬件到位之后，软件栈是决定集群"能不能好用"的关键。这里我以最常见的开源组合为例讲一遍：Rocky Linux 9 + Slurm + NFS/BeeGFS + OpenLDAP + Environment Modules。
3.1 操作系统与基础配置：少走弯路的做法
- OS统一为Rocky Linux 9.x或Ubuntu 22.04 LTS，所有节点版本必须一致，补丁级别尽量一致。版本不一致会导致MPI库、GPU驱动的兼容问题。
- 安装时选用最小化安装，不要装GUI。
- 配置好DNS和/etc/hosts。这是极其重要但常常被忽略的一步。Slurm、MPI、共享存储都依赖主机名解析，如果解析不一致会出现各种诡异问题。
- 关闭防火墙（或精确放行端口）和SELinux。HPC集群内部的节点信任关系通常靠SSH免密和NFS导出管理，防火墙策略会在MPI这类高端口通信场景下引发大量"半通不通"的故障。
3.2 Slurm调度器：为什么选它以及怎么配置
HPC集群的核心软件是作业调度器，它负责接收用户提交的作业、分配计算资源、监控作业运行状态、管理队列优先级。目前开源社区的事实标准是Slurm（Simple Linux Utility for Resource Management），20多年来积累了大量生产环境实践，文档丰富，插件机制完善。
Slurm本身并不复杂，核心组件就几个：
- slurmctld：控制守护进程，运行在管理节点，是整个调度系统的大脑。
- slurmd：计算节点上的守护进程，负责接收并执行由控制节点下发的任务。
- slurmdbd：可选的数据库守护进程，用于记录作业和计费信息，生产环境建议启用。
- 客户端工具：sinfo（查看节点状态）、squeue（查看作业队列）、sbatch（提交批处理作业）、srun（交互式运行）、scancel（取消作业）、sacct（查看历史作业）。
基础配置集中在slurm.conf，最重要的几个参数是：
code复制ClusterName=hpc-cluster
SlurmctldHost=master01
NodeName=node[01-32] CPUs=64 RealMemory=250000 State=UNKNOWN
PartitionName=normal Nodes=node[01-32] Default=YES MaxTime=INFINITE State=UP
PartitionName=gpu Nodes=gpu[01-08] Default=NO # 用Gres指定GPU资源
GresTypes=gpu
提示：配置里每个Node的CPUs和RealMemory要写准确，否则调度器分发的资源可能超过节点实际容量，导致任务被OOM杀掉或CPU超售。
装好Slurm之后不能直接宣布完工，还要做三件配套的事：
- MUNGE认证：Slurm默认用Munge做节点间认证，必须在所有节点上安装同一个Munge key，否则节点间通信会报错"Slurmctld: ... Unable to contact slurmd"。
- cgroup资源隔离：Slurm可以通过cgroup插件限制作业的CPU、内存、GPU使用量。强烈建议启用，否则一个作业就能把整个节点的内存吃光。
- 作业提交测试：在登录节点写一个test.sh，用sbatch提交，确认作业能正确排队、分配、执行、回收。
3.3 共享存储挂载与用户认证：让集群"像一个整体"
HPC集群要让人用得舒服，关键体验是：在任何节点上登录，看到的home目录、软件环境、用户身份都是一样的。这就靠共享存储加统一认证。
- 共享存储：把存储节点上的/home和/scratch通过NFS或BeeGFS导出，在所有计算节点上挂载到相同路径。home目录存用户文件和代码，scratch目录存临时运行数据，两者应该分开，因为scratch不需要备份，性能要求更高。
- 统一认证：推荐OpenLDAP或FreeIPA。小集群（<20节点）可以偷懒用NIS或Ansible批量写用户，但一旦超过20个用户、需要管理权限和组策略时，LDAP的价值就体现出来了：用户在一个节点上改密码，所有节点同步生效。
这块我要多说一句：LDAP和NFS的UID/GID一致性必须保证。很多集群故障的根因就是同一个用户在不同节点上的UID不同，导致文件归属错乱、权限拒绝。解决办法是配置LDAP时明确指定UID，或者在NFS挂载时用idmapd做映射。
3.4 环境管理：Environment Modules的妙用
HPC集群上通常要装多个版本的编译器、MPI库、Python环境，它们可能还会互相冲突（比如GCC 8和GCC 12编译的OpenMPI不能混用）。在没有容器技术之前，集群管理员用Environment Modules解决这个问题。
它的核心机制很简单：通过module load命令动态修改PATH、LD_LIBRARY_PATH等环境变量，让你在不同的软件版本间切换。配置一个modulefile的格式大致是这样：
tcl复制#-*- tcl -*-
proc ModulesHelp { } {
puts stderr {Loads OpenMPI 4.1.5 with GCC 12}
}
module-whatis {OpenMPI 4.1.5 with GCC 12}
set root /opt/openmpi/4.1.5-gcc12
prepend-path PATH $root/bin
prepend-path LD_LIBRARY_PATH $root/lib
setenv MPI_HOME $root
我在部署中习惯把常用的MPI、FFTW、HPL、Python虚拟环境都做成modulefile，用户在作业脚本里一行module load openmpi/4.1.5就能统一环境，避免了"你能跑我跑不了"的经典问题。
4. 计算节点配置与GPU集群：AI负载给HPC带来的新挑战
现在的高性能计算集群，越来越难跟AI训练/推理分开了。搜索引擎里"deepseek部署""ollama本地部署""Minimax h3本地部署"这类关键词的热度说明，很多团队是在把"高性能计算集群"当作"AI集群"来用的。所以这一章专门讲GPU和AI负载的适配。
4.1 GPU节点驱动与CUDA环境：地基必须夯实
GPU节点的软件栈相对固定，但也最容易出兼容性事故。正确顺序是：
- 安装操作系统（Rocky Linux 9或Ubuntu 22.04）。
- 安装NVIDIA驱动（用runfile或官方仓库），建议版本不低于535。
- 安装CUDA Toolkit（注意选对版本，CUDA 12.x配驱动>=525）。
- 安装NCCL（多卡通信库，跑分布式训练必备）。
- 验证：
nvidia-smi能看到所有GPU，运行nccl-tests验证多卡通信带宽。
一个必须强调的坑：驱动、CUDA、PyTorch的版本必须匹配。很多人一上来直接用发行版自带的GPU驱动，然后装最新版CUDA，最后PyTorch import报错，说找不到libcudart.so。这是版本耦合问题，不是"没装好"的问题。强烈建议：
- GPU驱动尽量装新（它是向下兼容的），比如550+系列。
- CUDA版本根据你要跑的框架决定，或者直接装CUDA 12.x，绝大多数现代框架都支持。
- 推荐用conda或Python虚拟环境来隔离不同项目对CUDA版本的需求，不要强求一机一套CUDA走天下。
4.2 GPU资源调度：在Slurm里怎么"分卡"
Slurm管理GPU资源需要在slurm.conf里定义Gres：
code复制GresTypes=gpu
NodeName=gpu[01-04] Gres=gpu:8 CPUs=64 RealMemory=500000
然后每个计算节点上还要在/etc/slurm/gres.conf里确认：
code复制NodeName=gpu[01-04] Name=gpu File=/dev/nvidia[0-7]
配好之后，用户可以通过--gres=gpu:4申请4张卡，或通过--gpus-per-node=8申请整卡。这样GPU资源才能像CPU那样被公平调度和限制，不会出现一个作业独霸8卡、其他作业干瞪眼的情况。
我在实际部署中遇到过一个问题：用户提交作业时没指定GPU，结果Slurm把任务调度到了GPU节点上但没分配GPU资源，任务跑起来直接报CUDA error。解决方法是给GPU节点上的CPU分配设置一个约束，或者在Partition配置里让GPU节点单独成一个分区，只有显式指定--partition=gpu的作业才能使用。
4.3 AI推理框架与HPC集群的结合：vLLM、Ollama的部署思路
如果说训练任务还能容忍单体服务器凑合，那么推理服务的部署就更需要集群思维了。比如热词里提到的vLLM、Ollama、Xinference、DeepSeek本地部署，本质上都是把大模型跑在多GPU上提供服务，这就是一种"AI推理集群"。
部署这类服务时，我的建议是：
- 模型并行：大模型权重超过单卡显存时，用张量并行（tensor parallelism）把模型切分到多卡推理。vLLM的
--tensor-parallel-size参数和后端的TP概念一致，配置前先算好每卡能装多少GB参数。 - 服务发现：多节点推理集群需要一个服务发现机制，把请求分发到不同的推理实例上，长连接模型下普通Nginx反代可能成为瓶颈，可以用LVS、Nginx的http/2连接池方案，或直接上K8s。
- 显存碎片：推理服务的显存管理别小看，vLLM的PagedAttention本质是为了解决KV Cache碎片问题。如果你用简单的多进程服务跑多模型，容易被显存碎片卡住。
如果你只是在一个计算节点上部署推理服务，其实"高性能计算集群"对你的帮助主要体现在：大模型数据集放在共享存储上，多节点都能快速加载；GPU资源通过Slurm统一调度，团队不会因为抢卡而冲突。但如果你的目标是把推理做成一个7x24的在线服务，集群加上K8s（或Slurm加K8s混部）会是更长远的方向。
5. 集群运维与监控：部署完成只是开始
很多人的集群部署完，验收一跑，就以为大功告成。实际上真正吃时间和考验水平的，是后续的运维。这一章讲监控、告警、扩容和常见故障处理。
5.1 监控指标：先把该看的东西看全
HPC集群的核心监控指标分为几类，缺一不可：
- 计算节点：CPU负载、内存占用、温度、风扇转速、电源状态。
- GPU节点：GPU利用率、显存占用、温度、功耗、NVLink通信量、GPU错误状态（XE错误计数器）。
- 网络：IB/RoCE端口流量、丢包率、链路状态、拥塞程度。
- 存储：吞吐量、IOPS、元数据操作延迟、容量水位。
- 调度器：集群节点状态（up/down/drain）、作业排队长度、平均等待时间、作业失败率。
开源监控首选Prometheus + Grafana，配合node_exporter、DCGM Exporter（GPU监控）、Slurm Exporter。存储和网络的监控可能要多花点功夫，比如Lustre/BeeGFS都有专门的Prometheus exporter。
注意：GPU监控一定得用DCGM Exporter而不是普通的node_exporter，否则你拿不到显存、温度、ECC错误这些关键数据。
配置告警时有个经验：不要一上来就设一堆阈值，那样只会告警疲劳。先跑一两周收集基线数据，然后只针对"会导致作业失败或节点宕机"的事件设告警，比如GPU温度超过85°C、节点ping不通、共享存储容量使用率超85%、Slurm队列中作业等待时间超过预设阈值。
5.2 容量规划与集群扩容：如何不踩坑地加节点
集群永远有扩容需求。不管是加计算节点、加GPU卡还是扩存储，最怕的就是"新节点和旧节点环境不一致"。
扩容的正确姿势是：
- 镜像化：用Ansible、Cobbler、Clonezilla等工具把新节点的系统配置成和现有节点完全一致（包括内核参数、驱动、软件包）。
- 测试：新节点先不加入调度器，用slurm的
--exclusive参数单独跑一遍诊断作业，确认CPU、内存、网络、GPU都正常。 - 热加入：把新节点配置写进slurm.conf，然后
slurmctld -t测试配置，再scontrol update或scontrol reconfigure让调度器热加载。Slurm支持动态添加节点，不需要重启整个集群。 - 压力验证：在新节点上跑一遍MPI通信测试和GPU集合通信测试，对比旧节点的性能基线，确认没有硬件或配置问题。
存储扩容则要提前规划文件系统的可扩展性。Lustre/BeeGFS这类并行文件系统的优势就是可以动态加OST（Object Storage Target），加完自动重新平衡数据。传统的NFS扩容则要麻烦得多，往往只能新建目录挂新盘，"软扩容"。
5.3 高可用设计：管理节点不能成为单点故障
HPC集群里计算节点挂了，作业失败可以重跑；但管理节点（slurmctld、LDAP、NFS）挂了，整个集群就会瘫痪。所以管理节点必须做高可用。
Slurm原生支持控制节点的双机热备，配置方法不复杂：
- 准备两台管理节点master01和master02，共享一个虚拟IP或域名。
- slurmctld配置里指定
SlurmctldHost=master01，同时让master02也装上slurmctld，启用Slurm自带的backup controller机制。 - 配合Munge和共享存储（管理节点的配置目录和状态目录放共享盘上），实现故障时自动切换。
NFS的高可用可以用DRBD + Pacemaker，或者直接用CTDB + GlusterFS。LDAP可以用主从复制加Keepalived虚拟IP。这些做下来，集群才算"生产可用"，而不是"学生实验可用"。
6. 常见部署故障排查实录：那些坑我替你踩过了
这一章是纯实战。我把部署高性能计算集群过程中遇到的高频故障、排查链路和解决办法写出来，希望能帮你少走弯路。
6.1 Slurm节点显示DOWN：原因与排查链路
故障现象：sinfo查看节点状态，个别节点显示*down*，作业无法调度到该节点。
排查顺序：
- 先看slurmd日志：
journalctl -u slurmd，确认节点上的slurmd有没有正常启动。 - 确认Munge服务正常：在相应节点上执行
munge -n | unmunge，如果解码失败说明Munge key不一致，这是最常见的原因。 - 如果日志显示"Communication connection failure"，检查管理节点到该节点的防火墙、端口（6817/6818）。
- 网络通了以后，用
scontrol update nodename=nodeXX State=RESUME手动把节点恢复。
如果是新加入的节点一直显示DOWN，优先排查slurm.conf里NodeName、CPUs、RealMemory和实际配置是否匹配。写错CPU数量会导致slurmd在注册时报"Config error"而拒绝上线。
6.2 MPI作业只能单节点运行：问题多半在网络或MPI库
故障现象：用mpirun在集群上提交任务，明明指定了多节点，但进程全部落在同一台机器上，或者跨节点通信直接报错。
排查思路：
- 检查主机名解析：
mpirun --hostfile hosts.txt hostname，如果每个节点都返回了正确主机名，说明解析正常。 - 检查SSH免密：从登录节点到所有计算节点能否免密登录。MPI默认基于SSH启动远程进程。
- 检查PMI和调度器集成：如果是用Slurm启动MPI，必须用
srun而不是mpirun，且安装的MPI库要启用Slurm的PMI支持（OpenMPI的pmi插件、Intel MPI的-genv I_MPI_PMI_LIBRARY）。 - 用
ping和ibstatus确认互连网络链路正常。 - 做一个跨节点的带宽测试：如果网络延迟巨大或丢包严重，检查交换机配置（RoCE要开PFC）、网卡固件、MTU一致性。
经验：MPI跑不起来或跑得慢，80%的问题出在网络（含主机名解析）和MPI与调度器的集成，而这两件事在部署一开始就应该验证，不要等到正式运行大量作业时才暴露。
6.3 共享存储性能瓶颈：NFS变成了"单点漏斗"
故障现象：集群上并发读取数据集时，所有节点都卡顿，作业启动时间从几秒变成几分钟。
这是典型的NFS元数据性能瓶颈。NFS的设计目标是"客户端-服务器"模式，所有元数据操作都要经过单个服务器处理，高并发小文件读写时，服务器CPU飙升，客户端等待IO。
解决办法有几个层次：
- 换文件系统：部署BeeGFS或Lustre，把元数据服务（MDS）和对象存储（OSS）分开，这是根本解决方案。
- 优化挂载参数：如果暂时不换，至少把NFS的挂载参数调优，比如
rsize/wsize调大到1MB，启用noatime，加大nfsd线程数。 - 改IO模式：在作业脚本里先把数据集从共享存储拷贝到本地盘（/tmp或/scratch-local），跑完再把结果拷回来。很多AI训练框架就是这么做的，数据加载的集中式瓶颈被绕开了。
6.4 GPU节点驱动冲突：重装驱动的正确姿势
故障现象：GPU节点上某次更新系统内核后，nvidia-smi报"Failed to initialize NVML: Driver/library version mismatch"。
原因很典型：内核升级了，但NVIDIA驱动模块还是旧的就地构建签名模块。正确解决路径：
- 确认目前内核版本：
uname -r。 - 重装对应版本的NVIDIA驱动：
./NVIDIA-Linux-x86_64-550.xx.run --kernel-source-path=/usr/src/kernels/$(uname -r)。 - 如果没有安装dkms，请下一次安装时加上
--dkms参数，避免内核每次升级都要手动重装驱动。 - 重装后
modprobe nvidia确认加载成功，再跑nvidia-smi。
提示：凡是涉及GPU驱动的操作，务必在计算节点不跑作业时进行。一个正在使用GPU的作业会让你modprobe失败，甚至需要重启系统。
7. 关于集群"多大才算大"：一种务实的分级视角
提到高性能计算集群，很多人会觉得这是超算中心才能玩的东西。但"高性能"是相对的，不同规模的团队对集群的需求完全不一样。我把它们分成三个级别：
| 规模 | 节点数 | 网络 | 存储 | 典型场景 |
|---|---|---|---|---|
| 入门级教学集群 | 4-16 | 万兆以太网 | NFS | 并行编程教学、小规模仿真、MPI实验 |
| 实验/科研集群 | 16-128 | RoCE/IB | BeeGFS/Lustre | 科学计算、中型AI训练、多用户共享 |
| 生产级AI/HPC集群 | 128以上 | IB + GPU互联 | Lustre/GPFS | 大模型训练、大规模科学仿真、商业计算服务 |
没必要为了追求"高性能"而去买IB交换机和高端存储。从万兆起步，跑通一套Slurm，让用户能提交作业、共享文件、统一环境，这已经是一个能用的集群了。关键是要留出升级路径——网络端口选型、存储架构是否支持横向扩展、节点扩展是否方便，这些在初期规划时就要想清楚。
以我自己的经验，一个16-32节点的小集群，用万兆RoCE + BeeGFS + Slurm，已经能覆盖实验室90%以上的计算需求。真正要花大钱的地方，是GPU节点的数量和卡间互联，那是AI负载的核心瓶颈。
8. 部署流程清单与后续演进思路
最后把完整部署流程整理成一张可直接对照的清单，方便你实际操作时勾选核对。
8.1 从零到一的部署顺序
- 规划阶段：确定计算需求（CPU/GPU/存储/网络），规划节点角色，确定IP和主机名规范。
- 基础系统搭建：安装操作系统，配置DNS/hosts，优化内核参数（尤其是网络栈和文件系统参数），配置Yum/Apt源。
- 共享存储搭建：部署BeeGFS/Lustre/NFS，导出home和scratch目录，挂载到所有节点并验证并发读写。
- 统一认证：部署OpenLDAP/FreeIPA，所有节点加入域（LDAP客户端配置），验证用户登录和UID一致性。
- 调度器部署：安装Munge + Slurm，配置slurm.conf，启动slurmctld和slurmd，通过sinfo验证节点状态。
- 环境管理：安装Environment Modules，配置编译器、MPI、常用的科学计算库的modulefile。
- GPU节点配置（如有）：安装NVIDIA驱动、CUDA、NCCL，配置Gres，验证GPU调度。
- 用户环境与作业脚本验证：创建测试用户，用sbatch提交CPU/GPU测试作业，确认作业生命周期（排队、运行、完成、回收）。
- 监控与告警：部署Prometheus + Grafana + node_exporter + DCGM Exporter + Slurm Exporter，配置告警规则。
- 高可用补强：管理节点双机热备，NFS/LDAP高可用，基础数据备份策略。
8.2 集群的演进方向
集群上线只是开始。如果在实际使用中逐渐发现瓶颈，演进方向一般是：
- 计算瓶颈：增加计算节点或GPU节点，注意保持网络和存储的带宽同步扩容。
- I/O瓶颈：从NFS迁移到并行文件系统，或引入分层存储（本地NVMe缓存 + 大容量机械盘/对象存储后端）。
- 调度智能化：用Slurm的优先级和抢占配置，或引入K8s来承载在线AI推理服务，和离线训练任务混部。
- 统一计算平台：中长期可以考虑以K8s为底座、以Kueue/Volcano做批处理调度、以Slurm作业模式兼容现有HPC习惯的双制式方案。
我在实际维护中体会到，集群管理最核心的问题不是"装一个炫酷的架构"，而是"让用户觉得好用、让管理员觉得可控、让算力不浪费"。从这个角度看，把基础做好、把监控做全、把文档写清楚，比追求任何高级功能都有价值。