
人工智能大模型强化学习AI Agent微调【免费下载链接】OpenClaw-RLOpenClaw-RL: Train any agent simply by talking项目地址https://gitcode.com/gh_mirrors/op/OpenClaw-RL点击查看免费下载本文围绕 slime/tests/ci/README.md 展开系统讲解 OpenClaw-RL 仓库中 slime 子项目如何构建一套面向大规模强化学习RL训练的 GitHub Actions 持续集成CI体系从 GitHub Secrets 配置、自托管 GPU Runner 的容器化部署到 GPU 锁竞争机制与端到端训练测试的编排。读完本文你将掌握如何在自有 GPU 机器上完整复刻一套支持多 Runner 并发、资源互斥、可快速调试的 RL 训练 CI 环境。一、为什么需要一套自托管 GPU CIslime 是 OpenClaw-RL 仓库中的大规模 RL 训练框架其测试以端到端e2e训练脚本为主。以 tests/test_qwen2.5_0.5B_gsm8k_short.py 为例一个测试就需要拉起 SGLang rollout 引擎与 Megatron 训练后端真正运行 Qwen2.5-0.5B 的 GRPO 训练并完成 GSM8K 评测——这显然不是 GitHub 托管的ubuntu-latest虚拟机所能承担的工作负载。因此slime 的 CI 采用了GitHub 托管跑格式检查 自托管跑 GPU 训练的混合策略pre-commit.yml 使用ubuntu-latest托管 Runner负责代码风格与静态检查pr-test.yml 与 conda-ci.yml 声明runs-on: self-hosted在带有 GPU 的裸机/容器 Runner 上执行真正的训练测试。整个自托管 Runner 的搭建方法、资源互斥机制与调试手段正是本文的核心内容。二、第一步配置 GitHub SecretsCI 训练过程中需要将训练指标上报到 Weights BiasesWB平台工作流中通过secrets.WANDB_API_KEY注入见 pr-test.yml 的env段。配置方式为进入 GitHub 仓库的Settings → Secrets and variables → Actions页面添加名为WANDB_API_KEY的 repository secret其值在 WB 账号的授权页面获取https://wandb.ai/authorize对应的 Authorize 页面保存后CI 工作流即可在运行时自动解密注入。从源码层面看该 Key 的作用链路清晰测试脚本通过U.get_default_wandb_args(__file__)见 command_utils.py读取环境变量WANDB_API_KEY若不存在则跳过 wandb 配置并打印提示存在则生成--use-wandb --wandb-project slime-{测试名} --wandb-group {run_id}_{GITHUB_COMMIT_NAME}等参数其中GITHUB_COMMIT_NAME由工作流设为${{ github.sha }}_${{ github.event.pull_request.number }}保证每个 commit 的训练曲线可追溯。三、第二步搭建新的 GitHub Runner三步骤详解Step 1编写.env环境文件在 github_runner 目录下仿照.env.example编写.env文件GITHUB_RUNNER_URLhttps://github.com/THUDM/slime GITHUB_RUNNER_TOKENpaste-your-token-here其中GITHUB_RUNNER_TOKEN从 GitHub 仓库的Settings → Actions → Runners → New self-hosted runner页面选择 Linux x64 架构获取。特别注意该 Token 具有时效性会在一段时间后失效需在部署前重新获取。从 docker-compose.yml 可以看到这两个变量在容器启动时通过 entrypoint 被消费/home/runner/config.sh --url ${GITHUB_RUNNER_URL} --token ${GITHUB_RUNNER_TOKEN} ...完成 Runner 注册。Step 2准备/home/runner/externalsRunner 镜像运行在宿主机之外需要将官方 Runner 镜像内的externalsRunner 运行时依赖的外部可执行文件集复制到宿主机目录供容器以卷挂载方式使用。文档给出了一组可直接执行的命令# 1) 在宿主机上创建 externals 目录借助特权容器操作根文件系统 docker run --rm -it --privileged --pidhost -v /:/host_root ubuntu /bin/bash -c rm -rf /host_root/home/runner/externals mkdir -p /host_root/home/runner/externals chmod -R 777 /host_root/home/runner/externals # 2) 启动一个临时容器将镜像内的 externals 拷贝出来 docker run -d --name temp-runner ghcr.io/actions/actions-runner:2.328.0 tail -f /dev/null docker cp temp-runner:/home/runner/externals/. /home/runner/externals docker rm -f temp-runner # 3) 校验拷贝结果 ls -alh /home/runner/externals注意--privileged --pidhost -v /:/host_root的组合会以宿主机根目录为挂载点执行写操作务必在专用 CI 机器上执行避免误操作生产环境。Step 3启动 Runner 集群cd /mnt/data/tom/primary_synced/slime/tests/ci/github_runner docker compose up -d在实际使用中将cd路径替换为你本地仓库中 github_runner 目录的绝对路径。四、深入 docker-compose8 副本 Runner 集群的配置解析github_runner/docker-compose.yml 是整个部署的核心关键配置如下配置项值说明imageghcr.io/actions/actions-runner:2.329.0官方 Runner 镜像。注释强调必须保持最新否则 Runner 会试图自我升级导致版本漂移问题volumes/var/run/docker.sock、/data/slime_ci、/home/runner/externals分别提供 Docker-in-Docker 能力、共享 CI 工作区模型/数据集缓存、Runner 运行时依赖deploy.replicas8单台宿主机拉起 8 个 Runner 副本构成一个小型并发池restartalways容器异常退出后自动拉起保证 CI 可用性environmentRUNNER_ALLOW_RUNASROOT: 1允许以 root 身份运行 Runner官方默认禁止privileged/usertrue/root特权容器模式赋予 GPU 与内核能力访问entrypointconfig.shrun.sh每次启动先注册再运行entrypoint 的核心逻辑值得展开entrypoint: sh -c cd /data/slime_ci /home/runner/config.sh --url ${GITHUB_RUNNER_URL} --token ${GITHUB_RUNNER_TOKEN} --unattended --work /data/slime_ci/runner_$(hostname) --disableupdate /home/runner/run.sh --unattended无交互式注册--work /data/slime_ci/runner_$(hostname)每个副本使用以主机名为后缀的工作目录避免多个副本抢占同一_work目录--disableupdate禁用自动更新配合镜像保持最新策略源码注释中还留有 TODOconfig.sh不应重复执行暗示长生命周期下可能存在的注册状态问题部署时值得关注。五、调试与快速迭代文档给出了完整的运维三板斧# 查看所有容器日志compose 聚合 docker compose logs -f # 只看某一个 Runner 容器 docker logs -f github_runner-runner-1 # 进入容器排查如检查 config.sh 注册状态 docker exec -it github_runner-runner-1 /bin/bash快速迭代模式重置并重启整个集群docker compose down -v docker compose up -d docker logs -f github_runner-runner-1-v会连带删除匿名卷适合反复调试注册流程down up保证 8 个副本以全新状态重新注册。六、GPU 资源互斥gpu_lock_exec.py的锁机制多个 Runner 副本并发抢占同一批 GPU 时若不做资源互斥训练测试会互相踩踏。slime 为此提供了 tests/ci/gpu_lock_exec.py它基于fcntl.flock文件锁实现了一套按需持锁、用完释放的 GPU 分配器其工作方式如下锁文件默认以/dev/shm/custom_gpu_lock_{gpu_id}.lock为每张 GPU 创建独立锁文件可通过--lock-path-pattern自定义且必须包含{gpu_id}占位符持锁通过FdLock.lock()对 fd 执行flock(LOCK_EX | LOCK_NB)非阻塞排他加锁os.set_inheritable(fd, True)保证execvp替换进程后锁依然有效训练进程存活期间锁不会丢分配策略--devices 0,1指定显式 GPU 集合--count N则自动扫描并凑齐任意 N 张空闲 GPU_try_acquire_count等待与超时获取失败时以SLEEP_BACKOFF * random()随机退避重试默认退避上限 5 秒--timeout控制最长等待时间默认 24 小时探测模式--print-only不加锁只探测输出当前空闲 GPU 列表可用于人工排障注入环境变量成功持锁后把选中的 GPU 列表以逗号分隔写入--target-env-name默认CUDA_VISIBLE_DEVICES随后execvp替换自身启动真正的测试命令。典型用法来自 CI 工作流与文档注释# 申请任意 4 张空闲 GPU 运行 GSM8K 短测试 python tests/ci/gpu_lock_exec.py --count 4 -- python tests/test_qwen2.5_0.5B_gsm8k_short.py # 指定 GPU 0,1 并设置 10 分钟等待超时 python tests/ci/gpu_lock_exec.py --devices 0,1 --timeout 600 -- python tests/test_qwen3_0.6B_fsdp_distributed.py七、CI 工作流如何调度这些测试pr-test.yml 是 GPU 测试的调度中枢其设计要点按标签触发e2e-test-short、e2e-test-fsdp、e2e-test-megatron、e2e-test-long等 job 各自绑定形如run-ci-short、run-ci-fsdp的 PR 标签只有被打上对应标签才会执行避免每次 push 都跑全量并发控制concurrency.group以工作流 PR 号为 keycancel-in-progress: true保证同一 PR 的新 commit 会取消旧任务容器化运行job 使用slimerl/slime:latest镜像options中挂载--gpus all、--ipchost、--shm-size16g、--ulimit memlock-1并把/data/slime_ci下的模型与数据集缓存目录挂载进容器矩阵并行strategy.matrix列出多个(num_gpus, test_file)组合例如e2e-test-megatron同时跑 GLM4-9B、Qwen3-30B-A3B含 DeepEP FP8 rollout 变体、Qwen3-4B PPO、Moonlight-16B-A3B 等 8 卡测试执行入口统一每个 job 的 Execute 步骤都是python tests/ci/gpu_lock_exec.py --count ${{ matrix.info.num_gpus }} -- python tests/${{ matrix.info.test_file }}——即先通过第六节的锁机制申请 GPU再运行具体测试环境变量透传WANDB_API_KEY、SLIME_TEST_ENABLE_INFINITE_RUN、SLIME_TEST_USE_DEEPEP、SLIME_TEST_USE_FP8_ROLLOUT、SLIME_TEST_ENABLE_EVAL统一注入控制测试的开关与精度变体。其中SLIME_TEST_ENABLE_INFINITE_RUN由 command_utils.py 的get_env_enable_infinite_run()消费支持workflow_dispatch手动触发无限训练模式。八、测试脚本中的 CI 模式与容错开关除了基础设施测试脚本本身也内建了 CI 适配逻辑保证本地可跑、CI 可验。以 test_qwen2.5_0.5B_gsm8k_short.py 为例脚本拼接完整的训练参数rollout、GRPO、优化器、SGLang 引擎、容错等并统一追加--ci-test标志启动前显式清除http_proxy/https_proxy等代理环境变量避免代理干扰训练中的网络通信工作流本身通过-e http_proxy$http_proxy透传代理用于拉取依赖训练阶段则需移除。--ci-test标志在源码中有多处联动见 arguments.py 的add_ci_arguments开启--ci-fault-tolerance时ray/rollout.py 会在第 2 个 rollout 触发故障注入验证健康检查与自动恢复链路megatron_utils/model.py 中启用 KL 检查器可被--ci-disable-kl-checker关闭并限制 MTPMulti-Token Prediction训练行为metric_utils.py 结合--ci-metric-checker-key/--ci-metric-checker-threshold对关键训练指标做阈值断言让 CI 能自动判定训练质量是否达标。九、从零到一部署清单综合全文在一台新 GPU 机器上落地 slime 自托管 CI 的完整清单如下仓库侧在 GitHub 仓库 Actions Secrets 中添加WANDB_API_KEYRunner 侧获取新的 runner token在 github_runner 下编写.env参照 .env.example宿主侧按第三节 Step 2 的命令准备/home/runner/externals并确认/data/slime_ci目录存在模型、数据集缓存的共享工作区启动docker compose up -d拉起 8 副本 Runner用docker compose logs -f观察注册与心跳验证在 PR 上打对应标签如run-ci-short触发 pr-test.yml观察gpu_lock_exec的加锁日志与训练曲线。至此一套支持多 Runner 并发、GPU 互斥分配、训练质量自动校验的 RL 训练 CI 环境即可稳定运行。赞分享人工智能大模型强化学习AI Agent微调【免费下载链接】OpenClaw-RLOpenClaw-RL: Train any agent simply by talking项目地址https://gitcode.com/gh_mirrors/op/OpenClaw-RL点击查看免费下载相关推荐three.js 快速上手3 步 10 分钟让网页跑起 3D 场景three.js 快速上手3 步 10 分钟让网页跑起 3D 场景 网页里加一块 3D 内容你大概率栽过两种跟头裸写 WebGL光一个漫反射就要几十行前端3D渲染图形学边缘AI部署新标杆LFM2.5-230M-GGUF如何实现质量、速度与内存效率的完美平衡边缘AI部署新标杆LFM2.5 230M GGUF如何实现质量、速度与内存效率的完美平衡 LFM2.5 230M GGUF是由Liquid AI开发的新一代洛雪音乐音源配置全攻略解锁全网高品质音乐资源洛雪音乐音源配置全攻略解锁全网高品质音乐资源 洛雪音乐音源项目为音乐爱好者提供了一个完整的解决方案帮助用户获取全网主流音乐平台的高品质音频资源。通过开源技术音视频创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考