radixark/miles

回滚过宽的 backuper 参数断言，修复 LoRA e2e CI 启动崩溃

值得快速阅读。虽然改动只有 8 行删除，但 PR body 展现了良好的工程判断：识别断言覆盖范围与实际行为（--colocate 隐式开启 offload_train）的偏差，并坚持把防御性检查放在真实故障点。建议关注后续 #2204 是否已合入，确认风险窗口已关闭。

参数校验拒绝 LoRA + colocate + offload 下禁用权重备份

值得精读，虽然改动仅 8 行，但它展示了如何通过参数验证将分布式训练中隐蔽的挂起问题转化为即时失败，体现了 fail-fast 的防御性设计。关注 `is_lora_enabled` 的覆盖范围及断言条件的完备性，未来若 LoRA 启用判断逻辑变化需同步维护。

AMD DSV4 4 节点配置调优，切换 unified-KV 路径

值得精读。虽然只改一个文件，但涉及 SGLang 后端路径切换和并行策略权衡，对理解 AMD 平台上的优化思路有帮助。可以重点看 `extra_env_vars` 的配置注释和 `_get_parallel_config` 的并行策略选择。

按后端 scale 格式门控 ue8m0 权重量化

该 PR 值得快速精读，尤其是 3 个 commit 反映的方案演进：从 `DEEPGEMM_SCALE_UE8M0` 门控改为真实 TE 环境变量门控，体现了“用训练侧事实约束转换侧行为”的设计思路。值得关注的设计决策：把后端能力判断（DeepGEMM 是否支持 ue8m0）与训练侧 scale 格式选择解耦。建议后续补充：环境变量缺失兜底、AMD gfx942/gfx950 分支、以及针对转换输出的回归测试。

删除无人消费的 daytona bake 快照 CLI

建议快速浏览而非精读：变更单文件且为纯删除，无新逻辑。值得借鉴的是 PR body 的“可消费性论证”——从 API 参数类型不匹配（CreateSandboxFromImageParams 与 CreateSandboxFromSnapshotParams）、资源配额约束（org 500 上限）、全局 grep 检索三层证明死代码无可消费方，这种删除理由的严谨性可复用于同类清理。合并后应复核 #1913 的 rebase 约定是否落地，并在 openenv 目录内搜索残留的 bake 或 snapshot_name 引用。

修复 Inkling 处理器无 save_pretrained 时崩溃

改动极小、逻辑直接，适合快速阅读（约 5 分钟）。值得关注的设计点是“面向能力而非类型”的守卫模式——用 `hasattr` 替代类型假设，对 bespoke/部分实现接口的对象更稳健。若仓库中类似处理器 dump 场景增多，可抽象为可序列化判定工具函数。长远看，建议为 `RolloutDataSource.__init__` 的 dump 分支补一个 fast 测试，防止回归。

fully-async 评估：共享引擎/专用机群/外部黑盒三种姿态

值得精读。核心设计决策包括：按权重来源切分评估姿态、快照单一 owner 防泄漏、版本钉住与逐引擎读回校验、`--eval-sglang-*` 继承式参数与 tp-coupled 回退、黑盒契约保持目录进/结果出。建议重点阅读 `eval_dispatch.py`、`eval_fleet.py`、`checkpoint_eval.py` 三件套及其 fast 测试，可复用到任何需要异步评估的 RL 训练框架。合并后应补跑一次 head commit 上共享引擎暂停姿态的 GPU 验证。

修复 sparse_mla_bwd NaN 并新增 GB300 RL 训练配方

值得精读，重点看三点：一是 PR body 对 kernel miscompile 的论证——为什么 Hopper 没炸不能作为 gate 条件，正确性修复不应依赖调度巧合，这是编译器 pass 配置踩坑的宝贵案例；二是显存瓶颈的实测推理——KV pool 而非 max-seq-len 才是 context 上限，mem-fraction 从 0.75 提到 0.85 是数据驱动而非拍脑袋；三是 --sglang-config 把复杂 rollout 引擎形状抽象为两个具名配方，并在 __post_init__ 用 assert 拒绝无法表达的组合，这种配置设计模式可直接借鉴到其他启动器。