View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-02-08 11:37 (UTC+8) ~ 2026-02-09 11:37 (UTC+8) 数据统计: 新 Issue 8 | 关闭 Issue 25 | 新 PR 29 | 合并 PR 10 | 关闭未合并 PR 12


📊 每日开发状态摘要

在2026年2月8日至9日期间,vLLM项目展现出高度的开发与维护活跃度,共处理了25个遗留Issue并新增了29个PR。开发重点集中在三个方面:一是对前沿技术栈(Python 3.14、PyTorch 2.10)的兼容性准备;二是针对新模型架构(如Qwen3.5、GLM-4.7-Flash)的支持与适配;三是持续的性能优化和问题修复,特别是在多模态、推测解码和AMD生态支持领域。

🎯 AMD/ROCm 生态相关动态

本周期内AMD生态相关活动较为活跃,主要体现在核心性能优化、bug修复和CI资源管理上。

  1. 性能优化:为新一代架构准备
    • PR #34100 (Open): 由AMD员工 (amd-hhashemi) 提交。该PR将wvSplitKQ内核的计算指令从之前的版本转换为16x16 MFMA(Matrix Fused Multiply-Add),旨在为未来的mi4xx架构(推测为MI400系列)做准备。同时,这一改动也降低了寄存器压力,提升了现有wvSplitKQ内核在MI300等架构上的性能。
  2. Bug修复:解决 torch.compile 兼容性问题
    • PR #34108 (Open): 修复了PR #33941引入的一个关键bug。该bug导致在ROCm平台上使用torch.compile时,由于amdsmi的FFI调用无法被Dynamo正确追踪,模型前向传播会崩溃。解决方案是将GCN架构检测逻辑提前到模块导入时执行,将结果存储为常量,从而绕过了Dynamo的追踪限制,确保了编译功能的正常运行。
  3. 功能优化:移除MoE内核冗余逻辑
    • PR #34086 (Open): 移除了FusedMoE内核中的分块(chunking)机制。由于chunked-prefill特性现在能保证单次前向传播的令牌数不会超过~65K,内核级别的分块循环已成为不必要的开销。此优化简化了代码,移除了约300行复杂逻辑。该PR虽然不专属于AMD,但其rocm标签表明它同样适用于ROCm平台,是通用性能提升的一部分。
  4. CI/资源管理
    • PR #34059 (Merged): 调整了AMD CI的资源配置,减少了“Benchmarks”和“Benchmarks CLI Test”两个测试组的GPU用量,以释放更多资源供其他测试任务使用,反映了对AMD CI管道效率的持续管理。
  5. 生态系统同步:升级至PyTorch 2.10
    • PR #30525 (Merged): 这是一个全局性升级,但对于AMD生态至关重要。它将项目依赖的PyTorch版本升级至2.10.0(包含ROCm版本),是vLLM支持最新AMD硬件和软件栈的基础。

💬 高热度讨论分析

  1. Issue #29595: Qwen3-VL在vLLM v0.11.1+上的Gounding精度下降(已关闭,30条评论)
    • 核心议题: 用户报告Qwen3-VL模型在vLLM v0.11.1及以后版本中,物体检测(grounding)能力严重下降,特别是在Hopper架构(H20/H100)GPU上,而A100上正常。
    • 观点与争议:
      • 用户方: 提供了详细的复现步骤和对比截图,指出性能下降和精度问题并存,怀疑与Flash Attention后端在Hopper上的特定实现有关。
      • 维护者方: 迅速响应,首先引导用户确认注意力后端,并推测问题可能与PyTorch 2.9在Hopper设备上的内部变化有关。最终,通过合并PR #30525(升级至PyTorch 2.10) 解决了此问题,表明根本原因可能是PyTorch 2.9与Hopper架构的兼容性问题。
    • 当前状态: 问题已随PyTorch 2.10升级而关闭,强调了vLLM对上游PyTorch版本依赖的敏感性。
  2. Issue #22308: GPT-OSS模型自定义工具调用支持(已关闭,19条评论)
    • 核心议题: 用户询问如何为GPT-OSS模型配置--tool-call-parser以支持自定义工具调用。
    • 讨论过程:
      • 初始回复错误地指向了reasoning-parser
      • 随后维护者澄清,Harmony格式的工具调用支持已通过--tool-call-parser openai实现,并已在文档中更新。
      • 另一用户提出在流式模式下(stream=True)使用openai解析器效果不佳,工具调用未被正确解析。
      • 核心争议点: 流式与非流式请求下工具调用的处理路径和提示格式存在差异,导致模型输出不一致。
    • 最终结论: 维护者确认流式工具调用存在bug(已被PR #24768修复),原因是系统提示中未正确激活commentary通道。此讨论揭示了工具调用实现中流式/非流式路径一致性的重要性。
  3. Issue #34096: 支持vLLM与Python 3.14(Open,3条评论)
    • 核心议题: 发起者建议vLLM应开始支持Python 3.14,因为PyTorch已提供官方支持。
    • 观点与进展:
      • 发起者: 详细测试了依赖兼容性,指出ray[cgraph]是主要障碍,并提供了使其变为可选依赖的解决方案和成功从源码安装的补丁。
      • 维护者: 立即表示接手此任务 (I will take this :))。
      • PyTorch团队成员: 补充说明torch.compile已在PyTorch 2.10中支持Python 3.14。
    • 当前状态: 正在进行中。这体现了vLLM社区对保持与最新Python生态系统兼容的前瞻性规划。

🔥 热门话题与趋势分析

  1. 前沿环境适配: Python 3.14支持和PyTorch 2.10升级是本期重点,反映出项目紧跟底层技术栈发展的步伐。
  2. 模型支持攻坚战: 多个Issue反映了新模型架构快速迭代带来的挑战:
    • GLM-4.7-Flash 因使用glm4_moe_lite架构(仅存在于transformers main分支)而无法加载。
    • Unsloth微调的Ministral-3模型缺少vLLM所需的配置文件(如params.json),导致部署困难。
    • 新增PR开始为Qwen3.5模型系列提供官方支持。
  3. 工具调用与流式处理的复杂性: Issue #22308和PR #34101(修复Hermes工具调用流式截断问题)均表明,在流式输出、停止序列、复杂解析逻辑交织的场景下,工具调用功能的健壮性面临持续挑战。
  4. 多模态与内存优化: 已合并的PR #32493引入了 enable_mm_embeds 标志,允许用户在禁用视觉编码器(节省内存)的同时,仍能输入预计算的图像嵌入,为多模态服务的部署提供了更灵活的配置选项。
  5. 安装与依赖问题: Issue #34090中用户因libmpi_cxx.so.40缺失导致安装失败,这可能是由特定PyTorch wheel包引入的间接依赖,提示了复杂依赖环境下的用户支持问题。

🛠️ 重点技术变更

  1. Python 3.14支持前瞻(Issue #34096): 尽管处于早期阶段,但社区已开始系统性评估和解决依赖问题,这是确保vLLM未来兼容性的关键一步。
  2. Qwen3.5模型支持(PR #34110): 提前为即将发布的Qwen3.5密集版和MoE版模型添加支持框架,体现了与头部模型厂商的紧密合作。
  3. PyTorch 2.10正式升级(PR #30525): 一个历时近两个月的大型PR终于合并。此升级不仅解决了Hopper架构上的性能/精度问题,也为利用PyTorch 2.10的新特性(如对Python 3.14的编译支持)奠定了基础。
  4. 多模态“文本only”模式增强(PR #32493): 通过 --limit-mm-per-prompt '{"image": 0}' --enable-mm-embeds 组合,实现了在保留嵌入输入功能的前提下,节省编码器内存开销的“轻量级”多模态服务模式,提升了部署灵活性。
  5. AMD架构优化(PR #34100): 将内核指令集向16x16 MFMA迁移,是针对AMD下一代GPU架构的底层优化,旨在持续提升其在AI计算中的竞争力。

📈 开发活跃度观察

💡 值得关注的问题

  1. Python 3.14依赖地狱(Issue #34096): ray[cgraph] 等关键依赖尚未提供Python 3.14的wheel包,这将成为vLLM支持新版Python的最大障碍。社区可能需要推动上游依赖或制定过渡方案。
  2. 模型架构的快速演进: GLM-4.7-Flash等模型依赖transformers库的main分支,与vLLM依赖稳定版PyPy包的策略存在冲突。如何平衡对新模型的快速支持与依赖稳定性,是一个持续存在的挑战。
  3. AMD生态整合的深水区: PR #34108暴露了AMD专用库(amdsmi)与PyTorch动态图编译(torch.compile)的兼容性问题。随着编译技术普及,此类底层集成问题可能会更多地浮现。
  4. 工具调用的流式处理一致性(Issue #22308 & PR #34101): 流式与非流式API在工具调用解析上的行为差异容易导致开发者困惑。确保两种模式下解析逻辑的完全一致,对提供稳定的开发者体验至关重要。

📋 附录:详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR