vLLM 迎来腾讯混元高性能算子：混合长度解码与 MoE 推理大幅提速

起因：当通用推理引擎遇到真实流量的「碎片化」

vLLM 已经成为大模型推理的事实标准引擎之一，但它的默认 Attention 和 MoE 后端主要是针对较规整的批量请求优化的。现实中的请求是动态混合长度的——有的 prompt 很长，有的只需要简单响应；当你在同一个 batch 里调度时，固定分割 KV 缓存的方式就会卡在最长的请求上，让短请求的 GPU 算力白白浪费。MoE 模型更是如此：多个专家的小矩阵乘法如果没有精心融合，kernel 启动和数据搬移的延迟就会盖过计算本身。腾讯混元团队在大规模服务中天天面对这种「脏乱差」的真实流量，于是打磨了一套算子库 HPC-Ops，现在他们把这部分核心优化直接贡献给了 vLLM 主分支。

拆解：两个算子如何「吃下」混合负载？

• Attention 后端：先看哪条请求最短 传统的 decode 阶段，KV 缓存被静态切分给不同的计算单元，batch 里所有请求必须等最慢的那个算完。HPC-Ops 的 Attention 后端换了一种「按步负载均衡」的调度：每步都动态评估，优先处理那些已经快完成的短请求，长请求则被更均匀地分摊。同时，它把 RoPE、QK 归一化、KV 写操作融合成一个紧凑的前置步骤，减少了 kernel 启动次数和数据在 HBM 与 SM 之间的移动。在 H20 GPU 上，这种调度让小任务更早释放，大任务也不被阻塞，混合长度解码性能最高达到静态 KV 分割的 2.95 倍，平均也比 FlashInfer 和 FlashAttention 快 2.25 倍。

• MoE 后端：一条完全融合的 FP8 流水线 MoE 推理的瓶颈不在于大规模矩阵乘，而在于 token 分发到各个专家时产生的大量小 GEMM 和中间结果搬运。HPC-Ops 的 MoE 后端把 token 重排、专家 GEMM（FP8）、激活函数、结果汇聚全部融合到一个 kernel 流水线里，几乎没有中间的 HBM 读写和 kernel 启动开销。在张量并行（TP8）或专家并行（EP8）两种配置下，该后端平均相比基于 Triton 和 CUTLASS 的实现分别提速 1.59 倍和 1.21 倍，而且输出质量完全对齐。

趋势洞察：推理优化的主战场从「算力」转向「调度与数据流」

这个工作的深层启示是：随着模型变 MoE、上下文变长、智能体交互变多，推理延迟的瓶颈早已不是单纯的 FLOPs。正如训练中大家逐渐意识到通信优化比堆卡更重要，推理中 kernel 如何调度 gpu 计算单元、如何融合操作以减少访存，正成为决定用户体验的关键。HPC-Ops 的贡献不仅是两个高性价比的算子，更是一套「面向真实流量模式设计计算」的范式——这种思路未来会主导推理框架的演进。

实用价值：vLLM 用户现在就能用

最直接的好处是：你不用修改一行模型代码，也无需维护单独的分支。只要你的 vLLM 已经合并了相关 PR，通过简单的后端选择参数就能切换到 HPC-Ops 的 Attention 或 MoE 后端。如果你部署的是 DeepSeek、Qwen、Mixtral 等 MoE 模型，并且使用 H20 或其他 Hopper 架构 GPU，强烈建议试试这些新后端。端到端的延迟下降会直接反映在用户体验和系统吞吐上。

反常识：同一张卡上也可以差出 2-3 倍

很多人以为，只要用了最快的 GPU（比如 H100、H20），推理性能就到头了。但现实是，同一个 batch 里不同长度的请求混合在一起时，糟糕的调度会让 GPU 利用率掉到 50% 以下。HPC-Ops 的例子告诉我们，仅靠更聪明的计算组织，就能在同样的硬件上榨出 2-3 倍的 performance。这不是魔法，是扎实的工程优化——而且它们正在变得开箱即用。

原文地址: vLLM × HPC-Ops: High-Performance Attention and MoE Backends from Tencent Hunyuan