腾讯混元推出的 HPC-Ops 推理算子库，迎来了一次真正的系统性升级。此次更新并非简单的硬件堆叠，而是从单点算子优化演进为一整套覆盖推理全链路的优化能力集合，多项指标全面超越业界主流基线。其目标十分明确：帮助开发者更轻松地构建高吞吐、低延迟的大模型推理服务。更重要的是，这些能力已全部开源，可立即使用。
先算一笔账：端到端 QPM 提升 30%，这意味着更低的成本、更高的效率以及更强的性能表现。
HPC-Ops 是腾讯混元 AI Infra 团队长期维护的一套工业级、高性能大模型推理底层算子库。首次开源时已提供 Attention、GroupGEMM 等高性能算子，原生支持 BF16 及多种 FP8 量化方案。本次升级则针对推理系统在实际业务中遇到的动态负载、精度要求与系统瓶颈，给出了更工程化的解决方案。
图1 HPC-Ops 核心算子升级示意图
本次升级的核心亮点集中在五大算子：Attention、RouterGEMM、FusedMoE、Fused AllReduce+Norm 和 Sampler。每个算子的优化思路都极具针对性，下面逐一拆解。
核心算子更新详解
随着大模型推理系统在业务侧的深入应用，推理优化面临的负载形态、精度要求和系统瓶颈变得更加复杂。HPC-Ops 这次升级的思路清晰明确：一是深度适配线上复杂负载，例如多精度计算与长短请求混排；二是走多算子联合优化的路线。
Attention：动态调度实现负载均衡，根治推理长尾延迟
线上推理请求的长度忽长忽短，在同一个批次中混合出现，容易导致计算不均与长尾延迟问题。传统的静态 split-kv 策略在均匀负载下表现尚可，但一旦进入长上下文混合负载，便显得力不从心——长序列需要更大的拆分才能充分并行，短序列仅需少量拆分，固定策略难以兼顾两者。
针对这一痛点，HPC-Ops 对 Attention 的调度机制进行了全面升级，从传统的固定任务划分迭代为运行时动态调度方案。具体而言，将所有推理请求按统一 Tile 粒度拆分，依据全局 Tile 总量均衡分配各 CTA 任务规模，再通过贪心装桶算法实现极致均分。执行时，Task Assign 模块会在每次推理前生成专属任务映射表，各层 Attention Kernel 依据映射表精准领取并执行任务，最后由 Combine Kernel 统一合并 split-kv 计算结果。
图2 Attention动态调度示意图
这项能力是腾讯混元与 NVIDIA 联合优化的成果，目前已同步适配 HPC-Ops 和 FlashInfer 仓库，可直接落地使用。
RouterGEMM：双 BF16 重构 FP32 计算，兼顾高精度与高性能
在 MoE 路由、稀疏 Attention 等模块中，经常遇到激活为 BF16 而权重为 FP32 的高精度 GEMM 计算。若将权重降精度参与计算，数值敏感的算子难以满足精度要求，会影响模型效果；若将激活升精度至 FP32 或 TF32，又会引入额外的类型转换开销，且纯 FP32 计算只能使用 CUDA Core，硬件利用率受限。
HPC-Ops 给出的方案是：通过双 BF16 GEMM 组合模拟 FP32 精度。离线阶段将 FP32 权重拆分为高位 BF16 和低位残差 BF16 两组张量，推理时执行两次 BF16 GEMM 并做线性组合。这样一来，激活值全程保持 BF16，无需类型转换，且两路矩阵乘都运行在 BF16 Tensor Core 上，算力利用率得到充分释放。
更进一步，实现时将双路计算融合到单一 Kernel 中：输入数据只搬运一次，通过双寄存器累加器分别缓存两路中间结果，最后经过一次 FMA 修正输出高精度结果，全程无中间结果的 HBM 往返开销。
图3 Router GEMM算子原理和设计架构图
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 启动带来的冗余开销。
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 推理场景。
Sampler：极致大算子融合，终结后处理性能瓶颈
传统的采样后处理往往需要十多个 Kernel 串联，流程碎片化、冗余开销大。HPC-Ops 推出的 fused_sampler 算子，将重复惩罚、温度缩放、Top-K、Top-P、Softmax、随机采样这全流程能力，端到端融合为 2 个核心 CUDA Kernel，并封装为单一算子。针对差异化业务场景还提供了更精简的专用内核，算子内可自动适配调度。
这次优化的性能增益主要来自五大维度：
- 全流程内核融合，将采样场景全局词表大小的 GPU 加载次数压缩至 1 次，且计算访存充分掩盖；
- 在 GPU 内部闭环完成重复惩罚掩码计算，无需 CPU-GPU 数据拷贝，消除了重复惩罚阶段的最大开销；
- 采用细粒度并行策略，将单请求拆分至多线程块并行执行，小批次场景并发度提升，推理延迟大幅降低；
- 优化 Top-K 计算逻辑，当 MaxTop-K ≤64 时，通过局部堆归并替代全局阈值扫描或拒绝采样，避免全词表重复读取；
- 合并计算链路，将 Top-K 归约过程与 Softmax 最大/求和计算融合，进一步削减加载和计算开销。
性能结果
实验设置：以下性能数据均在 CUDA13 环境采集，PyTorch 版本为 Torch2.11.0+cu130。各算子按照对应线上典型规格、并行配置和精度格式进行单算子测试。图中 latency 均表示算子级耗时，数值越低代表性能越好。
Attention：
在 Decode 阶段，请求长度实时波动和 batch 内长短请求混排会带来明显的负载不均。基于真实场景数据，动态调度方案在单 batch 长文本场景下单算子最高加速 2.95x，在混合长度 batch 场景下加速 1.59x~1.76x；端到端服务压测中，QPM 最高提升 17%。
图4 Attention性能对比图
Router GEMM：
在 N=192、K=4096 的典型路由 GEMM 测试中，HPC-Ops RouterGEMM 在 M=2~4096 范围内最大绝对误差不超过 0.00177；TF32 (cuBLAS) 对应最大绝对误差最高约 0.06464，约为 HPC-Ops 的数十倍。性能方面，HPC-Ops 相比 FP32 (cuBLAS) 在 M=512 处最高获得 3.22x 加速，在 M=4096 处仍保持 2.86x 加速；相比 TF32 (cuBLAS) 也可获得最高约 1.78x 的性能收益。
图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~32ktokens 的 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 能力体系，帮助全球研究者和工程团队以更低成本、更高效率搭建高吞吐、低延迟的大模型推理服务，推动大模型推理系统的性能边界不断突破。