2026-09-16
AITER norm 派发新增展平守卫，避免隐藏整张量拷贝
值得精读，尤其是 ROCm 平台维护者、负责 IR op dispatch / 内核路由的开发者，以及任何要写 AITER 或其他设备专用 op 谓词的人。三个最值得关注的设计点：其一，把「数学上支持」的谓词扩展成「数学支持且不做隐藏拷贝」的收益性判定——这是 supports_args 语义的一次细化，改变了谓词作为内核选择裁决层的定位；其二，`flatten_to_2d_is_free` 用 stride 推导复现 `Tensor.reshape` 的视图可表达性，并特意豁免 size==1 的维，是可直接复用的工具函数写法；其三，作者主动披露 vllm_c 兜底缺口并拒绝在本 PR 扩大范围，这种「精确收益 + 已知缺口」的分割方式值得借鉴。阅读时建议重点核对三件事：谓词拒绝后回退路径在当前版本 Inductor 下是否真的不物化拷贝、`-O.backend=eager` 等关闭 Inductor 的配置是否会出现小幅回退、以及本 PR 未提供自动化 dispatch 断言所带来的长期回归风险。
ROCm MLA RoPE 测试改为按 ULP 分级容差
值得精读，尤其是从事 ROCm 内核、数值测试或 CI 稳定性的工程师：这是“不要靠调 atol/rtol 掩盖数值差异”的一个正面范例，用 FMA 预舍入选择推导出 2 product-ULP 的物理上界，再用失败比例上限约束整体行为。阅读顺序建议：先看 PR body 中 Triton 3.7 vs 3.8 的 lowering 对比理解动机，再看 `assert_rope_close_rocm` 的 Tier 1/Tier 2 双段断言与 NeoX/交错两套乘积推导，最后看 `test_concat_and_cache_mla_rope_fused` 如何用 slot_mapping 把 KV cache 的 rope 区段收集回 token 顺序、并把 nope 区段保持严格比对。需要留意的设计决策是 bf16 的 `max_fail_fraction=1e-2` 取值依据（仅由 eps 更粗解释）以及 fp8 分支未被纳入统一模型；若后续要推广该断言，应先确认这两个边界。
kpool 索引器迁入 glm5next 并拆分后端
值得精读，但重点不在 729 行的搬运量，而在三处设计决策：一是 `vllm/models/glm5next/sparse_indexer.py` 这个 22 行 dispatcher——它决定了所有平台行为，CodeRabbit 指出的「非 ROCm 即 NVIDIA」回落值得你判断是否要改成显式平台判定；二是 `CustomOp` 的 `forward_hip` / `forward_native` dispatch 契约，任何把实现按硬件拆文件的改动都要先确认被覆写的方法名与 `dispatch_forward()` 的绑定规则一致，否则就是 Codex 那条 P1；三是 helper 抽取边界——只抽纯索引/形状逻辑、把 kernel 调用留在后端文件，这个尺子本 PR 把握得比较准，可以照搬到其他模型。若你在 ROCm 上使用 `custom_ops=["all"]` 或 enforce-eager，建议先确认 `forward_hip` 是否已补上再升级；若你的代码直接 import 了 `vllm.model_executor.layers.sparse_attn_indexer_kpool`，需要同步迁移到 `vllm.models.glm5next.sparse_indexer`。
AMD CI 新增可选 TheRock 镜像构建路径
值得精读但优先级中等：核心价值在 `.buildkite/scripts/rocm/build-config.sh` 的“一个共享选型 + 严格校验 + 三级变量回退”设计，以及 `configure_custom_rocm_stages` 与 `init_bake_files` 中“自定义栈不污染稳定 tag / registry 缓存”的隔离策略，这是 CI 复用与实验隔离的通用范式，可直接迁移到其他硬件或镜像变体。建议后续补两块：(a) 为 `validate_rocm_dockerfile`、`using_custom_rocm_dockerfiles` 增加 shell 级单测（本 PR 已主动移除回归测试，存在回退缺口）；(b) 把“自定义配方必须提供的阶段契约”写入文档或脚本头部注释，减少未来按错误配方配置 CI 的排查成本。
修复 MiniMax-M3 ROCm fused MXFP8 block scale 下溢，补回归测试
值得精读，重点在于 Issue #53668 的复现方法论：作者在无 ROCm 硬件的环境下用 Triton CPU interpreter 精确复现了量化下溢，给出最小复现与新旧公式对照，并说明该问题属于 PR #53110 未覆盖的第二个实现。PR 本体改动极小且被 reviewer 快速确认，是「同源 bug 双实现遗漏」的典型修复样本；对维护者而言，可考虑后续将 fused kernel 的 scale 逻辑直接抽取复用共享 reference，从根本上杜绝再次分叉。
Kimi-K3 SiTUv2 MoE 默认改用 AITER a4w4 FlyDSL 内核
值得精读。该 PR 是理解 vLLM 与外部 kernel 库（AITER）协作契约的典型案例：环境变量版本兼容（deprecated alias）、模块导入时一次性 env 同步（_sync_aiter_situv2_moe_env）、workaround 作用域收窄，都是可复用的设计手法。建议重点关注 _sync_aiter_situv2_moe_env 的幂等设计与 AITER 优先检查 A8W4 的 dispatch 细节，以及 oracle/mxfp4.py 中权重布局与 kernel 选择的耦合方式。若关注 ROCm 性能演进，可结合 AITER #4463 的 tuned CSV 数据一起阅读。
修复 GLM-5.3-Flash Quark MXFP4 权重加载崩溃与 scale 名误匹配
值得精读，尤其对量化加载链路（Quark、`AutoWeightsLoader`）和模型目录组织感兴趣的开发者。本 PR 展示了“以 checkpoint 事实驱动修复”的典型路径：先用 `config.json` 验证 `layer_quant_config` 的键形式，再决定修模型映射还是修量化库，避免在通用层引入不当行为。测试设计（用 recording param 隔离加载路径）也值得借鉴。
清理 8 文件 1895 行死内核代码，覆盖 AMD 与量化算子路径
值得快速浏览，不必精读。它展示了 vLLM 中临时代码生命周期的管理实践：在 docstring 中写明删除条件（如 AITER 修复版本），到期后由维护者执行清理。对于内核与算子维护者，建议关注两个设计决策：一是 lamport.py 中基于 PDL 的死锁规避证明方法，这是跨 GPU 通信 kernel 的高价值设计文档，即使代码被删除也值得从 git 历史中学习；二是 triton_fp8_mqa_logits.py 中针对 gfx942 LDS 预算的 tile 大小自适应判断，展示了 Triton kernel 在特定硬件上做 occupancy 与硬件上限双重校验的思路。另外，本 PR 完全没有 review 讨论，阅读时建议自行核对删除边界，或在需要修改这些目录时通过 git blame 追溯删除决策。
