专栏名称: 腾讯技术工程
腾讯技术工程事业群官方微信公众号。腾讯前沿科技技术、产品、行业信息交流发布平台。
目录
相关文章推荐
程序员的那些事  ·  外网热议:为什么 DeepSeek ... ·  2 天前  
腾讯技术工程  ·  MCP很好,但它不是万灵药!真正的技术进步, ... ·  2 天前  
伯乐在线  ·  美国 IT 业裁员狂飙 ... ·  2 天前  
伯乐在线  ·  美国 IT 业裁员狂飙 ... ·  2 天前  
稀土掘金技术社区  ·  用dayjs解析时间戳,我被提了bug ·  4 天前  
51好读  ›  专栏  ›  腾讯技术工程

微信自研高性能推理计算引擎 XNet-DNN:跨平台 GPU 部署大语言模型及优化实践

腾讯技术工程  · 公众号  · 程序员  · 2025-05-30 17:35

正文

请到「今天看啥」查看全文


从项目生态来看, llama.cpp 社区拥有近千名贡献者,其中代码贡献量超万行的核心开发者近 30 位,其硬件适配能力主要依赖厂商团队的直接投入,例如 Intel 和 Qualcomm 分别主导了 SYCL 与 OpenCL 后端开发,阿里巴巴等机构也参与其模型生态支持。然而,XNet-DNN 仅投入很少的开发资源实现了更广泛的 GPU 硬件覆盖与更优的推理性能,图 2 展示了 XNet-DNN 与开源项目 llama.cpp 的代码规模及开发者效率对比。

图2. XNet LLM(GPU) 与 LLama.cpp 代码量对比
图2. XNet LLM(GPU) 与 LLama.cpp 代码量对比

我们能够以更少的人力完成更优秀的更全面的工作, 其关键在于 RCI 架构设计的双重创新:

1. 跨平台特性降低开发冗余

借助 RCI 的跨平台特性,框架实现仅需一套逻辑,有效降低框架代码量。kernel 部分,非核心计算逻辑(如内存布局转换)可借助 RCI 编写通用实现,无需针对各平台重复开发。大幅减少开发工作量,也有效降低了包体积。表 3 展示了 XNet-DNN 的包体积与其他主流推理框架的对比。对于移动端等包体积敏感场景,XNet-DNN 有巨大优势。

表3 包体积对比
表3 包体积对比

2. 差异化策略平衡性能与效率

RCI kernel 支持两种开发模式:采用高级语言编写跨平台通用 kernel,或使用原生语言(如 Metal Shading Language/CUDA C/PTX/SASS/GCN)编写硬件专用 kernel。对于硬件特性差异显著的核心算子(如矩阵计算),采用专用 kernel 实现极致性能;共性操作则通过通用 kernel 提升开发效率,实现了开发工作量与应用高性能之间的有效平衡。

凭借 RCI 优秀的框架设计,使我们得以聚焦核心算子的深度优化,最终以极小的人力规模完成对 Apple、NVIDIA、AMD、Intel、Qualcomm、Mali、 Maleoon 等主流 GPU 的覆盖并取得超越业界的性能,人效比远高于传统开发方式。

2.3 RCI Command Tape 特性

GPU 的执行需要宿主机 CPU 参与大量工作。CPU 作为主处理器负责逻辑调度和命令序列构建,通过总线向 GPU 设备提交结构化的命令队列。这种提交过程涉及指令预编译、资源绑定、内存屏障同步以及上下文状态的维护。以上是 CPU 提交 GPU 命令的核心机制。

在推理任务中,典型的执行流程是由多个 kernel 组成一个队列,每个计算帧执行相同的队列。在传统 GPU 执行机制下,每个计算帧都需要驱动层对队列中所有 kernel 执行完整的指令预编译和资源绑定流程,硬件指令缓冲区需要反复构建。这一过程 CPU 重复执行大量的相同任务,造成 CPU 负载及功耗显著增加,一些场景下计算管线的端到端延迟甚至受限于 CPU 性能。

RCI 的 Command Tape 技术有效解决了这一瓶颈。 该技术提供了一种跨平台的命令预录制机制,预先录制命令队列,指令预编译和资源绑定等操作只在预录制时执行一次,后续计算帧的处理,只需要提交预录制命令队列即可,有效降低 CPU 负载和功耗,也能够更好的提高 GPU 管线的吞吐。该技术实现了与 Metal 的 Indirect Command Buffer、NVIDIA CUDA Graphs 以及 Adreno Recordable Queue 等效的能力。

如图 4 展示了在轻量级模型的推理任务中,decode 过程使用 CommandTape 技术所带来的性能提升。。

图4. Command Tape 在 iPhone (上) 及 Android (下) 设备的加速效果
图4. Command Tape 在 iPhone (上) 及 Android (下) 设备的加速效果

3. 榨取硬件潜能:核心算子的极致优化实践

所谓工欲善其事,必先利其器。凭借对各种计算硬件体系结构的深入理解和长期实战的经验总结。我们开发了一套微基准测试(Micro-benchmark)工具,它可以帮助我们准确获取硬件的算力峰值、各级存储结构的带宽以及延迟、指令吞吐、指令延迟以及一些硬件架构特点,这些信息大多数是硬件厂商不公开的,或者仅是理论数据。这些关键指标对于我们做性能优化非常关键,它可以帮助我们做数据排布,指令排布,实现最优的 pipeline 以获得最优的带宽利用率和算力利用率。同时,这套工具配合 Roofline 模型,可以快速准确的帮助我们定位到当前优化的瓶颈,以及当前优化距离最终目标还有多远。这套方法论让优化不再是玄学,所有的经验可总结,可借鉴,可复现,帮助我们能够有效的在不同的硬件上取得最优的性能。

3.1 如何做算子优化

本节先简单介绍一下,如何通过硬件指标配合 Roofline 模型来指导优化。图 5 是根据 8 Gen2 的带宽和算力画出的 Roofline 模型。我们通过 Micro-benchmark 测出,GPU Memory 的带宽为 60 GB/s, shared memory 的带宽为 465 GB/s, FP16 算力为 4668.5 GFLOPs。纵轴是算力,单位为 GFLOP/s, 横轴为计算密度,单位是 FLOPs/Bytes。图中的紫色线条和蓝色线条代表算力随计算密度变化的趋势。紫色垂线表示,按照 shared memory 的带宽能力,要达到峰值算力,需要计算密度达到 10 及以上,蓝色垂线表示,按照显存带宽能力,要达到峰值带宽需要计算密度达到 77 及以上。以显存带宽衡量,当计算密度小于 77,该算子就属于带宽受限型算子,当计算密度大于 77, 该算子就属于算力受限型算子。

如果一个算子已经是算力受限型算子,那么说明已经优化到极致了,我们是无法突破算力天花板的。然而由于带宽更昂贵,绝大多数的情况,算子都会落在带宽受限区域,此时为了达到硬件峰值,优化方向有两个,其一是提高计算密度,其二是提高带宽。以矩阵乘法为例,增大矩阵分块,可以提高计算密度,这个过程中需要考虑寄存器数量限制,寄存器资源有限,过大的分块导致可能会导致 register spill,性能反而会大幅下降;提高带宽,则是通过使用 shared memory 以及提升 Cache 命中率,来降低访存延迟。除此之外,我们需要根据 Micro-benchmark 获取的计算及访存指令延迟数据,合理的排布访存指令和计算指令以达到相互掩盖延迟,实现软流水获得最优的吞吐。可见算子优化是一种平衡之道,在有限的资源中,探寻一种最优的平衡,访存指令与计算指令的平衡,寄存器占用与计算密度的平衡等等,为了实现这种微妙的平衡,准确的 Micro-benchmark 就显得尤为重要,Micro-benchmark 数据越精准,就越能接近极限平衡也就是达到最优性能,反之则只能南辕北辙。

图5. Qualcomm 8 Gen2 Roofline
图5. Qualcomm 8 Gen2 Roofline

除了 Micro-benchmark 和 Roofline 之外,我们优化最重要的基础是计算机体系结构。只有深刻了解硬件的运行规则,才能凭借 Micro-benchmark 数据合理的分析瓶颈,配置资源;Roofline 则提供了一套评价机制,帮助我们衡量当前优化水准。

3.2 GEMM/GEMV 的优化

大语言模型的推理分为两个阶段,prefill 和 decode; 前者是对用户 prompt 的处理阶段,也就是 kv-cache 填充阶段,后者是 token 生成阶段。Decode 过程是迭代过程,每轮迭代生成一个 token,prefill 阶段可以进行批处理,一次运行填充多组 kv-cache。所以大语言模型的 prefill 和 decode 是两种不同类型的计算过程,prefill 阶段的核心计算是矩阵乘法(GEMM),decode 阶段的核心计算是矩阵向量乘(GEMV)。

从计算密度(Arithmetic Intensity)分析,GEMV 的理论上界为 2 FLOPs/Byte,GEMM 的计算密度则受分块策略影响,其上限由寄存器容量等硬件资源决定。因此二者的优化方向也大不相同。GEMV 的计算密度固定,属于纯带宽型算子,优化中需要关注带宽以及 GPU 的 occupancy, 在带宽方面需要满足最基础的访存合并,同时为了更优的 occupancy,一般需要数据重排,以满足 GPU 的访问模式。作为带宽型算子,最优实现是算子耗时与最大带宽情况下的数据读写耗时相当,也就是说,访存延迟完全掩盖了计算延迟。我们知道,GPU 是通过大量 warp 并行执行,通过访存和计算的相互掩盖以保证硬件单元的持续繁忙,那么在 GEMV 的优化中除了考虑数据排布的最优,还需要考虑 GPU occupancy,常见的方案如 split k 等,下文介绍的 shuffle 指令就可以避免数据交互,有效加速 K 方向的 reduce 计算。GEMM 的优化则更加复杂,前文已经对 GEMM 优化的方向及核心要素有了详细介绍,这里就不再展开。深度优化本身也是对基础优化技巧和理论的的深度实践,所以本节接下来会从硬件层级结构,如何提高GPU 并行度和带宽优化等方面来向大家介绍一些基础的优化技巧。

1. 硬件层次结构

GPU 的体系结构具有双重层次特征: 存储层次







请到「今天看啥」查看全文