Prhub

radixark/miles

Miles is an enterprise-facing reinforcement learning framework for LLM and VLM post-training, forked from and co-evolving with slime.

监控状态:已开启 最近同步:2026-09-17 11:45 同步状态:空闲 下次计划:2026-09-17 12:45

PR 列表

更多筛选
2026-08-20
2026-08-19

#2658 docs: link the Miles website from the README

原始 PR · 作者 Zhichenzzz · 合并时间 2026-08-19 01:06

文档 重要性 1.96 洞察度 1.00

README 新增站点首页链接并重命名 docs 徽章

不值得精读,属于低技术含量的文档维护。可留意的设计点是:在新增徽章时同步重命名相邻徽章的标签,避免同域名不同路径造成视觉歧义;类似的链接维护可以统一在导航表与徽章行同步进行,保证入口一致性。

文档 重要性 1.20 洞察度 1.00

README 与文档首页新增 v0.1 发布公告

此 PR 为纯文档公告,不值得技术精读。值得关注的是它作为 v0.1 发布链条的一部分与 #2564、#2538 形成联动,可学习其发布收尾流程:版本提升 → 发布工作流 → 对外新闻公告。若后续博客链接变更,建议同步更新两处。

#2656 docs: filter the blog link to Miles posts

原始 PR · 作者 guapisolo · 合并时间 2026-08-19 00:02

文档 重要性 1.70 洞察度 1.00

README 博客链接改为 Miles 过滤视图

该 PR 不值得精读,属于低价值的文档链接维护。可将其视为一个样例:仓库文档入口中的外链应尽可能指向过滤视图或专题页,减少读者噪音。建议在后续文档导航重构(如 README 结构治理)中一并规范化类似外链。

2026-08-18

#2655 docs: improve Miles Diffusion discovery

原始 PR · 作者 Rockdu · 合并时间 2026-08-18 23:54

文档 重要性 2.71 洞察度 3.00

模型索引按模态拆分,新增 Diffusion 表并直达 Miles Diffusion 仓库

值得快速浏览,作为"用最小文档结构调整提升可发现性"的小样本:按模态拆分索引表 + 三处入口同步 + 外部仓库主导航链接的组合,对文档维护者有参考意义,但无技术深度,不需精读。

文档 重要性 4.79 洞察度 4.00

全面校对 docs/ 与 main 的偏差,修复失效命令与过时指标名

值得精读,尤其是三处:其一,`argument-groups.md` 的重写完整刻画了 Miles launcher 的真实结构(Python 脚本 + `execute_train` 拼接 + `scripts/models/` 注入 model args),是理解整个 recipe 体系的入口;其二,`train-infer-mismatch-helper` 对"CLI flag vs YAML config key"的厘清,揭示了该功能真实的接入方式(`--custom-config-path` + `--custom-tis-function-path`);其三,PR 的"审计-交叉验证-刻意排除 coverage gaps"方法论本身可复用,且 review 中"grep 不到字面量不等于没有 emitter"的教训对任何文档型改动都有借鉴意义。建议关注 `eval/skipped_*` 删除争议是否会在后续 PR 中被回补。

#2654 docs: name the Slack channel #miles-rl

原始 PR · 作者 nblintao · 合并时间 2026-08-18 23:15

文档 重要性 1.66 洞察度 1.00

文档将 Slack 频道名统一更正为 #miles-rl

不值得精读,但可作为文档维护的样例:名称变更时应同步修改所有入口(首页、README、相关指南),避免只改一处造成不一致。当前变更简单,无需额外措施。

文档 重要性 4.18 洞察度 6.00

Qwen3.8-2.4T 训练 recipe 文档化,替换 PR 占位 stub

对计划在 GB300 上跑 Qwen3.8-2.4T-A95B LoRA RL 的工程师:值得精读,§6.2 的 NCCL 版本坑与 §6.4 的交替备份内存预算属于实测得出的硬经验。对文档维护者:注意本文档与 #2488 的强耦合,建议在 #2488 合并时同步 review 本文档。值得关注的设计决策是「任意时刻恰好一边持有 host backup」的内存预算推演,以及用 `zero_copy=True` 避免 clone 备份膨胀 malloc arena 的做法。

参与讨论