View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

vLLM 开发动态报告 - 2026-02-13

时间窗口: 2026-02-13 11:23 (UTC+8) ~ 2026-02-14 11:23 (UTC+8) 数据统计: 新 Issue 19 | 关闭 Issue 15 | 新 PR 43 | 合并 PR 26 | 关闭未合并 PR 7

📊 每日开发状态摘要

在2026年2月13日至14日的周期内，vLLM项目保持了较高的开发活跃度，共处理了43个新增PR和19个新增Issue。核心开发焦点集中在多模态模型支持、性能优化与Bug修复，以及AMD ROCm平台生态的持续完善上。社区正在积极推进多个关键技术特性的落地，包括新的推理输出功能、更高效的CPU权重卸载方案，并对近期引入的MoE重构和AOT编译等重大变更进行问题排查与优化。

🎯 AMD/ROCm 生态相关动态

本周期内AMD/ROCm生态的进展和问题修复较为活跃，体现了社区对该平台支持的持续投入。

  1. 问题修复与解决方案：
    • Issue #34500 ([Bug]: AMD 7900 running GLM-4.7-Flash crash)：用户报告在AMD Radeon PRO W7900D上运行GLM-4.7-Flash模型时崩溃。AMD员工 @vllmellm 迅速介入，指出问题与Triton后端相关，并建议设置环境变量 export FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE 以启用Triton for AMD。用户确认该方案有效，随后关闭了Issue。这表明针对特定AMD GPU型号，需要正确配置后端以获得兼容性。
    • PR #34543 ([Bugfix] Fix ROCm UVA CPU weight offloading broken by #32993)：这是一个关键修复。之前的PR #32993为CPU权重卸载添加了UVA支持，但仅在Python层检查了CUDA和XPU平台，导致在ROCm平台上抛出ValueError。此PR将current_platform.is_rocm()添加到检查条件中，确保ROCm平台能使用相同的UVA代码路径，修复了由此导致的CI测试失败。
    • PR #34538 ([ROCm][CI] Guard sparse MLA backend imports for ROCm compatibility in tests)：修复了ROCm CI中因无条件导入依赖flashinfer的FlashInferMLASparseBackend而导致的测试收集失败问题。通过动态构建测试列表，提升了测试套件在ROCm环境下的健壮性。
  2. 新功能与优化：
    • PR #34541 ([ROCM] Optimize ROCM_AITER_FA spec decode eagle performance)：旨在优化ROCm AITER FA后端在推测解码（EAGLE）场景下的性能。通过更改cuda_graph支持和移除CPU-GPU同步，使cudagraph也能用于草稿模型，从而提升性能。该PR依赖于另一个修复精度的PR (#32877)，目前存在合并冲突待解决。
    • PR #34515 ([Draft] amd-quark online fp8 and mxfp4 quantization)：一个由AMD员工 (@hangy-amd) 提交的草案PR，旨在将AMD Quark工具的在线FP8和MXFP4量化功能集成到vLLM中。这是AMD生态量化工具链整合的重要一步。
  3. 其他关联动态：
    • 已关闭的Issue #33678 ([Bug]: [ROCm] Kimi-K2.5 produces incorrect results on AMD MI308X) 和 #28494 ([Bug][AMD gfx1100] Enabling include_usage with stream=True results in freeze after 3 iterations) 表明，社区持续跟踪并解决了AMD平台上模型精度和API稳定性的历史问题。
    • 贡献者识别：本周期内活跃的AMD员工（用户名带 -amd 后缀）包括 @hangy-amd 和 @vivcheng-amd（在已关闭Issue中），显示了AMD团队对vLLM项目的直接贡献。

💬 高热度讨论分析

  1. Issue #32791 ([Bug]: chat.completions returns content: null for GPT-OSS multi-turn with json_object)：
    • 核心议题：用户在使用GPT-OSS系列模型进行多轮对话并结合json_object等结构化输出时，服务器返回content: null。
    • 观点与讨论：多位用户确认此问题，并发现仅在使用结构化输出且对话历史中包含助理消息时触发。讨论提出了多种临时解决方案，如降级vLLM版本、修改历史消息角色、在提示前添加随机字符串等。社区最终定位到根本原因是 gptoss_reasoning_parser 中的逻辑在多轮场景下错误地匹配了历史消息中的结束标记，导致提前应用了语法掩码。
    • 最终结论：在PR #34454中，通过修复解析器逻辑，确保仅在当前生成的消息中寻找结束标记，彻底解决了此问题。该PR已合并。
  2. Issue #29403 ([Bug]: fastsafetensors in tensor parallel requires too much VRAM)：
    • 核心议题：在张量并行模式下使用fastsafetensors插件加载模型时，出现VRAM使用量激增甚至加载失败的问题。
    • 观点与讨论：问题提出者怀疑fastsafetensors将所有权重加载到了GPU 0上，而非正确分散。贡献者 @bbrowning 通过调试证实了这一点，并指出这可能是一个bug。讨论涉及了对系统内存和GPU内存影响的分析，以及一个潜在的修复方案。
    • 当前状态：该Issue在数据周期内被关闭，但关闭原因未在提供的数据中明确显示（可能是通过其他PR修复或决定暂时规避）。这反映了社区对第三方依赖集成稳定性的关注。
  3. Issue #33804 ([RFC]: [compile] Rollout strategy for AOT Compilation.)：
    • 核心议题：讨论如何安全地推出Torch 2.10中的AOT编译功能，避免给用户带来问题。
    • 观点与立场：
      • 谨慎推出派：鉴于在测试中发现了与AOT相关的阻塞性问题，建议采取保守策略。
      • 具体方案：讨论了“在下一个vLLM发布版本中默认关闭AOT，待其在主分支充分测试后再于下下个版本启用”的方案。
    • 最终结论：核心维护者达成一致，决定在即将发布的vLLM 0.16版本中搭载PyTorch 2.10但默认关闭AOT编译，在发布后立即在主分支开启AOT，以便在下一个版本（0.17）发布前有充足时间暴露和修复问题。该RFC已关闭。

🔥 热门话题与趋势分析

  1. 多模态模型支持深化：围绕GLM-OCR、Qwen-VL等模型的Issues（#34040, #34502, #34506）表明，用户正将vLLM用于复杂的视觉语言任务，如图像-文本检索、OCR和视觉推理。社区正在积极解决由此带来的新挑战，如编码器缓存预估不准确和多模态API功能扩展（如#34518请求为Whisper API添加解码器前缀支持）。
  2. 推理输出与工具调用支持：Feature Request #34536 希望为离线推理添加推理输出支持，而Issues #34496, #34498 则涉及推理和工具调用API的健壮性修复。这表明vLLM的高级功能（结构化输出、推理、工具调用）正被更广泛地使用，其稳定性和易用性成为关注重点。
  3. 性能优化与核心Bug修复：
    • MoE性能回归：PR #34279 为修复IMA错误将步长改为int64，却导致小显存GPU（如GB10）上性能严重下降（~60x）。这引发了快速回滚（PR #34530）和针对性修复（PR #34507）的紧急行动，凸显了性能调优的复杂性。
    • 缓存与加载优化：PR #34527 修复了多模态处理器加载的LRU缓存失效问题，显著提升了预处理速度；PR #34498 优化了GDN元数据构建，避免CPU-GPU同步。
  4. 平台兼容性与部署：除了AMD ROCm，关于macOS多进程问题（#34534）、Python 3.13兼容性问题（#34504）以及CPU卸载内存占用（#32993）的讨论，反映了社区对跨平台、多样化部署场景支持的持续努力。

🛠️ 重点技术变更

  1. PR #34454 ([Bugfix]: Fix structured output in multi-turn gpt-oss)：此PR修复了GPT-OSS模型在多轮对话中使用结构化输出时的一个关键缺陷。通过修正gptoss_reasoning_parser中识别推理结束标记的逻辑，确保了语法约束仅在正确的时机应用，恢复了模型生成有效内容的能力。影响：显著提升了GPT-OSS系列模型在生产环境多轮交互场景下的可用性和可靠性。
  2. PR #32993 ([Feature] Support CPU Offloading without Pytorch Pinned Memory that leads to doubled allocation) (已合并)：解决了PyTorch固定内存分配可能引起内存翻倍的问题，引入了基于UVA的CPU卸载替代方案，并通过环境变量控制。影响：使大模型在CPU卸载场景下对系统内存的需求变得更可预测和高效，尤其有利于资源受限的环境。
  3. PR #33705 ([Hybrid] Enable spec decoding in mamba cache align mode) (已合并)：重新启用了Mamba模型在缓存对齐模式下的推测解码支持，此前因相关问题被禁用。影响：为Jamba等混合模型（Mamba+Attention）解锁了推测解码这一重要的性能加速特性。
  4. PR #34523 ([Misc] vLLM‘s –enforce-eager should turn off compile and cudagraphs only) (已合并)：将--enforce-eager调试标志的行为从设置优化级别-O0改为仅关闭torch.compile和cudagraphs，保留其他优化。影响：使调试行为更精确，避免因关闭其他优化（如flashinfer自动调优）而引入额外的性能偏差，便于问题定位。

📈 开发活跃度观察

💡 值得关注的问题

  1. 多模态模型缓存估计：Issue #34040 和其修复PR #34483 揭示了一个普遍性问题：多模态编码器的缓存需求预估方法（特别是针对单张图片）可能存在缺陷，容易导致运行时错误。需要检视其他多模态模型是否存在类似隐患。
  2. Python 3.13 兼容性：Issue #34504 指出因符号_PyThreadState_UncheckedGet未定义导致vLLM在Python 3.13上崩溃。这是一个影响新版本Python用户的环境兼容性问题，需要尽快修复。
  3. 实时API的健壮性：Issue #34532 报告Realtime API在客户端非正常断开连接时服务器会崩溃。这关系到API的生产环境稳定性，提出的将断言改为运行时错误验证的建议值得采纳。
  4. 分散式推理的复杂性：Issue #34526 报告在使用Nixl+CPU Offloading等多连接器组合时出现精度问题。这反映了在追求极致的分散式/异构推理架构时，调试和保证正确性的难度极高，相关功能需要更完善的测试和验证手段。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR