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`，让部署时的自适应行为可观测。
更新 AMD DSV4 配置：镜像 0914、PDI 20、cache-aware 路由
不需要精读，仅作为 DeepSeek-V4 部署配置演进的参考。值得留意的是：参数类文档变更若缺少基准数据，建议跟进一个附带 latency/throughput 验证的 PR；同时关注 0914 镜像与 cache_aware 策略在真实 MI355X 上的可用性。
修复 AMD 上 DSV4 MTP 崩溃，用 is_dspark 门控 D2H 优化
不值得精读，但值得记录。它展示了性能优化遭遇平台差异时的一种最小成本处理方式：不整体回滚，而是用 is_dspark 将优化限定在已知安全的平台。对 AMD 后端维护者而言，建议确认 is_dspark 覆盖了实际崩溃环境，并考虑补充自动化测试，防止回归。
ROCm 默认切 HIP Top-K，GLM-5.x 交互性提升
值得快速阅读（约 5 分钟）：单文件小改动，但包含一个可复用的设计模式——用 env 的 `is_set()` 判断区分“用户显式选择”与“平台默认值”，避免覆盖用户配置；同时以 A/B 数据驱动平台默认 kernel 切换。关注 AMD 平台支持、参数解析或环境变量契约的工程师建议阅读；对纯 CUDA 使用者影响很小。
Qwen3.5 MI355X HiCache 文档改回 kernel 与 page_first 后端
该 PR 本身不值得精读：6 行改动、无讨论、无测试。但值得关注两点：一是 cookbook 命令生成器与真实部署命令的一致性维护机制（recipe-link MAJOR-arg 检查），二是它与 #39358 的一来一回可作为 AMD HiCache 后端选型（`kernel` vs `direct`）演进的观察线索；若后续镜像版本再次调整 flag，应同步检查这份文档。
GLM-5.2 草稿专家层转逐通道 FP8，修复 Quark AITER 路径不可达
值得精读，尤其是量化/推理性能方向的工程师。建议重点看三处设计决策：（1）`should_apply_glm_nextn_moe_ptpc` 这一“同一判定服务权重转换与模块构建”的模式，以及提交 64c44144 为何要专门对齐两侧门控——这是静默数值错误的高发点；（2）`_resolve_nextn_quant_config` 从直接改动共享 `QuarkConfig` 改为 copy + deepcopy 的过程，以及配套的 `test_flag_on_does_not_mutate_caller_config`；（3）`QuarkW8A8FP8MoE` 的 runner 选择从死标志 `apply_router_weight_on_input` 改为 kernel 前置条件，并用 `print_info_once` 让回退可观测。若你负责 ROCm 上其它 quark FP8 MoE 模型的线上服务，建议在升级后对比 AITER 与 `--moe-runner-backend triton` 的表现与数值一致性和显存形态。此外，PR body 与最终实现存在文件位置不一致（body 仍写 `deepseek_weight_loader.py`），阅读时应以 `glm4_moe.py` 的 `GlmMoeDsaForCausalLMNextN` 为准。
修复 ROCm 上 EAGLE verify 静默贪心采样，HIP 接入 Triton 采样链
值得精读。核心价值不只是那个 `_verify_uses_greedy` 门控，而是整套“默认行为变更 + 数据链打通 + 底层 kernel 守卫”的联动修复。建议重点关注：`_verify_uses_greedy` 如何做到非 HIP 平台字节等价、`speculative_hook.py` 中 `cfg` 与 `resolved_view` 的读写契约差异、以及 `reject_sampling.py` 中 q 守卫的两次迭代（residual 与 accept test 分别加固）——后三者都是一般 review 容易漏掉的隐蔽点。
