vLLM × HPC-Ops：来自腾讯混元的高性能注意力和 MoE 后端

vLLM × HPC-Ops：来自腾讯混元的高性能注意力和 MoE 后端

为什么这很重要

生产环境的 LLM 服务现在需要处理动态、混合长度的批次以及日益庞大的 MoE 模型，因此延迟主要取决于内核如何调度工作和移动数据，而不是原始矩阵乘法的吞吐量。HPC‑Ops 提供负载均衡的注意力和全融合的 FP8 MoE 内核，能够减少空闲 SM 周期并消除每阶段的开销，直接解决这些真实场景中的瓶颈。

HPC-Ops：面向生产的算子库，已集成至 vLLM

HPC-Ops 是由腾讯混元 AI 基础设施团队构建的开源算子库，专注于注意力、MoE、GEMM、采样、归一化以及通信‑计算融合，并原生支持 Hopper GPU 的 BF16 与 FP8。其注意力和 MoE 内核已通过 PR #46020（Attention）和 PR #45924（MoE）上游合并至 vLLM，作为一等后端，无需修改源码或维护长期分支。

注意力后端：动态负载均衡调度

HPC‑Ops 注意力后端通过使用逐步负载均衡调度器，将每个 KV 序列切分为统一的 64 token 瓦片，根据实际工作量将瓦片分配给 CTA，并运行持久化的 kernel 网格，使所有 SM 保持满负荷，从而消除混合长度解码中静态 split‑KV 调度导致的空闲时间。该方案在混合长度解码下相较于静态 split‑KV 调度可实现最高 2.95 倍加速，平均比 FlashInfer 与 FlashAttention 在 H20 上快 2.25 倍。

一个融合的注意力前置（HpcRopeNorm）将 QK‑Norm、RoPE、KV‑cache 写入以及在 FP8 下的查询量化合并为单个 kernel，消除了独立的内存受限启动及其 HBM 往返。

在 vLLM 中的集成通过 HpcAttentionBackend 完成，它继承自 vLLM 的 AttentionBackend 基类，并通过标准后端机制注册。

MoE 后端：融合的低延迟 FP8 MoE 流水线

HPC‑Ops MoE 后端通过将路由、Gate‑Up GEMM、激活/量化、Down GEMM 与 top‑k 加权归约融合为单一执行流水线，消除了传统 MoE 路径的每阶段开销。它使用共享内存计数遍历来构建连续的专家区间，直接通过路由索引读取 token，将中间结果保存在寄存器或共享内存中，并采用占用率优先的 warp 组配合持久化网格，将不均匀的专家瓦片均匀分布到各 CTA。Programmatic Dependent Launch 通过重叠 kernel 启动来消除空洞。

该流水线在 FP8 下运行，采用每张量和块级的缩放方式，保持基线输出质量。在 H20 上相较于 Triton 与 CUTLASS，TP8/EP1 场景下平均加速 1.59 倍，TP1/EP8 场景下加速 1.21 倍。

在 vLLM 中的集成通过 HPCExperts 完成，它继承自 FusedMoEExpertsModular，并通过标准后端注册机制进行注册。

在 vLLM 中使用 HPC-Ops 后端

要使用这些后端，首先从源码安装 HPC‑Ops：

git clone https://github.com/Tencent/hpc-ops.git
cd hpc-ops
make wheel
python3 -m pip install dist/*.whl

为 Hy3（BF16）模型启用注意力后端：

vllm serve tencent/Hy3 \
    --tensor-parallel-size 8 \
    --attention-backend HPC_ATTN

对于 Hy3‑FP8，添加 KV‑cache 数据类型和块大小：

vllm serve tencent/Hy3-FP8 \
    --tensor-parallel-size 8 \
    --attention-backend HPC_ATTN \
    --kv-cache-dtype fp8_e4m3 \
    --block-size 64

启用 MoE 后端（仅限 FP8）：

vllm serve tencent/Hy3-FP8 \
    --tensor-parallel-size 8 \
    --moe-backend hpc

这些后端目前仅在 NVIDIA Hopper 架构的 GPU 上受支持，且在 H20 上表现最佳。

在 H20 上的性能

融合 MoE 与 Triton / CUTLASS 对比

在批量大小 4 到 16384 的范围内，HPC‑Ops MoE 的延迟均低于 Triton 与 CUTLASS。TP8/EP1 场景下平均加速 1.59 倍；TP1/EP8 场景下平均加速 1.21 倍，且在低延迟解码常见的小到中等批量大小上收益最大。

混合长度批次下的注意力解码

动态调度优于静态 split‑KV、FlashInfer 与 FlashAttention。加速随偏斜程度提升：在均匀的 64×0.5K 批次上为 1.00 倍，在 1×128K + 31×4K 的混合批次上达到 2.95 倍。对所有测试分布而言，相较于 FlashInfer/FlashAttention 中的最佳方案，平均优势为 2.25 倍。

不同 Prefill、Extend 与 Decode 形状下的注意力

在所有测试的形状上，HPC‑Ops 注意力延迟与 FlashAttention、Triton、FlashInfer 中最快的保持持平或更快（例如，q512 预填充时 0.047 ms 对比 0.069 ms，8q1s1k 解码时 0.019 ms 对比 0.031 ms）。

Hy3（8× H20）端到端性能

同时使用 HPC‑Ops 的注意力和 MoE 后端后，与 vLLM 默认后端相比，TTFT 降低约 24%，TPOT 降低约 17%。随着批量大小的增大，提升幅度进一步提升，在最大批量大小下 TTFT 下降约 30%，TPOT 下降约 30%。

接下来计划

腾讯混元团队将继续与 vLLM 社区合作，完善这些后端，随着成熟度提升将进一步上游合并，并欢迎用户提供反馈、问题和基准测试。

致谢

感谢腾讯混元 AI 基础设施团队（Sethran Liu、Chase Shao、Shengy Wei、Theo Cheng、Ryann Xue、Lando Jiang、Looper Zhao、Haank Lin、Aiden Ren、Lehua Ding、Chengv Jiang、Steven Kuang、Liqi He、Kipper Gong、Reedlau Liu、Raccoon Liu、Dick Zhu）、腾讯网络平台部、vLLM/Inferact 贡献者（Kaichao You、Yongye Zhu、Yifan Qiao）、NVIDIA 工程师（Yuanhang Sun、Perkz Zheng、Yuxi Chi、Jiang Shao、Jun Gu、Meng Wang、River Liu、Gary Ji、Chandler Zhou），以及更广泛的开源 kernel 社区，正是他们的工作为本项目提供了基础和对标。

Sources