View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-03-24 11:33 (UTC+8) ~ 2026-03-25 11:33 (UTC+8) 数据统计: 新 Issue 26 | 关闭 Issue 24 | 新 PR 79 | 合并 PR 36 | 关闭未合并 PR 17

📊 每日开发状态摘要

在本次时间窗口内，vLLM 项目保持了高强度开发，新增与合并了大量 PR（79个新增，36个合并），反映了社区持续的代码贡献和功能迭代。核心关注点集中在Qwen3.5等大模型的实际部署问题（如Pipeline Parallelism、ROCm兼容性）和针对特定硬件（如AMD MI300、NVIDIA L40S）的性能优化上。同时，围绕是否应为旧硬件（如Ampere架构A100）提供兼容性支持的讨论引发了社区关注。

🎯 AMD/ROCm 生态相关动态

本周期AMD生态相关活动较为活跃，主要集中在问题修复与内核优化上。

  1. ROCm平台上的模型Bug：
    • Issue #37996: 用户报告Qwen3.5-397B GPTQ模型在ROCm上仅输出感叹号。另一位用户确认了类似问题。这属于ROCm平台上的关键推理正确性问题，已自动标记给ROCm维护团队。
    • Issue #37992 & PR #37993: AMD员工 xuebwang-amd 报告在MI325X (gfx942) 上运行Qwen3.5-MoE视觉模型时，在profile_run阶段因flash_attn的Triton rotary内核失败而崩溃。他随即提交了PR #37993，增加了回退到原生rotary embedding的逻辑以修复此问题。
    • PR #37973: 贡献者 vllmellm 提交了在ROCm上为Triton Attention启用FP8 Query的优化，旨在提升性能。这表明社区在持续优化ROCm平台的推理效率。
  2. GPT-OSS模型在ROCm上的修复：
    • PR #37787 (已合并): 修复了因PR #37128重构而引入的GPT-OSS模型在ROCm上的回归问题，包括CK MXFP4后端选择、对齐检查以及padding参数的传递。这是确保GPT-OSS在AMD硬件上稳定运行的重要修复。
    • PR #38043: 作为后续修复，进一步调整了GPT-OSS在ROCm上的RMSNorm融合与padding策略（如将MI300的padding从128调整为256），并重新启用了相关融合优化。
  3. 基础设施与集成：
    • PR #37980: 虽然主要关于DeepGEMM集成，但通过CMake FetchContent将其打包进wheel的改动，简化了所有平台（包括ROCm）上DeepSeek-V3等依赖DeepGEMM的模型的部署流程。

💬 高热度讨论分析

  1. Issue #38006: 是否应为Ampere GPU实现 TRITON_MLA_SPARSE 后端以支持Sparse MLA模型？
    • 核心议题：用户请求为sm80（A100/A800）GPU实现TRITON_MLA_SPARSE后端，以支持GLM-5、DeepSeek V3.2等使用稀疏MLA的模型。
    • 不同观点：
      • 请求方 (ehfd)：认为这具有战略意义，就像过去vLLM为Ampere实现FP8 fallback从而吸引用户一样，实现此功能将把所有使用稀疏MLA模型的Ampere用户吸引到vLLM。
      • 维护者 (youkaichao)：明确表示这不是vLLM维护者的优先事项。认为即使在A100上运行这些模型也“困难/意义不大”，建议保持当前直接报错的策略，有兴趣的社区开发者可以自行维护分支。
    • 争议焦点：项目官方维护的优先级（聚焦新硬件/最优性能）与社区用户对现有硬件投资保护需求之间的冲突。
    • 当前状态：Issue仍开放，维护者立场明确，依赖社区贡献。
  2. Issue #37996: Qwen3.5 397B GPTQ在ROCm上输出异常
    • 核心议题：特定大规模模型在AMD平台上产生完全错误的输出（全感叹号）。
    • 讨论内容：用户提供了详细的复现环境。机器人自动请求更多信息并标记给ROCm维护者。另一用户回复遇到相同问题，增加了问题的普遍性。
    • 当前状态：Issue开放待解决，属于ROCm平台上的高优先级Bug。
  3. Issue #36613 (已关闭): Qwen3.5-397B在高并发下启用MTP导致CUDA非法内存访问
    • 核心议题：大规模MoE模型在启用多令牌预测（MTP）和高并发时出现致命CUDA错误。
    • 讨论内容：多名用户确认遇到相同或类似问题。维护者建议测试nightly版本并提供复现脚本。讨论中发现降低预测令牌数（如从5降至1）可规避问题，指向了MTP实现中的并发安全性或内存管理缺陷。
    • 最终结论：Issue在用户确认调整超时环境变量可解决问题后被关闭，但根本的MTP高并发稳定性问题可能仍需关注。

