目录
目录README.md

EdgeVecDB:面向移动设备的异构向量数据库

本项目提出并实现了EdgeVecDB——专为移动端异构硬件(CPU/GPU/NPU)协同优化的高性能向量数据库。EdgeVecDB通过统一调度多种计算后端,显著提升了RAG(检索增强生成)等智能Agent在本地化部署场景下的知识检索效率,突破了现有方案在移动设备上的性能瓶颈。系统支持高效的数据存储、查询、向量重构与持久化,适配终身学习等复杂推理需求,为移动端智能应用提供了坚实的数据基础。

1. 大模型调用方式的演进

大模型调用方式的演进

受限于移动设备的存储与算力,现有向量数据库难以支撑大规模知识的高效检索,且CPU、GPU、NPU等计算单元缺乏高效的协同调度,导致检索延迟突出,严重影响用户体验。此外,移动端RAG生态尚不完善,工具链和硬件加速库支持有限。针对这些挑战,本项目实现了面向移动设备的异构向量数据库,通过CPU、GPU、NPU协同加速LightRAG的构建与查询,显著提升边缘侧RAG应用的效率与体验。

2. 硬件平台与矩阵乘法性能

本项目所用硬件平台为红米K80 Pro,配备SnapDragon 8 Elite CPU、Adreno (TM) 830 GPU以及Hexagon DSP NPU。我们分别在CPU、GPU和NPU上测试不同规模的矩阵乘法运算,测试结果如下:

矩阵乘法性能对比

可以观察到,在CPU上进行矩阵乘法的效率远远小于GPU与NPU。如果仅仅只是利用CPU进行常规的运算,则会大大浪费现有可用的硬件计算资源。故我们希望能够通过不同的计算后端并行计算来实现计算加速。

不同计算后端同样有自己的最优性能计算区间,即超过特定范围后,计算效率会出现明显波动,甚至大幅降低。根据这个情况,我们可以针对不同的计算任务分类,把负载更小的任务部署在CPU侧,负载更重的任务,部署在更加稳定的GPU上,尽量保证所有硬件设备都能够以最大计算效率运行。

3. 现有方案对比与EdgeVecDB设计

现有的向量数据库在移动设备的场景下存在各种各样的问题,例如Faiss:

Faiss与EdgeVecDB对比

虽然Faiss实现了GPU版本的向量数据库,并有各种向量数据管理算法,比如倒排索引、基于HNSW算法的索引构建,但是其不同的计算后端互相隔离,数据库的内容不是由一个统一的结构管理;并且Faiss GPU版本高度绑定NVCC与CUDA。Faiss的设计在服务器部署的场景下,可以通过不断添加硬件设备来实现性能的提升,但是在边缘设备硬件设备固定的情况,Faiss的方式就会出现弊端,与本项目的设计理念不符。

因此我们重新设计并实现了一个面向边缘设备的向量数据库EdgeVecDB,数据由CPU统一管理维护,并把不同的计算后端抽象出对应的计算接口,统一调度计算任务,通过实时任务检测最大化利用现有硬件设备,加速LightRAG检索。

4. EdgeVecDB核心功能与接口

EdgeVecDB作为本项目自主开发的高性能向量数据库,向上层模块提供数据添加、查询、向量重构、数据持久化及恢复等多项核心功能。

  • query_range:支持在特定后端对特定数据进行查询
  • search:用户层查询,对应用层隐藏硬件设备信息
  • reconstruct:通过索引恢复向量数据
  • save:数据磁盘持久化,写入数据库头信息与向量数据
  • load:从磁盘读取数据,恢复数据库

当前数据库采用FlatIndex结构进行数据组织和管理,后续将逐步支持HNSW、倒排文件等更多高效索引方式,进一步优化大规模向量数据的存储和检索性能。

4.1 计算后端加速方法

  • CPU-BLASsrc/backend/cpu-blas):使用BLAS库加速向量矩阵乘法。针对大矩阵采用分块策略,避免效率下降,并通过OpenMP加速数据处理。
  • GPU-Komputesrc/backend/gpu-kompute):使用Vulkan API调用GPU,配合自定义矩阵乘法shader,支持分块处理。
  • NPU-Hexagonsrc/backend/npu-hexagon):通过高通Hexagon SDK调用NPU,FastRPC调用NPU计算接口,后续支持DMA直通加速。

所有接口通过/src/python模块向上层提供标准化Python接口,便于LightRAG和其他应用系统集成调用。

5. Android集成与架构

由于安卓系统原生并不直接支持Python环境,项目采用Android NDK与ChaquoPy工具链,将LightRAG整体项目及其全部依赖打包为Python whl安装包,并以插件形式集成至安卓应用项目中。

项目整体架构

在移植过程中,我们将LightRAG原有的向量数据库(如NanoVecDBStorage、FaissVecDBStorage)替换为自主设计实现的EdgeVecDB模块,充分发挥多种计算后端的并行加速能力,极大提升了系统在移动端的性能表现和可用性。

本项目基于ChaquoPy框架,将Python代码以插件形式集成至Android应用,以解决Android原生不支持Python的问题。针对LightRAG及其依赖库(如numpy、libomp、tiktoken、pandas等),我们进行了适配优化,统一打包为whl格式,便于高效部署。同时,对LightRAG核心模块及其配套的EdgeVecDB向量数据库完成了定制编译与打包,统一置于/app/src/main/python/目录,实现了复杂Python生态在Android端的完整移植与高效运行,为移动端RAG应用的拓展奠定了基础。

完善Android RAG生态

6. 关键优化细节

6.1 CPU矩阵乘法优化

  • 核心实现依赖高性能BLAS库中的sgemm_函数
  • 引入分块策略(A按4096行,B按1024行分块),提升缓存利用率,避免内存带宽瓶颈

6.2 GPU矩阵乘法优化

  • 编写并优化专用Shader,采用Tiled Matrix Multiplication策略
  • 分块加载到共享内存,+1 padding避免冲突,barrier同步,#pragma unroll提升循环效率

GPU矩阵乘法优化

方案/矩阵规模 256×256 512×512 1024×1024 2048×2048
CPU朴素多线程 21.33 ms 142.00 ms 1051.48 ms 32840.31 ms
CPU OpenBLAS 3.14 ms 8.23 ms 18.01 ms 92.28 ms
GPU Vulkan 6.14 ms 69.64 ms 1575.54 ms 2003.79 ms
GPU Vulkan优化 0.79 ms 1.12 ms 2.75 ms 14.81 ms

6.3 NPU矩阵乘法优化

  • 采用高通Hexagon DSP(HVX指令集)
  • 关键指令:Q6_V_vzero、Q6_dcfetch_A、Q6_Vqf32_vmpy_VsfVsf、Q6_Vqf32_vadd_Vqf32Vqf32、Q6_V_vror_VR、Q6_Vsf_equals_Vqf32
Hexagon HVX Instructions Operations
Q6_V_vzero 向量置零
Q6_dcfetch_A 数据缓存预取
Q6_Vqf32_vmpy_VsfVsf 向量浮点乘法
Q6_Vqf32_vadd_Vqf32Vqf32 向量浮点加法
Q6_V_vror_VR 向量右旋
Q6_Vsf_equals_Vqf32 浮点类型转换

Hexagon NPU 内存架构图

  • 内层循环向量化,单指令处理32个浮点数
  • 利用QuRT SMT特性多线程并行分配任务
  • 输入矩阵预转置+Q6_dcfetch_A预取,配合TCM加速数据传输

7. 智能调度与资源利用

我们对不同计算后端的数据处理能力进行了系统性评估,发现每种后端在特定数据规模区间内均具有最优性能表现。基于此,EdgeVecDB根据各后端的最优性能区间进行智能分配,将不同规模的数据块划分并分派给最适合的计算后端,有效避免单一设备因过载成为瓶颈,同时提升整体硬件资源利用率。

智能调度示意图

8. 性能测试与对比

为充分验证本项目所提出异构融合的向量数据库的实际效果,本章设计并执行了一系列性能测试。测试核心旨在量化EdgeVecDB异构向量数据库相较于传统方案的性能优势,并通过剖析系统运行时的性能数据,验证任务调度策略的合理性。

  • 硬件平台:红米 K80 Pro 智能手机(高通骁龙8 Elite,Adreno 830 GPU,Hexagon DSP NPU)
  • 软件环境:Android 操作系统,Chaquopy工具链部署
  • 测试数据:十万级别向量数据库,查询向量集nq从1000到7000,模拟不同负载下的RAG检索场景

性能对比实验结果

通过对比实验,EdgeVecDB在移动端异构融合调度下查询效率显著提升:

  • 相较于传统纯CPU后端,整体性能提高约4倍
  • 相较于LightRAG默认后端,性能提升近50倍(图中未展示)

“约50倍”性能提升,特指与原始LightRAG检索后端对比(主要基于Python实现,未经过底层优化)。核心计算模块迁移至高效C++实现(EdgeVecDB),显著减少了解释器开销。再借助GPU与NPU协同调度,进一步实现4倍性能提升。

9. 运行时调度与火焰图分析

为评估异构后端在运行时的计算资源分配效率,我们使用SimplePerf进行性能剖析并生成火焰图。

火焰图分析

结果显示,未出现大面积“平顶”区域(通常代表性能瓶颈),而是多个尖锐峰值,反映出计算负载被充分拆解,分布在各异构计算单元与多线程中,无明显阻塞。

关于
514.4 MB
邀请码
    Gitlink(确实开源)
  • 加入我们
  • 官网邮箱:gitlink@ccf.org.cn
  • QQ群
  • QQ群
  • 公众号
  • 公众号

©Copyright 2023 CCF 开源发展委员会
Powered by Trustie& IntelliDE 京ICP备13000930号