高通NPU端侧大模型推理框架调研：QNN、ONNX Runtime与llama.cpp适配对比

1. 为什么端侧大模型推理绕不开高通NPU

过去一年，端侧跑大模型从"能不能跑"变成了"怎么跑得又快又省电"。我接触过不少团队，模型在服务器上跑得好好的，一挪到手机上就傻眼——延迟高、发热大、掉电快。问题的核心在于，大多数人第一反应是用CPU硬扛，或者简单调个GPU，但真正能让大模型在移动端稳定输出的，其实是NPU这条路径。而在安卓阵营里，高通的Hexagon NPU是绕不开的存在，搭载骁龙8 Gen系列和8s Gen系列的设备保有量摆在那里，你不适配它，等于放弃了最大的用户盘子。

这篇内容我想聊的是高通NPU上跑大模型推理框架的技术调研和横向对比。具体来说，会涉及QNN（Qualcomm Neural Network）这套官方推理栈、Hexagon SDK的底层能力、不同框架（比如ONNX Runtime、TFLite、MNN、llama.cpp的QNN后端等）在高通NPU上的适配现状，以及实际部署时会遇到的那些"文档里不写但一定会踩"的坑。适合谁看？如果你正在做端侧AI应用、想把大模型塞进安卓设备、或者单纯想搞清楚高通NPU到底能干什么，这篇应该能帮你省下不少试错时间。

先给一个结论性的判断：目前高通NPU跑大模型，成熟度最高的路径是QNN + 量化后的模型，框架层面ONNX Runtime和llama.cpp的QNN后端相对可用，但离"开箱即用"还有距离。下面我把调研过程拆开讲。

2. Hexagon NPU的硬件底子决定了框架能做什么

2.1 Hexagon架构的几代演进与算力边界

要理解框架为什么这么设计，得先知道Hexagon NPU的硬件特性。高通的Hexagon不是一块单纯的"矩阵加速器"，它是一个异构计算单元，包含标量单元、向量单元（HVX）和张量加速器。从骁龙855时代的Hexagon 690开始，高通就在往里面加张量加速能力，到骁龙8 Gen 1的Hexagon 780、8 Gen 2的Hexagon 790，再到8 Gen 3的Hexagon 800系列，张量核心的占比越来越大。

关键点在于：Hexagon的向量单元HVX支持INT8和INT16的定点运算，张量加速器则针对INT8和部分INT4做了优化。这意味着什么？意味着你想让大模型在NPU上跑得动，量化几乎是必须的。FP16在部分场景能跑，但吞吐和功耗都不理想。我实测过同一个7B模型，FP16在NPU上基本跑不起来，INT8量化后能到可用的程度，INT4则进一步把内存占用压下来，但精度损失需要评估。

这里有个容易被忽略的细节：不同代际的Hexagon，其张量核心的指令集和吞吐是不一样的。骁龙8 Gen 2和8 Gen 3的NPU算力差距，在高负载大模型推理上体现得很明显。所以做框架选型时，不能只看"支持高通NPU"这个笼统的描述，要具体到芯片型号和Hexagon版本。

2.2 QNN在软件栈里的位置

QNN是高通官方提供的神经网络推理框架，它向下对接Hexagon NPU、Adreno GPU和CPU，向上提供统一的API。你可以把它理解成高通版的"推理引擎抽象层"。它的核心组件包括QNN Backend（后端）、QNN Context（上下文）、QNN Graph（计算图）等。

QNN的工作流程大致是：你把训练好的模型（通常是ONNX或TFLite格式）通过QNN Converter转成QNN的模型格式，然后在运行时用QNN Backend加载并执行。Converter这一步会做图优化、算子融合、量化等操作。这里的关键是，QNN Converter对算子的支持是有限的，不是所有ONNX算子都能转过去。我遇到过不少模型，卡在Converter这一步就过不去，报"unsupported operator"。

提示：在动手之前，先去高通官方文档查一下当前QNN版本支持的算子列表。这个列表每个版本都在变，而且不同Hexagon架构支持的算子也不完全一样。

