Miles框架CI流水线深度解析：从硬件标签选择到metric history gate完整指南-平芜编程栈

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/miles

Miles是一个面向企业的 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 与 Suite：CI 流水线的最小单元

在 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-cpu`	GitHub 托管 CPU	`ubuntu-latest`
`stage-b-2-gpu-h200`	2× H200	`["h200","2gpu"]`
`stage-c-4-gpu-h200`	4× H200	`["h200","4gpu"]`
`stage-c-8-gpu-h100`	8× H100	`["h100","8gpu"]`
`stage-c-8-gpu-b200`	8× B200	`["b200","8gpu"]`
`stage-c-4-gpu-mi350`	4× 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.py：

1. 领域标签（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：

默认偏好hopper（Hopper 主机 4 台以上、Blackwell 只有 1 台，避免打爆队列）；
run-ci-blackwell-only与run-on-blackwell一字之差、语义完全不同：前者跑"只能在 Blackwell 上跑"的测试，后者把能跑的测试挪到Blackwell。

图源：docs/advanced/p2p-weight-transfer.md，GPU 代际/规模差异正是 CI 需要分代际基线的原因

3. 节奏（Cadence）：regular / nightly / weekly / release

四种节奏共用同一套 stage 清单，差异在"准入范围"和是否写性能基线：

节奏	选择范围	写滚动基线
regular（普通 PR）	仅普通注册的测试	否（shadow 只读）
nightly（`nightly`标签或每周一至周六 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 文件，训练过程永不因门禁而阻塞；
合流（Harness）：tests/ci/run_suite.py 在测试通过合并各进程记录，失败尝试的记录直接丢弃、只认"通过的那次"的数据；
判定（Gate Library）：tests/ci/metric_history/gate.py 纯函数组合"解析声明 → 选取比较坐标 → 按约束判定"，对存储层只读；
存储（Store）：SQLite（离线开发）与 Neon（CI 生产）双后端，只通过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运行（带完整 provenance：commit_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
发布分支 CI	docs/developer/ci/04-release.md
贡献者上手指南	docs/developer/ci/contributor-guide.md

总结：Miles 的 CI 流水线把"选哪个测试"（领域标签）、"在哪跑"（代际调度）、"何时跑"（节奏）与"跑得好不好"（metric history gate）拆成了四个正交且声明式可控的维度。对新手来说只需记住三件事：GPU 测试必须带领域标签、用--list-only确认测试真的被发现、指标基线只由 nightly/weekly 写入——剩下的，流水线自己会守护。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考