View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-03-09 11:22 (UTC+8) ~ 2026-03-10 11:22 (UTC+8) 数据统计: 新 Issue 30 | 关闭 Issue 25 | 新 PR 114 | 合并 PR 46 | 关闭未合并 PR 24

📊 每日开发状态摘要

在过去24小时（2026-03-09至2026-03-10）内，vLLM 项目保持了极高的开发活跃度，新增了114个PR和30个Issue。社区关注的焦点主要集中在Qwen3.5系列模型的稳定性问题（特别是FP8、GPTQ量化和MoE变体）以及多模态推理中的内存泄漏上。同时，AMD生态的集成与优化工作持续进行，多个与ROCm、Quark相关的PR被提交，旨在提升在AMD硬件上的性能和功能支持。

🎯 AMD/ROCm 生态相关动态

本周期内，AMD相关贡献非常活跃，主要集中在性能优化、内核扩展和基础设施完善方面。

新增 Issue (1个):

新增/开放 PR (7个):

  1. 【性能优化】AWQ-Marlin 配置支持 (#36505)：由 AMD 员工 @mgehre-amd 提交。此PR使AWQMarlinConfig能在ROCm平台上使用统一的choose_mp_linear_kernel框架，替代了之前直接调用NVIDIA专用ops.marlin_gemm或ops.awq_gemm的路径。在AMD Strix Halo上测试Qwen3-4B-AWQ模型，获得了解码吞吐量提升73% 的显著性能收益。
  2. 【内核优化】AITER 持久化MLA解码内核 (#36574)：由 AMD 员工 @SKPsanjeevi 提交。为ROCm平台添加了AITER持久化模式MLA（多查询潜在注意力）解码内核支持，通过让内核常驻GPU计算单元来避免每次批处理的启动开销，旨在提升解码性能。通过环境变量VLLM_ROCM_USE_AITER_MLA_PERSISTENT控制。
  3. 【内核优化】AITER 融合MLA解码内核 (#36573)：由 AMD 员工 @khairulkabir1661 提交。添加了对MLA注意力的AITER融合解码内核支持，结合了FP4/FP8 BMM、RoPE、KV缓存写入等操作，旨在提升性能。
  4. 【Bug修复】Quark 模拟逻辑问题 (#36486)：修复了当AITER被禁用时，Quark（AMD的MXFP4/MXFP6量化工具）模拟路径不生效的问题。该问题由之前的PR引入，导致即使用户通过环境变量禁用AITER，系统仍错误地尝试使用AITER原生路径。此PR属于AMD/Quark生态的关键修复。
  5. 【CI/构建】添加新GPU架构支持 (#36499)：由 AMD 员工 @mgehre-amd 提交。将gfx1152/gfx1153（RDNA 3.5架构，如“Krackan”）添加到HIP支持的架构列表中，确保编译出的vLLM wheel包包含适用于这些新GPU的内核。
  6. 【CI/测试】降低ROCm测试的脆弱性 (#36442)：为ROCm测试添加重试机制，并禁用了“skinny GEMMs”特性以应对测试中的非确定性行为。讨论中，核心贡献者 @gshtras 指出，长期方案应是修复skinny GEMMs的bug而非在测试中禁用生产特性。
  7. 【基础设施测试】 (#36562)：标记为“DO NOT MERGE”，用于测试新的CI队列。

小结：AMD团队在本周期内动作频繁，一方面积极修复已发现的关键Bug（如Quark模拟逻辑），另一方面大力推进性能优化（AWQ-Marlin支持、AITER内核），并完善对新硬件的支持。性能回归Issue中的讨论也明确了社区对“优化需及时上游化”的期望。

💬 高热度讨论分析

  1. Issue #36452: Qwen3.5-35B-A3B-FP8 AssertionError
    • 议题：用户报告在启动Qwen3.5 FP8模型时遇到AssertionError导致启动失败。
    • 观点：
      • 用户 @Indigo-Coder-github：提供了详细的错误栈和复现步骤。
      • 核心贡献者 @ZJY0516：快速定位问题，指引用户查阅Qwen3.5配置文档，建议设置max_cudagraph_capture_size=256或enforce_eager=True。
      • 其他用户 @NovaShen555：建议尝试gpu_memory_utilization=1。
    • 争议/结论：无实质争议。用户确认文档中的解决方案有效，但追问了默认值导致错误的根本原因。@ZJY0516 解释是因为默认的max_cudagraph_capture_size大于最大缓存大小，并指出enforce_eager会影响性能。该Issue展示了社区对Qwen3.5系列模型“最佳实践”的积累，以及文档的重要性。
  2. Issue #36454: vLLM v0.15.0 与 ROCm v0.14.0 的性能回归
    • 议题：对比上游版本与AMD维护分支版本的性能。
    • 观点：
      • 报告者 @Spurthi-Bhat-ScalersAI：提供了详尽的基准测试数据和配置，证明AMD分支性能更优。
      • 核心成员 @robertgshaw2-redhat：代表项目立场，明确指出上游不跟踪下游分支的回归，责任在于AMD方将优化合并到上游。
    • 争议焦点：这并非技术争议，而是项目治理和协作流程的明确表态。它划清了社区版与供应商定制版的界限，强调了“上游优先”的原则。
    • 结论：Issue被迅速关闭，结论清晰：性能差异需由AMD通过上游PR解决。
  3. Issue #36456: 本地GGUF路径加载失败
    • 议题：使用本地GGUF文件配合--hf-config-path时，因代码路径问题导致模型架构识别失败（qwen35 is not supported yet）。
    • 观点：
      • 报告者 @shba007：进行了深入分析，指出maybe_override_with_speculators函数在处理本地GGUF文件时，绕过了用户提供的--hf-config-path，直接尝试解析GGUF文件，而当前transformers库的GGUF解析器尚未支持qwen35架构。
      • 其他用户：询问解决方案（如升级transformers）。
    • 争议/结论：这是一个明确的Bug报告，指出了本地加载路径与HF Hub加载路径的行为不一致问题。讨论揭示了vLLM模型加载流程中针对不同来源（HF Hub vs 本地文件）的逻辑差异，是底层框架兼容性的一个案例。
  4. PR #36486: 修复Quark模拟逻辑问题
    • 议题：如何正确修复Quark在AITER禁用时的模拟逻辑。
    • 观点：
      • PR作者 @wangjiaxin99：提出将多个条件合并为一个AND判断来简化逻辑。
      • 审阅者 @ChuanLi1101（可能为AMD方）：指出该简化逻辑可能错误地将两个独立的非模拟路径（CK原生路径 和 Triton MXFP4后端路径）耦合，导致某些场景下（如硬件不支持MX但存在Triton后端）仍错误地强制模拟。他提到了另一个待合并的修复PR (#36422)。
    • 争议焦点：修复方案的完整性与正确性。是简单合并条件，还是需要更精细地处理两条独立路径。
    • 当前状态：PR仍处于开放状态，需要根据评审意见修改逻辑以确保所有情况都被正确处理。

🔥 热门话题与趋势分析

  1. Qwen3.5系列模型的稳定性挑战：多个新增Issue（#36452, #36489, #36476, #36566, #36478）都围绕Qwen3.5不同规模的模型（35B, 122B, 397B）在v0.17.0版本下的启动失败、随机崩溃或性能异常。max_cudagraph_capture_size参数频繁成为临时解决方案的关键，表明该系列模型的CUDA图编译与KV缓存配置存在普遍适配问题。
  2. 性能回归与优化并进：一方面有用户报告版本升级带来的性能回退（#36454）；另一方面，大量PR（如#36505, #36574, #35777）致力于引入新的融合内核、优化调度以减少开销，这反映了项目在快速迭代中平衡性能与稳定性的常态。
  3. 多模态与内存泄漏：Issue #35191（关于Qwen3.5 397B多模态推理下内存线性增长直至OOM）在本次周期内被关闭，可能已修复。但这类问题揭示了大规模多模态模型服务时，缓存管理、内存回收机制的复杂性，是需要持续关注的领域。
  4. 生态系统扩展：
    • Apple Silicon支持：PR #36523 正式为macOS的MPS（Metal）后端添加平台支持，并附有详细文档，满足了社区长期以来的需求（#1441）。
    • 架构抽象化：RFC #36459 提议对vLLM IR内核注册机制进行重构，以更好地支持树外（Out-of-Tree）硬件后端，这为未来集成更多异构计算平台（如AMD、Intel、苹果等）奠定了更清晰的架构基础。

🛠️ 重点技术变更

  1. Apple MPS平台支持（#36523）：这是一个重要的平台扩展。该PR引入了完整的MPS平台实现，包括设备管理、纯PyTorch实现的Attention后端、Metal INT4/GGUF反量化内核（可选）等。它使vLLM能够利用Apple Silicon GPU进行加速推理，虽然性能与专用GPU有差距，但极大地拓宽了部署场景。
  2. vLLM IR 内核注册机制RFC（#36459）：这是一个重要的架构演进提案。旨在解决当前内核模块强制导入、不利于第三方平台集成的问题。核心思想是将内核模块加载的职责委托给Platform类，让每个平台（如CUDA、ROCm、MPS）自行决定加载哪些内核实现。这提升了vLLM的模块化和可扩展性，对AMD及其他异构后端社区是长期利好。
  3. Health检查改进（#36451）：针对V1引擎，添加了health_ping()机制，通过轻量级IPC轮询来检测引擎核心是否“活锁”（进程存活但业务循环卡死）。这增强了生产环境下的可观察性和可靠性，是对原有仅能检测进程崩溃的死亡哨兵机制的重要补充。
  4. AnyModel 异构模型支持（#36512）：来自NVIDIA的贡献，旨在支持通过NAS（神经架构搜索）生成的异构架构模型（每层的配置如KV头数、FFN维度、专家数可能不同）。这是首个在主流推理框架中支持此类高度灵活模型结构的工作，为部署前沿的模型压缩与优化成果打开了大门。

📈 开发活跃度观察

💡 值得关注的问题

  1. 多模态内存泄漏根因：虽然#35191被关闭，但大规模多模态模型（如Qwen-VL、Qwen3.5-VL）在长时间高并发下的内存增长问题需要持续监控，确认修复是否彻底。
  2. Qwen3.5系列的“踩坑”经验普及：大量用户遇到类似启动问题。需要评估是否应将max_cudagraph_capture_size等参数的推荐值更直接地整合到模型加载逻辑或错误提示中，降低用户的使用门槛。
  3. AMD优化上游化进程：在性能回归Issue的讨论后，社区会密切关注AMD团队是否以及如何将MI300X等平台的关键优化贡献到主分支，以避免未来版本再次出现类似的性能差距争议。
  4. XLA后端的内存开销：Issue #36537 报告了record_metadata_for_reloading函数在XLA后端导致2-3倍主机内存膨胀的问题。这对使用TPU等硬件的用户影响较大，需要尽快评估优化方案（如惰性记录）。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR