Miles框架CI流水线深度解析从硬件标签选择到metric history gate完整指南【免费下载链接】milesMiles is an enterprise-facing reinforcement learning framework for LLM and VLM post-training, forked from and co-evolving with slime.项目地址: https://gitcode.com/GitHub_Trending/miles1/milesMiles是一个面向企业的 LLM/VLM 强化学习后训练框架它与 slime 同源并协同演进。本文带你完整看懂 Miles 的CI 流水线设计一次 PR 提交后测试如何通过硬件标签选择stage 与 label 机制被分配到 H100、H200、B200 等不同 GPU 集群以及metric history gate如何把每次训练运行的ppo_kl、raw_reward等指标与历史基线对比自动捕捉肉眼难以发现的缓慢漂移。Miles 的核心架构是训练侧 Megatron 推理侧 SGLang双引擎协作CI 要守护的正是这条链路上每一环的正确性图源docs/developer/architecture.md 中的架构图一、Stage 与 SuiteCI 流水线的最小单元在 Miles 的 CI 里一个 stage 就是一个 CI job一个 suite 就是测试声明的suite值两者 1:1 映射。测试通过register_cuda_ci(suite...)声明自己属于哪个 suite运行器 tests/ci/run_suite.py 中CI_SUITES是唯一的套件清单按 CPU / CUDA / ROCm 三类硬件后端分组。stage 命名遵循stage-tier-gpus-hw规则一眼可读Stage / Suite硬件Runner 标签stage-a-cpuGitHub 托管 CPUubuntu-lateststage-b-2-gpu-h2002× H200[h200,2gpu]stage-c-4-gpu-h2004× H200[h200,4gpu]stage-c-8-gpu-h1008× H100[h100,8gpu]stage-c-8-gpu-b2008× B200[b200,8gpu]stage-c-4-gpu-mi3504× MI350 (ROCm)[self-hosted,amd,mi350,4gpu]几个值得记住的设计要点b/c是角色分级不是串行顺序stage-a-cpu成功后各 GPU stage 并行执行测试自带 GPU 预算测试通过ray start --num-gpus/torchrun --nproc-per-node声明自己需要的卡数而不是看见多少卡用多少卡因此调度到更大的 stage 时多余 GPU 只会闲置分片均衡多 shard 的 stage 由run_suite.py按每个测试的est_time做负载均衡。完整阶段清单见 docs/developer/ci/00-stage.md。二、硬件标签选择谁在哪台机器上跑GPU 集群资源稀缺且昂贵Miles 用两条正交的标签轴来控制哪些测试跑和在哪里跑核心代码在 tests/ci/ci_policy.py1. 领域标签Domain Labels选哪些测试测试在文件顶部声明自己的领域标签例如labels[megatron]对应 PR 上的 GitHub 标签run-ci-megatron。没有匹配的run-ci-*标签GPU 测试就完全不触发——这把昂贵的 GPU 矩阵挡在与 PR 无关的改动之外。全部合法标签定义在 tests/ci/labels.py包括megatron、sglang、fsdp、lora、ckpt、precision、fully-async、amd等 20 个。新增标签只需在KNOWN_LABELS加一行并创建对应仓库标签无需改任何 workflow YAML。2. 调度标签Dispatch Labels选哪个 GPU 代际每个 CUDA 测试还要声明支持哪些代际hardware[hopper, blackwell]。PR 上的run-on-hopper/run-on-blackwell标签决定测试是否离开主场 stage 迁移到其他代际。代际清单与 stage 拓扑的单一事实来源是 tests/ci/hardware.py默认偏好hopperHopper 主机 4 台以上、Blackwell 只有 1 台避免打爆队列run-ci-blackwell-only与run-on-blackwell一字之差、语义完全不同前者跑只能在 Blackwell 上跑的测试后者把能跑的测试挪到Blackwell。图源docs/advanced/p2p-weight-transfer.mdGPU 代际/规模差异正是 CI 需要分代际基线的原因3. 节奏Cadenceregular / nightly / weekly / release四种节奏共用同一套 stage 清单差异在准入范围和是否写性能基线节奏选择范围写滚动基线regular普通 PR仅普通注册的测试否shadow 只读nightlynightly标签或每周一至周六 cron除long、ft-long外全部是weekly每周六 cron全部启用标签是release发布分支调用同 weekly但依赖 SHA 冻结否防止污染滚动基线nightly / weekly / release 同时关闭 fast-fail让一次广覆盖运行暴露所有失败而不是停在第一个。三、给 CI 添加一个 GPU 测试三步走Miles 的 CI 注册是代码即配置你从不编辑 workflow YAML只需在测试文件顶部声明一行把test_*.py放进 tests/e2e/ 或 tests/fast-gpu/纯 CPU 测试放 tests/fast/ 则自动注册零声明文件顶部调用register_cuda_ci(est_time..., suite..., labels[...], hardware[...])四个参数缺一不可GPU 测试必须至少一个领域标签本地用python3 tests/ci/run_suite.py --hw cuda --suite 你的suite --match-all-labels --list-only确认你的文件出现在计划里——没被发现的测试会静默不跑CI 照样绿所以这步必须做。细节与排错表如何区分你的代码挂了还是基建问题见 docs/developer/ci/contributor-guide.md 和 tests/ci/README.md。四、metric history gate让指标漂移无处遁形单次运行看不出问题ppo_kl每次漂移 0.001连漂移 100 次之后单次数值依然看起来正常。Miles 的metric history gate代码位于 tests/ci/metric_history/就是为捕捉这种慢漂移而生的。工作原理四个角色的流水线采集Collector训练进程中的 miles/utils/tracking_utils/TrackingManager把每次log()同时扇出给 wandb只写不回读和CiHistoryBackend——后者把白名单指标快照成每个进程一份的 JSONL 文件训练过程永不因门禁而阻塞合流Harnesstests/ci/run_suite.py 在测试通过合并各进程记录失败尝试的记录直接丢弃、只认通过的那次的数据判定Gate Librarytests/ci/metric_history/gate.py 纯函数组合解析声明 → 选取比较坐标 → 按约束判定对存储层只读存储StoreSQLite离线开发与 NeonCI 生产双后端只通过write_run/recent_trusted_values/mark_untrusted三个接口对外。图源docs/models/deepseek/deepseek-v4-1-flash.md这类 reward / KL 曲线正是门禁逐点比对的对象判定规则双侧走廊 冷启动基线 同一坐标同测试、同指标、同steps/constraint字面量、同 step下历史可信值的均值约束是双侧走廊值必须落在[ref − band_down, ref band_up]内带宽 max(rel·|ref|, abs_floor)。不存在无上限的一侧——向更好方向飞得太远通常也是指标坏了冷启动某坐标还没有任何可信历史点时门禁处于 INACTIVE不报错这次运行空信任恰好为基线播种身份隔离run series 由(test_path, backend, suite)定义其中suite是实际执行的 stage。测试被 dispatch 到 Blackwell 后其数值归属 Blackwell 序列——两代 GPU 的基线永不混用自保护未过门禁的运行仍会入库但标记trusted false永不拉偏基线发现坏点只需mark_untrusted一个标志位翻转无需删行重建。谁有权写基线只有nightly 和 weekly运行带完整 provenancecommit_sha、pr_number等才写入基线普通 PR 运行与 release 运行只读 shadow——release 分支依赖的 SHA 是冻结的绝不能进入滚动基线污染夜间对比。目前门禁处于 shadow-first 阶段只记录与暴露、不阻塞 PR强制执行将由 per-test 白名单 全局 kill-switch 后续开启。完整声明方式register_ci_gate(metric_key, steps, constraint)、存储表结构与运维查询见 docs/developer/ci/03-metric-history-gate.md。五、一张图总结整条流水线PR 提交 → 解析触发事实 (ci_policy.py) → 确定节奏 regular/nightly/weekly/release → 领域标签选测试 × 调度标签选 GPU 代际 → stage 分片均衡、并行执行CPU 先行 gate → 测试通过后采集白名单指标 (JSONL) → metric history gate 与可信历史比对 → nightly/weekly 写回基线trusted 标记隔离坏点六、延伸阅读想了解去哪里stage 全清单与依赖关系docs/developer/ci/00-stage.md标签语义与 PR 评论命令/rerun-test等docs/developer/ci/01-label.md指标门禁完整设计docs/developer/ci/03-metric-history-gate.md发布分支 CIdocs/developer/ci/04-release.md贡献者上手指南docs/developer/ci/contributor-guide.md总结Miles 的 CI 流水线把选哪个测试领域标签、在哪跑代际调度、何时跑节奏与跑得好不好metric history gate拆成了四个正交且声明式可控的维度。对新手来说只需记住三件事GPU 测试必须带领域标签、用--list-only确认测试真的被发现、指标基线只由 nightly/weekly 写入——剩下的流水线自己会守护。【免费下载链接】milesMiles is an enterprise-facing reinforcement learning framework for LLM and VLM post-training, forked from and co-evolving with slime.项目地址: https://gitcode.com/GitHub_Trending/miles1/miles创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Miles框架CI流水线深度解析从硬件标签选择到metric history gate完整指南【免费下载链接】milesMiles is an enterprise-facing reinforcement learning framework for LLM and VLM post-training, forked from and co-evolving with slime.项目地址: https://gitcode.com/GitHub_Trending/miles1/milesMiles是一个面向企业的 LLM/VLM 强化学习后训练框架它与 slime 同源并协同演进。本文带你完整看懂 Miles 的CI 流水线设计一次 PR 提交后测试如何通过硬件标签选择stage 与 label 机制被分配到 H100、H200、B200 等不同 GPU 集群以及metric history gate如何把每次训练运行的ppo_kl、raw_reward等指标与历史基线对比自动捕捉肉眼难以发现的缓慢漂移。Miles 的核心架构是训练侧 Megatron 推理侧 SGLang双引擎协作CI 要守护的正是这条链路上每一环的正确性图源docs/developer/architecture.md 中的架构图一、Stage 与 SuiteCI 流水线的最小单元在 Miles 的 CI 里一个 stage 就是一个 CI job一个 suite 就是测试声明的suite值两者 1:1 映射。测试通过register_cuda_ci(suite...)声明自己属于哪个 suite运行器 tests/ci/run_suite.py 中CI_SUITES是唯一的套件清单按 CPU / CUDA / ROCm 三类硬件后端分组。stage 命名遵循stage-tier-gpus-hw规则一眼可读Stage / Suite硬件Runner 标签stage-a-cpuGitHub 托管 CPUubuntu-lateststage-b-2-gpu-h2002× H200[h200,2gpu]stage-c-4-gpu-h2004× H200[h200,4gpu]stage-c-8-gpu-h1008× H100[h100,8gpu]stage-c-8-gpu-b2008× B200[b200,8gpu]stage-c-4-gpu-mi3504× MI350 (ROCm)[self-hosted,amd,mi350,4gpu]几个值得记住的设计要点b/c是角色分级不是串行顺序stage-a-cpu成功后各 GPU stage 并行执行测试自带 GPU 预算测试通过ray start --num-gpus/torchrun --nproc-per-node声明自己需要的卡数而不是看见多少卡用多少卡因此调度到更大的 stage 时多余 GPU 只会闲置分片均衡多 shard 的 stage 由run_suite.py按每个测试的est_time做负载均衡。完整阶段清单见 docs/developer/ci/00-stage.md。二、硬件标签选择谁在哪台机器上跑GPU 集群资源稀缺且昂贵Miles 用两条正交的标签轴来控制哪些测试跑和在哪里跑核心代码在 tests/ci/ci_policy.py1. 领域标签Domain Labels选哪些测试测试在文件顶部声明自己的领域标签例如labels[megatron]对应 PR 上的 GitHub 标签run-ci-megatron。没有匹配的run-ci-*标签GPU 测试就完全不触发——这把昂贵的 GPU 矩阵挡在与 PR 无关的改动之外。全部合法标签定义在 tests/ci/labels.py包括megatron、sglang、fsdp、lora、ckpt、precision、fully-async、amd等 20 个。新增标签只需在KNOWN_LABELS加一行并创建对应仓库标签无需改任何 workflow YAML。2. 调度标签Dispatch Labels选哪个 GPU 代际每个 CUDA 测试还要声明支持哪些代际hardware[hopper, blackwell]。PR 上的run-on-hopper/run-on-blackwell标签决定测试是否离开主场 stage 迁移到其他代际。代际清单与 stage 拓扑的单一事实来源是 tests/ci/hardware.py默认偏好hopperHopper 主机 4 台以上、Blackwell 只有 1 台避免打爆队列run-ci-blackwell-only与run-on-blackwell一字之差、语义完全不同前者跑只能在 Blackwell 上跑的测试后者把能跑的测试挪到Blackwell。图源docs/advanced/p2p-weight-transfer.mdGPU 代际/规模差异正是 CI 需要分代际基线的原因3. 节奏Cadenceregular / nightly / weekly / release四种节奏共用同一套 stage 清单差异在准入范围和是否写性能基线节奏选择范围写滚动基线regular普通 PR仅普通注册的测试否shadow 只读nightlynightly标签或每周一至周六 cron除long、ft-long外全部是weekly每周六 cron全部启用标签是release发布分支调用同 weekly但依赖 SHA 冻结否防止污染滚动基线nightly / weekly / release 同时关闭 fast-fail让一次广覆盖运行暴露所有失败而不是停在第一个。三、给 CI 添加一个 GPU 测试三步走Miles 的 CI 注册是代码即配置你从不编辑 workflow YAML只需在测试文件顶部声明一行把test_*.py放进 tests/e2e/ 或 tests/fast-gpu/纯 CPU 测试放 tests/fast/ 则自动注册零声明文件顶部调用register_cuda_ci(est_time..., suite..., labels[...], hardware[...])四个参数缺一不可GPU 测试必须至少一个领域标签本地用python3 tests/ci/run_suite.py --hw cuda --suite 你的suite --match-all-labels --list-only确认你的文件出现在计划里——没被发现的测试会静默不跑CI 照样绿所以这步必须做。细节与排错表如何区分你的代码挂了还是基建问题见 docs/developer/ci/contributor-guide.md 和 tests/ci/README.md。四、metric history gate让指标漂移无处遁形单次运行看不出问题ppo_kl每次漂移 0.001连漂移 100 次之后单次数值依然看起来正常。Miles 的metric history gate代码位于 tests/ci/metric_history/就是为捕捉这种慢漂移而生的。工作原理四个角色的流水线采集Collector训练进程中的 miles/utils/tracking_utils/TrackingManager把每次log()同时扇出给 wandb只写不回读和CiHistoryBackend——后者把白名单指标快照成每个进程一份的 JSONL 文件训练过程永不因门禁而阻塞合流Harnesstests/ci/run_suite.py 在测试通过合并各进程记录失败尝试的记录直接丢弃、只认通过的那次的数据判定Gate Librarytests/ci/metric_history/gate.py 纯函数组合解析声明 → 选取比较坐标 → 按约束判定对存储层只读存储StoreSQLite离线开发与 NeonCI 生产双后端只通过write_run/recent_trusted_values/mark_untrusted三个接口对外。图源docs/models/deepseek/deepseek-v4-1-flash.md这类 reward / KL 曲线正是门禁逐点比对的对象判定规则双侧走廊 冷启动基线 同一坐标同测试、同指标、同steps/constraint字面量、同 step下历史可信值的均值约束是双侧走廊值必须落在[ref − band_down, ref band_up]内带宽 max(rel·|ref|, abs_floor)。不存在无上限的一侧——向更好方向飞得太远通常也是指标坏了冷启动某坐标还没有任何可信历史点时门禁处于 INACTIVE不报错这次运行空信任恰好为基线播种身份隔离run series 由(test_path, backend, suite)定义其中suite是实际执行的 stage。测试被 dispatch 到 Blackwell 后其数值归属 Blackwell 序列——两代 GPU 的基线永不混用自保护未过门禁的运行仍会入库但标记trusted false永不拉偏基线发现坏点只需mark_untrusted一个标志位翻转无需删行重建。谁有权写基线只有nightly 和 weekly运行带完整 provenancecommit_sha、pr_number等才写入基线普通 PR 运行与 release 运行只读 shadow——release 分支依赖的 SHA 是冻结的绝不能进入滚动基线污染夜间对比。目前门禁处于 shadow-first 阶段只记录与暴露、不阻塞 PR强制执行将由 per-test 白名单 全局 kill-switch 后续开启。完整声明方式register_ci_gate(metric_key, steps, constraint)、存储表结构与运维查询见 docs/developer/ci/03-metric-history-gate.md。五、一张图总结整条流水线PR 提交 → 解析触发事实 (ci_policy.py) → 确定节奏 regular/nightly/weekly/release → 领域标签选测试 × 调度标签选 GPU 代际 → stage 分片均衡、并行执行CPU 先行 gate → 测试通过后采集白名单指标 (JSONL) → metric history gate 与可信历史比对 → nightly/weekly 写回基线trusted 标记隔离坏点六、延伸阅读想了解去哪里stage 全清单与依赖关系docs/developer/ci/00-stage.md标签语义与 PR 评论命令/rerun-test等docs/developer/ci/01-label.md指标门禁完整设计docs/developer/ci/03-metric-history-gate.md发布分支 CIdocs/developer/ci/04-release.md贡献者上手指南docs/developer/ci/contributor-guide.md总结Miles 的 CI 流水线把选哪个测试领域标签、在哪跑代际调度、何时跑节奏与跑得好不好metric history gate拆成了四个正交且声明式可控的维度。对新手来说只需记住三件事GPU 测试必须带领域标签、用--list-only确认测试真的被发现、指标基线只由 nightly/weekly 写入——剩下的流水线自己会守护。【免费下载链接】milesMiles is an enterprise-facing reinforcement learning framework for LLM and VLM post-training, forked from and co-evolving with slime.项目地址: https://gitcode.com/GitHub_Trending/miles1/miles创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
