2026-09-16
DSV4.1 新增索引器内核，重做 Top-K v2 分派
建议精读，重点关注三处：`topk.py` 的探测驱动 JIT 宏与 `plan_topk_v2` 默认值语义、`topk_impl.cuh` 的 NaN padding 与 `coarse_bin_lower_bound` 的 round-to-even 补偿、`topk_v2.cuh` 的 `PageTransform` 解耦与 cluster 8/16 分派。四个值得学习的设计决策：用 NaN 而非极小值填充以保护合法的 -inf；用 ULP 步进而非重算 fp16 bin 处理 round-to-nearest-even；用 `cudaOccupancyMaxActiveClusters` 而不是 SM 数除法定 pool 尺寸（GPC 约束）；把 page-table 变换从选择内核解耦成独立结构以便两种输出模式共用。若负责索引器或 Blackwell 性能，建议先补齐 BBuf 要求的边界 benchmark 再信任这些阈值，并为三个新内核补注册测试。
为 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 前需要预留重新调优的窗口。
抽出 DSV4.1 独立内核与 Python 封装，作为 PR 栈首层合入
值得精读，尤其是准备接 #38798 / #39648 的工程师与负责 DSV4.1 内核维护的同学。
- 优先看三处设计决策：`small_gemm_bf16.py` 的 `MAX_M` 策略上限与 `can_use_*` 契约（调用方负责回退，内核只做「形状正确即最快」）；`mxfp8_epilogue.py` 的 UE8M0 舍入 + 128x4 swizzle 偏移 + padding 槽位裁剪策略（多 CTA 写集合不相交的隐含证明）；`q_rope_store.py` 的 prefill/decode 分支与 int64 偏移、PDL 开关。
- 阅读时把每个 `assert` 当成调用契约而非防御式编程：这些断言定义了调度层必须满足的形状、stride 与设备前提。
- 跟进项建议：(a) 按 BBuf 的意见把 `candidate_blocks.py` / `indexer_postprocess.py` 的独立覆盖补进本层或明确移交 #39648；(b) 为 `engram_gather` 补 owned / unowned ID 的用例；(c) 刷新 PR 描述中已过期的 byte-identical 声明与文件统计，避免后续审计引用失效结论；(d) 如计划支持非 Blackwell 平台，尽早确认 `can_use_*` 谓词在所有调用点的使用方式。
让 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）。
修复 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 容易漏掉的隐蔽点。
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` 断言）可直接借鉴。
