--profile 是唯一的资源参数。节点数、并行度和 NCCL 环境来自服务端硬件注册表，不来自你的配置。
Profile 与 series
series 是部署自己定义的一类加速卡。profile 是覆盖在 series 之上的命名预设：一个默认 形状，加上针对这个形状的进程环境与框架覆盖项。
覆盖项跟着 profile 走，不跟着你的实验走：NCCL 设置、PyTorch allocator、全 1 并行度、vLLM 显存
比例。换卡型不需要改实验。
h200:16 是总数，不是每节点数。注册表把它换算成节点数 × 每节点卡数。
把一个作业拆到两种卡上
重复--profile 并带上角色前缀，把训练和 rollout 放到不同的卡上：
gpus_per_node 必须相同。多 pool 在 kubernetes（每个 pool 一个 worker group）和
slurm（一个 hetjob，每个 pool 一个 component，--constraint 取自 series）上可用。node 不支持多 pool，只支持单个同构资源池，最多跨 8 台机器。Slurm 会拒绝没有配 constraint 的 series。
配额
配额由管理员按用户设置。提交时检查一次，出队时再检查一次。
在这些标量之上还能按 series 单独设限，这是异构集群把 H100 作业和 H200 作业分开计的方式。
超配额不会拒绝作业。它在
QUEUED 里等。tp status 和控制台的 Usage 页显示你的水位。存储是
测量而非预留，所以那道闸门比现实略滞后，而 GPU 闸门是精确的。
调度时间窗
管理员可以限制某个 series 什么时候能跑 —— 白天推理、夜里训练。时间窗按星期设置，可以跨午夜。 时间窗关闭时：- 新作业不出队。窗口剩余时间太少时也会被拦住。
- 正在跑的作业先得到一段宽限期，然后暂停。checkpoint 会保留。
- 窗口重新打开时，暂停的作业从 checkpoint 继续。
tp status 和作业页会把时间窗点名为等待原因。
计什么
每个作业记录gpu_seconds：持卡的墙钟时间乘卡数。排队时间不计。容器起来、作业真正占住 GPU
之后才开始计。
多个 pool 的作业按卡数拆分，而且是精确而非近似：一个作业的各个 pool 是一起放置、一起启动、
一起释放的。
下一步
作业状态讲把作业卡在QUEUED 里的配额与时间窗规则。
提交作业讲剩下的参数。
角色与配额是给设置它们的人看的。