vllm-project/vllm

多引擎 utility 调用等待全部收敛后再报错，支持安全补偿

值得精读。三个看点：(1) `join_all` 与 `try_join_all` 在"补偿安全"场景下的语义差异，是并发扇出错误模型的重要一课；(2) 用局部 RAII 守卫 `UtilityCallGuard` 统一异步取消、准备失败、发送失败的清理路径，是 Rust 异步代码清理资源的通用范式；(3) BugenZhao 的简化 commit 示范了如何把多分支错误处理收敛成单一 `Drop` 路径，并顺带修复普通 `call` 的取消泄漏。若后续要扩展 utility 协议或新增多引擎操作，建议直接复用这一模式。

修复 GLM-5.2 短 prefill 误走 dense MHA 导致输出退化

值得精读。这是一个典型的低改动、高影响正确性修复：改动仅 24 行，但涉及 sparse MLA 的 prefill 路由契约。建议关注两个设计点：一是用类级能力声明把后端能力与模型层能力解耦，避免 wrapper 未实现却由 indexer 错误宣告 dense 路径；二是在补实现与关能力之间选择后者，回归既有 MQA 路径，是控制复杂度的好例子。若你在维护其他 MLA 模型或 sparse attention 后端，应检查自己的模型是否也需要显式声明 `supports_dense_mha_prefill`。

解锁 MI325X 上 Kimi-K3 fused KDA 解码

值得精读。虽然 diff 极小（+15/-14），但 PR body 的 profiling 分析展示了 launch overhead（每 kernel 约 4 us）在未融合路径中的累积成本，以及"端到端收益受主导算子遮蔽"的判断方法——这是评估 kernel fusion 真实价值的常见陷阱。代码层面，"构建 gate、运行时 gate、测试 gate 三处同步修改"保证了单一事实源，避免 op 已编译但运行时不可达、或测试在目标机器上被误跳过的不一致状态。建议后续平台适配（如 gfx942r1、gfx12xx）复用该模式。

ROCm 按架构门控 FP8 scaled-MM，修复 gfx1100 误选

值得精读，虽是小改动（单文件 +26/-17），但揭示了 ROCm 上 kernel 能力判定的系统性陷阱：CUDA 数值 capability 与架构原生能力并非一一对应。重点关注两点：一是 `_supports_torch_fp8_scaled_mm()` 作为统一出口的分层设计；二是 TODO 中预留的 `torch.cuda.is_scaled_mm_supported` 替换计划，这是未来消除硬件白名单漂移的关键路径。建议后续将作者的手工验证脚本（平台路由矩阵 + gfx1100/gfx1201 正反用例）沉淀进 tests/，防止架构门控再次回归。

移除 FP8 Marlin 测试环境变量，改用公开后端配置并修复 CI 回退路径

值得精读，尤其是 vllm/model_executor/kernels/linear/__init__.py 的内核优先级调整和 scaled_mm/marlin.py 的 is_supported 简化。设计要点是"让兜底内核通过优先级列表自然出现，而不是靠测试环境变量强行注入"，同时配套测试必须感知实际后端选择结果。对于维护自定义 CI 或评测脚本的团队，建议同步排查是否仍引用 VLLM_TEST_FORCE_FP8_MARLIN 并迁移到 --linear-backend/--moe-backend。

标准化 FSE 检测，模型构建与权重加载统一量化兼容判定

值得精读。核心价值在于治理“双分辨率 bug 源”：把 FSE 判定收敛为单一来源（建模期 `resolve_layer_fused_shared_expert` + 模型级 `is_model_fused_shared_expert_compatible`），并让权重加载复用同一状态。值得关注的设计决策包括：量化兼容性检查只在用户显式请求 FSE 时执行（避免无谓开销）、AITER 不可用时归一化为 `False`、混合状态直接显式报错而非静默回退、Quark 层配置查找的精确/通配双模式。

移除 PaliGemma 遗留的图像 embedding 逆缩放，修复数值量级偏差

这是一个值得快速浏览的 PR，核心逻辑简单但在设计上有一个值得注意的教训：当上游模型（Gemma）调整 embedding 缩放策略后，下游多模态变体（PaliGemma）需要同步清理遗留的兼容代码。建议关注两点：(1) 仓库中是否还有其他基于 Gemma 的多模态模型存在类似遗留缩放；(2) 维护者删除测试文件的决定意味着该修复缺少长期回归保护，后续可考虑在仓库的多模态通用测试框架中补充 embedding 量级断言。

LLaVA-NeXT 启用 tower/connector LoRA 并修复 token 计数

值得精读。两个设计决策有借鉴价值：(1) 不扩散全局接口契约，优先复用已携带 `mm_kwargs` 的 `get_mm_lora_token_counts()` 做模型特定计算；(2) 对「占位符数不可逆」的复合 token 场景，用 `pixel_values` 的 tile 数前向推导而非反向推断。但需注意最终测试被删，若后续继续维护 tower/connector LoRA 栈，建议补回至少一个 adapter 加载 E2E 用例。