radixark/miles · 标签视图

修复 GB300 16 节点 tbench2 训练崩溃，折叠三个关键配置杠杆

值得精读。这是「用一次 16 节点 smoke run 的逐 token 取证驱动配置和运行期行为修复」的典型范例：PR body 中关于 `--tis-clip-low` 反向后果、SDK 非幂等重试导致 zombie decode 的量化分析（~1000 引擎侧请求 vs 128 活跃样本）尤其值得关注。建议重点阅读三个设计决策：①TIS clip 下限回归默认值的理由（不要为了"梯度稳定"而违背 importance sampling 语义）；②`max_retries=0` 与 `timeout=3600` 的配对逻辑（生成请求不幂等，重试代价高于超时等待）；③`finish_reason == "length"` 终结 episode 的边界语义。同时建议跟进 #2591 与 `--max-weight-staleness` 的后续修复，它们与本 PR 构成完整的崩溃治理链路。

截断轮次立即结束 episode，消除 22.7% 无效生成时间

值得精读。代码量极小（核心仅 3 行），但问题定位方法极具参考价值：用实测数据（6469 episodes、144.7h/638h、单样本 73% 时间被丢弃）量化不可见浪费，通过 dashboard 渲染盲区反推根因，再以训练端丢弃边界校准 rollout 端生成边界。设计上"截断即停止、但保留评分"的取舍清晰、与训练契约严格对齐，是实现最小修复的范例。

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 治理、测试编排感兴趣的读者可重点参考其结构。

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

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

Daytona 配方改用 --fully-async 以启用参数互斥校验

值得快速浏览，特别是对全异步 rollout 参数互斥设计感兴趣的读者，可对照 miles/utils/arguments.py 中 _resolve_rollout_functions 理解校验意图。长期建议为该配方补充一条启动脚本快照测试或文档说明，避免再次出现绕过校验的写法。

NeMo-Gym 文档去除 fork 分支指引，改用上游 main

可快速浏览确认文档一致性，值得精读的价值有限。设计上值得留意的是：在集成外部依赖的未合入特性时，作者在文档中留下 fork 分支指引并同步标注"until it merges"，在特性合入后同一 PR 内同步清理三处引用，这种"临时指引 + 上游合入即回收"的做法对维护上游敏感集成很有参考价值。

新增 GLM-5.2 × tbench2 Daytona 16 节点参考 RL 示例

值得精读。重点关注三处：① PR body 的调优因果链（每项优化如何降低显存或提升并发重叠）；② recipe 的“配置即代码”组织方式（默认值 = 参考配置 + CLI 偏差）；③ 引擎 balanced/low-latency 双形态与 dp-aware 路由的耦合设计。若团队要在 GB300 上跑大规模 agentic RL，这份示例是最新起点；复用时注意核心参数与镜像日期的版本对齐，并考虑把新 launch 脚本接入快照 harness。

沙箱辅助函数上收共享 recipe，统一多 provider 资源策略

值得精读，尤其是三个设计决策：`run_with_deadline` 对 `with` 块的论证（线程池 `__exit__` 会 join 被放弃的调用）、配置归属原则（描述一个沙箱的 knob 放 create 旁、fan-out knob 放后端）、异常清理的 try/except 保护模式。建议结合栈的 3/3（#2276 Modal 后端）一起看完整演进，并留意后续 PR 是否补充 provider 层单位映射测试。