腾讯混元 HPC-Ops 的 Attention 与 MoE 后端合入 vLLM 主干
vLLM × HPC-Ops: High-Performance Attention and MoE Backends from Tencent Hunyuan
腾讯混元 AI Infra 团队将 HPC-Ops 的 Attention 与 MoE 内核合入 vLLM 主干，成为一等后端，均针对 NVIDIA Hopper 架构优化，在 H20 上表现最佳。
腾讯混元把生产环境验证过的 Attention 与 MoE 内核合入 vLLM 主干，读者可据此了解混合长度解码与低延迟 MoE 的调度思路。
TL;DR
来自 HPC-Ops 的 Attention 和 MoE 内核——由腾讯混元 AI Infra 团队构建的生产级算子库——现已作为一等后端进入 vLLM main 分支（Attention PR #46020、MoE PR #45924）。两者均针对 NVIDIA 的 Hopper 架构进行了优化，在 H20 上表现最强：
- Attention：一个逐步、负载均衡的解码调度器，外加融合的 RoPE + QK-Norm + KV 写入前导。在混合长度解码上，相比静态 split-KV 调度最高提升 2.95×，相比 FlashInfer 和 FlashAttention 平均提升 2.25×。
- MoE：一个完全融合、低延迟的 FP8 MoE 流水线。在 TP8 / EP1 下平均提升 1.59×，在 TP1 / EP8 下相比 Triton 和 CUTLASS 平均提升 1.21×，且输出质量相当。
在 8× H20 上对 Hy3 进行端到端测试，这两个后端合计相比 vLLM 默认后端将 TTFT 降低约 24%，将 TPOT 降低约 17%。
两者都通过 vLLM 的后端接口接入原生 vLLM——无需修改源码，也无需长期维护分支。
本文涵盖三件事：HPC-Ops 是什么，这两个已上游的后端如何设计与集成，以及它们在 H20 上的性能表现。
为什么这很重要
生产级 LLM 服务不再像大多数内核最初调优时那样是均匀的单轮批次。真实流量是动态且长度混合的，模型越来越多地采用带长上下文的 MoE，而智能体工作负载对两者都提出了更高要求。在这种规模下，延迟在很大程度上取决于内核如何在 GPU 上调度工作以及在阶段之间移动数据，而不仅仅是原始矩阵乘法吞吐量。在注意力解码中，固定的 split-KV 调度会因混合批次中最长的请求而停滞，同时让短请求上的计算闲置。在 MoE 中，每个专家的 GEMM 很小，而传统流水线将 token 收集到每个专家的缓冲区中，在每个阶段都要付出启动开销，并在其间通过 HBM 移动中间结果。
vLLM 已经为社区提供了一个快速、灵活的服务引擎；剩余的延迟和吞吐量取决于注意力与 MoE 内核能多好地吸收这种杂乱的真实流量。这正是 HPC-Ops 的目标——一个在腾讯大规模生产服务中经过锤炼的算子库，而服务 Hy3 的同一批内核现已作为一等 Attention 和 MoE 后端上游到 vLLM。
关于 Hy3 系列模型的简要说明
Hy3 是腾讯混元的 Mixture-of-Experts 模型，面向智能体执行、编码和长程推理。它仅激活其 295B 参数中的 21B，就达到了同尺寸级别中最强的智能体能力之一——可与大 2–3 倍的开源旗舰模型匹敌——同时大幅减少幻觉，实现更可靠的多轮使用。在底层，它使用 192 个专家、top-8 路由、GQA 注意力（64 个头、8 个 KV 头、头维度 128）、256K 上下文窗口，以及用于投机解码的 3.8B MTP 层；它以 BF16 和 FP8（Hy3-FP8）形式发布。
本文有意不讨论模型本身——而是讨论服务它的内核，接下来我们转向这一点。
HPC-Ops：一个生产级算子库，现已进入 vLLM
HPC-Ops 是一个面向 LLM 推理的开源算子库，由腾讯混元 AI Infra 团队构建并维护。它聚焦于决定实际服务延迟和吞吐的热点路径——attention、MoE、GEMM、采样、归一化以及通信-计算融合——原生支持 BF16 和 FP8，并提供简洁的 Python API，可直接接入推理框架。这些 kernel 针对 NVIDIA 的 Hopper 架构进行了优化，在 H20 上表现尤为突出。
这些 kernel 已在腾讯内部大规模混元生产服务中得到验证。在本次发布中，其中两个 kernel 已作为一等后端合入 vLLM：
| vLLM 后端 | 优化内容 | 精度 | 合入版本 |
|---|---|---|---|
| Attention | 负载均衡的 decode + 融合 RoPE/QK-Norm 前导 | BF16 / FP8 | PR #46020 |
| 融合 MoE | 全融合低延迟 MoE 流水线 | FP8 | PR #45924 |
本文其余部分将聚焦这两个后端。
Attention 后端：动态负载均衡调度
挑战：每个 batch 中的变长 decode
在 decode 阶段，每个 token 生成步骤都会对请求的完整 KV cache 执行 attention。一个已累积 16K token 上下文的请求，其计算量大约是刚起步的 1K 请求的 16 倍。在生产服务中，输出长度不可预测，而连续批处理会让处于不同生成阶段的请求进入同一次 kernel 启动——因此单个 batch 中经常混合着极短和极长的序列。
现有的 decode kernel 通过固定的启动网格将工作映射到 CTA，以 KV head、请求和 split-KV 分块索引为键——而 split-KV 的拆分度必须在所有请求间保持一致，这迫使人们在两个糟糕的选项之间做选择。固定拆分数量，最长的序列就会成为瓶颈：短请求的 CTA 在很短的时间内完成并闲置。改为固定分块大小，拆分数量就必须按任何请求所需的最大值来设置，于是短请求会被空分块填充，这些分块启动后找不到工作便退出——浪费调度槽位。无论哪种方式，总 kernel 时间都由最重的 CTA 决定，而其他 CTA 则停滞，白白浪费 SM 周期。
解决方案：按步负载均衡的 decode 调度器
HPC-Ops attention 后端用扁平的持久化设计取代固定网格，它根据 batch 的实际长度分布自适应，而非依赖启动时的拆分策略，分三个阶段构建。
- 分配。一个轻量级的 assign kernel 将每个 KV 序列切分为统一的 64-token 分块。所有 head 和请求的总分块数除以可用 CTA 数量，得到每个 CTA 的预算——即桶大小。分块按 head 主序、batch 次序遍历，并依次填入 CTA 桶中：一旦某个 CTA 的桶满了，后续分块就溢出到下一个 CTA。因此，长序列会按其长度比例拆分到多个 CTA，而短序列只贡献少量分块，不会独占一个 CTA。每个 CTA 的最小工作量下限可防止总工作量较小时过度拆分，确保分块数量保持可控，下游 combine 成本不会超过调度收益。由此得到的任务映射在每个 decode 步骤计算一次，并被该步骤中的每个 transformer 层复用，因此其开销被摊薄至接近零。
- 计算与合并。随后运行一个持久化内核网格：每个 CTA 在其分配的任务箱上循环，取出一个任务描述符，为该分块计算注意力，将部分输出和 log-sum-exp 写入一个拆分缓冲区，然后推进到下一个任务，直到遇到终止符。由于网格是持久化的，任务之间没有重新启动的开销，波次之间也没有空闲间隙——每个 SM 在整个内核执行期间都保持饱和。最后一个轻量级的合并内核读取每个（head, request）对的分块数量，并将每个分块的部分结果归约为最终的 BF16 输出。
最终效果是，无论序列长度分布多么倾斜，所有 CTA 都承担大致相等的工作量，并几乎同时完成。静态调度中固有的长尾停顿被消除，之前浪费在空闲等待上的 GPU 周期被转化为有用的计算。
融合的注意力前奏
在注意力运行之前，每一层通常会将 QK-Norm、RoPE 和 KV 缓存写入——以及在 FP8 中的查询量化——作为独立的内存受限步骤来执行。HPC-Ops 将它们融合为单个算子（HpcRopeNorm）：从融合的 QKV 投影开始，它按照模型要求的顺序应用 QK-Norm 和 RoPE（Hy3 在 RoPE 之前进行归一化），将 K 和 V 直接写入分页缓存，并且在 FP8 中，输出一个带有其缩放因子的逐 token、逐 head 的 FP8 查询，这样注意力内核就无需重新量化。一个内核取代了这些独立的启动及其在每一层注意力前奏中的 HBM 往返，无论是在预填充还是解码中。
与 vLLM 集成
HPC-Ops 注意力 API 作为原生注意力后端集成到 vLLM 中，与现有的后端如 FlashAttention 和 FlashInfer 并列。具体来说，HpcAttentionBackend 继承自 vLLM 的 AttentionBackend 基类，并通过标准后端注册机制进行注册。
MoE 后端：融合的低延迟 FP8 MoE 流水线
挑战：小型专家 GEMM 及其周边开销
MoE 推理有两种截然不同的情形。在大批量、高吞吐量时，专家 GEMM 规模较大且受计算限制，现有实现在这种情况下通常表现良好。低延迟解码则相反：每个专家只接收少量 token，因此专家 GEMM 规模小且受内存限制。针对大型矩阵乘法调优的内核在这些形状上无法充分利用 GPU，而且由于每个专家产生的分块数量各不相同且逐步变化，这些小分块很难均匀地分布到 GPU 上。
GEMM 周边的工作加剧了这一问题。传统的 MoE 路径是一系列独立内核的链条：路由 token、将它们收集到按专家划分的缓冲区、Gate-Up GEMM、激活与量化、Down GEMM，以及将 top-k 加权归约回 token 位置。收集操作在任何矩阵乘法开始之前就在 HBM 中物化了一个收集后的 token 张量，而每个阶段都要付出自己的内核启动开销和中间结果的 HBM 往返。在解码中，GEMM 本身已经很小，所有这些开销与 GEMM 工作本身叠加在一起。
解决方案：融合的 FP8 MoE 流水线
HPC-Ops MoE 后端对整个 MoE 路径进行了重新架构：路由与索引预处理、Gate-Up GEMM、激活与量化、Down GEMM 以及 top-k 加权归约被融合为一条紧凑的执行路径，消除了多阶段设计的冗余开销。
- 路由与索引构建。 一次共享内存计数遍历将 token 分配给专家，并为每个专家分配连续的输出范围，从而减轻大 token 路由带来的全局原子操作压力，并构建 GEMM 直接使用的路由索引和逐 tile 任务映射。
- Gate-Up GEMM。 Gate-Up GEMM 通过路由索引直接读取原始 token，跳过了独立的 gather 步骤。随后激活与 FP8 量化作为单独融合内核运行，其输出由 Down GEMM 直接读取。
- 占用率优先，无需 warp 特化。 单个 warp 组同时处理数据搬运与计算，将内存延迟隐藏从 CTA 内软件流水线转移到跨 CTA 硬件调度，并提高每个 SM 的常驻 CTA 数量。随后启动一个持久化网格以保持每个 SM 满载，消费任务映射并将每个专家的小而不均匀的 tile 集合均匀分配到各 CTA 上。
- PDL 链式阶段。 程序化依赖启动（Programmatic Dependent Launch）将每个内核启动与前一个内核的尾部重叠，消除阶段之间的气泡，一直延续到最终的 top-k 加权归约，后者还可以合并共享专家的输出。
这些设计共同使中间结果和启动操作远离关键路径。专家以 FP8 运行，同时支持逐张量和分块缩放，并达到与基线相当的输出质量。
与 vLLM 集成
HPC-Ops Fused MoE API 作为原生 MoE 后端集成到 vLLM 中，与 DeepGEMM 和 Triton 等现有后端并存。具体而言，HPCExperts 继承自 vLLM 的 FusedMoEExpertsModular 基类，并通过标准后端注册机制进行注册。
在 vLLM 中使用 HPC-Ops 后端
本指南介绍如何在 vLLM 中启用 HPC-Ops 后端（Attention 和 MoE）。
安装
开始之前，请从源码安装 HPC-Ops：
git clone https://github.com/Tencent/hpc-ops.git
cd hpc-ops
# Build and install the wheel package
make wheel
python3 -m pip install dist/*.whl快速开始
HPC-Ops Attention 后端目前仅支持 Hy3 系列模型。
要使用 HPC-Ops Attention 后端为标准 Hy3 模型启动 vLLM 服务器，请运行：
vllm serve tencent/Hy3 \
--tensor-parallel-size 8 \
--attention-backend HPC_ATTN对于 Hy3-FP8 模型，需要一些额外的选项：
vllm serve tencent/Hy3-FP8 \
--tensor-parallel-size 8 \
--attention-backend HPC_ATTN \
--kv-cache-dtype fp8_e4m3 \
--block-size 64提示： 要为自定义模型启用 HPC-Ops Attention 后端，请在模型的 forward 方法中将 rope_norm 替换为 HpcRopeNorm。参考 PR #46020。
HPC-Ops MoE 后端仅支持 FP8 模型。
要使用 HPC-Ops MoE 后端启动 vLLM 服务器，请运行：
vllm serve tencent/Hy3-FP8 \
--tensor-parallel-size 8 \
--moe-backend hpc硬件支持
HPC-Ops 后端目前仅在 NVIDIA Hopper 架构 GPU 上受支持，并在 H20 上提供最佳性能。
H20 上的性能
Fused MoE：HPC-Ops 对比 Triton / CUTLASS
我们在 Hy3 模型配置下，分别在 TP8 / EP1 和 TP1 / EP8 设置下，将 HPC-Ops MoE 后端与 Triton 和 CUTLASS MoE 后端进行了基准测试。按批次大小平均，HPC-Ops 在 TP8 / EP1 下比最佳基线快 1.59 倍，在 TP1 / EP8 下快 1.21 倍，在主导低延迟解码的中小批次大小上收益最大。
表 1：TP8 / EP1 下不同 batch size 的 FusedMoE 延迟（µs）（专家权重分片在 8 个 rank 上）
| Batch | HPC-Ops（µs） | Triton（µs） | CUTLASS（µs） |
|---|---|---|---|
| 4 | 42.0 | 56.4 | 74.5 |
| 16 | 85.7 | 124.2 | 209.2 |
| 32 | 124.0 | 184.3 | 275.6 |
| 64 | 147.2 | 374.9 | 330.3 |
| 128 | 161.5 | 302.9 | 345.3 |
| 256 | 170.1 | 310.9 | 351.6 |
| 512 | 194.5 | 331.6 | 369.2 |
| 1024 | 281.4 | 652.7 | 438.3 |
| 2048 | 491.8 | 731.5 | 794.4 |
| 4096 | 872.0 | 1366.0 | 1230.7 |
| 8192 | 1695.0 | 2216.8 | 2362.9 |
| 16384 | 3241.9 | 4329.1 | 4364.4 |
表 2：TP1 / EP8 下不同 batch size 的 FusedMoE 延迟（µs）（专家分片在 8 个 rank 上）
| Batch | HPC-Ops（µs） | Triton（µs） | CUTLASS（µs） |
|---|---|---|---|
| 4 | 118.6 | 147.4 | 140.4 |
| 8 | 136.7 | 192.8 | 170.7 |
| 16 | 149.8 | 198.4 | 263.5 |
| 32 | 153.6 | 214.6 | 264.4 |
| 64 | 166.5 | 358.1 | 266.8 |
| 128 | 213.5 | 251.7 | 272.6 |
| 256 | 386.2 | 454.9 | 493.5 |
| 512 | 705.5 | 691.7 | 741.7 |
| 1024 | 1342.6 | 1369.1 | 1359.1 |
| 2048 | 2513.9 | 2668.7 | 2530.4 |
混合长度批次下的 Decode：动态调度 vs 静态调度
Attention 后端最突出的优势是在混合长度批次上的 decode。为了单独考察调度器，我们将 FP8 decode 从均匀的 KV 长度分布扫描到高度倾斜的分布（标签 A×B = A 个请求，KV 长度为 B），并将 HPC-Ops 动态调度与静态 split-KV 调度、FlashInfer 和 FlashAttention 进行对比。相比静态调度的优势随倾斜程度增加而增大，从小型均匀批次上的持平，到 1×128K + 31×4K 混合场景下的 2.95×。在这些场景中，动态调度平均比 FlashInfer 和 FlashAttention 中最快者快 2.25×。
表 3：不同 KV 长度分布下的 Decode 延迟（ms）
| Decode 场景 | HPC-Ops 动态（ms） | HPC-Ops 静态（ms） | FlashInfer（ms） | FlashAttention（ms） | 动态 vs 静态 |
|---|---|---|---|---|---|
| 64×0.5K | 0.013 | 0.013 | 0.050 | 0.025 | 1.00× |
| 64×4K | 0.033 | 0.043 | 0.221 | 0.095 | 1.32× |
| 32×0.125K + 32×4K | 0.020 | 0.033 | 0.119 | 0.053 | 1.59× |
| 2×32K + 30×4K | 0.032 | 0.056 | 0.169 | 0.094 | 1.76× |
| 1×64K + 15×4K | 0.042 | 0.097 | 0.118 | 0.065 | 2.32× |
| 1×128K + 31×4K | 0.063 | 0.186 | 0.220 | 0.097 | 2.95× |
Attention：HPC-Ops vs FlashAttention / Triton / FlashInfer
我们进一步使用 vLLM 的 attention benchmark，在 prefill、extend 和 decode 形状上将 HPC-Ops Attention 后端与 FlashAttention、Triton 和 FlashInfer 进行了基准测试。在这些形状中，HPC-Ops 几乎在所有情况下都与三者中最快者持平或更快。
表 4：Attention 延迟（ms）对比 FlashAttention、Triton 和 FlashInfer
| Batch Spec | Type | Batch Size | HPC-Ops（ms） | FlashAttention（ms） | Triton（ms） | FlashInfer（ms） |
|---|---|---|---|---|---|---|
| q512 | prefill | 1 | 0.047 | 0.069 | 0.123 | 0.070 |
| q1ks2k | extend | 1 | 0.406 | 0.431 | 1.132 | 0.431 |
| q2k | prefill | 1 | 0.530 | 0.574 | 1.525 | 0.609 |
| q4k | prefill | 1 | 2.002 | 2.093 | 5.816 | 2.144 |
| q8k | prefill | 1 | 7.883 | 7.957 | 22.702 | 8.084 |
| 2q1ks4k | extend | 2 | 1.835 | 1.830 | 5.046 | 1.829 |
| 8q1s1k | decode | 8 | 0.019 | 0.031 | 0.035 | 0.021 |
| 16q1s2k | decode | 16 | 0.054 | 0.098 | 0.106 | 0.052 |
| 32q1s1k | decode | 32 | 0.057 | 0.102 | 0.080 | 0.058 |
| 64q1s4k | decode | 64 | 0.299 | 0.620 | 0.510 | 0.340 |
端到端：Hy3 在 8× H20 上
最后，我们在 8× NVIDIA H20 GPU 上评估了采用 HPC-Ops MoE 和 Attention 后端的 Hy3 模型相对于 vLLM 默认后端的端到端（E2E）性能。在所有测试用例中，HPC-Ops 后端始终优于 vLLM 默认后端，在 TTFT 和 TPOT 上均实现了大幅降低。TTFT 平均下降约 24%，TPOT 平均下降约 17%，在最大 batch size 下最高可达约 30%。
表 5：不同 batch size 下的 TPOT（输出长度 = 4K）
| Batch Size | Baseline TPOT（ms） | HPC TPOT（ms） | Improvement |
|---|---|---|---|
| 1 | 8.00 | 7.76 | +3.0% |
| 4 | 11.14 | 10.67 | +4.2% |
| 8 | 13.49 | 11.31 | +16.2% |
| 16 | 17.98 | 13.56 | +24.6% |
| 32 | 24.13 | 18.32 | +24.1% |
| 64 | 31.10 | 21.90 | +29.6% |
表 6：不同 batch size 下的 TTFT（输入长度 = 8k，禁用 Chunked Prefill，禁用 Prefix Caching）
| Batch Size | Baseline TTFT（ms） | HPC TTFT（ms） | Improvement |
|---|---|---|---|
| 1 | 565.69 | 431.00 | +23.8% |
| 4 | 1920.15 | 1471.43 | +23.4% |
| 8 | 3948.22 | 3035.44 | +23.1% |
| 16 | 7807.18 | 5885.63 | +24.6% |
表 7：不同输入长度下的 TTFT（batch size = 16，禁用 Chunked Prefill，禁用 Prefix Caching）
| Input Length | Baseline TTFT（ms） | HPC TTFT（ms） | Improvement |
|---|---|---|---|
| 2k | 1792.62 | 1363.13 | +24.0% |
| 4k | 3704.27 | 2886.40 | +22.1% |
| 8k | 7807.12 | 5893.93 | +24.5% |
下一步计划
这只是与 vLLM 社区长期合作的开端。我们将继续与 vLLM 维护者和贡献者合作，改进和扩展这些能力，并在进一步成熟后向上游提交更多工作。非常欢迎反馈、问题和基准测试，我们期待共同构建开放、高性能的推理。
致谢
我们要感谢各团队中为将这些后端引入 vLLM 而共同努力的众多人员：
- 腾讯混元 AI Infra — 构建并优化 HPC-Ops Attention 和 MoE 内核，并将其作为后端贡献给 vLLM。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。
- 腾讯网络平台部 — 在通信优化方面的紧密协作。Xuan Zhang、Haoran Zhao、Yuanyuan Gong、Yadong Liu、Jinzhu Wang、Yinben Xia、Xiang Li、Quan Wen、Zekun He。
- 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。
我们还要感谢更广泛的开源内核社区，本工作建立在其成果之上并与之进行对比，包括 NVIDIA CUTLASS/CuTe、TensorRT-LLM、FlashInfer、FlashAttention 和 Triton。
来源：vLLM Blog · vllm.ai