View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-02-27 11:05 (UTC+8) ~ 2026-02-28 11:05 (UTC+8) 数据统计: 新 Issue 26 | 关闭 Issue 21 | 新 PR 81 | 合并 PR 41 | 关闭未合并 PR 21

📊 每日开发状态摘要

在本次观察窗口内，vLLM 社区保持了较高的开发活跃度，新增与关闭的 Issue 和 PR 数量众多。开发焦点主要集中在推理稳定性问题排查（尤其是针对 Qwen 系列模型）、AMD (ROCm) 平台的优化与问题修复，以及新功能与性能优化（如模型运行器 V2、WebSocket 支持、性能剖析工具改进）上。社区在快速迭代新特性的同时，也面临着由硬件多样性（AMD/NVIDIA/ARM）和模型复杂性（MoE、多模态、推测解码）带来的兼容性与稳定性挑战。

🎯 AMD/ROCm 生态相关动态

本周期 AMD 生态相关活动非常活跃，涉及多个关键修复、功能增强和持续集成（CI）改进。

  1. Issue #35569: [ROCm] ROCM_ATTN 后端在 Qwen3-VL-Reranker 上出现系统性数值偏差
    • 描述：在 AMD MI355 (gfx950) 平台上，使用 ROCM_ATTN 注意力后端时，Qwen3-VL-Reranker-2B 模型的评分输出存在约 8.5% 的确定性偏差，而其他 ROCm 后端 (ROCM_AITER_FA, TRITON_ATTN, FLEX_ATTENTION) 则表现正常。在 MI325 (gfx942) 上误差较小。
    • 分析：这表明 ROCM_ATTN 后端在该特定模型和硬件上存在底层数值精度问题，可能源于内核实现差异。需要 AMD 团队（如 @kenroche, @gshtras）进一步调查。
    • 影响：影响 AMD 平台上使用该后端进行重排序任务的准确性。
  2. PR #35560: [WIP][Bugfix][ROCm] 修复 MoE 模型在 TP=1 时的 MXFP4 在线量化
    • 描述：修复了三个阻止标准 HuggingFace MoE 模型（如 Qwen3-30B-A3B）在使用 quantization=”mxfp4″ 和 tensor_parallel_size=1 时加载的关键错误。问题涉及索引错误、未知量化方法以及数据类型不匹配。
    • 分析：此修复对于提升 AMD 平台对主流 MXFP4 量化模型的支持至关重要。它区分了 GPT-OSS 格式和标准 HF 格式的检查点，并正确处理了在线量化流程。
    • 影响：显著改善了 AMD GPU 上运行 MXFP4 量化 MoE 模型的兼容性和用户体验。
  3. PR #35485: [Bugfix][ROCm] 在 RDNA3/RDNA4 (gfx1x) 上禁用完整 CUDA 图捕获
    • 描述：为解决 Triton 注意力内核在 RDNA3/RDNA4 架构上进行 HIP 图捕获时崩溃的问题，该 PR 在检测到 gfx11xx/gfx12xx GPU 时，自动将 cudagraph_mode 从 FULL_AND_PIECEWISE 降级为 PIECEWISE。
    • 分析：这是一个针对特定 AMD GPU 架构已知稳定性问题的规避措施。评论中 @tjtanaa 指出，仅此更改可能不足以完全解决请求发送后的崩溃问题，需要更多测试。
    • 影响：旨在提高在 RDNA3/RDNA4 GPU 上运行 vLLM 的稳定性，但最终效果待验证。
  4. PR #35553 & #35571: [ROCm][CI] 工具使用和视觉评分测试稳定性修复
    • 描述：这两个 PR 针对 ROCm CI 测试的间歇性失败，引入了平台特定的覆盖设置：禁用 VLLM_ROCM_USE_SKINNY_GEMM、禁用前缀缓存、设置 --max-num-seqs 1，以消除原子归约和非确定性批处理方差的影响。
    • 分析：反映了在 AMD 平台上确保测试结果确定性的持续努力。这些调整有助于隔离内核问题，使测试更可靠。
    • 影响：提升 AMD CI 流水线的稳定性和可信度。
  5. 其他相关 PR：
    • PR #35491 (xuebwang-amd): 支持 AMD Quark 量化的 Qwen3.5 模型（MXFP4, PTPC FP8 等），聚焦模型加载和精度。
    • PR #35527: 为 ROCM_ATTN 后端添加对 stablelm 模型头大小 80 的支持，是支持更多模型的前置工作。
    • PR #35533: 修复了 AITER RoPE 操作在编译过程中的一个功能性（functionalization）错误，已合并。

💬 高热度讨论分析

  1. Issue #35477: 如何使用 vllm bench serve 测试编码器-仅 BERT 模型的性能（5条评论）
    • 核心议题：用户尝试对 BAAI/bge-large-zh-v1.5 编码器模型进行性能测试，但基准测试工具卡住。
    • 不同观点：
      • 用户（@duanshengliu）提供了详细的复现步骤，并怀疑是 --served-model-name 参数导致的 bug。
      • 维护者（@noooop）澄清了 bge-reranker-v2-m3 是重排序模型，不支持 /v1/embeddings 端点。
    • 最终结论：用户自行发现并解决了问题，方法是在启动服务和运行基准测试时都不使用 --served-model-name 参数。这确实暗示了该参数在处理某些模型时可能存在逻辑缺陷。该 Issue 已关闭。
  2. Issue #35541: vLLM 在低 num_gpu_blocks_override 设置下无限期挂起（关联 PR #35542）
    • 核心议题：当 GPU KV 缓存块数量被人为设低，而请求所需块数超过总量时，调度器会陷入无限重试循环，导致进程挂起而非抛出错误。
    • 观点与方案：
      • 问题提出者（@kvcache670）：进行了根因分析，指出 V1 调度器在等待队列请求分配失败时，只是跳出循环而未处理该请求，导致其一直阻塞队列头部。
      • 解决方案（同一用户）：在 PR #35542 中提出了修复：在重试后，计算请求所需块数与实际可用块数，如果永远无法满足，则主动中止（abort）该请求，并继续处理后续请求。
    • 争议焦点：无显著争议，这是一个明确的缺陷修复。另一个相关 PR #35570 也提出了类似的修复方案。
    • 当前状态：Issue 开放，修复 PR #35542 已提交待审。
  3. Issue #35507: 使用 OffloadingConnector 时出现断言错误
    • 核心议题：用户在使用 OffloadingConnector 进行 KV 缓存卸载时遇到断言错误 assert len(req.block_hashes) >= num_gpu_blocks。
    • 讨论过程：
      • 维护者（@lengrongfu, @haosdent）建议使用最新版本，并指出 PR #27648 可能已修复。
      • 用户（@liunianxuxie）表示受项目限制只能使用 v0.11.0，在按照 PR #27648 修改代码后出现了新的错误。
    • 当前状态：问题仍处于开放状态，凸显了在旧版本上使用复杂功能（KV卸载）时，向后移植修复的困难。用户可能需要等待官方版本更新或自行深度调试。

🔥 热门话题与趋势分析

  1. 推理稳定性与挂起问题：多个 Issue（#35504, #35502, #35541）报告了在不同配置（TP>1, Qwen 模型，低内存限制）下的推理挂起问题。这表明在高并发、复杂模型和资源受限场景下，调度器和执行引擎的健壮性面临持续考验。
  2. 多模态与编码器模型支持：围绕如何正确测试编码器模型（Issue #35477）、修复多模态模型加载（Issue #35522, PR #35535）和处理音频-视频交错逻辑（PR #35487）的讨论活跃，体现了 vLLM 向超越纯文本生成任务扩展的持续努力。
  3. AMD 平台优化与测试：如前一节所述，本周期有大量针对 AMD 平台的修复和 CI 改进工作，表明社区正致力于缩小其在功能、性能和稳定性上与 NVIDIA 平台的差距。
  4. 性能优化与新功能：
    • 推测解码：涉及 MTP 权重验证（PR #35548）、后缀解码崩溃（Issue #35521）和基准测试工具修复（PR #35471）。
    • 前端与 API：WebSocket 支持被加入 Responses API（PR #35492），并计划为 Realtime 端点添加监控指标（PR #35500）。
    • 内核与编译：继续推进 torch.compile 相关优化（PR #35472, #35475）和 Model Runner V2 相关工作（PR #35564, #35520, #35120）。
  5. 模型支持与加载问题：不断有新的模型被添加（PR #32407），同时也有现有模型在特定配置（如 FP8 量化、TP>1）下的加载和运行问题被报告（Issue #35519, #35496, #35528）。

🛠️ 重点技术变更

  1. PR #35560: [ROCm] 修复 MXFP4 在线量化 for MoE (TP=1)：这是一个对 AMD 平台量化支持至关重要的修复。它解决了从标准 HF 格式加载 MoE 模型并启用 MXFP4 在线量化时的三个连环错误，涉及权重加载器逻辑、量化方法注解和数据类型处理，直接影响 Qwen3、Mixtral 等流行 MoE 模型在 AMD GPU 上的可用性。
  2. PR #35480: 在 do_mamba_copy_block 中使用固定内存进行异步 H2D 传输：此优化针对使用线性注意力（如 Mamba）的模型，修复了由非固定内存传输引起的 aten::to 同步等待问题（可达20ms）。通过使用固定内存，将此类延迟降低至0.13ms，显著提升了包含线性注意力层模型的预处理效率。
  3. PR #34580: 为 Qwen3 VL ViT 注意力启用 FlashInfer cuDNN 后端：此 PR 为 Qwen3 视觉语言模型的视觉编码器引入了 FLASHINFER 注意力后端。通过适配 cuDNN 后端所需的输入格式（如 cu_seqlens），并在必要时进行填充以避免图重编译，在 GB200 上实现了显著的编码器前向传播加速（从 ~7.2ms 降至 ~3.7ms），对提升多模态任务端到端性能有重要意义。
  4. PR #35487: 修复批处理非交错音视频请求的误判：这是一个关键的多模态逻辑修复。原函数通过简单的 token 位置范围重叠来判断音视频是否交错，在批处理多个独立请求时会产生误判，导致后续嵌入层崩溃。修复方案是添加“密度检查”，确保在真正的交错模式下，音视频 token 之间没有间隙。这提升了 Qwen2.5/3-Omni 等模型在批处理场景下的稳定性。

📈 开发活跃度观察

💡 值得关注的问题

  1. Qwen 系列模型的推理稳定性：Issue #35504 和 #35502 报告了 Qwen3.5/Coder-Next 模型在特定版本和配置下出现推理挂起和性能下降的问题，可能涉及 GDN 优化、AllReduce 融合等底层更改。这需要核心开发者重点关注，因为 Qwen 是 vLLM 支持的关键模型家族之一。
  2. ARM64 (Grace) + Blackwell (GB10) 的兼容性问题：Issue #35519 报告了在 ARM64 架构的 Grace CPU 搭配 Blackwell GPU 上，NVFP4 量化的 Qwen3.5 模型因内核包含非法指令而崩溃。这揭示了新硬件组合带来的新兼容性挑战，可能需要对量化内核进行特定架构的适配或提供明确的不支持声明。
  3. 多节点/分布式场景下的复杂问题：Issue #35496 报告了在 TP=8 的大模型部署中，因 FlashInfer GDN 内核 JIT 编译超时导致 Ray RPC 超时和服务崩溃。这提示在大规模分布式部署中，首次运行的编译时间可能成为服务可用性的瓶颈，需要考虑预编译或更智能的等待/超时策略。
  4. ModelOpt W4A8 MXFP4+FP8 量化格式的支持缺口：Issue #35528 指出，目前没有 NVIDIA 的 PTQ 工具（ModelOpt）能产出可直接使用 vLLM 原生 FlashInfer MXFP4 MoE 内核的检查点，造成了功能断层。这需要 vLLM 开发团队与 NVIDIA ModelOpt 团队协作，定义或支持一种统一的量化检查点格式。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR