HPC-Ops × SGLang：腾讯混元开源高性能 Attention、Router GEMM 与 MoE 算子

HPC-Ops 是一个面向 LLM 推理的开源算子库，已部署于腾讯的大规模生产服务中。其核心算子，包括 Dynamic Attention 和 Fused MoE，在混元的在线推理中发挥着关键作用，将 Hy3 模型的 TPOT 最多降低 48.8%。HPC-Ops Attention、Router GEMM 和 MoE 现已集成到 SGLang 的主分支中，将这些经过生产验证的优化带给开源服务社区。

在这篇博客中，我们介绍 HPC-Ops 中三个重要算子的设计及其与 SGLang 的集成。随后，我们展示在 H20 上的算子基准测试和服务结果，以及 H200 的验证结果。这些集成面向 NVIDIA Hopper GPU（SM90），并已在 Qwen3、Hy3 和 LongCat 工作负载上完成验证。

亮点

• Attention：在 H20 上，HPC-Ops 动态调度相比其静态 split-KV 调度达到 2.95×，并且在每个测量用例中平均比 FlashInfer 和 FlashAttention 中的最优者快 2.25×。在上游 H200 验证中，集成 Hy3-FP8 路径并搭配 FP8 KV cache，相比 FlashAttention 将输出吞吐量提升 3.7–5.9%。
• Router GEMM：在 H20 上，HPC-Ops 比 FP32 cuBLAS 快 1.30–3.22 倍，而其相对于 FP32 cuBLAS 的最大绝对误差为 0.00177，相比之下 TF32 cuBLAS 为 0.06464。在上游 H200 LongCat-Flash 内核验证中，它相比现有 FP32 路径实现了 4.31 倍加速。
• MoE：在 H20 上，HPC-Ops 在 Hy3 上相比 SGLang 和 vLLM 基线中的最优者，实现了每批次平均加速 TP8 / EP1 下 1.08 倍和 TP1 / EP8 下 1.21 倍。在上游 Qwen3/H200 内核基准测试中，它在八个 token 时相比 Triton 最高达到 4.21 倍。
• 端到端服务：在 8× H20 搭配 Hy3-FP8 上，同时启用 HPC-Ops Attention 和 MoE 使 TPOT 在批次大小 4–64 时降低 15.1–48.8%，TTFT 在批次大小 4–16 时降低 3.3–6.0%。在 8× H20 搭配 LongCat-Flash-Lite-FP8 上，启用 HPC-Ops Router GEMM 使输入吞吐量在批次大小 4–64 时提升 5.5–6.1%。

注意力、路由与专家：MoE 模型服务中的三条热点路径

生产环境中的 MoE 服务很少像孤立内核基准测试中所测量的那样呈现均匀负载。它在同一条对延迟敏感的路径中，融合了变长 Attention 计算、对精度敏感的路由，以及稀疏专家执行；长上下文、多轮对话和智能体工作负载进一步拉大了活跃 KV 长度的分布范围。因此，服务性能不仅取决于原始的矩阵乘法吞吐量，还取决于负载均衡、数值保真度和开销控制。

这些约束在 MoE 模型服务的三个性能关键阶段中显现出来。在 decode 阶段，Attention 计算随每个请求的活跃 KV 长度而扩展，使变长批次成为一个负载均衡问题。Router GEMM 生成用于 top-k 选择的分数，其中微小的数值变化就可能改变专家的选择。随后，被选中的专家处理小而参差不齐的 token 组，使得元数据构建、token 搬运、中间存储和启动开销足以与专家 GEMM 本身相匹敌。

HPC-Ops 为每个阶段提供了专用算子来应对：针对 Attention 的负载感知调度、针对 Router GEMM 的精度感知公式，以及针对 MoE 的融合流水线，后者消除了独立的 gather 操作并减少了启动和中间流量。上游集成通过 SGLang 的原生后端和 dispatch 接口，将这些算子与 SGLang 的服务运行时配对。以下各节将解释每个算子的设计方式。

Attention：变长 decode 的负载均衡

在解码阶段，每个新 token 都要对请求的完整 KV cache 做注意力计算，因此 Attention 的工作量会随活跃序列长度而增长。一个缓存了 16K token 的请求，其 KV 计算量大约是缓存 1K token 请求的 16 倍。在生产环境中，提示词和输出长度差异极大，而连续批处理会把处于不同生成阶段的请求放进同一次 launch；因此一个批次里常常既有很短的 KV cache，也有长达数万 token 的序列。

静态 split-KV 调度会把工作映射到一个固定的 launch grid 上，覆盖 KV heads、请求和 KV chunks，并且整个批次共用同一套划分策略。静态 split-KV 调度器通常遵循两种策略之一，而这两种策略在混合长度批次上表现都不好。(1) 固定 split 数量，长请求就会产生重得多的 chunks：短请求的 CTA 早早完成，而少数长时间运行的 CTA 决定了 kernel 的尾部延迟。(2) 改为固定 chunk 大小，那么 grid 就必须为最长的请求预留足够多的 splits，导致较短的请求留下空 chunk 或几乎为空的 chunk，却仍然占用调度槽位。一种策略造成工作量不均；另一种则调度了根本不存在的工作。

围绕活跃 KV 工作进行调度

HPC-Ops 用一个持久化 kernel 取代了静态的按请求拆分方式，该 kernel 会根据批次的实际长度分布，在多个 CTA 之间动态平衡 KV tile。对于每个 decode 批次，一个 assign kernel 会根据实时的 KV 长度构建全局任务映射：它将每个序列切分为统一的 64-token tile，汇总所有 head 和请求的 tile 数量，再将总数除以持久化 CTA 的数量，从而设定每个 CTA 的 tile 预算。分配 kernel 会为每个 CTA 的 bin 填充至该预算，然后再溢出到下一个 bin，因此长序列会按其长度比例跨越多个 CTA，而短序列只贡献其实际拥有的 tile。最小工作量下限可防止在总工作量较小时出现过度分区，从而使下游的 combine 保持低成本。任务映射在每个 decode 步骤中根据设备端序列长度生成一次，并在各 Transformer 层之间复用，从而摊薄其开销。

在执行时，每个 CTA 会清空其分配的 bin。对于每个描述符，它会对一个或多个连续的 KV tile 计算 Attention，并写入带有其 log-sum-exp 统计量的部分输出；同一个常驻 CTA 会继续处理下一个描述符，直到其 bin 为空。由于每个 CTA 只为给定请求生成部分结果的一个子集，因此一个最终的 combine kernel 会读取每个请求和 head 的实际 chunk 数量，并在正确的全局 softmax 归一化下合并这些部分结果。近乎相等的 bin 大小确保各 CTA 大致同时完成，从而消除了少数异常长的请求否则会造成的 kernel 尾部。

融合式 attention 前导

对于 Hy3 FP8，HPC-Ops 将 Attention 前导部分融合到 QKV 投影之后：它在 RoPE 之前应用 QK-Norm，以逐 token、逐 head 的缩放因子输出 FP8 格式的 Q，并将 K 和 V 直接写入分页 FP8 缓存。它将量化后的 Q 及其缩放因子直接传递给主 Attention kernel，避免了重新量化。该融合路径消除了中间张量及其相关的 HBM 往返，并在 prefill 和 decode 中省去了单独的 kernel 启动。

Router GEMM：平衡路由精度与吞吐量

Router 精度直接影响 MoE 模型质量。在每个 MoE 层，router 将隐藏状态投影为专家分数，对这些分数进行 top-k 选择来决定哪些专家执行。第 k 个和第 (k+1) 个专家之间的分数差异可能很小，因此该投影的算术精度决定了是否能选出正确的专家。

为保持 router 精度，一些生产模型即使隐藏状态为 BF16，仍保留 FP32 的 router 权重。将这些权重转换为 BF16 可以获得 BF16 Tensor Core 的吞吐量，但会丢弃可能翻转 top-k 决策的低位尾数位。完整的 FP32 GEMM 保留所有权重精度，但 Tensor Core 吞吐量较低。

一种精度感知的 BF16 方案

HPC-Ops 通过将 FP32 权重分解为两个 BF16 分量来解决这一问题。它通过直接截断提取出一个 BF16 高位部分 Whigh，然后从缩放后的残差中构造出第二个 BF16 分量 (W−Whigh)×256。原始权重被近似为 W≈Whigh+Wlow/256，因此矩阵乘积变为两次 BF16 GEMM，其结果通过一个缩放校正进行合并，以恢复低阶尾数贡献。单个 kernel 执行两次 BF16 乘法：它从共享内存中一次性加载激活 tile，在 FP32 寄存器中累加两个部分结果，在 epilogue 中应用 1/256 缩放，并将最终的 FP32 router 分数写入全局内存。这种公式化方法在 BF16 Tensor Core 上执行主要算术运算的同时，恢复了接近完整 FP32 GEMM 的精度。

在框架层面，SGLang 在模型加载时缓存分解后的权重对，并在请求和 CUDA graph 重放之间复用。形状感知调度在实测的交叉点上选择使用 HPC-Ops kernel 还是默认路径。低于这些交叉点时，单一 FP32 路径更快，因为两次乘积的开销超过了 Tensor Core 带来的收益。

MoE：减少小型专家 GEMM 周边的开销

在 decode 阶段，MoE 层中的每个专家只接收少量 token。由此产生的专家 GEMM 规模小且受内存带宽限制，GPU 的 SM 在这些形状下利用率不足。负载不均衡进一步加剧了这一问题：路由到每个专家的 token 数量因专家而异，并且逐步变化，使得难以将这些小而 uneven 的 tile 均匀分配到可用的 SM 上。

除了专家 GEMM 本身之外，围绕它们进行的各项操作也带来了可观的开销。传统的 MoE 路径将多个独立 kernel 串联起来：路由、将 token 收集到各专家缓冲区、Gate-Up GEMM、激活与量化、Down GEMM，以及将 top-k 加权结果归约回 token 位置。收集步骤在任何 matmul 开始之前，就已在 HBM 中物化出一个完整的 token 张量，而后续每个阶段都要为中间结果付出各自的 kernel 启动和 HBM 往返开销。当 GEMM 规模较小时，这些周边开销在该阶段墙钟时间中占据了与之相当的比例。

面向延迟的融合式 MoE 流水线

针对低批量推理，HPC-Ops MoE 后端将路由与索引预处理、Gate-Up、激活与重量化、Down，以及 top-k 加权归约协调在一条低延迟流水线中，该流水线围绕任务映射驱动的持久化专家 GEMM 构建。

• 路由与索引构建。从选定的 top-k 专家 ID 出发，一次共享内存计数遍历将 token–专家分配组织为按专家划分的连续输出区间，从而减轻全局原子操作压力，并构建出持久化专家 GEMM 直接消费的路由索引和逐 tile 任务映射。
• Gate-Up 与激活。Gate-Up GEMM 通过路由索引直接读取原始 token，跳过了独立的收集步骤及其额外的 HBM 流量。随后，SiLU-and-mul 与 FP8 重量化作为一个融合 kernel 运行，其输出由 Down GEMM 直接读取。
• 占用优先，不做 warp 特化。 单个 warp 组同时处理数据搬运和矩阵运算，而不是划分出独立的生产者组和消费者组。这提高了 CTA 驻留率，并将内存延迟隐藏从 CTA 内部的软件流水线转移到跨 CTA 的硬件调度。持久化网格随后消费这些任务映射，将细小且不均匀的专家 tile 分散到各个 SM 上。
• PDL 链式阶段。 程序化依赖启动（Programmatic Dependent Launch）将每个下游 kernel 的启动与前一个阶段的尾部重叠，减少了 Gate-Up、激活、Down 以及最终的 top-k 加权归约之间的间隙，后者将专家输出恢复为 token 顺序。

这些优化共同减少了关键路径上的中间流量和 kernel 启动开销。

从 HPC-Ops kernel 到 SGLang

通过 SGLang 的原生后端和调度接口，HPC-Ops 直接作用于服务运行时已有的状态，同时保持为一个独立维护的算子库。Attention 消费分页 KV 存储和实时的设备端序列元数据，无需额外的布局转换；Router GEMM 在跨请求和 CUDA graph 重放中复用预处理权重和工作区；MoE 遵循 SGLang 的专家 ID 和分区，无需额外重映射。这些集成在保持每个算子预期数据路径的同时，契合了 SGLang 现有的执行模型。

三条集成的算子路径总结如下：

快速开始

本指南介绍如何在 SGLang 中使用 HPC-Ops 的 Attention、Router GEMM 和 MoE 算子。

安装

从源码安装 HPC-Ops：

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

HPC-Ops 已包含在 SGLang 官方的 x86_64 开发镜像中（lmsysorg/sglang:dev，或针对 CUDA 12.9 的 lmsysorg/sglang:dev-cu12），因此使用这些镜像时无需单独安装。

Attention 与 MoE

Attention 和 MoE 在 SGLang 中是相互独立的后端选择，可以分别启用，也可以针对兼容的模型（如 Qwen3 和 Hy3）同时启用。以下示例同时选择了两个 HPC-Ops 后端，并启用了 FP8 KV-cache 的 Attention 路径：

