slime 项目 CI 体系深度解析双层测试架构、GPU E2E 工作流与测试编写实战【免费下载链接】slimeslime is an LLM post-training framework for RL Scaling.项目地址: https://gitcode.com/GitHub_Trending/slime12/slime本篇技术指南聚焦 slimeLLM post-training / RL Scaling 训练框架仓库的持续集成体系它如何以「默认运行的 CPU 正确性测试 label 触发的 GPU end-to-end 测试」双层结构在快速反馈与真实 Megatron SGLang 训练路径覆盖之间取得平衡。读完本文你将掌握 slime CI 的完整工作原理、每个 label 与 job 的触发关系、prepare()/execute()e2e 测试编写范式、GPU 锁申请机制以及如何通过 Jinja2 模板安全地修改 CI matrix。为什么 CI 要拆成两层slime 的训练与 rollout 涉及 Megatron 训练后端、SGLang 推理引擎、Ray 调度、分布式 checkpoint 等大量组件完整跑一次训练会消耗大量 GPU 时间。因此 CI 被有意拆成两层这个设计决策贯穿整个仓库默认运行的 CPU 正确性测试每个 PR、每次 push 到main、以及手动workflow_dispatch都会运行。它覆盖纯逻辑层面的正确性不变量correctness invariant不等待 GPU 集群即可快速检查。通过 label 触发的 GPU end-to-end 测试在自托管 GPU runner 上验证真实的 Megatron SGLang training/rollout 路径。正如文档所述这个拆分是刻意的大部分 correctness invariant 应该在不等待 GPU 集群的情况下快速检查真正依赖完整训练和 rollout 的行为则由 GPU e2e job 覆盖。前者的目标是快后者的目标是真两者互补而非替代。工作原理模板驱动的工作流slime 的 CI workflow 定义在 .github/workflows/pr-test.yml但不要直接编辑它——该文件由 Jinja2 模板 .github/workflows/pr-test.yml.j2 自动生成。CPU JobsCPU job 运行在 GitHub-hosted 的ubuntu-latestrunner 上有两个 jobcpu-unittest安装 CPU 版 PyTorch 和轻量依赖然后通过python tests/test_file.py运行注册的 unit/contract tests。agent-adapter-test以同样方式运行 agent adapter tests但额外安装openai、openai-agents、anthropic等 provider SDK 依赖这部分测试被单独拆出正是因为它们有额外的第三方依赖。从模板源码pr-test.yml.j2可以看到 CPU job 的依赖安装细节通过pip install torch --index-url https://download.pytorch.org/whl/cpu安装纯 CPU PyTorch再安装pytest numpy packaging pyyaml omegaconf tqdm httpx requests ray pybase64 pylatexenc sympy aiohttp pillow safetensors psutil等轻量依赖最后pip install -e . --no-deps安装 slime 本体。CPU job不使用 Docker、不申请 GPU、也不会调用tests/ci/gpu_lock_exec.py。执行时通过matrix.info.num_gpus判断为0时直接运行否则走 GPU 锁路径。GPU E2E JobsGPU job 运行在自托管 GPU runner上每个 job 依次执行四个步骤启动 Docker container通常使用slimerl/slime:latest镜像验证使用slimerl/slime-test:latest。在容器内通过pip install -e . --no-deps --break-system-packages安装 slime。通过python tests/ci/gpu_lock_exec.py --count num_gpus申请所需 GPU。执行注册的测试文件python tests/test_file.py。模板中的 Docker 启动参数值得注意它完整反映了 GPU 训练环境的需求见 pr-test.yml.j2docker run --pullalways --rm \ --privileged \ --cap-add SYS_NICE \ --security-opt seccompunconfined \ --network host \ --gpus all \ --ipchost \ --shm-size16g \ --ulimit memlock-1 \ --ulimit stack67108864 \ --memory0 \ --memory-swap0 \ ...其中--network host用于 Ray/SGLang 的分布式通信、--shm-size16g保证共享内存充足、--ulimit memlock-1取消内存锁定限制Megatron/ NCCL 常用、--memory0 --memory-swap0不限制容器内存。容器还会挂载宿主机共享目录-v /mnt/nvme0n1/slime_ci/models:/root/models和-v /mnt/nvme0n1/slime_ci/datasets:/root/datasets用于缓存已下载的模型与数据集避免每个 job 重复下载。GPU 测试通常遵循e2e 模式prepare()下载模型和数据集execute()构建 CLI 参数并调用U.execute_train(...)U是 slime/utils/external_utils/command_utils.py 的别名。U.execute_train内部会先清理残留的 sglang/ray/redis/slime 进程随后ray start --head拉起 Ray 集群最后通过ray job submit将训练任务提交到集群执行并注入PYTHONPATH、CUDA_DEVICE_MAX_CONNECTIONS、NCCL_NVLS_ENABLE按是否检测到 NVLink 自动设置等运行时环境变量。Changed-Test Jobrun-ci-changed是一个动态检测机制它相对origin/main找出新增或修改的tests/test_*.py和tests/plugin_contracts/test_*.py文件并为每个文件构建 matrix。关键逻辑在模板的e2e-test-changed-detectjob 中CHANGED$(git diff --name-only --diff-filterAM origin/main...HEAD -- tests/test_*.py tests/plugin_contracts/test_*.py || true) # 对每个文件提取 NUM_GPUS缺省时默认为 8 NGPU$(grep -oP ^NUM_GPUS\s*\s*\K\d $filepath | head -1) NGPU${NGPU:-8}也就是说如果测试文件缺少NUM_GPUS常量CI 会默认使用8因此纯 CPU 测试文件必须显式声明NUM_GPUS 0changed-test job 本身走 self-hosted Docker 路径当NUM_GPUS 0时它直接运行测试、不申请 GPU。CI Jobs 与触发方式一览TriggerJob类型说明自动运行cpu-unittestCPU默认运行的 unit/contract tests覆盖 argument validation、schedule、reward、sample、rollout validation、checkpoint utilities 和 plugin contracts。自动运行agent-adapter-testCPU默认运行的 agent adapter tests包含额外 provider SDK 依赖。run-ci-sglang-confige2e-test-sglang-configGPUSGLang config 测试覆盖高级 rollout engine deployment 和 mixed/offload 场景。run-ci-megatrone2e-test-megatronGPU核心 Megatron 训练测试覆盖 dense、MoE、PPO、MTP、OPD、async rollout、PD/Mooncake 和 debug replay 路径。run-ci-precisione2e-test-precisionGPU数值精度和并行一致性检查。run-ci-ckpte2e-test-ckptGPUCheckpoint save/load 正确性包括 CPU/GPU optimizer state 和 async save。run-ci-imagee2e-test-imageGPU在slimerl/slime-test:latest上运行与run-ci-megatron相同的 matrix。run-ci-changede2e-test-changedMixed只运行 changed tests并使用每个文件中的NUM_GPUS。也可以在 Actions 页面通过workflow_dispatch手动验证它会按照 workflow 条件运行注册的 jobs。workflow_dispatch还提供一个infinite_run布尔输入配合环境变量SLIME_TEST_ENABLE_INFINITE_RUN可以让训练无限运行用于长时间稳定性验证。从模板源码可以进一步确认 label 的判定逻辑pr-test.yml.j2if: (github.event_name workflow_dispatch) || (github.event.pull_request contains(github.event.pull_request.labels.*.name, label))即 GPU job 只在两种情况下触发手动 workflow_dispatch或 PR 被打上对应 label。而自动 job 的条件是github.event_name pull_request || github.event_name workflow_dispatch || github.event_name push。此外 workflow 声明了concurrency分组和cancel-in-progress: true同一 PR/ref 的新提交会取消旧运行push 到main专门触发默认的 CPU job用于捕获两个 PR 单独通过、合并后 main 损坏的 PR-pair 回归见模板顶部注释。CPU Unit Tests正确性第一道防线CPU suite 是 correctness 的第一道防线用来在进入昂贵 GPU run 之前捕获 silent RL infrastructure bugs。当前注册的 CPU suite 覆盖对应 pr-test.yml.j2 中cpu-unittest的 tests 列表共 50 个文件Megatron argument 和 HF config validation如 tests/test_megatron_argument_validation.pyDP/CP scheduling utilities 和 CP loss invariancetests/test_dp_schedule.py、tests/test_cp_utils.py、tests/test_loss_cp_invariance.pymetric reporting 和 distributed metric aggregationtests/test_metric_report.py、tests/test_metric_report_dist.pymath、GPQA、F1、DeepScaler、DAPO-style math 等 reward-model grading utilitiestests/test_rm_math.py、tests/test_rm_gpqa.py、tests/test_rm_f1.py、tests/test_rm_deepscaler.py、tests/test_rm_math_dapo.pySample行为、rollout validation 和 agent trajectory mergingtests/test_sample.py、tests/test_process_rollout_data.pyHF checkpoint saver 行为tests/utils/test_hf_checkpoint_saver.pyrollout function、generate function、runtime hook 和 path loading 的 customization hook contractstests/plugin_contracts/test_plugin_generate_contracts.py 等四个 contract 测试另有 PPO loss/advantage/whiten、FP8、stateless Adam、layerwise alignment、reloadable process group、placement group、expert routing 等基础设施测试。Agent adapter teststests/test_agent/ 下的 5 个文件单独放在agent-testjob 中因为它们需要额外 SDK 依赖。常用本地命令在仓库根目录直接执行python tests/test_agent/test_trajectory_manager_branching.py python -m pytest tests/test_megatron_argument_validation.py tests/plugin_contracts/test_plugin_generate_contracts.py值得说明的是CPU 测试文件普遍以顶层NUM_GPUS 0声明自身不需要 GPU见 tests/test_megatron_argument_validation.py 第 9 行这样即便被run-ci-changed动态拾取也只会走纯 CPU 路径。GPU E2E Tests验证 CPU 测不到的真实训练路径GPU e2e tests 验证 CPU tests 无法覆盖的集成训练/rollout 行为run-ci-sglang-config高级 SGLang deployment path包括 config-based engine layoutstests/test_sglang_config_mixed_offload.py、tests/test_qwen2.5_0.5B_sglang_config_distributed.py 等 6 个文件。run-ci-megatron主要 Megatron backend coverage。从模板中的megatron_tests变量可以看到其矩阵规模——约 25 条测试条目覆盖 dense/MoE recipetests/test_qwen3_30B_A3B.py、tests/test_moonlight_16B_A3B.py、async rollouttests/test_qwen2.5_0.5B_fully_async_short.py、OPDtests/test_qwen2.5_0.5B_opd_sglang.py、PPO-style pathtests/test_qwen3_4B_ppo.py、tests/test_qwen3_4B_ppo_disaggregate.py、PD/Mooncaketests/test_qwen3.6_35B_A3B_pd_mooncake.py和 debug rollout-then-train replaytests/test_qwen2.5_0.5B_debug_rollout_then_train.py。单个 job 还可以携带test_args如 checkpoint 测试的 optimizer state 组合、use_deepep、use_fp8_rollout、enable_eval等 matrix 附加字段。run-ci-precision不同并行设置下的数值一致性tests/test_qwen3_0.6B_parallel_check.py。run-ci-ckptcheckpoint save/load 组合和 async save——同一测试文件 tests/test_qwen3_4B_ckpt.py 以不同test_args注册 5 次--save-optimizer gpu --load-optimizer gpu、gpu/cpu、cpu/cpu、cpu/gpu四种 optimizer state 迁移组合外加--async-save异步保存。run-ci-image与run-ci-megatron相同的 matrix但运行在slimerl/slime-test:latestrelease/test image 上用于验证新镜像没有破坏既有测试。日常 PR 优先使用 targeted labels。run-ci-image消耗 GPU 时间较多相当于把整个 megatron matrix 重跑一遍应谨慎使用。GPU 锁机制gpu_lock_exec 深入GPU job 的核心步骤之一是 tests/ci/gpu_lock_exec.py它在共享的自托管 GPU 机器上实现基于fcntl.flock的文件锁调度。其命令行接口python tests/ci/gpu_lock_exec.py --count num_gpus [--devices 0,1] [--total-gpus 8] [--timeout 86400] \ [--target-env-name CUDA_VISIBLE_DEVICES] [--lock-path-pattern /dev/shm/custom_gpu_lock_{gpu_id}.lock] \ [--print-only] -- command主要参数与行为--count申请任意N个空闲 GPU--devices则指定具体的 GPU id 列表二者互斥。--total-gpus宿主机 GPU 总数默认8即单台 H100 节点的标准配置。--timeout等待锁的超时秒数默认 24 小时超时抛TimeoutError。--target-env-name默认将获取到的设备列表写入CUDA_VISIBLE_DEVICES环境变量模板中的默认用法也可以改成其他变量名。--lock-path-pattern锁文件路径模式默认/dev/shm/custom_gpu_lock_{gpu_id}.lock放在/dev/shm是 tmpfs进程退出自动清理避免残留锁文件。--print-only只探测并打印当前空闲 GPU不持有锁。获取锁后工具将 GPU 列表写入指定环境变量如CUDA_VISIBLE_DEVICES0,2,3,5再以子进程方式执行--之后的命令。获取锁采用非阻塞flock(LOCK_EX | LOCK_NB) 指数退避重试SLEEP_BACKOFF 5.0乘以随机因子的策略工具还会接管SIGINT/SIGTERM/SIGHUP在收到信号时先终止子进程再退出并归一化负 returncode128 - returncode。获取到--devices指定的 GPU 时会按顺序逐个阻塞等待。该工具支持lslocks排查锁状态源码注释中明确提示。在 workflow 中的典型用法CPU 为 0 时不加锁直接运行if [ $NUM_GPUS 0 ]; then python $TEST_PATH ${TEST_ARGS_ARRAY[]} else python tests/ci/gpu_lock_exec.py --count $NUM_GPUS -- python $TEST_PATH ${TEST_ARGS_ARRAY[]} fi编写新测试CPU Tests对于 CPU-only tests遵循 4 个步骤按照附近文件的模式将测试放在tests/test_*.py、tests/utils/test_*.py或tests/plugin_contracts/test_*.py下。如果这个文件可能被run-ci-changed运行添加顶层NUM_GPUS 0。让文件可以直接执行if __name__ __main__: raise SystemExit(pytest.main([__file__]))如果测试需要永久进入 CI matrix在 .github/workflows/pr-test.yml.j2 的cpu-unittest或agent-adapter-testjob 中注册然后重新生成 workflow见下文Workflow 生成。GPU E2E Tests对于 GPU e2e tests创建tests/test_your_test_name.py遵循已有的prepare()/execute()模式。用NUM_GPUS N声明所需 GPU 数量。在prepare()中下载所需模型和数据集。在execute()中构建参数并调用U.execute_train(...)。在 .github/workflows/pr-test.yml.j2 的合适 GPU job 中注册测试然后重新生成 workflow。官方示例骨架含清理代理环境变量的细节——因为容器内下载需要代理而训练进程通常不应带代理import os import slime.utils.external_utils.command_utils as U MODEL_NAME Qwen2.5-0.5B-Instruct MODEL_TYPE qwen2.5-0.5B NUM_GPUS 4 def prepare(): U.exec_command(mkdir -p /root/models /root/datasets) U.exec_command(fhf download Qwen/{MODEL_NAME} --local-dir /root/models/{MODEL_NAME}) def execute(): # 构建参数字符串并调用 U.execute_train(...) ... if __name__ __main__: prepare() for proxy_var in (http_proxy, https_proxy, HTTP_PROXY, HTTPS_PROXY): os.environ.pop(proxy_var, None) execute()一个真实参照是 tests/test_qwen2.5_0.5B_debug_rollout_then_train.py它声明MODEL_NAME Qwen2.5-0.5B-Instruct、MODEL_TYPE qwen2.5-0.5B、NUM_GPUS 8prepare()中下载模型和 GSM8K 数据集execute()拆成两阶段——execute_rollout_only用--debug-rollout-only启动 SGLang 生成两轮 rollout 并保存到临时目录execute_train_only则用--load-debug-rollout-data跳过 SGLang、加载已保存数据直接训练两步验证了 rollout-then-train 的两阶段调试链路。Uslime/utils/external_utils/command_utils.py还提供了convert_checkpointHF → torch_dist 权重转换自动读取scripts/models/type.sh中的MODEL_ARGS、hf_download_dataset、fp8_cast_bf16、get_default_wandb_args自动根据测试文件名生成--use-wandb --wandb-project slime-test_name参数等便捷函数以及NUM_GPUS_OF_HARDWARE {H100: 8, GB200: 4, GB300: 4}等硬件配置常量可用于编写多硬件适配的测试。Workflow 生成pr-test.yml由 Jinja2 模板pr-test.yml.j2自动生成不要直接编辑pr-test.yml——生成的 YAML 文件头部带有auto-generated警告注释直接修改会在下次生成时被覆盖。如果要修改固定 CI matrix编辑 .github/workflows/pr-test.yml.j2。运行生成脚本python .github/workflows/generate_github_workflows.py同时提交.github/workflows/pr-test.yml.j2和生成的.github/workflows/pr-test.yml。生成器 .github/workflows/generate_github_workflows.py 使用自定义定界符的 Jinja2 Environment% %为块、 为变量扫描*.yml.j2文件渲染后写入同名.yml并在头部写入自动生成声明。模板中还使用了 config.tests | tojson(indent2) | indent(10, true) 将 Python 侧的测试矩阵数据序列化为 YAML因此修改矩阵时只需增删模板顶部的tests列表条目无需手写大段 YAML。当前目录下的其他 workflow如conda-ci.yml、pre-commit.yml也遵循同一套 .j2 模板 生成器模式。PR 应该选择哪些检查文档给出了清晰的决策路径按改动类型对号入座纯 argument parsing、reward、schedule、sample、trajectory 或 hook-contract 改动优先依赖 CPU tests它们默认运行且反馈最快。SGLang topology 或 rollout engine deployment 改动使用run-ci-sglang-config其矩阵同时包含 GPU 为 0 的纯配置校验tests/utils/test_sglang_arguments.py、tests/utils/test_sglang_config.py和真实部署测试。Megatron training、loss、checkpoint conversion 或 model recipe 改动使用run-ci-megatron必要时加run-ci-precision数值一致性或run-ci-ckptcheckpoint 组合。Docker image 或 dependency 改动使用run-ci-image在slimerl/slime-test:latest上验证。新增或修改测试使用run-ci-changed做 targeted validation——它只运行你改动的测试文件并把NUM_GPUS作为 GPU 数量是最省资源的回归手段。附自托管 runner 的部署要点GPU e2e job 依赖自托管 runner部署说明见 tests/ci/README.md 与 tests/ci/github_runner/docker-compose.yml需在仓库 Secrets 中配置WANDB_API_KEY用于 e2e 测试的指标上报。runner 以 Docker 方式部署compose 文件启动 8 个ghcr.io/actions/actions-runner副本挂载/var/run/docker.sock使 runner 能启动 CI 所需的训练容器、/data/slime_ci与 CI 容器共享模型/数据集缓存和/home/runner/externals并通过GITHUB_RUNNER_URL/GITHUB_RUNNER_TOKEN环境变量完成注册token 会定期失效需要及时更新。runner 以privileged: true、user: root运行entrypoint 中先config.sh注册、再run.sh启动。总结slime 的 CI 体系是一套为RL 训练框架量身定制的工程实践CPU 层用 50 个轻量测试守住参数校验、奖励计算、采样、checkpoint 工具与插件契约等纯逻辑不变量GPU 层用 label 门控的自托管 e2e 测试覆盖 dense/MoE 训练、PPO/OPD、async rollout、PD/Mooncake、数值精度与 checkpoint 组合等真实训练路径run-ci-changed则提供了按文件粒度的动态回归。理解这套分层与触发机制是在该仓库贡献代码时快速定位该跑哪个 label、怎么写一个新测试的关键。对开发者而言把测试放进tests/test_*.py、声明正确的NUM_GPUS、遵循prepare()/execute()模式再在 .j2 模板中注册并重新生成 workflow即可让新功能获得完整的 CI 保护。【免费下载链接】slimeslime is an LLM post-training framework for RL Scaling.项目地址: https://gitcode.com/GitHub_Trending/slime12/slime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考