LMSYS：Blog（Chatbot Arena 团队）

精选

AI 编辑部评分，满分 100

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

2026-08-08 01:51· 8分钟前· Tencent Hunyuan AI Infra and the SGLang Team

AI 导读

腾讯混元开源算子库 HPC-Ops 已集成至 SGLang 主分支，其 Dynamic Attention 与 Fused MoE 在 Hy3 模型上最高降低 TPOT 48.8%。

推荐理由

HPC-Ops 集成到 SGLang，带来生产验证的负载均衡 Attention 和精度感知 Router GEMM，实测 Hy3 TPOT 降幅最高 48.8%，为 MoE 低延迟服务提供了可直接使用的开源优化。

正文 · AI 翻译

HPC-Ops 是一个面向大语言模型推理的开源算子库，已部署于腾讯的大规模生产服务中。其核心算子（包括 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 上，针对 Hy3，HPC-Ops 在 TP8 / EP1 配置下相比 SGLang 和 vLLM 基线中的最优者实现了平均每批次 1.08× 的加速，在 TP1 / EP8 配置下实现了 1.21× 的加速。在上游 Qwen3/H200 内核基准测试中，在八个 token 时，它相比 Triton 最高达到 4.21× 的加速。
端到端推理服务：在 8× H20 搭配 Hy3-FP8 的环境下，同时启用 HPC-Ops Attention 和 MoE，在批大小 4–64 时可将 TPOT 降低 15.1–48.8%，在批大小 4–16 时可将 TTFT 降低 3.3–6.0%。在 8× H20 搭配 LongCat-Flash-Lite-FP8 的环境下，启用 HPC-Ops Router GEMM 在批大小 4–64 时可将输入吞吐量提升 5.5–6.1%。

Attention、路由和专家：MoE 模型推理服务中的三条关键路径

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

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

HPC-Ops 针对每个阶段都设计了专门的算子：针对 Attention 的工作负载感知调度、针对 Router GEMM 的精度感知公式化，以及针对 MoE 的融合流水线，后者消除了独立的 gather 操作，并减少了启动和中间流量。上游集成通过 SGLang 的原生后端和调度接口，将这些算子与 SGLang 的服务运行时配对。以下章节将说明每个算子是如何设计的。

Attention：混合长度解码的负载均衡

在解码阶段，每个新 token 都要对整个请求的 KV 缓存进行注意力计算，因此 Attention 的计算量随实时序列长度增长。一个缓存了 16K token 的请求，其 KV 计算量大约是缓存 1K token 请求的 16 倍。在生产环境中，提示词和输出长度差异很大，而连续批处理会将处于不同生成阶段的请求放入同一次启动中；因此，一个批次通常会混合短 KV 缓存和长达数万 token 的序列。

静态 split-KV 调度将工作映射到 KV 头、请求和 KV 块上的固定启动网格，整个批次共享一种分区策略。静态 split-KV 调度器通常遵循两种策略之一，但两者在混合长度批次上表现都不佳。（1）固定拆分数量时，长请求会产生更重的块：短请求的 CTA 提前完成，而少数长运行的 CTA 决定了内核的尾部延迟。（2）改为固定块大小时，网格必须为最长请求预留足够的拆分，导致较短请求出现空块或近乎空的块，却仍然占用调度槽位。一种策略造成工作不均；另一种策略则调度了不存在的工作。

围绕实时 KV 工作进行调度

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

在执行阶段，每个 CTA 负责清空其分配到的分箱。对于每一条描述符，它会在一个或多个连续的 KV tile 上计算 Attention，并连同其 log-sum-exp 统计量一起写出部分输出；该常驻 CTA 会继续处理下一条描述符，直到其分箱为空。由于每个 CTA 仅为给定请求生成部分输出的一个子集，因此最终的合并内核会读取每个请求和每个注意力头的实际块数，并在正确的全局 softmax 归一化下合并这些部分输出。近乎均等的分箱大小可确保各 CTA 大致同时完成，从而消除少数异常长请求原本会引发的内核尾部效应。

融合的 Attention 前奏

对于 Hy3 FP8，HPC-Ops 将 Attention 前奏融合在 QKV 投影之后：它在 RoPE 之前应用 QK-Norm，以按 token、按头的缩放因子将 Q 输出为 FP8，并将 K 和 V 直接写入分页 FP8 缓存。它将量化后的 Q 及其缩放因子直接传递给主 Attention 内核，从而避免重新量化。该融合路径消除了中间张量及其相关的 HBM 往返，以及 prefill 和 decode 阶段中各自独立的内核启动。

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 高位部分，然后利用缩放后的残差构成第二个 BF16 分量。原始权重被近似为两者之和，因此矩阵乘积变为两次 BF16 GEMM，其结果通过缩放校正合并，以恢复低阶尾数的贡献。单个内核同时执行两次 BF16 乘法：它从共享内存中一次性加载激活块，在 FP32 寄存器中累加两个部分结果，在收尾阶段应用缩放，并将最终的 FP32 路由分数写入全局内存。这种设计在 BF16 Tensor Core 上执行主要算术运算的同时，恢复了接近完整 FP32 GEMM 的精度。 $W_{h i g h}$ $(W - W_{h i g h}) \times 256$ $W \approx W_{h i g h} + W_{l o w} / 256$ $1 / 256$

在框架层面，SGLang 在模型加载时缓存分解后的权重对，并在请求和 CUDA 图重放之间复用。一个感知形状的调度器在实测交叉点处选择 HPC-Ops 内核或默认路径。在交叉点以下，单一 FP32 路径更快，因为双乘积的开销超过了 Tensor Core 带来的增益。

MoE：降低小型专家 GEMM 周围的额外开销

在解码阶段，MoE 层中的每个专家仅接收少量 token。由此产生的专家 GEMM 规模小且受内存带宽限制，GPU 的 SM 在这些形状下利用率不足。负载不均衡使问题更加严重：路由到每个专家的 token 数量因专家而异，且随步骤变化，这使得将这些小而形状不均的块均匀分布到可用 SM 上变得困难。

除了专家 GEMM 本身，围绕它们的操作也引入了大量额外开销。传统的 MoE 路径将路由、将 token 收集到各专家缓冲区、Gate-Up GEMM、激活与量化、Down GEMM 以及将 top-k 加权归约回 token 位置等操作串联为多个独立内核。收集步骤在任何矩阵乘法开始之前，就在 HBM 中物化出完整的 token 张量，而后续每个阶段都要承担自身的内核启动和中间结果的 HBM 往返开销。当 GEMM 规模较小时，这些周边开销消耗了该阶段相当比例的墙钟时间。

一个融合的、面向延迟优化的 MoE 流水线

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

路由与索引构建。从选定的 top-k 专家 ID 出发，通过共享内存计数遍历将 token–专家分配整理为连续的按专家划分的输出区间，从而降低全局原子操作压力，并构建路由索引和按 tile 划分的任务映射，供持久化专家 GEMM 直接消费。
Gate-Up 与激活。Gate-Up GEMM 通过路由索引直接读取原始 token，省去了独立的 gather 操作及其额外的 HBM 流量。随后 SiLU-and-mul 与 FP8 重量化作为单个融合内核运行，其输出由 Down GEMM 直接读取。
以占用率为先，不采用 warp 特化。由单个 warp 组同时负责数据搬运和矩阵运算，而非预留独立的 producer 与 consumer 组。这提高了 CTA 驻留率，并将内存延迟隐藏从 CTA 内软件流水线转移到跨 CTA 硬件调度。持久化网格随后消费这些任务映射，将小而参差不齐的专家 tile 分布到各 SM 上。
PDL 链式阶段。Programmatic Dependent Launch 将每个下游内核的启动与前一阶段的尾部重叠，缩小 Gate-Up、激活、Down 以及最终 top-k 加权归约（将专家输出恢复为 token 顺序）之间的间隙。

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

从 HPC-Ops 内核到 SGLang

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

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

HPC-Ops 算子	优化内容	精度	上游 PR
Attention	负载均衡的混合长度解码，以及融合的 QK-Norm、RoPE、量化和 KV 写入前序操作	BF16 激活值；BF16 或 FP8 E4M3 KV cache	#30540, #32304
Router GEMM	使用 BF16 Tensor Core 进行精度感知的路由投影，同时保留 FP32 权重信息	BF16 激活值 × FP32 权重 → FP32 分数	#30247, #31943
MoE	针对小型且不均衡的专家 GEMM 的低开销执行	BF16 隐藏状态；FP8 E4M3 专家权重	#30541

快速开始

本指南介绍如何在 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 路由权重的低阶信息。该集成路径已在 LongCat-Flash Chat 和 Lite 上完成验证，并会对受支持的模型和路由形状自动选择启用。一旦安装 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 拉取请求中报告的 H200 结果。

H20 算子基准测试

注意力机制。

注意力调度器的核心优势体现在混合长度解码场景中，即同一批次内的请求可能具有差异极大的 KV 缓存长度。我们评估了从均匀分布到高度偏斜分布的 FP8 KV 缓存解码；表中 A×B 表示 A 个请求，每个请求的 KV 长度为 B。为隔离调度效果的影响，我们将 HPC-Ops 动态调度与其静态拆分 KV 方案进行对比，同时以 FlashInfer 和 FlashAttention 作为额外基线。动态与静态相比的增益随偏斜度增加而增长，从均匀 64×0.5K 批次下的持平，到 1×128K + 31×4K 混合场景下的 2.95 倍。在所有六种情况下，动态调度平均比每种情况下 FlashInfer 和 FlashAttention 中的最优者快 2.25 倍。

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

解码场景	HPC-Ops 动态	HPC-Ops 静态	FlashInfer	FlashAttention	动态 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×

H20 mixed-length Attention decode latency

图 1：随着实时 KV 工作负载偏斜度增加，动态调度的效果愈发显著。数值越低越好。

路由 GEMM。

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

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

M	HPC-Ops	FP32 cuBLAS	TF32 cuBLAS	相对 FP32 的加速比	相对 TF32 的加速比
1	11.200 µs	14.576 µs	14.048 µs	1.30×	1.25×
16	11.744 µs	23.808 µs	18.752 µs	2.03×	1.60×
48	12.144 µs	31.008 µs	20.064 µs	2.55×	1.65×
96	13.904 µs	31.760 µs	24.720 µs	2.28×	1.78×
208	17.088 µs	39.280 µs	28.928 µs	2.30×	1.69×
512	26.992 µs	86.976 µs	44.736 µs	3.22×	1.66×
1024	50.640 µs	110.480 µs	68.544 µs	2.18×	1.35×
2048	76.688 µs	198.576 µs	100.800 µs	2.59×	1.31×
4096	141.120 µs	403.728 µs	205.760 µs	2.86×	1.46×

H20 Router GEMM numerical error and cuBLAS latency

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

随后，我们重新测试了 LongCat-Flash 使用的两种路由形状。在 SGLang 的模型感知调度范围内，与 SGLang 默认实现相比，HPC-Ops 在 Chat 形状上实现了 1.06–2.83 倍的加速，在 Lite 形状上实现了 1.09–2.46 倍的加速。

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

M	Chat 默认	Chat HPC-Ops	加速比	Lite 默认	Lite HPC-Ops	加速比
64	39.19 µs	37.01 µs	1.06×	—	—	—
128	74.18 µs	59.36 µs	1.25×	25.83 µs	23.72 µs	1.09×
256	100.03 µs	82.47 µs	1.21×	41.87 µs	34.01 µs	1.23×
512	190.37 µs	141.73 µs	1.34×	71.89 µs	41.95 µs	1.71×
1024	380.68 µs	207.00 µs	1.84×	108.64 µs	74.09 µs	1.47×
2048	961.15 µs	339.04 µs	2.83×	235.81 µs	106.81 µs	2.21×
4096	1469.70 µs	670.14 µs	2.19×	423.52 µs	172.44 µs	2.46×
8192	2881.00 µs	1333.84 µs	2.16×	835.22 µs	339.66 µs	2.46×

H20 LongCat-Flash Router GEMM latency

图 3：在 SGLang 调度范围内，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 延迟。数值越低越好。

批次	HPC-Ops	SGLang	vLLM Triton	vLLM CUTLASS	相对最优加速比
16	85.7 µs	88.6 µs	124.2 µs	209.2 µs	1.03×
32	124.0 µs	137.2 µs	184.3 µs	275.6 µs	1.11×
64	147.2 µs	164.4 µs	374.9 µs	330.3 µs	1.12×
128	161.5 µs	179.9 µs	302.9 µs	345.3 µs	1.11×
256	170.1 µs	191.5 µs	310.9 µs	351.6 µs	1.13×
512	194.5 µs	230.1 µs	331.6 µs	369.2 µs	1.18×
1024	281.4 µs	300.5 µs	652.7 µs	438.3 µs	1.07×
2048	491.8 µs	522.5 µs	731.5 µs	794.4 µs	1.06×
4096	872.0 µs	899.2 µs	1366.0 µs	1230.7 µs	1.03×
8192	1695.0 µs	1712.7 µs	2216.8 µs	2362.9 µs	1.01×
16384	3241.9 µs	3257.1 µs	4329.1 µs	4364.4 µs	1.00×

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

批次	HPC-Ops	SGLang	vLLM Triton	vLLM CUTLASS	相对最优加速比
4	118.6 µs	183.1 µs	147.4 µs	140.4 µs	1.18×
8	136.7 µs	231.5 µs	192.8 µs	170.7 µs	1.25×
16	149.8 µs	234.2 µs	198.4 µs	263.5 µs	1.32×
32	153.6 µs	475.3 µs	214.6 µs	264.4 µs	1.40×
64	166.5 µs	477.3 µs	358.1 µs	266.8 µs	1.60×
128	213.5 µs	482.3 µs	251.7 µs	272.6 µs	1.18×
256	386.2 µs	494.3 µs	454.9 µs	493.5 µs	1.18×
512	705.5 µs	970.7 µs	691.7 µs	741.7 µs	0.98×
1024	1342.6 µs	1476.8 µs	1369.1 µs	1359.1 µs	1.01×
2048	2513.9 µs	2871.2 µs	2668.7 µs	2530.4 µs	1.01×

H20 Hy3 MoE latency

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

H200 算子验证

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

表 6：上游 SGLang 拉取请求中报告的算子验证结果。

算子	上游验证工作负载	对比	结果
FP8 Attention	使用 FP8 KV cache 的 Hy3-FP8；混合长度解码	HPC-Ops 动态调度 vs. HPC-Ops 静态 split-KV	输出吞吐量 +2.0%；总吞吐量 +2.0%；中位 TTFT −5.3%
BF16 Attention	使用 BF16 KV cache 的 Qwen3；混合长度解码	HPC-Ops 动态调度 vs. HPC-Ops 静态 split-KV	输出吞吐量 +3.0%；平均端到端延迟 −2.8%；平均 TPOT −2.8%
Router GEMM	LongCat-Flash Chat 与 Lite 路由器的形态	HPC-Ops 路由器 GEMM 与 SGLang 默认实现的对比	内核加速比：1.56–4.31×
MoE	Qwen3 FP8 MoE 工作负载，token 数从 1 到 4,096	HPC-Ops MoE 与 SGLang Triton 融合专家模块的对比	内核加速比：0.89–4.21×

端到端性能

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

Hy3-FP8：Attention 与 MoE。

在 8K 输入和 4K 输出的情况下，HPC-Ops 在 batch size 为 1 时将 TPOT 降低了 3.3%。在 batch size 4–64 范围内，降幅扩大到 15.1–48.8%。

表 7：Hy3-FP8 在启用 FP8 KV cache 并同时启用 HPC-Ops Attention 和 MoE 时的 TPOT。数值越低越好。

Batch	SGLang 默认	HPC-Ops	提升幅度
1	7.56 ms	7.31 ms	3.3%
4	11.10 ms	9.42 ms	15.1%
8	14.29 ms	10.76 ms	24.7%
16	22.90 ms	13.09 ms	42.8%
32	35.33 ms	18.09 ms	48.8%
64	40.70 ms	23.81 ms	41.5%

在 8K 输入的情况下，HPC-Ops 在 batch size 1–16 范围内将 TTFT 提升了 3.3–9.0%。

表 8：Hy3-FP8 在 8K 输入、启用 FP8 KV cache 时的 TTFT。正提升值表示延迟更低。

Batch	SGLang 默认	HPC-Ops	提升幅度
1	460.67 ms	419.43 ms	9.0%
4	1612.47 ms	1533.66 ms	4.9%
8	3210.93 ms	3018.68 ms	6.0%
16	5810.53 ms	5619.48 ms	3.3%

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

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

输入长度	SGLang 默认	HPC-Ops	提升幅度
2K	1509.98 ms	1375.95 ms	8.9%
4K	2779.46 ms	2715.18 ms	2.3%
8K	5810.53 ms	5619.48 ms	3.3%

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：LongCat-Flash-Lite-FP8 在启用 HPC-Ops Router GEMM 时的输入吞吐量。数值越高越好。

Batch	SGLang 默认	HPC-Ops Router GEMM	提升幅度
1	16,612.11 tok/s	16,695.77 tok/s	0.5%
4	54,466.27 tok/s	57,810.27 tok/s	6.1%
8	60,425.93 tok/s	63,833.96 tok/s	5.6%
16	61,995.23 tok/s	65,539.10 tok/s	5.7%
32	62,833.85 tok/s	66,306.52 tok/s	5.5%
64	62,841.93 tok/s	66,422.92 tok/s	5.7%

H20 SGLang end-to-end performance

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

H200 服务验证

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

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

算子	上游验证工作负载	对比	结果
Attention	Hy3-FP8 搭配 FP8 KV cache 的服务工作负载	HPC-Ops Attention 对比 FlashAttention	输出吞吐量：+3.7–5.9%
Router GEMM	LongCat-Flash Lite 预填充服务工作负载	HPC-Ops Router GEMM 对比 SGLang 默认实现	输入吞吐量：+2.8–5.4%
MoE	Qwen3 和 Hy3 FP8 MoE 服务工作负载	HPC-Ops MoE 对比 SGLang 默认实现	输出吞吐量：Qwen3 从持平到 +2.7%；Hy3 −4.2% 到 +6.3%

上游集成还经过了数值和模型级保真度检查。Attention 测试在 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。我们非常欢迎反馈、问题和基准测试，并期待共同推进开放、高性能的大语言模型推理。

致谢

我们感谢跨团队众多人士的通力合作，将这些算子引入 SGLang：

腾讯混元 AI 基础设施团队——负责构建和优化 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——感谢在内核和性能优化方面的紧密合作。团队成员：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。

产品更新开源生态推理

来源：LMSYS：Blog（Chatbot Arena 团队） · lmsys.org

导出 Markdown