主题
保留并恢复 RLinf 训练
RLark 的启动操作会重新创建 Job 工作负载和 Ray 进程，不会自动选择 RLinf checkpoint。能否恢复训练取决于外部 RLinf 配置、checkpoint 完整性和持久存储。
了解停止、启动和恢复的区别
| 动作 | RLark 行为 | 与 checkpoint 的关系 |
|---|---|---|
| 停止 | 把 Kubernetes Task 副本数协调为 0，终止当前 Pod 和 Ray 进程 | 不写 checkpoint，也不等待应用写完；必须事先由应用完成保存。 |
| 启动 | 清除停止标志，按同一 Job 模板重新创建 Pod，并启动新的 Ray 集群 | 原 runScript 是否设置恢复目录，决定 RLinf 从头开始还是尝试恢复。 |
| 删除 | 删除 Job，并清理受控 Task、工作负载、Ray Service 和 Task 创建的 PVC | Bucket 或主机目录中的数据不一定删除，但 RLark 文件入口、Pod 日志和 PVC 引用可能消失。 |
容器文件系统、内存中的模型状态和 Ray actor 都不会跨 Pod 重建保留。
RLark 不管理 checkpoint 选择
Job CRD 没有 resume_dir、训练后端或 checkpoint 状态字段。RLark 不会：
- 识别 FSDP、FSDP2 或 Megatron checkpoint 布局；
- 判断分片、优化器、RNG、dataloader 或 replay buffer 是否完整；
- 保证写入原子化；
- 按 step 列出、比较或选择 checkpoint；
- 把启动自动转换为
runner.resume_dir； - 验证恢复后的模型、step 或数据迭代位置。
这些行为由目标 RLinf 版本和具体 runner 决定。RLinf 常见 runner 使用 global_step_<N> 目录并从 runner.resume_dir 读取，但所需子目录随 runner 和训练后端不同。例如，FSDP 可包含分布式 checkpoint 分片，Megatron 可包含 iter_*、mp_rank_* 和 latest_checkpointed_iteration.txt；部分 runner 还保存 critic 或 dataloader 状态。不能只看到 actor/ 或目录名称就判定 checkpoint 完整。
runner.resume_dir: auto 也不是所有 RLinf runner 的通用能力。只有目标版本和入口明确支持时才能使用。
停止前保留运行
- 找到 RLinf 实际写入的完整 checkpoint 目录，不要只依据当前工作目录。
- 确认该目录位于能够保留数据的挂载中。需要在 Pod 重建或重新调度后恢复时，使用经过验证的对象存储；主机目录只有在新 Pod 回到保留原目录的节点时才有效。写入容器根文件系统的数据会随 Pod 消失。
- 让应用完成一次 checkpoint 保存；依据该 runner 的成功日志和完整性规则等待所有分片、状态文件和元数据落盘。
- 使用对象存储时，从文件浏览器或经批准的存储工具核对完整对象前缀、文件数量、大小和最后修改时间；对象较多时不要依赖控制台首批 100 项。使用主机目录时，请管理员在实际节点核对 checkpoint 文件、大小、时间和备份结果。
- 记录训练后端、global step、RLinf 代码 ref、镜像 digest、脱敏最终配置、Job YAML、数据版本和 checkpoint 完整路径。
- 导出仍需保留的日志。RLark 日志页只提供每个主容器末尾最多 1000 行，Pod 终止后无法通过该页面恢复完整历史。
- 确认异步上传、外部 tracker 和视频写入已经完成，再执行停止。
不确定 checkpoint 应该写到哪个路径时，请先阅读在训练任务中使用存储。
停止不是 checkpoint 操作
控制台选择停止后没有二次确认，也不会调用 RLinf 保存接口。应用尚未完成写入时停止，可能留下不完整的 checkpoint。请先按训练后端的规则检查完整性，再使用该目录恢复。
选择恢复方式
根据是否需要修改 resume_dir 或其他运行字段选择操作。原 Job 的固定配置已经指向正确 checkpoint 时，可以重新启动；需要改配置时，请创建新 Job。
原 Job 已经设计为从固定配置解析恢复目录
如果原 runScript 每次都会从受版本控制的配置或稳定指针中取得正确 resume_dir，可以在更新该外部输入并确认无误后选择启动。RLark 仍会启动全新的 Pod 和 Ray 进程；这不是进程续跑。
需要修改 resume_dir 或其他运行字段
不要在已停止 Job 上使用编辑弹窗。弹窗重建 CRD 时会清除 spec.stopped，可能在提交时重新启动工作负载；它也不能完整保留所有 Pod 字段。
优先流程是：
- 保存原始 Job YAML 和 checkpoint 记录。
- 复制为新 Job，并在外部 Hydra 配置或已确认的运行脚本 override 中明确设置 checkpoint 路径。
- 重新执行启动前检查。
- 在 YAML 预览中确认新名称、镜像、角色、资源、挂载和命令；原 Job 含 CPU、内存或其他创建器不支持字段时，不要用控制台复制。
- 保留原 Job，直到确认新 Job 已成功恢复。
恢复后验证
- 确认各角色落在预期节点，新的 Ray 集群包含全部预期 Worker。
- 在脱敏日志中找到 RLinf 明确加载所选 checkpoint 的信号，而不是只看到目录存在。
- 核对恢复的 global step、模型/优化器状态和 runner 要求的其他状态。
- 确认新指标从预期 step 继续，且没有意外覆盖旧 run。
- 等待下一次 checkpoint 完整写出并按同一规则验证。
任一项不符时停止新 Job，保留原 checkpoint，不要在同一目录上连续试错或清理旧数据。