大模型推理优化这个赛道，2024 年之前大家还在聊 FlashAttention、PagedAttention 这类学术级突破，2025 年画风一转，变成了各路大厂把生产线上跑出来的私货直接开源——拼的不是谁的理论更优雅，而是谁的 Kernel 真的扛过双十一级别的流量。腾讯混元 AI Infra 团队这波放出的 HPC-Ops 升级版推理算子库，就是典型的「产线战损总结」：Attention、Router GEMM、FusedMoE、AllReduce+Norm、Sampler 五个核心算子，每一个都带着明确的性能数字和对比基线，而且全部开了源。对正在做推理部署的工程团队来说，这批代码不需要从零读论文推导，直接 fork 就能塞进自己的推理栈里。
Attention 算子：动态调度吃掉长尾
长文本推理的头号杀手是延迟毛刺
做大模型推理服务的人都有体会——平均延迟好优化，P99 延迟才是真正的噩梦。尤其当输入序列拉到 32K、64K 甚至更长，Attention 计算的负载在不同请求之间差异巨大：有的请求刚起头，有的已经进入 Prefill 中段，传统静态调度方案下 GPU 算力被严重碎片化，长尾延迟动辄是均值的 3～5 倍。混元这套 Attention 算子把改动重点放在运行时调度层，而不是 kernel 本身的数学公式。它在每个 batch 执行前会先做一轮轻量级的负载画像，识别出当前请求序列长度的分布特征，再动态决定每个 SM 上分配多少线程块、Prefill 和 Decode 阶段是否需要交错执行。这种「先看一眼再动手」的策略，让长文本场景下的端到端推理吞吐最高拉到原来的 2.95 倍，整体 QPM（每分钟 Query 数）也涨了 17 个百分点。值得注意的是，性能增益不是靠堆算力换来的，而是调度策略本身的精细度提升——这对显存受限的消费级显卡同样有效。
对比 vLLM 和 SGLang 的实际表现
放眼市面上的开源推理框架，vLLM 和 SGLang 是绕不开的两个参照系。混元团队给出的对比数据相当硬：同样硬件配置、同样模型权重，在 64K 长文本基准下，HPC-Ops 的 Attention 算子单算子性能领先 vLLM 约 1.4 倍，相对 SGLang 的优势在 Decode 重负载场景下能拉到 1.6 倍以上。这套对比的关键在于测试条件足够透明——所有 benchmark 脚本都随仓库一并开源，工程团队可以拿自己的真实业务流量跑一遍验证，而不是只看厂商给出的理想数字。
Router GEMM：精度不打折，速度翻三倍
为什么 MoE 模型离不开高精度 GEMM
MoE 架构的路由器（Router）本质是一个高维分类器，输出概率直接决定 token 被分发给哪个专家。在 BF16 自动混合精度训练已成标配的今天，Router GEMM 如果也跟着降精度，会导致专家路由出现系统性偏差——轻则模型效果下降，重则训练崩溃。混元的解法是用两组 BF16 矩阵乘法来模拟 FP32 精度：输入先做一次拆分，输出再做一次误差补偿累加，最终数值精度与 FP32 GEMM 在统计意义上等价，但硬件执行路径完全跑在 Tensor Core 的 BF16 通道上。这个 trick 不新鲜，但混元把它工程化得相当彻底——配套的误差补偿参数可配置，支持不同的拆分策略以适配不同模型规模。
对比 CuBLAS FP32 的 3.22 倍加速
基准测试对照的是 NVIDIA 官方 CuBLAS 库的 FP32 GEMM 实现，这是工业界事实标准的精度参考系。结果是 HPC-Ops 的 Router GEMM 在保持同等精度的前提下，最高跑出 3.22 倍的速度提升，平均加速比在 2.5 倍以上。换句话说，做 MoE 模型推理的团队，如果之前因为 Router 精度问题被迫降速跑 FP32，现在可以直接换这个算子白嫖近三倍吞吐，而且不需要修改任何模型权重文件。
FusedMoE：把专家调度从「串行拼装」变成「单 Kernel 通杀」
传统 MoE 推理的算子碎裂问题
MoE 推理的算子链路通常是这样一个串行拼装：先做 Router GEMM 选出 Top-K 专家，然后 Gather 把对应 token 搬运到专家所在的显存区域，接着跑专家内部的 FFN 计算，最后 Scatter 把结果送回原始位置。中间穿插着大量内存搬运和 kernel launch 开销，GPU 利用率很难拉满。FusedMoE 的核心思路是把上述流程压进尽可能少的 CUDA Kernel，减少中间张量的显存往返。
1.2～1.6 倍的性能提升区间
实测下来，FusedMoE 相对 vLLM 和 SGLang 的原生实现，性能提升幅度落在 1.2 到 1.6 倍之间——具体数字取决于模型规模、专家数量和 batch 大小。模型越大、专家越分散，FusedMoE 的优势越明显，因为算子融合省下的内存带宽在大模型上被放大得更彻底。对于 7B、13B 级别的中小 MoE 模型，这个算子也能带来 20% 左右的稳定收益，几乎是「不拿白不拿」的优化。
Fused AllReduce+Norm：通信和归一化的一次性合并
多卡推理的隐性瓶颈
张量并行的推理服务在多卡部署时，AllReduce 通信几乎是无处不在的——每一层 Attention 输出后、每一层 FFN 输出后，都要等一次跨卡同步。再加上紧接着的 RMSNorm 或 LayerNorm，单次推理流程中这类「通信+小计算」的组合要重复几十次。传统实现里，AllReduce 和 Norm 是两个独立 kernel，中间夹着一次显式同步，GPU 的通信引擎和计算引擎在等对方。混元这次推出的 Fused AllReduce+Norm 算子，把这两个操作压成单个 kernel，通信尚未完全结束时就启动 Norm 的前置计算，等通信收尾直接出结果。
对比主流方案最高 1.68 倍提速
在 8 卡 H800 和 16 卡 A100 两个典型部署配置下，这个融合算子相对 NCCL AllReduce + 独立 LayerNorm 的主流组合方案，提速区间在 1.3 到 1.68 倍。卡数越多、通信占比越大的场景，融合带来的收益越高。对部署 70B 以上大模型的多机多卡团队来说，这是几乎零成本的优化——替换一个 kernel，性能白送 30% 以上。
Sampler：解码采样从「七步走」压缩到「两步走」
采样环节的隐形开销
很多人没意识到，大模型推理的采样阶段其实是个被严重低估的性能洼地。完整的解码采样流程包括：Logits 截断、Top-K 过滤、Top-P 过滤、温度缩放、随机数生成、Argmax/Sampling、索引映射——加起来通常是 5 到 7 个独立 CUDA Kernel，每个 kernel 之间都要做一次显存读写。在 Decode 阶段每生成一个 token 都要跑一遍这套流程，开销被 token 数量线性放大。
4～7.5 倍的采样加速
混元的 Sampler 算子把上述流程压成 2 个 CUDA Kernel：一个负责所有过滤和缩放的前处理，一个负责最终采样和索引映射。实测下来，相对 vLLM 的原生 Sampler 实现提速 4.0 到 7.5 倍——Decode 阶段的尾延迟被直接砍掉一大截。对在线对话类产品，这意味着用户能看到首字延迟明显缩短、流式输出的卡顿感大幅降低；对批量推理任务，这意味着整体吞吐可以再往上拱一截。
这套算子库真正的价值在哪
生产验证过的代码，不是论文里的玩具
HPC-Ops 这批算子和那些发了论文但没人复现成功的工作有本质区别——它们在腾讯混元的线上推理服务里跑了足够长时间，扛过真实业务流量的各种 corner case。代码里那些看起来不起眼的边界条件处理、异常分支兜底、性能 fallback 逻辑，全是产线事故喂出来的经验。对外部使用者来说，这意味着接入风险极低，性能数字基本可以预期。
完全开源、协议友好
所有算子都走标准的开源协议，仓库里提供了完整的 benchmark 脚本、依赖说明和接入示例，做推理部署的团队可以直接编译、替换、跑压测，不需要走任何商务流程。这和某些厂商「开源核心框架但闭源关键 kernel」的做法形成鲜明对比——后者等于开源了个寂寞，核心加速能力拿不走。混元这波操作，至少在推理基础设施层面，是真正把压箱底的活儿都端出来了。
