View on GitHub

LLM Dev Highlights

« Back to vLLM Reports

vLLM 开发动态报告 - 2026-01-28

时间窗口: 2026-01-28 11:22 (UTC+8) ~ 2026-01-29 11:22 (UTC+8) 数据统计: 新 Issue 21 | 关闭 Issue 5 | 新 PR 64 | 合并 PR 30 | 关闭未合并 PR 15


📊 每日开发状态摘要

在2026年1月28日至29日的时间窗口内,vLLM项目保持了极高的开发活跃度,新增64个PR并合并了30个,显示出持续的代码贡献和快速迭代。开发焦点集中在性能优化(如算子优化、CUDA图、流水线并行支持)、功能增强(如FP8 LoRA提案、多模态模型支持)和问题修复(特别是FP8兼容性、工具解析)等方面。整体趋势表明项目在扩展模型支持、提升推理效率与系统稳定性上齐头并进。

🎯 AMD/ROCm 生态相关动态

本周期内AMD生态相关活动持续进行,主要体现在性能优化、默认配置调整和测试修复方面:

  1. 功能请求与性能优化:AMD员工 monajafi-amd 提交了Issue #33279,提议引入环境变量 VLLM_TRITON_AUTOTUNE 以控制Triton内核的自动调优行为,旨在解决由其带来的非确定性、启动时间增加和不稳定问题,默认建议禁用。此改进对AMD及其他硬件平台的性能可移植性与稳定性均有重要意义。
  2. ROCm后端默认设置调整:PR #33271 计划调整ROCm平台的默认设置,包括在支持的平台(gfx9x)上默认启用AITER MoE后端、禁用AITER MHA,并将默认注意力后端切换为ROCM_ATTN(因其性能表现通常优于TRITON_ATTN)。
  3. KV缓存更新与编码器修复:PR #33106 的后续修复 PR #33269#33278 为ROCm的多个注意力后端(RocmAiterUnifiedAttention, RocmAttention, TritonAttention)添加了对 forward_includes_kv_cache_update 的支持,并修复了编码器(Encoder)模型在相关路径下的崩溃问题,提升了功能完整性。
  4. CI/测试改进
    • PR #33277 通过限制 max_num_seqs=1 来减少ROCm平台上 test_sharded_state_loader 测试的批次差异,旨在降低测试不稳定性(Flakiness)。
    • PR #32891 为AMD CI的分布式测试(A100)添加了 TORCH_NCCL_BLOCKING_WAIT 环境变量作为已知HIP运行时bug的临时解决方案。

技术影响分析:本周期更新聚焦于提升AMD平台上的开发体验与稳定性(可控的自动调优、测试修复)和运行时性能(默认后端调优、算子功能支持)。虽然未出现对Quark量化工具或MI300等新硬件的直接支持,但持续的底层优化为AMD生态的稳健运行奠定了基础。

💬 高热度讨论分析

  1. Issue #33264: Should we use prompt_cache_key instead of cache_salt in vLLM?
    • 核心议题:讨论OpenAI API中的 prompt_cache_key 与vLLM现有的 cache_salt 参数是否应统一。
    • 观点整理
      • 用户 dr75:认为两者设计动机不同。prompt_cache_key 主要用于路由(由网关/负载均衡器处理),而 cache_salt 主要用于vLLM实例内部的缓存隔离与安全。不建议合并,以避免不必要地耦合路由和缓存隔离逻辑。用户可以根据自身用例,在更高层将OpenAI的参数映射到vLLM参数。
      • 用户 hustxiayang:认为两者实现相似,询问为何 prompt_cache_key 不能直接用于vLLM的缓存隔离目的,以实现与OpenAI接口的统一。
    • 争议焦点:概念上的分离(路由 vs. 安全隔离)是否需要在接口层面保持一致。
    • 当前状态:讨论以厘清概念和适用场景为主,dr75 的建议(保持分离,在网关层映射)被更详细地阐述,尚未有代码变更。
  2. Issue #32109: [Bug]: Blackwell (SM120) FP8 MoE path fails for GLM-4.7 (本期关闭)
    • 核心议题:修复在Blackwell GPU(SM120)上运行FP8 MoE模型时,因错误选择了仅支持SM90/SM100的CUTLASS后端而导致的崩溃问题。
    • 观点整理
      • 问题发现者:报告了错误“No compiled cutlass_scaled_mm for CUDA device capability: 120”。
      • 贡献者 XiaobingSupermalaiwah:分析了代码,指出CUTLASS的FP8 MoE内核仅实现了SM90和SM100版本。提出了添加条件判断或实现SM120内核的补丁方案。
      • 最终解决方案:通过 PR #33285 修复。该PR在FP8后端选择逻辑中明确限制CUTLASS后端仅适用于SM90和SM100,从而使SM120设备能够正确地回退到Triton内核,解决了问题。
    • 最终结论:通过软件层面的正确功能检测和屏蔽,而非为SM120实现新的CUTLASS内核,以更简洁的方式保证了兼容性。
  3. RFC #33224: Deprecate and delete InductorAdaptor in favor of InductorStandaloneAdaptor
    • 核心议题:提议弃用并最终删除 InductorAdaptor,全面转向 InductorStandaloneAdaptor,以简化 torch.compile 集成代码。
    • 观点整理
      • 提议者 zou3519InductorStandaloneAdaptor 自PyTorch 2.9起已默认开启,且某些模型(如Deepseek 3.2)必须依赖它才能运行。维护两套代码会增加复杂度和维护负担。
      • 支持者 ProExpertProg:完全同意(SGTM)。他指出,需要考虑支持 torch.compile 的后端(CUDA, ROCm等)何时升级到PyTorch 2.10,以确定弃用时间点。
    • 当前状态:社区反馈积极,倾向于简化。后续需确定具体的弃用时间表。

🔥 热门话题与趋势分析

  1. 性能优化持续深入
    • 算子级优化:PR #32892 对MoE permute 内核进行优化,获得了40%-300%的显著性能提升。
    • 编译与缓存:PR #33232 为Qwen多模态模型的ViT编码器启用分片CUDA图,旨在减少内核启动开销,降低TTFT。
    • 分布式调度:PR #32618 完善了异步调度与流水线并行(PP)的协同工作,报告了30.8%的端到端吞吐量提升。
  2. FP8精度与应用扩展
    • 问题修复:多个PR(如 #33285, #33300, #33280)集中修复了FP8在MoE、CUTLASS后端选择、CompressedTensors块量化等方面的兼容性问题。
    • 新功能提案:RFC #33301 正式提出支持 FP8 LoRA推理,旨在显著减少大规模服务中多个LoRA适配器的内存占用,并利用现代GPU的FP8计算优势。
  3. 模型与工具生态拓展
    • 新模型支持:出现了对DeepSeek OCR 2、MiniMax、FunASR等新模型架构的支持PR(#33252, #33244, #33058)。
    • 工具与解析器完善:针对GLM-4、Kimi等模型的工具调用解析器进行了流式输出、空参数处理等多处改进(#33218, #33248)。
  4. 系统可观测性与调试
    • 指标细化:Issue #33289 及对应PR #33290 为Prefill/Decode分离部署添加了带标签的Prompt Token来源指标,帮助用户区分本地计算、KV传输和缓存命中的工作量。

🛠️ 重点技术变更

  1. PR #33285:修复Blackwell GPU上FP8 MoE的CUTLASS后端选择
    • 内容:在FP8 MoE后端选择逻辑中,将vLLM CUTLASS后端严格限制为仅支持SM90和SM100设备。
    • 影响:从根本上解决了Blackwell(SM120)等新架构GPU因误选未实现的内核而崩溃的问题,确保了FP8 MoE模型在新硬件上的兼容性与可用性。
  2. PR #32892:MoE Permute内核性能优化
    • 内容:通过优化 aligned_expert_first_token_offset 的计算逻辑和减少共享内存使用,重构了 moe_permute 内核。
    • 影响:在多种批次大小下取得了40%到300% 的性能提升,虽然该操作在整体MoE计算中占比不高,但优化有助于降低系统延迟,体现了对核心算子的深度打磨。
  3. PR #32618:完全支持异步调度+流水线并行
    • 内容:解决了异步调度模式下流水线并行最后一阶段需要向其他阶段广播采样结果的问题,通过GPU直接的张量广播替代了原有的CPU路径。
    • 影响:在测试中实现了30.8%的端到端吞吐量提升和31.8%的TPOT提升,使得vLLM在复杂分布式推理场景下的性能潜力得到进一步释放。
  4. PR #33191/#33256:代码质量与文档改进
    • 内容:前者将 flake8-implicit-str-concat 规则加入Ruff检查,后者修复了多处文档和代码中的拼写错误。
    • 影响:这些变更虽不直接影响功能,但提升了代码库的长期可维护性和代码质量,是成熟项目的重要标志。

📈 开发活跃度观察

💡 值得关注的问题

  1. RFC #33301: Support FP8 LoRA inference:这是一个重要的新特性提案,旨在解决大规模部署中多LoRA适配器的内存瓶颈。其实验结果和实施方案值得社区深入评审,可能成为下一个关键性能特性。
  2. Issue #33263: Prevent overallocation of kv-cache:用户提出KV缓存应根据 max_num_seqs * max_model_len 自动限制,而非总是占满可用GPU内存。这触及了资源管理的易用性与灵活性之间的平衡,可能需要设计更智能的默认策略或提供更好的指导。
  3. Issue #33279: Environment Variable to Control Triton Autotuning:由AMD员工提出的这一特性,反映了生产环境对确定性、稳定启动时间的强烈需求。无论最终是否以环境变量形式实现,相关问题的解决思路值得核心团队关注。
  4. CI稳定性:Issue #33297 报告了CI中因GPU内存利用率设置导致的测试失败,提示在资源紧张的CI环境中需要更稳健的默认配置或测试隔离策略。

📋 附录:详细数据列表

新增 Issue

已关闭 Issue

新增 PR

已合并 PR

关闭但未合并的 PR