View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-03-27 11:31 (UTC+8) ~ 2026-03-28 11:31 (UTC+8) 数据统计: 新 Issue 18 | 关闭 Issue 11 | 新 PR 83 | 合并 PR 27 | 关闭未合并 PR 29

📊 每日开发状态摘要

本周期（2026-03-27至2026-03-28）vLLM 项目保持高强度开发，新增 83 个 PR 和 18 个 Issue，合并了 27 个 PR。核心进展集中在 AMD/ROCm 生态的性能优化与问题修复、Transformers v5 升级带来的大规模兼容性调整，以及多模态功能与缓存管理的持续改进。社区协作活跃，多名贡献者积极认领了为适配 Transformers v5 而分解出的若干“good first issue”。

🎯 AMD/ROCm 生态相关动态

本周期 AMD 生态相关活动非常活跃，主要集中在性能优化、构建系统修复和文档更新。

  1. 新增 Issue (性能问题):
    • #38406 [Bug]: vllm 0.18 kimi k2.5 way worse than h200 single node：用户 functionstackx（频繁提交 AMD 相关报告）指出，即使在启用 VLLM_ROCM_USE_AITER=1 后，MI325X 运行 Kimi K2.5 模型的性能依然显著低于 NVIDIA H200。此问题已引发 AMD 员工（@chunfangamd， @andyluo7， @hongxiayang）和社区的关注，是当前 ROCm 性能调优的重点。
    • #38303 [Bug]: minimax nvfp4 model crash：内容被截断，但从标题看涉及 NVFP4 量化模型，可能关联 AMD 的 Quark 量化工具链。
  2. 新增与合并的 PR:
    • #38367 (已合并) [ROCm][Documentation] update quickstart and installation to include rocm nightly docker tips：由 AMD 员工 hongxiayang 提交，更新了官方文档以包含 ROCm nightly Docker 镜像的使用说明，提升了用户体验。
    • #38365 [ROCm] patch benchmark_moe：修复 benchmark_moe.py 脚本以兼容 ray==2.54.0，该版本不再使用 ROCR_VISIBLE_DEVICES 环境变量。
    • #38346 [ROCM] Optmize redudent d2d copy of moe.：优化了 MI355 上运行 MiniMax M2.5 模型时 MOE 内核的输出路径，消除了冗余的 D2D 拷贝，展示了针对特定 AMD 硬件和模型的深度优化。
    • #38337 [ROCm][Build] Fix pip install detection when build isolation installs CUDA PyTorch：修复了在 ROCm 系统上使用 pip 构建时，因构建隔离环境安装了 CUDA 版 PyTorch 而导致的错误检测问题。
    • #38334 [ROCm] Use Triton attention fallback for ViT to avoid SDPA OOM：为 Vision Transformer 注意力后端添加 Triton 回退路径，以解决在不支持高效 SDPA 的 ROCm 设备（如 gfx906）上运行多模态模型时的 OOM 问题。
    • #38413 [ROCm] [Release] Update ROCm variant from rocm700 to rocm721：将基础镜像版本从 ROCm 7.0.0 升级至 7.2.1，是 #38252 的后续工作。
    • #38371 Enable building MoRI with AMD AINIC stack：更新 ROCm 基础镜像构建，支持使用可选的 AMD AINIC (Pensando) 网卡栈构建 MORI，面向 disaggregated/KV 卸载场景。
    • #38396 [AMD][CI] Update DeepEP branch：更新 DeepEP 分支以正确为 gfx942/gfx950 进行预编译，并调整测试用例到 MI325。
    • #38415 [ROCm][CI] Fix UV install in Dockerfile.rocm to detect curl failures and retry：修复 Docker 构建中 UV 安装脚本，使其能检测 curl 失败并重试。
  3. 其他相关 PR:
    • #38317 [ROCm][CI] Enable hybrid chunked prefill test：在 ROCm CI 中启用混合分块预填充测试，移除了原有的 CUDA 专属跳过标记。
    • #38381 [ROCm][CI] Pin test_hybrid test to TRITON_ATTN on ROCm：将 test_hybrid.py 测试在 ROCm 上固定使用 TRITON_ATTN 后端，以减少批处理差异导致的测试不稳定性。

