实验室 GPU 集群管理经验分享与问题探讨，求建议

[jingyijun]

我们的环境：

• 计算节点：20+台配备 3090/4090/A800 的服务器，10Gbps 交换机互联

• 共享存储：双副本 PB 级 GPFS 存储池（非官方对接维护），目前问题是运维成本过高，包括运维人员水平和价格方面。正评估 Minio+JuiceFS 替代方案。

• 任务调度：Slurm 系统，现存问题：

  • GPU 共享困难，Debug 状态下显存利用率不足

  • 任务申请卡数碎片化影响调度效率

• 账号管理：基于 /etc/passwd 文件同步，正在探索迁移至 OpenLDAP ，并与飞书账号集成

重点问题求教：

1. 存储方案选择： 当前 GPFS 在加载 conda 环境时出现显著延迟（从共享存储加载 conda 环境经常会导致 VSCode Timeout ），可能原因是否是元数据操作瓶颈？考虑到我们缺乏官方支持且运维成本高，是否有必要迁移到 Ceph/JuiceFS 等开源方案？特别希望了解实际性能对比数据。

2. Slurm 与容器化整合： 有些开源仓库提供了模型代码运行环境的 docker 镜像，但是当通过 Slurm 分配 GPU 进入计算节点 bash ，再进去运行 Docker 后台任务时，常出现任务结束后容器残留导致 GPU 占用冲突。是否有成熟的 Slurm 插件或脚本方案能实现提交时自带容器信息，并且实现生命周期绑定？

3. 调度系统演进方向：

   我们观察到许多算力租赁平台采用 K8s 管理算力，实现：

   • 一个相对友好的 UI
   • 交互式开发机（ JupyterLab/VSCode Server ）
   • 后台任务（训练、推理）环境的镜像化打包和统一资源分配
   • 队列调度

   相较 Slurm ，这种架构在 GPU 利用率方面是否具有显著优势？迁移成本与收益如何权衡？

参考（ 3 年前）: https://v2ex.com/t/823176

希望各位能不吝赐教，期待大家的实战经验分享！（文本由 DeepSeek 润色过）

[SorryChen]

刚好我在两个不同的机构，分别部署过基于容器的，和基于普通 Slurm 的。一个机构刚好两种都体验了。

首先结论，对于我们组的大部分研究人员来说，全部投票 Slurm 。首先我们这大部分大学都是 Slurm ，很多人熟悉。其次容器对不熟悉 docker 的人来说，简直天书，完全不明白，为什么 container 关了我有些东西就不见了。而 Slurm 虽然上手有那么几条命令，看着挺复杂。但是一共也就那几条命令。另外就是 slurm 集群的所有操作，包括代码编写，调试，申请资源，等等基本都在登陆节点，而基于容器的通常都有个网页 UI 之类的，从那上面申请资源进行训练啥的。体验很割裂。而且基于容器的申请一个资源到正式运行代码，速度挺慢的，而 slurm 一秒就搞定了。综上，我们组当时体验了两个切换投票的时候，slurm 全票通过。

存储：我们用了 juicefs 和 seaweedfs 作为 S3 。运行挺好的。速度也很快。管理员需要研究研究 seaweedfs 的源码。文档较少。

Slurm：
1. 碎片化任务：容易解决。无非就是有的 1-2 GPUs 的调试任务，明明可以填空别的 mix 机器，却单独放到了一个 8x 节点上，导致这个 8x 节点无法进行 8 卡训练。这是因为 slurm 的最小 load 分配策略导致的，优先散布任务而不是紧凑分配任务。所以可以在命令比如 srun 外面包一层。在真正提交任务给 slurm 之前，优先寻找 slurm 里面的 mix 节点，然后分析哪个可以填空当前任务，如果找到了，附加参数 -w nodename 给这个任务即可。
2. 调试 GPU 利用率低：有的人喜欢 srun --pty bash 这样进去用交互的方式调试。极其浪费资源。因此通过 job_submit.lua 限制这类任务只能提交到特定分区，比如 dev 分区。该分区设置最大 job 时间比如 4 小时。同时还可以 sacctmgr 限制该分区每人最多用 2x 卡。另外，鼓励大家使用一次性资源申请调试任务。比如 srun -p xxx --gres=gpu:4 python train.py 这样一样可以调试任务，而且申请到的 GPU 资源会在程序停止运行后立马释放，最大化共享。
3. 碎片资源利用：管理员可以写一个 job 提交脚本，通过分析集群资源 layout ，让用户的多机多卡任务适配。比如用户进行 8 卡训练，但是集群只有两个 4x 空闲机器。理论上此时也可以开始训练。所以我这边写了个脚本，自动完成 layout 分析，提供给用户一些可用的环境变量，比如 NODE_RANK ，LOCAL_RANK ，MASTER_ADDR ，MASTER_PORT ，就可以了。用户只需要设置好这些，无论是单机 8 卡，还是双机 4 卡，都能跑起来。提交任务的时候只需一条命令 slurm-submit --num_gpus=8 python train.py ，脚本自动去寻找机器。
4. 交互式开发：同样可以做到。理论上用户并不可以直接访问 GPU 机器，因此需要在用户申请到 GPU 资源后，在 job 内启动 vscode server/jupyter server 。但是该服务在 GPU 机器上，用户无法访问，因此需要端口映射。用 frp 即可。管理员只需要基于 frp ，包一层，提供给用户一个命令，比如 forward_port 。用户运行这个命令之后，你的脚本里去调用 frpc ，然后把相应端口映射给登陆节点。用户只需访问 loginnode:port 即可访问上述服务。
5. 队列调度：slurm 的队列足够强大了，多个 qos 配置，包括资源抢占，以及 backfill 策略，都相当好用。相反我用过的两个基于容器的，包括开源的和大型公司私有的，完全比不上。

[samli12]

你们需要一个专门的 HPC 运维

[Busby]

有专门运维上 slurm
无专门运维的话还是 K8s 吧，autodl 有私有化部署方案（官网免费，但没尝试用）
我们组非计算机，就简单用 docker 控制分配了，按照三年前帖子方案，分配到人

[runzhliu]

计算+存储看起来规模不小了，有同学专职运维不？

存储方面，Ceph 的运维成本很高，考虑到数据价值，除非有懂 Ceph 的同学或者有专职运维，否则不要轻易尝试。
调度方面，Kubernetes+Docker ，这是工业化标准，有能力还是尽量往这个方向走。

slurm 我见到很多算法的同事用，就因为直接直接登节点，已经见过 10+次误删数据，甚至把节点直接搞垮了，如果简单是最重要的条件，那就没问题。

[cxz2536818783]

k8s+volcano ，稍微研究一下就会认为这套方案就是在帮你简化运维，volcano 是 cncf 首个云原生批量计算项目，你说的资源管理作业管理队列管理他都有，很多用户也从 slurm 迁移到了 volcano

[jingyijun]

@SorryChen 感谢回复！碎片化、调试这块深受启发，交互式这里我们这个 GPU 机器都是可以直接访问到对应机器的端口的，应该问题不大？不过我还有几个问题想问。
1. 灵活性：我们实际运维中还是会遇到一些同学，希望 apt install 的方式在宿主机上装一些软件，可能是需要 follow 一些工作的时候，确保跟 README 里写的环境匹配上。这个时候容器化环境会更加灵活一些，然而 slurm 看起来就是跟容器不太兼容的，用户还是没有办法随意装一些全局的环境。
2. 容器化：容器环境我感觉也没有那么天书？我们所有的用户 HOME 目录都在共享存储 gpfs 上，所以类似 ~/anaconda 这种目录就很自然跨计算节点共享，如果说用容器化方案，挂载共享存储目录/个人环境打包上传到共享容器库之后，数据应该也不会很容易丢失？
3. 我自己后续可能会做一些基于 k8s 的探索、研究，包括 k8s scheduler for ml batch process system / kuberay 等等，供给实验室 scale up 的实验。然而现在基于 slurm 的平台貌似很难和 k8s 协同管理。我也看到过一些基于 k8s 的和 slurm 同类型的平台例如 Kueue 这种，这是否有一个权衡的方案。

[jingyijun]

@runzhliu
1. 没有专职运维，都是实验室感兴趣的同学兼职运维。所以说运维成本高，沟通学习成本也高。但是现在 HPC 专职运维我们一直在招，没有找到能力匹配且酬金合适的。或许可以了解下专职运维市场行情大概是怎样的？
2. Ceph 我们隔壁实验室在用，确实很劝退。我们也在探索 K8s 。
3. slurm 为什么会误删数据？每个用户应该用的是自己的 linux 账号呀，他没道理能删除系统环境里的东西。

[jingyijun]

@cxz2536818783 感谢！粗略看感觉确实很匹配我们的需求

[runzhliu]

@jingyijun 因为最后都会抱怨 linux 用户权限不足，经常到最后就是 root 了，另外就是有共享访问的数据，如果 r/w 权限设置不当，也有可能误删，当然这都是基础设施知识和实践较少的同学有可能会遇到的

[abbottcn]

万兆以太网，会不会是短板？

[rogerer]

@jingyijun 需要找个本科师弟来做这个维护哈哈

[bitllion]

1. 存储方面：
a. 推荐 lustre , 我给某双一流大学做的 lustre, 即使机房意外断电，也没有丢数据
b. 存储系统的设计，元数据服务器务必用 RAID 1 模式下的 NVME 盘，显著提高元数据性能，例如读写文件锁、搜索加载文件树； OSS 服务器可以用小容量（重建 raid 更快）机械硬盘，RAID 6 模式 ； lustre 后面再接一个 NAS(NFS ），定时 rsync 备份全量的 lustre 数据
2.调度系统：
a.对于高校用户，还是推荐 slurm ，k8s 是为大公司业务系统设计的，他们有大量管理设计开发微服务的经验，往往维护 k8s 集群的是一个小团队
b.容器的问题，可以看看 singularity 和 slurm 的解决方案 、SPANK 插件 ，还有你的 sbatch 脚本和 slurm 配置是否正确，我之前维护一个 GPU 集群，跑大模型也是用的 slurm+docker ，没有出现过容器残留的现象

[zweibright]

1 、conda 环境小文件多，可先缓存到本地硬盘，加载时不从共享存储系统读取，速度应该会快很多。思路参考： https://docs.tacc.utexas.edu/tutorials/managingio/#python ，没有具体实测过，但觉得思路可行。
2 、slurm 我们也好像没遇到残留问题，真有残留可以试试 slurm 的后处理功能，即作业退出时清除容器
3 、slurm 调度 docker ，root 权限不好管理，要加入 docker 组啥的，不知大家一般咋搞？

[SorryChen]

@jingyijun 灵活性确实没有容器高，不过我还没有遇到 conda install 不好安装的常用工具，或者编译安装。其他的也可以用 module 管理。容器环境打包等对小白还是太复杂了。这东西需要根据使用的人的感觉和经验来衡量。如果你们的用户都熟悉那就不是问题。毕竟集群最终是要给同学们用的。

我的感觉容器的适合成熟产品大规模部署，多机器来源等这些情况。比如我的计算资源一些来自 A 供应商，一些来自 B 供应商。他们甚至网络都不通啥的。这种情况我之前团队的容器方案可以轻易搞定聚合。但是 slurm 就不容易。slurm 胜在简单直观。如果只是小团队，几十台机子，我认为 slurm 心智负担最小。

[webcape233]

gpfs 这种小文件性能是不会很好，不过一般也不至于那么卡吧，测过 io 了吗？什么网络,200gb ib rdma 那性能嗖嗖的。 以你们的运维条件，lustre 那种更不要想了，更别说 ceph ，主要还是先找 ibm 看看文件系统的情况，这钱得花。 调度方面的问题得找经验丰富的 hpc 工程师看看，网上问这么全面复杂的情况,拿不到什么灵丹妙药