View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

vLLM 开发动态报告 - 2026-03-25

时间窗口: 2026-03-25 11:43 (UTC+8) ~ 2026-03-26 11:43 (UTC+8) 数据统计: 新 Issue 29 | 关闭 Issue 10 | 新 PR 92 | 合并 PR 44 | 关闭未合并 PR 74

📊 每日开发状态摘要

本周期（2026-03-25至2026-03-26）vLLM项目保持高速开发节奏，新增及关闭大量Issue和PR，社区活跃度极高。核心关注点集中在AMD生态兼容性与性能优化、工具调用（Tool Calling）相关Bug修复以及前沿功能探索（如流式视频输入、新型量化方法）。AMD平台的支持，特别是针对不同架构（gfx1030/RDNA 2， gfx1201/RDNA 4， MI300系列）的性能调优和问题修复是本期焦点。

🎯 AMD/ROCm 生态相关动态

本周期AMD生态相关活动非常活跃，涉及性能诊断、功能启用、Bug修复及测试完善等多个方面。

新增Issue:

  1. #38107: [Bug]: Abnormally bad performance on AMD ROCM gfx1030：用户报告在RDNA 2架构（gfx1030，如W6800, 6900XT）上性能异常低下（个位数token/s）。核心贡献者 Michelle-HCJ 精准指出根因在于 bfloat16 数据类型在RDNA 2硬件上缺乏支持，导致回退至软件模拟，建议改用 float16。该问题被迅速定位并关闭，体现了社区对AMD平台性能问题的深入理解。

新增PR (Open & Merged):

  1. #38086 ([ROCm] Enable VLLM triton FP8 moe for gfx1201)：由 AMD 员工（vllmellm）提交，为 RDNA 4 (gfx12xx) 显卡启用Triton FP8 MoE支持，并针对Qwen3/Qwen3.5 FP8 MoE模型进行了性能调优，解决了此前因检测失败导致的 NotImplementedError。
  2. #38109 ([Bugfix] Fix FP8 MoE support detection on ROCm)：修复了在ROCm（特别是RDNA 4）上检测FP8 MoE支持时，因amdsmi返回哨兵值或旧版GPU识别逻辑不准确导致的失败。统一改用 p.supports_fp8() 进行集中检测。
  3. #38108 (Fix Device Index for ROCm Ray Workers in MoE Benchmark)：修复了在多GPU AMD系统上使用Ray运行MoE自动调优脚本时，因设备序号错误导致的崩溃。
  4. #38181 ([ROCm] Fix cp_mha_gather_cache for strided KV views)：修复了ROCm后端在处理具有跨步KV视图的混合注意力+Mamba模型（如Qwen3.5-397B-A17B-FP8）时，KV缓存收集逻辑错误的问题。
  5. #37833 ([ROCm] Fix MoE kernel test failures on gfx950) (已合并)：修复了在MI355 (gfx950) 上多个MoE内核测试失败的问题，涉及对Triton返回值处理、CUDA/ROCm内核路径区分、FP8量化边界精度容忍度调整等，确保CI稳定性。
  6. #36574 ([ROCm] Utilize persistent MLA kernel from AITER) (已合并)：集成AITER的持久化MLA解码内核，通过在GPU计算单元上常驻内核来减少启动开销，在DeepSeek-R1模型上取得了显著性能提升（最高达2.4倍）。
  7. #36702 ([ROCm] Attention selector reordering) (已合并)：重新排序了ROCm注意力后端选择器的优先级，将原生 ROCM_ATTN 设为最高优先级（性能最优），优化了不同模型下的后端选择逻辑。
  8. #38155 ([ROCm][CI] Add LM Eval Qwen3.5 Models test for MI355)：为MI355 GPU新增Qwen3.5模型的GSM8K评测CI任务，持续完善AMD硬件的模型质量验证。
  9. #38167 ([ROCm][CI] Fix wvSplitKrc mock argument order)：修复了ROCm特定GEMM单元测试中因模拟函数参数顺序错误导致的测试失败。
  10. #38088 ([ROCm][CI] Increase OpenAPI schema test timeouts) (已合并)：针对ROCm CI环境可能较慢的情况，延长了OpenAPI schema测试的超时时间，提升测试稳定性。

Backport PRs (针对v0.13.0分支):

  1. #38180: 将修复Qwen3-Next非标准块大小（544）支持的PR #31380 backport至v0.13.0。
  2. #38146: 将修复AITER MLA解码路径中last_page_len计算错误的PR #31282 backport至v0.13.0。
  3. #38145: 将修复ROCM_AITER_TRITON_MLA后端在DeepSeek-V3上精度回归的PR #31816 backport至v0.13.0。

总结： 本周期AMD生态工作呈现 “深度优化” 和 “广度覆盖” 的特点。一方面，针对特定架构（RDNA 2, RDNA 4, CDNA 3）的性能问题和功能缺失进行精准修复；另一方面，通过完善CI测试、修复内核Bug、backport重要补丁，系统性提升vLLM在AMD全栈硬件上的稳定性、功能完整性和用户体验。

💬 高热度讨论分析

  1. Issue #38106: tool_choice="required" + speculative decoding leads to failed tool calls
    • 核心议题：当强制工具调用(tool_choice="required")与推测解码（使用Qwen3.5模型）结合时，模型输出了非JSON格式（XML）的工具调用，导致解析失败，进而产生无工具调用列表但finish_reason="tool_calls"的异常输出。
    • 观点与讨论：
      • 提交者 SvenLorenz 提供了详尽的复现步骤和日志，指出这可能是推测解码模型未遵循tool_choice的JSON格式约束，并提出了临时解决方案（禁用推测解码或修改解析器）。
      • 维护者 chaunceyjiang 积极跟进，首先确认此为首次遇到，并请求打印关键数据以定位问题。
    • 争议焦点：无显著争议，主要在于问题根因的排查——是推测解码的逻辑缺陷，还是模型本身在特定条件下的输出偏好？
    • 当前状态：问题仍为open，处于诊断阶段。
  2. Issue #38107: AMD gfx1030性能异常
    • 核心议题：RDNA 2消费级显卡在vLLM下性能远低于预期（对比llama.cpp）。
    • 观点与讨论：
      • 用户 Nero10578 提供了完整的配置、命令和性能数据。
      • 贡献者 Michelle-HCJ 给出了权威且专业的诊断：明确指出RDNA 2无硬件bf16支持，vLLM自动选择bf16会导致软件模拟，性能骤降。建议显式使用--dtype float16。
    • 争议焦点：无。这是一个典型的技术科普与问题解决场景。
    • 最终结论：用户采纳建议后问题解决，Issue被关闭。此案例对社区用户具有重要参考价值。
  3. Issue #38141 & PR #38142: Streaming Video Input RFC
    • 核心议题：提议为vLLM新增流式视频输入处理能力，以支持实时视频理解应用。
    • 观点与讨论：
      • 发起者 lishunyang12 撰写了非常详尽的RFC，论证了市场需求、技术可行性和实施路线图。
      • 随后，他提交了实现PR #38142，但很快主动关闭，并说明将工作合并至独立的 vllm-omni 仓库进行开发。
    • 争议焦点：无公开争议，但该举动反映了项目在管理复杂、跨领域新特性时的一种架构决策——将“全模态”相关的高级功能放在专门的项目中孵化，以保持核心vLLM引擎的专注性。
    • 当前状态：RFC和PR均已关闭，相关工作转移到 vllm-project/vllm-omni#2201。
  4. Issue #38171: [Feature]: Add TurboQuant Support for KV Cache Quantization
    • 核心议题：请求集成一篇新论文提出的 “TurboQuant” 向量量化方法，用于KV缓存压缩。
    • 观点与讨论：
      • 提交者 tunglinwood 系统性地介绍了该方法的理论优势（近最优失真率、无偏内积估计）。
      • 其他用户（gaby, 1315577677）表达了强烈的兴趣和支持，认为这对于大模型的内存节省“意义重大”。
    • 争议焦点：无争议，更多是社区对前沿技术的热切期待。
    • 当前状态：Issue为open，是一个高质量的特性提案。

🔥 热门话题与趋势分析

  1. AMD硬件支持持续深化：除上述专门章节外，多个PR和Issue显示社区正致力于解决AMD平台从消费级到数据中心级的各类“最后一公里”问题，包括性能调优、新架构适配、测试稳定化等。
  2. 工具调用与结构化输出：相关Bug修复和讨论热度不减（如#38106， #38168， #38103）。这反映出随着模型能力提升，复杂输出格式的处理已成为推理服务的核心挑战，相关解析器、流式支持、与推测解码等功能的兼容性是维护重点。
  3. 视频与多模态处理成为新前沿：虽然流式视频RFC被移至独立仓库，但它明确指出了行业趋势。同期还有PR #38156（优化NanoNemotron-VL视频编码批处理），表明多模态推理的效率和功能扩展是持续投入的方向。
  4. 内核与量化优化：社区持续引入和优化专用计算内核（如#38086 FP8 MoE， #38169 对问题内核的revert），并探索新的量化方案（如#38171 TurboQuant， #38138 新的在线量化前端），旨在提升性能与扩展硬件支持。

🛠️ 重点技术变更

  1. PR #38142 ([Realtime] Add streaming video input support) & Issue #38141：尽管已关闭，但其提出的架构和协议设计展示了将vLLM实时音频流处理能力扩展至视频领域的清晰路径，是项目边界拓展的重要尝试。
  2. PR #38086 ([ROCm] Enable VLLM triton FP8 moe for gfx1201)：此PR标志着vLLM对AMD最新RDNA 4架构的正式FP8 MoE计算支持，对于在该硬件上运行先进的MoE模型至关重要。
  3. PR #38174 ([Feature] Universal speculative decoding for heterogeneous vocabularies)：实现了支持异构词汇表的通用推测解码算法（Token-Level Intersection），允许草稿模型和目标模型使用不同的词表，显著提升了推测解码的模型选择灵活性，是一项重要的算法改进。
  4. PR #38168 ([Bugfix] Fix Hermes tool parser when stream interval > 1)：修复了Hermes工具解析器在流式输出间隔大于1时的边界错误。工具解析器的健壮性直接影响用户体验，此类修复至关重要。
  5. PR #38138 ([wip] new online quantization frontend)：正在开发新的在线量化前端，旨在提供更统一、简洁的用户配置接口（如quantization="fp8_blockwise"），预示着用户API的进一步优化。

📈 开发活跃度观察

💡 值得关注的问题

  1. AMD RDNA2 架构的 bfloat16 性能陷阱：Issue #38107 揭示的问题具有普遍性。项目文档或默认配置中可能需要更明确的警告或自动回退机制，以避免用户在RDNA2等不支持硬件bf16的显卡上遭遇性能断崖。
  2. ROCm CI测试框架的健壮性：Issue #38097 指出测试子进程创建方式可能导致测试被静默跳过，这可能影响测试覆盖率，尤其是对ROCm平台的测试质量。
  3. 新量化技术的集成路径：Issue #38171 (TurboQuant) 获得了社区积极反响。此类来自学术界的先进量化方法，如何评估、集成到vLLM现有的量化体系中，是一个值得观察的技术管理过程。
  4. 工具调用解析器的长期维护：工具调用相关的Bug报告频繁且细节复杂（如与流式、推测解码的交互）。需要持续投入资源以保证这套系统的稳定性和正确性。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR