View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2025-12-22 10:50 (UTC+8) ~ 2025-12-23 10:50 (UTC+8) 数据统计: 新 Issue 17 | 关闭 Issue 9 | 新 PR 78 | 合并 PR 29 | 关闭未合并 PR 21

📊 每日开发状态摘要

在过去24小时内，vLLM 社区保持高度活跃，新增了17个 Issue 和78个 PR，同时合并了29个 PR。开发重点集中在三个方面：1) AMD 生态适配，特别是针对新架构（如 Strix Halo）的 FP8 支持和 ROCm 构建修复；2) 性能优化与缺陷修复，涉及注意力机制、推测解码、编译缓存等多个核心模块；3) 对新硬件（如 NVIDIA Blackwell）和量化格式（如 ModelOpt FP8）的扩展支持。整体来看，项目正处在一个快速迭代、积极解决平台兼容性与性能瓶颈的阶段。

🎯 AMD/ROCm 生态相关动态

本周期 AMD 生态相关的活动非常活跃，主要体现在构建修复、新架构（Strix Halo）支持以及 AITER 运行时优化上。

Issues:

PRs (主要来自 c0de128，专注于 Strix Halo 支持):

  1. FP8 支持扩展 (#31184): 在 supports_fp8() 函数中添加 gfx11 前缀检查，旨在为 RDNA 3/3.5 架构（包括 Strix Halo）启用 FP8 量化。需要验证：审阅者要求提供 gfx11 硬件上的 lm_eval 测试结果以确认功能有效性，贡献者表示无相关硬件访问权限。
  2. AITER 设备参数统一 (#31178, #31176, #31149): 一系列 PR 旨在将硬编码的 device=”cuda” 替换为从输入张量获取的设备，以提高 ROCm 在多 GPU 和特定架构上的兼容性。同样，需要实际硬件测试验证。
  3. 代码质量与 Bug 修复 (#31177, #31121, #31119, #31118): 涉及异常处理细化、修复 Python 列表别名导致的 MoE 专家分配错误、张量切片赋值模式统一、未初始化变量修复等。这些是针对 ROCm 代码路径的基础性加固。
  4. CI/测试修复 (#31192, #31159): #31192 因 ROCm 使用 spawn 而非 fork 的进程创建方式，跳过了依赖 fork 的 V1 引擎测试。#31159 回退了 Triton 版本以修复 GPT-OSS 在 gfx950 上的导入错误。

总结：AMD 生态的工作聚焦于扩大硬件支持范围（gfx11）和夯实代码基础（设备兼容性、内存/逻辑错误）。一个突出挑战是缺乏易于访问的 gfx11 测试环境，导致部分 PR 无法提供端到端性能验证，依赖 CI 和核心维护者进行最终确认。

💬 高热度讨论分析

  1. PR #31193: [Feature] Add iteration level logging and enhance nvtx marker
    • 核心议题：是否默认启用详细的迭代级别日志（请求数、令牌数、耗时）和增强的 NVTX 标记。
    • 不同观点：
      • 反对默认开启 (wangshangsam, nvpohanh, robertgshaw2-redhat)：认为该功能主要服务于 GPU 性能分析与调优的专家用户，对绝大多数普通用户而言过于冗长，且可能带来不必要的 CPU 开销和日志干扰。
      • 维护者行动 (maxyanghu)：基于反馈，迅速将功能改为默认关闭，通过环境变量 VLLM_LOG_ITERATION_DETAILS 控制。
    • 结论：功能被保留，但遵循了“安静默认”的原则，体现了对用户体验和性能开销的考量。
  2. Issue #31128: [Feature]: Add support of Blackwell SM121(DGX Spark)
    • 核心议题：请求为 NVIDIA DGX Spark (Blackwell, ARM64, CUDA 13) 提供原生支持。
    • 讨论内容：
      • 问题：vLLM 0.13.0 依赖 PyTorch 2.9.0，但其官方轮子不提供 ARM64 + CUDA 版本。NGC PyTorch 2.10 镜像是目前唯一选择。
      • 社区提供的解决方案：多位用户贡献了从源码编译、使用 CUDA 13 专用轮子（从 v0.13.0 开始提供）和特定 Docker 镜像的详细步骤。
    • 结论：讨论显示 vLLM 已通过夜间构建和特定版本轮子提供了对 Blackwell 和 CUDA 13 的支持，但官方文档和版本兼容性说明可能需要更新以更好地引导用户。
  3. Issue #31148 & PR #31198: Jais2 model unsupported rotary_dim kwarg
    • 核心议题：Jais2 模型在初始化时因 get_rope() 接收到不支持的 rotary_dim 参数而失败。
    • 讨论与解决：Issue 中迅速关联了修复 PR (#31198)。该 PR 删除了导致问题的错误 LoRA 逻辑。这是一个典型的“报告-修复”快速响应案例。
  4. Issue #31155: [Bug] [ROCm] [Critical]: ROCm build broken
    • 核心议题：ROCm 构建因未使用变量错误而中断，属高优先级阻塞性问题。
    • 讨论与解决：问题被迅速标记为 critical，并在几小时内通过 #31156 修复和合并。体现了对关键平台构建问题的快速响应能力。

🔥 热门话题与趋势分析

🛠️ 重点技术变更

  1. PR #31197 (已合并): Revert [SM100] Enable fp8 compute for prefill MLA：紧急回退了之前合并的 #30746。原因是在依赖的 FlashInfer 更新 (#30993) 未就绪前，该更改可能导致问题（如破坏 Blackwell CI）。影响：暂时撤销了 FP8 在 MLA 预填充阶段的加速支持，等待底层库稳定。
  2. PR #31167 (已合并): [Perf] Remove blocking copy in GDN Attention：移除了 Qwen3-Next 模型中 GDN 注意力层的一个阻塞性拷贝操作。影响：为异步调度和 MTP 的完全非阻塞化扫清障碍，在小批量场景下测得约 1% 的性能提升。
  3. PR #31192 (已合并): [AMD][CI] fix v1/engine test_preprocess_error_handling：因 ROCm 平台使用 spawn 多进程方法，而测试依赖 fork，故跳过该测试。影响：保证了 AMD CI 的通过率，但也凸显了跨平台多进程模型带来的测试复杂性。
  4. PR #30957 (已合并): Support NVIDIA ModelOpt HF FP8 variants：新增对两种 ModelOpt 私有 FP8 格式 (FP8_PER_CHANNEL_PER_TOKEN, FP8_PB_WO) 的加载支持。影响：扩展了 vLLM 对 NVIDIA 优化后模型的兼容性，满足了特定用户工作流的需求。
  5. Issue #31200: [Bug]: class Request and block_hasher has circular reference：指出多模态特征缓存中 Request 和 block_hasher 之间存在循环引用，可能引起内存泄漏。影响：提供了一个使用 weakref 的修复方案，此问题对长期运行的多模态服务至关重要。

📈 开发活跃度观察

💡 值得关注的问题

  1. AMD Strix Halo (gfx11) 的 FP8 支持验证：PR #31184 等已添加代码支持，但缺乏硬件实测验证。这是扩大 vLLM 在 AMD 消费级显卡上应用的关键一步，需要社区或 AMD 内部协调完成最终验证。
  2. 多模态服务中的内存泄漏风险：Issue #31200 揭示的循环引用问题可能影响服务的长期稳定性，其修复方案值得尽快评估与合并。
  3. Qwen3-Next MTP 稳定性：Issue #31186 报告了 Qwen3-Next 在多令牌预测（MTP）下的崩溃问题。Qwen3-Next 是新近的重要模型系列，其性能与稳定性备受关注。
  4. 编译缓存的并发安全性：Issue #31199 反映的 TorchInductor 编译缓存在多进程并发加载时的损坏问题，可能影响高并发部署场景的稳定性。
  5. 复杂分布式配置的协同逻辑：Issue #31145 和 #31154 分别暴露了多连接器（Multi-Connector）和 N-gram 推测解码在 TP 场景下的边缘 case，提示在复杂分布式组件组合时，需要更全面的集成测试。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR