View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

vLLM 开发动态报告 - 2025-12-11

时间窗口: 2025-12-11 10:48 (UTC+8) ~ 2025-12-12 10:48 (UTC+8) 数据统计: 新 Issue 15 | 关闭 Issue 23 | 新 PR 68 | 合并 PR 45 | 关闭未合并 PR 27

📊 每日开发状态摘要

在2025年12月11日至12日的24小时内，vLLM项目保持了极高的开发活跃度，合并了45个PR并处理了38个Issue。开发焦点集中在性能优化、内存管理、对新硬件（如Blackwell Ultra）的支持以及对近期热门模型（如DeepSeek-V3.2、GPT-OSS）的问题修复上。AMD/ROCm平台的支持工作主要体现在持续集成（CI）的测试完善和特定内核的适配上。

🎯 AMD/ROCm 生态相关动态

本周期内，直接的AMD功能开发PR较少，主要工作集中在CI测试的完善和问题修复上：

  1. CI与测试适配：
    • PR #30508 (已合并) 与 PR #30417 (已合并)：由AMD贡献者（rasmith）提交，分别跳过了ROCm不支持的cutlass_w4a8_moe测试和缺少特定模块（如deep_ep）的融合测试，确保ROCm测试流水线能够顺利通过。
    • PR #30526 (已合并)：将V1 e2e测试的代理池从mi325_1调整为mi325_4，以确保多GPU测试有足够的硬件资源。
    • PR #30527 (开放中)：计划为ROCm环境下的推测解码多GPU测试添加GPU可用性检查，防止因资源不足导致的测试失败。
  2. Issue 追踪关闭：
    • Issue #14964 (已关闭)：追踪AMD AITER内核集成的总览性Issue被维护者主动关闭，因其“过于陈旧”，并建议相关方开新的追踪器。
    • Issue #22698 (已关闭)：关于MI300/MI308上CUDA图运行末尾存在“气泡”的性能问题。经AMD工程师（vllmellm）确认，在最新的rocm/vllm-dev:nightly镜像中此问题已不复现，故关闭。
  3. Bug修复与支持确认：
    • Issue #28184 (已关闭)：关于Whisper编码器-解码器模型在vLLM 0.11与ROCm上不工作的问题。AMD工程师确认相关PR已合并，在最新nightly镜像中问题已解决。

分析：本周期AMD生态的动态以“稳”为主，侧重于确保现有功能在CI中的稳定性和修复已知问题，而非引入新功能。关闭历史遗留的追踪Issue也表明项目在梳理和优化问题管理流程。

💬 高热度讨论分析

  1. Issue #30453: DeepSeek-V3.2 频繁重复解码问题
    • 核心议题：用户报告在H200上部署DeepSeek-V3.2时，遇到严重的重复解码（Repetitive Decoding）问题。
    • 观点与进展：
      • 提问者 makabaka6338 提供了极其详尽的环境信息和请求脚本。
      • 其他用户 mondaylord 和 niceallen 表示遇到类似问题（流响应首token被截断或“+1”）。
      • 讨论焦点迅速转向环境版本排查。用户 h1248759474 反复询问具体的依赖包版本，提问者最终列出了完整的pip list输出。
    • 当前状态：问题仍为 Open。讨论尚未涉及根本原因分析，目前停留在信息收集和确认共性现象阶段。
  2. Issue #30498: GPT-OSS-120B 在达到 max_tokens 时返回空内容
    • 核心议题：用户发现GPT-OSS-120B模型在预热后（即命中前缀缓存后），即使max_tokens设置得足够大，返回的content字段也为null，而使用--enforce-eager标志可以规避。
    • 观点分析：
      • 用户视角 (ashtarkb): 提供完整复现步骤，认为这是一个Bug。
      • 初步解释 (alew3): 认为如果推理（reasoning）用完了所有令牌配额，content为空是预期行为，并建议改进检查代码。
      • 深度分析 (bbrowning): 指出这很可能与Issue #26480是同一个Bug——即命中前缀缓存后，CUDA图可能导致无限生成token id 0。--enforce-eager有效是因为它禁用了CUDA图。这个观点得到了提问者的认可。
    • 当前状态：问题仍为 Open。讨论指向一个已知的、与缓存和CUDA图相关的核心Bug，需要更深层的修复。
  3. Issue #30521: Flashinfer 后端内存分析回归 (DP > 1)
    • 核心议题：在数据并行（DP>1）时，使用Flashinfer后端的vLLM 0.12.0在内存分析（profiling）阶段存在回归，可能导致OOM。
    • 观点分析：
      • 报告者 nrghosh 自己进行了深入分析，指出问题关键在于：内存分析在CUDA图捕获和采样器预热之前运行，因此未计入这部分内存（特别是Flashinfer较大的工作区缓冲区），导致KV缓存分配过大。
      • 他提出了几个思考方向：1) 在计算KV缓存前为采样器预热预留内存；2) 使用更小的预热批次；3) 探究Flashinfer CUDA图内存使用是FlexAttention两倍的原因。
    • 当前状态：问题仍为 Open。这是一个由经验丰富的贡献者提出的、带有自我分析的深度技术讨论，直接指向内存管理流程的核心逻辑。
  4. Issue #30139 (已关闭): 推理模型不进行推理，将结果全放入 reasoning_content
    • 核心议题：多个用户报告Mistral Ministral等推理模型在vLLM中未正确分离推理和回答内容。
    • 观点与结论：
      • 用户困惑：多个用户确认了此问题，影响Ministral、MiniMax-M2等模型。
      • 根本原因：Mistral的推理解析器（MistralReasoningParser）最初借鉴了DeepSeek V1的实现，包含了一些启发式规则（如没有开始标签则全视为推理），这不适合Mistral模型可切换“聊天/推理”模式的特性。
      • 解决方案：Mistral员工 juliendenize 提交了 PR #30391，改进了解析器的逻辑，使其更符合Mistral模型的行为。该PR已合并并解决了此问题。
    • 最终结论：通过上游模型提供方的直接贡献，问题得到修复。这体现了社区与模型开发商合作的高效性。

🔥 热门话题与趋势分析

  1. 新模型支持与问题：DeepSeek-V3.2 和 GPT-OSS-120B 是绝对的焦点，相关Issue讨论热烈。这反映出社区快速采用前沿大模型，同时vLLM在适配这些架构复杂的新模型时面临挑战（如重复解码、缓存Bug）。
  2. 部署与硬件适配：
    • 新硬件：PR #30484 开始为 NVIDIA Blackwell Ultra (SM103) 添加初始支持。
    • CPU后端：针对 Arm CPU 的构建问题（Issue #30470）和性能优化（Issue #30487，L2缓存检测）受到关注，显示移动端和边缘计算场景的重要性。
    • 安装问题：如何离线或高效使用预编译wheel（Issue #30464）是实际部署中的常见痛点。
  3. 性能与内存优化：这始终是vLLM的核心议题。本期围绕CUDA图内存估算（PR #30515）、编码器缓存内存占用（PR #30452, #30475）、Triton内核split_k设置（PR #30528）的讨论，都是对极致性能的追求。
  4. 推理与工具调用：关于如何禁用Qwen模型的“思考”（Issue #30477），以及推理模型输出解析（Issue #30139, #28852）的讨论，说明“推理”和“工具调用”已成为LLM应用的高级特性，对其可靠控制的需求强烈。

🛠️ 重点技术变更

  1. PR #30515: 在内存分析中计入CUDA图占用：这是一个重要的改进。通过在内存分析阶段进行一次小的、假的CUDA图捕获，来预估其真实内存占用，从而更准确地计算可用的KV缓存空间。这将有效减少因低估CUDA图内存而导致的启动后OOM问题，对于DeepSeek-R1等大模型在极限配置下稳定运行至关重要。
  2. PR #30452 / #30475: 优化编码器缓存内存使用：这两个关联PR针对多模态模型的编码器缓存进行了重构。通过仅存储实际的嵌入向量而非完整的占位符张量，实现了高达12.5倍的内存节省。这使得如Qwen3-VL等大型视觉模型能够在有限的GPU内存下支持更长的上下文或更多视频帧，是多模态推理能力的关键提升。
  3. PR #30484: 添加SM103 (Blackwell Ultra) 支持：为未来的NVIDIA B300/GB300系列GPU添加了初始支持。虽然需要配合Triton补丁，但这是保持vLLM在最新硬件上领先地位的必要步骤。
  4. PR #30528: 为Triton内核设置 split_k=1：针对Hopper架构（SM90）的性能调优。通过强制设置split_k=1，避免小批次推理时Triton内核回退到float32精度，从而提升小批次场景下的推理速度。这体现了对真实生产场景中多样化负载的精细化优化。
  5. PR #30389: 标准化 RoPE partial_rotary_factor 获取：一个重要的底层重构，统一了从配置中获取旋转位置编码维度的方式，全部改为通过rope_parameters[“partial_rotary_factor”]。这解决了因社区量化模型配置不一致（如MiniMax-M2）导致的加载失败问题，提升了模型的兼容性和鲁棒性。

📈 开发活跃度观察

💡 值得关注的问题

  1. DeepSeek-V3.2重复解码 (Issue #30453)：作为最新发布的热门模型，其部署稳定性至关重要。此问题影响广泛，需要优先调查是否与vLLM的调度或缓存逻辑存在特定交互问题。
  2. GPT-OSS-120B缓存与CUDA图Bug (Issue #30498)：被关联到一个已知的深层Bug（#26480）。这个问题会影响所有命中前缀缓存的请求，导致输出质量严重下降，是需要彻底解决的核心稳定性问题。
  3. NIXL解耦服务在流水线并行下的握手错误 (Issue #30501)：用户尝试在复杂配置（TP=8, PP=2）下运行DeepSeek-R1的分解式服务遭遇失败。这揭示了高级分布式特性在边界用例下的兼容性问题，对于推动大规模模型服务技术有重要参考价值。
  4. Flashinfer后端内存分析 (Issue #30521)：该讨论揭示了当前内存分析流程的一个潜在缺陷——未能充分考虑不同后端（Flashinfer vs FlexAttention）在CUDA图和工作区内存上的差异。这可能需要一个更通用、更精准的内存预测框架。

📋 附录：详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR