View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-03-11 11:27 (UTC+8) ~ 2026-03-12 11:27 (UTC+8) 数据统计: 新 Issue 33 | 关闭 Issue 25 | 新 PR 73 | 合并 PR 71 | 关闭未合并 PR 30

📊 每日开发状态摘要

在2026年3月11日至12日的24小时窗口期内，vLLM项目保持了极高的开发活跃度，共新增73个PR并合并了71个。主要进展集中于AMD/ROCm生态性能优化、新模型（尤其是多模态模型）支持以及大规模系统部署（如DGX Spark）的兼容性修复。同时，社区围绕多个核心功能（如量化、工具调用、调度器）的bug修复与性能优化展开了深入讨论。

🎯 AMD/ROCm 生态相关动态

本周期AMD生态相关的贡献非常活跃，主要体现在性能优化、功能完善和兼容性修复上。

  1. 性能优化（Perf）:
    • PR #36810 (新增): [ROCm][Perf] Fused GEMM + static FP8 output quantization。由 andyluo7 提交，核心创新在于将FP8 GEMM与静态量化融合为单个torch._scaled_mm调用，直接输出FP8数据，消除了BF16中间结果的DRAM往返。在MI300X上，针对常见模型形状（如4096x4096）实现了1.5倍至1.6倍的性能提升。这利用了ROCm 6.0+ hipBLASLt原生支持FP8输出的特性。
    • PR #36743 (新增): [ROCm] Optimize concat_mla_q for CDNA3 (MI300X) and CDNA4 (MI355X)。同样是 andyluo7 的贡献，针对不同架构进行了针对性优化：在CDNA3上使用非临时存储提示以提升HBM带宽效率（小规模token提速可达23%）；在CDNA4上启用256位宽加载/存储，使向量化循环迭代次数减半。
    • PR #35093 (已合并): 为CDNA4添加了针对Kimi K2.5 MoE模型的调优内核配置，在TP=8场景下带来了显著的端到端性能提升（更低的TTFT和TPOT）。
  2. 功能与兼容性:
    • PR #36785 (新增): Update rocm get gpu info capability。由 tmm77 提交，旨在允许amdsmi在torch不可用时获取GPU信息，以支持更灵活的部署场景（如使用Ray后端时）。
    • PR #35923 (已合并): 修复了ROCm注意力后端在Qwen3.5等使用非标准block size（如1056）模型上无法正确运行的问题。
    • PR #36499 (已合并): 将gfx1152/gfx1153 (Krackan, RDNA 3.5) 架构加入HIP支持的架构列表，确保为这些新GPU正确编译内核。
    • PR #36274 (已合并): 修复ROCm注意力后端验证逻辑，使其与CUDA平台行为一致，在验证前剥离block_size，以支持不规则block size。
  3. 相关Issue:
    • Issue #36805: 报告了一个与TorchAO相关的误导性错误信息，该信息错误地将GPU计算能力（SM 8.9）表述为CUDA版本。该Issue被标记了rocm标签，并由机器人自动通知了AMD相关维护者（@hongxiayang, @tjtanaa）。
    • Issue #36769: 关于Qwen3.5工具调用的bug报告，同样被标记rocm并通知了AMD维护者。

总结：AMD生态的贡献者（包括andyluo7、amd-asalykov、tmm77等）在本周期表现突出，工作重点从基础功能支持转向深度性能挖潜和架构特定优化，特别是针对MI300X/MI355X以及FP8计算路径，显示出vLLM在AMD硬件上的支持日趋成熟和精细化。

💬 高热度讨论分析

  1. Issue #36753: “POST /wake_up causes vLLM process to crash”
    • 核心议题：用户尝试利用vLLM的Sleep/Awake功能在单卡上动态切换多个模型时，发送/wake_up请求导致进程崩溃。
    • 观点与进展：
      • 用户 lazybum-sudo 详细描述了复现步骤，并直接@了维护者。
      • 维护者 DarkLight1337 将其转交给相关专家 (@youkaichao, @tjtanaa)。
      • 贡献者 KrxGu 主动提出可以介入调查，认为问题可能出在sleep/wake控制路径和EngineCoreClient.ensure_alive()的失败上。
    • 当前状态：维护者表示需等待被@专家的回应，问题仍为open。这是一个涉及核心引擎生命周期管理的复杂问题，社区正在协调资源进行排查。
  2. Issue #36805: “Misleading error message for FP8 quantization”
    • 核心议题：错误信息 “Float8 dynamic activation quantization is only supported on CUDA>=8.9 and MI300+” 具有误导性，其中的“CUDA>=8.9”实际指的是GPU计算能力（SM version），而非CUDA工具包版本。
    • 观点与立场：报告者 jranaraki 明确指出这是TorchAO中的问题，并给出了清晰的修改建议。社区机器人自动标记并通知了ROCm相关维护者。
    • 争议焦点：无争议，属于明确的bug报告和改进建议。
    • 当前状态：open，等待上游（TorchAO）或vLLM维护者处理。
  3. PR #36766 vs. PR #36779: 关于 opcheck 测试失败的修复方案争议
    • 核心议题：两者都旨在修复 rms_norm_per_block_quant 内核opcheck测试中误报权重张量被修改的问题。
    • 不同观点：
      • PR #36766 的方案是跳过opcheck的 test_schema 检查。
      • PR #36779 的方案是修正测试中传递给内核的 scales 张量形状，并添加运行时校验，从根本上解决问题。
    • 争议焦点：KrxGu（PR #36779作者）强烈反对跳过test_schema，认为这会掩盖真正的内存安全风险，并指出PR #36766的方案可能未经充分本地验证。最终，ProExpertProg 支持了 KrxGu 的根本性修复方案。
    • 当前状态：PR #36766 已被关闭，PR #36779 正在推进中。这体现了社区对代码质量、测试严谨性和根本性修复的重视。

🔥 热门话题与趋势分析

  1. 新一代硬件支持与适配：
    • NVIDIA Blackwell (sm_121)：多个Issue（#36821, #36835）集中报告了在DGX Spark（B200）上运行vLLM的问题，包括缺少内核支持、CUTLASS兼容性检查失败等。社区迅速提供了从源码编译的解决方案和定制Docker镜像。
    • AMD CDNA4 (MI355X)：PR #36743专门针对该架构进行优化，显示支持已进入性能调优阶段。
  2. 大规模/复杂部署问题：
    • CPU Offload 与 UMA：Issue #36796 报告了在GH200统一内存模式下CPU Offload的复杂错误。
    • 张量并行与数据并行：Issue #36793 反映了在TP=2, DP=2配置下运行量化模型的稳定性问题。
    • 分布式通信优化：PR #36834 提出了一个新的分层AllReduce实现，旨在优化多节点性能。
  3. 模型与工具生态扩展：
    • 新模型集成：大量PR关于支持新模型，如Kimi-Audio（#36127）、ColPali（#36818）、Granite4工具解析器（#36827）等。
    • 推测解码（Speculative Decoding）增强：多个PR（#36767, #36361, #35461）围绕DFlash、EAGLE3集成和概率性拒绝采样进行改进，这是当前提升推理效率的热点方向。

🛠️ 重点技术变更

  1. PR #36810 (Fused GEMM+FP8量化 for ROCm)：此变更是AMD平台FP8推理性能的关键优化。通过内核融合减少数据移动，直接利用了AMD硬件和软件栈的新特性，对MI300系列用户的性能体验有实质性提升。
  2. PR #36799 (移除Sparse24 CT集成)：这是一个重要的清理和弃用（Deprecation）变更。由于Sparse24模型使用不广泛，为减轻维护负担，移除了相关集成和内核。这标志着项目在权衡功能广度与维护成本后做出的决策，有助于代码库的长期健康。
  3. PR #35461 (Model Runner V2 概率性拒绝采样)：为vLLM V2模型运行器增加了概率性拒绝采样算法，相较于严格的拒绝采样，能显著提升草案令牌的接受率（在GLM 4.7上+6.69个百分点）和整体吞吐量（+15%），是推测解码领域的重要演进。
  4. PR #35781 (调度器优化 for P/D disaggregation)：针对异步远程KV加载场景优化了调度器开销，采用事件驱动方式减少队列扰动，带来了约5%的端到端性能提升。这体现了对 disaggregation 等前沿架构性能的持续打磨。

📈 开发活跃度观察

💡 值得关注的问题

  1. 新一代GPU的兼容性：Issue #36821, #36835 揭示了对NVIDIA Blackwell架构的官方支持尚不完善，用户目前依赖社区提供的自定义构建方案。这需要项目官方CI和发布流水线尽快跟进。
  2. 内存与并发相关的稳定性：Issue #36796 (CPU Offload), #36826 (并发请求导致流式传输卡顿/崩溃), #36793 (TP/DP配置错误) 等都指向了在复杂配置和高负载下的内存管理、并发同步等深层次稳定性挑战。
  3. 量化与编译的交互：Issue #36805 (错误信息)、PR #36766/36779 (opcheck测试) 以及一些关于GPTQ Marlin内存访问错误的Issue，都反映了量化技术栈与PyTorch编译等底层系统交互的复杂性，是易出问题的领域。
  4. 引擎生命周期管理：Issue #36753 (/wake_up 崩溃) 涉及到Sleep/Wake这一高级功能，其健壮性对于生产环境多模型部署至关重要，需要核心维护者重点关注。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR