腾讯混元AI Infra进化：HPC-Ops推理核心算子全面升级

大模型推理底层算子库 HPC-Ops 迎来了一次重大版本升级。这次并非小修小补，而是直接推出了五个关键算子，精准针对线上真实业务负载中的工程痛点——Attention 长尾延迟、显存搬运、跨卡通信——给出了高效解决方案。从实测数据来看，多项性能指标已明显超越现有开源方案。

一、 背景与成果介绍

HPC-Ops 是腾讯混元 AI Infra 团队开源并长期维护的一套工业级大模型推理底层算子库。首轮开源时已提供了 Attention、GroupGEMM 等高性能算子，原生支持 BF16 及多种 FP8 量化格式，针对主流推理硬件进行了深度优化适配。

本次升级的核心目标是让推理系统更好地适应动态负载、更高精度以及更紧密的耦合。具体而言，包含五大算子：动态调度 Attention、双 BF16 组合模拟 FP32 精度的 RouterGEMM、全链路融合的 FusedMoE、通信计算合一的 Fused AllReduce+Norm，以及将后处理流程压缩到极致的大算子 Sampler。下面逐一解读。

图1 HPC-Ops 核心算子升级示意图

• Attention：针对长短请求混排导致的计算不均衡问题，采用运行时动态负载调度策略，长文本处理最高加速 2.95x，端到端 QPM 提升 17%。
• RouterGEMM：双 BF16 GEMM 组合实现 FP32 级精度，精度优于常规 BF16/TF32，相比 CuBLAS FP32 最高提速 3.22x。
• FusedMoE：MoE 全模块流水线整合，消除显存搬运与内核启动开销，相较 vLLM、SGLang 等框架性能提升 1.2x～1.6x。
• Fused AllReduce+Norm：深度融合通信、残差与归一化，相比 NCCL、FlashInfer 性能提升 1.04x～1.68x。
• Sampler：将解码阶段原本十多个操作算子融合为 2 个 CUDA Kernel，相比 vLLM 提速 4.0x～7.5x，较 FlashInfer 提速 1.9x～4.7x。

HPC-Ops 将持续开放经过真实业务验证的高性能算子，为社区提供更贴近生产实践的优化参考。欢迎社区伙伴积极参与开源共建！

项目地址：https://github.com/Tencent/hpc-ops

二、核心算子更新详解

随着大模型推理在业务侧的深入，负载形态、精度要求和系统瓶颈日益复杂。本次更新围绕两条工程主线：深度适配线上复杂负载（多精度、长短请求混排）和多算子联合优化。五大核心算子具体如下：

1. Attention：动态调度负载均衡，根治推理长尾延迟

线上推理的典型痛点是请求长度实时波动，batch 内长短请求混杂。传统静态 split-kv 对均匀负载有效，但一旦遇到长上下文混合负载，固定策略难以兼顾：长序列需要大 split-kv 来并行，短序列则只需少量拆分。HPC-Ops 此次对 Attention 调度进行了彻底升级——从固定任务划分转为运行时动态调度。

方案先将所有请求按统一 Tile 粒度拆分，根据全局 Tile 总量均衡分配各 CTA 任务量，然后采用贪心装桶算法实现极致均分，从源头消除计算单元负载失衡。执行时，Task Assign 模块每次推理前生成专属任务映射表，各层 Attention Kernel 按表领取任务，最后用 Combine Kernel 合并 split-kv 结果。全流程负载均衡，协同高效。

图2 Attention动态调度示意图

该能力由腾讯混元 AI Infra 团队与 NVIDIA 联合打磨，针对动态负载建模、Tile 粒度适配、CTA 任务均衡进行了多轮精细调优。目前已完成适配 HPC-Ops 和 FlashInfer，可直接用于线上真实场景。

2. RouterGEMM：双BF16重构FP32计算，兼顾高精度与高性能

MoE 路由、稀疏 Attention 等模块中，常见激活为 BF16、权重为 FP32 的高精度 GEMM。若直接降低权重精度，则精度不足影响模型效果；若将激活升至 FP32 或 TF32，则需逐元素类型转换，增加带宽和算力开销，且纯 FP32 只能使用 CUDA Core，硬件利用率受限。

