RLark Web 控制台文档

主题

检查 RLinf 任务是否正常运行 ​

第一次运行需要完成下面六项检查。每项都要记录检查时间和结果位置；控制台显示运行中、出现 TensorBoard 链接或看到一条“启动脚本”日志，都不能单独说明 RLinf 已经正常工作。

这次检查覆盖的内容

本页只检查启动清单和部署参数中记录的这一组代码、镜像、配置与资源：Job 是否创建、Pod 是否落到指定节点、Ray 和应用是否启动，以及业务进展和输出是否符合预期。一次通过不能代替 RLinf 版本兼容表，也不能自动成为其他环境可复用的配方。

创建运行记录 ​

复制下面的表格。可以记录脱敏日志片段、对象元数据或获授权的运维检查结果；不要保存凭据、私钥、访问令牌或包含密码和密钥的完整环境变量。

markdown
# 首次运行验证记录

- 运行 ID：
- 启动清单版本/链接：
- 部署参数版本/链接：
- Job 名称：
- 提交 YAML 记录：
- 验证人：

| 检查项 | 结果（PASS / FAIL / BLOCKED） | 检查时间 | 记录位置 | 备注/负责人 |
| --- | --- | --- | --- | --- |
| 1. Job 已创建且配置一致 |  |  |  |  |
| 2. Pod 数量和所在节点正确 |  |  |  |  |
| 3. Ray 已按预期启动 |  |  |  |  |
| 4. 应用和配置版本一致 |  |  |  |  |
| 5. 业务有进展且输出已持久化 |  |  |  |  |
| 6. 结果已保存并明确后续处理 |  |  |  |  |

任何一项为 FAIL 或 BLOCKED 时，都不能把这次运行标为通过。先按照启动清单中的停止条件处理任务，再按照记录中的联系人和恢复路径解决问题。

检查 1：Job 已创建且配置一致 ​

  1. 提交后在任务列表找到精确的 Job 名称；列表通常每 10 秒自动刷新，也可以手动刷新。
  2. 打开详情，核对创建时间以及角色配置中的镜像、选择器、副本数、GPU/设备、挂载、环境变量、Header 和运行脚本与提交 YAML 一致。
  3. 记录 Job 当前状态。这个状态用于判断平台是否正在运行任务，不代表训练结果。

通过条件：Job 可以打开，页面配置与已保存的 YAML 一致，而且任务没有被意外停止。

不要只看这些摘要：列表中的“集群”来自 Task 选择器；任务列表的 Worker 总数和进度按 Task 数量计算；运行时长目前是占位值。这些信息不能说明实际 Pod 数量或训练进度。详情页有 Pod 信息时按当前 Pod 行计数，没有 Pod 信息时显示 Task 摘要，因此仍需检查预期副本和实际 Pod。

检查 2：Pod 数量和所在节点正确 ​

  1. 在详情的 Worker 标签逐行选择查看详情。Pod 子表显示名称、Node、IP 和阶段后，才能确认这一行对应实际 Pod；出现“暂无 Pod 详情，等待任务同步”时，本项检查尚未通过。
  2. 对每个子表中的实际 Pod 记录角色、Pod 名称、Node、Pod 阶段和 IP，并与管理员的全局匹配记录比较。控制台不显示数据面命名空间，需要由获授权的管理员确认命名空间与部署参数一致。
  3. 确认每个角色的实际 Pod 数等于获批副本数，且 Header 只有一个实际 Pod。
  4. 仍有疑问时，请获授权的运维人员检查 Pod 调度事件、容器状态和重启次数。

通过条件： 所有预期 Pod 都落在批准的 Node/命名空间，数量与角色正确，Header 实际 Pod 数为 1，且没有未解释的 Pending、失败或重启。

不要用于判断 Pod 是否正常：Worker 行的创建时间可能来自 Job 创建时间，节点类型可能根据名称或角色显示，CPU、内存、延迟和 FPS 也不是实际用量指标。没有 Pod 详情时显示的 Task 摘要不能说明 Pod 已经存在。参见检查 Worker 和 Pod。

检查 3：Ray 已按预期启动 ​

  1. 在日志标签分别选择 Header 和每个 Worker，检查准备脚本与 Ray 启动阶段。
  2. 找到启动清单中定义的启动标志；对 Header 额外取得 ray status 或等价信息，确认预期节点和进程已经加入。
  3. 检查镜像拉取、命令缺失、Python import ray、网络接口、Ray 地址和超时相关错误。

通过条件：每个角色都有对应的启动记录，Ray 拓扑与启动清单中的预期数量一致，并且日志中没有被启动脚本忽略的集群检查失败。

日志限制：日志页只读取当前 Pod 的 main 容器，每个 Pod 最多显示最后 1000 行，不包含上一个容器实例的日志。没有日志或读取失败时，日志区域也可能显示一条文本提示。时间范围不会改变查询内容；开启“实时”后，页面每 5 秒重新获取一次。需要更完整的日志时，请获授权的运维人员从目标集群补充。参见查看和导出日志。

检查 4：应用和配置版本一致 ​

运行脚本开始执行后，应用还需要在日志或运行记录中写出以下信息：

  • 本次运行 ID；
  • RLinf 仓库和完整提交 SHA；
  • 解析后的配置文件位置与校验和，包括基础配置、覆盖项和环境输入的结果；
  • 数据版本/校验和以及输出和检查点前缀；
  • 应用识别到的角色、rank/worker 数和关键运行时版本。

把这些值与启动清单逐项比较。镜像 digest 来自提交 YAML 和管理员的镜像拉取检查；应用还需要在日志或运行记录中输出实际代码版本和解析后的 Hydra 配置，再与启动清单核对。

通过条件：应用报告的运行 ID、配置哈希、数据版本和拓扑都与启动清单一致，没有来源不明的默认值或环境变量覆盖。

检查 5：业务有进展且输出已持久化 ​

  1. 等待启动清单中定义的最小业务进展信号，例如工作负载明确输出的一次训练、采集或评测里程碑。不要用通用示例替代启动清单中的判据。
  2. 在获批准的持久化位置确认预期文件或对象存在、大小合理且可以重新读取；按清单记录校验和、对象版本或其他可复核信息。
  3. 如果这次工作负载需要生成 checkpoint，请确认 checkpoint 使用本次运行的唯一前缀，并按任务自己的安全检查方式验证可加载性。不要为了测试恢复而覆盖原 checkpoint。

通过条件：在最大等待时间内出现清单中定义的业务信号，而且至少一个需要持久化的产物可以重新读取或通过等价检查。

不能单独作为通过条件：Job 指标页目前没有真实指标。TensorBoard 入口出现，只说明配置了目录和访问路径，不能说明 Header 已就绪、事件文件存在或训练正常。

检查 6：保存结果并明确后续处理 ​

  1. 汇总前五项检查结果，列出仍需运维人员确认的内容、联系人和下一步。
  2. 按启动清单的停止条件决定继续运行、由获授权人员停止，或保留任务用于排查。任务仍在生成唯一日志或输出时，不要为了演示而删除。
  3. 如果验证计划要求停止任务，先确认输出和 checkpoint 已持久化，再选择停止并确认 Pod 被缩容。当前“停止”是把任务副本缩为 0；之后“启动”会重新创建进程，不等同于从 checkpoint 恢复。
  4. 记录日志保留位置、输出和检查点的联系人、保留期限及后续问题链接。按平台流程清理秘密或临时访问授权，并记录执行结果。

通过条件：六项检查记录完整，已经明确任务是继续运行、停止还是保留排查；另一位获授权人员可以重新读取持久化结果；尚未确认的项目没有标成通过。

可使用下面的最终结论，不要扩大适用范围：

text
首次运行在 <time> 完成，使用启动清单 <manifest-ref> 和部署参数 <profile-ref>。
本次已确认 Job 创建、Pod 位于批准的节点、Ray 启动、应用与配置版本一致，并看到了清单中定义的最小业务进展和可回读的持久化输出。
结果只适用于这组代码、镜像、配置和环境，不能代替 RLinf 版本兼容表、通用训练配方、性能测试或真实机器人安全批准。

出现等待超时、Pod 缺失或日志不一致时，把结果标为未通过，并按首次运行问题排查找到最早出现问题的环节。需要更详细的检查方法时，参见训练任务与 Worker 故障排查。