Android NNAPI：硬件加速抽象层

可视化演示

展示NNAPI作为硬件抽象层的架构原理：应用层到硬件的分层调用、算子编译加速流程、INT8量化精度管理、跨芯片设备性能调优，交互切换四种模式深入理解端侧加速。

NNAPI初识

酒店的客人，大多不关心后厨有几位厨师、用的是燃气还是电磁炉。他们只认一个入口——前台。Android 诞生之初，AI 开发者面对的却是另一番景象：同样一个“识别猫”的模型，在高通芯片上要写一种代码，在联发科芯片上要换一种写法，在华为 NPU 上又要重新适配。这就是硬件碎片化——每家芯片都有自己的“方言”，开发者被迫成为“八国翻译”。

NNAPI 正是为了终结这种混乱而生的。它从 Android 8.1（API 27）开始随系统提供，位于应用与芯片驱动之间，扮演“总前台”的角色。开发者只需通过 NDK 提供的 ANeuralNetworks 系列 C 接口描述模型、提交任务，至于底层是 CPU、GPU 还是 NPU 在执行，完全不用关心。像 TensorFlow Lite、PyTorch Mobile 这样的推理框架，也通过 delegate（委托）机制把算子转交给 NNAPI，进一步降低了接入门槛。

一次完整的 NNAPI 推理，前台内部要走四个动作：构建模型（把算子图登记成菜单）、编译（把菜单交给合适的部门形成执行方案）、执行（各部门按方案出菜）、等待结果（收拾台面）。这四步分别对应创建 Model、Compilation、Execution 三个核心对象的过程。理解了这条主链路，后面谈抽象层、驱动、调优就都有了坐标系。

在前台出现之前，客人得自己跑到后厨、电工房、洗衣房分别打招呼；前台出现之后，一切只需一个入口。NNAPI 存在的意义，就是把“找谁干活”这件事从开发者手里收走，变成系统内部的日常。

抽象层原理

前台要对各部门派活，前提是有一套统一的“内部工单”——不管你是西餐部还是中餐部，工单上“桌号、菜品、忌口”三栏必须填齐。这个工单格式，就是硬件抽象层（HAL，Hardware Abstraction Layer）的精神。

NNAPI 下层与厂商驱动之间，隔着一层 HAL 接口。它规定了驱动必须实现的最小功能集：设备发现、模型编译、执行、能力上报。任何硬件，只要把这套接口实现完整，就能被 NNAPI 调度。HAL 的好处是双向的——对系统，它不用知道某芯片内部如何取指令；对厂商，它只需按约定实现接口，不必为每个 App 定制，更不必泄露芯片机密。

技术细节上有三个关键点。设备发现：系统服务启动时枚举所有注册的 IDevice（HIDL/AIDL 版本的驱动接口），应用可通过 ANeuralNetworks_getDeviceCount 拿到设备列表和名称，就像前台先盘点今天哪些部门在岗。能力声明：每个设备上报自己支持的算子集合和性能参数，NNAPI 据此制定编译策略。共享内存：输入输出通过 AHardwareBuffer 等内存域在 App 与驱动之间零拷贝传递——就像工单直接钉在厨房案板上，不必再抄一遍。

前台最重要的资产不是菜，而是那张所有部门都认的工单格式。抽象层真正的价值，正在于把“硬件差异”压缩进一张小小的能力名单里，让上层世界保持简单。

驱动集成

部门主管们各有性格：西餐主厨脾气大但手艺精，工程队只接大活儿。前台不强求他们改脾气，只要求他们学会看工单。厂商驱动就是这么一位“翻译官”，把 NNAPI 的标准请求翻译成自家芯片的指令。

在 Android 系统中，高通负责骁龙芯片的 Hexagon DSP/NPU 驱动，联发科负责天玑的 APU 驱动，ARM 提供 Mali GPU 驱动，Google 自己还维护了一份 CPU 参考实现。每份驱动都实现了 android.hardware.neuralnetworks 接口（早期用 HIDL，新版本迁移到 AIDL），并且运行在独立的 vendor 进程中——即便驱动崩溃，也不会拖垮整个系统，这是进程隔离带来的安全边界。

