1. 为什么要在高通NPU上折腾大模型推理
把大模型塞进手机、平板或者边缘计算盒子，这件事从2023年下半年开始就成了端侧AI最热闹的方向。而只要你的目标设备用的是高通骁龙系列芯片，那绕不开的一个核心组件就是Hexagon NPU。我做端侧推理优化差不多两年时间，从最早用CPU硬扛7B模型（那速度简直没法看），到后来切到Hexagon NPU上跑量化模型，再到折腾QNN SDK的各种算子适配，踩过的坑可以说能写一本小册子。
这篇文章想聊的，是我对高通NPU大模型推理框架做的一轮系统性调研和深度对比。核心要回答几个问题：高通平台上到底有哪些可用的推理框架？它们各自的技术路线是什么？QNN、Genie、AI Hub这些工具之间的边界在哪里？实际部署一个7B级别的模型，从模型转换到端侧跑通，中间要过几道坎？以及，面对不同的项目需求，到底该怎么选。
适合读这篇的人，我大致分三类：一是正在做端侧AI应用开发、需要把大模型落到高通设备上的工程师；二是做技术选型、需要评估高通NPU方案可行性的架构师；三是对端侧推理感兴趣、想了解Hexagon NPU底层机制的技术爱好者。不管你是哪一类，我都会尽量把原理讲透、把操作步骤写清楚，让你看完能直接上手试。
先给一个整体判断：高通在端侧大模型推理这块的布局，核心是QNN（Qualcomm Neural Network）SDK这一套工具链，往上衍生出Genie推理运行时、AI Hub模型托管平台、以及面向Android的AIDL服务接口。它的技术路线和英伟达的CUDA生态、英特尔的OpenVINO有相似之处，但又有自己非常鲜明的特点——强绑定Hexagon NPU的硬件架构，对量化极其敏感，算子支持是最大的门槛。
2. 高通NPU推理框架全景拆解
2.1 Hexagon NPU的硬件底座决定了框架设计
要理解高通的推理框架为什么长这样，得先看Hexagon NPU的硬件结构。从骁龙8 Gen 1开始，Hexagon处理器内部集成了专门的Tensor Accelerator和Vector Extension单元，到了骁龙8 Gen 3和8 Elite，NPU的算力已经标称到45 TOPS甚至更高（不同厂商的标称口径不一样，别太当真，看实际benchmark更靠谱）。
Hexagon NPU的关键特性有几个：一是支持INT4/INT8/INT16混合精度，这对大模型量化至关重要；二是片上内存（TCM）和共享内存的层级设计，决定了模型权重和激活值怎么摆放；三是**HVX（Hexagon Vector eXtensions）**负责向量运算，**HMX（Hexagon Matrix eXtensions）**负责矩阵乘加，大模型的Transformer结构里大量的MatMul就是靠HMX来加速的。
这些硬件特性直接影响了框架的设计。比如QNN SDK里为什么对算子融合（operator fusion）那么讲究？因为NPU的指令调度和内存带宽是瓶颈，把多个算子融合成一个kernel执行，能大幅减少数据在DDR和片上内存之间的搬运。再比如为什么高通特别强调量化？因为NPU的INT4/INT8吞吐远高于FP16，而大模型的参数量摆在那里，不量化根本塞不进内存带宽预算。
2.2 QNN SDK：整个生态的地基
QNN SDK是高通端侧推理的核心工具链，它提供了一套统一的API，让开发者可以把训练好的模型（PyTorch、ONNX、TensorFlow等格式）转换到高通硬件上执行。QNN的架构大致分三层：
- 前端（Converter）：把外部模型格式转成QNN自己的模型格式，比如
.cpp、.bin、.serialized等。这一步会做图优化、算子映射、量化标注。 - 中间层（Graph/Op定义）：QNN定义了自己的算子集合，每个算子对应Hexagon NPU上的一种或多种硬件实现。如果某个算子NPU不支持，就会fallback到CPU或GPU执行。
- 后端（Backend）：真正跑在Hexagon NPU、Adreno GPU或Kryo CPU上的运行时。QNN支持多种backend，比如
libQnnHtp.so对应Hexagon Tensor Processor，libQnnCpu.so对应CPU。
QNN SDK的版本迭代很快，我用的比较多的几个版本是2.18、2.22、2.26。每个版本对算子的支持、量化策略、性能都有变化。这里有个经验：不要盲目追最新版，先确认你的目标设备固件里预置的QNN版本，因为端侧部署时SDK版本和固件版本不匹配会导致各种奇怪的加载失败。
2.3 Genie：面向大模型的推理运行时
如果说QNN是地基，那Genie就是专门为大模型盖的那层楼。Genie是高通在2024年推出的一个推理运行时，它的定位类似llama.cpp或者MLC LLM，但底层走的是QNN的HTP backend。
Genie的核心能力包括：模型加载、tokenizer管理、KV Cache管理、采样策略（top-k、top-p、temperature）、以及对话模板的拼接。它把大模型推理的常见流程都封装好了，开发者只需要提供一个配置文件（描述模型路径、上下文长度、量化方式等），就能跑起来。
我实测下来，Genie在骁龙8 Gen 3上跑一个4-bit量化的Llama-3-8B，prefill阶段大概能到20-30 tokens/s，decode阶段在10-15 tokens/s左右。这个速度放在手机上已经算可用了，但和云端GPU还是没法比。Genie的优势在于功耗控制，NPU跑推理的能效比CPU高一个数量级，长时间对话不会让手机烫得拿不住。
2.4 AI Hub与模型托管：降低上手门槛
Qualcomm AI Hub是一个在线的模型托管和转换平台。你可以把HuggingFace上的模型提交上去，AI Hub会自动帮你做量化、转换、并在真实设备上跑benchmark。它支持不少主流模型，比如Llama、Mistral、Phi、Stable Diffusion等。
AI Hub的价值在于省去了本地搭环境的麻烦。QNN SDK的安装和配置在Linux上还算顺畅，在Windows上就比较折腾。AI Hub直接在云端帮你把模型转好，你下载转换后的产物就能用。但它的限制也很明显：只支持它列表里的模型架构，自定义模型或者魔改过的结构就得自己动手。
2.5 Android AIDL与系统集成
从Android 14开始，高通在系统层面提供了AIDL接口来访问NPU推理服务。这意味着应用层可以通过标准的Android IPC机制调用NPU，而不需要自己链接QNN的native库。这对应用开发者友好很多，但也带来一些限制，比如接口的抽象层次较高，细粒度的性能调优空间变小。
热词里提到的“高通 安卓15添加 aidl”就是这个方向。如果你在做系统级应用或者预装应用，走AIDL是更规范的做法；如果是做独立APK或者native demo，直接链接QNN库更灵活。
3. 主流框架深度对比与选型逻辑
3.1 四类方案的核心差异
我把高通平台上做大模型推理的方案分成四类，用一个表格来对比：
| 方案 | 底层依赖 | 上手难度 | 灵活性 | 适用场景 |
|---|---|---|---|---|
| QNN SDK原生 | HTP/CPU/GPU backend | 高 | 最高 | 深度定制、算子级优化 |
| Genie运行时 | QNN HTP | 中 | 中 | 快速部署LLM对话应用 |
| AI Hub托管 | 云端转换+QNN | 低 | 低 | 验证可行性、标准模型 |
| Android AIDL | 系统NPU服务 | 低 | 低 | 系统应用、规范集成 |
这个表格是宏观视角，实际选型时还要看具体约束。比如你的模型是不是标准Transformer？有没有自定义算子？目标设备的QNN版本是多少？上下文长度要支持多长？这些都会影响最终选择。
3.2 量化策略：INT4还是INT8
大模型端侧部署，量化是绕不过去的。高通NPU支持INT4、INT8、INT16、FP16等多种精度，但不同精度对性能和精度的影响差异很大。
INT8量化是比较成熟的选择，QNN SDK对INT8的支持最完善，算子覆盖最全。一个7B模型INT8量化后大约7GB，放在手机上还是偏大，但放在边缘盒子上没问题。精度损失通常在1-2个百分点以内。
INT4量化能把模型压到3.5GB左右，更适合手机。但INT4对量化算法要求高，per-channel和group-wise量化策略要选对，否则精度掉得厉害。QNN SDK从2.20版本开始对INT4的支持好了很多，但仍有部分算子只支持INT8，混合精度部署时需要仔细检查。
我的经验是：先跑INT8确认流程通，再尝试INT4压体积。如果INT4精度不达标，可以考虑AWQ或GPTQ这类量化算法，把权重转成INT4但激活保持INT8或FP16。
3.3 算子支持：最大的坑在这里
QNN SDK的算子支持列表是选型时必查的。Transformer结构里常见的算子，比如MatMul、LayerNorm、Softmax、GELU、RoPE等，大部分都有HTP实现。但一些新模型用的算子，比如某些变体的注意力机制、自定义的激活函数，就可能不支持。
不支持怎么办？两条路：一是算子拆分，把不支持的算子用支持的算子组合出来；二是fallback到CPU，但这会严重拖慢速度，因为数据要在NPU和CPU之间来回搬。
我踩过的一个坑是RoPE（旋转位置编码）的实现。早期QNN版本对RoPE的支持不完整，导致模型跑出来的结果完全乱套。后来发现是位置编码的sin/cos计算精度不够，换成查表方式才解决。这类问题在文档里往往不会写，只能靠实测发现。
3.4 内存与KV Cache管理
大模型推理的另一个瓶颈是KV Cache。上下文越长，KV Cache占用的内存越大。高通NPU的片上内存有限，KV Cache通常要放在DDR里，这就带来带宽压力。
Genie运行时对KV Cache做了优化，支持分页管理和动态回收。但如果自己用QNN SDK裸写，KV Cache的管理就得自己来。我的做法是：把KV Cache按层切分，每层单独分配buffer，推理时按需加载。这样虽然增加了一些管理开销，但能有效控制峰值内存。
4. 从模型到端侧的完整实操流程
4.1 环境准备与SDK安装
先说环境。QNN SDK官方支持Ubuntu 20.04/22.04，Windows上也能用但坑比较多。我的建议是用Ubuntu 22.04 + Docker，把环境隔离好，避免污染宿主机。
安装步骤大致如下：
# 下载QNN SDK（需要注册高通开发者账号） # 解压后设置环境变量 export QNN_SDK_ROOT=/path/to/qnn-sdk export PATH=$QNN_SDK_ROOT/bin/x86_64-linux-clang:$PATH export LD_LIBRARY_PATH=$QNN_SDK_ROOT/lib/x86_64-linux-clang:$LD_LIBRARY_PATH # 验证安装 qnn-onnx-converter --version qnn-model-lib-generator --version这里有个细节：QNN SDK的x86版本主要用于模型转换和模拟执行，真正跑在设备上的是aarch64版本。转换时用x86工具，部署时用aarch64库，别搞混了。
4.2 模型转换：从PyTorch到QNN
假设你有一个PyTorch训练的模型，转换流程一般是：
- 导出ONNX：用
torch.onnx.export把模型转成ONNX格式。注意opset版本，QNN对opset 17的支持比较好。 - ONNX简化：用
onnx-simplifier做常量折叠和算子融合，减少图规模。 - QNN转换：用
qnn-onnx-converter把ONNX转成QNN模型。这一步要指定量化参数，比如--act_bw 8 --weight_bw 8表示激活和权重都用8bit。 - 模型编译：用
qnn-model-lib-generator把QNN模型编译成设备可加载的共享库。
转换过程中最常见的报错是算子不支持。这时候要看QNN的日志，找到具体是哪个算子，然后决定是拆分还是替换。
4.3 量化校准：决定精度和性能的关键
量化校准是转换过程中最需要耐心的环节。QNN支持多种校准方法，比如MinMax、MSE、Percentile等。不同方法对精度的影响不一样。
我的做法是：准备一个校准数据集，大概100-500个样本，覆盖模型的实际输入分布。然后用qnn-onnx-converter的校准模式跑一遍，生成量化参数。校准完后，一定要在验证集上测精度，和FP32版本对比，看掉点是否在可接受范围内。
如果精度掉太多，可以尝试：
- 换校准方法（比如从MinMax换成MSE）
- 增加校准样本数量
- 对敏感层保持FP16精度（混合精度）
4.4 端侧部署与性能调优
模型转换好后，部署到设备上。如果是Android设备，通常通过adb push把模型文件和QNN库推到设备上，然后用一个native可执行文件加载运行。
性能调优的几个方向：
- 线程亲和性：把推理线程绑定到大核，减少调度抖动。
- 内存对齐：QNN对内存对齐有要求，不对齐会导致性能下降甚至崩溃。
- Batch Size：端侧通常batch=1，但prefill阶段可以适当增大batch提高吞吐。
- KV Cache复用：多轮对话时复用KV Cache，避免重复计算。
我实测过一个7B INT4模型在骁龙8 Gen 3上的表现：prefill 512 tokens大约需要1.5秒，decode阶段每token约80-100毫秒。这个数据供参考，实际会因模型结构、量化方式、散热条件而变化。
5. 常见问题排查与避坑指南
5.1 模型加载失败
现象：QNN库加载模型时报错，提示版本不匹配或算子不支持。
排查思路：
- 确认设备固件里的QNN版本和SDK版本一致。用
adb shell查看/vendor/lib64/libQnnHtp.so的版本号。 - 检查模型转换时用的QNN版本和部署时是否一致。跨版本转换经常出问题。
- 看日志里具体是哪个算子失败，对照QNN的算子支持列表。
5.2 推理结果异常
现象：模型能跑，但输出乱码或者重复。
排查思路：
- 检查tokenizer是否匹配。不同模型的tokenizer差异很大，用错了会导致输入ID完全不对。
- 检查位置编码的实现。RoPE的精度问题我前面提过，是高频坑。
- 检查量化校准是否充分。校准不足会导致激活值分布偏移，输出异常。
5.3 性能不达预期
现象：推理速度比预期慢很多。
排查思路：
- 用QNN的profiling工具看每个算子的耗时，找到瓶颈。
- 检查是否有算子fallback到CPU。fallback会严重拖慢速度。
- 检查内存带宽是否成为瓶颈。大模型推理很多时候是memory-bound而不是compute-bound。
5.4 常见问题速查表
| 问题 | 可能原因 | 解决方法 |
|---|---|---|
| 模型加载失败 | 版本不匹配 | 统一SDK和固件版本 |
| 输出乱码 | tokenizer错误 | 确认tokenizer配置 |
| 输出重复 | 采样参数问题 | 调整temperature/top-p |
| 速度慢 | 算子fallback | 检查算子支持列表 |
| 精度掉点 | 量化过度 | 混合精度或换校准方法 |
| 内存溢出 | KV Cache过大 | 限制上下文长度或分页管理 |
6. 一些实操心得和后续扩展方向
折腾高通NPU大模型推理这段时间，最大的感受是：工具链在快速成熟，但文档和社区支持还跟不上。很多问题只能靠实测和看源码解决。我建议新手先从AI Hub跑通一个标准模型，建立信心，再逐步深入QNN SDK做定制。
另外，热词里提到的“高通caf kernel”“高通kgsl学习”这些，其实和NPU推理是有关联的。CAF kernel里的GPU/NPU驱动、KGSL的电源管理，都会影响推理性能和功耗。如果你要做极致的性能优化，这些底层知识是绕不开的。
后续我打算继续研究几个方向：一是多模态模型在NPU上的部署，比如视觉编码器加LLM的组合；二是 speculative decoding 在端侧的可行性；三是不同量化算法（AWQ、GPTQ、SmoothQuant）在高通NPU上的实际表现对比。这些内容如果有新的发现，我会再整理出来分享。
最后分享一个小技巧：调试QNN模型时，善用qnn-net-run这个工具，它能在x86上模拟执行，快速验证模型转换是否正确。虽然模拟执行的性能和设备上不一样，但至少能确认图结构和算子映射没问题，省去反复推设备的时间。
