使用 mllm-NPU 实现每秒 1000 个 Token 的设备上

LLM 预填充

摘要。

设备上的大语言模型（大语言模型）正在催生新颖的移动应用程序，例如 UI 任务自动化和个性化电子邮件自动回复，而不会泄露用户的私人数据。 然而，由于需要长上下文来生成准确的个性化内容，以及缺乏并行计算能力，设备上的大语言模型仍然存在不可接受的长推理延迟，尤其是第一个词符（预填充阶段）的时间移动CPU/GPU。

为了实现实用的设备上大语言模型，我们推出了mllm-NPU，这是第一个有效利用设备上神经处理单元（NPU）卸载的大语言模型推理系统。 本质上，mllm-NPU是一种算法系统协同设计，解决了大语言模型架构和当代 NPU 设计之间的一些语义差距。 具体来说，它在三个级别上重新构建了提示和模型：（1）在提示级别，它将可变长度提示划分为多个固定大小的块，同时保持数据依赖关系； (2) 在张量级别，它识别并提取显着的异常值，以最小的开销在 CPU/GPU 上并行运行； (3) 在块级别，它根据硬件亲和性和对精度的敏感度，以无序方式将 Transformer 块调度到 CPU/GPU 和 NPU。 与竞争基准相比，mllm-NPU 的预填充速度平均提高 22.4$\times$，节能 30.7$\times$，节能高达 32.8$\times$ 端到端实际应用程序的加速。 mllm-NPU首次实现了十亿级模型（Qwen1.5-1.8B）每秒超过1000个token的预填充，为实用的设备端大语言模型铺平了道路。

1. 介绍

随着隐私问题（gdpr，）的不断增加，人们对在移动设备上本地运行大语言模型（大语言模型）（称为设备上大语言模型)的兴趣日益浓厚，例如 Apple Intelligence (apple-intelligence, ) 和 Android AI Core (AI-Core, )。 与此同时，移动大小的语言模型（1B-10B 参数）的进步，例如 Qwen2-1.5B 和 Phi3-3.7B，已经证明了它们的性能与 GPT-3 等更大的模型相当，尽管参数减少了计数 (abdin2024phi, ; qwen2, ; MMLU-排行榜, )。 这一进展使得设备上语言模型的部署变得可行。 在不泄露隐私数据的情况下，设备上的大语言模型推理可以催化新颖的移动应用程序，例如 UI 任务自动化 (li2024personal, )（例如，将用户的语言命令翻译为 UI 操作，例如“转发给 Alice 的未读电子邮件”）和自动消息回复（电子邮件，）。

然而，高推理延迟仍然是实际设备上大语言模型的重大障碍。 为了完成一个 UI 任务，大语言模型需要摄取屏幕视图层次结构（通常是 600-800 个 token(wen2024autodroid, ; LlamaTouch, ))来逐步生成相应的 UI 操作(wen2023empowering ，）。 正如 $\mathrm{\S }$2.1 中所示，对于 Qwen1.5-1.8B (qwen2, )，每个这样的步骤需要 8.1 秒，因此超过40 秒即可完成 5 步 UI 任务。 同样，Gemma-2B 模型根据历史电子邮件数据（包含 1500 个 Token ）模仿用户的语气，需要 26.7 秒来自动回复电子邮件。 深入研究这些任务，我们发现提示处理（预填充阶段）通常主导端到端推理延迟，例如 UI 自动化任务的 94.4%–98.8%。 这是因为设备上的大语言模型任务通常涉及长上下文理解来处理个性化任务。 不幸的是，现有的研究工作主要集中在加快文本生成速度（解码阶段），例如激活稀疏性 (xue2024powerinfer, ; Song2023powerinfer, ) 和推测解码 (kim2023big, ; miao2023specinfer, ; yang2023predictive ，）。 因此，本工作主要针对提高设备端大语言模型的预填充速度。

大语言模型预填充是有计算限制的(zhong2024distserve, ; patel2023splitwise, ; wu2024loongserve, );然而，移动CPU和GPU的并行计算能力有限(yi2020heimdall, ; han2024pantheon, )。 相反，我们的动机是神经处理单元 (NPU) 在现代移动设备中无处不在，例如 Qualcomm Hexagon NPU 和 Google Edge TPU。 这些移动 NPU 在整数向量运算方面非常高效，计算能力高达 73 TOPS (8gen3, )。 在 CNN 上，它们相对于移动 CPU/GPU 的改进被证明分别高达 18$\times$/4$\times$,(xu2022mandheling, )。 与 CPU/GPU 相比，移动 NPU 也更节能，并且工作负载争用更少。

令人惊讶的是，虽然承诺具有如此多的优势，但目前还没有支持 COTS 移动 NPU 上大语言模型推理的系统。 事实上，我们的基础知识工作表明，由于以下挑战，直接使用移动​​ NPU 进行大语言模型推理并不能提供性能优势。

$\bullet$ 可变长度提示的准备成本很高。 移动 NPU 通常仅支持静态形状的推理，而大语言模型提示长度是动态的（具有最大上下文长度）。 在移动设备上，针对每个不同大小的提示在 NPU 上重新准备和优化大语言模型执行图的成本很高（例如，Gemma-2B 模型需要 11 秒）。 另一方面，简单地将大语言模型请求填充到相同的最大上下文长度会浪费宝贵的计算资源。

$\bullet$ 大语言模型量化算法与移动NPU设计不匹配。 由于存在异常激活(xiao2023smoothquant, ; dettmers2022gpt3, )，最先进的大语言模型量化方法通常使用每组量化来保持高精度。 它将原始激活和权重张量划分为多个具有独立量化尺度的组，以避免异常值对其他组的影响。 然而，我们的调查表明，移动 NPU 无法直接执行每组 MatMul（表2)。 相反，他们必须将 MatMul 拆分为多个组大小的子张量 MatMul，然后使用浮点求和运算来减少子张量中间结果。 此过程会影响 NPU 效率并产生高达 10.7$\times$ 的性能开销。

$\bullet$ 浮点 (FP) 运算无法消除。 移动 NPU 通常提供显着的基于整数的 MatMul 加速，但在 FP 运算方面较弱。 然而，大语言模型很难以最小的精度损失量化为纯整数执行。 现有的量化大语言模型仍然依赖于LayerNorm和Attention等浮点运算符。 将这些 FP 算子调度到 NPU 之外很容易增加推理关键路径。

这项工作提出了mllm-NPU，这是第一个具有高效设备上NPU卸载功能的大语言模型推理系统。 mllm-NPU的主要设计目标是减少预填充延迟和能耗。 它针对大语言模型主流的纯解码器Transformer架构（例如LlaMA、GPT等）。 关键思想是最大限度地提高移动 NPU 上的预填充执行速度，以加速整数计算，同时在 CPU/GPU 上保留基本的浮点运算以保持准确性。 为了克服上述挑战并提高NPU卸载效率，mllm-NPU在三个层面上重新构建了提示和模型：（1）在 提示级别： mllm-NPU将可变长度的提示分为多个固定大小的块，同时保持数据依赖性； (2) 在 张量级别： mllm-NPU 识别并提取显着的异常值以在 CPU/GPU 上运行； (3) 在 块级别： mllm-NPU 根据硬件关联性和对精度的敏感度将 Transformer 块调度到 CPU/GPU 和 NPU。 相应的新技术详述如下：

$\bullet$ 块共享图 ($\mathrm{\S }$3.2) mllm-NPU 拆分可变长度提示分成带有预先构建的子图的固定大小的“块”，从而减少图形准备时间。 然后，在具有块级因果依赖性的那些图上执行每个可变长度提示。 这种方法利用了词符生成仅依赖于仅解码器大语言模型中的先前标记的见解。 然而，同时加载多个预构建的块图会产生显着的内存开销，例如比大语言模型权重多 2-4$\times$。 为了解决这个问题，mllm-NPU 进一步识别与提示大小无关的运算符（例如 FFN），并在每个块执行中共享它们，从而将内存开销减少多达 4$\times$。

$\bullet$ 影子异常值执行 ($\mathrm{\S }$3.3) 在不影响 NPU 效率的情况下解决了激活异常值问题。 在不更改 NPU 上每个张量 MatMul 的情况下，mllm-NPU 将激活异常值通道提取到紧凑张量中，并在 CPU/GPU 上并行执行，因为异常值非常稀疏（0.1%–0.3%）总频道数）。 由于 CPU 内存中重复的 MatMul 权重以及 CPU/GPU 和 NPU 之间的同步开销，该设计进一步引发了内存占用增加的问题。 因此，基于异常值更有可能出现在一小部分通道位置的观察结果，mllm-NPU通过仅将那些“热通道”权重保留在内存中来优化内存使用，并从内存中检索其他权重。按需磁盘。 mllm-NPU还通过测量异常值的重要性来在层级别修剪不重要的异常值，以减少同步开销。

$\bullet$ 乱序子图执行 ($\mathrm{\S }$3.4) mllm-NPU被引导通过一个关键的见解，多个子图可以以无序的方式安排，而不需要严格遵循原始提示中的块顺序。 这显着扩大了mllm-NPU的调度空间，最大限度地减少了CPU/GPU浮点运算带来的执行气泡。 鉴于寻找最优乱序执行顺序是一个NP难题，mllm-NPU采用了微秒级在线调度算法。 该算法基于观察到NPU的工作负载较重并构成关键路径。 因此，在选择执行哪个子图时，mllm-NPU会优先考虑那些对减少NPU停顿影响更显着的子图，而不是仅仅关注子图的执行延迟。 值得注意的是，mllm-NPU的调度算法并没有最大化并行处理能力。 相反，mllm-NPU 旨在最大限度地提高 NPU 的利用率，同时最大限度地减少 CPU/GPU 工作负载的影响。

实施和评估。 我们在 MLLM (mllm, ) 和 QNN (QNN, ) 之上实现了 mllm-NPU，其中包含 10K 行 C/C++ 和汇编代码。 我们使用五个移动大小的大语言模型（Qwen1.5-1.8B (qwen2, )、Gemma-2B (gemma2b, )< 来评估 mllm-NPU /t2>、phi2-2.7B (phi2-2.7, )、LlaMA-2-7B (Llama-2-7b, ) 和 MisTrial-7B （Mistral-7B，）)、四个大语言模型基准测试和两个移动设备（小米 14 和 Redmi K60 Pro）。 我们将 mllm-NPU 与五个竞争基准进行了比较，包括三个工业开源引擎（llama.cpp (llama-cpp, )、TFLite (tflite, ) 、MNN (mnn, )) 和两个最先进的研究原型 (MLC-LLM (mlc-llm, ) 和 PowerInfer-v2 (xue2024powerinfer,))。 实验表明，mllm-NPU 在预填充延迟和能耗方面始终显着优于所有基线，同时保持推理精度（与 FP16 相比损失 ¡1%）。 在 CPU 上比基准快 7.3$\times$–18.4$\times$，在 GPU 上比基准快 1.3$\times$–43.6$\times$，提示长度为1024. 它还实现了 1.9$\times$–59.5$\times$ 的能耗降低。 据我们所知，mllm-NPU是第一个在数十亿规模的大语言模型上在COTS移动设备上实现$>$1000个 Token /秒预填充速度的系统。 在端到端实际应用中，mllm-NPU 与基线相比，推理延迟（预填充+解码）减少了 1.4$\times$-32.8$\times$。

贡献总结如下：

• 我们深入研究了使用移动 NPU 加速大语言模型预填充的挑战和机遇。

• 我们提出了第一个具有高效移动 NPU 卸载的大语言模型推理引擎，具有三种新颖的技术：块共享图、影子异常值执行和乱序子图执行。

• 我们在 mllm-NPU 上进行了全面的实验，证明了其优于竞争基准的性能。 mllm-NPU的代码完全可以在https://github.com/UbiquitousLearning/mllm获取。

2. 背景

2.1. 设备端大语言模型推理分析

端端大语言模型越来越多地应用于Apple智能(apple-intelligence, )、UI自动化(wen2023empowering, )、邮件自动回复等前沿场景（电子邮件，），由于增强的隐私保护。 为了支持这些应用程序，已经开发了许多轻量级大语言模型，如表1所示。 然而，它们的推理延迟仍然是一个重大挑战。 例如，根据 DroidTask (wen2024autodroid, ; LlamaTouch, ) 和 LongBench 数据集 (bai2023longbench, )，这对于实际部署来说是不切实际的。

为了证实这一观察结果，我们在最先进的设备端大语言模型引擎（llama）上使用 Qwen1.5-1.8B 模型评估了 DroidTask（UI 自动化任务）和 LongBench（上下文感知生成任务）数据集.cpp），如图1所示。 结果证实，预填充阶段显着影响推理时间，占总延迟的 94.4% 至 98.8%。 随着提示长度的增加，预填充阶段占总推理时间的比例也会增加。 造成这种情况的因素有很多：(1) 移动 CPU/GPU 缺乏云 GPU (yi2020heimdall, ; han2024pantheon,) 的并行能力，主要是为处理应用程序逻辑或渲染任务而设计的。 (2) 移动大语言模型任务通常需要较长的提示才能进行个性化、上下文感知的生成。 例如，自动电子邮件回复可能需要大量的用户数据，例如历史电子邮件、日程安排和位置信息（超过 1000 个 Token ），而处理 UI 自动化的设备上大语言模型必须处理大量的 UI 标签 Token （XML 或 HTML）和用户命令。 (3) 移动大语言模型现在支持长上下文窗口。 例如，Qwen2-1.5B 等最新模型可以容纳最多 32K 个标记的上下文窗口，如表 1 所示。

表 1。 手机大小的大语言模型的最大上下文长度。

Model	Max Context	Year	Model	Max Context	Year
Opt-1.3B	2K	2022.5	TinyLLaMA-1.1B	2K	2023.9
StableLLM-3B	4K	2023.10	phi-2-2.7B	2K	2023.12
Gemma-2B	8K	2024.2	Qwen1.5-1.8B	32K	2024.2
Phi3-mini-3.8B	128K	2024.5	Qwen2-1.5B	32K	2024.6

(a) Different sequence lengths

(b) Breakdown analysis

图 1。 (a) 在预填充和解码阶段在不同序列长度下生成词符的延迟。 (b) UI 自动化和上下文感知 QA 的端到端推理延迟细分。 两者都使用 llama.cpp 作为设备上的推理引擎。

2.2. 机会：移动 NPU

为了优化预填充延迟，mllm-NPU 利用了一个关键机会：现代移动 SoC 普遍包含非常适合整数运算（例如基于 INT8 的矩阵乘法）的移动神经处理单元 (NPU)。 表2总结了主流厂商提供的知名移动NPU的规格。 例如，高通的移动 SoC 采用 Hexagon NPU，每秒可实现高达 73 万亿次 INT8 运算。 根据 AI-Benchmark (ai-benchmark, ) 的数据，小米 14 中的 Hexagon NPU 仅需 0.6 毫秒即可推理出 MobileNet-V2 模型，比手机快 23$\times$ CPU 比移动 GPU 快 3.2$\times$。

表 2。 主流厂商提供的知名移动NPU规格。

Vendor	Latest NPU	SDK	Open	Group	INT8 Perf.
Qualcomm	Hexagon NPU (8gen3, )	QNN (QNN, )	$\times$	$\times$	73 TOPS
Google	Edge TPU (edgetpu, )	Edge TPU API (Edge-TPU-API, )	$\times$	$\times$	4 TOPS
MediaTek	MediaTek APU 790 (APU-790, )	NeuroPilot (neuropilot, )	$\times$	N/A	60 TOPS
Huawei	Ascend NPU (Ascend-NPU, )	HiAI (hiai, )	$\times$	$\times$	16 TOPS
”Open”: Open-source?; ”Group”: Support per-group quantization MatMul? ”N/A”: No available documents for public; ”INT8 Perf.”: Int8 performance.

移动NPU架构和微实验。 移动 NPU 通过单指令多数据 (SIMD) 架构提供显着的性能优势。 例如，Hexagon NPU 支持 1024 位 INT8 向量运算，允许多个 SIMD 指令并行执行。 然而，与移动 GPU 相比，它们的浮点计算能力相对较弱。 移动 NPU 的时钟频率在 500 至 750 MHz 之间，比移动 CPU 和 GPU 更节能。 此外，与拥有独立物理内存的云GPU不同，移动NPU集成在移动SoC中，与移动CPU共享相同的物理内存，从而无需在NPU执行期间进行内存复制。

为了评估 INT8 MatMul 在移动 NPU 上的性能，我们使用移动大语言模型中常用的 MatMul 尺寸在小米 14 上进行了基础知识实验。 与 CPU INT8 相比，移动 NPU 上的 INT8 MatMul 实现了 4.5–5.8$\times$ 加速，并且比 GPU FP16 有了显着改进。 计算工作量越大，性能提升就越明显。 然而，在移动 NPU 上执行 FP16 MatMul 导致性能比 CPU INT8 慢 159$\times$。 这些结果与移动 NPU 的 INT8 SIMD 架构一致，证实移动 NPU 最适合加速 INT8 矩阵乘法。

图 2。 在移动 NPU 上执行 DNN 的工作流程，以及 QNN (QNN, ) 上每个过程的延迟。

移动 NPU 上的 DNN 执行工作流程。 在移动NPU上执行DNN涉及配置NPU环境、创建计算图、优化图、执行图和释放图，如图2所示。 通常，创建和优化计算图是最耗时的，前者包括将模型转换为 NPU 所需的中间表示和内存分配，需要 300-500ms，而后者包括调整内存布局、执行顺序的优化，以及算子融合，需要很多秒。 此外，NPU SDK的闭源特性也限制了大语言模型的进一步适配。

2.3. 大语言模型与移动NPU之间的差距

鉴于其固有的优势，我们惊讶地发现现有的DNN引擎都不支持移动NPU上的大语言模型加速。 然后我们深入挖掘根本原因，发现现有移动 NPU 设计与大语言模型推理流程之间存在巨大差距。

$\bullet$ 大语言模型预填充阶段依赖于可变长度的提示，导致在构建和编译 NPU 图上花费过多的时间。 如图2所示，在移动NPU上执行计算图之前，必须对其进行构建和优化，该过程需要数十秒。 例如，使用 QNN 框架为 Gemma 2B 模型构建图需要 360 毫秒，图优化需要 11.54 秒。 与 CNN 模型不同，CNN 模型构建和优化一次，并且可以使用相同的输入形状多次执行，大语言模型预填充阶段必须处理可变长度的提示，需要为每个推理重建和重新优化计算图。 因此，在这种情况下使用移动 NPU 不会带来任何性能优势，而且速度通常比使用 CPU 慢。

图 3。 每张量量化 MatMul 和每组量化 MatMul。 $seq$、$hds$、$group$分别表示序列长度、隐藏大小和组数。

图 4。 使用 Qualcomm QNN 框架的小米 14 上不同量化算法在 HelloSwag 数据集上的预填充延迟和准确性。

$\bullet$ 激活异常值的存在使得大语言模型难以在全张量级别上进行量化，而更细粒度的组级别量化又会阻碍NPU的效率。 我们的预备知识实验如图 4 所示，表明两种流行的量化算法（K-Quant (llama-cpp, ) 和 AWQ (lin2023awq, ))与每张量量化相比，会产生 8.1$\times$–10.7$\times$ 的显着推理开销（图 3(a)）。 这是因为 K-Quant 和 AWQ 等算法使用细粒度的每组量化（图3(b)）来保持高精度。 这些算法将激活和权重分为多个组，每个组都有独立的量化尺度。 在NPU上，这种方法需要将MatMul操作分成多个子张量MatMul，这无法充分利用移动NPU的能力。 此外，它需要通过浮点加法来聚合中间结果，从而导致额外的浮点计算。 SmoothQuant (xiao2023smoothquant, ) 是个例外，它使用每个张量量化，但精度损失很大，例如 LlaMA-2-7B 和 HelloSwag 数据集上的精度分别下降了 3.9% 和 8.4%分别为Qwen1.5-1.8B型号。

图 5。 量化设备端大语言模型推理的工作流程。 蓝色显示的操作是使用 INT4/INT8 格式计算的，而橙色显示的操作是使用浮点数据格式计算的。

表 3。 最先进的量化推理方法中的运算符数据格式。 第一行中的每个模块如图5所示。

Quantization	Type	Acc.	Cal QKV	Atten.	Cal O	Norm.	FFN
K-Quant (llama-cpp, )	Per-Group	Low	INT8	FP16	INT8	FP16	INT8
GPTQ (frantar2022gptq, )	Per-Group	High	FP16	FP16	FP16	FP16	FP16
AWQ (lin2023awq, )	Per-Group	High	FP16	FP16	FP16	FP16	FP16
SmoothQuant (xiao2023smoothquant, )	Per-tensor	Low	INT8	FP16	INT8	FP16	INT8
”Atten.”:Attention; ”Norm.”: Normalization.

$\bullet$ 端上大语言模型推理依赖于浮点运算，与NPU的INT8加速设计相冲突。 图5说明了量化推理的典型工作流程。 为了确保推理精度，只有线性层（以蓝色突出显示）以 INT8/INT4 数据格式执行矩阵乘法。 对于这些层，在执行与权重的点积之前，激活 $x$ 被量化为 INT8/INT4。 其他操作，例如 Attention 和 LayerNorm（以橙色突出显示），以浮点格式计算。 表3进一步总结了最先进的量化推理算法中的算子数据格式。 所有这些都依赖于浮动注意力和标准化操作。 鉴于浮点运算会极大地降低移动 NPU 的性能，因此这些运算无法在 NPU 上高效执行，且开销较大。

3。 mllm-NPU设计

图 6。 mllm-NPU的工作流程。

3.1. mllm-NPU概述

设计目标。 mllm-NPU旨在通过设备上的NPU卸载来减少移动大小的大语言模型的预填充延迟和能耗。 它支持设备上的各种移动大小的大语言模型，并且可以作为LLM即系统服务的一部分集成到移动操作系统或移动应用服务中（yin2024llm，；yuan2024mobile，）。

工作流程。 图6说明了mllm-NPU的工作流程。 mllm-NPU的核心思想是最大化其在移动NPU上的执行，以实现整数运算加速；同时在 CPU/GPU 上保留必要的浮点运算，以免影响精度。 为了实现更高效的 NPU 卸载，mllm-NPU 通过以下方式重新构建提示和模型： (1) 提示级别： 可变长度提示被缩减为多个固定大小的块，并保留数据依赖性； (2) 在 块级别： Transformer块根据CPU/GPU和NPU的硬件无限性和精度敏感性被调度到CPU/GPU和NPU中； (3) 在 张量级别： 识别并提取重要的异常值以在 CPU/GPU 上运行。

$\bullet$ 准备阶段。 mllm-NPU首先使用增强的每张量量化算法将大语言模型量化为W8A8格式。 量化算法与现有算法不同，因为它过滤掉最不重要的激活异常值，并将其余的提取到独立的、轻量级的算子中，与原始算子互补。 mllm-NPU 还生成固定长度的块共享图 ($\mathrm{\S }$3.2)，以有效处理可变长度的提示。

$\bullet$ 执行阶段。 当收到提示时，mllm-NPU将其分成固定大小的块并按因果关系进行处理。 这些块图将根据数据格式分成调度到 CPU/GPU 和 NPU 上的子图，以实现高效执行。 为了保持准确性，某些基于 INT8 的线性层在 CPU/GPU 上并行进行稀疏浮点离群值阴影执行，以补偿离群值的量化误差 ($\mathrm{\S }$3.3)。 为了提高执行效率，mllm-NPU以无序方式明智地调度块($\mathrm{\S }$3.4)。

3.2. 块共享图执行

为了解决动态提示长度的挑战，一个直观的解决方案是预先设置一个固定长度的计算图并使用填充(tillet2019triton, ; olston2017tensorflow, ; FastTransformer, )。 然而，这种方法缺乏灵活性，并且过多的填充会浪费计算资源。

图7。 提示图、块图和块共享图的图示。 块长度为 32。

分块预填充。 为了增强灵活性并最小化可变长度提示的填充，我们认识到在大语言模型中处理长提示相当于按因果关系处理多个分割的子提示或“块”。 这是可行的，因为流行的大语言模型使用仅解码器架构，其中第$i$词符的结果仅取决于前面的标记。 为此，mllm-NPU 首先在准备阶段预构建和预优化基于固定长度块的 NPU 计算图。 在推理过程中，mllm-NPU 将长提示拆分为多个块，并使用这些预先构建的块图对其进行处理，如图 7(b) 所示。

然而，单独使用块图是不可扩展的，因为 mllm-NPU 需要在内存中存储大量不同的块图，从而显着增加内存开销。 这是因为不同的块图具有不同大小的注意力运算符。 例如，考虑到提示长度为 1024 和块长度为 32，第一个块的注意算子的 QKV 维度大小均为 $32\ast hds$，而最后一个块的注意算子的 QKV 维度大小分别为 $32\ast hds$、$1024\ast hds$ 和 $1024\ast hds$，如图 7(b)所示。

块共享图。 mllm-NPU基于大语言模型算子落入的洞察，引入了块共享图，如图7(c)所示两个不同的类别：（1）静态运算符（绿色），例如 Linear 和 LayerNorm，它们仅依赖于块长度并且可以在不同块之间共享； （2）动态算子（红色），例如Attention，它依赖于块长度和块顺序，并且不能在不同块之间共享。 因此，mllm-NPU根据算子的共享性将大语言模型划分为多个子图。 共享子图构建并优化一次，而非共享子图针对不同块单独构建。 在预填充阶段，来自不同块的激活通过相同的静态运算符子图，同时动态选择适当的特定于维度的动态运算符。 这种方法显着减少了内存开销并增强了可扩展性，因为大多数动态运算符（例如注意力）不包含权重，只需要激活缓冲区。

我们的实验表明，144 个子图中的 120 个可以在 Qwen1.5-1.8B 模型中共享，对于提示长度为 1024 和块长度为 256 的情况，内存消耗最多可减少 75% (7.2GB)。

图8。 QKV Linears 和 FFN 在不同块长度下的每个 Token 延迟。

我们还进行了广泛的实验来选择合适的块长度。 两个流行的大语言模型（Qwen1.5-1.8B和Gemma-2B）在小米14设备上的结果如图8所示。 根据观察，mllm-NPU经验性地为小米14设备选择了256的块长度，这有效地利用了移动NPU的能力，同时减少了块内填充。 实际上，这种分析需要在不同的 NPU 上执行。

图 9。 影子异常值执行的工作流程。

3.3. 影子异常值执行

为了在不影响大语言模型精度的情况下实现 NPU 友好的每张量激活量化，mllm-NPU 采用了一种称为影子异常值执行的新颖方法。 如图9所示，mllm-NPU将运行时存在异常值的激活通道提取为更紧凑的张量，在CPU上执行，并将其合并回结果NPU 上的原始算子。 该程序可以表述如下：

(1) ${\displaystyle \frac{x}{s}}\odot w=$ $\left\{\min [\max ({\displaystyle \frac{x}{s}},-127),128]+\lfloor {\displaystyle \frac{x}{s}}/128\rfloor \times 128\right\}\odot w$

$=$ $\min [\max ({\displaystyle \frac{x}{s}},-127),128]\odot w\text{on NPU}$

$+$ $extract\left(\lfloor {\displaystyle \frac{x}{s}}/128\rfloor \times 128\right)\odot w\text{on CPU}$

其中 $x$、$w$、$s$、$\odot$ 和 $extract$ 表示原始浮动激活、INT8 权重，分别是量化比例因子、MatMul 运算和将激活异常值提取到更紧凑的张量中的函数。 具体来说，根据结合律，MatMul$\frac{x}{s}\odot w$可以等价地分为两部分之和： (1) 适用于规模内 MatMul 的移动 NPU。 mllm-NPU首先根据比例因子$s$将$x$量化并舍入到-127到128的范围。然后，它通过使用权重 $w$ 执行标准 W8A8 每个张量 MatMul 来获得中间结果。 (2) 用于 MatMul 的移动 CPU/GPU 超出规模。 mllm-NPU计算超过$s$的部分值。由于这些异常值很少见，mllm-NPU 从张量中提取这些值，将它们压缩为密集张量，并使用权重 $w$ 执行 MatMul。

由于异常值非常稀疏（大约 5-15 个通道，仅占总通道的 0.1%-0.3%，如图 10 所示），因此 CPU 上的 Shadow 执行速度比NPU上的原始张量，其执行时间可以通过重叠完全隐藏。 为了进一步最小化这个额外过程的开销，mllm-NPU通过离线分析大型语料库来确定异常值阈值（即等式1中的$s$)，从而可以识别异常值通过简单地将激活数与该阈值进行比较来确定异常值。 阴影异常值执行的设计与任何每张量量化算法兼容，mllm-NPU当前的原型基于简单的最大-最小对称量化(jacob2018quantization, ).

虽然影子异常值执行似乎很好地平衡了 NPU 亲和力和大语言模型准确性，但需要解决两个更关键的问题才能使其实用。 首先，虽然移动SoC对异构处理器使用统一的存储芯片，但它们使用独立的存储空间。 为了启用激活异常值的影子执行，mllm-NPU 必须在 CPU 内存空间上保留每个 MatMul 权重的另一个副本。 这使内存占用增加了近 2 倍。 其次，虽然异常值的执行即使在 CPU 上也很快，但 CPU 和 NPU 之间的降和同步仍然需要不小的开销，例如，Qwen1.5 上的端到端延迟为 29.7%，能耗为 20.1%。 1.8B。

图10。 使用 wikitext 数据集在 2048 推断下的 Qwen1.5-1.8B 模型上每层离群值通道的平均数量和百分比。 在一次推理过程中，只有不到 0.3% 的通道存在异常值。

图11。 使用 wikitext 数据集在 2048 推断下的 Qwen1.5-1.8B 模型上每个通道的异常值时间。 不到 3% 的渠道贡献了超过 80% 的异常值。

大多数异常值往往出现在一小部分通道位置中。 我们观察到，虽然在处理长提示期间（例如 78%），异常值出现在各种通道位置，但这种外观是高度倾斜的——很少有通道主导异常值的出现。 例如，如图 11 所示，在 Qwen1.5-1.8B 和 LlaMA-2-7B 模型的各种输入中，不到 3% 的通道对大多数异常值（超过 80%）有贡献。 因此，对于影子异常值执行，mllm-NPU仅将那些“热通道”需要使用的张量权重保留在CPU内存空间中，如果这些“热通道”上存在异常值，则从磁盘中检索其余部分。位置在运行时被提取（这种情况很少见）。 请注意，权重检索也可以与原始 MatMul 的 NPU 执行重叠。 这种方法将影子执行的内存开销减少了 34.3%，并且延迟可以忽略不计。

大多数异常值都可以被修剪，而不影响准确性。 令人惊讶的是，我们观察到大多数 MatMul 算子上的激活异常值对大语言模型的准确性并不重要，可以简单地删除。 这里，异常值的重要性通过最大异常值与量化尺度之间的比率来衡量（等式 1 中的 $s$)。 比率越大表示激活分布越分散，导致量化误差越显着。 mllm-NPU 使用离线阶段的大型语料库数据来分析这些异常值的重要性（图12)，并修剪大部分不重要层的异常值。 通常，我们观察到输入和输出附近的层具有更高的重要性。 这是因为靠近输入的层很容易受到 Token 差异的影响，表现出更大的波动，而靠近输出的层很容易积累来自浅层的误差。 根据观察，mllm-NPU通过离线分析修剪前85%最不重要层的异常值，从而消除CPU-NPU同步。

图 12。 左：Qwen1.5-1.8B 模型中不同层的异常重要性。 右图：HellaSwag 和 Winograde 数据集上的准确度与修剪层之间的关系。

3.4. 子图乱序执行

如($\mathrm{\S }$2.3)所述，大语言模型量化算法无法完全消除浮点运算，mllm-NPU因此将其执行流程划分为NPU以及CPU/GPU协同。 通常，LayerNorm、Attention以及阴影异常值计算都放在CPU/GPU上；而其他线性层则在 NPU 上处理。 然而，我们发现简单地重叠执行效率很低，会导致较大的执行泡沫（关键路径中的泡沫率为37%），如图13(a)所示。

无序执行。 为了减少这些执行气泡，mllm-NPU 以一个关键见解为指导，即在块和子图级别进行分区后，大语言模型子图可以以无序方式进行调度。 更具体地说，任何输入就绪的子图都可以在不严格遵循块序列的情况下执行。 例如，当 C2-Graph1 完成时，可以在冒泡期间执行第三个块 (C3-Graph1) 的第一个子图。

图 13。 无序子图执行。

为了保持正确性，mllm-NPU 考虑两种类型的依赖关系：(1) 跨块依赖。 像 Attention 这样的算子依赖于之前块的数据。 这意味着 $i$ 块 $j$ 子图 $G_{i,j}$ 依赖于 $0,1,\mathrm{\dots },i-1$ 块的 $j-1$ 子图：

(2) $G_{i,j}\leftarrow G_{0,j-1},G_{1,j-1},\mathrm{\dots },G_{i,j-1}$

(2) 块内依赖性。 LayerNorm、Linear 和 Quantize 等运算符仅依赖于同一块中的先前子图。 因此，第 $i$ 块的第 $j$ 子图 $G_{i,j}$ 取决于同一块的第 $j-1$ 子图：

(3) $G_{i,j}\leftarrow G_{i,j-1}$

由于移动处理器在并行性和抢占性方面较弱(yi2020heimdall, ; han2024pantheon, ; xu2022mandheling, )，为了确保效率，处理器在任何给定时间只能执行一个子图。:

(4) ${\displaystyle \sum _{i=0}^N}{\displaystyle \sum _{j=0}^M}{P}_{i,j,t}=1,\forall t$

其中 $P_{i,j,t}=1$ 表示子图 $G_{i,j}$ 正在处理器 $P$ 上运行，时间 $t$,$N$ 和 $M$ 分别表示块和子图的最大数量。 mllm-NPU旨在找到一个执行顺序，在这些约束下最小化所有子图的总执行时间。 不幸的是，这个调度问题可以简化为经典的 NP 难旅行商问题(hoffman2013traveling, )。 而且，由于块的数量随用户提示而变化，无法离线生成最优调度策略。

相反，mllm-NPU 使用在线启发式算法。 关键思想是不要关注子图 $g$ 的执行时间，而是关注执行 $g$ 如何有助于减少 NPU 停顿，其动机是观察到在预填充阶段，NPU执行时间通常主导推理延迟，是关键路径。 例如，使用 Qwen1.5-1.8B 模型，提示长度为 256，NPU 执行需要 315ms，大约是 CPU 的两倍。

具体来说，我们定义子图$g$对减少NPU停顿的贡献如下：如果子图$g$要在CPU/GPU上执行，则让$S$是$g$完成后可以执行的一组新子图。 $S$将在NPU上执行。 $S$执行时间较长有利于减少NPU卡顿。 因此，$g$的贡献被定义为$S$的总执行时间。相反，如果$g$在NPU上执行，$S$的执行时间越短越好，$S$的执行时间的负值为$g$ 的贡献，公式为：

(6) $C=\begin{array}{c}\{\begin{array}{c}\sum T_i,\forall i\in S\text{if}g\text{is on the CPU/GPU}\\ -\sum T_i,\forall i\in S\text{if}g\text{is on the NPU}\end{array}\hfill \end{array}$

其中 $T$ 是子图执行时间。 mllm-NPU始终选择$C$最大的子图，这意味着$S$的子图$g$在网络上执行时间最长NPU 或 CPU/GPU 上的最短执行时间。

简而言之，mllm-NPU 在准备阶段离线分析所有子图执行时间及其依赖关系。 在预填充阶段，它会计算所有待处理的子图 $C$ 值，并选择具有最大 $C$ 的子图来运行，性能开销为微秒级。

4. 实施与评估

我们已经为 Qualcomm Hexagon NPU 全面实现了 mllm-NPU，包括 10K 行 C/C++ 和汇编语言代码。 我们选择高通 SoC 作为目标平台，因为它在移动设备上的受欢迎程度和强大的 NPU 能力。 Qualcomm Hexagon也是唯一一款具有开放指令集架构的移动NPU。 mllm-NPU 建立在 MLLM (mllm, )（一种最先进的移动大语言模型引擎）和 QNN 框架 (QNN, )，高通神经处理 SDK。 支持Hugging Face (Hugging-Face, )导出的标准大语言模型格式。 为了方便大语言模型的执行，除了QNN支持的算子之外，我们还实现了KVCache、SiLU、RMSNorm、ROPE等特定算子。 为了减少 CPU/GPU 和 NPU 之间的上下文切换开销，mllm-NPU 利用共享缓冲区来同步来自不同处理器的中间结果。 对于端到端推理，mllm-NPU与任何解码引擎兼容，并利用 MLLM CPU 后端进行解码阶段，易于实现，默认块长度为 256。 离群层的默认剪枝率为 85%。

该原型还包含两项优化。 (1) 我们广泛的实验表明，移动 NPU 通常更喜欢 CNN 架构中的张量大小（例如，相等的“高度”和“宽度”）。 例如，权重为 2048$\times$2048 的线性层对于 1024×1×2048 和 32$\times$32$\times$2048 的输入产生相同的结果，但是使用 32$\times$32$\times$2048 将执行延迟减少 1.62$\times$。 因此，mllm-NPU 在准备阶段会分析线性层的所有可能的等效形状，并选择最有效的一个。 (2) 移动 NPU 通常访问有限的内存区域（例如，Hexagon NPU 为 4GB），该内存区域可能小于大语言模型权重的大小。 为了在有限的内存内最大化预填充加速，mllm-NPU优先在 NPU 上执行计算密集型任务，例如 FFN，以提高效率。

4.1. 实验设置

硬件设置。 我们在两台配备不同 Qualcomm SoC 的智能手机上测试 mllm-NPU：小米 14（Snapdragon 8gen3，16GB 内存）和 Redmi K60 Pro（Snapdragon 8gen2，16GB 内存）。 所有设备均运行 Android OS 13。

模型和数据集。 我们使用多种典型的移动端大语言模型进行了测试：Qwen1.5-1.8B (qwen2, )、Gemma-2B (gemma2b, )、Phi2- 2.7B (phi2-2.7, )、LLaMA2-Chat-7B (Llama-2-7b, ) 和 Mistral-7B (Mistral-7B, ) 。 为了评估mllm-NPU的量化精度，我们采用了广泛认可的大语言模型基准，包括LAMBADA (lambada, )、HellaSwag (zellers2019hellaswag, )、WinoGrande (ai2:winogrande, )、OpenBookQA (OpenBookQA2018, ) 和 MMLU (hendryckstest2021, )。 对于推理速度实验，我们选择了来自 Longbench、2wikimqa 和 TriviaQA (bai2023longbench, ) 的基于检索的数据集，用于模拟上下文感知生成任务，例如自动电子邮件回复。 此外，我们还使用 DroidTask 数据集 (LlamaTouch, ) 评估了屏幕问答和将指令映射到 UI 操作场景中的 mllm-NPU，以模拟基于代理的 UI 自动化任务。

图 14。 不同设备上不同提示长度下的预填充速度（数据集：Longbench-2wiki-Multi-doc QA）。

图 15。 Redmi K60 Pro 不同提示时长下的能耗（数据集：Longbench-2wiki-Multi-doc QA）。

基线。 我们主要将 mllm-NPU 与 5 个基线进行比较，包括 3 个广泛使用的移动大语言模型引擎 (TFLite (tflite, )、 MNN (mnn, ) 和 llama.cpp (llama-cpp, ))。 这些引擎仅支持移动CPU和GPU； 2 个高级基线是 MLC-LLM (mlc-llm, )（用于设备上 GPU 的大语言模型编译器）和 PowerInfer-v2 ，它还利用移动 NPU 来加速预填充(xue2024powerinfer, )。 由于 PowerInfer-v2 不是开源的，我们使用其论文中报告的数据。 需要注意的是，这些基线通常仅支持我们评估的 5 个大语言模型的子集。

指标。 我们主要测量大语言模型的推理精度、预填充延迟、预填充能耗、预填充内存消耗和端到端推理延迟。 Android 操作系统中通过 /sys /class/power_supply 每 100ms 进行一次分析来获取能耗。 所有实验重复三次，我们报告平均数。

4.2. 预填充性能。

我们在两台设备上以 64、256 和 1024 个 Token 的提示长度评估 mllm-NPU 的预填充性能（速度和能耗），如图 14 所示15。 尽管数据集之间存在异常值，但对预填充性能的总体影响很小，因此我们报告了 LongBench 数据集的结果。 结果表明 神经网络处理单元 在这两个指标上始终优于所有基线，并且随着提示长度的增加，优势变得更加明显。

预充速度。 对于 1024 个 Token 的提示长度，mllm-NPU 可以将预填充延迟减少 18.17–38.4$\times$、7.3$\times$、32.5–43.6$\times$、小米 14 上分别与 llama.cpp-CPU、MNN-CPU、MLC-GPU、TFLite-GPU 相比为 1.27–2.34$\times$。 在 Redmi K60 Pro 上，这些改进为 21.3–41.3$\times$、7.43$\times$、37.2–69.3$\times$ 和 1.3–2.6$\times$ 分别。 这些加速归功于 mllm-NPU 使用了三种充分利用移动 NPU 的创新技术，包括阴影异常值执行、高效每张量 MatMul 和 乱序子图执行。 与同样使用 NPU 进行预填充的基线 PowerInfer-V2-NPU 相比，mllm-NPU 可以实现 3.28–5.32$\times$ 和 3.4–5.6$\times$ 加速通过采用 NPU 友好的 INT8 线性计算和细粒度子图调度($\mathrm{\S }$3.4)分别在两个设备上实现。

在提示符长度为 64 的情况下，mllm-NPU 的预填充速度比 llama 快 14.86-7.10$\times$、1.69$\times$、10.91-17.32$\times$、1.48$\times$ 和 1.81-2.51$\times$。cpp-CPU、MNN-CPU、MLC-GPU、TFLite-GPU 和 PowerInfer-V2-NPU 的速度分别比 1024 个词符提示的速度平均低 10.5$\times$、4.31$\times$、2.68$\times$、1.02$\times$ 和 1.96$\times$。 这是因为较短的提示可能会导致填充问题并限制 mllm-NPU 的乱序执行调度效率。

预充能源消耗。 能耗评估是在唯一可 Root 的设备 Redmi K60 Pro 上进行的。 PowerInfer-V2 由于缺乏能耗数据和开源代码而被排除在外。 对于 1024 个 Token 提示，mllm-NPU 将能耗降低 35.63–59.52$\times$、35.21–59.25$\times$ 和 1.85–4.32$\times$ 分别与 llama.cpp-CPU、MLC-GPU 和 TFLite-GPU 进行比较。 对于 64 个 Token 提示，节省的成本分别为 10.38–14.12$\times$、10.38–17.79$\times$ 和 3.22–3.67$\times$。 这些节省归功于移动 NPU 的高能效以及 mllm-NPU 的三项新技术，可最大限度地提高 NPU 性能。

表 4。 使用小米 14 上的真实移动应用程序执行来进行不同框架的端到端延迟比较。

LLM	Datasets	MLC	LCPP	MNN	PI	TFLite	Ours	Speedup	Datasets	MLC	LCPP	MNN	PI	TFLite	Ours	Speedup
Qwen1.5-1.8B	Longbench: 2wiki -Multi-doc QA (prompt length: 1500 tokens)	45.6	26.7	10.6	-	-	1.7	6.2-26.8$\times$	Longbench: TriviaQA (prompt length: 1500 tokens)	46.0	27.0	11.2	-	-	2.0	5.6-23.0$\times$
Gemma-2B		78.4	34.6	-	-	2.6	1.9	1.4-41.3$\times$		81.8	36.2	-	-	2.8	2.2	1.3-37.2$\times$
Phi-2-2.7B		87.0	53.3	13.0	-	6.3	3.1	2.0-28.1$\times$		91.4	56.3	14.7	-	6.8	3.6	1.9-25.4$\times$
LlaMA-2-7B		184.7	146.0	22.4	19.8	-	5.3	3.7-34.8$\times$		197.3	156.2	23.8	21.8	-	6.2	3.5-31.8$\times$
Mistral-7b		254.2	200.2		20.0	-	5.5	3.6-46.2$\times$		266.2	210.0	-	21.5	-	6.4	3.4-41.6$\times$
Geo-mean (speedup)		34.7$\times$	21.8$\times$	4.8$\times$	3.7$\times$	1.7$\times$	-			31.0$\times$	19.6$\times$	4.4$\times$	3.4$\times$	1.6$\times$	-
LLM	Datasets	MLC	LCPP	MNN	PI	TFLite	Ours	Speedup	Datasets	MLC	LCPP	MNN	PI	TFLite	Ours	Speedup
Qwen1.5-1.8B	DroidTask: clock (prompt length: 800 tokens))	21.0	10.4	3.9	-	-	1.4	2.8-15.0$\times$	DroidTask: applauncher (prompt length: 600 tokens)	16.2	8.1	3.1	-	-	1.1	2.8-14.7$\times$
Gemma-2B		39.4	16.5	-	-	2.5	1.2	2.1-32.8$\times$		29.4	12.3	-	-	1.9	0.9	2.1-32.7$\times$
Phi-2-2.7B		46.6	25.0	7.4	-	4.2	3.1	1.4-15.0$\times$		35.4	19.0	5.9	-	3.2	2.4	1.3-14.8$\times$
LlaMA-2-7B		87.7	60.4	10.6	11.1	-	4.8	2.2-18.3$\times$		63.7	43.9	7.7	8.2	-	3.6	2.1-17.7$\times$
Mistral-7b		122.3	68.6	-	12.0	-	4.9	2.4-25.0$\times$		90.1	50.6	-	8.9	-	3.8	2.3-23.7$\times$
Geo-mean (speedup)		20.2$\times$	10.8$\times$	2.4$\times$	2.4$\times$	1.7$\times$	-			19.7$\times$	10.5$\times$	2.5$\times$	2.3$\times$	1.7$\times$	-
*LCPP and PI in the first row represent llama.cpp and PowerInfer-V2, respectively.

4.3. 端到端性能

我们使用两种工作负载来对照基准系统评估 mllm-NPU 的实际性能：DroidTask 数据集上的 UI 自动化和 LongBench 数据集上的上下文感知自动电子邮件回复。 端到端推理延迟结果如表4所示。 我们的主要观察是 神经网络处理单元 始终在所有四个数据集上实现最低的推理延迟。

对于 LongBench 数据集，mllm-NPU 显示出显着的速度提升：比 llama.cpp-CPU 提高 23.0–46.2$\times$，比 MLC-LLM 提高 16.5–36.4$\times$ -GPU，MNN-CPU 上为 4.08–4.19$\times$，PowerInfer-V2-NPU 上为 3.51–3.73$\times$，TFLite-GPU 上为 1.27–2.03$\times$ 。 这种令人印象深刻的性能主要归功于 mllm-NPU 在预填充阶段的卓越效率。 相对于 TFLite-GPU 的加速比较低，因为 mllm-NPU 目前依赖 CPU 后端进行解码，没有进行优化，而 TFLite 使用 GPU。 值得注意的是，mllm-NPU与任何解码引擎兼容，这意味着一旦TFLite开源，mllm-NPU可以将其集成为解码后端，从而有可能进一步增强性能。

对于 DroidTask 数据集，mllm-NPU 与 llama.cpp-CPU 相比，端到端推理延迟减少了 7.9-12.5$\times$；与 MLC-LLM-GPU 相比，端到端推理延迟减少了 15.0-32.8；与 MNN-CPU 相比，端到端推理延迟减少了 2.38-2.45。8$\times$，与 MLC-LLM-GPU 相比降低了 2.38-2.45$\times$，与 MNN-CPU 相比降低了 2.27-2.44$\times$，与 PowerInfer-V2-NPU 相比降低了 1.35-2.38，与 TFLite-GPU 相比降低了 1.35-2.38$\times$。 DroidTask 数据集的性能提升略小，因为 UI 自动化中的提示比电子邮件编写中的提示更短。

表 5。 大语言模型在mllm-NPU和基线上的能力精度。 “SQ”：SmoothQuant； ”Int8()”: 大语言模型.Int8(); “Degrad.”：与 FP16 相比，精度下降。

LAMBADA	FP16	SQ	INT8()	K-Quant	Ours	Ours Degrad.
Qwen1.5-1.8B	71.1%	65.6%	71.0%	62.7%	71.7%	+0.6%
Gemma2-2B	59.6%	45.8%	59.2%	56.9%	59.4%	-0.2%
Phi-2-2.7B	72.2%	66.1%	71.7%	59.3%	67.5%	-4.7%
LlaMA-2-7B	87.5%	71.9%	88.0%	15.6%	86.3%	-1.2%
Mistral-7b	84.8%	51.2%	85.3%	23.9%	84.1%	-0.7%
Avg. Degrad.	-	-14.9%	0%	-31.3%	-1.2%

HellaSwag	FP16	SQ	INT8()	K-Quant	Ours	Ours Degrad.
Qwen1.5-1.8B	43.8%	40.9%	43.5%	44.3%	43.8%	0%
Gemma2-2B	46.5%	43.8%	46.1%	45.4%	47.3%	+0.8%
Phi-2-2.7B	48.2%	46.2%	47.7%	47.6%	46.9%	-1.3%
LlaMA-2-7B	52.8%	44.4%	53.1%	50.5%	53.5%	+0.7%
Mistral-7b	57.4%	44.9%	57.9%	57.0%	57.0%	-0.4%
Avg. Degrad.	-	-5.7%	-0.1%	-0.8%	-0.0%

WinoGrande	FP16	SQ	INT8()	K-Quant	ours	Ours Degrad.
Qwen1.5-1.8B	58.3%	51.0%	58.2%	59.0%	59.3%	+1.0%
Gemma2-2B	58.3%	54.8%	59.0%	58.5%	59.5%	+1.2%
Phi-2-2.7B	72.2%	68.9%	72.4%	72.5%	70.2%	-2.0%
LlaMA-2-7B	65.2%	56.9%	66.2%	67.4%	65.1%	-0.1%
Mistral-7b	73.5%	59.1%	73.3%	73.5%	73.1%	-0.4%
Avg. Degrad.	-	-7.4%	+0.3%	+0.7%	-0.1%

OpenBookQA	FP16	SQ	INT8()	K-Quant	ours	Ours Degrad.
Qwen1.5-1.8B	28.8%	23.0%	28.5%	28.0%	26.6%	-2.2%
Gemma2-2B	33.7%	28.0%	34.2%	33.0%	38.4%	+4.7%
Phi-2-2.7B	41.0%	35.9%	40.2%	39.5%	37.7%	-3.3%
LlaMA-2-7B	32.7%	25.0%	32.0%	31.5%	31.1%	-1.6%
Mistral-7b	39.4%	25.6%	39.3%	37.9%	39.3%	-0.1%
Avg. Degrad.	-	-7.6%	-0.3%	-1.1%	-0.5%

MMLU	FP16	SQ	INT8()	K-Quant	ours	Ours Degrad.
Qwen1.5-1.8B	29.7%	27.9%	29.1%	29.8%	30.8%	+1.1%
Gemma2-2B	35.7%	32.1%	35.1%	35.1%	36.4%	+0.7%
Phi-2-2.7B	35.4%	35.3%	35.6%	35.7%	36.7%	+1.3%
LlaMA-2-7B	37.8%	29.2%	38.1%	34.4%	36.9%	-0.9%
Mistral-7b	42.1%	30.9%	41.4%	42.3%	41.0%	-1.1%
Avg. Degrad.	-	-5.1%	-0.3%	-0.7%	+0.2%

4.4. 推理准确率

我们在五个大语言模型基准上研究了 mllm-NPU 的推理精度：LAMBADA (lambada, )、HellaSwag (zellers2019hellaswag, )、WinoGrande (ai2:winogrande, )、OpenBookQA (OpenBookQA2018, ) 和 MMLU (hendryckstest2021, )。 为了进行比较，我们评估了 4 个替代方案：FP16（非量化）、K-Quant (llama-cpp, )（在 llama.cpp 中使用）、SmoothQuant (xiao2023smoothquant, ) （最先进的每张量方法）和大语言模型.Int8() (dettmers2022gpt3, ) （最先进的浮点数方法）异常值处理方法）。 mllm-NPU的精度损失可以忽略不计，并且显着优于其他量化算法，如表5所示

具体来说，mllm-NPU 的平均准确度仅比 FP16 低 1%，但其准确度比 SmoothQuant 提高了 32.9%，比 K-Quant 提高了 70.9%。 SmoothQuant 使用静态分析将离群值平滑至正常值，这一改进归功于 mllm-NPU 通过 CPU 浮点精度动态处理离群值位置。 mllm-NPU 在元素级别解决异常值，提供比使用组级别量化尺度的 K-Quant 更高的精度。 此外，mllm-NPU 实现了与大语言模型.Int8() 相当的精度（平均损失 0.1%），因为两者都以浮点精度处理异常值。 但mllm-NPU更好地利用了NPU特有的计算特性，保持了高精度和NPU效率。

4.5. 内存消耗

我们将 mllm-NPU 与 INT8 权重基线进行比较，因为移动 NPU 仅支持 INT8 权重计算。 使用 512-token 提示的 Redmi K60 Pro 上的内存消耗结果如图16所示。 mllm-NPU 比 llama.cpp 和 TFLite 多消耗 1.32 $\times$ 内存。 开销是由于 MLLM 和 QNN 框架造成的，它们为每个运算符分配独立的激活缓冲区以提高速度。 mllm-NPU 引入的微小额外内存开销是其 $\mathrm{\S }$3.3 影子异常值执行 技术（黑色），它将微小的浮点权重加载到内存中，仅占总内存的0.6%–1%。

图 16。 不同基线的内存消耗（提示长度=512）。

图 17。 mllm-NPU 的消融研究（提示长度=512）。

4.6. 消融研究。

我们利用Qwen1.5-1.8B、Gemma-2B、LlaMA2-7B模型对mllm-NPU各项技术带来的收益进行了全面的细分分析，如图17。 最左边的条代表使用 llama.cpp 在 CPU 上的预填充速度。 第二个条显示了移动 NPU 上的简单实现，然后是我们三种技术的结合，最右边的条代表 mllm-NPU。 这三种技术分别用chunk ($\mathrm{\S }$3.2)、outlier ($\mathrm{\S }$3.3 和 OOE ($\mathrm{\S }$3.4。 我们观察到 神经网络处理单元 的三种技术对整体改进做出了重大贡献。

首先，由于大语言模型与移动 NPU 之间存在巨大差距，直接将大语言模型预填充工作负载卸载到移动 NPU 会导致 2.55–2.68$\times$ 的延迟，具体参见 $\mathrm{\S }$2.3。 此外，块共享图通过减少图构建和优化延迟，将预填充速度提高了 1.46–5.09$\times$。 Gemma-2B 模型实现了最高的加速比，因为它需要更多的时间来构建和优化。 此外，阴影离群值执行将预填充延迟减少了 3.91–8.68$\times$，允许每个张量 MatMul 操作以最小的 CPU/GPU 开销充分利用移动 NPU。 最后，乱序子图执行通过减少 NPU 内的执行气泡，将预填充延迟减少了 18%–44%。

5. 相关工作

设备端大语言模型优化。 大语言模型非常消耗资源，尤其是需要长上下文时(xu2024survey, ; zeng2024cap, )。 为了减少设备上大语言模型推理的大量内存消耗，人们提出了各种压缩技术，包括量化和知识蒸馏(yao2022zeroquant, ; frantar2022gptq, ; guan2021cocopie, ; niu2020patdnn, ; wang2020minilm, ; huynh2017deepmon, ; you2022speechmoe2 , ; yi2023edgemoe, ; mllm-npu,)。 为了最大限度地减少设备上的大语言模型计算，研究人员引入了词符剪枝 (wang2021spatten, ; cai2022enable, ; kim2022learned, ; rao2021dynamicvit, ; bolya2022token, )，它会剪掉不必要的词符推理过程中的标记。 推测解码是一种通过将任务卸载到较小的大语言模型来加速词符生成的方法，已在开源框架（llama-cpp，；FastTransformer，）中广泛采用，并得到广泛研究(kim2023big, ; miao2023specinfer, ; yang2023predictive, ; he2023rest, ; fu2024break, ; cai2024medusa, )。 除了推理之外，设备上的大语言模型训练（尤其是微调）也在移动研究中受到关注(cai2022fedadapter, ; xu2024fwdllm, ) 作为系统优化，mllm-NPU 是正交的并且与这些算法级优化兼容。

ML 的片上卸载。 对此进行了深入研究，通过利用 GPU 和 NPU 等异构移动处理器（kim2019mulayer, ; zeng2021energy, ; ha2021acceleating, ; Lane2016deepx, ; han2019mosaic, ; zhang2020mobipose, ; lee2019mobisr, ; georgiev2014dsp, ; xu2022曼特宁,; xue2024powerinfer，；niu2024smartmem，；niu2024sod，）。 MobiSR (lee2019mobisr, ) 利用移动 NPU 来加速超分辨率计算。 然而，这些方法并没有解决LLM特定的功能，并且不适合设备上的大语言模型场景。 最相关的工作是PowerInfer-V2 (xue2024powerinfer, )，它也利用移动NPU进行预填充，但主要侧重于设备内存不足的大语言模型推理。 mllm-NPU 受到这些努力的启发，是第一个具有高效、端到端设备上 NPU 卸载的大语言模型推理框架。

移动NPU执行优化。 随着移动 NPU 在智能手机中的重要性日益增加，人们在优化其执行效率方面做出了巨大努力(root2023fast, ; thomas2024automatic, ; niu2022gcd, ; vocke2017extending, ; ragan2013halide, ; franchetti2008generating, )。 Pitchfork (root2023fast, ) 定义了可移植的定点中间表示以优化定点执行效率。 Isaria (thomas2024automatic, ) 提出了一个框架，用于自动生成 DSP 架构的矢量化编译器，为移动 NPU 创建高效的运算符代码。 作为一个系统框架，mllm-NPU是正交的，可以利用它们生成更高效的算子库作为执行后端，进一步提升性能。

6. 结论

本文提出了mllm-NPU，这是第一个利用设备上NPU卸载来减少预填充延迟和能耗的大语言模型推理系统。 mllm-NPU采用了新技术：块共享图、影子离群值执行和乱序子图执行，以提高 NPU 卸载效率。 大量实验已证明 mllm-NPU 具有卓越的性能优势，例如高达 43.6$\times$ 的加速和 59.5$\times$ 的节能。