vLLM与腾讯混元联合上游两个HPC后端，支持NVIDIA Hopper GPU

腾讯混元AI Infra团队与vLLM团队联合将两个高性能后端上游至主线vLLM项目。这就是HPC_ATTN注意力后端和hpc MoE后端，无需fork或修改vLLM核心即可作为一等组件使用。这一贡献标志着工业团队将生产级内核优化直接上游至所依赖的开源项目的少见案例，而非将其保留为内部优势。

vLLM生态系统中的两个新HPC后端

腾讯网络平台部门、混元AI Infra团队与vLLM/Inferact维护者之间的合作，为现代LLM推理的两个长期瓶颈提供了解决方案：解码阶段的动态负载均衡和FP8 MoE路由开销。两个后端通过vLLM的标准注册机制集成——注意力的PR #46020和MoE后端的PR #45924——这意味着用户通过配置参数选择新后端，无需对核心进行任何修改。

验证后端的参考模型是Hy3，腾讯混元模型，总参数2950亿，激活参数210亿。模型包含192个专家（top-8路由），64个query head和8个KV head，head维度128，以及256K token的上下文窗口。推测解码层（MTP）额外增加38亿参数。

为什么动态调度对注意力至关重要？

静态split-KV调度假设批次内序列长度均匀。在生产环境中这很少成立——短请求和长请求的混合导致完成工作的计算单元处于空闲等待状态，而其他单元仍在处理长序列。结果是GPU周期损失，与批次内长度离散度成正比。

HPC_ATTN后端通过逐步负载均衡的解码调度器解决这一问题，该调度器按当前生成步骤中每个序列的实际长度，将64 token的瓦片分配给各计算单元。融合的前序程序将RoPE旋转、QK-Norm归一化和KV写入操作合并为单次内核遍历，消除这些操作之间冗余的内存读写。

在由一个128K token序列和31个4K token序列组成的混合工作负载上，动态调度比静态等效方案实现2.95倍加速。在混合长度解码批次上，相较FlashInfer和FlashAttention实现的平均优势为2.25倍。后端支持BF16和FP8精度。

FP8 MoE流水线作为单一执行路径

标准MoE推理经历一系列独立的内核调用：路由、Gate-Up GEMM、激活函数、量化、Down GEMM和top-k归约。内核之间的每次跳转意味着往返高带宽内存（HBM），对于解码主导型工作负载——批次小、延迟关键——这成为掩盖硬件实际计算速度的主要开销。

hpc后端使用程序性依赖启动（PDL）链接将整个流水线融合为单一执行路径。路由表存储在共享内存而非HBM中，消除了阶段间代价高昂的专家索引获取。该架构仅支持FP8，与Hopper一代的硬件能力一致。

在NVIDIA H20 GPU上的测量结果

端到端测量在Hy3模型的8× H20配置上进行。首token时间（TTFT）平均降低24%。每输出token时间（TPOT）平均改善17%，在最大批次大小64时提升达30%。

MoE后端在TP8/EP1配置下比最佳基线（Triton/CUTLASS）实现1.59倍更低延迟，TP1/EP8配置下为1.21倍。优势在小至中等批次大小时最为显著，对应需要以最低延迟服务少量并发请求的典型生产解码场景。

无fork集成与Hopper特定性

两个后端专为具有Hopper架构的GPU设计——H20被列为最佳平台。依赖PDL机制和Hopper特定指令意味着扩展到旧架构并非易事且未有公告。

通过正式PR流程上游，腾讯混元团队遵循了让所有vLLM用户无需在每次新上游发布时管理fork即可获得优化的贡献模型。对于在Hopper集群上扩展MoE推理的运营商，这是可通过标准vLLM升级周期获得的直接可用改进。