产品 / 面向 AI 开发者
Slurm on TAIP
正式可用你的 Slurm 脚本，原样不动——跑在 Kubernetes 上，一套登录、一个 home、一份配额。
Slurm on TAIP 在你的 Kubernetes 集群上运行的是真正的多租户 Slurm，而非模拟——基于 SchedMD 官方上游的 Slinky slurm-operator。真实的 slurmctld / slurmd / slurmdbd / slurmrestd 负责调度作业，因此你依赖的行为（MPI、计费语义、分区、QOS、数组作业）就是 Slurm 本来的行为。它与 TAIP 的其余部分融为一体：SSH 登录用平台身份认证（经 SSSD 接入平台 LDAP 目录），首次登录即在共享集群存储上创建你的 /home；一个小巧的、带 leader 选举的控制器（account-sync）把每位用户在 ConsoleX 的工作区配额，对账成 Slurm 账户与 GrpTRES 上限——严格强制执行。GPU 是一等资源，配有硬性 cgroup 隔离；Open OnDemand Web 门户还提供基于浏览器的文件、作业、Shell 与 JupyterLab，让不想碰 SSH 的用户也能用。Slurm 25.11 采用 auth/slurm，无需运维 MUNGE 守护进程；上游镜像原样镜像，绝不 fork。
规格
- 状态
- v0.4.4 — 已在 Kubernetes 上投产
- Slurm
- 真正的 Slurm 25.11 · Slinky slurm-operator 1.1.1 · auth/slurm（无 MUNGE）
- 接入方式
- SSH（LDAP/SSSD）· JWT slurmrestd · Open OnDemand Web 门户
- 身份
- 平台 LDAP 目录 · POSIX uid/gid · 首次登录 pam_mkhomedir
- 存储
- 共享集群存储——/home + /scratch，与 TAIP 其余部分同一份文件
- 多租户
- ConsoleX 配额 → Slurm 账户 + GrpTRES（CPU/内存/GPU），严格强制
- GPU
- gres/gpu + gpu 分区 · 硬性 cgroup ConstrainDevices 隔离
用实证说话
一段代码看明白。
没有私有 SDK，无需改写—— Slurm on TAIP 在现有工具所在之处完成对接。
$ ssh you@taip-login # 你的平台密码——与各处一致
$ ls ~ # /home 已挂载在集群存储上
data/ train.slurm
$ sbatch train.slurm # 原样不动——0 行改动
Submitted batch job 4127
$ squeue --me # 跑在真实 GPU 节点上
JOBID PARTITION NAME ST TIME NODES
4127 gpu train R 0:08 1▌真正的 Slurm 25.11——sbatch / srun / salloc / sacct、分区、QOS、数组作业，行为与 Slurm 本来一致。它运行在 Kubernetes 平台之内，而不是与之并列的另一个世界里。
核心能力
Slurm on TAIP 为您带来什么
你的脚本一行不改即可运行
真实的 slurmctld / slurmd / slurmdbd / slurmrestd（上游 Slurm 25.11）负责调度——不是披着 Slurm 外衣的 Kubernetes 调度器。sbatch、srun、salloc、sacct、分区、QOS 与数组作业，行为与 Slurm 本来完全一致。零行改动。
统一身份，你早已在册
用现有平台凭据 SSH 登录——登录节点运行 SSSD，接入平台 LDAP 目录。POSIX uid/gid 来自平台目录，pam_mkhomedir 在首次登录时创建 home。没有独立的 Slurm 用户库，也无需第二个密码。
统一数据平面
/home/<user> 与共享的 /scratch 就在平台其余部分所用的同一份集群存储上。Slurm 作业写下的文件，正是你 notebook 读到的文件——无需拷入拷出，没有数据孤岛。
一份配额，自动对账
account-sync 是一个带 leader 选举的小型控制器，它读取每位用户在 ConsoleX 的工作区配额，对账成 Slurm 账户、关联与 GrpTRES 上限（CPU / 内存 / gres/gpu）。严格强制——超限作业被拒绝，而非尽力而为地限流。
GPU：既被调度，也被隔离
请求 GPU 分区与显卡（-p gpu --gres=gpu:1），Slurm 即为你调度。硬性 cgroup ConstrainDevices 隔离意味着作业连未分配给它的 GPU 都打不开——GPU 容量是受治理、被调度的资源，而非随意争抢。
Web 门户——无需 SSH
Open OnDemand 门户提供基于浏览器的文件、作业与 Shell，外加一个 JupyterLab 交互应用：以 Slurm 作业的形式、在你自己的 conda/venv 中启动，可选 GPU。基于平台身份的 OIDC 单点登录。
通过 REST 自动化
除 SSH 外，还有一个 JWT 认证的 slurmrestd（含 /slurmdb 计费端点），让你从 CI、流水线或自有工具提交与跟踪作业。
紧跟上游，绝不 fork
基于 SchedMD 官方支持的 Slinky operator；官方 slurmctld / slurmd / slurmrestd 镜像原样镜像，只有 login 镜像在上游之上叠加 SSSD + 集群存储。你得到的是 SchedMD 的真实发布，且更新及时——而不是滞后的分叉。Kubernetes 原生生命周期：Helm 安装、operator 对账、以 Secret 管理密钥。
工作原理
从平台登录到运行作业，无需迁移。
- 步骤 01
用平台身份登录
用你已有的凭据 SSH 登录（或打开 Web 门户）。SSSD 接入平台 LDAP 目录完成认证；首次登录即在共享集群存储上创建你的 /home。
- 步骤 02
提交你早已写好的脚本
sbatch train.slurm——一字节不改、无需重写。真正的 Slurm 25.11 把它调度到专用节点池上，分区、QOS 与数组作业一如既往地工作。
- 步骤 03
获取 GPU，并守在配额内
请求 gpu 分区与显卡，Slurm 即调度并硬性隔离。你在 ConsoleX 的工作区配额就是你的 GrpTRES 上限，自动对账、严格强制。
- 步骤 04
用你习惯的方式跟踪
用 squeue/sacct、Open OnDemand 门户，或 JWT slurmrestd API 跟踪作业——全部由同一份共享计费数据库支撑。
适用团队
为这些团队而建
- 积累了多年 Slurm 脚本与肌肉记忆的科研与 ML 团队
- 正在标准化到 Kubernetes、却仍需服务 HPC 用户的平台负责人
- 希望用一个受治理的平台替换独立裸机 Slurm 集群的组织
- 想要批处理调度与配额、又不愿再维护第二套身份与存储平面的团队
搭配使用
其他开发者产品
ConsoleX
正式可用登录即获得受治理的 Kubernetes 工作空间。无需 kubectl，无需提工单。
用户首次 SSO 登录时，自动获得一个隔离的命名空间：配额、默认拒绝的网络策略、存储与 Web 终端——自动开通，持续收敛。
了解更多DevSpace
正式可用几秒钟内在 GPU 上拉起 Jupyter 或 VS Code。闲置环境自动关停。
一键创建 Jupyter、Marimo、Streamlit、Gradio、VS Code 环境——GPU 就绪、按用户经独立认证代理隔离，支持 SSH，默认闲置自动关停。
了解更多TrainX
正式可用管理员写模板，用户填表单，Kubernetes 跑作业。
自描述的训练模板直接渲染成 UI 表单——提交前实时校验配额，运行中流式日志、解析进度条，一键 TensorBoard。
了解更多