ArcLight：突破众核CPU推理瓶颈，NUMA感知架构让LLM推理性能飙升46%

当前大语言模型推理领域呈现出 GPU 追求高性能、CPU 侧重易部署的双轨发展格局。然而，主流 CPU 推理框架难以有效适配广泛部署于 Web 服务器与高端网络设备中的众核 CPU 平台。

这类平台普遍采用非统一内存访问（NUMA）架构，其跨节点的内存访问延迟远高于本地访问，形成了严重的“跨 NUMA 内存访问墙”，成为制约 LLM 推理性能的核心瓶颈。

现有的框架要么未针对 NUMA 架构进行深度优化，要么因代码臃肿、抽象复杂而难以开展细粒度的性能调优。

ArcLight 正是为了应对这一挑战而提出的解决方案。它是一款从零构建的轻量级 LLM 推理架构，旨在为众核 CPU 提供高效、透明的部署底座。其设计遵循极简与模块化的理念，通过整合 NUMA 感知的内存管理、多视图线程调度与细粒度可控的张量并行技术，直接针对跨节点访存这一核心痛点进行优化。

实验验证表明，ArcLight 在众核 CPU 平台上成功突破了主流框架的性能上限，推理吞吐量最高可提升 46%，同时保持了良好的全品类 CPU 兼容性。

一、引言

大语言模型的快速普及催生了对高效推理框架的旺盛需求。当前该领域主要分为两大技术路线：基于高性能 GPU 的系统与易部署的 CPU 端系统。其中，llama.cpp 作为 CPU 推理的开创性框架，凭借其高效的 C++ 实现，成功推动了 LLM 在 CPU 上的落地运行。

然而，主流 CPU 推理框架在适配众核 CPU 平台时面临显著挑战。这类平台普遍采用非统一内存访问（NUMA）架构，将 CPU 核心与内存划分为多个节点。在该架构下，跨节点访问远程内存的开销远高于本地内存访问，如图 1 所示。

图 1：一个拥有 128 个核心、4 个 NUMA 节点的众核 CPU 平台示意图。

现有框架普遍忽视了这一跨 NUMA 内存访问墙。当 LLM 推理任务扩展至数十个核心时，频繁的数据同步与非本地内存访问开销成为主要性能瓶颈，导致系统无法充分利用硬件的理论算力。

对 llama.cpp 这类成熟框架进行 NUMA 感知的深度改造难度极大，需要从底层内存分配、线程管理到顶层模型定义进行全栈式的“精细化重构”。此外，主流框架在持续迭代中代码日益臃肿，遗留代码与复杂的抽象层使得内部逻辑不透明，阻碍了研究者实现细粒度优化或快速适配新兴模型架构。

为了弥补这一技术缺口，本文提出了 ArcLight——一款从零设计、面向众核 CPU 的轻量级 LLM 推理架构。ArcLight 遵循极简与模块化的设计哲学，仅保留实现高性能推理所必需的核心组件。清晰的模块边界使得开发者无需维护庞大的单体代码库即可轻松扩展功能或集成新模型。更为关键的是，ArcLight 针对众核环境提供了定向优化，包括 NUMA 感知的内存与线程管理、细粒度可控的张量并行，从而有效缓解跨节点内存访问带来的性能损失。

实验结果表明，在众核 CPU 平台上，ArcLight 相比当前主流的 llama.cpp，推理吞吐量最高可提升 46%，显著突破了现有框架的性能上限。本文的核心贡献如下：
1. 轻量级推理架构：开源了一款模块化框架，凝练了 LLM 推理的核心能力，为研究者提供了一个透明、可定制的 CPU 端 LLM 部署底座，避免了传统框架的冗余开销。
2. 众核 CPU 多维优化：提出了一套针对众核 CPU 的全维度优化方案，通过优化线程调度与内存访问墙，大幅提升了 CPU 端 LLM 推理的性能边界。

二、系统设计

ArcLight 采用简洁清晰的模块化设计，以极简方式实现 CPU 推理的核心功能，便于后续的扩展与迭代。本章将阐述 ArcLight 的整体架构及其核心设计细节。

2.1 整体架构

如图 2 所示，ArcLight 采用了解耦式架构，分为高层解码前端与底层推理后端。

图 2：ArcLight 系统架构图。

这种设计使得核心计算部分保持轻量级和硬件无关性，同时支持在推理引擎内部进行定向优化。
* 推理后端实现了 CPU 高性能推理所需的最小模块集，包含五大核心模块：内存管理器、线程管理器、张量库、前向计算图构建器、计算图调度器。此外，引擎还内置了专用算子库，包含 LLM 计算所需的数学核函数（如 GEMM、Softmax）。
* 解码前端通过引擎暴露的精简 API 进行交互，负责权重加载、模型定义与自回归解码循环等任务。

整个架构仅由约 10 个 C++ 头文件与源文件构成，体现了其轻量化的设计目标。

2.2 张量库

张量库定义了 ArcLight 中的张量数据结构及其所有运算（计算核函数除外）。与 llama.cpp 采用的 C 风格定义不同，ArcLight 基于 C++ 类实现了严格的面向对象封装，从而提升了代码的模块化程度与可维护性。

ArcLight 中的张量由头信息与数据区两部分组成：
* 张量头存储核心元数据，包括张量名称、形状、数据类型、运算类型、辅助参数，以及用于构建计算图的源张量指针。
* 数据区为一段连续的虚拟内存块。

该库提供了高层接口来管理上述属性，例如获取/设置名称与形状、计算内存分配所需的总字节数等方法。

2.3 内存管理器

内存管理器负责运行时内存的生命周期管理。其核心职责是在程序启动时向操作系统预分配一个足够大的内存池，随后根据需求将池中的内存分配给权重张量与激活张量。

2.3 内存管理器

与 llama.cpp 采用的统一内存访问（UMA）单体缓冲区策略不同，ArcLight 在启用 NUMA 感知后，会在每个 NUMA 节点的本地内存中独立分配缓冲区。这种设计大幅简化了张量与 NUMA 节点的显式绑定过程，如图 3 所示。

图 3：统一内存访问（上）与非统一内存访问（下）的缓冲区管理策略对比。在统一内存访问策略中，NUMA 节点对系统是透明的。

此外，为降低逐层推理过程中的内存开销，我们为激活缓冲区实现了双缓冲机制。两个激活缓冲区按层的奇偶性交替使用，从而显著降低运行时的内存占用，如图 4 所示。

图 4：双缓冲机制示意图。

2.4 线程管理器

线程管理器在推理启动前创建一组工作线程，在运行时协同执行张量计算。llama.cpp 等常规方案将工作线程组织为单一线程池，所有线程执行同一计算任务，这仅适用于单一前向计算图。

图 5：多视图线程组织结构。

为灵活支持单图与多子图执行模式，ArcLight 引入了多视图线程组织，如图 5 所示：
* 在线程池内新增了线程组的逻辑抽象。池的初始化与图执行时提供了显式接口与算子，能够动态重构内部线程组织。
* 当线程池被划分为 n 个组时，这些组可以并行执行 n 个独立的张量运算。

线程组内的屏障同步是推理框架的常规设计，所有线程需同时通过屏障以保证执行进度一致。引入多逻辑线程组织后，屏障管理变得复杂。为此，我们新增了全局屏障机制，以实现整个线程池的跨组同步，如图 6 所示，以此与传统组内屏障进行区分。

图 6：局部屏障与全局屏障对比。“g0t0”表示第 0 组中的第 0 号线程。
* 未启用全局屏障时，同步仅发生在逻辑线程组内部。
* 启用全局屏障后，所有逻辑组线程必须共同到达并通过该屏障。

2.5 前向计算图构建器

与 llama.cpp 类似，ArcLight 采用静态计算图，在执行前完成全图构建。

计算图构建器实现并暴露一组张量运算接口，用于定义图节点。这些接口接收源张量指针与必要参数，返回当前节点对应的输出张量。前端在定义模型时，只需选用并组合这些接口即可构建完整的计算图。

此外，我们简化了主流框架常用的拓扑排序流程。由于模型定义顺序天然遵循拓扑序，因此在每个节点构造函数的末尾将其追加至顺序容器，避免了重新分析图结构的开销。

计算图模块同时实现了 KV 缓存管理，包含 KV 缓存张量的创建、写入（set）、读取（get）等基础操作。本计算图构建设计大量复用了 llama.cpp 的实现思路。

2.6 计算图调度器

计算图构建完成后，所有节点的执行顺序已确定并存储于顺序容器中。调度器按顺序遍历该容器，依次执行每个节点关联的计算（如 GEMM、注意力计算），再进入下一个节点。

为保证执行正确性并避免节点间干扰，每个节点计算完成后会执行屏障同步。在多 NUMA 优化场景下，计算图的构建与调度逻辑更为复杂，将在下一章详细说明。

2.7 张量运算

调度器按顺序处理计算图中的张量运算。

所有算子接口在 ops.h 中声明，其实现与硬件特性相关：
* 拷贝、reshape 等硬件无关运算在 common.cpp 中实现。
* GEMM、FlashAttention 等依赖特定 CPU 指令集的算子，则根据目标硬件进行针对性实现。

例如，不同世代的 ARM CPU 对 GEMM 提供了不同等级的硬件加速支持，NEON 提供 SIMD 指令，而 i8mm 则加速 8 位整数乘法。ArcLight 并未自研算子库，而是重组并复用了 llama.cpp 的算子实现。

三、跨 NUMA 张量并行

在众核平台中，本地内存访问与跨节点访问的延迟差距极大。llama.cpp 等主流框架未针对 NUMA 引发的内存屏障进行显式优化。基于前述推理基础设施，我们提出了跨 NUMA 张量并行方案，以突破众核平台的性能限制。

3.1 跨 NUMA 内存访问

我们首先测量了不同 NUMA 节点间的内存访问速度。在 4-NUMA 节点的测试机上，对不同核心-内存组合进行了基准测试，结果如表 1 所示。

表 1：不同核心-内存组合的内存访问速度（GB/s）。

系统中每个 NUMA 节点管理 6 条 DDR4 内存通道与 48 个 ARM 核心。结果显示，核心访问本地内存的速度约为跨节点访问远程内存的 4 倍，这充分验证了众核平台上存在严重的跨节点内存访问墙。

llama.cpp 仅对众核平台提供了基础支持，通过暴露 --numa 选项，当设置为 distribute 时，线程池的线程会被均匀绑定到不同 NUMA 节点的核心上。然而，它并未将张量显式绑定到指定的 NUMA 节点，导致计算与内存访问频繁不匹配。

图 7：llama.cpp 中的 GEMM 内存亲和性示意图。蓝色表示权重，红色表示激活值。

如图 7 所示，线程分布在各 NUMA 节点，对应的权重区域也相应切分。根据操作系统的“首次访问”策略，物理内存页会在首次被访问的 NUMA 节点上分配。以 GEMM1 为例，若初始激活值仅存在于节点 0，则节点 1-3 的权重分区必须远程访问激活值，产生非本地内存访问。
* GEMM1 完成后，输出的激活张量会均匀分布到所有节点。在执行 GEMM2 时，权重仍切分在各节点，但每个权重分区仅有 1/4 的激活访问是本地访问，其余 3/4 为远程访问。这种模式在后续的 GEMM 运算中持续存在，形成了长期的性能瓶颈。

3.2 权重切分

张量并行（TP）可以减少连续 GEMM 运算间的跨节点数据访问，已广泛用于多设备 LLM 训练。当 CPU 上的跨 NUMA 内存访问成为瓶颈时，张量并行可以从原理上缓解该问题。

如图 8a、8b 所示，与原始 MLP 相比，经过合理切分的矩阵乘法序列可以完全消除跨节点内存访问。

图 8：标准多层感知机（a）、张量并行多层感知机（b）与注意力机制（c）的简化计算图。

在 Transformer 模型中，权重矩阵 ( W_1 )、( W_2 )、( W_3 )、( W_Q )、( W_K ) 按行切分，( W_O )、( W_4 ) 按列切分，即 ( W_Q )、( W_K )、( W_V ) 按注意力头进行切分。

以图中的 MLP 为例，原始计算为 ( Y = phi(XW_1)W_2 )；张量并行下变为 ( Y_i = phi(X_iW_{1,i})W_{2,i} )，最终 ( Y = sum_i Y_i )。所有参与张量并行的张量均被拆分到各 NUMA 节点的本地缓冲区中，从而有效隔离了跨节点内存访问。

3.3 并行计算图

未启用张量并行时，所有线程协同执行同一运算（如 GEMM）。在 CPU 上启用张量并行后，多个算子可以并发执行，计算图变为一组并行子图，需要框架能够灵活切换单图与多子图执行模式。

我们实现了两个核心算子：Scatter（分发） 与 Gather（聚合）。
* Scatter 算子将线程池重构为多个逻辑组，并为每个并行子图的输入创建视图张量。Scatter 完成后，各子图开始并行执行。
* Gather 算子收集并求和所有子图的输出张量，然后将线程池恢复为单组模式。Gather 完成后，执行流程回到非张量并行模式。

3.4 线程同步

如前所述，进入多子图张量并行模式后，各子图相互独立、无数据依赖，即便执行相同的 GEMM 运算也可以异步运行。

图 9：不同线程组同步方式的对比。虚线表示屏障。

启用张量并行后，线程组间的同步有两种方案，如图 9 所示：
* 方案 A：所有线程组使用全局同步，每组完成一个算子后，共同进入下一个算子。
* 方案 B：同步仅限制在每个线程组内部，仅在张量并行段的开始与结束时使用全局屏障。

图示与实验结果均表明，采用子图异步执行（方案 B） 能显著减少线程空闲时间，从而进一步加速张量并行的整体执行。

四、实验

我们在搭载 4 个 NUMA 节点（共计 192 个物理核心）的测试平台上，对比了 ArcLight 与 llama.cpp 的解码吞吐量。

实验设置与结果分析

实验在配备多个NUMA节点的服务器上进行，具体配置如下：
* 每个节点包含 48 个华为鲲鹏 920 核心（ARMv8.2）与 6 个 DDR4 内存通道。
* 操作系统为 Ubuntu 22.04。
* 测试模型为 Qwen3-4B，采用 Q4_0 量化格式，张量运算使用 NEON 向量指令优化。
* 基准测试设定提示词长度为 15 token，生成长度为 256 token。

单 NUMA 节点性能

首先测试所有推理线程绑定到单个 NUMA 节点的场景。

图 10：使用单个 NUMA 节点时的解码速度

如图 10 所示，当推理线程数从 6 增至 48 时，ArcLight 与 llama.cpp 的解码吞吐量均随核心数增加而线性提升。这表明在节点内部高内存带宽支持下，推理任务可以实现良好的横向扩展。
* llama.cpp 的缓冲区未进行 NUMA 感知分配，内存页面由操作系统跨节点分散分配。
* ArcLight 强制进行节点本地内存分配，因此吞吐量表现略优。

多 NUMA 节点性能

随后测试线程均匀分布到多个 NUMA 节点的场景，覆盖 2 节点与 4 节点配置。

图 11：采用多个NUMA节点时的解码速度。“N”表示NUMA节点的数量。

如图 11 所示，在多 NUMA 节点场景下，启用了张量并行的 ArcLight 性能显著优于仅进行线程绑定、依赖操作系统进行内存分配的 llama.cpp。这一性能提升主要源于 ArcLight 通过跨 NUMA 节点的张量并行策略，有效打破了单节点的内存访问带宽瓶颈。此外，3.4 节提出的子图异步执行机制额外带来了约 5 token/s 的性能增益。

长提示词场景性能

为评估框架在处理长上下文时的表现，测试了提示词长度为 300 token 的场景。

图 12：提示词长度为300时，使用多个NUMA节点的解码速度。“N”表示NUMA节点数量。

图 13：提示词长度为300时，使用多个NUMA节点的预填充速度。“N”表示NUMA节点的数量。

如图 12 与图 13 所示，在长提示词场景下，ArcLight 凭借其 NUMA 感知的架构设计，在解码（Decoding）和预填充（Prefilling）阶段均保持了显著的性能优势。

五、相关工作

当前主流的 LLM 推理框架主要分为两类：
* GPU 端：如 vLLM、TensorRT-LLM，通过 FlashAttention、PagedAttention 等技术优化显存管理与计算效率。
* CPU 端：如 llama.cpp、ONNX Runtime，专注于在通用处理器上进行模型部署与推理。

这些框架通过流水线并行、序列并行等技术，致力于解决特定硬件设备的内存与计算瓶颈。然而，它们普遍缺乏对众核 CPU 平台中跨 NUMA 访存瓶颈的系统性优化。

六、结论与局限

本文设计并实现了一个面向众核 CPU 的轻量级 LLM 推理架构 ArcLight。通过重新设计内存管理、线程调度与计算图执行逻辑，并对 NUMA 架构进行针对性优化，ArcLight 在主流 CPU 平台上相比现有框架取得了显著的性能提升。

本工作仍存在以下局限，将在未来工作中持续改进：
* 平台支持：目前仅在 ARM 平台完成验证，对 x86 等其他架构的支持有待后续开发。
* 算子优化：Scatter 与 Gather 等关键算子的实现仍较为初步，后续将聚焦于降低其内存开销与提升并行效率。

关注“鲸栖”小程序，掌握最新AI资讯