HPC-Ops 的解法是双 BF16 GEMM 组合模拟 FP32 精度。离线阶段将 FP32 权重拆成高位 BF16 和低位残差 BF16 两组张量：W ≈ W_high + scale × W_low（scale=1/256，对齐 BF16 的 8 位尾数）。推理阶段执行两次 BF16 GEMM 后线性组合，激活全程保持 BF16，无需类型转换，两路矩阵乘均在 BF16 Tensor Core 上运行，算力利用率充分释放。更进一步，实现时将双路融合到单一 Kernel：输入数据仅搬运一次，用双寄存器累加器分别缓存两路中间结果，Epilogue 阶段一次 FMA 修正出高精度结果写入显存，全程无中间结果 HBM 往返。

图3 Router gemm算子原理和设计架构图

3. FusedMoE：全算子流水线重构，极致压缩推理开销

HPC-Ops 将 MoE 完整推理链路进行了深度融合和执行逻辑重排，重构出全新的流水线架构：路由与索引预处理、Gate-Up GEMM、激活量化、Down GEMM、Top-K 加权聚合，五大核心阶段整合成紧凑的一体化执行链路，彻底解决传统方案多阶段拆分带来的冗余开销。

路由与索引预处理阶段利用共享内存分块统计，为每个专家预留连续显存输出区间，大幅降低大规模 Token 输入下的索引构建成本。Gate-Up GEMM 阶段直接通过路由索引读取原始输入数据，省去独立 Gather 数据搬运；同时取消 Warp Specialization，让同一个 WarpGroup 完成数据搬运与计算，访存延迟掩盖从 CTA 内软件流水线升级为跨 CTA 硬件调度，单 SM 可驻留线程块数量明显提升，硬件资源利用率最大化。

推理中，激活量化结果按专家维度紧凑写入显存，Down GEMM 无缝读取、高效计算，末端完成 Top-K 加权聚合。全流程通过 PDL 技术串联成无气泡执行链路，频繁 Kernel 启动的冗余开销被显著消除。

4. Fused AllReduce+Norm：通信计算深度融合，打通张量并行瓶颈

张量并行场景中，通信、残差计算、归一化拆分执行会造成性能损耗。HPC-Ops 联合腾讯网络平台部，创新实现了 AllReduce 通信、残差相加、RMSNorm 归一化的全链路融合计算，封装成 NVLink 原生一体化操作：RMSNorm(AllReduce(x)+ residual, weight)。双方围绕通信拓扑优化、P2P 同步、计算与通信融合逻辑协同打磨，让原本分段执行的离散链路变成一体化高效率运行。

该能力基于 CUDA 多播 (multimem) 和 P2P 点对点技术构建，原生支持 BF16 精度与单节点多 GPU 部署，采用 Reduce-Scatter + All-Gather 的 two-shot 高效执行策略。同时针对不同推理场景提供两套差异化方案：

• 高吞吐版本（fuse_allreduce_rmsnorm_high_throughput）：依托 NVSwitch 多播机制完成归约，适合大规模 Token 的 Prefill 预处理。
• 低延迟版本（fuse_allreduce_rmsnorm_low_latency）：基于 Lamport P2P 机制，通过 PDL 实现双 Kernel 重叠执行，适合小批量 Token 的 Decode 推理。

5. Sampler：极致大算子融合，终结后处理性能瓶颈

传统采样后处理多 Kernel 串联、流程碎片化，冗余开销大。HPC-Ops 推出 fused_sampler 算子，把主流框架中十多个零碎 Kernel 实现的重复惩罚、温度缩放、Top-K、Top-P、Softmax、随机采样全流程，端到端融合成 2 个核心 CUDA Kernel，封装为单一算子。针对不同业务场景提供更精简专用内核，算子内自动适配调度，最大化释放 GPU 算力。性能增益主要来自五个维度：

1. 全流程内核融合，采样场景全局词表大小的 GPU 加载次数压缩到 1 次，计算访存充分掩盖。
2. GPU 内部闭环完成重复惩罚掩码计算，无需 CPU-GPU 数据拷贝，消除了重复惩罚阶段的最大开销。
3. 细粒度并行策略，单请求拆分到多线程块并行执行，小批次场景并发度提升，推理延迟大幅降低。
4. 优化 Top-K 计算逻辑，当 MaxTop-K ≤64 时，用局部堆归并替代全局阈值扫描或拒绝采样，避免全词表重复读取，减少比较次数。
5. 合并计算链路，将 Top-K 归约过程与 Softmax 最大/求和计算融合，进一步削减加载和计算开销。

三、性能结果

以下数据均在 CUDA13 环境采集，PyTorch 版本为 Torch2.11.0+cu130。各算子按对应线上典型规格、并行配置和精度格式进行单算子测试；图中 latency 表示算子级耗时，数值越低越好。

Attention

Decode 阶段请求长度实时波动、batch 内长短请求混排会带来明显负载不均。基于真实场景数据，动态调度方案在单 batch 长文本场景下单算子最高加速 2.95x，在混合长度 batch 场景下加速 1.59x~1.76x；端到端服务压测中，QPM 最高提升 17%。该能力已同步适配 HPC-Ops 与 FlashInfer，可直接用于在线推理中的长尾延迟治理。

图4 Attention性能对比图

Router GEMM

在 N=192、K=4096 的典型路由 GEMM 测试中，HPC-Ops RouterGEMM 在 M=2~4096 范围内最大绝对误差不超过 0.00177；TF32(cuBLAS) 对应最大绝对误差最高约 0.06464，约为 HPC-Ops 的数十倍。性能方面，相比 FP32(cuBLAS) 在 M=512 处最高获得 3.22x 加速，在 M=4096 处仍保持 2.86x 加速；相比 TF32(cuBLAS) 也可获得最高约 1.78x 的性能收益，适合 MoE Router GEMM 等精度敏感场景。

图5 Router GEMM误差对比图

图6 Router GEMM性能对比图

FusedMoE

基于 DeepSeek-V3、Hy3preview、Qwen3-235B 等典型 MoE 模型实测，在 per-tensor FP8 配置下，HPC-Ops FusedMoE 相比 vLLM CUTLASS、vLLM Triton 和 SGLang 当前实现，TP=8/EP=1 场景整体获得约 1.5x~1.6x 的性能收益，TP=1/EP=8 场景获得约 1.2x~1.5x 的性能收益，并保持输出精度一致。

图7 FusedMoE性能对比图

Fused AllReduce+Norm

测试覆盖了 8~32k tokens 的 TP8 张量并行场景。小 token 场景下，低延迟模式可将通信后处理链路压缩到约 9~13us；大 token 场景下，高吞吐模式借助 NVSwitch multicast 能力获得更高带宽利用率。相比 NCCL 与 FlashInfer 同类路径，实测最高获得约 1.68x 的性能收益，有效缓解张量并行通信及后处理瓶颈。

图8 Fused AllReduce+Norm性能对比图

Sampler

以下展示了三种 Sampler 方法基于两组真实业务参数在不同 batch 下的性能。简单的温度采样场景下，HPC-Ops Sampler 相比 vLLM/PyTorch 与 FlashInfer 平均提升约 5.2x、2.6x；启用了各种采样测量的完整采样场景下，相比 vLLM/PyTorch 与 FlashInfer 平均提升约 5.4x、2.6x。无论 batch 大小和场景复杂度，采样算子均有较大的性能收益。

图9 Sampler性能对比图

四、结语

从首轮开源聚焦单点高性能算子，到本轮实现推理全链路核心能力的系统性升级，HPC-Ops 已经从单一高性能算子库，全面进化为覆盖大模型推理全流程、兼顾精度与速度、适配规模化生产落地的系统级推理优化能力集合。

本次所有优化能力，均沉淀自腾讯混元 AI Infra 团队长期的线上生产实践，深度适配真实、复杂的大规模推理业务场景，并且全部正式开源、面向社区开放共享。未来团队将持续深耕大模型推理底层核心技术，不断迭代 HPC-Ops 能力体系，助力全球研究者和工程团队以更低成本、更高效率搭建高吞吐、低时延的大模型推理服务。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：腾讯混元AI Infra进化：HPC-Ops推理核心算子全面升级要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题