跳转到主要内容
面向已有 Slurm 的机房。控制面只走 slurmrestd（REST + JWT），没有 sbatch / SSH 旁路。训练在 Enroot/Pyxis 或 Apptainer 容器里跑。

​
前置

  1. slurmrestd 开启并配置 JWT 鉴权；
  2. 计算节点装容器运行时：Enroot + Pyxis（推荐）或 Apptainer；
  3. 共享文件系统（作业暂存目录与产物）；
  4. 一等框架的执行工件以 SQSH / SIF 形式发布到 runtime registry（custom + slurm 不允许 OCI 镜像隐式物化）。

​
配置

​
语义要点

需要 Slurm 26.05 和 API v0.0.45。LaunchRequest 渲染为批脚本，每次尝试保留独立、不可改写的环境文件和调度日志。提交响应丢失时保留这些文件，并在找到原分配前拒绝重复提交。生命周期操作使用原生 SLUID；数字 JobID 仅用于查询首次提交回执。平台负责重试，因此关闭 Slurm 自动重新排队。
多池作业渲染为 Slurm 异构作业：每池一个组件，--constraint 按卡型 series 的 slurm_constraint 钉节点。series 未声明 constraint 时装配层直接拒绝（fail-closed，组件不会落到任意 GPU 节点）。
状态经 REST 轮询映射到平台状态机；日志从共享目录读取回传（异步化处理，大日志不阻塞事件循环）。

​
已知边界

  • Playground 不支持：训练节点通常无入向网络；
  • E2E 闭环暂未覆盖 slurm（需容器化 slurmrestd + Apptainer，规划中）——批脚本渲染、REST 客户端、hetjob 与状态映射有完整单测。见 E2E 闭环测试。

​
纯 CPU 自定义作业

使用 custom/custom，声明一个资源池：nodes: 1、gpus_per_node: 0，以及正数 cpus 和 memory_gb。选择能运行 CPU 作业的 Slurm 分区。批脚本使用 --cpus-per-task 和 --mem，不申请 GPU，也不启动 Ray。 在 TUNEPLANE_RUNTIME_REGISTRY_FILE 中，以明确的 custom-... 运行时 ID 注册 SIF/SQSH 文件；将 spec.framework.runtime_id 设置为该 ID，不填写 spec.framework.image。提交前和计算节点启动前都会校验文件摘要。仍需共享存储及 容器运行时。暂不支持临时磁盘预留和跨机器 CPU 作业。