跳转到内容

核心概念

GPUPlane 围绕四个一等实体建模训练生命周期。理解它们的边界,就理解了整个系统。

术语 定义
Job 计算任务(调度单位),类型如 TRAIN / EVALUATE / CUSTOM
Run 实验运行(观测单位),一次训练/评估执行产生的完整记录
Checkpoint 模型版本的一等实体:由训练进程保存、由平台注册
Evaluation 对某个 checkpoint 的一次评估,结果回挂到该 checkpoint
Project / Experiment 两级归组:Project ⊃ Experiment ⊃ Run
Node / GPU Slot agent 主机与其上的 GPU 槽位(按卡独占分配)
Project ──< Experiment ──< Run ──< Checkpoint ──< Evaluation
│ ▲
│ └──── (parent_checkpoint 自关联, resume 链)
├─< MetricPoint (raw/rollup)
├─< Event
└─< RunLogRef
Job ──< (1..N attempt) ──< Run Node ──< GPUSlot ── owner_job ──> Job

一个 Job 从提交到终结的完整状态机:

CREATED已创建QUEUED排队中DISPATCHING下发中RUNNING运行中SUCCEEDEDFAILEDCANCELLED已取消(终态)LOST失联(server 恢复后重排)cancel(未调度)cancel(运行中)agent 断线 /心跳超时retry_job:同 id、attempt+1 —— 先改配置再重试

要点:

  • QUEUED 表示“已进调度队列”——GPU 空闲、selector 匹配才会被 dispatch。
  • 终态是 SUCCEEDED / FAILED / CANCELLEDLOST 是 agent 断线导致的失联态, server 恢复/重连后按策略重排或标记。
  • retry_job 复用同一个 job id(attempt 递增)——OOM/NaN 后先改配置再重试, 否则只会以同样的方式再失败一次。

Job 与 Run 的边界(最重要的一个概念)

Section titled “Job 与 Run 的边界(最重要的一个概念)”

Job 是调度单位,Run 是观测单位,两者通过 runs.job_id + runs.attempt 关联:

  • Job 每次 dispatch(含 retry)创建一个新 Run(同 job_id,attempt 递增)—— 重试的指标不会和上一次混淆。
  • Run 可以没有 Job:训练在平台外启动后自注册(source = sdk), 或事后用 gpuctl import-run 导入(source = import)。
  • Job 也可以不产生 Run:type = CUSTOM 的纯脚本任务只记录日志与退出码。
  • agent 的 CheckpointWatcher 监视 job 的输出目录(--watch checkpoints), 以防抖 + 指纹策略注册新 checkpoint(避免登记到写了一半的文件)。
  • Evaluation 是一个 EVALUATE 类型的 Job:继承训练 job 的 working_dir 与资源, 评估脚本按约定输出 {"metrics": {...}},结果回挂到被评估的 checkpoint。
  • get_best_checkpoint 排序时优先使用评估结果,训练期 best 值只作为兜底—— 因为训练集上的最优不等于泛化最优。

所有“最好”的判断都由一个 primary metric 驱动(不多目标)。解析顺序:

experiment → project → global(默认 eval/loss 最小化 或 eval/accuracy 最大化)

详见 指标与 Primary Metric