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`，让部署时的自适应行为可观测。
合并 autotune 缓存并修复 MXFP4 TP 对齐等六项杂项
值得精读，但只需重点看三个文件：`mxfp4_flashinfer_trtllm_moe.py` 的 `_pad_intermediate_size`（补齐布局与 scale 填充值的选择）、`flashinfer_autotune.py` 的 `flashinfer_autotune_context`（对 FlashInfer `AutoTuner` load/save 语义的绕过方式）、`fp8_utils.py` 的 `block_supported` 守卫（tuple/list 比较这种容易写错的细节）。`scheduler.py`、`fp8.py`、`weight_updater.py` 三处属于清理项，浏览即可。若你是 SM100 MXFP4 TP 配置的使用者，建议按 `print_warning_once` 的提示实测补齐后的吞吐，并与 TP/EP 组合对比；若你是维护者，建议把被删掉的 MXFP4 TP padding 回归用例以更轻量的形式补回，并在文档里明确“补齐只发生在权重加载后、形状契约以 `intermediate_size_per_partition` 为准”。
为 H20 新增 GLM-5.3-Flash block-FP8 MoE 调优配置
值得精读，但重点不在 diff 本身（只有 1 行代码 + 2 份 JSON），而在于它示范了 sglang 的 MoE 配置分发机制：文件名即查找键、M 桶分档、设备名隔离，以及调优器与运行时如何共享同一套 E/topk/intermediate_size 口径。建议关注三点：一是 `get_model_config()` 中 `Glm5NextForConditionalGeneration` 被加入外层白名单但未加入共享专家融合内层白名单的语义后果（E 不加 1）；二是小 M 与大 M 收益落差极大（1.9x vs 1.05x），不要向长 prefill 场景承诺同等加速；三是这类配置资产与 Triton 版本目录强绑定，升级 Triton 前需要预留重新调优的窗口。
放宽 MoE 入口守卫，MXFP8 dispatch 不再启动崩溃
值得精读，但属于「小改动、大信息量」的类型：31 行内完整体现了 dispatcher 侧量化契约演进后，入口守卫如何跟上。
重点关注：
1. 为什么用 `quant_info.use_mxfp8 and dtype == float8_e4m3fn` 的联合判定，而不是单纯 `quant_info.use_mxfp8`——理解这条「双条件」是为了避免配置与载荷不一致时静默走错路径，这个模式可以复用到其他量化入口的守卫。
2. `else` 分支完整保留原有两条错误信息，意味着作者刻意让既有 FP8 失败语义零漂移，这是低风险修补的示范做法。
3. 输出侧仍强制 BF16 的不对称设计，是阅读时最值得追问的一点：它到底是 TRT-LLM 的硬约束，还是当前实现尚未覆盖的遗留假设。
4. 建议后续补一个覆盖 `mxfp8` dispatch 的三分支单元测试，并考虑在 `else` 分支的错误信息中提示「`use_mxfp8` 与实际 payload dtype 不一致」这一可能原因。
让 fused_moe_triton 调优器支持 XPU，并新增 Arc Pro B60 的 DeepSeek-OCR-2 MoE 调优配置
值得精读，尤其是正在做多后端 Triton kernel 调优或维护 MoE 相关 benchmark 工具的工程师。三个值得关注的设计决策：一是用 `get_device_module` 一次性收敛同步、事件、图捕获与播种，避免在 kernel 里写 XPU 专用分支，这是「最小持续成本」路线的具体落地；二是 `clear_b_tma_desc_cache` 揭示的隐藏耦合——描述符缓存与图捕获内存争用，在长生命周期服务的语境下为什么是 no-op；三是把 topk_ids 层布局从硬编码改为从模型配置解析，代价是引入了对模型元数据字段的隐式依赖。阅读时建议同时对照 Intel Triton issue #7306 / #7691 与 PR body 中的 workload 结果表，并留意 `tuning_fused_moe_triton.py` 与 `_sep` 版本仍需保持行为一致，以及 review 中 airMeng 提出的下一步方向（KV cache store 等 memory-bound kernel）。
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` 为准。
修复工具调用序号、图填充计数契约、prefill 嵌入刷新等五项缺陷
值得精读。两个设计决策有学习价值：① 用"槽位存在性"表达数据契约——槽位不存在即契约无效，让 CUDA graph 静态批与 eager 批在两条路径上共享同一不变量，避免再次出现"graph 携带 stale 状态、eager 携带 None"的分叉；② replay 闭包处理输入槽位的模式——能从 kwargs、位置参数逐步回退到现场计算（get_input_embeddings），可复用于其他 graph runner 的输入刷新。建议合并前向作者确认非 EP 下其他 num_token_non_padded 读取点的审计情况。
DeepEP v2 支持 BF16 与批量不变的确定性推理
值得精读。这是一个「通信集合正确性工程」的完整样本：如何把 rank 相关的浮点求和变成 rank 无关、如何用配置校验避免静默错误、如何用 mock 观察 wire 格式、如何设计多 GPU 位级回归。重点看三个设计决策：`create_moe_dispatcher` 把 `quant_method` 传入所有后端分支（当前仅 deepep_v2 消费，未来可复用）；wire dtype 跟随时 checkpoint 而非自由开关；确定性 reduce-scatter 用 `input.clone()` 保持调用契约的细节。若团队正在做确定性推理或多卡一致性治理，本 PR 的测试方法论（4 卡批量 × 目标 rank 不变性 + `atol=0, rtol=0` 断言）可直接借鉴。
