实验室 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 工程师看看，网上问这么全面复杂的情况,拿不到什么灵丹妙药

[eric107008]

之前在学校里帮忙运维了一下实验室的 GPU 集群，个人感受下基于容器的云方案的好处在于能够应付不懂操作的小白在未经良好培训的情况下瞎操作搞垮整个集群的问题。主要是学校里应付的人多而且你永远想不到一个“精通深度学习算法却不知道什么是栈”的博士生会从哪里给你问来类似“卸载 CUDA 只需要 sudo rm -rf /*" 之类的操作（因为真的遇到过有个博二的同门从一个群里问来这个操作，你不给 root 权限就等着天天被人发 teams 要密码）。总的来说其实是一个 Tradeoff ，毕竟 k8s 之类的其实是从云服务衍生出来的技术，为的是资源池化并且 expecting 类似 web 服务这种跑起来不关机的业务，所以也对 jupyter 之类的调试场景支持得更好一些。slurm 则是为超算之类的场景考虑的，expecting 那种一个脚本跑完拉到的业务，调试的话不是没有方案，但还是需要各种 hack 实现一些节点调度之类的问题。我的办法是，集群上先跑一个私有云（啥技术栈都无所谓，PVE ，VMWare, Microcloud 甚至 Hyper-V ），然后根据负载分成两部分，一部分用来跑 slurm 跑大任务，一部分用来跑（我们当时用的 lxd ）调试容器。白天调试的人多就多分点资源给容器，晚上没人上班就把容器冻结起来把资源分给 slurm 跑 Job 。最主要的还是做好人员培训，写个完善点的文档让每个人知道一点 linux 知识。你永远想不到草台班子会给你的集群带来什么样的惊吓，只能通过限制权限（提交 job 的方式非常单一，配环境要好好写配置文件）+织好安全网（调试只能用容器/虚拟机并且准备好一些常用的基础镜像）做好管理。

存储方面，自己并不是专家，只能用点 minio 这种勉强维持生活，听听社区里其他高手们的建议吧。

[cxz2536818783]

@jingyijun 欢迎 GitHub 提需求