HPC-Ops – 腾讯混元开源的工业级高性能大模型推理算子库

1. HPC-Ops是什么

HPC-Ops是腾讯混元AI Infra团队开源的一款工业级高性能大模型推理算子库，专为应对生产环境中大规模、高并发的推理负载而设计。它并非单一的算子优化，而是覆盖了从Attention、MoE、GEMM到通信融合与采样的完整推理链路，通过深度软硬件协同设计，实现了端到端的性能飞跃。基于NVIDIA H20等SM90架构GPU，HPC-Ops通过动态调度与算子融合技术，将端到端的QPM（每秒查询量）提升了30%以上，多项核心指标显著超越了vLLM、FlashInfer、SGLang等业界主流推理框架与算子库。该库已成功支撑腾讯混元大模型的大规模生产级推理服务，是经过严苛实战检验的“重型武器”。

技术定位与领域： HPC-Ops属于高性能计算（HPC）与深度学习推理的交叉领域，专注于为大语言模型（LLM）提供极致优化的底层算子。其独特定位在于，它并非一个通用的推理框架，而是一个可深度集成的算子库，旨在为vLLM、SGLang等上层框架提供“核动力引擎”。它解决了传统静态优化策略无法适应在线推理负载动态变化这一核心痛点。

研发背景： 由腾讯混元AI Infra团队研发，该团队长期服务于腾讯内部的大规模AI生产环境，对超大规模模型的部署、运维和性能瓶颈有着深刻理解。研发HPC-Ops的动机源于对现有开源方案（如FlashInfer）在生产级、动态负载下的性能极限不满，旨在通过底层创新，将腾讯在工业级推理中积累的最佳实践固化为一套可复用、可扩展的算子库。

核心价值： HPC-Ops的核心价值在于其系统性和实战性。它并非追求单点算子的理论峰值，而是通过全链路的协同优化，解决了在线推理中“木桶效应”的长尾延迟问题。其创新的动态Attention调度、高精度Router GEMM和通信计算融合等技术，为行业提供了处理长短请求混排、MoE路由精度、张量并行瓶颈等现实难题的宝贵解决方案。

技术特点： 其核心技术特点包括：一是运行时动态优化，通过Tile级动态调度和贪心算法，实现CTA级负载均衡；二是全链路算子融合，将MoE、通信、采样等复杂流程重构为无气泡流水线；三是高精度与高性能的平衡，独创双BF16模拟FP32精度，兼顾数值敏感场景与Tensor Core高吞吐。

2. 主要功能

HPC-Ops的功能模块化清晰，每个模块都针对推理链路中的特定瓶颈进行了深度优化。以下按技术创新程度排序：

• 动态Attention调度： 这是HPC-Ops最核心的创新之一。针对在线推理中长短请求混排导致的长尾延迟问题，它摒弃了传统的静态split-kv策略。通过运行时将请求按统一Tile粒度拆分，并采用贪心装桶算法均衡分配给各CTA（线程块），实现了CTA级别的负载均衡。在长文本场景下，该技术相较于FlashInfer等基线，最高可实现2.95倍的加速，从根本上解决了动态负载下的“木桶效应”。

• Router GEMM（双BF16模拟FP32）： 针对MoE路由等对数值精度极为敏感的场景，HPC-Ops独创了此技术。它将FP32权重离线拆分为高位和低位两个BF16矩阵，在推理时通过两次BF16 Tensor Core GEMM计算，并在线性组合后通过FMA指令修正，最终以近乎BF16的计算速度达到FP32的精度。其误差仅为TF32的1/36，而性能较cuBLAS FP32最高提升3.22倍，完美平衡了精度与算力。

• FusedMoE（无气泡流水线）： HPC-Ops将MoE推理的五个阶段——路由索引、Gate-Up GEMM、激活量化、Down GEMM、Top-K加权聚合——重构为一条单一、无气泡的流水线。通过消除各阶段间的显存搬运和内核启动开销，并利用跨CTA硬件调度掩盖访存延迟，该模块相较于vLLM和SGLang，性能提升了1.2倍至1.6倍，是MoE模型推理的关键加速器。

• Fused AllReduce+Norm（通信计算融合）： 在张量并行场景下，跨GPU通信是核心瓶颈。HPC-Ops将AllReduce通信、残差相加与RMSNorm归一化深度融合为一个原生NVLink一体化操作。它针对Prefill和Decode场景分别采用NVSwitch多播和Lamport P2P机制，实现了通信与计算的高度重叠，相比NCCL和FlashInfer的独立实现，性能最高可提升1.68倍。

• Sampler大算子融合： 采样是推理末端的后处理步骤，通常由多个小Kernel组成，启动开销大。HPC-Ops将重复惩罚、温度缩放、Top-K、Top-P、Softmax及随机采样等十余个内核融合为仅2个CUDA Kernel，极大地减少了Kernel Launch次数和显存读写，补齐了推理链路末端的性能短板。

• GroupGEMM FP8： 原生支持专家并行（EP）和分组专家矩阵乘，兼容per-tensor与block-wise两种FP8量化模式。这使得HPC-Ops能够高效适配DeepSeek-V3等采用FP8训练的MoE模型，在保证推理精度的同时，利用FP8的低精度高吞吐特性进一步提升性能。

3. 如何使用

HPC-Ops的集成和使用流程清晰，旨在降低开发者的接入门槛。以下是详细的使用指南：

1. 环境要求与前置条件：

   • 硬件： 必须配备NVIDIA SM90架构的GPU（如H20、H100等），这是其深度优化的基础。服务器需具备NVLink互联以充分发挥通信融合优势。
   • 软件环境：
     • 操作系统：Linux（推荐Ubuntu 22.04+）。
     • Python版本：3.8及以上。
     • CUDA版本：12.8及以上，并确保nvcc编译器在PATH中。
     • 编译器：支持C++17标准的编译器（如GCC 9+）。
     • PyTorch：建议安装与CUDA版本匹配的PyTorch 2.0+。

2. 核心使用流程（编译与安装）：

   • 克隆仓库： 执行 git clone https://github.com/Tencent/hpc-ops.git 将代码拉取到本地。
   • 编译打包： 进入项目目录 cd hpc-ops，运行编译脚本（通常为 python setup.py bdist_wheel），该过程会自动编译CUDA内核并生成一个.whl文件。
   • 安装部署： 使用 pip install dist/**.whl 命令安装生成的wheel文件，将HPC-Ops算子库安装到当前Python环境中。

3. 关键配置与调用：

   • 导入模块： 在Python脚本中通过 import hpc 导入HPC-Ops模块。
   • 准备数据： 根据目标算子（如Attention、FusedMoE）的API要求，准备好输入张量（通常是torch.Tensor），并确保数据类型（如torch.bfloat16）和形状符合要求。
   • 调用算子： 直接调用对应算子的Python API，例如 hpc.ops.fused_attention(query, key, value, ...) 或 hpc.ops.fused_moe(gate, input, ...)。这些API封装了底层的CUDA Kernel调用。

4. 注意事项与最佳实践：

   • 框架集成： HPC-Ops的设计目标是作为“引擎”被集成。最佳实践是将其Python API嵌入到vLLM、SGLang等主流推理框架的模型代码中，替换掉原有的Attention、MoE等算子实现，从而获得端到端的性能提升。
   • 性能基准测试： 项目benchmark目录下提供了性能复现脚本。在目标硬件上运行这些脚本，可以快速验证HPC-Ops在自己环境下的实际性能表现，并与FlashInfer等基线进行对比。
   • 测试验证： 在集成前，务必运行tests目录下的测试脚本，确保算子计算的正确性，避免因数值差异导致模型输出异常。

4. 优缺点分析

5. 同类工具对比

HPC-Ops的主要竞争对手是FlashInfer、vLLM等社区驱动的推理优化方案。以下从多个维度进行技术对比：

选型建议：

• 面向追求极致性能的AI Infra团队： 如果你的团队有较强的技术实力，并且正在部署超大规模MoE模型（如DeepSeek-V3），面临长短请求混排、张量并行瓶颈等现实问题，那么HPC-Ops是首选。它提供的全链路优化和高精度方案是其他竞品无法比拟的，尽管集成成本更高，但性能回报是巨大的。

• 面向中小团队或快速验证场景： 如果你的目标是快速搭建一个可靠的推理服务，对性能要求不是极致，或者团队没有精力进行底层优化，那么vLLM是最佳选择。它提供了完整的解决方案，并且可以通过配置轻松替换底层算子，未来也能受益于HPC-Ops等更优的算子。FlashInfer则更适合那些只想优化Attention环节，或者作为其他框架的组件来使用的场景。

6. 编辑点评

HPC-Ops的出现，标志着大模型推理优化进入了一个新的阶段——从“单点极致”走向“系统最优”。过去，FlashInfer等社区项目在单个算子（如FlashAttention）上做到了极致，但生产环境的瓶颈往往在于链路中的协同与调度。HPC-Ops正是抓住了这一痛点，通过动态调度、流程重构和通信融合，实现了“1+1>2”的系统性增益。

技术创新性评估： HPC-Ops的技术创新点非常扎实。其动态Attention调度并非简单的改进，而是一种算法层面的范式转变，从根本上解决了静态调度的局限性。双BF16模拟FP32的Router GEMM方案，则展现了团队对硬件底层指令集（Tensor Core）和数值计算的深刻理解。这些技术并非“空中楼阁”，而是基于对生产负载的深入观察和严谨的工程实践。

实用价值分析： 对于任何运行大规模LLM推理服务的公司而言，HPC-Ops的实用价值是巨大的。30%的端到端QPM提升意味着同等硬件成本下，可以服务更多用户，或者降低延迟、提升用户体验。其解决的长尾延迟问题，更是直接影响服务稳定性和SLA的关键因素。作为经过腾讯混元大规模验证的开源项目，其可靠性远非实验室原型可比。

适用人群定位： 主要面向AI Infra工程师、系统优化工程师和高级算法工程师，他们负责搭建和维护大规模推理集群。对于应用层的开发者，HPC-Ops的价值体现在其作为底层引擎，通过上层框架（如vLLM）间接提供更优的服务。

未来发展潜力： HPC-Ops的开源，有望形成一个围绕腾讯混元技术的生态。随着社区贡献的增加，其支持的硬件平台（如AMD、华为昇腾）和算子种类可能会扩展。未来，它很可能成为与FlashInfer并驾齐驱的工业级算子底座，尤其是在处理复杂MoE和动态负载方面，HPC-Ops的优势会愈发明显。

7. 应用场景

• 高吞吐在线推理服务： 在腾讯混元等面向公众的大模型API服务中，请求长度和内容千变万化。HPC-Ops的动态Attention调度和Sampler融合技术，能有效降低因长请求导致的服务长尾延迟，保证所有用户的体验一致性，显著提升服务吞吐量（QPM）。

• MoE大模型推理部署： 对于DeepSeek-V3、Qwen3-235B等采用MoE架构的千亿级大模型，HPC-Ops的FusedMoE和GroupGEMM FP8模块是核心加速器。它们能够高效处理路由和专家计算，减少显存访问和Kernel启动开销，使得在相同硬件上部署更大规模或更低延迟的MoE模型成为可能。

• 张量并行分布式推理： 在单节点多GPU（如8卡H20）部署超大模型时，张量并行是标配。HPC-Ops的Fused AllReduce+Norm技术，通过将通信与计算深度融合，有效缓解了跨GPU通信这一核心瓶颈，使得模型规模可以随着GPU数量线性扩展，而性能不会因通信开销而大幅下降。

• 精度敏感型推理任务： 在需要高精度输出的场景，如金融风控、法律咨询或科学计算相关的LLM应用中，MoE路由和稀疏Attention等模块的数值精度至关重要。HPC-Ops的Router GEMM技术，能以极低的性能代价提供FP32级别的精度，避免了因低精度量化导致的模型输出质量下降。

8. 常见问题FAQ

Q：HPC-Ops与vLLM是什么关系？我需要同时使用它们吗？
A：HPC-Ops是一个算子库，而vLLM是一个推理框架。它们不是竞争关系，而是互补关系。最佳实践是将HPC-Ops作为vLLM的底层算子引擎，通过替换vLLM中的Attention、MoE等模块的默认实现，来提升vLLM的整体推理性能。

Q：HPC-Ops只能在NVIDIA H20 GPU上运行吗？
A：目前，HPC-Ops深度针对NVIDIA SM90架构（如H100、H20）进行优化，利用了其第四代Tensor Core和NVLink等技术。在较老的GPU架构（如A100）上可能无法编译或无法获得预期的性能增益。未来是否会支持其他厂商的硬件，取决于社区的贡献和腾讯团队的规划。

Q：我的模型没有使用MoE，使用HPC-Ops还有意义吗？
A：有意义。即使不使用MoE，HPC-Ops的动态Attention调度、Sampler融合和Fused AllReduce+Norm等优化，对于所有Transformer架构的大模型推理都有显著的性能提升。尤其是动态Attention调度，对于任何处理在线、变长请求的服务都是必选项。

Q：HPC-Ops的“双BF16模拟FP32”是否会引入额外的显存开销？
A：会增加约一倍的权重存储开销，因为需要存储高位和低位两个BF16权重。但考虑到Router GEMM通常只占模型总参数量的一小部分（路由权重），这个额外的显存开销是完全可以接受的。其带来的精度收益和性能提升远大于这点显存代价。

Q：我在集成HPC-Ops时，如何确保算子计算的正确性？
A：项目仓库的tests目录下提供了详尽的测试脚本。在集成任何新算子之前，务必运行这些测试，以验证其输出与PyTorch原生实现（或参考实现）的数值误差在可接受范围内。这是避免模型推理结果异常的关键步骤。

9. 项目地址

• GitHub仓库： https://github.com/Tencent/hpc-ops （包含源代码、安装指南、测试和基准测试脚本）