View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

vLLM 开发动态报告 - 2026-04-01

时间窗口: 2026-04-01 11:38 (UTC+8) ~ 2026-04-02 11:38 (UTC+8) 数据统计: 新 Issue 32 | 关闭 Issue 17 | 新 PR 68 | 合并 PR 30 | 关闭未合并 PR 10

📊 每日开发状态摘要

本期（4月1日-2日）vLLM项目开发活跃度保持高位，新增32个Issue和68个PR，合并了30个PR。开发焦点主要集中在 AMD/ROCm平台体验优化、Transformers v5兼容性迁移 以及 vLLM IR（中间表示）架构的推进 上。同时，围绕分散式服务、量化性能和工具调用准确性的问题反馈与修复是社区讨论的核心。

🎯 AMD/ROCm 生态相关动态

本期AMD生态相关活动非常活跃，主要围绕功能补齐、性能优化和问题修复展开。

  1. 新Issue：强调ROCm与CUDA/SGLang的体验对等
    • #38692、#38693、#38687：用户 functionstackx 连续提交三个Issue，核心诉求是提升ROCm在分散式服务和CI测试方面的体验，以达到与CUDA以及ROCm版SGLang同等的水平。具体问题包括：vLLM router不支持MoRI KV缓存连接器、缺少ROCm CI测试、以及Docker镜像未内置Pollara AINIC与Thor-2网卡驱动。AMD员工 chunfangamd 已介入并@相关同事。
    • 状态与影响：这些Issue均处于开放状态，凸显了用户对AMD生产环境可用性的迫切需求。解决这些问题对提升AMD GPU集群的部署体验至关重要。
  2. 活跃PR：内核优化、兼容性修复与量化支持
    • #38762 (rbrugaro-amd)：修复ROCm上DeepSeek MoE模型的allreduce + rmsnorm融合模式匹配问题，通过预处理消除无操作（no-op）的view节点，使模式匹配生效。
    • #38757 (mikaylagawarecki)：继续将共享的CUDA/ROCm内核迁移到libtorch稳定ABI的工作，提升跨版本兼容性。
    • #38750 (gshtras)：修复因缺失符号导致的ROCm运行时导入失败问题。
    • #38774 (BowenBao)：重构Quark MoE的MXFP4量化路径，使其通过oracle和kernel后端执行，并将后端名称统一为“AITER”。
    • #38719 (xaguilar-amd)：修复了在AMD平台上，当使用Aiter MLA FP8持久化内核与CUDA图时，KV缓存损坏和元数据错误导致的Kim-i 2.5模型输出异常问题。
  3. 已关闭Issue：历史问题得到解决
    • #35637：关于MI355运行Minimax M2.1 MXFP4模型时AITER MoE TP4错误的问题，随着PR #34285的合并而被关闭。
    • #35925：关于Qwen3.5-35B在启用AITER时产生错误输出（NaN导致）的问题已关闭。

小结：AMD团队正积极响应用户对“体验对等”的诉求，工作重点从基础功能支持转向性能优化、稳定性和生产环境完善。围绕AITER内核、量化支持和编译兼容性的修复是本期重点。

💬 高热度讨论分析

  1. RFC #38760：Per-iteration forward pass metrics
    • 核心议题：提议在vLLM引擎层添加每次迭代的前向传播详细指标（如Prefill/Decode请求数、KV缓存深度、实际GPU耗时等），以解决当前Prometheus异步拉取模式数据丢失、不同步、无历史的问题。
    • 各方观点：
      • 提议方 (tedzhouhk)：认为这对于编排系统（自动扩缩容、路由器、分散式服务规划器）构建精确的成本模型至关重要，现有指标无法满足需求。
      • 潜在考量（隐含在RFC细节中）：需要设计低开销的指标收集与导出机制，避免影响引擎性能，并考虑API设计（如回调函数、轻量级RPC）。
    • 当前状态：RFC开放征求意见，是面向生态系统工具链的重要基础设施提案。
  2. Issue #38257（已关闭）：Qwen3-VL-235B多图长对话OOM
    • 核心议题：超大视觉语言模型在多图像、长文本多轮对话中发生OOM。
    • 讨论过程：
      • 用户 (cjackal)：提供了详细复现步骤。
      • 社区 (DarkLight1337)：建议排除CUDA图问题。
      • 维护者 (ywang96)：怀疑masked_scatter_操作存在内存拷贝问题。
      • 解决方案：指向PR #34246，该PR将masked_scatter_替换为直接索引操作，从根本上解决了内存问题。用户确认该PR有效。
    • 结论：问题根因在于PyTorch某个版本前masked_scatter_在特定条件下的实现问题，通过PR #34246的简化方案得以修复。体现了对大规模多模态模型内存优化的持续改进。

