跳转到正文

任务创建字段

创建任务时,可以用本页把表单字段与 YAML 预览中的 rlinf.io/v1alpha1 Job 对照起来。RLark Job 定义资源和运行结构;RLinf/Hydra 配置随镜像、配置文件或运行命令进入工作负载。YAML 预览只显示即将提交给 RLark 的资源定义。

首次提交前,请按照提交训练任务前检查整理工作负载信息。全局节点匹配、资源或存储条件无法自行确认时,请向平台管理员取得填写任务所需的信息;这不是 RLark 的审批记录。不要自行猜测环境默认值。

核对 Job 级字段

控制台字段写入位置表单行为和使用限制
任务名称metadata.name必须是 1–63 位小写 DNS 名称。
任务类型不写入 CRD只决定弹窗最初添加哪些角色。RL、数据采集、评测和自定义不是 Job API 中的类型字段。
Header 角色对应模板的 spec.tasks[].head只有选中的角色为 true。Head 标记会作用于该 Task 的所有副本,因此该角色必须只有 1 个副本。
网络域spec.domain可选,由各 Task 继承。选择 Domain 不会替应用设置通信网卡。
SSH 公钥spec.sshPublicKey可选,同一公钥会注入所有角色的 Pod。
运行脚本Header 模板的 runScript只写入 Head Task,但该 Task 的每个副本都会执行,因此必须保持单副本。
TensorBoard 日志目录Header 模板的 tensorBoardDir用于配置代理和 sidecar 的容器路径。训练程序把 event 文件写入该目录后,TensorBoard 才能读取。

核对每个角色的字段

控制台字段写入位置表单行为和使用限制
角色显示名称spec.tasks[].nameRLARK_TASK_ROLE显示名称会转换为小写 Task 名,并按名称映射为 ActorRolloutEnv。自定义名称不会创建新的 API 角色。
集群不写入独立字段用于筛选弹窗中的 Node、设备和 StorageClass。Task 命名空间由全部 Node 中的 nodeSelector 匹配结果决定。
节点选择nodeSelector只使用管理员在全部 Node 中验证过、由不同标签键组成且只命中预期集群的单值条件。
已选节点数StatefulSet replicas根据所选集群内的匹配节点数自动计算,不是可编辑的 Worker 数。还需确认其他集群中没有同标签节点。
GPU主容器 resources requests 和 limits 中的 nvidia.com/gpu非零值同时写入 request 和 limit。只有界面计算出大于 0 的上限时,才会阻止超额输入。
设备资源主容器 resources requests 和 limits 中的 rlinf.io/*非零值同时写入 request 和 limit。表单不会检查每个实际落点能否满足请求。
CPU、内存表单没有输入项Job 的 Pod 模板可以表达,但控制台创建器不会生成。必须声明时,请停止使用该弹窗并向平台管理员取得受支持的配置方式。
镜像main 容器的 image只检查非空。提交前还要验证仓库权限、digest、镜像内容和多角色兼容性。
准备脚本prepareScript在每个副本启动 Ray 前,由同一个 bash 包装进程执行。
环境变量main 容器的 env只属于对应角色,不会自动覆盖 Hydra 字段。不要填写敏感值。
主机目录Pod hostPath volume 和 volumeMount源路径属于 Worker 所在节点;每个实际落点都必须存在相同路径,并具备正确内容、空间和权限。训练程序使用 volumeMount 的容器路径。
对象存储PVC volume、volumeMount 和 pvcStorageMapStorageClass 必须可用于目标集群。Task 启动时确保对应 PVC;创建表单不直接填写 Bucket 或对象键,训练程序使用容器挂载路径及其下的相对对象路径。

填写这两个选项前,先按照在训练任务中使用存储确认数据位置、容器路径、StorageClass 和多 Worker 访问方式。

控制台还会固定生成:

  • agentType: Kubernetes
  • kind: StatefulSet 工作负载;
  • 名为 main 的业务容器;
  • 平台生成的 RLARK_TASK_ROLE
  • Ray Head 或 Worker 包装脚本及平台环境变量。

Task API 还可以表达其他 Kubernetes 工作负载、Docker 和 Raw 类型,但控制台没有对应的创建流程。

分别映射 RLark 和 Hydra 配置

RLark Job 定义资源和运行结构,RLinf 工作负载带入 Hydra 应用配置。创建 Job 时,需要把两侧配置逐项映射;平台不会自动转换。

RLinf/Hydra 内容RLark 中最接近的表达提交前核对
cluster.node_groups角色、nodeSelector 和副本数确认节点数量、GPU 拓扑和进程布局一致;RLark 不导入 Node Group。
cluster.component_placement角色级资源和落点确认每个角色对应正确的 RLinf placement strategy;角色名称不会自动转换。
node_groups[].env_configs角色环境变量、准备脚本或外部配置文件确认脚本或应用读取对应值;RLark 不读取这些 Hydra 字段,也不会在两处之间同步。
hardware rank平台生成的 RLINF_NODE_RANK核对 Task 顺序、副本数和 StatefulSet Pod 序号是否与 Hydra placement 的顺序一致。
runner.resume_dir、logger 和算法参数外部 Hydra 文件或经过验证的运行脚本 override在 RLinf 配置或运行脚本中固定这些值;Job CRD 不包含对应字段。

迁移任务时,分别检查:

  1. RLark 的角色、节点、资源、脚本和挂载是否表达了正确的基础设施要求。
  2. 目标镜像中的 RLinf/Hydra 配置是否表达了正确的应用要求。
  3. 进程数量、rank、路径和网络假设是否逐项对齐。

YAML 预览正确,只能确认 Job CRD 的内容,不能确认 RLinf 配置已经兼容。

保存实际使用的运行配置

任务运行时需要分别核对以下来源:

  1. 镜像提供代码、Python/Ray 环境、默认文件和系统依赖。RLark 会覆盖主容器 ENTRYPOINT,不要依赖原入口产生的副作用。
  2. 外部 Hydra YAML由镜像中的 RLinf 入口按对应版本组合和插值;RLark 不读取它。
  3. Pod 环境变量只有被 Hydra、脚本或应用显式读取时,才会影响业务配置。
  4. 准备脚本可以在 Ray 启动前激活环境或准备文件。
  5. 运行脚本中的命令行 override由应用解释,RLark 按表单内容执行脚本文本。

这些来源的优先级由 RLinf、Hydra 和脚本决定,控制台不会把它们合并成统一的覆盖顺序。例如,同名环境变量是否覆盖 Hydra 值,取决于应用自己的配置逻辑。

控制台的 YAML 预览只显示 Job CRD,不会导入或解析 Hydra YAML。提交前,按训练任务启动前检查生成并保存脱敏的 RLinf 最终配置,再与镜像 digest、Hydra 输入和 Job YAML 一并归档。比较两次运行时,请使用各自保存的最终配置和运行记录。