2026-09-16
MORI intranode grid 按设备 CU 数收敛，避免小 CU 设备 barrier 死锁
值得精读，但只需读一处的 9 行代码 —— 它是一个信息密度很高的小修复：既展示了 MoE dispatch kernel 中 grid-wide barrier 对 block 驻留数的硬约束，也展示了“保守上界 vs 实测驻留上限”的典型工程取舍。
精读建议关注三个点：(1) clamp 放在 dtype 分支之后而非 fp4 分支内部，是否是有意的“全局收敛”；(2) `EpMode.INTRA_NODE` 与 `mori.ops.EpDispatchCombineKernelType.IntraNode` 双枚举判定是否等价；(3) `torch.cuda.current_device()` 在初始化早期是否已被正确设置。
对审阅者的行动建议：合入方向正确，但应把两件事补上——一是为 96 CU DPX 场景和非 fp4 dtype 路径补一个可复现的回归测试（哪怕是在 CU 数受限的模拟配置上断言 `block_num <= cu_count`）；二是补充 SPEED 数据或至少在 PR/文档中记录 grid 缩小对 EP4 吞吐的实测影响，避免后续把性能回退误判为 kernel 问题。同时建议在创建 MORI 配置后打印最终的 `block_num`，让部署时的自适应行为可观测。
NPU Dockerfile 默认工作目录改到仓库根目录
不建议为此 PR 投入深度精读——它就是一行 `WORKDIR` 修正加一行注释，读完 patch 即可理解全部语义；真正值得略作停留的是两个设计层面的信号：(1) 参照同文件里 `TARGETARCH` 的 fail-fast 校验，是否应为 workdir 增加一个轻量断言（例如构建期检查 clone 目录存在），避免 `WORKDIR` 静默创建空目录这一失败模式；(2) 其他 Dockerfile（`docker/Dockerfile`、各平台镜像）是否也应统一到 `/sgl-workspace/sglang`，否则不同镜像的 CWD 约定会继续分叉，给文档和 CI 脚本带来长期维护成本。另外建议关注 `Latest PR Test (Extra)` 的那次失败是否有后续 issue 跟踪。
修复始终失败的覆盖率 Job，新增按 GPU 数统计视图
值得精读，尤其是长期维护 CI 的人。重点看两处设计决策：一是用 `set -o pipefail` + `|| echo` 把「非门禁」从意外行为改成显式契约，以及随之而来的问题发现责任转移；二是 `_SUITE_ACCEL_COUNT_RE` 用 `(?:^|-)` / `(?:-|$)` 锚定来区分 runner 规模与 `-tp4`、`qwen3-235b` 这类同名数字，这类「从命名反解元数据」的做法在新增套件命名不规范时会静默失真，建议后续补一个覆盖 `stress`、`mm-gen-*`、`-tp4` 等边界的单测。可略读 `by-gpu-count` job 与 JSON 字段部分，属机械扩展。
为 Router e2e worker 限定显存预算并禁用 prefill 图，消除启动 OOM
建议精读，但重点不在 diff（只有 22 行、单一测试基建文件），而在 PR body 的诊断链路。值得关注三点：一是「KV 池按卡容量分配、slack 却被激活预留独占」这条内存计费缺陷的完整账本，它解释了许多人遇到过的‘小模型反而更容易 CUDA graph OOM’现象；二是把测试夹具参数收敛成单个 `CI_WORKER_ARGS` 常量、复用既有 `worker_args` 契约而不改读侧的设计手法；三是作者主动标注的后续动作——应针对 memory profiler 开 issue，让 KV sizing 为 graph capture 预留额度。评审/维护者后续应确认两件事：新增 e2e spec 是否强制携带 `CI_WORKER_ARGS`，以及在更大显存或非 H100 runner 上 0.6 这个比例是否仍然合适。
清理 Diffusion 死代码与 PipeFusion 遗留，净删 1264 行
值得精读，尤其是 `parallel_state.py` 与 `group_coordinator.py` 的合并方式：它展示了如何用通用实现替换专用实现并同时修复资源泄漏，新增的 Gloo 生命周期回归测试是验证分布式资源释放的很好模板。对于维护 diffusion 模块的工程师，建议关注 PP = 2 场景在合并后的通信行为，以及被删除环境变量是否有外部依赖。
清理 SRT 大量死代码与废弃测试，净删 3159 行
值得精读，尤其适合作为“大规模死代码清理”的范例：PR body 给出了每类删除的可验证论证（调用方扫描、import 检查、动态查找、测试矩阵隔离对比），并量化了删除的测试收益与保留项。值得关注的设计决策包括：缓存键简化为 UUID 列表、用 main/PR 测试计数差精确对齐删除的测试用例、以及删除 scanner 测试但保留行为测试的“迁移后退役守卫”模式。对编译、模型加载与 HiCache 模块维护者，建议留意编译缓存键变化与三个守卫测试退役后的长期影响。
修复 NPU 多 stage PP 启动崩溃，去掉失效属性引用
值得花几分钟精读，但不是因为改动的技术难度，而是因为它揭示了一个可复用的工程教训：删除公共属性（#38293）与新增对该属性的引用（#38249）在时间上交错，最终由 NPU 用户在启动阶段埋单。阅读时建议重点关注三点：① 作者在 PR body 中的根因回溯链路，理解「跨 PR 集成缺口」是如何形成的；② `all_gather_group` 从条件取值改为恒取 `attn_tp_group` 的语义变化，是否会影响下游 all-gather 分支；③ 该路径为何没有自动化测试，以及在 NPU CI 中加入 `pp-size > 1` 启动冒烟用例的可行性。若你是 NPU 相关代码的维护者，建议顺手排查其他平台分支（XPU/ROCm）是否存在同样指向 `require_attn_tp_allgather` 的残留引用。
真实 GPU e2e 测试覆盖 HiCache 分层缓存路由
值得精读。虽然纯测试变更，但测试设计方法论有很高参考价值：用引擎自身记账而非树状态做 payoff 断言以避免 vacuous pass；按 owner 份额而非集群总量计算驱逐预算；驱动式而非固定请求数；验证前提（双 worker 注册）而非假设；参数化覆盖面相反事件顺序。建议结合系列前序 PR（tier-aware tree 与 metrics 支撑）一起阅读，并关注后续第 4 部分。