2.3 为什么不能直接用CUDA那套思路

很多人从服务器端转过来，习惯性地想找"高通版的cuDNN"或者"高通版的TensorRT"。QNN确实在定位上类似TensorRT，但生态成熟度差得远。CUDA生态有十几年的积累，算子库、工具链、社区支持都很完善。QNN这边，文档相对零散，示例代码不多，遇到问题主要靠官方论坛和高通开发者支持。

另一个差异是调试手段。在服务器上你可以用nsight、nvprof各种工具看kernel执行情况。高通这边，Hexagon SDK提供了一些profiling工具，但用起来门槛高，而且很多细节不对外开放。这导致性能调优时，你往往只能靠"改参数-测延迟"这种黑盒方式。

3. 主流推理框架在高通NPU上的适配现状

3.1 ONNX Runtime的QNN Execution Provider

ONNX Runtime是目前端侧推理框架里对高通NPU支持相对最好的一个。它通过QNN Execution Provider（EP）把计算图的一部分或全部offload到Hexagon NPU上执行。用起来的方式是：在创建InferenceSession时指定QNN EP，并配置相关参数。

实际用下来，ONNX Runtime + QNN EP的优点是接入成本低，如果你已经有ONNX模型，改几行代码就能试。但问题也很明显：第一，算子覆盖不全，遇到不支持的算子会fallback到CPU，导致性能断崖式下降；第二，量化流程不够顺滑，你需要先用QNN的工具做量化，再喂给ONNX Runtime；第三，版本兼容性坑多，ONNX Runtime版本、QNN SDK版本、设备固件版本三者之间的匹配关系需要仔细核对。

我踩过的一个坑是：在某台骁龙8 Gen 2设备上，ONNX Runtime 1.16 + QNN SDK 2.18能跑通，但换成1.17就报错。后来查下来是QNN EP的接口变了。所以建议锁定版本组合，不要随意升级。

3.2 llama.cpp的QNN后端

llama.cpp这两年在端侧大模型圈子里很火，它的QNN后端也在逐步完善。相比ONNX Runtime，llama.cpp的优势是专门为大语言模型做了优化，支持GGUF格式的量化模型，内存管理更精细。它的QNN后端目前还在活跃开发中，社区提交比较频繁。

我用llama.cpp的QNN后端跑过Qwen2和Llama3的量化版本，整体体验是：小模型（1B-3B）跑起来比较顺，7B以上对内存和NPU算力要求高，需要设备有足够的RAM。另外，llama.cpp的QNN后端对KV Cache的处理还在优化中，长上下文场景下性能衰减比较明显。

3.3 TFLite与MNN的NPU委托

TFLite通过NNAPI（Android Neural Networks API）间接调用高通NPU。NNAPI是高通、谷歌等联合推的安卓标准，理论上写一次代码能跑在多家NPU上。但实际效果嘛……NNAPI的抽象层太厚，很多高通NPU的特性用不上，性能不如直接走QNN。而且NNAPI的算子支持也是参差不齐，大模型这种复杂结构，很容易碰到不支持的算子。

MNN是阿里开源的推理框架，它对高通NPU也有支持，主要通过QNN后端。MNN的优点是轻量、部署简单，在国内社区有一定用户基础。但在大模型场景下，MNN的生态和工具链不如ONNX Runtime完善。

3.4 框架对比一览

这张表是我基于实际调研和测试给出的主观评价。接入难度低不代表效果好，QNN原生接入难度最高，但能榨出最多性能。选哪个取决于你的团队能力和项目需求。

4. 模型量化：NPU推理的命门

4.1 为什么INT8是起步线

前面提过，Hexagon NPU的张量核心主要针对INT8和INT4优化。FP16虽然部分支持，但吞吐上不去。所以模型量化不是"可选项"，而是"必选项"。量化的本质是把浮点权重和激活值映射到低位宽的整数表示，减少内存占用和计算量。

以7B模型为例，FP16权重约14GB，INT8约7GB，INT4约3.5GB。手机RAM普遍在8-16GB，FP16根本放不下，INT8勉强，INT4比较现实。但量化会带来精度损失，尤其是INT4，对模型能力的影响需要仔细评估。

4.2 QNN的量化工具链

QNN提供了量化工具，支持PTQ（训练后量化）和部分QAT（量化感知训练）流程。PTQ的流程大致是：准备一批校准数据，跑一遍模型收集激活值分布，然后计算量化参数。校准数据的质量和数量直接影响量化效果。

我自己的经验是，校准数据最好覆盖实际使用场景的输入分布。比如你做的是对话模型，校准数据就应该包含各种长度的对话文本，而不是随便拿几百条新闻凑数。另外，QNN的量化工具对某些算子（如LayerNorm、Softmax）的处理比较敏感，量化后精度掉得厉害，这时候可能需要把这些算子留在CPU上执行。

注意：量化不是一劳永逸的。同一个模型，在不同设备、不同QNN版本上，量化效果可能不一样。建议在目标设备上做端到端的精度验证。

4.3 混合精度的取舍

全INT8量化有时候精度不够，全INT4又太激进。混合精度是个折中方案：对精度敏感的层用INT8，对精度不敏感的层用INT4。QNN支持这种混合精度配置，但需要手动指定每层的量化位宽，工作量不小。

我的建议是，先用全INT8跑通，看精度是否达标。如果达标，再尝试把部分层降到INT4，逐步压缩。如果全INT8就不达标，那可能需要考虑QAT，或者换更小的模型。

5. 从模型到部署的完整链路拆解

5.1 环境准备与版本对齐

这一步看似简单，实则是最容易翻车的地方。你需要对齐的版本包括：QNN SDK版本、ONNX Runtime版本（如果用ORT）、设备固件版本、Android NDK版本。高通每个季度会发布新的QNN SDK，但设备固件不一定同步更新。如果SDK版本高于设备固件支持的版本，可能会报错。

我的做法是：先确定目标设备，查清楚它支持的QNN版本范围，然后选择对应的SDK。不要盲目追新。另外，QNN SDK的安装和环境变量配置也有讲究，官方文档写得比较散，建议把QNN_SDK_ROOT、PATH、LD_LIBRARY_PATH这些配好之后，写个脚本固化下来。

5.2 模型转换与图优化

模型转换是第一个硬骨头。以ONNX模型为例，你需要用QNN Converter把它转成QNN格式。转换命令大致长这样：

qnn-onnx-converter \ --input_network model.onnx \ --output_path model.cpp \ --input_dim input_ids "1,128" \ --input_dim attention_mask "1,128" \ --quantization_overrides quant_overrides.json

这里有几个关键参数：--input_dim指定输入维度，大模型的输入通常是动态的，但QNN对动态shape支持有限，可能需要固定shape；--quantization_overrides指定量化配置，如果你有自定义的量化参数，通过这个文件传入。

转换过程中最常见的报错是算子不支持。这时候有两个选择：一是修改模型结构，用支持的算子替换不支持的算子；二是把不支持的算子标记为CPU执行。前者工作量大但性能好，后者省事但有性能损失。

5.3 运行时集成与内存管理

模型转好之后，就是集成到Android应用里。QNN提供了C++ API，你需要写JNI层来调用。这里的关键是内存管理：NPU的内存和CPU内存是分开的，数据在两者之间搬运有开销。QNN提供了共享内存的机制，可以减少拷贝。

另一个坑是模型加载时间。大模型的QNN模型文件可能几百MB，加载到NPU上需要时间。如果每次启动都重新加载，用户体验很差。我的做法是做一个常驻服务，模型加载一次，后续请求复用。

5.4 性能调优的实操手段

性能调优没有银弹，主要靠这几种手段：第一，调整量化配置，找到精度和速度的平衡点；第二，调整图切分策略，把哪些算子放NPU、哪些放CPU；第三，调整batch size和序列长度，找到NPU利用率最高的配置；第四，用QNN的profiling工具定位瓶颈。

我实测下来，图切分策略对性能影响最大。如果切得不好，数据在NPU和CPU之间来回搬运，开销比计算本身还大。原则是：尽量让连续的算子在同一设备上执行，减少跨设备的数据传输。

6. 实测中那些文档不会告诉你的坑

6.1 算子兼容性的隐形陷阱

官方文档列的"支持算子"和实际能跑的算子，中间有差距。有些算子文档说支持，但特定参数组合下会报错。比如Attention算子，不同的mask方式、不同的head维度，支持情况不一样。我遇到过文档说支持MultiHeadAttention，但实际转换时因为head数不是8的倍数而失败。

应对策略是：尽早做端到端的转换测试，不要等到模型都训练完了才发现转不过去。另外，保持和QNN SDK版本的同步，新版本往往会修复一些算子问题。

6.2 内存墙与OOM

大模型在NPU上跑，内存是硬约束。NPU的专用内存通常比系统RAM小，模型权重、激活值、KV Cache都要占内存。7B模型INT8量化后约7GB，加上KV Cache和运行时开销，很容易OOM。

我的经验是：第一，用INT4量化压缩权重；第二，限制上下文长度，减少KV Cache占用；第三，及时释放不用的中间张量。QNN提供了一些内存复用机制，但需要手动配置。

6.3 发热与降频

手机跑大模型，发热是必然的。NPU满载运行时功耗不低，持续跑几分钟后，设备会降频保护。降频后推理速度可能掉一半。这个问题在散热好的设备上稍好，但物理限制摆在那里。

实际产品中，需要做热管理策略：比如限制单次推理的token数、在温度过高时降级到小模型、或者做请求排队。这些策略需要在应用层实现，框架层面帮不了太多。

6.4 多线程与并发

QNN的上下文不是线程安全的。多个线程同时调用同一个QNN Context会出问题。如果你的应用需要并发推理，要么加锁串行化，要么创建多个Context。但多个Context会占用更多内存，需要权衡。

7. 不同场景下的框架选型建议

7.1 快速验证场景

如果你只是想快速验证"高通NPU能不能跑我的模型"，建议走ONNX Runtime + QNN EP这条路。接入成本最低，社区资料相对多，遇到问题容易找到参考。缺点是性能不是最优，但验证阶段够用。

7.2 产品级部署场景

如果要做产品，对性能和稳定性有要求，建议直接基于QNN原生API开发。虽然工作量大，但能完全控制图切分、内存管理、量化策略，性能上限最高。代价是需要投入更多人力做底层适配。

7.3 大语言模型专用场景

如果是LLM场景，llama.cpp的QNN后端值得关注。它针对Transformer结构做了不少优化，GGUF格式的量化模型生态也成熟。但要注意它的版本迭代快，接口可能变化，需要锁定版本。

7.4 跨平台兼容场景

如果应用需要同时跑在高通、联发科、苹果等多平台，NNAPI或ONNX Runtime的抽象层更合适。但要做好心理准备：抽象层意味着性能损失，高通NPU的特性用不上。

8. 我对这条技术路线的个人判断

折腾了这段时间，我的整体感受是：高通NPU跑大模型，技术上可行，但工程上还有不少路要走。QNN作为官方栈，能力是有的，但工具链的成熟度、文档的完善度、社区的支持度，和服务器端的CUDA生态比还有明显差距。

短期内，我建议的做法是：模型侧做好量化和结构适配，框架侧优先考虑ONNX Runtime或llama.cpp的QNN后端，部署侧做好热管理和内存管理。不要指望一套配置跑遍所有设备，针对主力机型做定向优化是必要的。

另外，高通的QNN SDK更新频率不低，每个版本都可能带来新的算子支持和性能改进。保持关注，但不要盲目升级，升级前做好回归测试。这个领域变化快，今天的最佳实践可能下个月就过时了，保持动手测试的习惯比记住任何结论都重要。