View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

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

时间窗口: 2025-12-29 10:51 (UTC+8) ~ 2025-12-30 10:51 (UTC+8) 数据统计: 新 Issue 17 | 关闭 Issue 19 | 新 PR 35 | 合并 PR 20 | 关闭未合并 PR 43


📊 每日开发状态摘要

在2025年12月29日至30日的24小时窗口内,vLLM项目保持了极高的开发活跃度,共处理了超过70个Issue和PR。开发焦点集中在多模态模型支持扩展(特别是LoRA适配)、针对特定模型(如MiniMax-M2、DeepSeek-V3.2)的性能优化,以及持续修复各类平台(尤其是AMD/ROCm)的测试与稳定性问题。多项关键优化和功能(如异步调度默认启用、卷积层统一替换)被合并入主干,显示出项目在追求高性能与广泛兼容性上的持续进步。

🎯 AMD/ROCm 生态相关动态

本周期内AMD生态相关活动活跃,主要集中在性能问题修复和测试稳定性提升上。

  1. 关键性能问题报告 (#31475):
    • 议题:用户 ehartford 报告在8×MI300X上运行GLM-4.7和MiniMax-M2.1等MoE模型时,FP8推理速度显著慢于BF16,与预期不符(例如GLM-4.7 FP8 TPS ~30, BF16 TPS ~60)。此问题在vLLM和sglang上均复现,提示可能是ROCm平台上FP8实现路径的普遍性能问题。
    • 影响:这直接挑战了在AMD硬件上使用FP8进行高效推理的假设,对MI300X用户部署大型MoE模型有重大影响。问题已被标记为bugrocm,并自动通知了AMD相关维护者(@hongxiayang等)。
  2. ROCm平台Bug修复与优化(已合并PR):
    • PR #31502: 修复了近期代码重构导致的ROCm FP8静态量化问题,确保量化参数能被正确替换和加载。
    • PR #31499: 作为MoE重构的一部分,将 prepare_moe_fp8_layer_for_marlin 改为纯函数,提升了与量化权重重加载机制的兼容性。
    • PR #31460 / #31187: 修复了ROCm CI测试中的多个失败问题,包括将NIXL替换为RIXL,以及修正注意力测试。
    • PR #30719: 修复了GPTQ GEMM内核中因输出张量零值化竞争条件导致的数值错误,此问题在input_size > 128时更易触发。
  3. 尝试性优化(未成功) (#31487):
    • 贡献者尝试为ROCm添加一个融合的Triton LayerNorm内核,旨在减少内核调用次数和HBM访问,以提升类似BERT/ViT架构的性能。该PR被快速关闭,具体原因未说明,但体现了社区对AMD平台性能优化的关注。

小结:AMD生态的核心动态是一个严重的FP8性能回归问题被明确提出,同时开发团队在持续修复基础功能和测试套件的稳定性。MI300X上FP8性能劣于BF16的现象需要AMD和vLLM团队共同深入调查。

💬 高热度讨论分析

  1. Issue #31475: MI300X上FP8性能不及BF16
    • 核心议题:AMD MI300X GPU上FP8推理性能异常,速度反而不如更高精度的BF16。
    • 观点与进展
      • 报告者 (ehartford):提供了详细的测试环境、模型和可复现的数据,指出问题存在于vLLM和sglang两个项目中,暗示是ROCm底层实现的共性问题。
      • 社区/自动化:Issue被自动标记并通知ROCm维护团队。报告者进一步在sglang项目中验证并确认了相同现象,强化了问题根因在于ROCm平台的判断。
    • 当前状态:问题开放中,等待AMD或核心开发团队的深度技术分析。这是影响AMD平台竞争力的潜在关键问题。
  2. Issue #31479: 为更多多模态模型启用LoRA支持
    • 核心议题:当前仅部分多模态模型(Qwen VL, idefics3)支持对视觉塔(tower)和连接器(connector)添加LoRA适配器,需要将其扩展到所有多模态模型。
    • 观点与协作
      • 发起人 (jeejeelee):清晰地说明了需要实现 get_num_mm_encoder_tokensget_num_mm_connector_tokens 两个函数的技术原因。
      • 社区贡献者 (Zyyeric, B-201, Anexdeus):多人主动表示愿意承接此项工作,表现出强烈的社区协作意愿。
      • 协调:发起人建议贡献者内部协商分工,避免重复劳动。
    • 当前状态:开放中,已被标记为help wanted。相关PR #31513(为LLaVA添加支持)已提交,显示工作已启动。
  3. Issue #31501: stream-interval > 1 导致工具调用参数丢失
    • 核心议题:在使用--stream-interval参数且值大于1时,流式输出中的工具调用(tool call)参数内容丢失。
    • 观点与排查
      • 报告者 (ktsaou):详细描述了问题现象(参数变为空{}),并提供了完整的服务端启动命令和客户端复现脚本。
      • 维护者询问 (chaunceyjiang):要求提供客户端复现代码以精准定位问题。
      • 报告者跟进:迅速提供了基于OpenAI客户端的复现脚本。
    • 争议焦点:无实质性争议,属于明确的bug。讨论集中在如何高效复现和定位问题上。
    • 当前状态:开放中,已具备完整的复现路径,等待修复。

🔥 热门话题与趋势分析

🛠️ 重点技术变更

  1. PR #31502 & #31499: ROCm量化与MoE重构修复
    • 内容:修复了ROCm平台FP8静态量化因参数替换方式错误而失败的问题,并将相关函数纯化以提升兼容性。
    • 影响:确保了AMD用户能够正常加载和使用量化模型,是维护AMD平台功能完整性的关键补丁。
  2. PR #31493: 优化MiniMax-M2/M2.1的QKNorm
    • 内容:通过融合操作,在张量并行模式下将QKNorm所需的all_reduce通信次数减少为一次。
    • 影响:直接降低了该系列模型在分布式推理时的通信开销,提升了吞吐量(根据PR描述,优化后在TP=4时解码吞吐提升约7%)。
  3. PR #31498: Transformers后端统一使用vLLM ConvNdLayer
    • 内容:使通过Transformers建模后端加载的模型中的nn.Conv2d/nn.Conv3d自动替换为vLLM的ConvNdLayer
    • 影响:扩展了自定义卷积算子的收益范围,特别是对于非CUDA硬件(OOT设备),能带来潜在的通用性能提升。
  4. PR #27614: 默认启用异步调度
    • 内容:将--async-scheduling设为默认开启选项。
    • 影响:这是调度系统的重大变更。异步调度有助于提高GPU利用率,特别是在处理大量并发的短请求时。此举表明该功能已足够稳定,旨在为大多数用户提供更好的开箱即用性能。
  5. PR #30184: 支持离线FastAPI文档
    • 内容:通过自带静态资源,支持在无外网访问的隔离环境中使用/docs交互式API文档。
    • 影响:提升了vLLM在安全敏感或内网环境中的部署友好度和集成调试便利性。

📈 开发活跃度观察

💡 值得关注的问题

  1. MI300X FP8性能瓶颈 (#31475):此问题若确认为ROCm底层限制,将严重影响AMD最新硬件在高效推理场景下的竞争力。需要密切关注AMD官方的回应或修复进展。
  2. 多模态模型LoRA支持扩展 (#31479):这是一个明确的、社区驱动的功能扩展任务。其完成进度将影响众多多模态应用开发者的微调能力。
  3. 推测解码优化提案 (RFC #31483):提出了名为EARS的自适应拒绝采样算法,旨在提升高不确定性生成任务中推测解码的效率。该RFC是否被采纳并实现,可能影响未来vLLM在创意生成类任务上的性能。

📋 附录:详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR