radixark/miles · 标签视图

DSv4 双后端可选，对齐 Megatron 权重契约，恢复训练

值得精读。该 PR 展示了三类可借鉴的设计决策：一是用显式 raise 替代静默 fallback，杜绝用户不知情的实现漂移；二是通过统一 checkpoint 命名契约让两种实现共享同一数据源，并用 `assert_checkpoint_is_current` 做防御性拒绝；三是利用已有的原子更新组把分散参数在导出时重新聚合（`_packed_alphas` 的 bucket 传递），是分布式 checkpoint 转换中优雅的处理方式。PR body 中关于 tid2eid、SwiGLU clamp、MTP replay 等调试细节也极具参考价值。

令牌条改为整条滚动，分页控件移除，请求减半

值得精读，尤其是关心 dashboard 前端与超长列表渲染的工程师。作者先用实测证明 DOM 构建成本远低于直觉（64k span 仅 66 ms），再用 `offsetParent + scrollTop` 的懒定位替代分页状态，最后针对 review 发现的隐藏面板时序问题设计一次性 `_onShown` 回调；这三个决策都可迁移到其他长列表或懒加载面板场景。

端口与并发数解耦，新增 workers 参数

值得精读。这是一个有清晰设计意图的破坏性 CLI 重构：默认 32 workers 的取舍、拒绝旧语法而非兼容、TODO(#1837) 标记临时端口分配，都体现了对“配置属主唯一”和“迁移可见性”的坚持。建议重点关注 _resolve_session_server_ports 的实现与 review 中未解决的连续端口占用问题，后续很可能被 #1837 的统一端口分配重构取代。

升级 refactor 验证技能，新增 proof 生成与链式验证工具链

值得精读。核心看点是 `mechanical_refactor_reproduction_utils.py` 中 AST 定位 + 源码文本拼接的原子原语设计，以及 `mechanical_refactor_proof_generator.py` 中从 diff 反推 recipe 的启发式推断；这两者组合实现了「机器证明机械重构」的闭环。对计划做大规模代码移动或希望自动化重构 review 的团队有直接借鉴价值。建议重点关注 `verify_mechanical_refactor` 的 worktree 校验流程和 `infer_recipe` 对不支持场景（rename、语句级重排）的显式拒绝策略。

--hardware 自动探测节点并推导 GPU 数

值得精读：它展示了如何把分散在 19 个脚本里的机器假设收敛为单一事实来源，并用「替换前字面量一致性核对 + 快照不变 + pin 机制」三重手段保证行为不漂移。最值得学习的两点：resolve_hardware() 用 typing.get_args 反射字段 Literal 做显式校验，避免 match 静默穿透；测试用 _fake_torch 在无 GPU runner 上完整覆盖硬件探测矩阵。合并前建议在 B300/GB300/H200 实机各跑一次探测。

verifiers 三个测试按 example 目录归档，纯移动无内容变更

不值得精读，属于低风险、高确定性的测试组织维护。值得留意的是其确立的目录镜像原则——“`tests/fast/` 下的目录应镜像被测代码的包结构”，以及 PR body 中展示的“纯移动安全性论证”模板（包路径访问、无 `__file__`、无外部引用、CI list-only 对比），可作为后续同类测试迁移 PR 的参照。

15 个示例测试迁入 tests/fast 纳入 CI，并用守卫测试杜绝孤儿测试

值得精读，尤其是 `tests/ci/test/test_ci_discovery_coverage.py` 的三个守卫设计和 `git ls-files` 替代文件系统遍历的决策——这是“用测试约束测试放置”的治理范式，比一次性迁移更有长期价值。值得关注的决策点：①“无法运行的测试应自我声明 skip 而不是隐形缺席”的原则；②`_KNOWN_ORPHANS` 设计为只收缩，条目随文件迁移自动过期，避免豁免永久化；③`test_the_example_suites_reach_the_cpu_plan` 直接调用 `collect_tests(discover_ci_files())` 校验真实计划，而不是断言文件存在这种弱检查。对 CI 治理、测试编排感兴趣的读者可重点参考其结构。

CPU 测试优先放行，PR 镜像构建后置门控

值得精读，适合负责 CI 流水线维护的工程师。重点关注三个设计点：可复用工作流提取如何降低主工作流体积；seam test 模式如何用文本断言锁定 GitHub Actions 结构；fail-closed 与 fork 回退如何防止静默降级。合并后建议先观察真实 PR 的门控时序再继续演进。