驱动需要实现的核心方法不多：prepareModel 对应“把菜单预演一遍，形成内部执行计划”；execute 对应“正式出菜”；异步回调则对应“边做边汇报进度”。驱动还会上报性能等级（performanceInfo），NNAPI 用这些数字计算哪些算子交给谁最划算。驱动质量直接影响真实性能——同一个算子，优化到位的驱动可能比粗糙实现快一个数量级，这也是同一颗芯片在不同手机上跑分差异巨大的原因之一。

前台不必懂每个部门内部的火候与刀工，它只需确认：这位主管看得懂工单。这就是厂商驱动的全部修养——站在系统与芯片之间，把两边的话都说得明明白白。

算子加速

一场三百人的宴会只靠一个部门做不完。前台会把菜单拆开：凉菜给冷菜间、热菜给热灶、甜点给烘焙房。NNAPI 干的正是拆菜单的活——模型切分（partitioning）。

神经网络模型本质是一张算子图（conv、relu、fc、softmax……）。NNAPI 编译器会检查每个算子是否在某硬件的能力集合里，把“同一硬件能连续吃下的算子”打包成一个子图（partition），分配给对应驱动执行。切分的结果往往不是单硬件独占，而是 CPU、GPU、NPU 各领一段，像流水线一样接力完成推理。

切分时有三个原则。一是尽量把相邻算子分给同一硬件，减少交接成本——换部门就要递盘子，递一次就有一次开销。二是每个算子在目标硬件上必须真实可用，否则会回退到 CPU 参考实现，速度反而更慢。三是融合优化：像 Conv+ReLU 这类连续小算子，很多驱动支持融合成单个算子，一次内存读取、一次计算，省掉中间结果的写回与读取。融合做得好的模型，往往比盲目“堆更多硬件”更有效。

聪明的前台从不让一位大厨从头到尾做整桌菜，而是让最拿手的人各领一盘。算子加速的本质，就是“合适的人干合适的活”。

量化支持

“七分熟和牛、黑椒汁、配芦笋”——报菜名给后厨既费时又容易出错。前台干脆把常用菜品编号成套餐：7 号套餐，一秒钟说清楚。量化，就是给神经网络模型编“套餐号”。

训练好的模型权重通常是 FP32（32 位浮点），而在手机芯片上，用 8 位整数（INT8）表示不仅能省 75% 的带宽和存储，还能在支持 INT8 的 NPU/DSP 上获得数倍加速。NNAPI 从早期版本就支持 8 位量化张量的传递，驱动负责把整数还原成近似浮点值参与计算。FP16 则是另一种折中：精度损失极小、模型体积减半，适合 GPU 这类原生支持半精度的硬件。

量化核心是缩放因子 s 与零点 z：把浮点范围线性映射到 0~255 的整数区间。NNAPI 支持 per-tensor（整个张量共用一个缩放参数）和 per-channel（每个输出通道各用一组参数，精度更好）两种方式。开发者通常先用训练后量化（PTQ）快速压测，模型偏差偏大时再用量化感知训练（QAT）恢复精度——前者像直接给老菜谱编号，后者像让厨师按编号重新试菜。

菜单编号这件事看似不起眼，但正是它，让招牌菜从“主厨限定”变成了“流水线量产”。量化让大模型从云端落地到手机，靠的就是这组简单的整数映射。

性能调优

老练的酒店在大堂设了“预开台”：客人落座前，餐具、茶水、冷盘全部就位；重复来的熟客，口味偏好直接存档。性能调优，就是把这套旺季管理经验搬进推理链路。

第一次调用 NNAPI 执行某个模型时，驱动要做编译，往往很慢；后续执行会快很多。所以线上推理前要做“预热”（warmup）——先用一次推理把驱动唤醒、缓存建好，计时只统计稳定后的执行。此外，模型权重和输入输出尽量都放进 NNAPI 的共享内存对象，避免每次执行在 Java 层和 Native 层之间反复拷贝，这好比让餐具直接留在备餐间，不用每次从仓库搬。

还有三个常用手段。一是编译缓存（Compilation caching）：把 prepareModel 生成的编译产物序列化落盘，下次启动直接加载，省掉几十到几百毫秒的编译时间，相当于把熟客口味偏好存档。二是异步执行：主线程不阻塞在等待上，CPU 在驱动计算的同时继续调度其他工作。三是批量输入：一次喂多条输入，摊薄固定开销。调优时用 systrace 抓调度时间线，黄色等待块往往比红色计算块更值得优化——因为等待意味着某个硬件在空转。

