2026-09-16
Router 新增饱和下限，全队排队时钉住前缀拥有者
值得精读：`policies/admission.rs` 的 pin 分支是完整的「何时不该分流」判据实现，`policies/engine_load.rs` 的极性注释解释了为什么缺采样两个方向的默认动作都是留在前缀拥有者。重点关注三个设计决策：floor 与 limit 的取值关系如何决定标签口径；压力排序与缓存局部性排序之间的取舍（作者明确标记为未决）；`all_queued` 语义扩张对现有看板的影响。若计划在生产启用，建议先确认 prefill 舰队负载采样覆盖率，并观察 `saturation_pin` 与 `all_queued` 计数是否出现预期外的增长。
修复始终失败的覆盖率 Job，新增按 GPU 数统计视图
值得精读，尤其是长期维护 CI 的人。重点看两处设计决策：一是用 `set -o pipefail` + `|| echo` 把「非门禁」从意外行为改成显式契约，以及随之而来的问题发现责任转移；二是 `_SUITE_ACCEL_COUNT_RE` 用 `(?:^|-)` / `(?:-|$)` 锚定来区分 runner 规模与 `-tp4`、`qwen3-235b` 这类同名数字，这类「从命名反解元数据」的做法在新增套件命名不规范时会静默失真，建议后续补一个覆盖 `stress`、`mm-gen-*`、`-tp4` 等边界的单测。可略读 `by-gpu-count` job 与 JSON 字段部分，属机械扩展。
路由器按请求强制与注入采样契约，拒绝码与指标落地
值得精读，尤其是三处设计决策：(1) `ProbedValue` 三态把「省略 / 可读数字 / 读不出」在反序列化期一次定形，避免了在每次请求上物化客户端大小的 `serde_json::Value`；(2) `parse_as_engine_number` 的注释解释了为什么不能靠推导 pydantic 规则写这个函数（Python 数字字面量规则与 pydantic 在 `1._5`、`1e_5`、`-_1` 上不一致），以及为什么 `reject` 选择 fail-closed；(3) 采样键 last-wins、路由键重复即 400 的非对称设计，理由是「让契约比较的值与引擎真正采样用的值一致」。建议重点关注：注入语义对客户端的影响评估、`Unusable` 误拒的线上可观测性、以及 stack 3 是否真的消除了 `build_outgoing_body` 的额外解析开销。适合作为「如何为跨 fleet 的强制契约编写 fail-closed 守卫、并为灰度准备指标」的工程范例。
Router 新增在途 HTTP 计数，随响应体结束才释放
值得精读，但只需聚焦两个文件：`src/server/inflight.rs`（计数原语与 RAII 守卫的设计，全文是标准「streaming 会计」范式）与 `src/server/app.rs` 的 `count_requests`（唯一的接线点，一行 `resp.map(...)` 承载了全部语义）。阅读时重点回答三个问题：(1) 为什么守卫必须挂在响应体而不是 handler future；(2) 为什么必须是 `Drop` 而不是显式 decrement（客户端中途断开）；(3) 为什么 `Relaxed` 足够。测试部分值得看的是「非空性验证」思路 —— 作者通过把守卫改回 handler 出口释放来证明测试不是空断言，这种自我证伪值得借鉴。追 #39016 时建议回看本 PR，确认 drain 的等待条件确实基于这条 gauge，并补充 gzip / timeout 层下的在途观测。夹带的 `pd_protocol_binding.rs` 修复可略读。
Router 新增队列闸门：排队 worker 不再凭缓存亲和夺冠
值得精读，尤其是做路由 / KV 局部性 / 负载均衡的同学。重点看三处设计决策：(1) 为什么用 `num_waiting_reqs` 而不是 in-flight 或运行深度，以及 fail-open 的取舍（`queue_gate_admits` 的注释本身就是设计说明）；(2) 两条「第二层」为何不是同一个条件——这是把闸门从「一个 if」变成「一个可上线的特性」的关键，PR body 里「with a single prefix owner the gate rejects it, the set empties, the ungated tier re-admits that same queueing owner, and affinity traffic keeps flowing exactly where the gate meant to divert it」是最值得记住的一段；(3) `cache_aware_fallback_decision` 的判定顺序（`fleet_all_queued` 先于容量）如何决定「饱和 fleet 会不会读成健康 fleet」，这条正是 review 抓出来的 bug。上线前建议先确认引擎确实发布负载样本，并在目标 fleet 上评估 `fleet_is_all_queued` 的每请求开销。
HiCache 指标按 rank 打标并拆分 shrunk 归因，修复多 rank 求和失真
值得精读。如果团队将 HiCache 作为生产级分层缓存使用，本 PR 的指标语义约定（per-shard vs logically replicated、attempt 级诊断 vs 最终 miss 计数）是解读后续 HiCache 面板和告警的前提。特别值得学习的设计决策：一是 rank 标签与 storage collector 键约定对齐，避免 L2/L3 两层指标无法关联；二是在重构导致某些 reason 失去代码路径后，保留 label 预置以维持 dashboard 稳定、同时明确文档口径；三是把"窗口字节 delta / duration sum"定义为活跃带宽，区分纯 rate 含空闲时间的口径。
为 sgl-router 监控看板新增 KV 分层存储覆盖率三面板
这个 PR 最值得精读的是 PR body 而非 diff：其中关于"跨 namespace 相除会得到一个漂亮的错误数字（0.54 vs 1.00）"、"检查查询的值而非仅仅检查返回行"、"max 会掩盖 quietest replica 失联"的监控设计论证具有普遍借鉴价值，适合负责可观测性面板与告警设计的工程师参考。建议与 #39109、#39110 按 stack 顺序一起阅读，了解指标从产生、测试到面板化呈现的完整链路。
修复首 token 延迟元数据与复用层 attention 索引
值得快速精读。两个修复都很小但边界处理值得借鉴：index_attention_layers_by_global_id 用对象引用相等区分“复用”与“重复”，并保留位置索引表的语义；convert_to_output_meta_info 用 first_token_time > created_time 的守卫防止脏延迟输出。关注点：复用层返回原始表后，调用方对表长度的假设是否仍然成立。