分析：AMD 团队（通过 -amd 后缀用户识别）在本周期投入显著，工作覆盖性能调优（#38406， #38346）、构建系统健壮性（#38337， #38415）、CI/CD 完善（#38317， #38381）和用户体验（#38367）。特别是针对 MI300 系列（MI325， MI355）的性能问题和新硬件（AINIC）的支持，表明 AMD 正致力于在 vLLM 上构建完整且高性能的软件生态。

💬 高热度讨论分析

  1. Issue #38374: IPC update_weights (checkpoint format): hot-swapped weights can diverge from cold load
    • 核心议题：使用 IPC（CUDA 进程间通信）以检查点格式热更新模型权重后，推理结果与冷启动目标检查点服务器的结果不一致。
    • 观点与进展：提交者 kimihailv 提供了非常详细的复现步骤和结果对比，显示热交换后的模型行为更接近原始模型而非目标模型。该 Issue 在创建后约 14 分钟内被迅速关闭，表明可能是一个可快速定位和修复的 bug，或已被其他 PR 解决。
  2. Issue #38375: IndexError when --renderer-num-workers + --mm-processor-cache-type shm
    • 核心议题：多模态渲染器工作线程 (--renderer-num-workers > 1) 与共享内存多模态缓存 (--mm-processor-cache-type shm) 不兼容，导致高并发下 IndexError。
    • 观点与争议：scyyh11 迅速定位了问题根源：SHM 缓存设计假设单写入者，而多渲染器工作线程导致了并发写入。他提出了临时解决方案（设置 --renderer-num-workers=1），并询问原 PR（#34789）作者 @DarkLight1337 是应该丢弃 renderer_num_workers 配置还是修复 SHM 缓存路径本身。争议焦点在于功能兼容性与设计修改的权衡。
    • 当前状态：待维护者决策。
  3. Issue #38382: [Transformers v5] Mistral multimodal models
    • 核心议题：升级至 Transformers v5.4 后，Mistral 多模态模型（Pixtral， Voxtral）因处理器重构而出现 IndexError。
    • 观点与进展：hmellor 指出问题源于 #38018 PR 使用 v5.3 开发，而 v5.4 重构了处理器。allgather 主动认领此问题。这反映了大型上游依赖更新对下游项目造成的广泛影响。
    • 当前状态：allgather 已提交修复 PR #38410。
  4. Issue #38387: [Transformers v5] HCXVisionForCausalLM
    • 核心议题：Transformers v5 升级导致 HCXVisionForCausalLM 模型初始化失败 (AttributeError: 'HCXVisionConfig' object has no attribute 'text_config')。
    • 观点与进展：HanFa 指出可能与 Transformers 的一个 PR 相关。hmellor 认为问题可能在于模型配置代码本身的缺陷，并鼓励 HanFa 尝试修复。这体现了社区协作解决上游变更问题的模式。
    • 当前状态：HanFa 已认领。
  5. PR #38315: [Perf][GDN] Fuse kkt + solve_tril kernels in chunk forward
    • 核心议题：为 Gated Delta Network (GDN) 融合 KKT 和 solve_tril 内核以提升预填充性能。
    • 观点与争议：PR 展示了对 H200 上 Qwen3.5-397B 模型 TTFT 的显著提升。然而，贡献者 Nepherpitou 报告在 4x3090 上测试 Qwen 122B AWQ 模型时出现了输出损坏（!!!!!!!!!!!!!）。作者 ZJY0516 回应未能复现，并请求更多信息。争议焦点在于更改的准确性和硬件/模型泛化能力。
    • 当前状态：存在合并冲突，待解决并进一步验证准确性。

🔥 热门话题与趋势分析

  1. Transformers v5 升级浪潮：这是本周期最突出的趋势。hmellor 创建了总领 Issue (#38379) 并分解出多个子 Issue（如 #38386， #38387， #38389 等），吸引了大量社区贡献者（kasha01， HanFa， amitmodi 等）认领。问题涉及 tokenizer 配置、模型初始化、处理器兼容性等多个方面，是一次系统性的工程适配。
  2. 多模态功能深化与问题暴露：多个 Issue（#38375， #38382， #38385）和 PR（#38330， #38405）围绕多模态展开，涉及缓存并发、处理器兼容性、序列化协议等。这表明随着多模态特性被更广泛和复杂地使用，其底层架构的鲁棒性和扩展性正面临考验。
  3. 性能优化持续进行：针对特定硬件（AMD MI355， NVIDIA Blackwell）和模型架构（GDN， MLA， MoE）的深度性能优化 PR 不断涌现（如 #38346， #38354， #38315），体现了 vLLM 对极致推理效率的追求。
  4. AMD 生态支持力度加强：如前述，本周期 AMD 相关的修复、优化和文档更新非常密集，显示出 AMD 团队正系统性地提升 vLLM 在其硬件上的可用性和性能。

🛠️ 重点技术变更

  1. PR #38346 [ROCM] Optmize redudent d2d copy of moe.：此 PR 通过优化 MI355 上 MOE 内核的输出路径，消除了两次不必要的设备间（D2D）拷贝。这是针对特定硬件（MI300系列）和模型（MiniMax M2.5）的“外科手术式”优化，能直接提升端到端推理吞吐量，体现了平台专属优化的价值。
  2. PR #38334 [ROCm] Use Triton attention fallback for ViT to avoid SDPA OOM：该修改为 ROCm 设备上 ViT 的注意力计算添加了 Triton 回退路径，有效避免了 PyTorch SDPA “math” 后端因分配 N² 注意力矩阵导致的 OOM 问题。这对在 AMD 显卡上稳定运行多模态模型至关重要。
  3. PR #38337 [ROCm][Build] Fix pip install detection…：此修复解决了在 ROCm 系统上从源码构建时的一个隐蔽但影响很大的问题，提升了开发体验和构建可靠性，是完善 AMD 平台支持基础设施的关键一环。
  4. PR #34789 (已合并) [Bugfix] Offload blocking tokenizer ops to shared thread pool：此 PR 通过将阻塞性的 tokenizer 和多模态预处理操作卸载到共享线程池，解决了高并发下事件循环被阻塞导致的管理接口（如 /health）无响应问题。这是提升服务端稳定性和可观测性的重要改进。
  5. PR #37975 (已合并) [Model] Extract GatedDeltaNetAttention into shared layer：将 Qwen3Next 和 Qwen3.5 中的 GDN 层实现重构为独立的共享模块。这提高了代码复用性、可维护性，并为其他平台（如 XPU， NPU）实现定制化算子支持奠定了基础。

📈 开发活跃度观察

💡 值得关注的问题

  1. AMD MI325X 性能瓶颈：Issue #38406 中报告的 Kimi K2.5 在 MI325X 上性能远逊于 H200 的问题尚未解决，这可能是影响 AMD 数据中心 GPU 市场竞争力的关键性能问题，需要 AMD 团队持续重点关注和优化。
  2. Transformers v5 升级的连锁反应：虽然社区已积极介入修复，但此次升级暴露出的兼容性问题面广且深。需要密切关注后续是否还有隐藏问题，以及升级是否会对生产环境部署的模型稳定性造成影响。
  3. 多模态缓存与并发处理的根本矛盾：Issue #38375 揭示了当前多模态缓存设计与并发预处理之间的设计冲突。最终的修复方案（是限制功能还是重构缓存）将影响多模态服务的高并发能力。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR