1. 为什么要在高通NPU上折腾大模型推理把大模型塞进手机、平板或者边缘计算盒子这件事从2023年下半年开始就成了端侧AI最热闹的方向。而只要你的目标设备用的是高通骁龙系列芯片那绕不开的一个核心组件就是Hexagon NPU。我做端侧推理优化差不多两年时间从最早用CPU硬扛7B模型那速度简直没法看到后来切到Hexagon NPU上跑量化模型再到折腾QNN SDK的各种算子适配踩过的坑可以说能写一本小册子。这篇文章想聊的是我对高通NPU大模型推理框架做的一轮系统性调研和深度对比。核心要回答几个问题高通平台上到底有哪些可用的推理框架它们各自的技术路线是什么QNN、Genie、AI Hub这些工具之间的边界在哪里实际部署一个7B级别的模型从模型转换到端侧跑通中间要过几道坎以及面对不同的项目需求到底该怎么选。适合读这篇的人我大致分三类一是正在做端侧AI应用开发、需要把大模型落到高通设备上的工程师二是做技术选型、需要评估高通NPU方案可行性的架构师三是对端侧推理感兴趣、想了解Hexagon NPU底层机制的技术爱好者。不管你是哪一类我都会尽量把原理讲透、把操作步骤写清楚让你看完能直接上手试。先给一个整体判断高通在端侧大模型推理这块的布局核心是QNNQualcomm Neural NetworkSDK这一套工具链往上衍生出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 EliteNPU的算力已经标称到45 TOPS甚至更高不同厂商的标称口径不一样别太当真看实际benchmark更靠谱。Hexagon NPU的关键特性有几个一是支持INT4/INT8/INT16混合精度这对大模型量化至关重要二是片上内存TCM和共享内存的层级设计决定了模型权重和激活值怎么摆放三是**HVXHexagon Vector eXtensions**负责向量运算**HMXHexagon 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 ProcessorlibQnnCpu.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-8Bprefill阶段大概能到20-30 tokens/sdecode阶段在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.04Windows上也能用但坑比较多。我的建议是用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端侧通常batch1但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上模拟执行快速验证模型转换是否正确。虽然模拟执行的性能和设备上不一样但至少能确认图结构和算子映射没问题省去反复推设备的时间。 
长河君 · 2026/10/31 16:01:41 · 阅读 1.2k 高通NPU大模型推理框架深度对比：QNN、Genie与AI Hub选型指南
1. 为什么要在高通NPU上折腾大模型推理把大模型塞进手机、平板或者边缘计算盒子这件事从2023年下半年开始就成了端侧AI最热闹的方向。而只要你的目标设备用的是高通骁龙系列芯片那绕不开的一个核心组件就是Hexagon NPU。我做端侧推理优化差不多两年时间从最早用CPU硬扛7B模型那速度简直没法看到后来切到Hexagon NPU上跑量化模型再到折腾QNN SDK的各种算子适配踩过的坑可以说能写一本小册子。这篇文章想聊的是我对高通NPU大模型推理框架做的一轮系统性调研和深度对比。核心要回答几个问题高通平台上到底有哪些可用的推理框架它们各自的技术路线是什么QNN、Genie、AI Hub这些工具之间的边界在哪里实际部署一个7B级别的模型从模型转换到端侧跑通中间要过几道坎以及面对不同的项目需求到底该怎么选。适合读这篇的人我大致分三类一是正在做端侧AI应用开发、需要把大模型落到高通设备上的工程师二是做技术选型、需要评估高通NPU方案可行性的架构师三是对端侧推理感兴趣、想了解Hexagon NPU底层机制的技术爱好者。不管你是哪一类我都会尽量把原理讲透、把操作步骤写清楚让你看完能直接上手试。先给一个整体判断高通在端侧大模型推理这块的布局核心是QNNQualcomm Neural NetworkSDK这一套工具链往上衍生出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 EliteNPU的算力已经标称到45 TOPS甚至更高不同厂商的标称口径不一样别太当真看实际benchmark更靠谱。Hexagon NPU的关键特性有几个一是支持INT4/INT8/INT16混合精度这对大模型量化至关重要二是片上内存TCM和共享内存的层级设计决定了模型权重和激活值怎么摆放三是**HVXHexagon Vector eXtensions**负责向量运算**HMXHexagon 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 ProcessorlibQnnCpu.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-8Bprefill阶段大概能到20-30 tokens/sdecode阶段在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.04Windows上也能用但坑比较多。我的建议是用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端侧通常batch1但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上模拟执行快速验证模型转换是否正确。虽然模拟执行的性能和设备上不一样但至少能确认图结构和算子映射没问题省去反复推设备的时间。