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

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

@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 这种，这是否有一个权衡的方案。