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` 为准”。
放宽 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` 为准。