python3 -m sglang.launch_server \
  --model tencent/Hy3-FP8 \
  --tp-size 8 \
  --attention-backend hpc_ops \
  --kv-cache-dtype fp8_e4m3 \
  --page-size 64 \
  --moe-runner-backend hpc_ops

对于 BF16 KV cache，请省略 --kv-cache-dtype fp8_e4m3。若只想使用其中一个 HPC-Ops 算子，只需指定对应的后端选项。

Router GEMM

在 SGLang 中，HPC-Ops Router GEMM 在执行 BF16 Tensor Core 矩阵运算的同时，保留了 FP32 router 权重的低阶信息。该集成路径已在 LongCat-Flash Chat 和 Lite 上完成验证，并会在支持的模型和 router 形状下自动选用。安装 HPC-Ops 后，标准的 LongCat-Flash 启动即可使用它：

python3 -m sglang.launch_server \
  --model meituan-longcat/LongCat-Flash-Lite-FP8

性能评估

HPC-Ops 后端目前支持 NVIDIA Hopper 架构 GPU，并在 H20 上实现最佳性能。以下评估涵盖 H20 上的算子基准测试、8× H20 上的端到端 SGLang 服务，以及上游 SGLang pull request 中报告的 H200 结果。

H20 算子基准测试

Attention。

Attention 调度器最显著的收益体现在混合长度 decode 场景中，此时同一批次内的请求可能具有差异极大的 KV-cache 长度。我们评估了从均匀分布到高度偏斜分布的 FP8 KV-cache decode；表中 A×B 表示 A 个 KV 长度为 B 的请求。为隔离调度效果，我们将 HPC-Ops 动态调度与其静态 split-KV 对应方案进行对比，同时以 FlashInfer 和 FlashAttention 作为额外基线。动态调度相对静态调度的增益随偏斜程度增大而增长，从均匀 64×0.5K 批次上的持平，到 1×128K + 31×4K 混合场景下的 2.95×。在所有六个案例中，动态调度平均比各案例中 FlashInfer 和 FlashAttention 的最优者快 2.25×。

表 1：H20 上不同 KV 长度分布下的解码延迟。越低越好。

图 1：随着实时 KV 工作负载愈发不均衡，动态调度变得越来越有效。越低越好。

Router GEMM。

我们首先用通用的 K=4096,N=192 sweep 来评估 Router GEMM。在所测量的 M 值范围内，HPC-Ops 比 FP32 cuBLAS 快 1.30–3.22×，比 TF32 cuBLAS 快 1.25–1.78×。以 FP32 cuBLAS 作为数值参考，最大绝对误差保持在 0.00177 或以下，而 TF32 为 0.06464。

表 2：在 H20 上 K = 4096、N = 192 时的 BF16 × FP32 Router GEMM 延迟。越低越好。

图 2：Router GEMM 相对于 FP32 cuBLAS 的数值误差（左）以及相对于 FP32 和 TF32 cuBLAS 的延迟（右）。越低越好。

随后我们重新测试了 LongCat-Flash 所使用的两种 router 形状。在 SGLang 的模型感知调度范围内，相较于 SGLang 默认实现，HPC-Ops 为 Chat 形状带来 1.06–2.83× 的加速，为 Lite 形状带来 1.09–2.46× 的加速。

表 3：在 H20 上，LongCat-Flash Router GEMM 在 SGLang 调度范围内的延迟。越低越好。

图 3：在 SGLang 的 dispatch 范围内，LongCat-Flash Chat（左）与 Lite（右）形状下的 Router GEMM 延迟。越低越好。

MoE。

对于 MoE，我们在 Hy3 形状下以 TP8 / EP1 和 TP1 / EP8 配置对完整融合算子进行基准测试，并与 SGLang、vLLM Triton 和 vLLM CUTLASS 进行对比。取每一行三个基线中的最低延迟，HPC-Ops 在 TP8 / EP1 下实现了 1.08× 的平均每批次加速，在 TP1 / EP8 下实现了 1.21× 的平均每批次加速，在低延迟解码中常见的中小批次规模下增益最大。

表 4：H20 上 TP8 / EP1 配置下的 Hy3 MoE 延迟。越低越好。

表 5：Hy3 MoE 在 H20 上 TP1 / EP8 配置下的延迟。越低越好。

图 4：Hy3 MoE 在 TP8 / EP1 与 TP1 / EP8 配置下的延迟。越低越好。

