radixark/miles

wandb 组后缀改用 sdk 内部 generate_id 修复启动崩溃

值得快速阅读：这是一个小而典型的「依赖内部 API 漂移导致启动崩溃」修复案例，展示了如何精准定位隐性问题并验证行为兼容。值得关注的设计点是作者刻意不把 wandb 版本 pin 捆绑进紧急修复，而是留作单独决策。建议后续跟进：为 wandb_utils 增加针对 init_wandb_primary group 生成的测试，并考虑在 pyproject.toml 中约束 wandb 版本下限。

训练镜像 apt 装 tmux，SSH 断线后可恢复长任务

不值得精读，属于一行镜像依赖变更；但拆链策略值得借鉴：把触碰 `docker/` 的变更从大型功能链单独拆出，避免每次 push 触发完整多架构镜像重建，是高效的 CI 资源管理习惯。若你在维护训练镜像或 devbox 工作流，可直接合并此类变更。

删除 FAQ 页面，清理导航并更新入站链接

值得快速浏览。这个 PR 是文档清理的典型范例：先尝试局部修正、再基于 review 反馈转为整体删除，并同步清理入站链接。对维护文档的团队有参考价值，尤其是如何处理“过时且误导”的页面、如何与导航配置保持一致。

miles 版本号重置为 0.1.0，启动首次发布流程

不值得精读，但适合快速浏览以了解发布流水线设计：版本号被 release-tag.yml 的 tag gate 直接校验，体现了 CI 门禁驱动的发布策略。管理人员可借此确认首次发布链路完整性，工程师无需关注代码细节。

新增 CI 门控的版本发布工作流，冻结依赖三元组并发布官方镜像。

值得精读。本 PR 展示了多个高价值设计决策：用 commit status 做跨工作流门控、cadence 覆盖隔离 release 与 nightly 基线、retag 规避镜像清理周期、cherry-pick 与镜像层一致性约束。发布维护者应重点阅读 `docs/ci/04-release.md` 与 `release-tag.yml` 的 force 逃生门；普通贡献者需要了解 `bot-cherry-pick.yml` 的限制。

解除流式优化器状态与训练器卸载的强耦合

值得精读，尤其关注参数校验层面的设计权衡，以及“放宽断言但未补测试”的后续跟进。该修复展示了在大型集群真实负载约束下，参数级耦合假设如何被实际拓扑推翻的过程。

Daytona 客户端进程级复用，修复 fd 泄漏致训练停止

值得精读。这是一个教科书式的 '连接池/客户端复用' 资源泄漏修复：有完整的现场数据（fd 时间线、SSLEOFError 频率）、清晰的根因链（无 close + 闭包持有 + 重试放大）和有效的验证方法（16 节点复跑、fd 收敛曲线）。值得关注的设计决策包括：用 `threading.Lock` + 模块级单例做进程级复用并保留延迟导入、测试中用假模块替换 `sys.modules` 以纯单元方式验证单例语义。对团队而言，可借此建立一条 code review 检查项：凡是 SDK 持有连接池且无 close() 时，禁止在每次调用/重试中新建客户端。

启用 21 个已验证测试至 MI350 ROCm 套件

值得快速浏览，尤其是 `tests/ci/run_suite.py` 的套件拆分配置和任意一个测试文件的 `register_rocm_ci` 注册模板。该 PR 展示了如何在保持测试体不变的前提下，将已验证的测试安全接入新硬件 CI 通道，是后续新增 ROCm 测试的参考样板。若团队后续要继续扩 ROCm 覆盖，建议关注 `est_time` 校准是否持续基于实测数据，以及外部 sgl-project/sglang nightly 对新套件名的消费是否稳定。