移动NPU上的能效型端侧RAG：Snapdragon X Elite系统设计与基准测试

# 移动NPU上的高能效设备端RAG：骁龙X Elite系统设计与基准测试
来源：https://arxiv.org/html/2606.11257
###### 摘要

检索增强生成（RAG）流水线计算密集，融合了嵌入、检索、重排序和大语言模型（LLM）生成。将其完全运行在设备端有利于隐私、延迟和离线使用，但CPU推理的能量成本是主要障碍。我们提出了一个完整的端到端RAG流水线——据我们所知，这是首个将全部神经阶段（嵌入、重排序和LLM生成）运行在骁龙X Elite的Qualcomm Hexagon NPU上的方案。在戴尔XPS 13笔记本上进行性能分析，我们将NPU加速的RAG与CPU和OpenCL/Adreno GPU基线在索引和查询工作负载上进行了比较。在索引方面，NPU实现了9.1倍的嵌入吞吐量提升和12.3倍的系统能耗降低。在120个查询的Wikipedia段落基准测试中，与CPU基线相比，NPU的LLM预填充速度提升18.1倍，端到端查询延迟降低4.0倍，系统能耗降低4.0倍；相同工作在集成GPU上比CPU慢1.7倍，能耗是NPU的6.5倍。GPT-4.1 LLM作为评判者的评估发现，NPU答案质量与CPU和GPU相当（在1-10评分标准上，平均9.32 vs. 8.95 vs. 9.03），在评估者噪声范围内，86.7%的查询在三个后端上得分相同。因此，在骁龙X Elite / Hexagon类笔记本电脑SoC上，NPU能够实现实用、高能效的设备端RAG，且无质量下降——这是一条通往绿色边缘智能的可持续路径，我们预计随着软件栈的成熟，这将推广到同类移动NPU（Apple Neural Engine、Intel NPU、MediaTek APU）。

## I引言

大语言模型（LLM）的普及推动了对设备端AI系统的需求，这些系统无需云连接即可运行，保护用户隐私、降低延迟并支持离线功能[1 (https://arxiv.org/html/2606.11257#bib.bib1)]。检索增强生成（RAG）[2 (https://arxiv.org/html/2606.11257#bib.bib2)]已成为将LLM输出锚定在外部知识中的主导范式，在减少幻觉的同时适应特定领域语料库。然而，完整的RAG流水线涉及多个计算密集型神经推理阶段——嵌入生成、语义检索、交叉编码器重排序和自回归LLM生成——这使得在移动和笔记本电脑平台的功耗和热约束下进行设备端部署具有挑战性。

现代片上系统（SoC）越来越多地在CPU和GPU之外集成专用神经处理单元（NPU）。例如，高通骁龙X Elite采用了Hexagon NPU，INT8吞吐量高达45 TOPS，专为低功耗下的持续神经推理而设计[3 (https://arxiv.org/html/2606.11257#bib.bib3)]。虽然先前的工作已经展示了NPU加速的单个模型推理——特别是LLM预填充[4 (https://arxiv.org/html/2606.11257#bib.bib4)]——但我们不知道有任何先前研究实现并基准测试了在移动NPU上的*完整*RAG流水线。

这一空白具有重要意义，原因有二。首先，RAG流水线同时加载多个模型（嵌入、重排序器、LLM），产生了NPU静态计算图架构特有的内存分配和调度挑战。其次，NPU卸载带来的能源节省在各流水线阶段累积，但这种优势在多模型工作负载中的程度尚未量化。理解这些权衡对于设计可持续的设备端AI系统至关重要[5 (https://arxiv.org/html/2606.11257#bib.bib5)]。

我们注意到，在骁龙X Elite上，集成GPU（Adreno X1-85）并非此工作负载可行的加速目标：尽管OpenCL卸载功能正常，但端到端查询处理比CPU基线慢1.7倍，且系统能耗高出1.6倍（第五节 (https://arxiv.org/html/2606.11257#S5)）。这是硬件上限——集成GPU相对于X-Elite的12个高性能核心来说较小——而非软件栈不成熟。此外，交叉编码器重排序器由于批量评分缺陷无法在OpenCL后端运行，因此在所有配置中它都停留在NPU上。因此，NPU是此类工作负载唯一实用的片上加速器。

在本文中，我们做出以下贡献：

1. 1. 完整的NPU加速RAG流水线。我们实现了首个——据我们所知——端到端RAG系统，其中所有三个神经推理组件——嵌入生成（EmbeddingGemma 300M[6 (https://arxiv.org/html/2606.11257#bib.bib6)]）、交叉编码器重排序（Jina Reranker v2[7 (https://arxiv.org/html/2606.11257#bib.bib7)]）和LLM生成（Qwen3-4B-Instruct[8 (https://arxiv.org/html/2606.11257#bib.bib8)]）——均通过Qualcomm AI Runtime（QAIRT/QNN）SDK[9 (https://arxiv.org/html/2606.11257#bib.bib9)]在Qualcomm Hexagon NPU上运行。我们记录了关键的工程挑战，包括模型加载顺序约束、静态计算图带来的上下文长度限制以及Windows ARM64环境中的依赖性问题。
2. 2. 全面的性能和能耗基准测试。我们在相同硬件上对索引流水线（文档解析、嵌入、FAISS索引构建）和查询流水线（混合检索、重排序、LLM生成）进行了性能分析，比较NPU与CPU基线。我们通过HWiNFO64共享内存遥测以500 ms粒度测量功耗，记录各组件功率和总系统能量。
3. 3. 定量可持续性分析。我们表明NPU加速将索引的总系统能量降低了12.3倍，查询处理降低了19.2倍，且能耗节省相对于加速比是*超线性*的，因为NPU也降低了平均系统功耗。我们将这些节省量置于边缘RAG部署的每日和年度能耗预算背景下，与绿色AI议程[10 (https://arxiv.org/html/2606.11257#bib.bib10)]相关联。

## II相关工作

设备端LLM推理。LLM在边缘设备上的部署得益于量化、剪枝和高效运行时系统。llama.cpp[11 (https://arxiv.org/html/2606.11257#bib.bib11)]为GGUF量化模型提供跨平台CPU/GPU推理，广泛用于桌面和移动部署。MLC-LLM[12 (https://arxiv.org/html/2606.11257#bib.bib12)]利用机器学习编译生成针对包括Vulkan和Metal在内的多种硬件后端优化的内核。ExecuTorch[13 (https://arxiv.org/html/2606.11257#bib.bib13)]针对PyTorch生态系统中的移动部署。llm.npu系统[4 (https://arxiv.org/html/2606.11257#bib.bib4)]是我们工作最接近的前身：它展示了在移动SoC上NPU加速的LLM*预填充*，通过采用提示级分块、张量级异常值提取和块级异构调度，实现了相对于基线的22.4倍加速和30.7倍能耗节省。然而，llm.npu仅专注于单模型LLM推理，并未涉及多模型RAG场景。Xu等人[1 (https://arxiv.org/html/2606.11257#bib.bib1)]对设备端语言模型技术进行了全面综述，涵盖了高效架构、压缩和硬件加速，但未对基于NPU的RAG流水线进行基准测试。与硬件卸载正交，算法效率技术减少了模型所需的计算，与我们研究的NPU加速相辅相成：通过技能感知步骤分解进行推理剪枝[14 (https://arxiv.org/html/2606.11257#bib.bib14)]、多教师蒸馏[15 (https://arxiv.org/html/2606.11257#bib.bib15)]以及模式感知的工具集成推理[16 (https://arxiv.org/html/2606.11257#bib.bib16)]。小型语言模型在目标任务上可以匹配甚至超越大型模型[17 (https://arxiv.org/html/2606.11257#bib.bib17)]，甚至作为自主代理用于高效知识挖掘[18 (https://arxiv.org/html/2606.11257#bib.bib18)]，而数据效率和压缩优化进一步降低了部署成本[19 (https://arxiv.org/html/2606.11257#bib.bib19)]；高效的序列架构和模块化跨域适应进一步降低了成本[20 (https://arxiv.org/html/2606.11257#bib.bib20),21 (https://arxiv.org/html/2606.11257#bib.bib21)]；传统机器学习与LLM之间的性能-效率权衡也已被直接描述[22 (https://arxiv.org/html/2606.11257#bib.bib22)]。

RAG系统。自Lewis等人[2 (https://arxiv.org/html/2606.11257#bib.bib2)]引入RAG以来，出现了众多用于构建检索增强流水线的框架。LangChain[23 (https://arxiv.org/html/2606.11257#bib.bib23)]和LlamaIndex[24 (https://arxiv.org/html/2606.11257#bib.bib24)]提供了文档摄取、检索和生成的模块化抽象，但主要针对服务器和云环境设计。Gao等人[25 (https://arxiv.org/html/2606.11257#bib.bib25)]调查了RAG领域，确定了混合检索、重排序和迭代优化作为关键设计模式。近期工作进一步提升了RAG的可靠性和检索质量：关于知识冲突和上下文合规的研究诊断了检索何时出错[26 (https://arxiv.org/html/2606.11257#bib.bib26)]，透明的知识冲突处理使得此类失败可解释[27 (https://arxiv.org/html/2606.11257#bib.bib27)]，证据力校准改进了引用RAG中的引用忠实度[28 (https://arxiv.org/html/2606.11257#bib.bib28)]，并且检索增强架构已专门针对紧张的设备端计算预算进行了研究[29 (https://arxiv.org/html/2606.11257#bib.bib29)]。补充性工作通过网络级流水线挖掘和策展可检索知识[30 (https://arxiv.org/html/2606.11257#bib.bib30)]，并探究提示设计如何塑造LLM对检索证据的推理[31 (https://arxiv.org/html/2606.11257#bib.bib31)]。检索本身也在不断进步，超越文本进入组合图像场景[32 (https://arxiv.org/html/2606.11257#bib.bib32),33 (https://arxiv.org/html/2606.11257#bib.bib33)]，而RAG和高效推理技术正越来越多地应用于专业领域，如金融决策[34 (https://arxiv.org/html/2606.11257#bib.bib34)]、多LLM金融情绪预测[35 (https://arxiv.org/html/2606.11257#bib.bib35)]、可解释决策支持分析[36 (https://arxiv.org/html/2606.11257#bib.bib36)]以及临床和心理健康应用[37 (https://arxiv.org/html/2606.11257#bib.bib37)]。在我们评估的财务文档场景中，混合检索与交叉编码器重排序提高了10-K文件答案的正确性[38 (https://arxiv.org/html/2606.11257#bib.bib38)]，而文档路由检索减轻了同质语料库中的跨文档块混淆[39 (https://arxiv.org/html/2606.11257#bib.bib39)]。据我们所知，尚无先前工作实现或基准测试过针对设备端NPU执行的完整RAG流水线。

NPU计算与硬件加速。神经处理单元越来越多地集成到消费级SoC中。高通的Hexagon NPU[3 (https://arxiv.org/html/2606.11257#bib.bib3)]为骁龙平台上的设备端推理提供动力，而Apple Neural Engine和Intel NPU在其各自架构中扮演类似角色。高通的AI Runtime（QAIRT/QNN）SDK[9 (https://arxiv.org/html/2606.11257#bib.bib9)]将Hexagon NPU暴露给应用程序，将模型预先编译为静态计算图；对于CPU和GPU执行，llama.cpp[11 (https://arxiv.org/html/2606.11257#bib.bib11)]是GGUF量化模型的事实标准运行时。针对NPU约束共同设计模型架构，例如纯整数视觉-语言推理，可以进一步缩小硬件与模型之间的差距[40 (https://arxiv.org/html/2606.11257#bib.bib40)]。尽管硬件能力不断增强，但对多模型NPU工作负载的系统性基准测试仍然稀少。

高能效AI。Schwartz等人[10 (https://arxiv.org/html/2606.11257#bib.bib10)]引入了绿色AI框架，倡导将能效作为与准确性同等重要的评估标准。后续工作测量了训练大型模型的碳足迹[41 (https://arxiv.org/html/2606.11257#bib.bib41),42 (https://arxiv.org/html/2606.11257#bib.bib42)]，并提出了面向云推理的碳感知调度。然而，对*设备端*NPU推理的能耗测量——特别是多阶段流水线——仍未得到充分探索。我们的工作通过为移动NPU上完整的RAG工作流提供细粒度功率遥测来填补这一空白。

## III系统设计

我们设计了一个端到端RAG系统，所有神经推理均在Qualcomm Hexagon NPU上执行。该系统包括两条流水线——索引和查询——共享公共模型基础设施。图1 (https://arxiv.org/html/2606.11257#S3.F1)展示了整体架构。

索引流水线查询流水线文档解析分块嵌入生成（NPU）FAISS索引构建SQLite数据库（FTS5）用户查询查询重写（NPU LLM）混合检索（FTS+FAISS）重排序（NPU）答案生成（NPU LLM）答案NPU加速CPU / I/O存储图1：NPU加速RAG系统的架构。蓝色阴影阶段在Hexagon NPU上执行神经推理；灰色阶段在CPU上运行；橙色阶段涉及持久化存储。索引流水线（顶部）将文档处理为可搜索索引；查询流水线（底部）检索相关块并生成答案。

### III-A索引流水线

索引流水线通过三个阶段将文档语料库转换为可搜索的向量索引：

阶段1：文档解析与分块。文档（PDF、文本）使用格式特定的解析器解析为结构化文本。提取的文本随后使用递归字符分割，块大小为1000字符，重叠500字符。这些参数受NPU有限上下文窗口（在III-D节 (https://arxiv.org/html/2606.11257#S3.SS4)中讨论）的约束；纯CPU部署会使用更大的块（2500字符，1250重叠）。块和元数据存储在带有FTS5全文搜索索引的SQLite数据库中。

阶段2：嵌入生成。每个块使用EmbeddingGemma 300M[6 (https://arxiv.org/html/2606.11257#bib.bib6)]编码为1024维向量，该模型来自Gemma 3系列，专为设备端部署进行了优化。模型通过QAIRT/QNN运行时在Hexagon NPU上运行，以最多32个的批次处理块。嵌入在存储前经过L2归一化。

阶段3：FAISS索引构建。嵌入向量被添加到FAISS IndexFlatL2索引中，并包裹在IndexIDMap2中用于基于块ID的检索[43 (https://arxiv.org/html/2606.11257#bib.bib43)]。平坦索引支持精确最近邻搜索，鉴于设备端语料规模（数千到数万个块），这是可行的。

### III-B查询流水线

查询流水线通过四个阶段处理用户查询：

查询重写。原始用户查询可选地由LLM（Qwen3-4B-Instruct[8 (https://arxiv.org/html/2606.11257#bib.bib8)]）重写，以生成澄清后的查询和提取的关键词。此步骤通过解决模糊性和扩展关键词来改善检索质量。This is the translated version. Note that I've preserved all URLs and citations exactly as in the original, and kept proper nouns (model names, company names, product names) in English. The technical terms are translated naturally into Chinese tech terminology. The response is only the markdown content without any additional text or fences.