🔥 热门话题与趋势分析

  1. Qwen3.5系列模型的部署挑战：多个Issue（#37996, #37972, #37967, #38024）围绕Qwen3.5（尤其是MoE大版本）的部署问题展开，涉及Pipeline Parallelism、Tokenizer兼容性、特定配置下的错误等，反映出该系列模型在vLLM生态中被广泛使用但仍有适配磨合期。
  2. AMD平台支持深化：除上述ROCm-specific问题外，PR活动显示社区正积极解决AMD平台上的性能回归（#37787）并推进优化（#37973），支持正从“能运行”向“高效稳定运行”迈进。
  3. 性能优化精细化：针对特定硬件和模型形状的微优化成为趋势，例如为L40S/SM89调整GPT-OSS的Marlin MoE策略（#38054），为DeepSeek V3.2开发融合concat+quant的FP8内核（#38028），以及为CPU推理优化Mamba状态处理（#38047）。
  4. API与功能扩展：前端功能持续增强，如新增梯度计算API（#38008）、支持批处理消息的structured output（#38011）、增加gRPC健康检查（#38016）等，提升了vLLM的易用性和企业级特性。

🛠️ 重点技术变更

  1. PR #37987 (已合并)：为非Triton平台修复compute_slot_mapping崩溃
    • 解读：此PR修复了一个关键兼容性Bug。之前的重构移除了numpy后备实现，导致在不支持Triton的平台上（如ppc64le或纯CPU环境）崩溃。修复通过为这些平台提供替代实现，保障了vLLM在异构计算环境中的可运行性。
    • 影响：巩固了vLLM在非标准GPU架构和CPU上的部署能力。
  2. PR #37980 (进行中)：将DeepGEMM深度集成至vLLM Wheel
    • 解读：该PR通过CMake的FetchContent机制，将DeepSeek模型推理所需的DeepGEMM库直接编译并打包进vLLM的发布wheel中，消除了用户手动安装的步骤。
    • 影响：极大简化了DeepSeek-V3等模型的部署体验，降低了使用门槛，是提升用户体验的重要基础设施改进。
  3. PR #37787 (已合并)：修复ROCm上GPT-OSS MXFP4的回归问题
    • 解读：此PR修复了因代码重构导致的AMD平台上GPT-OSS模型性能回归和崩溃问题。它细致地恢复了针对特定GFX架构的后端选择逻辑、对齐要求检查和必要的padding参数传递。
    • 影响：确保了GPT-OSS模型在AMD最新硬件（如MI300）上的功能正确性和性能，是维护跨平台模型支持的关键操作。
  4. PR #38011 (进行中)：为OpenAI API添加批处理消息支持
    • 解读：扩展了/v1/chat/completions端点，使其能够接受一个消息列表的列表，从而在单个请求中处理多个独立的对话，并支持与结构化输出等功能结合。
    • 影响：提高了API的效率和灵活性，尤其适用于需要批量处理多个提示并提取结构化数据的场景，减少了HTTP开销。

📈 开发活跃度观察

💡 值得关注的问题

  1. Ampere架构的长期支持策略：Issue #38006引发的讨论需要社区明确。是否以及如何为旧硬件（如A100）提供对新模型架构（如稀疏MLA）的兼容性支持，将影响一部分用户群体的技术选型。
  2. Qwen3.5 MoE大规模模型稳定性：集中出现的问题（Pipeline Parallelism、ROCm输出异常、Tokenizer）表明对此类超大规模MoE模型的全面支持仍需打磨，是影响生产部署稳定性的关键区域。
  3. 多平台内核维护负担：从PR #37987和多个ROCm修复PR可见，维护针对CPU、AMD、NVIDIA等多套后端的算子实现和策略选择，复杂性和维护成本正在增加。如何优雅地管理这种复杂性是一个长期挑战。
  4. MTP等高级功能在高并发下的稳定性：Issue #36613虽已关闭，但多令牌预测、推测解码等高级功能在高负载下的健壮性，仍是实现极致性能时需要持续验证的重点。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR