1. NNAPI到底值不值得学？先搞清它在Android ML体系里的位置
做端侧AI的人，迟早会撞上NNAPI这个名字。它全称叫Neural Networks API，是Android系统里负责把神经网络推理任务调度到异构计算单元的那一层。Google在Android 8.1（API 27）把它放进了系统，初衷特别朴素：设备上的CPU、GPU、NPU、DSP越来越分化，每个芯片厂商都有自己的加速栈，如果每个App都各写一套适配代码，开发者和硬件厂商都受不了。NNAPI想当那个“中间人”，让上层框架只需要描述“我要跑这个计算图”，底下的硬件驱动自动接活。
很多人第一次接触NNAPI是在TensorFlow Lite的加速选项里看到的“使用NNAPI代理”。勾上之后推理确实变快了，但底层发生了什么基本是个黑盒。有人说NNAPI就是个给框架用的东西，跟普通开发者没关系；也有人觉得它可以直接替代框架，自己在C++层手搓推理。这两种说法都不太准确。
先端正心态：NNAPI不是一个推理引擎，它不实现算子本身，它只负责“调度”。它知道哪个设备支持哪个算子、哪块硬件更快、怎么做内存拷贝最省，但真正算卷积、算矩阵乘的是硬件驱动（HAL层）里的实现。你可以把它理解为机场的航班调度中心，它不亲自开飞机，但所有起飞降落、跑道分配、延误调配都由它统一安排。
那它到底值不值得花时间学？我的看法是：如果你只做业务层调用，框架的委托API已经把你包好了，NNAPI的知识属于“知道了更好，不知道也能跑”。但一旦你开始优化延迟、降低功耗、压内存，或者要在奇怪的国产SoC上排查“为什么推理变慢了”，绕开NNAPI基本不可能。因为所有端侧加速的根，最后都要回归到这套调度机制上。
1.1 它和TensorFlow Lite、PyTorch到底是什么关系
这个问题我面试过很多人，能一次讲清的不多。简单说：TensorFlow Lite、PyTorch Lite是一类东西，它们负责把训练好的模型转换成端侧可以跑的格式，同时提供图优化、算子融合、量化这些能力。NNAPI是Android系统的组件，负责在运行时把计算图映射到硬件设备上。
框架和NNAPI之间的接口，就是委托（Delegate）。你用TensorFlow Lite的NNAPI Delegate时，TFLite会做一层它的图优化，然后把支持NNAPI的算子打包成NNAPI模型提交下去，不支持的算子仍然留在TFLite自己的CPU内核里执行。所以最终的执行链路是混合的：一部分算子走NNAPI加速，一部分算子走框架的CPU回退。
这种“委托代理”的结构决定了：NNAPI的性能不只是它自己的事，还取决于框架怎么切分计算图、怎么准备张量数据、怎么处理输入输出的内存。你在TFLite那边勾一个加速开关，背后其实是一连串的算子分发策略在起作用。
如果拿房产中介打比方，TFLite是房东，负责把房子（模型）收拾好、挂出去；芯片驱动是租客的搬家团队，负责实际进场干活；NNAPI就是那个中介平台，把房源信息分发给合适的租客，还要盯着一张订单里不同租客怎么交接。
1.2 直接调NNAPI和走框架委托，两条路线各适合谁
直接调NNAPI原生接口意味着你要自己写C/C++代码，自己管理模型的内存布局，自己构建执行计划。Android提供了NDK里的C API，也可以写JNI层在Java/Kotlin里调用。这条路线的代价很高，写起来远不如TFLite一行代码加个option来得快。
但直接调的好处也很实在：你可以精确控制每一笔内存往哪个设备上放，可以让某个计算图绑定到指定的NPU而不是让调度器猜，可以绕开框架自带的一层拷贝开销。对于真正要抠到“每一帧推理省下2毫秒”的项目，这个控制力是值得的。
我个人的经验是分三种场景看：如果你只是想在App里塞一个图像分类、文本Embedding或者轻量检测，老老实实走TFLite的NNAPI委托，省心，效果也够；如果你的模型里有自定义算子、图结构很特殊，或者量化方案跟TFLite默认路线不太一样，那你需要直接拥抱NNAPI；如果你在做推理框架本身（比如帮公司封装一套统一推理SDK），那NNAPI原生接口几乎是必修课。
还有一种容易被忽略的情况：模型特别小、但延迟要求极端的场景，比如低于5ms的实时音频处理。框架本身的调度开销可能就占了大头，这时候直接调NNAPI把模型预编译、把执行句柄缓存好、把输入输出内存固定住，是可行的一条路。
1.3 为什么说NNAPI是“调度层”而不是“推理引擎”
这个定位理解错的话，后续做性能排查会非常痛苦。NNAPI不碰算子内部的实现细节，它构建的是“计算图对应到设备执行计划”这个映射关系。算子本身算得对不对、快不快，是芯片厂商在HAL驱动里写好的实现决定的。
所以在NNAPI下面还有一层，叫作HAL（Hardware Abstraction Layer）。系统通过HAL接口去加载各个芯片厂商的驱动，每个Driver负责上报自己支持哪些算子、支持哪些精度、有几颗计算核心、支持多大的张量尺寸。NNAPI把这些能力汇总起来，在compile阶段做型号匹配，在execution阶段做实际调度。
这也是为什么同样一个模型，在一台骁龙机器上跑得飞快，在另一台天玑机器上可能某个卷积算子“啪”地掉回CPU，速度瞬间差好几倍。不是NNAPI本身笨，而是不同厂商的Driver能力边界不一样。遇到这种问题先别骂Google，去查一下目标设备的算子支持表更实在。
2. 从模型到设备执行：NNAPI的完整工作链路
NNAPI的使用流程看起来不复杂，但每个步骤背后都有一堆容易被忽略的细节。先记住一个核心三件套：Model（模型描述）、Compilation（编译产物）、Execution（执行实例）。
用做饭来类比的话，Model是菜谱原稿，写着需要什么食材、先放什么后放什么；Compilation是把菜谱给熟练的厨师看一眼，他确认用什么锅、什么灶、火力怎么分配，然后心里形成一套操作方案；Execution是真正开火炒菜的那一下，每次炒都可以用同一套操作方案，但每次都单独记一笔菜下锅、起锅的状态。
理解了这个分层，你就知道为什么NNAPI特别强调“编译一次，执行多次”。如果每次推理都重新走一遍构建模型、编译、再执行的全流程，开销会非常难看。
2.1 三件套的构建顺序与要点
构建Model的第一步是定义张量。你要用ANeuralNetworksModel_addOperand注册输入张量、输出张量、常量张量以及中间张量。Operand的类型不只是float、int、bool这些基础类型，还包括张量类型（TENSOR_FLOAT32、TENSOR_QUANT8_ASYMM等）和标量类型（INT32、FLOAT32等）两种。
这里有个新手特别容易弄混的点：标量操作数（比如卷积的padding、stride这些参数）在NNAPI里也是Operand，也要通过addOperand加进模型里，并且在addOperation时作为输入项引用。只注册了张量但漏了标量，模型是构建不起来的。
第二步是添加操作（Operation）。你用ANeuralNetworksModel_addOperation把算子类型、输入操作数列表、输出操作数列表都填进去。算子类型是一大堆以ANEURALNETWORKS_开头的枚举，从基础的ADD、MUL、CONV_2D到稍复杂的LSTM、TRANSPOSE、RESIZE_BILINEAR都有。
第三步是设置输入输出张量的索引，然后调用ANeuralNetworksModel_finish。注意，finish之后模型就不可再改了，编译器会在这个时候做各种合法性和形状推导。如果输入的张量维度带未知值（比如动态尺寸），部分设备和驱动会直接拒绝编译。
Compilation阶段的关键是把Model和一个或多个设备绑定。通常是用ANeuralNetworksCompilation_createForDevices指定设备列表，也可以用默认的create让系统自己选。编译做完后用ANeuralNetworksCompilation_finish收尾，之后可以缓存到内存里重复使用。
Execution阶段则是实实在在喂数据：先把输入数据拷到输入张量对应的内存（或者指定内存域），然后设置输入值、执行、等待结果、读取输出。如果是异步执行，要注册回调函数，在回调里处理推理完成事件。
2.2 设备能力查询：决定走哪条加速路线的关键一步
NNAPI有个很容易被忽略的机制，就是设备能力查询。NNAPI不是把所有算子一股脑丢给同一个设备，它会在编译前判断哪些操作可以被哪些设备支持。调用ANeuralNetworksModel_getSupportedOperationsForDevices，可以拿到一个布尔数组，每个元素对应Model里的一个operation，标明目标设备是否支持。
这个步骤非常现实：你以为模型里5个算子都走NPU，结果查询下来NPU只支持前面3个卷积，后面两个算子在它的驱动里没实现，于是NNAPI会把计算图切成两段，前3个算子走NPU，后2个算子走CPU。如果切分点选得不好，中间还得多一次数据拷回拷出的过程，性能反而下降。
所以在实际项目里，我建议你在构建model之前就完成能力查询，并且根据查询结果决定要不要调整图结构。举个例子，某项目里我们做人脸关键点检测，模型尾部有几个自己拼的算子，某款芯片的Driver不支持其中两个，当时我们直接把那两个算子挪出了NNAPI计算图，改用CPU并行算，整体延迟反而比强行塞进NNAPI低。
设备能力查询还能帮你做“设备白名单”策略。比如公司内部机型画像显示70%的存量机器是某款GPU性能好、40%的机器DSP对某类算子支持差，你就可以在服务端下发模型时带上一个设备能力指纹，决定端侧是走NNAPI主加速还是走框架回退。
2.3 一个最小C++示例：从构建到推理全流程
说了这么多抽象概念，放一个尽量精简的C++示例，演示NNAPI的完整调用套路。这个例子不针对具体模型，只展示框架结构，方便你对照理解。
// 1. 创建设备列表并查询 uint32_t deviceCount = 0; ANeuralNetworks_getDeviceCount(&deviceCount); ANeuralNetworksDevice* device = nullptr; ANeuralNetworks_getDevice(0, &device); // 2. 构建模型 ANeuralNetworksModel* model = nullptr; ANeuralNetworksModel_create(&model); // 定义输入输出张量 uint32_t inputDims[] = {1, 32, 32, 3}; ANeuralNetworksOperandType inputType{ .type = ANEURALNETWORKS_TENSOR_FLOAT32, .dimensionCount = 4, .dimensions = inputDims, .scale = 0.0f, .zeroPoint = 0 }; uint32_t inputIndex = 0; ANeuralNetworksModel_addOperand(model, &inputType); // 注册常量、其他操作数、算子... // 这一步每个模型千差万别，真实项目通常从框架转换脚本自动生成 ANeuralNetworksModel_identifyInputsAndOutputs(model, &inputIndex, 1, &outputIndex, 1); ANeuralNetworksModel_finish(model); // 3. 编译 ANeuralNetworksCompilation* compilation = nullptr; ANeuralNetworksCompilation_createForDevices(model, &device, 1, &compilation); ANeuralNetworksCompilation_finish(compilation); // 4. 执行 ANeuralNetworksExecution* execution = nullptr; ANeuralNetworksExecution_create(compilation, &execution); // 准备输入数据 std::vector<float> inputData(32 * 32 * 3); // 填充 inputData ... ANeuralNetworksExecution_setInput(execution, 0, nullptr, inputData.data(), inputData.size() * sizeof(float)); std::vector<float> outputData(10); ANeuralNetworksExecution_setOutput(execution, 0, nullptr, outputData.data(), outputData.size() * sizeof(float)); // 同步执行 ANeuralNetworksExecution_compute(execution); // 5. 读取结果并清理资源 // outputData 即为推理结果 ANeuralNetworksExecution_free(execution); ANeuralNetworksCompilation_free(compilation); ANeuralNetworksModel_free(model);代码里最容易被忽略的是OperandType里scale和zeroPoint的填写。浮点模型填0和0没错，但量化模型如果填错，推理结果会完全不可用。很多框架在转换模型时把NPU需要的量化参数写进常量里，NNAPI这里只需要在张量类型上保持一致就行。
另外提醒一句，ANeuralNetworksExecution_compute是同步阻塞调用，主线程直接跑会卡UI。真实项目一定要用异步版执行，并配合回调处理结果，相关细节后面踩坑部分再展开。
3. 硬件适配的灰色地带：为什么不支持、性能为什么不达标
理论链路讲完，进入我最想聊的部分——真实设备上的适配问题。NNAPI设计的初衷是“统一调度”，但实际跑起来你会发现，各家Driver对算子的实现质量参差不齐，有的支持但实现得很烂，有的报支持但精度离谱，有的干脆不支持。这在碎片化严重的Android生态里是绕不过去的一道坎。
3.1 同一模型在不同芯片上的结果差异从哪来
NNAPI里的许多操作都允许实现方选择不同的计算策略。浮点模型在GPU上通常走OpenCL或Vulkan的浮点管线；在NPU上可能会被转成某种更高精度的内部格式再算；在DSP上往往先用动态定点（dynamic fixed point）做一层转换。每一步转换都会引入微小误差，同一个0.1的浮点误差在不同硬件上可能积累成完全不同的结果。
特别是INT8量化模型，每个芯片厂商对scale和zeroPoint的处理都不一定严格按NNAPI规范来。有些驱动为了性能，会把激活函数融合进卷积实现里，融合得好没问题，融合得粗犷就会让精度掉一截。分享一个真实案例：某模拟项目X里做ocr文字检测，同一份INT8模型在一台机器上F1能到0.83，在另一台明显更新款的机器上只剩0.71，排查了很久才发现是对方Driver对某个归一化算子的实现忽略了zeroPoint偏移，输入分布的均值直接偏了。最后是绕过NNAPI，把归一化挪到模型外部，改用CPU预计算，才彻底解决。
所以在做跨设备精度验证时，不要只看“精度曲线有没有下降”，要分开统计每个算子的输出分布差异。NNAPI的调试信息里可以拿到每个operation在设备上的实际输出，对比CPU浮点实现的输出，基本能定位到具体是哪个算子的迁移出了问题。
3.2 算子支持度查询与回退策略的实践方法
上一章提过getSupportedOperationsForDevices，现在说具体怎么用。拿到布尔数组后，最常见的处理思路是把“支持”和“不支持”的部分拆成两个子图：支持的部分进NNAPI，不支持的部分留在框架CPU执行。但中间的数据交接会产生拷贝和同步，这个代价在有些场景下比直接全部跑CPU还高。
我见过一个比较合理的策略是：先统计整个模型里算子在不同设备上的覆盖率，设一个阈值。如果覆盖率在95%以上，就让NNAPI做主导，CPU只兜底；如果覆盖率只有60%~70%，干脆别用NNAPI，因为切图的同步成本大概率超过硬件加速带来的收益。阈值怎么定？拉你手上的真机跑一遍，看切图开销占推理总耗时的百分比，一般超过5%就要警惕。
有些驱动会提供“偏好”设置，比如ANEURALNETWORKS_PREFER_FAST_SINGLE_ANSWER、PREFER_SUSTAINED_SPEED这些偏好参数。它们影响驱动选择低功耗核还是高性能核，挺值得尝试组合。但注意，偏好只是“建议”，驱动可以无视。实测中某款芯片上设了快速偏好，比设默认偏好快了不到3%，收益很有限。
3.3 Vendor Driver与HAL版本对全局的影响
NNAPI的接口版本从HAL 1.0一路走到1.1、1.2、1.3。版本越高，能表达的计算图结构越复杂，比如1.2引入了控制流（IF、WHILE），1.3强化了内存域（Memory Domain）和按序执行的能力。问题在于，老设备不可能通过OTA把HAL版本推高，芯片厂商的驱动版本跟随系统大版本走，Android大版本不更新，你的NNAPI能用到的特性就会被锁死。
因此跨版本兼容是绕不开的话题。写完代码别只在最新测试机上开心，要专门找一台老系统设备过一遍全套流程。很多“系统崩溃”“莫名回退”的线上问题，最后都是HAL版本能力差异导致的。
还有一个隐性坑：部分厂商会把NNAPI驱动和它们自己的私有AI SDK绑定在一起预装。你在系统设置里某个开关一关，驱动就失效了，下次调用NNAPI直接找不到设备或全设备返回不支持。这种问题代码层面无解，只能在文档里提示用户检查相关开关。
4. 性能调优：把NPU/DSP真正用起来的几个杠杆
功能跑通只是第一步，真正头疼的是性能。NNAPI本身的调度逻辑很多时候像一个“黑盒算法”，你只能在外面拨几个旋钮，看它怎么反映。下面这几个杠杆我基本每个项目都会碰，按优先级排一下。
4.1 优先级、超时与内存布局的取舍
NNAPI执行可以设置优先级和超时。优先级影响的是多个计算任务同时排队时谁先被调度，超时则控制一次执行最长的等待时间。这两个参数不直接影响单次推理快慢，但会影响系统的整体稳定性。如果你在做一个实时交互应用，优先级拉高可以降低排队延迟；如果是后台批量分析，优先级放低，给前台让资源，反而更合理。
超时参数要特别小心：设得太短，大型模型在多任务并发的机器上容易超时失败；设得太长，一旦某个驱动实现出bug，你的线程会像死锁一样吊在那儿。我的经验是从500ms起步，按单次推理平均耗时的5~10倍去设，同时配套一个外层看门狗，避免极端情况下卡死。
内存布局方面，最核心的是减少跨设备拷贝。NNAPI在Android 10之后支持AHardwareBuffer共享内存域，你可以让输入数据直接在GPU/CPU共享的内存块里准备，省掉一次“InputBuffer -> NNAPI可见内存”的复制。这个优化在输入是摄像头帧或者高频传感器数据时效果尤其明显，实测里经常能省掉20%左右的总耗时。
4.2 缓存编译计划，省掉每次初始化的固定开销
很多团队把NNAPI用成了“每次推理都全新构建”的模式，这个代价非常大。构建Model、finish、compile、finish这一整套流程，轻则几十毫秒，重则上百毫秒，对一次只需几毫秒的推理来说完全是灾难。
正确做法是：App启动时构建一次Model和Compilation，缓存下来；整个生命周期里，Execution可以反复创建销毁。如果Model的权重参数在运行期不会变化，连Execution的配置都可以复用。做到这个级别之后，单次推理的调度开销能压到微秒级。
还有一类更激进的优化是预置编译缓存。NNAPI允许你把编译结果保存到文件里，下次启动时直接加载，跳过重新编译。对于几百MB的大模型，这个优化能把启动时间从秒级压到几百毫秒。不过要注意，编译缓存跟设备驱动版本强相关，驱动一更新，缓存失效，要自动检测后重新生成。
4.3 多设备并行与拆分执行的现实
NNAPI可以把一个模型“分区”给多个设备执行，但实际效果很少能像想象中那样加速。原因是不同设备之间的同步开销、数据拷贝开销通常会抵消并行收益。我见过比较成功的案例是：把模型切成两个完全独立的子图（比如双分支结构，左分支和右分支各走一个设备），然后在汇合点同步。这种“结构天然并行”的切分收益才明显。
如果是串行结构，强行把前半段和后半段分到不同设备，几乎都亏。因为前半段输出要拷到后半段所在的设备内存，这中间有一次全张量拷贝，往往比后半段本身的耗时还高。判断能不能并行，先看数据结构，再看设备带宽，别只看理论算力。
5. 踩坑实录：我在真实项目里遇到的五个NNAPI问题
这个章节本来是给内部组会整理的笔记，拿出来分享希望能帮大家少走弯路。每个问题都来自真实项目，虽然细节做了脱敏，但排查思路是可复用的。
5.1 动态输入尺寸导致的编译失败
某项目里做文本检测，模型输入是变长的，宽度随图像检测结果动态变化。在TFLite里跑没问题，因为TFLite CPU内核支持动态shape。换到NNAPI委托后，部分机型直接编译失败，部分机型成功但运行期输出全是0。
原因解释起来很简单：NNAPI的OperandType在addOperand时就固定了dimensions，动态维度在转换时通常被填成-1或者某个占位符。有的驱动对占位符支持不友好，编译阶段直接报错；有的驱动编译时用了张量真实更大的内存布局，但执行时没处理好输入尺寸变更，输出索引就乱了。
解决办法是分尺寸预编译：把输入尺寸离散化成几个档位（比如宽高比固定的一组尺寸），每个档位单独构建一份Compilation缓存起来，运行期按实际输入尺寸选择最接近的档位。内存上花了更多空间，换来了稳定性和速度，值得。
5.2 INT8量化模型在GPU上反而变慢
量化模型按道理应该更快，但在某些芯片的GPU上，INT8的卷积实现是先把输入反量化成FP16，算完再量化回去。如果GPU没有原生的INT8加速单元，这个流程比直接跑FP16模型还要多两次转换开销，最终结果就是量化模型比浮点模型慢40%。
排查起来其实不难：把同一个模型分别用FP32、FP16、INT8三种精度在NNAPI上跑一遍，对比单算子耗时。问题机型上INT8版本的每个卷积算子内部会多出两个数据转换操作，用性能分析工具盯算子级别的时间分布就能看出来。结论是：不要无脑量化，要在目标设备上做精度对照实验，如果INT8收益不明显，宁可上FP16。
5.3 Driver宣称支持但实际走了CPU回退
这个是最坑的，没有之一。通过能力查询接口得到的支持列表是驱动自己上报的，但“支持”不等于“实现得好”，甚至不等于“真的会执行”。某款机器上，能力查询显示所有算子都被NPU支持，但跑起来每个算子在设备端都用了“CPU参考实现”，性能纹丝不动。
后来仔细看驱动日志，发现它把NPU执行失败的原因吞掉了，默默降级到CPU。这种降级在正常API调用里根本感知不到，你只会突然觉得“这次推理为什么慢了”。应对办法是在优化阶段对比同一份模型在“全部设备强制用CPU”和“启用NNAPI”两种条件下的耗时差，如果在某个机器上两者几乎一样，说明没有真正用上加速硬件。
5.4 线程安全与生命周期管理
NNAPI的Compilation对象并不是严格线程安全的：多个线程同时用它创建Execution时，文档说没问题，但某些驱动实现有并发bug，会出现偶发的执行崩溃。在开源代码里能查到的issue不少，报错大多指向内存访问越界。
我们当时的处理是给Compilation加了一个读写锁，读锁保护Execution创建，写锁保护Compilation释放。另外，Model对象在Execution存活期间不能提前释放，否则某些驱动会因为内部引用计数没处理好而崩。这两个坑让我明白：就算上层API写着“线程安全”，底层驱动不一定做到，关键路径上加保护成本很低，值得。
5.5 设备温度和电量状态导致的性能飘移
NNAPI调度到的DSP/NPU这类芯片，功耗和发热曲线跟CPU/GPU不一样，频繁高强度调用后温度一上来，驱动会自动降频保护。这就导致同一个模型，在冷机状态下跑10ms，连续跑五分钟之后变成18ms，而且不是渐变，是某一次掉帧后突然变慢。
排查这类问题时，不要光盯代码，要盯系统当前状态。我们踩过一次：某项目中测试人员反馈“推理越来越慢”，我们怀疑是内存泄漏，排查了一圈发现是设备放在被子里测试，温度过高触发降频。后来所有性能测试统一加了一个前置步骤：先跑两分钟热身，让设备进入稳定温度区间，再记录正式数据。这个习惯建议尽早养成，它能帮你排除掉一大类“环境型”性能波动。
6. NNAPI版本演进与端侧AI的下一步
做了这么多年端侧部署，我觉得NNAPI的路子是对的，它确实把“模型可移植性”从一个美好的愿望变成了基本盘。但它的控制力仍然有限，某些地方甚至有点粗糙，这给上层框架和开发者留下了大量优化空间。
6.1 NNAPI 1.2/1.3引入的关键能力
控制流算子是1.2版本最醒目的更新，IF和WHILE这两个操作让循环类网络可以完整映射到NNAPI，而不用像老版本那样把循环展开成一次性的大图。RNN、LSTM这类带时序结构的模型因此受益很多，不用再为了适配NNAPI而专门改模型结构。
1.3版本则把重点放在内存域优化上。设备与设备之间共享内存的机制更灵活了，像GPU和NPU之间如果本身就共用物理内存，可以通过Memory Domain直接传递张量，绕掉拷贝。这听起来简单，实际效果好得很明显，因为异构芯片的数据搬运往往是端侧推理最大的隐性成本。
不过这两个版本的能力普及要看系统更新节奏，不是所有机器都有。要保证代码兼容，写的时候就按“最低支持HAL 1.2”来做，然后用运行时API探测拿到当前设备的最高特性，再决定要不要走高级路径。
6.2 Transformer类模型与NNAPI的适配现状
这两年大模型往端侧跑，大家都关心Transformer能不能吃上NNAPI红利。坦率说，NNAPI原生的算子集合对Transformer的支持还比较有限。Self-Attention里的MatMul、Softmax、加性残差这些基础算子它都有，OpenCL或Vulkan的GPU后端基本能覆盖，但像GQA、动态KV Cache这些结构只能通过组合算子去拼，性能远比不上芯片厂商专门优化的专用实现。
所以对Transformer类模型，我目前更推荐的是直接对接芯片厂商的专用推理SDK，或者用框架里专门做Transformer加速的执行后端，NNAPI更适合当兼容底座。它是“有总比没有好”的那一层，但要榨干性能，还是得往更贴近硬件的方向走。
6.3 给团队落地NNAPI的三条建议
第一条，建立真机算子覆盖矩阵。每次发版之前，把你目标用户占比最高的十台机器跑一遍“算子支持-延迟-精度”三张表，自动生成报告。没有这个矩阵，你所有的性能优化都像在黑箱里瞎调。第二条，默认让框架帮你委托，只在有明确痛点时下沉到NNAPI原生层。别一开始就追求原生控制，成本高，且大部分项目等不到那个阶段就死了。第三条，把编译缓存和异步执行当成硬性要求，这俩不是锦上添花，是上线稳定性的底线。
回到我自己的经验，NNAPI最大的价值不在于帮你把模型跑得最快，而在于帮你建立一个“模型-硬件-调度”的系统性视角。弄懂了这一层，你再看任何端侧推理优化问题，都会自然而然地先问一个问题：这个计算任务当前到底在哪个设备上执行？是它真正擅长的工作吗？如果没有经过这样的拷问，后面所有的调优动作都可能只是在错误的层上打转。
