View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2026-03-03 11:21 (UTC+8) ~ 2026-03-04 11:21 (UTC+8) 数据统计: 新 Issue 30 | 关闭 Issue 18 | 新 PR 94 | 合并 PR 38 | 关闭未合并 PR 28

📊 每日开发状态摘要

本周期内（2026-03-03至2026-03-04），vLLM社区保持高活跃度，新增94个PR和30个Issue，合并38个PR。开发焦点集中在性能优化、错误修复和新功能集成上。一个显著趋势是针对特定硬件（尤其是AMD ROCm平台）和特定模型系列（如Qwen）的深度优化与问题排查，同时分布式执行器后端的重构、实时流媒体API和KV缓存管理等核心架构议题也引发了热烈讨论。

🎯 AMD/ROCm 生态相关动态

本周期AMD生态相关活动非常活跃，主要体现在性能优化、Bug修复和工具链支持上。

新增Issue（AMD相关）:

新增PR（AMD相关）:

分析: AMD团队（以-amd后缀用户为代表）正在vLLM上密集开展优化工作，重点在三个方面：1) 通过AITER集成提升核心算子（注意力、线性层、MOE、RoPE）在MI系列GPU上的性能；2) 深化其Quark量化工具链与vLLM的整合，支持新的数据类型（NVFP4）和优化工作流（AOT反量化）；3) 持续修复在复杂模型（Qwen系列）和配置（高TP值）下暴露的兼容性与正确性问题。近期关于AITER导致模型输出质量下降的两个严重Bug需要高度关注。

💬 高热度讨论分析

  1. Issue #35848: [RFC]: Revamp Ray Distributed Executor Backend (from Ray team)
    • 核心议题: Ray团队提议弃用当前基于Compiled Graph的RayExecutor，改用新的RayExecutorV2。新设计将采用与MultiprocExecutor相同的控制平面（ZMQ/SHM MessageQueue）和数据平面（torch.distributed NCCL），但利用Ray Actor实现跨节点并行和细粒度资源调度。
    • 不同观点:
      • 提问方 (robertgshaw2-redhat): 质疑如果新后端复用MultiprocExecutor的组件，其独特价值何在？是否真的需要vLLM内部集成资源调度。
      • 解释方 (kouroshHakha, jeffreywang-anyscale): 阐述了深度集成的优势：1) 简化部署：用户只需一个命令行即可启动跨集群服务，无需复杂的“headless + driver”设置；2) 与Ray编排器协同：当vLLM与Ray Data、Ray Serve等协同工作时，Ray可以精细控制GPU工作进程的放置，实现资源感知调度和弹性伸缩，这是外部编排器（如K8s）难以做到的。
    • 当前状态: 讨论已达成基本共识，认为重构方向合理，可以统一代码、减少对难以调试的Ray功能（如DAG）的依赖，提升用户体验和功能支持。RFC处于开放状态。
  2. PR #35852: [Scheduler] Fix KV-cache head-of-line blocking
    • 核心议题: 修复V1调度器中因KV缓存不足导致的队头阻塞问题，确保大型请求不会不必要地阻塞后续可运行的小型请求。
    • 不同观点:
      • PR作者 (oneraghavan): 提出三处关键修改，旨在让调度器在单个请求分配KV缓存失败后继续尝试调度其他请求，而非直接中断整个调度循环。
      • 审阅者 (orozery): 赞同修复特定用例（一个大请求阻塞多个小请求）的初衷，但担心这种改变可能对追求高吞吐、希望通过减少运行序列数来缓解KV缓存压力的通用工作负载产生负面影响。特别指出，修改“运行中请求”的调度逻辑可能导致重请求被持续饥饿。
    • 争议焦点: 在优化混合工作负载的公平性与延迟和维护通用工作负载的吞吐与缓存效率之间寻求平衡。审阅者认为原调度器的“中断”行为是为了保护刚刚通过重调度腾出的缓存空间，使其能用于原请求的后续尝试。
    • 最终结论: 经过深入讨论，作者承认审阅者的担忧有道理，特别是改变“运行中请求”的调度逻辑可能引发饥饿问题。该PR已被关闭，表明社区倾向于更保守的调度策略，或在更全面的评估后再进行此类核心调度逻辑的修改。
  3. PR #35930: [Model Runner V2] Use dictionary instead of tuple for execute_model_state
    • 核心议题: 随着execute_model_state的不断扩展，提议将其从元组改为字典，以提升可读性和降低错误率。
    • 不同观点:
      • PR作者 (WoosukKwon): 认为这只是连接两个方法（prepare_inputs和execute_model）的中间通道，希望保持其一定的“hacky”特性，不将其视为模型运行器的标准部分。
      • 审阅者 (njhill): 建议使用数据类或命名元组以获得强类型和明确性，认为明确指定两个阶段之间传递的状态会更利于代码的阅读和维护。
    • 当前状态: 讨论反映了在代码灵活性/简易性与类型安全/可维护性之间的权衡。作者倾向于保持字典形式，审阅者表示尊重但持不同意见。PR仍处于开放状态。

🔥 热门话题与趋势分析

  1. Qwen模型家族的深度集成与问题：Qwen（特别是3.5、3-VL、Next版本）是当前最活跃的模型支持领域，但也是问题高发区。本周期出现了AITER兼容性导致输出损坏/精度下降、GatedDeltaNet (GDN) 层的CUDA图捕获AssertionError、视频输入时间戳处理Bug、Marlin量化与TP的兼容性问题等多个Issue。这反映了vLLM在支持复杂、新颖的模型架构时面临的挑战。
  2. 多媒体与实时流处理：关于模型特定的实时音频流抽象的RFC（#35908）和Qwen3-VL视频输入处理的Bug报告（#35909），表明多模态和低延迟流式输入正成为重要的功能前沿和测试焦点。
  3. 分布式与执行后端演进：除了Ray后端的RFC，还有关于统一引擎进程监控的RFC（#35858）和对应PR（#35862），旨在为弹性扩展和容错奠定基础。这显示了vLLM在向更稳定、更灵活的生产级分布式系统迈进。
  4. 响应API（Responses API）的增强与插件化：多个PR（#35903, #35905, #35904, #35906）致力于扩展响应API的功能，如支持无状态多轮对话、可插拔的响应存储后端、处理Harmony协议令牌泄漏、整合结构化输出与推理。这表明OpenAI Responses API兼容性正变得日益重要和复杂。

🛠️ 重点技术变更

  1. PR #35601 (已合并): [ROCm][Bugfix]: Disable AITER Triton ROPE by default。此PR部分回滚了之前的优化，因为在某些大批次场景下，AITER的RoPE实现性能比原生实现差25%。这反映了性能优化需要针对具体工作负载进行细致调优和权衡，默认启用的激进策略可能导致用户遭遇性能回归。
  2. PR #34552 (已合并): [BugFix] Add support for MTP num_speculative_tokens > 1 with sparse MLA。修复了GLM-5等使用稀疏MLA注意力模型在多令牌推测解码（MTP）时崩溃的问题。推测解码对复杂注意力模式的支持仍是技术难点，此修复扩展了推测解码的适用模型范围。
  3. PR #35838 (已合并): Enable bnb for multiple indices weight。修复了bitsandbytes量化在加载具有多分片索引的融合权重时崩溃的问题。这提升了4-bit量化在更广泛模型上的可用性，对资源受限的部署场景有积极意义。
  4. Issue #35925 (进行中): [Bug]: Qwen3.5-35B-A3B generates corrupted responses when AITER is enabled。这是一个严重的正确性问题，表明AMD的AITER优化与Qwen3.5的某些特性存在冲突。根本原因可能是注意力、MOE或RoPE内核在特定输入模式下的数值错误，需要AMD团队优先调查。

📈 开发活跃度观察

💡 值得关注的问题

  1. AITER的稳定性与模型兼容性：Issue #35925和#35828揭示了AITER优化可能导致严重的模型输出质量问题。这需要AMD团队紧急修复，并考虑建立更完善的模型-硬件-优化组合的回归测试集。
  2. Ray分布式后端的未来：RFC #35848提出的重构是一项重大架构变更，虽然得到初步认可，但其实现细节、对现有用户的影响以及性能表现需要后续PR的严密跟踪。
  3. 实时流媒体API的设计：RFC #35908提出的“模型特定实时流抽象”试图解决当前协议过于简单、导致模型逻辑渗入共享层的问题。其设计选择（扩展协议、增加参数或创建新的引擎API）将影响未来所有ASR/实时音频模型的集成方式。
  4. 复杂模型架构的持续挑战：从Qwen的GDN、Mamba到各种稀疏注意力、MOE模型，vLLM需要不断适配快速演进的模型架构，这对其内核实现、调度器和量化支持都构成了长期压力。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR