View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-03-15 11:50 (UTC+8) ~ 2026-03-16 11:50 (UTC+8) 数据统计: 新 Issue 6 | 关闭 Issue 10 | 新 PR 39 | 合并 PR 7 | 关闭未合并 PR 11

📊 每日开发状态摘要

本周期（2026-03-15至2026-03-16）vLLM 社区保持高度活跃，新增 39 个 PR，合并 7 个，显示了强劲的开发动力。核心关注点集中在内存管理优化（多个内存 OOM/高估 Bug）、对新硬件与新模型架构的适配（如 RTX Blackwell SM 120、混合 Mamba/Attention 模型），以及AMD 生态支持的持续深化。性能优化与量化支持（特别是 MXFP4 和 Quark）是技术演进的主要方向。

🎯 AMD/ROCm 生态相关动态

本周期 AMD 生态贡献显著，涵盖 GPU 与 CPU 领域：

  1. PR #37137 [ROCm][Quantization] Add Quark W4A16 MXFP4 A16 for LinearLayer
    • 贡献者：xuebwang-amd（AMD员工）
    • 内容：为 LinearLayer 添加了基于 Quark 量化工具的 W4A16 MXFP4（权重量化）支持。这是 AMD 自研量化工具链与 vLLM 集成的重要一步，旨在为 AMD GPU 提供高效的量化推理方案。
    • 测试：在 Qwen3-8B 模型上使用 MXFP4 权重量化进行了正确性验证（GSM8K 基准测试）。
    • 影响：丰富了 AMD 平台上的量化格式选择，有助于提升 MI 系列 GPU 的推理能效。
  2. PR #35970 [Merged] In-Tree AMD Zen CPU Backend via zentorch [1/N]
    • 贡献者：amd-lalithnc（AMD员工）
    • 内容：已合并。为 AMD Zen（EPYC）CPU 引入了 “zentorch” 后端支持。当检测到支持 AVX-512 的 AMD CPU 并安装 zentorch 后，平台将自动路由 GEMM 操作至优化后的 zentorch_linear_unary 内核。
    • 技术细节：引入 ZenCpuPlatform 子类、权重预打包（通过 VLLM_ZENTORCH_WEIGHT_PREPACK 控制）、专用的 Docker 构建目标（vllm-openai-amd），并修复了 PyTorch 2.10 下的一个编译缓存问题。
    • 影响：这是 AMD CPU 原生高性能支持 的基础性工作，旨在为基于 EPYC 的服务器的 CPU 推理场景提供显著的性能提升。
  3. Closed Issue #35132 & #29534
    • 内容：两个与 ROCm CI 相关的测试失败问题被关闭，表明之前影响 AMD 平台测试稳定性的问题（如跨层 KV 布局测试、MOE LoRA 对齐内核的共享内存超限）已通过相关 PR 得到修复。
    • 影响：提升了 AMD CI 流水线的稳定性和可靠性，是保障 AMD 平台代码质量的关键。

小结：AMD 团队正从 GPU 量化（Quark） 和 CPU 原生后端（zentorch） 两个维度系统性地增强 vLLM 在 AMD 全栈硬件上的竞争力与用户体验。

💬 高热度讨论分析

  1. Issue #37096: [Bug]: v0.17.0-aarch64 onwards will run out of CUDA memory for gpt-oss-120b on GH200 144GB
    • 核心议题：用户在 GH200（ARM架构）上运行大模型时遭遇严重的内存 OOM，non_torch_memory 计算出现负值，导致 KV 缓存过度分配。
    • 不同观点：
      • 报告者 (xuancong84, gaby)：提供了详细环境信息，指出多个模型在 0.17.x 版本均出现异常内存申请。
      • 推测者 (ZJY0516， haosdent)：关联到可能与 PR #30515（睡眠模式）或 PR #32947（cumem 分配器）有关。haosdent 明确指出根因可能是 memory_reserved() 未能跟踪 cumem 清理，导致计算偏差，并提出了修复 PR #37111。
    • 当前状态：问题开放中，但根本原因已由 haosdent 定位并提交修复 PR（#37111）。讨论体现了社区对内存管理这一核心问题的高度关注和高效协作。
  2. Issue #37113: MLA attention support for SM 120 (RTX Blackwell)
    • 核心议题：支持 MLA（Multi-head Latent Attention）模型（如 GLM-5， DeepSeek-V3.2）在 NVIDIA 新一代 RTX Blackwell (SM 120) 显卡上的运行。
    • 讨论内容：用户 voipmonitor 系统性地提出了问题、解决方案（三个关联 PR #37116, #37117, #37119）和性能基准。后续更新中揭露了 MTP 推测解码在并发请求下的竞态条件崩溃问题，并进行了根因分析（批处理队列竞态、Blackwell SM120 稳定性），提出了修复 PR #37132。
    • 争议焦点：无显著争议，更多是技术攻关的同步与进展分享。
    • 当前状态：开放中，作为跟踪 Issue。一系列修复 PR 已提交，展现了社区快速适配新硬件的能力。
  3. Issue #37121: [Performance]: KV cache ~7x memory overestimation for hybrid Mamba/attention models (Qwen3.5)
    • 核心议题：vLLM 的 KV 缓存分析器未能正确处理 Qwen3.5 等混合 Mamba (O(1) 状态) 与 Attention (O(n) KV) 的模型架构，导致内存分配被严重高估（约7倍），利用率低下。
    • 不同观点：
      • 报告者 (swtb3)：详细分析了代码根因（kv_cache_utils.py 中的统一页面大小和报告逻辑问题），并提出了具体的修复方案。
      • 社区：无反对意见。报告者主动表示愿意提交 PR。
    • 当前状态：开放中。对应的修复 PR #37124 已迅速被提交，展示了问题从发现到提出解决方案的高效流程。

🔥 热门话题与趋势分析

  1. 模型支持持续扩大：新增了 HyperCLOVA X（PR #37107）模型的支持，反映了 vLLM 紧跟主流模型家族发展的趋势。
  2. 性能优化与内存管理：多个 PR 围绕性能提升和内存精确管理展开，例如：
    • 内核优化：PR #37110 将 FP8 动态逐组量化融合到 Triton attention 内核中，消除 HBM 往返，提升 prefill 性能（最高 1.73倍）。
    • 加载优化：PR #37136 针对 DP+EP 部署场景，在模型加载时跳过读取非本地专家权重，将 MoE 模型加载速度提升最高 2.5 倍。
    • 内存估算修复：除了 #37124，PR #37111 修复了因 cumem 分配器导致的 memory_reserved() 跟踪错误，解决了内存 OOM 的根本问题。
  3. 量化支持深入推进：围绕 MXFP4 格式的优化（PR #37128, #37135）和 AMD Quark 工具的集成（PR #37137）是量化方面的主要工作，旨在为不同硬件平台提供高效的量化方案。
  4. 新硬件与架构适配：除了对 RTX Blackwell (SM 120) 的支持（Issue #37113），对混合架构模型（Mamba+Attention）的适配（Issue #37121）也是当前热点，说明 vLLM 正在应对越来越复杂的模型结构。

🛠️ 重点技术变更

  1. PR #37111: [Bugfix] Fix OOM caused by cumem allocator inflating memory_reserved()
    • 解读：修复了一个深层次的 CUDA 内存管理 Bug。当使用 cumem 分配器时，其手动释放缓存块的操作绕过了 PyTorch 的跟踪，导致 torch.cuda.memory_reserved() 数值虚高，进而使 vLLM 低估了非 KV 缓存内存，过度分配 KV 缓存引发 OOM。
    • 影响：解决了自 #32947 后可能引入的系统性内存估算错误，对使用 cumem 分配器加载大模型的稳定性至关重要。
  2. PR #37124: [Bugfix] Fix KV cache overestimation for hybrid Mamba/attention model…
    • 解读：专项修复了 vLLM KV 缓存管理逻辑对混合状态模型（如 Qwen3.5）的不适配问题。通过区分对待 Mamba 层的常数大小“状态”和 Attention 层的线性增长 KV 缓存，实现了精确的内存计算与分配。
    • 影响：大幅提升了 Qwen3.5 系列模型在 vLLM 中的内存利用率，为高效部署此类新兴架构模型铺平道路。
  3. PR #37135: [Bugfix] Fix FP16 overflow in NVFP4 Marlin kernel epilogue…
    • 解读：修复了 NVFP4 Marlin 量化内核中两个关键 Bug：1) FP16 累加器在应用 global_scale 前转换导致的溢出；2) SM75 架构上 FP16 MMA 累加导致的中间溢出。通过调整计算顺序和禁用 FP16 累加，确保了数值稳定性。
    • 影响：保障了 NVFP4 量化模型在更广泛 GPU 架构（尤其是较旧的 SM75）上使用 FP16 精度推理的正确性，扩大了该量化方案的适用性。

📈 开发活跃度观察

💡 值得关注的问题

  1. 内存管理复杂性：Issue #37096 及其修复 PR #37111 揭示了底层内存分配器（如 cumem）与上层内存统计之间微妙的交互问题。随着更多定制化内存管理策略的引入，此类问题的调试和防范需要持续关注。
  2. 新硬件与新格式的稳定化：Issue #37113 显示，在 RTX Blackwell 上支持 MLA 等新 attention 格式仍面临稳定性挑战（如并发 MTP 下的竞态条件）。确保新硬件上各种优化内核的稳定运行是持续的工作。
  3. 混合模型架构的通用支持：Issue #37121 和 PR #37124 解决了 Qwen3.5 的特定问题，但随着 Mamba、MLA、MoE 等组件以各种形式组合，vLLM 的 KV 缓存、调度器等核心组件可能需要更通用的抽象来优雅地支持这些混合架构。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR