跳转到正文

RLark 与 RLinf ​

RLinf 定义算法、Hydra 配置、组件放置和训练程序。RLark 根据你在 Web 控制台中填写的节点、资源、镜像、脚本和挂载创建 Job 与 Worker,并为这次运行启动 Ray 集群。

图表预览

把 RLinf 配置映射到 RLark ​

在控制台中选择创建任务时,提交的是一个 RLark Job。Job 中的每个角色描述一组按相同配置启动的 RLark Worker。当前 Kubernetes 运行方式下,每个 Worker 对应一个 Pod,并在 Pod 中启动一个 Ray 节点。RLinf 再根据 node_groups 和 component_placement,在这些 Ray 节点及其 GPU 或设备上运行 Actor、Rollout、Env 等组件。

角色名称不是 RLinf 组件放置规则

角色列表沿用了 Actor、Rollout、Environment 这些 RLinf 常见名称,但在 RLark 中,它们表示 Worker 组的配置模板。角色名称不会把同名 RLinf 组件自动放入这些 Worker。

先按照 cluster.num_nodes、node_groups 和实际运行条件确定需要多少个 Worker、怎样分组,再填写 RLark 角色。不要仅因为 component_placement 中出现 Actor、Rollout 和 Env,就创建三个同名角色。

同一台物理机器可以运行多个 RLark Worker,每个 Worker 仍是独立的 Pod 和 Ray 节点,并分别申请资源。RLinf 组件是否共享 GPU,只由 component_placement 中的资源范围决定,不能根据角色名称或物理机器是否相同判断。

cluster.num_nodes: 1 且一个 GPU 节点能够提供全部运行条件时,可以直接按照在单个 GPU 节点上运行 RLinf操作。多节点、多个 node_groups 或不同 Worker 需要不同运行条件时,先阅读规划多节点和异构 Worker,再进入创建训练任务。需要了解 Job 提交后的编排关系时,再查看 Job、角色、Worker 与 Task。

准备运行所需的信息 ​

下表用于确认已有 RLinf 内容如何进入 RLark,以及运行后在哪里核对结果。

已有内容在 RLark 中如何提供运行后核对
RLinf 代码、Python/Ray 环境和系统依赖固化到可追溯的镜像,并在角色中填写镜像地址和明确版本从日志或运行记录确认代码 commit、镜像版本和运行时版本
Hydra 配置、命令行覆盖项和 component_placement随镜像或挂载提供,通过运行脚本启动;RLark 不会导入或改写这些配置保存解析后的最终配置,并核对 node_groups、组件进程和资源范围
cluster.num_nodes、每个节点的 GPU/设备和运行环境映射为一个或多个角色;各角色的 Worker 数之和应与 cluster.num_nodes 一致核对实际 Worker、Ray 节点、RLINF_NODE_RANK 和每个 Worker 可见的资源
数据、模型、checkpoint 和输出路径通过镜像、主机目录或对象存储挂载到 Worker确认应用使用容器内挂载路径,并能重新读取需要保留的输出

RLark 不计算 Hydra 配置的最终合并结果,也不会自动判断训练是否有效。提交后仍要按照工作负载自己的日志、业务信号、checkpoint 和持久输出检查运行结果。

确认版本兼容性 ​

使用目标环境确认过的版本组合

控制台会保存镜像引用,但不会验证镜像中的 RLinf、Ray、CUDA 和驱动是否兼容。目标环境提供兼容表或经过验证的镜像时,请使用其中的版本组合;没有这类资料时,请先在目标环境验证本次使用的 commit、镜像版本和依赖。

为本次运行记录:

  1. 上游 RLinf 或 fork 的精确 commit,以及补丁来源;
  2. RLinf、Python、Ray、CUDA、驱动和设备依赖版本;
  3. 镜像地址和明确版本;需要精确复现时,按选择镜像版本和执行入口补全镜像记录;
  4. 原始 Hydra 配置、命令行覆盖项和解析后的最终配置;
  5. 数据集、模型、checkpoint 和输出位置;
  6. 预期 Worker 数、每个 Worker 的资源和节点分组;
  7. 可以确认应用启动、业务进展和运行失败的日志或输出。

能够打开创建页面或生成 Job YAML,只说明表单内容可以提交给 RLark,不能代替上述兼容性检查。

继续准备任务 ​