radixark/miles

修复 LoRA 恢复时忽略 --no-load-optim 导致旧优化器状态误载

值得精读，但定位是精准的小范围 bugfix。重点关注三点：一是 `load_optimizer` 参数默认值选择（`True`）如何保证向后兼容；二是 `--no-load-optim` 语义被严格限定为“只跳过 optimizer，保留 iteration 与 scheduler”，与 Megatron 原生行为对齐；三是通过 entry 存在性守卫实现与 #3083 的无序合入，这是一种低成本的跨 PR 兼容设计。若团队后续会扩展 LoRA 恢复功能，可继续关注 `load_lora_adapter` 的参数演进。

修复 LoRA 保存忽略 --no-save-optim 致恢复静默重启

值得精读，尤其是 commit 历史中的方案修正过程：从“跳过整个训练状态文件”改为“只丢弃 optimizer 条目”，展示了数据契约对 flag 语义的约束。关注点包括：单文件三元组（iteration / scheduler / optimizer）的解耦设计、`getattr(args, "no_save_optim", False)` 的兼容写法、以及测试中伪造 `megatron.bridge` 模块让 HF PEFT 导出快速失败的技巧。建议与 #3245 一起阅读，形成保存/加载闭环。

补上 offload 权重同步连接阶段的内存分配守卫

值得精读。改动虽小，但准确定位了 offload 显存管理中一个隐蔽问题——连接建立过程（而非仅数据传输）同样会分配 CUDA 张量，且把状态标记与 barrier 一并纳入守卫的决策体现了对“分配窗口”的完整思考。建议与 #3128 一起阅读，理解 offload 下 actor 权重同步的完整安全边界；同时留意 guapisolo 对守卫放置位置的提醒，后续重构 `disable()` 调用时应保持“覆盖所有可能分配 CUDA 张量的阶段”这一原则。

避免 worker 启动转发父进程 Python 入口点

值得精读。`python_argv_prefix()` 是解释器 argv 解析的典型边界场景：短选项可聚簇、部分选项带值、attached selector 需要与普通标志区分。该 PR 用逐字符簇扫描 + `for...else` 结构以少量代码覆盖了这些边界，并配套真实子进程回归测试而非仅断言字符串，测试设计值得借鉴。建议重点阅读 `python_argv_prefix()` 的扫描逻辑与新增参数化测试。

nightly 失败 job 自动重跑一次，卡片区分 flaky 与真实失败

值得精读。这个 PR 是 CI 通知链路上的一次小而有代表性的可靠性改进：自动重跑 + flaky 区分的状态机设计（attempt 1 重跑、attempt 2 报告、拒跑兜底、防循环守卫）清晰且可测试。特别值得关注两点：一是作者对未验证路径的诚实标注与 fallback 设计（先合入、后观察、再切换 token 来源），二是 identity boundaries 测试随权限提升同步收紧，保证 actions: write 是唯一新增写权限。建议后续跟踪第一个失败的 nightly，确认 workflow_run 事件确实触发，否则需要切换到 App token。

CPU-only PR 跳过 CUDA/ROCm 镜像准备

值得精读。该 PR 展示了 CI 门控设计中「需求推导」与「复用现有 gate」的平衡，尤其是 diff 缺失时保留 runnable 语义的修复，以及提交历史中「先扩展输出、后回退为复用条件」的演进过程，对理解 milos CI 策略的 stage 选择模型很有帮助。关注 `tests/ci/ci_policy.py` 的 `_write_github_outputs` 与 `tests/ci/stage_selection.py` 的 `select_skipped_gpu_stages` 两处核心逻辑即可。

CUDA 镜像升级 torch_memory_saver，修复暂停态释放崩溃

代码本身只有一行 pin 变更，不值得逐行精读；真正值得读的是评论区与 #3243 的验证链条——它解释了为什么「fork PR 的 GPU 红灯不能当证据」，以及如何用仓内分支承载镜像验证，对任何改 Dockerfile/依赖 pin 的人都直接可复用。关注三个设计决策：选上游修复的 merge commit（最小 bump）而不是跟最新版本；CUDA/ROCm 双 pin 的对称性维护；以及遗留的 segfault 与 backward OOM 必须另开 issue，不能随本 PR 一起关掉。

补齐 AMD 平台 Qwen3-4B LoRA RL 启动器

值得精读。若团队需要维护或扩展 AMD / ROCm 上的 LoRA RL 训练，这是当前唯一入口；其「平台差异收敛在启动器层」的做法——环境变量桥接（HIP → CUDA 可见设备）、SGLang Triton 后端固定、以及「配方 + 快照 + 文档」三件套的组织方式——是值得复用的模式。验证数据（logprob 差、KL、截断率、AIME 趋势）可作为后续 AMD 训练健康度对比的参考基线，但不应据此断言训练收益。