H200 算子验证

上游 PR 还包含 H200 服务结果，证实性能提升在 Hopper GPU 上具有普适性。

表 6：上游 SGLang pull request 中报告的算子验证。

端到端性能

端到端评估在 8× NVIDIA H20 GPU 上运行，对照相应的默认 SGLang 实现。在 Hy3-FP8 上，采用 TP8 与 FP8 KV cache，我们通过同时启用 HPC-Ops Attention 和 MoE 来测量综合服务影响。在 LongCat-Flash-Lite-FP8 上，仅测量 Router GEMM。我们还汇总了上游 SGLang pull request 中报告的 H200 服务验证结果。

Hy3-FP8：Attention 与 MoE。

在 8K 输入和 4K 输出下，HPC-Ops 在 batch size 1 时将 TPOT 降低 3.3%。在 batch size 4–64 范围内，降幅增至 15.1–48.8%。

表 7：启用 FP8 KV cache 以及 HPC-Ops Attention 和 MoE 后的 Hy3-FP8 TPOT。越低越好。

在 8K 输入下，HPC-Ops 在 batch size 1–16 范围内将 TTFT 改善了 3.3–9.0%。

表 8：Hy3-FP8 在 8K 输入下使用 FP8 KV cache 的 TTFT。正向改善意味着延迟更低。

在 batch size 为 16 时，我们还在禁用 chunked prefill 和 prefix caching 的情况下，将输入长度从 2K 扫描到 8K。HPC-Ops 在三种输入长度下将 TTFT 提升了 2.3–8.9%。

表 9：在 batch size 为 16 时，使用 FP8 KV cache 的 Hy3-FP8 TTFT 在不同输入长度下的表现。正向提升表示延迟降低。

LongCat-Flash-Lite-FP8：Router GEMM。

Router GEMM 单独使用 1,024 token 输入和 128 token 输出进行评估。在 batch size 为 1 时，输入吞吐量基本持平，提升了 0.5%，而在 batch size 4–64 范围内则提升了 5.5–6.1%。

表 10：使用 HPC-Ops Router GEMM 的 LongCat-Flash-Lite-FP8 输入吞吐量。越高越好。

图 5：SGLang 端到端结果。三个 Hy3-FP8 面板同时启用了 FP8 KV cache、HPC-Ops Attention 和 MoE；右下角面板单独隔离了 Router GEMM。

H200 服务验证

上游 pull request 还在 H200 上评估了 SGLang 服务循环中集成后的算子，在主要调优目标 H20 之外提供了模型级别的集成检查。

表 11：上游 SGLang pull request 中报告的模型级服务验证。

上游集成也经过了数值和模型层面的保真度检查。注意力测试在 BF16 和 FP8 下均通过，所评估的 Hy3 FP8 贪心输出与 BF16 路径逐 token 一致。Router GEMM 在与 FP32 参考实现的对比中通过，并保持了贪心输出。对于 Qwen3，HPC-Ops MoE 路径与 Triton 相对于 FP32 的误差相当，余弦相似度为 0.99974，最大相对误差为 0.024。完整配置和逐用例结果可在上游 PR 中查看。

下一步

这项工作是 HPC-Ops 与 SGLang 社区更广泛合作的一部分。我们将继续与 SGLang 维护者和贡献者合作，改进和扩展这些算子，并在更多 HPC-Ops 能力成熟后将其上游化。非常欢迎反馈、问题和基准测试，我们期待共同推进开放、高性能的 LLM 推理。

致谢

我们要感谢各团队中众多共同努力将这些算子引入 SGLang 的人：

• 腾讯混元 AI Infra —— 构建并优化了 HPC-Ops 的 Attention、Router GEMM 和 MoE 算子，并将它们贡献给 SGLang。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。
• SGLang——感谢开放的后端接口、评审和设计讨论。Xiaoyu Zhang（BBuf）、Xinyuan Tong、Ke Bao，以及整个 SGLang 团队。
• NVIDIA——感谢在 kernel 与性能优化方面的紧密合作。Yuanhang Sun、Perkz Zheng、Yuxi Chi、Jiang Shao、Jun Gu、Meng Wang、River Liu、Gary Ji、Chandler Zhou。

我们还要感谢更广泛的开源 kernel 社区，本工作建立在其成果之上并与之进行对比评测，包括 NVIDIA CUTLASS/CuTe、TensorRT-LLM、FlashInfer、FlashAttention 和 Triton。