Tencent HPC 进入 SGLang，挑战默认推理内核

Tencent HPC 已进入 SGLang 主分支，带来三条优化后的算子路径，并报告称 Hy3 的 token 延迟降低了 48.8%。这项贡献将腾讯混元 HPC-Ops 库中的 Dynamic Attention、Router GEMM 和 Fused MoE 实现引入了一款广泛使用的开源推理引擎。

这一核心数据需要谨慎解读。TPOT，即每输出 token 耗时，衡量的是首个 token 出现后生成 token 之间的平均延迟。Tencent 和 SGLang 报告称，在测试的 Hy3 配置中，性能最高可提升 48.8%，而这并不意味着所有模型、GPU 和流量模式都会获得同样的收益。

不过，这不只是又一组孤立的 CUDA 基准测试。SGLang 用户可以通过上游框架使用这些内核，无需维护私有分支。这让腾讯的算子工作直接与既有的 SGLang、FlashInfer、CUTLASS、Triton 以及厂商支持的推理路径展开竞争。

Tencent HPC 从内核库走进 SGLang

关键变化在于分发方式，而不只是又一项更快的基准成绩。

HPC-Ops 是由腾讯混元 AI Infrastructure 团队开发的开源推理算子库。其算子仓库涵盖注意力、GEMM、Mixture-of-Experts 计算、采样、归一化以及融合通信操作。

算子是在 GPU 上执行特定模型任务的底层计算构件。SGLang 等框架会将这些构件组合成用于处理模型请求的执行路径。

在上游集成之前，希望使用 HPC-Ops 的团队需要在自己的服务环境中安装并连接其组件。这项工作涉及兼容性测试、后端选择，以及任一项目发生变化时的持续适配。

集成到 SGLang 主分支改变了这种关系。该框架可通过维护中的后端路径识别并将受支持的 Hy3 操作分派给腾讯内核。用户不再需要仅为评估该实现而维护长期存在的 SGLang 分支。

首批贡献聚焦于三个对延迟敏感的领域：

• Dynamic Attention 将不均衡的解码工作分配到 GPU 执行单元。

• Router GEMM 加速用于选择 MoE 专家的、对精度敏感的矩阵乘法。

• Fused MoE 将多个专家处理阶段合并，以减少内核启动次数和内存流量。

它们分别针对不同的推理延迟来源。结合起来，这些优化可应对长上下文和稀疏模型带来的不规则工作负载。

Hy3 是一个有用的测试案例，因为它同时包含这两类问题。Tencent 将 Hy3 描述为一种面向智能体执行、编程和扩展推理而设计的稀疏 Mixture-of-Experts 模型。其架构会针对每个 token 仅激活部分模型，但仍需对不断增长的上下文执行注意力计算，并在众多专家之间进行路由。

这种组合会在通常主导简化基准测试的大型矩阵乘法之外产生延迟。在线服务期间，调度、数据移动、精度转换、路由和小型内核启动都可能变得同样重要。

报告中的端到端结果是：在测试的 Hy3 工作负载上，TPOT 最高降低 48.8%。这一数字来自项目作者的基准测试环境，尚未在广泛的硬件组合上获得独立复现。

这一区别很重要，因为“最高”反映的是测得的最佳案例，并不代表每一种请求模式下的平均提升。处理短而均匀提示词的服务器，可能与处理长度不一的智能体会话的服务器得到不同结果。

HPC-Ops 也仍具有硬件特定性。其公开要求列出了 NVIDIA 的 SM90 架构、Python 3.8 或更高版本，以及 CUDA 12.8 或更高版本。该库称，其内核尤其针对 NVIDIA H20 GPU 进行了调优。

这限制了其即时可移植性，但并不削弱上游可用性的意义。SGLang 已成为模型构建者、基础设施团队和内核开发者常用的集成点。进入该项目能让腾讯的工作获得比独立仓库通常所能带来的更贴近真实场景的测试。

这也延续了其与 vLLM 的类似集成。7 月，HPC-Ops 的注意力和 MoE 后端作为一等选项进入 vLLM 主分支。随附的 vLLM benchmarks 显示，在八张 H20 GPU 上，首 token 和输出 token 延迟均有所降低。

因此，SGLang 成为第二个主要的模型服务生态系统，Tencent 可借此检验其面向生产环境的内核能否走出腾讯自身基础设施。基准测试背后，真正值得关注的正是这一点。

Tencent HPC 为何对在线模型服务重要

现代推理性能取决于对不规则工作的管理，而不只是最大化原始矩阵吞吐量。

离线基准测试通常采用固定的提示词长度、可预测的批次和稳定的张量形状。生产流量则不同。请求持续到达，上下文以不同速度增长，用户也会在不可预测的时点停止生成。

一个请求可能携带 16,000 token 的上下文，另一个则刚以 1,000 token 开始。静态注意力调度可能会让一个 GPU block 承担远多于其他 block 的工作。较短任务会提前完成，而最长任务决定整个启动何时结束。

Dynamic Attention 试图减少这种不平衡。HPC-Ops 将键值缓存工作拆分为更小的 tile，并根据当前工作负载分配这些 tile。随着解码过程中请求长度的变化，这种映射会被重新构建。

键值缓存会保存此前的注意力状态，使模型无需为每个新 token 重新计算全部历史。历史越长，需要读取和处理的缓存数据就越多。

HPC-Ops 描述了一种调度器：它将请求拆分为统一的 tile，并将其分发到 cooperative thread arrays。cooperative thread array，或 CTA，是执行已调度工作单元的一组 GPU 线程。

该库报告称，在选定的可变长度测试中，Dynamic Attention 的性能最高可达其静态 split-k 基线的 2.88 倍。其更广泛的注意力结果还包括在指定配置下相对于 FlashInfer、FlashAttention 和 TensorRT-LLM 的提升。

这些算子级别的数据不应与端到端服务器性能提升混为一谈。更快的注意力内核只会影响总延迟中花费在该操作上的部分。请求调度、通信、模型加载、采样和其他层仍处于执行路径中。

不过，随着上下文增长，注意力计算会变得愈发关键。智能体应用会不断将工具结果、检索文档和中间推理追加到活跃会话中。这恰好形成了动态调度所针对的、长度不均衡的缓存。

编程助手提供了一个具体例子。一个请求可能仅包含一个小函数和一条简短指令。另一个请求则可能包括仓库地图、多个文件、构建日志以及完整的对话历史。

将两类请求放入同一个连续批次可以提升利用率，但也会造成不均衡的注意力工作。静态 split 策略要么让部分 GPU 单元闲置，要么为较短请求启动空 chunk。

动态调度试图让这些请求以更高效率共存。当序列长度差异显著，且服务器有足够的并发工作可供重新平衡时，收益应最为明显。

这也是 TPOT 比单一吞吐量数字更重要的原因。吞吐量衡量的是所有请求的总体输出。TPOT 则更直接反映单个用户在生成过程中连续看到 token 的速度。

对于交互式智能体而言，缓慢的 token 输出会在长回复和反复的工具调用中累积。更低的 TPOT 可以缩短每段生成时间，继而使下一步工具调用或模型步骤更早开始。

这项集成也对推理框架中的默认内核选择构成压力。SGLang 已提供多种注意力和 MoE 实现，分别针对不同模型、精度和 GPU 进行了优化。新的后端必须在不引入脆弱配置规则的前提下胜过这些选项。

只有当框架分派逻辑保持易于理解时，这种竞争才会让运营者受益。基础设施团队需要知道 HPC-Ops 何时启用、它支持哪些形状，以及不受支持的请求将由哪种回退机制处理。

团队还需要来自自身流量的证据。公开基准测试可以帮助识别有前景的后端，但无法复现序列长度、批次大小、量化、并行方式和服务级别目标的每一种组合。

评估这项贡献的团队应测量中位数和尾部 TPOT、首 token 时间、请求吞吐量、GPU 内存使用情况以及输出一致性。仅看平均延迟可能掩盖影响最慢用户的停顿。

同样的严谨性也适用于评估相关的技术知识。工程团队可以将基准测试命令、部署说明和故障分析保存在可搜索知识库中，而不是依赖零散的聊天线程。

Tencent HPC 之所以重要，是因为它为这些团队提供了另一条可维护的执行路径进行测试。它的价值将来自可重复的服务性能提升，而非发布图表上的最高数字。

Dynamic Attention 和 Fused MoE 针对不同瓶颈

报告中的 Hy3 性能提升，来自于消除每个生成 token 过程中不断累积的多项微小延迟。

Dynamic Attention 针对注意力计算期间的负载不均衡。Fused MoE 则针对模型将 token 路由到选定专家后的碎片化问题。Router GEMM 位于两者之间，加速为这些专家分配所作出的决策。

MoE，即 Mixture-of-Experts，会用更大规模的专用前馈网络集合替代部分稠密神经层。路由器会为每个 token 选择一小部分专家，从而限制每个 token 实际执行的计算量。

这种稀疏性减少了活跃计算，但也引入了不规则性。不同专家接收到的 token 数量可能不同。服务器必须计算路由分数、组织 token、执行多个较小的矩阵乘法，并合并加权输出。

传统实现通常会将这些操作拆分为多个内核。它们先将 token 收集到面向特定专家的缓冲区，再启动矩阵操作、应用激活函数、量化中间值，并对选定输出进行归约。

每一次拆分都可能带来一次额外的内核启动和一次额外的高带宽内存访问。这些成本单独看很小，但在低批次解码期间却很重要，因为每项专家操作处理的 token 相对较少。

HPC-Ops 使用融合的 FP8 MoE 路径。FP8 是一种八位浮点格式，相比更宽的格式可减少内存流量，并提高可用的 tensor core 吞吐量。

这条融合路径结合了与路由相关的预处理、门控和扩展矩阵乘法、激活量化、投影回模型宽度以及加权归约。Tencent 表示，该实现通过路由索引读取原始 token，而不是先将其复制到收集好的专家缓冲区中。

这一设计旨在同时减少内存移动和内核启动间隙，同时也改变了实现隐藏延迟的方式。

与其在单个 GPU block 内高度依赖软件流水线，HPC-Ops 会针对低延迟形态增加常驻 block 的数量。这样一来，当其他工作正在等待数据时，硬件调度器便可在不同 block 之间切换。

该库称，其 Fused MoE 算子在张量并行下速度最高可提升至 1.6 倍，在专家并行下最高可提升至 1.5 倍。其公开比较涵盖 SGLang、vLLM Triton 和 vLLM CUTLASS 实现。

张量并行将模型计算拆分到多个 GPU 上。专家并行则将不同的 MoE 专家部署在不同工作节点上，因此 token 必须传输到持有所选专家的工作节点。

最佳选择取决于模型形态、互连速度、请求并发度和内存限制。融合的本地 kernel 无法消除分布式专家布局所必需的通信。

Router GEMM 解决的是一个更微妙的限制。GEMM 指通用矩阵乘法，是许多神经网络层背后的核心运算。

路由器会将低精度激活值与权重相乘，而权重中细微的数值差异可能影响专家选择。若过度降低这些权重的精度，就可能改变路由决策，进而改变模型输出。

使用完整 FP32 算术可保护精度，但当前 tensor core 并未提供与低精度格式相同的 FP32 吞吐量。直接实现可能不得不回退到更慢的 CUDA core 计算。

HPC-Ops 将每个 FP32 权重拆分为两个 BF16 分量。BF16 保留 FP32 的指数范围，但使用更少的尾数位。

其中一个分量承载权重的高位部分。第二个分量承载经过缩放的残差，项目文档说明其缩放系数为 1/256。随后，kernel 执行两次 BF16 tensor-core 乘法，并合并结果。

两项计算都保留在同一个 kernel 内。它们共享输入数据搬运，将中间累加器保留在寄存器中，并且只写入一次最终结果。

腾讯称，在选定的路由器和状态压缩形态下，其性能最高可达 cuBLAS FP32 或 TF32 基准的 3.22 倍。该说法针对的是经过测试的算子形态，并不代表所有 GEMM 工作负载。

这一机制之所以重要，在于它试图在获取低精度硬件吞吐量的同时保留路由行为。如果无法实现可比的专家选择，单纯提速对生产推理而言并不是一笔好交易。

这类精度问题也是输出验证细节至关重要的原因。基准测试应比较路由决策或最终模型输出，而不应只比较执行时间。

此前的 vLLM 集成报告称，其 MoE 对比中输出质量保持一致。如今的 SGLang 集成则为维护者和用户提供了另一个机会，可测试不同框架实现之间的数值行为。

这三个算子共同构成了一套连贯的执行逻辑。Dynamic Attention 分配上下文计算任务。Router GEMM 决定稀疏计算流向何处。Fused MoE 则以更少的边界执行这些计算。

因此，这项改进讲述的是机制，而非某个单体 kernel 的速度几乎翻倍。多个瓶颈得到了缓解，而其综合价值取决于每个瓶颈对特定工作负载的贡献程度。

48.8% TPOT 声明并不能证明什么

最强的基准结果为测试提供了可信的线索，但并非可移植的性能保证。

所报告的降幅适用于腾讯的 Hy3 评估及受支持的硬件条件。无论是这一数字还是当前文档，都不能证明所有 SGLang 模型能获得同样的结果。

Hy3 结合了模型特定的注意力行为、稀疏路由、FP8 执行和特定的专家结构。不含 MoE 层的稠密模型无法从 Fused MoE 或 Router GEMM 路径中受益。

采用不同旋转位置编码、归一化顺序、头部维度、量化缩放系数或缓存布局的模型，可能需要额外的集成工作，也可能只会启用 HPC-Ops 的部分功能。

硬件也构成了另一条边界。HPC-Ops requirements 目前主要面向 NVIDIA SM90 GPU 和 CUDA 12.8 或更高版本。其最强的公开结果聚焦于 H20。

这意味着 NVIDIA Ampere 系统、Blackwell 配置、AMD 加速器及其他硬件仍处于已展示范围之外。SGLang 支持的环境范围，比这一后端当前所针对的范围更广。

即使在 H20 上，流量形态也会改变结果。当一个 batch 包含长短不一的序列时，Dynamic Attention 的优势最为明显。长度一致的短请求留给调度器修正的不均衡更少。

Fused MoE 同样依赖 batch 大小。vLLM 团队称，其最大的收益出现在小型和中型 batch 中，因为传统启动开销和内存访问在总耗时中占比更大。

在高并发情况下，更大的矩阵运算可能已能充分利用 GPU，从而缩小差距。当专家并行跨越多个设备或节点时，通信也可能成为主导因素。

因此，48.8% 这一数字需要结合完整基准矩阵来理解。读者应关注 prompt 长度、输出长度、并发度、张量并行规模、专家并行规模、缓存精度、GPU 时钟频率以及基准配置。

基准质量尤其重要。默认后端对于新用户而言可以是合理的比较对象，但它未必代表调优后的最佳替代方案。

SGLang 的模块化专家并行架构允许使用自定义 kernel 和专用后端。FlashInfer、DeepGEMM、Triton、CUTLASS 和原生 SGLang kernel 都在持续演进，因此对比结果可能迅速变化。

集成日期同样重要。在稳定版本覆盖更广部署之前，主分支代码会快速发生变化。已合并的后端仍可能需要完成打包、文档、兼容性测试和运行保障措施。

数值准确性仍是需要独立验证的另一个领域。Router GEMM 使用两个 BF16 分量近似 FP32 权重计算。这一设计旨在达到 FP32 级别的精度，但下游用户仍应测试模型级行为。

有用的检查包括确定性解码下的输出一致性、路由索引重叠度、代表性数据上的困惑度，以及任务级评估。微小的数值差异可能无害，也可能将 token 重定向至不同专家。

生产可靠性不止于数值匹配。kernel 必须能够处理边界形态、内存压力、取消请求、持续 batching、前缀缓存和不断变化的序列长度，且不能出现罕见故障。

开源审查有助于发现这些问题，但可见性并不等同于成熟度。SGLang releases 展示了模型支持、kernel、量化路径和调度行为变化的频繁程度。

腾讯表示，HPC-Ops 已在其自身环境中支持大规模推理。这一经验很有意义，但外部部署往往会暴露内部模型集群从未使用过的组合。

此外还有维护问题。上游代码降低了维护 fork 的负担，但外部 HPC-Ops 包及其兼容性矩阵仍需要持续维护。

用户应关注腾讯和 SGLang 对性能回归报告的响应速度，也应检查持续集成是否覆盖受支持的 GPU、精度和模型组合。

这些限制都不会否定该结果。它们界定了该结果实际说明的内容。

腾讯和 SGLang 展示了一个针对受支持 Hopper 硬件上游后端的强劲、模型特定基准。更广泛的声明需要更广泛的复现。

正确的回应既不是自动采用，也不是直接否定，而是在组织自身的服务级目标下，与现有最佳后端进行受控测试。

三个信号将决定 Tencent HPC 是否改变默认选择

下一阶段关乎采用、可复现性，以及能否扩展到一个模型和一个 GPU 家族之外。

第一个信号是 SGLang 内部对 Hy3 的独立基准测试。外部运营者应使用公开命令和完整配置细节，复现所报告的 TPOT 改进。

一项有价值的复现应包括中位数和 P99 TPOT、首 token 时间、输出吞吐量、内存使用量和请求失败情况，并测试混合长度与统一长度两类工作负载。

若确认结果接近报告区间，将增强腾讯的说法：组合算子优化能够实质改变用户可感知的解码延迟。若收益明显更小，则表明最大结果可能高度依赖于某种工作负载形态。

第二个信号是对 Hy3 和 H20 之外的支持。HPC-Ops 已在算子层面发布了对 DeepSeek-V3、Hunyuan 模型和 Qwen3-235B 的基准覆盖。

框架层面的集成更为困难。每个模型在注意力布局、归一化顺序、量化、专家路由和分布式执行方面都可能不同。

若支持另一款被广泛部署的 MoE 模型，将表明该后端提供的是可复用基础设施，而非一条仅为 Hy3 精确适配的路径。对 Blackwell 的支持也将检验该项目能否超越最初的 Hopper 目标。

该项目的路线图列出了更广泛的量化支持、未来硬件、megakernel 和低精度通信。megakernel 将多个连续操作合并，以减少启动开销和中间内存流量。

如果这些项目伴随 SGLang 集成和公开基准一同推出，Tencent HPC 将成为推理后端中更广泛的竞争者。如果进展仍局限于少数 H20 配置，它仍有价值，但会保持专用性。

第三个信号是 SGLang 用户是否会在真实部署中选择这一后端。仓库星标和孤立的微基准，对运营采用的证明有限。

更有用的迹象包括部署方案、框架文档、外部集群的 bug 报告、兼容性测试和持续的维护者活动。稳定版本的纳入比仅出现在主分支中更重要。

采用会推动竞争 kernel 改进混合长度调度、路由器精度和 MoE 融合。届时，SGLang 维护者将面对一项富有成效的挑战：在不产生令人困惑或脆弱默认配置的前提下，选择最快的后端。

失败报告同样具有参考价值。它们将揭示受控基准掩盖的未支持形态、数值边界情况、打包摩擦或运营限制。

对于开发者而言，眼下的问题很实际：新后端是否能针对他们实际运行的模型、GPU 和流量模式降低延迟？

对于基础设施采购方而言，这个问题具有经济意义，无需进行公开价格比较。更低的 TPOT 可以提高可用容量并改善交互响应速度，但前提是可靠性和输出质量保持稳定。

对于 AI 产品团队而言，影响可能超出基准仪表盘。更快的 token 交付可缩短编码会话、智能体循环、文档分析及其他每项任务需进行多次模型调用的工作流。

Tencent HPC 值得认真评估，因为其算子现已进入 SGLang 的上游路径。这一集成消除了优化研究成果与生产测试之间的一道障碍。

48.8% 这一数字应当开启测试，而非终结测试。运行于受支持 Hopper 硬件上的 Hy3 团队，现在就可以将该后端与当前 SGLang 配置进行基准对比。

其他人则应关注这三个信号：独立复现、更广泛的模型与硬件支持，以及持续部署的证据。它们将共同决定 Tencent HPC 是成为常见的推理选项，还是保持为 Hy3 的专用优势。