核心概念
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 └─< RunLogRefJob ──< (1..N attempt) ──< Run Node ──< GPUSlot ── owner_job ──> JobJob 的生命周期
Section titled “Job 的生命周期”一个 Job 从提交到终结的完整状态机:
要点:
QUEUED表示“已进调度队列”——GPU 空闲、selector 匹配才会被 dispatch。- 终态是
SUCCEEDED / FAILED / CANCELLED;LOST是 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的纯脚本任务只记录日志与退出码。
Checkpoint 与 Evaluation
Section titled “Checkpoint 与 Evaluation”- agent 的 CheckpointWatcher 监视 job 的输出目录(
--watch checkpoints), 以防抖 + 指纹策略注册新 checkpoint(避免登记到写了一半的文件)。 - Evaluation 是一个
EVALUATE类型的 Job:继承训练 job 的 working_dir 与资源, 评估脚本按约定输出{"metrics": {...}},结果回挂到被评估的 checkpoint。 get_best_checkpoint排序时优先使用评估结果,训练期 best 值只作为兜底—— 因为训练集上的最优不等于泛化最优。
Primary Metric
Section titled “Primary Metric”所有“最好”的判断都由一个 primary metric 驱动(不多目标)。解析顺序:
experiment → project → global(默认 eval/loss 最小化 或 eval/accuracy 最大化)