旺季里决定口碑的往往不是厨师颠勺的速度，而是前台把等待时间藏起来的本事。性能调优到极致，用户感知到的不是“某次很快”，而是“每次都很快”。

大模型落地

今天最风光的宴会，是端侧大模型——几亿到几十亿参数的 LLM 要在手机上跑起来。这好比一场千人婚宴，任何单一部门都扛不下来，必须全店总动员：冷菜、热灶、烘焙、酒水、传菜，所有部门并行接单。

端侧大模型流行 4bit 量化，把权重压到极低位数。内存公式 M = n×b/8 给出了底线：一个 7B 模型，4bit 量化后约 3.5GB，手机勉强装得下。但推理时还有 KV Cache、中间激活值，内存压力远超权重本身，所以端侧适配不止是量化，还要做算子精简、层剪枝和内存换入换出。

跨芯片协同是 NNAPI 大显身手的舞台：Transformer 解码时，QKV 投影这类 GEMM 算子是计算大头，适合 NPU/GPU；LayerNorm、Softmax 这类小算子调度成本高，CPU 反而游刃有余。NNAPI 根据能力表自动切分，让三种芯片流水线并行。新兴 NPU 开始原生支持 GQA、RoPE 等 LLM 算子，进一步把更多子图从 CPU 手里抢过来。对开发者来说，写好模型格式转换与量化管线，剩下交给 NNAPI 这个“总调度”，就能实现一套代码跨芯片统一加速。

千人婚宴之所以能成，前台未必认识每位宾客，但它一定知道：哪个部门现在闲着，哪道菜需要排多久。这就是抽象层在端侧大模型时代不可替代的理由。

AI 应用场景

Python 演示

"""模拟 NNAPI 抽象层：算子派发 + 量化加速效果"""from collections import defaultdict  class Hardware:    """一块真实存在的计算硬件，如 CPU / GPU / NPU"""     def __init__(self, name, speed, support):        self.name = name              # 硬件名        self.speed = speed            # 处理速度：算子数/毫秒        self.support = set(support)   # 支持的算子集合  class NNAPI:    """仿照 Android NNAPI 的调度中心"""     def __init__(self, devices):        self.devices = devices  # 设备列表，按优先级从高到低排列     def dispatch(self, graph):        """将算子图派发到各硬件，返回总耗时（毫秒）"""        plans = defaultdict(int)        for op in graph:            for dev in self.devices:                if op in dev.support:                    plans[dev.name] += 1                    break        total = 0.0        for dev in self.devices:            count = plans[dev.name]            cost = count / dev.speed            if count:                print(f"  {dev.name}: {count} 个算子 -> {cost:.2f} ms")            total += cost        return total     def quantize(self, graph, bits):        """模拟量化：算子数不变，计算速度按位宽比例提升"""        for dev in self.devices:            dev.speed *= 32 / bits        return self.dispatch(graph)  def main():    cpu = Hardware("CPU", 100, {"Conv", "ReLU", "FC", "Softmax"})    gpu = Hardware("GPU", 600, {"Conv", "ReLU", "FC"})    npu = Hardware("NPU", 3000, {"Conv", "ReLU"})    api = NNAPI([npu, gpu, cpu])     graph = ["Conv"] * 30 + ["ReLU"] * 20 + ["FC"] * 10 + ["Softmax"] * 2    print("FP32 推理:")    t1 = api.dispatch(graph)    print("INT8 量化后推理:")    t2 = api.quantize(graph, 8)    print(f"量化加速比: {t1 / t2:.1f}x")  if __name__ == "__main__":    main()

1. plans = defaultdict(int)用计数器记录各硬件分到的算子数，默认 0 免去判空。
2. for dev in self.devices:按优先级从高到低依次询问，找到第一个支持该算子的硬件。
3. if op in dev.support:检查算子是否在硬件的“能力名单”里，对应 NNAPI 的能力声明。
4. cost = count / dev.speed单段耗时等于算子数除以处理速度，对应切分耗时公式。
5. dev.speed *= 32 / bits量化把位宽从 32 降到 bits，硬件速度按比例提升，体现量化的收益。

常见误区

面试题