View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-03-26 11:45 (UTC+8) ~ 2026-03-27 11:45 (UTC+8) 数据统计: 新 Issue 37 | 关闭 Issue 33 | 新 PR 96 | 合并 PR 37 | 关闭未合并 PR 33

📊 每日开发状态摘要

本周期（2026-03-26至2026-03-27）vLLM 社区活动高度活跃，共产生 133 个新的 Issue 和 PR。开发焦点集中在性能优化（特别是 KV 缓存管理与 kernel 融合）、对新模型和量化格式的支持（如 Phi-4-Vision、TurboQuant），以及 AMD/ROCm 生态系统的持续完善。多个关键技术提案（如增量 MoE 卸载）和性能修复 PR 被合并，显示出项目在高效推理引擎方向上的快速迭代。

🎯 AMD/ROCm 生态相关动态

本周期 AMD 生态相关活动非常活跃，涵盖问题修复、性能优化、CI/CD 和文档完善等多个方面。

Issues：

PRs（重点关注来自 -amd 贡献者的提交）：

  1. 性能优化：
    • #38313 & #38299 (by khairulkabir1661): 为 ROCm 平台的 DeepSeek MLA 注意力机制添加 AITER 融合 kernel 支持，分别实现 RoPE + KV 缓存融合 和 RMSNorm + FP8 量化融合，旨在减少内存带宽和 kernel 启动开销，提升 MI300X 等 AMD GPU 上的性能。
    • #38296 (by divakar-amd): 重构 AITER 的 FP8 attention kernel 以原生支持 q_scale，简化代码并提升性能。
  2. Bug 修复：
    • #38293 (by vecheruk-amd): 修复了使用 Quark 量化（如 MXFP4）的 MoE 模型在进行推测解码（MTP/Eagle）时，因 draft 模型 MoE 层前缀不匹配而导致的 AssertionError 崩溃问题。修复方式是将断言改为回退到未量化的 MoE 方法。
    • #38263 (by tjtanaa): 紧急修复了刚刚启用的 ROCm nightly 发布管道中因变量未定义导致的构建失败。
    • #37547 (by gronsti-amd): 修复了 ROCm 上 Sparse MLA 实现中因 lru_cache 使用不当导致模块重复导入的性能问题。
  3. 平台支持与 CI：
    • #38236 (by Chinmay-Kulkarni-AMD): 更新 AMD Zen CPU 后端，正确声明支持的 dtype 并切换至 zentorch-weekly 依赖。
    • #38238 (by dhonnappa-amd): 为适应 Kubernetes 环境，移除了 AMD 硬件 CI 测试脚本中与宿主机 GPU 状态交互的步骤。
    • #38165 (by AndreasKaratzas): 修复 CI 测试容器中 PYTORCH_ROCM_ARCH 环境变量设置，确保 Quark 的 JIT 编译仅针对当前 GPU 架构，而非所有架构，加速测试。
    • #38184 (by micah-wil): 在 MI325 设备上启用 kernel 核心操作测试，并处理 MI250 上的相关测试不稳定性。
  4. Release 与生态建设：
    • #37283 (by tjtanaa): 已合并。此 PR 实现了 ROCm nightly 版本的 Docker 镜像和 wheel 包的自动化发布，是 AMD 生态在 vLLM 中成为“一等公民”的关键一步，直接回应了 Issue #36703 和 #36704 的需求。

总结：AMD 团队在 vLLM 中贡献全面且深入，从底层的 kernel 性能优化（AITER）、量化工具链集成（Quark），到平台支持（Zen CPU）、CI/CD 管道和最终的用户交付物（Nightly 版本）均在同步推进，显示出其构建完整、高性能异构计算生态的决心。

💬 高热度讨论分析

  1. Issue #38256: [RFC]: Incremental MoE Expert Offloading：
    • 核心议题：提出一个动态的 MoE 专家权重卸载架构，通过 GPU 缓存 + 异步流水线，使大型 MoE 模型能在显存较小的硬件上运行。
    • 观点与状态：作者 e1n00r 详细阐述了设计原则（缓存作为权重提供者）、3-PR 分阶段实施计划，并提供了独立实现 tinyserve 的生产数据作为佐证。目前尚无评论，但 RFC 本身内容详实，旨在征集社区对架构设计的反馈。
  2. PR #38280: [Quantization] Add TurboQuant KV cache quantization：
    • 核心议题：实现 Google 的 TurboQuant 算法，这是一种面向质量无损的亚 4 比特 KV 缓存向量量化方法。
    • 观点与状态：贡献者 lishunyang12 展示了在 Qwen2.5-1.5B 上 2/3/4 bit 量化均达到 100% 输出匹配 且 零延迟开销 的惊人基准测试结果。社区反应积极，xinyu-intel 确认在 XPU 上测试同样零质量损失和零延迟开销。讨论还涉及与另一实现草案的对比和未来测试建议。
  3. Issue #38212: MiniMaxM2ReasoningParser broken for M2.5：
    • 核心议题：MiniMaxM2ReasoningParser 无法正确处理 M2.5 模型生成的 `` 开始标签，导致推理内容泄漏到输出中。
    • 观点与状态：报告者 SilviuSavu 精准定位到是覆盖 extract_reasoning_streaming 方法时未考虑开始标签所致。参与者 Huyueeer 提供了详细的测试代码进行验证。核心争议点在于修复方式（直接移除覆盖 vs. 修改），从后续 PR #38213 看，采取了移除覆盖的简洁方案。
  4. Issue #38246: [Feature]: Better Flashinfer compilation logging：
    • 核心议题：Flashinfer 内核编译/调优时可能长达 10 分钟无日志，易被误认为卡死，请求增加进度提示。
    • 观点与状态：提出者 ProExpertProg 描述了痛点。社区迅速响应，JINO-ROHIT 立即认领了该 Issue 并提交了修复 PR #38254。讨论高效务实，直指用户体验问题。
  5. PR #38216: [Perf] Batch KV cache swap copies：
    • 核心议题：通过 cuMemcpyBatchAsync 批量执行 KV 缓存卸载/加载中的内存拷贝操作，大幅减少驱动调用开销。
    • 观点与状态：贡献者 Etelis 提供了详尽的各模型基准测试数据，显示在多种配置下可获得 3.6x 至 7.4x 的加速。此优化不改变行为，且对 CUDA 12.8+ 和旧版本均有妥善处理，是一项收益明确的基础性能改进，目前无争议。

🔥 热门话题与趋势分析

  1. 性能优化白热化：社区对极致性能的追求体现在各个层面：KV 缓存管理（批量拷贝 #38216、TurboQuant 压缩 #38280、混合模型卸载 #38261）、Kernel 融合（AMD 的 AITER 融合 #38313, #38299）、执行调度（跳过空工作 #38287）。
  2. 新模型与模态支持：持续集成新发布的模型是 vLLM 保持竞争力的关键。本周期出现 Phi-4 视觉推理模型 的支持问题 (#38309) 及对应 PR (#38306)，以及 NVIDIA Nemotron-3-Nano 混合模型在 Blackwell 上的运行问题 (#38208)。
  3. 工具调用与推理流：与模型智能体能力相关的工具调用解析器 (#38274, #38189)、推理（Think）流解析器 (#38212, #38213) 的 bug 修复和重构持续进行，反映了对生产环境复杂用例稳定性的重视。
  4. AMD 生态全面性建设：从底层 Kernel、量化工具（Quark），到 CI/CD、发布管道（Nightly Docker/Wheel），再到使用文档，AMD 正在 vLLM 内构建一个完整、可用的软件栈，挑战 CUDA 的生态垄断地位。

🛠️ 重点技术变更

  1. PR #37283: [Releases] [ROCm] Enable Nightly Docker Image and Wheel Releases for ROCm：
    • 技术解读：此 PR 为 ROCm 后端建立了与 CUDA 对等的持续发布管道，自动构建并推送 nightly 版本的 Docker 镜像（vllm/vllm-openai-rocm:nightly）和 pip wheel 包。
    • 影响：极大提升了 AMD 平台用户的开发体验，使其能方便地使用最新特性，是 AMD 生态成熟的重要标志。需关注后续文档（Issue #38304）的同步更新。
  2. PR #38280: [Quantization] Add TurboQuant KV cache quantization：
    • 技术解读：首次引入 TurboQuant 这一前沿的 KV 缓存向量量化技术。实现包括算法核心、引擎集成、Triton kernel 和完整基准测试。其特点是能在极低位宽（2-4 bit）下实现近乎无损的压缩，且运行时开销极低。
    • 影响：为超长上下文场景下的显存节省提供了新的强大工具，可能改变 KV 缓存压缩的技术选型格局。
  3. PR #38216: [Perf] Batch KV cache swap copies via cuMemcpyBatchAsync：
    • 技术解读：将 KV 缓存卸载/加载过程中大量细粒度的 cudaMemcpyAsync 调用，聚合成一次 cuMemcpyBatchAsync 调用。利用现代 CUDA 驱动的批处理能力，显著降低 CPU 侧的开销。
    • 影响：直接提升使用 KV 缓存卸载功能的场景（如内存不足或使用 NIXL 等外部缓存）的吞吐量，是一项普适且高效的基础设施优化。
  4. RFC #38256: Incremental MoE Expert Offloading：
    • 技术解读：提出一个渐进式、基于缓存的 MoE 专家权重动态调度方案。与静态卸载不同，它根据热度在 GPU 显存（缓存）和 CPU 内存之间迁移专家权重，允许超大规模 MoE 模型在有限显存上运行。
    • 影响：为解决大模型（如千亿参数 MoE）部署的硬件门槛提供了新颖的软件思路。其实施方案（分 3 个 PR）设计精巧，旨在降低评审复杂度。
  5. PR #38313 & #38299: [ROCm] AITER fusion kernels for MLA：
    • 技术解读：针对 DeepSeek MLA 模型在 AMD GPU 上的特定计算模式，利用 AITER 库实现了 RoPE 融合 KV 缓存写入、RMSNorm 融合 FP8 量化等多个关键操作的 kernel 融合。
    • 影响：这是针对特定模型-硬件组合的深度性能优化，展示了 AMD 团队通过软硬件协同设计挖掘 MI300 系列 GPU 潜力的能力，有助于提升其在特定负载下的竞争力。

📈 开发活跃度观察

💡 值得关注的问题

  1. Issue #38257: Qwen3-VL-235B OOM with multi-image long multiturn inputs：超大视觉语言模型在处理多图、长对话输入时出现 OOM，即使在 8x H100 节点上。这触及了当前多模态大模型推理的显存边界，其解决方案可能涉及更复杂的激活或 KV 缓存管理策略。
  2. Issue #38266: tokenizing long redundant sequences causes API server deadlock：使用特定 tokenizer（如 Harmony）处理长冗余字符串时， tokenization 耗时过长会导致 API 服务器死锁，影响其他并发请求。这暴露了服务端请求处理隔离性的潜在问题，对生产部署有重要影响。
  3. RFC #38256: Incremental MoE Expert Offloading：此架构提案若被接受并实现，将显著扩展 vLLM 对超大规模 MoE 模型的部署能力，是一个值得跟踪的重要技术发展方向。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR