View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

vLLM 开发动态报告 - 2025-12-28

时间窗口: 2025-12-28 11:01 (UTC+8) ~ 2025-12-29 11:01 (UTC+8) 数据统计: 新 Issue 5 | 关闭 Issue 7 | 新 PR 21 | 合并 PR 8 | 关闭未合并 PR 15

📊 每日开发状态摘要

在本次观察周期内，vLLM 项目保持活跃的开发节奏，新增了21个PR和5个Issue，合并了8个PR。开发焦点集中在多模态模型支持、推理性能优化（特别是MoE内核调优）以及前端API功能完善上。同时，AMD/ROCm生态的兼容性与测试稳定性是后台持续投入的重要方向。

🎯 AMD/ROCm 生态相关动态

本周期内，AMD/ROCm 生态相关活动活跃，主要体现在 CI/CD 测试修复、依赖项迁移和核心功能支持上。

  1. ROCm CI 测试修复与依赖更新 (PR #31327, #31323, #31441)
    • 技术细节:
      • PR #31327: 将 xgrammar 依赖从自定义分支迁移至上游 PyPI 发布版（0.1.29）。此版本包含对 AMD GPU 上 Triton 内核 warp 大小（32 vs NVIDIA 的 64）的关键修复，解决了结构化输出在 MI300 上的资源不足错误。
      • PR #31323: 为支持音频转录测试，添加了从源码构建 ROCm 兼容版 TorchCodec 的脚本和 CI 步骤，解决了该库无预编译 ROCm 轮子的问题。
      • PR #31441: 为通过 Isaac 多模态模型测试，在 ROCm 测试依赖中增加了 perceptron 库。
    • 影响分析: 这些改动共同提升了 vLLM 在 AMD 平台上的测试覆盖率和稳定性，减少了对特定分支的依赖，向使用标准上游包迈进，有利于长期维护。
  2. ROCm 平台特定测试跳过与基础设施修复 (PR #31462, #31460)
    • 技术细节:
      • PR #31462: 在 ROCm 平台上跳过依赖 DeepGemm（CUDA 特定功能）的测试 test_silu_mul_fp8_quant_deep_gemm。
      • PR #31460: 为修复 ROCm 平台上的 “NixlConnector PD accuracy tests”，在 Dockerfile 中将 NCCL 替换为 ROCm 的 RCCL/RIXL，并添加 UCX 支持。
    • 影响分析: 明确了 ROCm 与 CUDA 在底层库支持上的差异，确保了 CI 的通过率，并完善了 ROCm 分布式通信的基础设施。
  3. Quark 量化工具相关重构 (PR #31461)
    • 技术细节: 这是 MoE 层重构系列的第11部分，专门重构了 quark_moe 层。贡献者指出当前缺乏针对 Quark 方法的测试，并寻求指导。
    • 影响分析: 这表明 AMD 的 Quark 量化工具集成在 vLLM 代码库中正在进行现代化重构，但测试覆盖可能是一个待完善的领域。
  4. PyNCCL 回退机制增强 (PR #31459)
    • 技术细节: 修复了 CudaCommunicator 中 all_gatherv 方法在 PyNCCL 不可用（如在 AMD GPU 上）时缺少 torch.distributed 回退路径的问题。此前这导致在 AMD MI350x 上进行多维度并行（TP/DP/EP）时出现断言错误。
    • 影响分析: 这是一个对 AMD 平台非常重要的修复，它解决了在使用复杂并行策略时的一个关键阻塞点，提升了 vLLM 在 AMD 硬件上的部署能力和健壮性。

💬 高热度讨论分析

  1. Issue #30624: Qwen3VL 在异步调度下的 GPU 断言错误
    • 核心议题: 多位用户报告在运行 Qwen3-VL 系列模型（8B至235B）并启用 --async-scheduling 时，出现 masked_scatter_size_check 或 vectorized_gather_kernel 的 CUDA 断言失败，问题表现不稳定。
    • 观点与测试:
      • 用户反馈: bash99 测试发现禁用 --async-scheduling 后问题消失，指向异步调度是触发条件。
      • 维护者推测: DarkLight1337 联想到一个已知的多模态 CPU 张量竞争条件问题，并建议尝试修复该问题的 PR #31373。
      • 验证结果: bash99 随后确认 PR #31373 解决了启用异步调度时的崩溃问题。
    • 最终结论: 问题根源于之前一个针对异步多模态竞争条件的修复被意外回退。PR #31373 重新应用了该修复，并在此周期内被合并，从而解决了此问题。这展示了社区协作定位和修复复杂、间歇性 bug 的过程。
  2. Issue #18619: Qwen2.5 从 v0.8.4 到 v0.8.5 的性能下降 (已关闭)
    • 核心议题: 用户报告 Qwen2.5 模型在 vLLM 版本升级后出现显著的吞吐量下降（从 ~60 请求/秒降至 ~57）。
    • 争议与调查:
      • 原始报告: 提供了详细的 Nsight Systems 性能分析截图，显示内核执行时间分布发生变化。
      • 社区验证: 另一位贡献者 Zerohertz 尝试复现，但测得的吞吐量数量级（~3 请求/秒）与原始报告不符，引发了对测试配置差异的讨论。
      • 讨论焦点: 双方对性能数据的基准存在较大分歧，未能就“性能回归”的具体表现达成一致。讨论涉及调度配置、评测方法等细节。
    • 当前状态: 由于问题年代较久且未能形成一致的、可复现的结论，该 Issue 因停滞（stale）而被关闭。它凸显了性能问题排查中对标准化、可复现的评测环境的依赖。

🔥 热门话题与趋势分析

  1. 多模态与视觉语言模型支持: 新增多个相关 PR（如支持 t5gemma-2, Cogagent，修复 Jina reranker 多模态输入），同时已关闭的多个 CI Failure Issue 也集中于修复多模态模型测试。这表明对多样化 VLM 的集成和稳定性保证是当前重点。
  2. 推理性能深度优化: 趋势体现在针对特定硬件（如 NVIDIA B200）和模型（如 Qwen3-MoE, GLM-4.5/4.6）的 Triton MoE 内核调优配置被频繁提交和合并（PR #31448, #31407）。这反映了社区对极致推理性能的追求。
  3. 前端 API 与用户体验完善: 围绕工具调用（tool call） 的流式输出问题，同期出现了两个修复 PR（#31451, #31457），均旨在解决流式响应中丢失工具名称等元数据的问题。此外，也有关于 Docker 镜像拉取限速、本地模型加载失败的 Issue，显示对生产化部署体验的关注。

🛠️ 重点技术变更

  1. PR #31461 ([MoE Refactor][11/N] refactor quark_moe layer): 作为 MoE 层大规模重构的一部分，此 PR 专门处理 AMD Quark 量化相关的 MoE 实现。其重要性在于推动代码库的现代化和统一，但贡献者提出的“缺乏测试”问题也指出了未来需要加强验证的方向。
  2. PR #31373 ([BugFix] Re-fix async multimodal cpu tensor race condition): 此修复解决了启用异步调度时，多模态模型因 CPU 张量复用不同步而导致的间歇性 GPU 断言错误（如 Issue #30624）。对提升多模态模型在高压、异步推理场景下的稳定性至关重要。
  3. Issue #31467 ([RFC]: A Triton operator dispatch mechanism through modified CustomOp): 这是一个重要的架构设计提议。作者指出当前 Triton 内核调用方式分散（通过Attention后端、CustomOp、直接调用），且不同硬件后端（如 ROCm 和 CUDA）需要不同实现，但缺乏统一的调度机制。提案旨在创建一个抽象的 TritonOp 层来实现硬件后端的动态分发。这可能为 vLLM 未来更好地支持异构计算平台（包括 AMD NPU 等）奠定基础。

📈 开发活跃度观察

💡 值得关注的问题

  1. Issue #31467 (Triton算子分发机制RFC): 这是一个可能影响深远的架构讨论。如果采纳，将改变 vLLM 中 Triton 内核的组织和调用方式，旨在提升对多硬件后端的支持能力。社区对其设计方案的反馈和最终决策值得跟进。
  2. Issue #31454 (支持Qwen2.5 ModelOpt/GradNAS剪枝检查点): 该需求涉及动态读取模型权重来推断每层不同的中间尺寸，以支持高级模型压缩技术产出的检查点。这反映了对前沿模型优化技术生态兼容性的需求，实现后能增强 vLLM 的模型加载灵活性。
  3. PR #31461 中提出的测试缺失问题: 在重构 Quark MoE 层时，贡献者明确指出缺乏相应的单元测试。这暴露了项目中某些特定硬件或工具链相关功能的测试覆盖率可能存在缺口，是保证 AMD Quark 量化功能长期可靠性的潜在风险点。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR