View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

vLLM 开发动态报告 - 2026-02-24

时间窗口: 2026-02-24 11:31 (UTC+8) ~ 2026-02-25 11:31 (UTC+8) 数据统计: 新 Issue 18 | 关闭 Issue 17 | 新 PR 74 | 合并 PR 30 | 关闭未合并 PR 26

📊 每日开发状态摘要

本周期（2026-02-24至2026-02-25），vLLM 项目处于高速开发迭代阶段，新增 PR 74个，合并 PR 30个，显示出活跃的代码贡献和高效的审查合并流程。开发焦点集中在性能优化、内核改进（尤其是 AMD ROCm 平台）、以及修复模型推理与编译相关的各类 Bug。一个显著的趋势是多模态大模型（特别是 Qwen 系列）在高并发场景下的稳定性和内存问题引发了深入讨论。

🎯 AMD/ROCm 生态相关动态

本周期 AMD 生态相关活动活跃，主要集中在 ROCm 平台的性能优化、内核完善和 CI 测试扩展上。

  1. PR #35246 ([ROCm] Refactor attention backend selection logic)：重构了 ROCm 平台的注意力后端选择逻辑，旨在提高代码可维护性和调度清晰度。
  2. PR #35250 ([Bugfix][Hardware][AMD] Gate FP4 ops on gfx950 to prevent MI300X crash)：关键修复。为 gfx950 (MI300X) 专用的 FP4 BMM 和 FP4 ASM GEMM 操作添加了硬件检查门控。此前在 gfx942 (MI300X) 上启用相关环境变量会导致非法指令崩溃。此修复确保了功能仅在支持的硬件上启用。
  3. PR #35245 ([ROCm][WIP]: Fused aiter rope kvcache mla)：致力于为 ROCm + AITER 平台实现 RoPE + KV Cache + Cat 操作的融合内核，目标提升如 DeepSeek、Kimi 等 MLA 模型的推理效率。此 PR 依赖于多个前置 PR。
  4. PR #35239 ([ROCm][CI] Added MI325 mirrors (stage C))：扩展 AMD CI 测试范围，在 MI325 节点上为更多测试组（如入口点集成、示例、标准语言/多模态模型测试）启用“镜像”测试，标志着 ROCm 支持的成熟度和测试覆盖度的提升。
  5. Issue #35169 ([Bug]: Memory Access Fault during Step-3.5-Flash inference (ROCM))：用户报告在 ROCm 平台上运行特定模型时遇到内存访问错误，已自动标记给 ROCm 相关维护者，表明社区对 AMD 平台问题的响应流程。
  6. PR #35183 ([ROCm] Split wvSplitKrc into deterministic/fast kernels, add --fast-skinny-gemm CLI flag, overhaul tests)：将 wvSplitKrc 内核拆分为确定性版本和快速（非确定性）版本，并引入 CLI 标志让用户选择，默认提供确定性结果以确保正确性。同时全面重写了测试套件，将运行时间从90分钟以上大幅缩短至7分钟以内，显著提升了开发效率。
  7. PR #35180 ([ROCm]: Enable customop and rope+kvcache fusion for AITER RoPE)：修复并默认启用 AITER RoPE 自定义操作，同时启用 RoPE 与 KV Cache 的融合。测试显示在 gpt-oss 模型上带来约1%的性能提升，并为后续 MLA 模型的融合优化奠定基础。

分析：本周期 AMD 生态的动态呈现出从“功能可用”向“性能优化”和“体验完善”深化的特点。既有防止硬件崩溃的关键安全修复，也有旨在提升推理性能的融合内核开发。同时，CI 测试范围的持续扩大和测试效率的优化，为 ROCm 支持的长期稳定性和开发体验提供了重要保障。特别是将内核拆分为“确定性/快速”两种模式，体现了对生产环境不同需求（正确性 vs 极致性能）的细致考量。

💬 高热度讨论分析

  1. Issue #35191 ([Bug]: Qwen3.5 397B FP8 fills 1TB RAM and OOM killed with high-concurrency multimodal requests)
    • 核心议题：用户在使用 Qwen3.5-397B-FP8 模型处理高并发多模态请求时，遭遇系统内存（RAM）线性增长直至 OOM（耗尽1TB）的问题。
    • 观点与排查：
      • 用户 (FWao)：详细描述了问题现象，指出在多模态缓存命中率降至零后，内存开始不受控制地增长。尝试了禁用前缀缓存、调整多模态编码器 TP 模式、禁用异步调度等多种方法均未解决。
      • 维护者 (DarkLight1337， ywang96)：首先排除了前缀缓存（对混合模型默认关闭）和常见高并发警告日志的影响。建议用户尝试移除 --mm-encoder-tp-mode data 参数。
      • 其他用户 (cjackal)：指出这可能是 Qwen2.5 视觉处理器中长期存在的 Bug（参考 #28230），并在 Qwen3 VL 235B 模型上复现了类似 OOM，错误回溯指向多模态嵌入计算函数 _merge_multimodal_embeddings。
    • 争议焦点：问题的根本原因尚未确定，可能涉及多模态处理流程中的内存管理缺陷，或特定模型架构（Qwen VL）与 vLLM 多模态管道的兼容性问题。
    • 当前状态：问题仍在开放调查中，维护者已介入，指向一个可能相关的历史 Issue。
  2. Issue #35190 ([Feature]: Support for multiple embedding types in a single inference call)
    • 核心议题：vLLM 0.15 支持了多向量检索（如 ColBERT），但目前每种向量类型需单独调用 API。用户请求在一次推理调用中返回所有支持的嵌入类型（如稠密、稀疏、colbert向量），以提升 RAG 管道效率。
    • 观点与讨论：
      • 用户 (rgidda)：认为当前设计对需要混合搜索（稠密+稀疏）或 ColBERT 式交互的应用不友好，造成了双倍的计算和网络开销。
      • 维护者 (noooop)：建议或许可以通过插件（io_processor_plugin）来满足此场景。
      • 贡献者 (staugust)：指出插件可以将两次调用融合为一次，但由于 PoolingParams 在 CachedRequestState 中只能设置一个任务，vLLM 仍需索引两次。建议先通过插件支持单次调用多向量检索，再升级 DispatchPooler.forward 以支持多任务。
    • 争议焦点：无显著争议，主要讨论实现路径。是从前端 API 层直接支持，还是通过插件机制逐步演进。
    • 当前状态：开放讨论中，倾向于通过插件方案进行渐进式改进。
  3. Issue #35195 ([CI] Missing or incorrect SpanKind import in tracing code causes AttributeError)（虽评论未显示，但从标题和状态变化可推断）
    • 核心议题：CI 测试中因 OpenTelemetry 的 SpanKind 枚举导入错误导致追踪代码失败。
    • 观点与行动：该 Issue 在创建当天即被关闭。关联的 PR #35211 直接 Revert 了此前移除冗余 OpenTelemetry pip 安装的 PR #35032。这表明在将 OpenTelemetry 依赖捆绑进 vLLM 主包后，CI 环境中某些测试仍依赖于旧的显式安装方式。
    • 争议焦点：无，属于明确的回归问题，采取快速回滚修复。
    • 当前状态：已通过回滚 PR 合并得到解决。

🔥 热门话题与趋势分析

  1. 性能优化与剖析：
    • Issue #35254 和 #35226 分别从宏观版本升级（观测到 4 倍性能提升）和微观模型层面（DeepSeek 3.2 多流索引器）提出性能分析与优化建议。
    • PR #35229 实现了针对 Blackwell (SM100) 的融合内核，体现了对最新硬件特性的持续跟进。
  2. 编译与内核稳定性：
    • Issue #35238 和 PR #35256 揭示了 torch.compile 与自定义算子（CustomOp）交互时的 dtype 传播问题，导致模型崩溃。这反映了在追求编译优化性能时，对算子实现健壮性的更高要求。
    • PR #35161 修复了 MoE 对齐内核中 expert_ids 的填充值，这是确保底层计算正确性的重要修复。
  3. 多模态与视觉模型挑战：
    • Issue #35191 和历史上 #28230 反映了以 Qwen 系列为代表的大型视觉语言模型在 vLLM 中面临高并发、长上下文内存管理的严峻挑战。
    • Issue #35169 表明 ROCm 平台上运行多模态模型也可能遇到底层内存访问问题。
  4. 推理正确性与解析器：
    • Issue #35221 和关联的 PR #35258、#35230 均围绕 Qwen3ReasoningParser 在推理输出被截断时的错误解析行为进行修复，强调了对推理（Thinking）功能边界条件的精确处理。

🛠️ 重点技术变更

  1. PR #35156 ([BUGFIX][Qwen3.5] Hardcode mlp.gate as not quantizable)：快速响应并修复了 Qwen3.5-397B-A17B-NVFP4 等 NVFP4 量化模型加载失败的问题。通过硬编码 mlp.gate 层为不可量化，绕过了 checkpoint 中缺失相应量化排除标记的缺陷，确保了对新量化格式的即時支持。

  2. PR #35161 ([Bugfix] Fix expert_ids padding values in moe_align_block_size kernel)：修复了 MoE 对齐内核中 expert_ids 填充值应为 -1 却错误设为 0 的问题。虽然因早期退出逻辑当前可能不影响精度，但此修复消除了下游内核对无效 ID 的误判风险，提升了代码的健壮性和未来兼容性。

  3. PR #35229 ([Perf] Fused silu_mul_fp8_quant_packed kernel for SM100 DeepGEMM MoE)：响应 Issue #35217 的需求，为 SM100 (Blackwell) 架构在 DeepGEMM MoE 中实现了 silu_mul_fp8_quant_packed 融合内核，将原本分离的激活与量化操作合并，旨在提升 FP8 MoE 的计算效率。

  4. PR #34055 ([Refactor] [1/N] Reorganize kernel abstraction directory)：完成了内核抽象层的目录结构重构，将 kernels 包从 quantization 目录下移至 model_executor 根目录。这是清理代码结构、使非量化相关的线性内核不再依赖量化目录的重要架构调整。

  5. PR #33726 ([Model][Spec Decode] Nemotron-H MTP and Mamba Speculative Decoding Support)：新增了对 Nemotron-H 模型家族 MTP 推测解码的支持，并统一扩展了 Mamba 类注意力后端对推测解码的兼容性。这使得更多线性注意力模型能够受益于推测解码技术。

📈 开发活跃度观察

💡 值得关注的问题

  1. 多模态大模型的内存泄漏风险：Issue #35191 揭示的 Qwen3.5 VL 在高并发下的内存无限增长问题，可能影响所有类似架构的视觉语言模型在生产环境中的稳定性，需要优先调查。
  2. 编译优化与算子兼容性：Issue #35238 暴露的 torch.compile 与自定义算子间的 dtype 不匹配问题，是影响编译模式稳定性的潜在瓶颈，需要系统性审视所有自定义算子的“原生”实现路径。
  3. 推测解码的精度测试稳定性：Issue #35168 和 #35167 显示，由于模型本身生成的非确定性，基于输出文本完全匹配的推测解码精度测试存在固有波动性，可能需要调整测试方法论（如引入确定性提示或放松匹配标准）。
  4. 架构演进：Issue #35213 提出的拆分 EngineClient 协议，为支持解耦的前端-后端（如 vllm online）奠定基础，是一个重要的架构设计方向，值得关注其后续进展。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR