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

正文

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

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

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

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

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

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 技术所带来的性能提升。。

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 数据越精准，就越能接近极限平衡也就是达到最优性能，反之则只能南辕北辙。

除了 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 的体系结构具有双重层次特征： 存储层次

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