> ## Documentation Index
> Fetch the complete documentation index at: https://starforge.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 作业状态
> 从 QUEUED 到 SUCCEEDED，暂停续跑、自动重试，以及何时开始计 GPU 时间
CLI 和控制台的状态以服务端台账为准。K8s Pod 阶段、Slurm `PENDING` 这类后端字符串会映射到下面这张表。没有一种「未知但看起来像成功」的状态。
## 各状态含义
| 状态 | 在集群上？ | 常见原因 |
| ----------- | -------- | ------------------------------------------------ |
| `QUEUED` | 否 | 已准入，在等配额、GPU、调度窗口，或（续跑后）一次新的投放。`job_ref` 为空。 |
| `SUBMITTED` | 投放进行中 | 配额已经预扣。执行器还没返回句柄。 |
| `PENDING` | 是，还没在训练 | 拉镜像、nodeSelector、Slurm 分配、Ray 集群起来。 |
| `RUNNING` | 是 | 入口进程在跑。 |
| `SUCCEEDED` | 终态 | 进程退出码 0。`--then export` / `--then eval` 仍可能再起作业。 |
| `FAILED` | 终态（除非重试） | 非零退出、ingest 硬失败、OOM、preRunning 超时。 |
| `STOPPED` | 终态（除非重试） | 用户或管理员停止。 |
| `PAUSED` | 否 | 训练进程已停；点继续后回到 `QUEUED`。和一次新的出队同一条路：配额和容量闸门再走一遍。 |
`QUEUED` 不是「已经在 Slurm/K8s 上排队等卡」。那种情况是 `PENDING`。仪表盘上一直排队，先看配额和调度窗口，不要先 `kubectl get pods`。
## 暂停、继续、重试
* `sf job pause` / 控制台暂停：停掉运行中的进程，台账行保留，状态 `PAUSED`。
* `sf job resume`：状态回到 `QUEUED`。调度器会重新投放，不是附着到旧容器上。
* 控制台「重试」/ `sf job retry`：`FAILED` 或 `STOPPED` 的训练作业可以直接重试，不必重新 `sf submit`。
用**同一个 run\_id** 重新排队 —— 输出目录不变，框架从最近 checkpoint 继续，台账仍是同一行，
重试次数累加。走的是和继续完全一样的那条路，配额、容量、可用时段闸门再走一遍。
* `FAILED` 之后的自动重试有预算和冷却。次数写在作业详情里。不想再跑就停掉。
重试按钮变灰时，鼠标停上去会说明原因。最常见的一种是工作目录快照已经不在 ——
它是提交时那份代码的唯一副本，作业被删除时一并清理，之后只能重新提交。
## GPU 时间
排队不计费。计量从 `PENDING` 之后真正占卡开始（容器起来、有 `start_time`）。口径是 `gpu_seconds`（墙钟时间 × 卡数），控制台用量页能看到。
## 盯一份作业
```bash theme={"theme":{"light":"github-light","dark":"github-dark-dimmed"}}
sf job status # 省略 id 则看最近一次
sf job logs # 跟踪；省略 id 则最近一次
sf job logs -n 0 # 回放历史
```
控制台作业页：图表、日志、验证、系统（GPU 利用率）、事件、诊断。