2026-09-16
合并 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 前需要预留重新调优的窗口。
抽出 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_*` 谓词在所有调用点的使用方式。
放宽 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 不一致」这一可能原因。
XPU 块状 FP8 线性改用 torch scaled_mm，并预排布 scale 存储
值得精读，但重点不在算子本身，而在三处工程决策：一是派发层级的选择（把平台分支放进 _dispatch_auto_backend 而非顶层，保证显式 backend 仍可覆盖），这是容易被写错且直接破坏用户配置的细节；二是用公开 API torch.nn.functional.scaled_mm + ScalingType 显式表达 activation 与 weight 两套 block scale 配方，替换私有 torch._scaled_mm 关键字参数写法，可读性与前向兼容性都更好；三是把 scale 的 transpose-contiguous 物化提前到 process_weights_after_loading_block_quant，属于典型的「热路径代价前移」优化。建议后续补充：XPU 上 Triton vs scaled_mm 的延迟对比数据、在派发处增加 torch 版本/能力兜底，以及确认除 w8a8_block_fp8_linear 之外没有其他读取 weight_scale_inv 的消费方依赖行连续布局。
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` 为准。
