vllm-project/vllm

注意力后端构建器类型标注统一改为 KVCacheSpec

值得精读。重点关注三点：1）mypy 对 `__init__` 与 classmethod 在 override/Liskov 检查上的差异，这是很多类型错误标注的根源；2）`KVCacheSpec` → `AttentionSpec`/`MambaSpec` 的类型分层与"子类类级属性注解收窄"模式，可迁移到其他插件式抽象基类；3）review 中泛型化方案被否决的权衡过程（会污染 out-of-tree builder 签名且调用点拿不到窄类型），展示了类型 API 设计时对第三方扩展方的考量。对只关注运行时行为的读者，可直接跳过。

K3 DSpark 草稿模型启用 all-reduce 与 RMSNorm 融合

值得精读 dspark_mla.py 的 forward 改造，它是‘延迟 all-reduce、融合进下一个 Norm’这一高性能模式的简洁示例；同时可关注 vllm/models/common/ops 目录的演进。建议在后续 PR 中补充该融合路径的数值对齐测试，减少对人工评估的依赖。

明确 split_audio 单声道要求，立体声输入直接报错

PR 体量小、逻辑清晰，值得快速阅读，重点看两点：一是为什么用 `ValueError` 而不是 `assert`（防御性 API 设计的常见取舍）；二是如何在文档、测试、调用点三处同步对齐一个数据格式契约。不建议过度投入精读，但可作为“契约澄清型小改动”的范例。

FusedMoE 更名 FusedMoEFactory，全仓 80 文件同步

值得精读，但重点不在代码逻辑（无行为变更），而在两点：其一，通过 80 个文件的改动清单可以快速梳理 vLLM 中所有 MoE 相关模块的全景依赖关系；其二，review 中关于 FusedMoEFactory 与 MoERunner 的命名语义讨论，是“工厂函数命名 vs 运行时类命名”的良好工程案例。若后续有人重新落地该改名，建议同时解决 laguna.py 注释重复问题，并利用 grep 断言的 CI 检查保证旧名不再出现。

更新 ROCm Transformers AR+RMS 融合测试期望

值得快速浏览，属于测试期望与编译器 pass 行为联动的典型小样本。对 torch.compile / fusion pass 与端到端测试期望设计感兴趣的工程师可以精读：关注 #48757 的 canonicalization 如何改变图结构、`_replace` 覆盖为何不可省略，以及将 CUDA 扩展推迟到单独 PR 的范围管理思路。

INT8 MoE 权重预打包职责下沉到内核

值得精读，尤其适合关注 MoE 内核架构与量化权重处理链路的工程师。核心看点是 prepack 归属权的设计取舍：为什么从 backend 下沉到 kernel、如何通过 `process_weights_after_loading` 对齐既有 `FusedMoEExperts` API，以及后续新增 CPU 内核（如 s390x）时如何只改内核类即可。建议同时阅读 `compressed_tensors_moe_w8a8_int8.py` 与 `online/int8.py` 两处入口的调用顺序，理解内核创建与权重打包的先后依赖。

s390x CPU 推理优化并新增 oneDNN INT8 GEMM 支持

值得精读的文件是 csrc/cpu/cpu_types_vxe.hpp 与 cmake/cpu_extension.cmake：前者展示了 SIMD 树形归约与 minimax 多项式近似的工程写法，可对照 FP32Vec8/FP32Vec16 的职责拆分；后者展示了构建期对第三方库打补丁的 hack 方式，可作为反面教材关注其可持续性。建议重点关注两点：一是 INT8Vec16::save 的越界检查是否在合并前补齐，二是 fadara01 提出的统一 exp 分发方向（将 DEFINE_FAST_EXP 收敛为所有后端共用的 vec.exp() 调用）是否会被后续 PR 采纳。

XPU RMSNorm 统一到 vllm_c，删除重复实现

值得快速精读，尤其是 `vllm/kernels/vllm_c.py` 中 `GPGPU_DEVICE` 的引入方式——通过一个平台聚合布尔值来扩展内核注册范围，是 IR 内核统一化的简洁范例。同时可关注 `get_default_ir_op_priority` 中 `vllm_c > native` 的优先级设计，理解 IR 的注册-选择-回退机制。对于 XPU 内核维护者，建议在合并后补充一次针对非连续输入与高维输入在真实模型上的 smoke 验证。