🔥 热门话题与趋势分析

  1. Transformers v5 兼容性攻坚：出现了一系列标记为“Transformers v5”的子任务Issue（如 #38734, #38736, #38740, #38735），旨在修复因HuggingFace Transformers库升级至v5版本导致的各类模型初始化失败问题。社区成员踊跃认领，表明项目正处在紧跟上游依赖的关键升级期。
  2. vLLM IR 架构深化：多个Issue/PR（#38733, #38744, #38745, #38756）围绕将激活函数、量化、RoPE等操作迁移到新的vLLM IR（中间表示）体系。讨论涉及内核实现、编译优化和OOT（Out-of-Tree）平台迁移指南，标志着项目底层抽象和硬件无关化进入新阶段。
  3. 分散式服务与异构推理：Issue #38710报告了XPU+CPU异构分散式服务的精度问题，Issue #38692则关注ROCm分散式服务中KV传输的支持。这反映了业界对跨设备、跨节点高效部署复杂模型工作流的探索和挑战。
  4. 量化性能与精度回归：Issue #38720（FP8速度显著慢于BF16）和 #38697（W8A8解码慢于FP16）报告了量化后性能不升反降的情况。同时，PR #38728提出在Hopper架构上将NVFP4权重转换为FP8进行计算以提升性能。这表明量化技术的实际收益与硬件、内核实现紧密相关，仍是优化重点。

🛠️ 重点技术变更

  1. PR #38760（RFC）：引擎级迭代指标提案：这是一个可能改变监控与调度生态的提案。它旨在提供高保真、时间同步的批处理成本数据，对于构建智能的负载均衡和资源调度系统具有基础性价值。
  2. PR #38684（已合并）：DeepSeek-V3.2 Indexer融合优化：将Indexer中的WK和Weights_Proj投影操作融合，相比原有的重叠优化获得了更显著的解码速度提升（在特定测试中提升约3%），是针对特定模型架构的低开销高效优化范例。
  3. PR #34246（已合并）：简化多模态掩码处理：利用PyTorch 2.9.0后的优化，将容易引起内存问题的masked_scatter_操作替换为直接索引赋值，成功解决了Qwen3-VL等大模型在多图场景下的OOM问题，是一次通过依赖升级和代码简化解决深层缺陷的优秀实践。
  4. PR #37831（已合并）与 #38751（回滚）：展示了代码审查和CI的严格性。PR #37831修复了Qwen3Coder工具解析器对复杂JSON Schema（anyOf/oneOf）的处理，但因合并冲突后引入了测试失败，迅速被#38751回滚。这体现了主分支稳定性优先的原则。

📈 开发活跃度观察

💡 值得关注的问题

  1. ROCm体验对等：Issue #38692, #38693, #38687 提出的问题直指AMD平台在生产部署中的关键短板，其解决进度将显著影响vLLM在AMD生态中的采纳度。
  2. Transformers v5迁移：一系列相关的good first issue是当前项目兼容性升级的重点，其完成情况关系到未来能否平滑使用最新Transformer模型。
  3. vLLM IR的推进：相关RFC和任务（#38744, #38733等）的讨论与实施，将决定vLLM未来内核抽象、跨平台移植和编译优化能力的天花板。
  4. Per-iteration Metrics RFC：#38760 的讨论结果将直接影响外部调度器、监控系统的能力边界，建议相关生态开发者积极参与。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR