View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-03-31 11:57 (UTC+8) ~ 2026-04-01 11:57 (UTC+8) 数据统计: 新 Issue 14 | 关闭 Issue 19 | 新 PR 60 | 合并 PR 51 | 关闭未合并 PR 23

📊 每日开发状态摘要

在2026年3月31日至4月1日期间，vLLM项目保持了极高的开发活跃度，新增并合并了大量代码。开发焦点集中在性能优化（特别是针对AMD平台和新量化方法）、问题修复（尤以Qwen3.5系列模型和FP8量化相关的问题为多）以及功能增强（如工具调用、池化模型支持）上。社区通过积极处理积压的旧Issue和引入多项重要优化（如vLLM IR、MoE重构、编译专用模式），展现出强劲的迭代和问题解决能力。

🎯 AMD/ROCm 生态相关动态

本周期内，AMD/ROCm生态的开发和优化活动非常活跃，涉及性能优化、问题修复和工具增强。

  1. 性能与功能优化
    • PR #38665 [ROCm] Enable dual-stream MoE shared experts and GLM-5 MXFP4 Quark support：由AMD员工提交。该PR旨在提升GLM-5 MXFP4模型在AMD MI355X GPU上的推理性能。主要改动包括：1）将MoE共享专家的双流执行从仅限CUDA扩展到is_cuda_alike()，从而支持ROCm/HIP流；2）将GLM-5模型架构 (glm_moe_dsa) 添加到Quark动态MXFP4支持列表中。这是将ATOM项目中的高性能优化移植到vLLM的重要一步。
    • PR #38647 Add opt-in --record-power option to vllm bench serve：由AMD员工 fxmarty-amd 提交。此PR为性能基准测试工具增加了功耗和能效（tokens/Joule）的测量功能，目前支持AMD GPU和CPU。这对于评估不同精度（dtype）和服务配置的能效至关重要。
    • PR #38627 [WIP] [ROCm] [Doc] Update ROCm attention selection doc and test coverage：修正了ROCm注意力后端自动选择的逻辑，确保在未指定--attention-backend时，能根据环境变量 VLLM_ROCM_USE_AITER 和sink_attn设置正确选择ROCM_ATTN、ROCM_AITER_FA或ROCM_AITER_UNIFIED_ATTN，并更新了文档和测试。
    • PR #38615 [ROCm] Fix aiter persistent mode mla with q/o nhead<16 for kimi-k2.5 tp8：修复了当每个GPU的注意力头数较少时，AITER MLA持久化模式下的形状不匹配问题，使得Kimi-K2.5等模型在TP=8时能正常工作。
  2. Bug修复与CI维护
    • PR #38680 [CI][ROCm] Remove unsupported cases in test_fusion.py：由于组量化（group quant）和逐张量量化（per-tensor quant）融合在ROCm AITER上不受支持，此PR移除了相关的测试用例，以通过CI。
    • PR #38614 [ROCm][CI] Fix ROCm Python-only install fetching CUDA torch via build isolation：修复了ROCm的Python-only安装测试中，因构建隔离导致错误下载CUDA版torch的问题。
    • PR #37841 replace cuda_device_count_stateless() to current_platform.device_count()：这是一项跨平台清理工作，将获取设备数量的函数统一为平台无关的接口，有助于未来对XPU等新加速器的支持，ROCm也从中受益。
  3. 模型支持与测试
    • PR #38664 [CI][ROCm] Add Qwen3.5-35B-A3B-MXFP4 model eval into CI：计划将AMD发布的MXFP4量化模型加入CI测试，表明对AMD生态量化模型的支持正进入标准化流程。

总结：AMD团队在本周期表现非常积极，提交了多项提升性能、能效和稳定性的核心代码，并持续完善CI/CD流程，显示出对vLLM在AMD硬件上成熟度的高度投入。

💬 高热度讨论分析

  1. Issue #38626: [Bug]: CUDA error: an illegal memory access was encountered when deploy Qwen3.5-35B-A3B-FP8 on A100
    • 核心议题：在A100 GPU（TP=2）上部署FP8量化的Qwen3.5模型时，在解码阶段触发CUDA非法内存访问错误。
    • 不同观点：
      • 贡献者 CodersAcademy006 提供了深入的技术分析：指出错误发生在rank 1，可能与非原生FP8（A100为模拟）、CUDA图（CUDAGraphMode）重放、以及缓存请求恢复导致的张量形状变化有关。给出了详细的调试建议（如CUDA_LAUNCH_BLOCKING=1）。
      • 贡献者 ZJY0516 则建议用户尝试最新版vLLM (0.18)。
    • 争议焦点：无直接争议。讨论侧重于技术根因分析。
    • 当前状态：问题仍为开放状态，等待用户反馈调试结果或确认新版本是否已修复。
  2. Issue #38634: [Bug]: MLA + FP8 KV cache + CUDA Graph causes random NaN in decode phase
    • 核心议题：使用MLA架构模型（如DeepSeek）时，开启FP8 KV缓存和CUDA Graph会导致解码阶段产生NaN值。
    • 不同观点：
      • 维护者 gaby 首先指出用户使用的vLLM版本 (0.12.0) 过旧，建议升级至最新版 (0.18.1)。
      • 用户 wwwjs 询问升级是否能解决问题。
      • 贡献者 RemizovDenis 从量化理论角度补充，指出标准FP8量化在分布尾部容易失稳，并介绍了替代方案（如3-bit + 残差缩放）。
    • 争议焦点：无争议。讨论形成了标准流程：先升级版本，再考虑是否为已知的量化稳定性问题。
    • 当前状态：开放。建议用户升级后观察问题是否复现。

🔥 热门话题与趋势分析

  1. Qwen3.5系列模型问题集中：多个Issue（#38656， #38626， #38643， #38666）报告了不同配置下Qwen3.5模型的启动卡死、CUDA错误、输出乱码等问题。这表明该热门模型系列（尤其是其FP8/A3B/NVFP4变体）在复杂配置下的兼容性和稳定性面临挑战。
  2. FP8量化与KV缓存的稳定性：除了上述Qwen3.5问题，Issue #38634和#38658均指向FP8 KV缓存与特定条件（CUDA Graph、Marlin、非原生FP8硬件）结合时产生的数值问题（NaN）或性能退化，成为当前一个技术攻坚点。
  3. 工具调用解析器的健壮性：Issue #38674 揭示了Jamba工具解析器对特定token格式的硬编码依赖，导致不支持标准Mistral格式的模型。这反映了工具调用生态多样化带来的兼容性挑战。
  4. 编译与性能优化持续深入：多个PR（如 #38675, #38657, #38671, #33825）围绕torch.compile、内核融合、迁移到Torch稳定ABI、以及引入vLLM IR等底层优化展开，体现了对极致推理性能的持续追求。

🛠️ 重点技术变更

  1. PR #38675 [torch.compile] Add compile-only mode：引入了vllm compile CLI命令和API，允许用户预编译模型而不执行推理，从而将编译开销与权重加载过程解耦，实现“热启动”。这是解决大模型启动慢问题的关键一步。
  2. PR #37160 [Feat][v1] Simple yet General CPU KV Cache Offloading：实现了一种新的、更简洁通用的CPU KV缓存卸载方案。它复用现有的BlockPool和KVCacheCoordinator，自动获得了HMA、前缀缓存和LRU驱逐等支持，相比旧方案代码量更少、功能更全。
  3. PR #36286 [MoE Refactor] Migrate Unquantized to Full Oracle Flow：将未量化（BF16）MoE的计算路径迁移到新的模块化“Oracle”流程，与FP8/NVFP4路径统一。这是MoE内核现代化重构的重要里程碑，提升了代码一致性和可维护性。
  4. PR #33825 [vLLM IR] 1/N Implement IR skeleton and rms_norm op：已合并。这是实现vLLM中间表示（IR）系统的基石PR。它定义了IR操作和内核的注册、分发机制，并首先实现了rms_norm算子。vLLM IR旨在成为统一、可扩展的算子抽象层，对未来的编译优化和多后端支持至关重要。

📈 开发活跃度观察

💡 值得关注的问题

  1. Qwen3.5 FP8/A3B模型的广泛问题：系列Issue表明该模型在特定硬件和配置下的部署存在不小风险，需要用户和开发者重点关注稳定性修复。
  2. MLA架构与FP8 KV缓存的兼容性：Issue #38634和#38652暗示MLA类模型与FP8 KV缓存的组合可能存在固有稳定性挑战，可能需要模型级或算法级的特别处理。
  3. 工具调用解析器的标准化：Issue #38674暴露了当前各解析器“各自为战”的问题，未来可能需要更统一、可配置的解析框架来应对多样化的模型输出格式。
  4. 新量化方法的引入：PR #38662 提出了全新的“TurboQuant” KV缓存量化方法（2/3-bit），声称能大幅降低内存占用。这类新技术虽然前景广阔，但其稳定性、性能收益和集成复杂度需要经过社区充分评估。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR