radixark/miles

fully-async rollout 迁入核心库并清理 PYTHONPATH hack

值得快速阅读，重点看迁移模式和 PYTHONPATH 清理的边界处理。真正值得精读的是后续的类化 API 重写 PR（stacked follow-up）和 `--fully-async` 参数落地 PR，本 PR 可作为理解 fully-async 架构的入口文档。注意 gemini 提出的 `ModuleNotFoundError` 风险点，若仓库未强制安装 miles 包，建议合入后补一个环境验证。

补齐测试夹具缺失的 spec 解码参数

建议快速合并。值得关注的点是：本 PR 暴露了手工构造 session server 命名空间的脆弱性，后续可以考虑抽一个公共构造器（例如 `make_session_server_args`）统一维护字段列表；另外在新增 server 侧读取的 args 时，应同步搜索所有 `SimpleNamespace` 构造点。

新增 Inkling 家族 TITO 支持，可跑多轮会话

值得精读，重点看三个设计决策：1) 优先复用 HF 原生 `chat_template.jinja`，仅把固定模板用作测试渲染基准，避免双份渲染逻辑长期漂移；2) 用四个角色 sentinel 固化 comparator 边界，把 assistant 轮之后的非 assistant 内容差异提升为硬失败，这是 TITO 追加式会话正确性的关键；3) 大权重进不了 CI 时先用 slice 手动验证并如实记录缺陷边界，而不是注册无人验证过的配置。建议结合 sgl-project/sglang#32958 的解析器修复一起阅读，理解 serving 侧约束。

补齐 session 路径 spec 计数器采集

值得快速精读（约 10-15 分钟）。这是一个教科书式的“双路径重复实现导致指标失真”案例：PR body 对根因、实测数据、修复后效果和数据可用性边界的分析非常扎实，尤其“修完 `spec_accept_length` 但 `spec_accept_rate` 仍为 0，因为字段缺失而非 bug”的区分，展示了严谨的排查方法论。后续建议以 `# TODO unify with Sample.update_from_meta_info` 为线索，推动 session 与直接 rollout 路径的元数据采集逻辑合并，从根本上消除此类分叉。

开启 dp-attention 时自动启用 dp-aware 路由

PR 虽然只有 3 行源码 + 28 行测试，但值得精读：PR body 提供了完整的生产故障分析（GLM-5.2 744B 上 dp rank 排队与超时数据），展示了如何把线上指标转化成一行默认行为修改；默认开启而非新增开关的设计取舍也值得借鉴。建议重点看 validate_args 的参数编排位置与测试中手动补齐 RouterArgs 字段的做法。

按 indexer_rope_interleave 条件量化 DSA indexer wk

值得精读：它展示了对历史修复的回溯修正，以及基于下游引擎（SGLang）参数布局做条件化量化的设计模式。建议结合 #1928 一起阅读，理解 DSA indexer 在 interleaved/非 interleaved 下的差异；同时关注 `indexer_rope_interleave` 配置在模型转换链路中的传递可靠性。

PPO 支持 Actor/Critic 共享 GPU 训练

值得精读。本 PR 展示了“driver 拥有 offload 计划、actor 拥有机制”的生命周期所有权拆分、基于 `_asleep` 的幂等 offload/onload（retry-safe）、用 Ray object reference 替代 NCCL 广播的数据交接方式，以及对 `kl_coef`（GAE 折扣）与 `kl_loss_coef`（KL 惩罚）语义差异的细致处理。建议重点关注 `miles/backends/megatron_utils/actor.py` 的 train/sleep/wake_up 与 `miles/ray/placement_group.py` 的布局计算，并跟踪后续“critic 独立参数、multi-critic、不同并行度”等 TODO 的演进。

共享服务器腿改原生打分，退役适配补偿

值得精读，尤其适合想理解「删除兼容分支时如何保正确性」的工程师。三个看点：(1) 运行时契约守卫的设计——当 preflight 不可行时，用回复自身的契约指纹（info.harness）把静默误打分变成大声失败；(2) 跨仓库边界的演进编排——miles 侧 PR 明确依赖上游 OpenEnv#1012 且给出双向不兼容的切换顺序；(3) review 中 Shi-Dong 抓出的 0.0 vs None 差异，是「删除看似等价代码」时最容易漏掉的行为边界。