前阵子接了个需求要把一个在服务器上跑得不错的检测模型塞进手机要求精度不掉太多、首帧延时尽量压到几十毫秒级别。一开始我习惯性地想用TFLite或者MNN结果一查算子支持就有点头疼几个关键自定义算子在这类框架里要么不支持、要么得自己写实现CPU跑起来帧率又实在难看。后来看到手头测试机是高通平台干脆换个思路直接走高通自家的QNN框架把模型量化后部署到HTPHexagon张量处理器上。折腾了差不多两周终于把整条链路跑通从模型量化、QNN转换到Android端的JNI封装全部走完。这篇就把整个过程中的技术选型、实操步骤和踩过的坑整理出来给准备在安卓端跑大模型或者重模型的朋友做个参考。先说清楚一个概念标题里的“大模型”并不单指那种几十B参数的LLM也包括那些体积大、计算量大、在CPU和GPU上跑不动的CV模型或者跨模态模型。QNN目前对LLM这类动态shape模型的整图编译支持还在逐步完善阶段但如果是CNN、Transformer编码器这类静态shape的模型可以说是一把好手。这篇文章的核心链路是“PyTorch/ONNX模型 - 量化 - QNN转换 - HTP编译 - Android集成”这套流程跑通之后换个模型也就是替换文件、重新校准的事扩展性很强。1. 为什么选择QNN手机端推理框架的优劣势对比1.1 手机端跑大模型的需求和现实限制先说需求端。现在很多App都在尝试把AI能力直接放在端侧比如智能修图、实时翻译、文档识别、手势检测这类对隐私和延迟敏感的场景。如果所有请求都走云端一是网络延迟不稳定二是数据出设备这件事本身就有合规和隐私压力。因此端侧推理成了一个刚需。但端侧跑模型有几个绕不开的限制算力、内存、功耗和散热。手机上的CPU虽然这两年进步很大但要跑一个几千万参数的模型单帧推理耗时经常是几百毫秒起步发热也压不住。GPU虽然快一些但Adreno GPU在通用计算场景下的能效比还是不如专门的NPU。高通平台从骁龙8系列开始HTP已经是标配专门用来跑AI推理算力峰值能做到几十TOPS级别。QNNQualcomm Neural Network就是高通为这套硬件提供的统一软件框架定位类似TFLite、MNN但它是直接面向高通的CPU/GPU/HTP三端。1.2 QNN框架的核心优势和适用边界QNN相对其他框架有几个很实在的优点。首先是算子支持到位高通在QNN里维护了一套针对Hexagon指令集深度优化的算子库常见的卷积、全连接、LayerNorm、Softmax、注意力机制都有实现而且很多算子在HTP上有专门的硬件指令加速不是简单地“能在NPU上跑”而是“在NPU上跑得又快又省电”。其次是量化支持灵活。QNN支持PTQ训练后量化和QAT量化感知训练两条路线权重和激活的位宽也给了多种选择默认int8也可以在关键场景切换到A16W8这种“激活16bit、权重8bit”的混合精度方案。遇到精度敏感的任务这个选项经常能救命。第三是工具链完整。从ONNX/TFLite模型导入、校准、量化、编译成HTP可执行的二进制整套流程都有官方命令行工具和SDK支撑不用自己造轮子。但QNN也不是万能的。它的主要使用门槛有两个一是只适用高通平台换到联发科或者麒麟芯片就得换框架二是动态shape支持比较差如果你模型里有动态尺寸的输入或者循环结构转换时会遇到不少麻烦。所以我的建议是如果目标机型就是高通系而且模型静态shape能固定QNN是性价比很高的选择如果必须全平台覆盖那还是老老实实TFLite/MNN或者用Android自带NNAPI做后端分发。1.3 QNN的基本架构和关键组件QNN SDK解压之后你会看到sdk目录下分成好几个模块实际工程里最常用的是这几个libQnnHtp.soHTP后端的主库运行时要动态加载。libQnnHtpV*.so不同SoC版本对应的HTP实现比如骁龙8 Gen 2对应的是libQnnHtpV75.so这个版本号要跟目标机器的DSP固件匹配不然会初始化失败。libQnnSystem.so系统管理相关库。qnn-onnx-converter把ONNX模型转成QNN计算图描述。qnn-context-binary-generator把转换后的模型编译成序列化的context二进制实际部署时加载这个文件。运行时有两条路线可以选一条是直接从模型描述里逐节点构建图另一条是直接从context二进制文件恢复整个计算图。实际部署我强烈建议用后者加载速度更快而且有利于保护模型结构不会暴露图结构。2. 模型量化INT8不是万能的精度掉点怎么办2.1 为什么要量化量化到底牺牲了什么HTP上跑fp16甚至fp32理论上可行但那只是一条备选路线。实际端侧部署首选还是int8量化原因很简单内存带宽和计算效率。int8的数字宽度只有fp16的一半、fp32的四分之一单位时间能搬运的数据量直接翻倍HTP上的专用硬件指令对int8的吞吐也远大于浮点。对一个几十到几百MB的模型来说量化之后体积能缩小到原来的四分之一内存占用和加载耗时都能大幅优化。代价就是精度。量化本质是把连续的浮点数值映射到离散的整数区间里这个过程必然有信息损失。模型里如果有一些层对数值变化特别敏感比如输出层前面的全连接、某些归一化层量化之后结果可能偏差很大。更麻烦的是量化误差会逐层传递前面一层的小误差到后面可能被放大所以经常出现“模型整体准确率只掉了一个点但个别难例输出完全不对”的情况。2.2 校准数据集量化效果的分水岭PTQ量化的核心是校准calibration。校准的过程是用一批有代表性的输入数据跑一遍浮点模型统计每一层激活值的分布范围然后根据这个范围来确定量化参数scale和zero_point。如果校准数据选得不好统计出来的范围就会失真量化后的模型会有灾难性掉点。我的经验是校准数据要满足三个条件一是数量够我一般用200到500张样本太多反而让校准变慢太少又统计不准二是分布贴近真实应用场景如果你模型是白天拍的图结果校准全用晚上暗光图激活分布肯定偏三是尽量覆盖边界情况宁可把一些极端亮度的样本加进去也不要让量化参数在高动态范围场景下直接失效。QNN的qnn-onnx-converter在做PTQ时需要传入一个校准数据列表input_list里面每条数据是预处理好的输入文件路径。在校准的时候它会用HTP仿真器或者实际设备跑一遍推理收集激活分布然后据此校准量化参数。这个步骤很关键如果发现量化后模型在特定场景下输出异常第一反应应该是检查校准集的代表性而不是急着调量化方案。2.3 量化精度掉点A16W8和局部跳过量化如果你校准集做得没问题但量化后精度还是不可接受这时候有几个手段可以试。第一个是切到A16W8混合精度也就是激活保留16bit只把权重量化到8bit。这样做内存占用比纯int8多了一些但激活部分的动态范围扩大了很多那些对数值敏感的层基本都能喘过气来。对很多模型来说这个方案是“精度和性能都能打”的折中点。具体在QNN里怎么配qnn-onnx-converter提供了一系列量化相关的参数可以通过--quantize_full_type_int16把整体切到int16也可以更精细地指定某个算子区间用不同位宽。实际操作中我喜欢先跑一个默认int8的基线再跑一个全int16对比然后在A16W8上做局部调整看具体是哪些层拖累了精度。第二个手段是让某些层跳过量化保留浮点计算。不过这个操作在HTP上要小心一旦有浮点层整条推理链路就可能需要在CPU和HTP之间来回切换性能损耗很大。所以除非是输出层这种最敏感的位置我一般不建议普通中间层这么做。还有一个很隐蔽的坑量化后输出“数值不动”就是模型输出值一直卡在某个常数附近。这个现象我遇到过好几次排查下来基本都是某一层激活值的min/max统计严重抖动导致scale被估得特别小量化分辨率完全不足。解决办法是检查校准数据里是否有归一化不一致的样本或者在转换配置里手动指定该层的量化范围。2.4 量化方案的实测对比数据为了直观展示不同量化方案对精度和性能的影响我拿一个基于Transformer的模型做过一组对比实验这里放数据给大家参考。模型大小在300MB左右主要在骁龙8 Gen 2平台上测量化方案模型体积峰值内存占用单帧推理耗时精度指标相对fp32fp32CPU参考310MB约780MB620ms100%fp16HTP155MB约410MB145ms99.6%int8HTP78MB约220MB68ms97.2%A16W8HTP89MB约260MB82ms99.1%这个对比能看出两件事一是int8在速度上优势非常明显但精度代价不小二是A16W8的精度损失小得多速度还能保留在比较高的水平。如果你的业务对精度很敏感A16W8往往是最优解性能比纯int8慢了20%左右但精度几乎追平fp16。3. QNN模型转换全流程从ONNX到HTP二进制3.1 模型导出前的准备固定shape和算子清理在开始转换之前有个容易被忽略的环节是ONNX导出的质量。PyTorch导出ONNX时如果模型里有动态维度比如batch为-1、输入宽高可变的检测头QNN转换时就容易卡住。我的建议是导出前先固定所有动态轴的shape尤其是输入张量的双维度都定死可以使用torch.onnx.export的dynamic_axes参数将不需要动态的轴留空只保留batch维度做1。另外有些算子QNN支持得不好比如某些不太常见的上采样方式或者特定版本的RoPE实现转换时会报“Unsupported op”。碰到这种情况可以尝试在导出前把模型结构替换成等价实现或者升级ONNX opset版本到13以上很多问题其实跟opset太低有关。还有一个实操细节导出ONNX之后先用onnxruntime跑一遍确认浮点模型的输出跟PyTorch一致再做后续转换。很多转换失败其实不是QNN的问题而是原始模型导出的时候就已经有坑了。3.2 qnn-onnx-converter详细步骤拿到ONNX模型之后转换流程大概分三步。第一步是准备输入列表文件。这个文件每一行是一个输入数据的路径二进制格式raw格式就行。比如input_data_001.raw input_data_002.raw input_data_003.raw需要确保这些raw文件的尺寸和dtype跟模型输入一致。比如输入是1x3x224x224的float32张量那么每个raw文件的内容就是2242243个float32数值。第二步是执行转换命令python qnn-onnx-converter \ --input_network model.onnx \ --output_path model_qnn \ --input_list calibration_list.txt \ --quantization_parameters ... # 可选如果在没有量化需求的情况下比如只想先做fp16或者不量化可以不加input_list直接转换。但实际部署基本都要量化所以校准列表一般都会提供。转换完成之后你会得到一个model_qnn.cpp文件和model_qnn.bin之类的中间产物。这里的cpp文件是计算图的一个C描述还不是HTP能直接执行的二进制。第三步是用qnn-context-binary-generator把cpp编译成context二进制qnn-context-binary-generator \ --model model_qnn.cpp \ --backend libQnnHtp.so \ --binary_file model_qnn.serialized.bin这里有个细节编译时指定的backend版本要和运行时在手机上加载的libQnnHtp版本保持一致不然后续在手机上加载context二进制时会报错因为序列化格式可能不兼容。3.3 子图切分CPU算子和HTP算子的分工转换过程中经常遇到的情况是模型大部分算子都能落到HTP上但有一小撮算子不受支持。qnn-onnx-converter默认会给这些算子生成CPU实现让整张图在“HTPCPU”混合模式下运行。听起来挺美好实际用起来要注意性能损耗。为什么说子图切分要谨慎因为数据在CPU和HTP之间搬运是有成本的。假设模型前半段在HTP中间一个算子切到CPU后面的卷积又切回HTP那么一个推理周期内至少发生了两次cross-buffer复制每次复制都有几十微秒的开销如果模型本身单帧只有几十毫秒这个开销就占了大头。所以我在工程里一般会做两件事第一尽量从源头减少CPU子图的数量比如把某些不支持的算子替换成支持算子哪怕是多个算子组合也比切分到CPU划算第二如果实在无法避免CPU子图就尽量让它们集中在一个连续区间不要散落在各处。还有个更直接的方案转换时通过--op_package之类的参数把支持度好的算子强制到HTP执行不支持的统一丢到一个分组里。QNN有几个环境变量也可以用来控制子图策略具体可以查看SDK文档里关于libQnnHtp的设置项。3.4 模型文件的大小优化和加载优化模型转成serialized.bin之后体积一般比原始float模型小很多int8量化后的bin基本就是原模型四分之一左右。但部署到App时还可以再压缩一层直接把bin文件压缩进APK首次启动时解压到App私有目录或者做成资源文件在启动时加载。这里要特别提醒一个坑不要把bin文件放在assets的深层目录里然后频繁读取。assets目录的访问效率和普通文件系统不一样大文件加载会很慢。我的做法是App首次启动时把bin从assets复制到files目录后续直接从files目录加载。另外可以做一个简单的文件hash校验防止模型文件被篡改或者下载不完整。4. Android端集成JNI封装、库加载和推理调用4.1 工程配置CMake、NDK和依赖库QNN在Android端的使用方式是以C/C库为主你需要通过JNI把推理能力暴露给Java层。工程结构一般是Android Studio项目里建一个native模块用CMake来构建JNI代码同时把QNN SDK里的so库打包到jniLibs。具体步骤下载QNN SDK解压后找到lib/aarch64-android目录下的so文件。按需拷贝libQnnHtp.so、libQnnHtpV*.so、libQnnSystem.so到app/src/main/jniLibs/arm64-v8a/。在CMakeLists.txt里引入这些so库同时把头文件路径指向SDK的include目录。写一个JNI包装类提供Java层调用的方法比如loadModel()、execute()、release()。这里要注意NDK版本的选择。QNN对NDK版本并不是完全无感太新的NDK可能在链接阶段报GLIBC相关错误太老的又可能出现编译器版本兼容问题。我实际验证下来R23b或者R25c都挺稳的建议优先尝试这两个版本。4.2 JNI代码骨架加载Context二进制并执行推理下面是一个简化版的JNI代码结构核心步骤都有。真实项目中你可能还需要加入线程同步、内存池复用这些优化。#include jni.h #include string #include vector #include QNN/QnnInterface.h #include QNN/QnnContext.h #include QNN/QnnGraph.h #include QNN/QnnTensor.h // 全局句柄封装省得每次调用都重新初始化 QnnBackend_Config_t* backendConfig nullptr; std::vectoruint8_t contextBuffer; Qnn_ContextHandle_t contextHandle nullptr; Qnn_GraphHandle_t graphHandle nullptr; QnnTensor_Map_t inputTensors; QnnTensor_Map_t outputTensors; bool loadContextBinary(const std::string binPath, const std::string libPath) { // 1. 加载libQnnHtp.so // 2. 从SDK引入QnnInterface拿到函数指针表 // 3. 调用backendInitialize // 4. 调用contextCreateFromBinary创建context // 5. 从context里拿到root graph句柄 return true; } float* getInputTensorPointer() { // 通过QnnTensor_createMemBackedTensor拿到可写输入指针 } float* execute(float* inputData, int inputSize) { // 拷贝数据到输入张量 // 调用QnnGraph_execute // 返回输出指针 }代码里值得关注的点是QnnGraph_execute是一个阻塞调用执行期间占用当前线程。如果你的App需要在UI线程里做推理就一定要放到子线程否则直接ANR。另外QNN支持通过QnnProfile接口做耗时统计调试阶段很有用。4.3 输入输出的内存管理细节QNN张量的内存管理逻辑和其他框架不太一样。它不倾向让用户直接往张量对象里塞裸指针而是提供了一套createMemBackedTensor机制你先分配一块连续内存然后把它跟一个tensor对象绑定起来之后每次execute就复用这块内存。这套机制的好处是省去了反复malloc和释放的开销坏处是一旦你忘了释放或者传错了size段错误几乎是一瞬间的事。我写代码的时候习惯把输入输出张量的创建放在模型初始化阶段完成推理时只做数据拷贝和execute。每次推理的输入数据拷贝到输入内存块执行完之后直接从输出内存块读走结果。这样整个推理循环里没有一次堆内存分配稳定性好很多。还有一个容易踩的坑是dtype对齐。如果你的模型输入是float32但QNN量化后实际执行时的输入可能是uint8或者int8那么JNI层直接往输入张量写float数据就会得到垃圾输出。正确做法是先搞清楚模型转换后的输入张量dtype到底是什么可以通过QnnTensor_getTensorLayout或者直接看转换日志。一般来说量化模型如果做了端到端量化输入也会被量化那就需要在JNI层先做一次输入数据的归一化和量化转换而不是直接塞浮点。4.4 用sigaltstack还是直接崩溃聊聊信号处理QNN的HTP后端在部分机型和固件上偶尔会因为DSP侧的固件问题导致native崩溃这种崩溃往往发生在底层so库里不像Java异常那样有完整堆栈。我遇到过一次在特定机型上推理几小时后偶发crash的情况排查起来比较头疼。一个有效的兜底方案是在native层注册自己的信号处理器捕获SIGSEGV和SIGBUS打印出当前调用栈和模型文件名方便线上定位。这种方式不能修复崩溃本身但能大幅缩短排查时间。具体可以用sigaction实现把关键信息写入logcat。5. 性能调优和精度验证不能只追求“跑起来”5.1 预热、计时和稳定性测试部署到手机之后第一件事不是看功能对不对而是先做性能和稳定性摸底。我常用的测试方法是专门写一个自动化测试页面或者命令行工具让模型连续推理几百帧统计每一帧的耗时分布。这里注意两点一定要预热。模型的第一次推理往往不是真实水平因为涉及缓存、内存映射、甚至CPU频率提升的过程至少跑20帧之后再开始计时。看P95而不是平均。平均耗时会掩盖偶发的长尾延迟如果P95明显高于P50说明系统里有些帧被调度或者内存管理拖累了这在端侧是很常见的。5.2 CPU频率、锁核和散热的影响手机端的算力表现非常受限于功耗调度。同一个模型在手机冷机状态和玩了半小时游戏之后测出来的结果可能差30%以上因为CPU/GPU/NPU的频率已经被温控策略压下去了。所以我做评测的时候会强调测试环境的一致性同一台手机、同一个系统版本、同一个电量区间、尽量在冷机状态下测。如果你的App对稳定性有要求可以尝试通过系统的性能接口申请高性能模式但要注意这个操作会加速耗电和发热生产环境一般不建议默认开启。更好的做法是把推理任务集中处理避免频繁唤醒和休眠带来的调度抖动。5.3 精度验证不只看准确率还要看数值分布部署完成之后精度验证是很多人的盲区。最常见的问题是拿了一张测试图发现模型输出跟服务器端浮点模型有差异就慌慌张张觉得量化方案不对。其实量化模型有轻微数值偏差是正常的真正要关注的是偏差是否在可接受范围内。我的建议是准备一批典型的bad case把量化模型的输出和浮点模型的输出逐层对比。QNN提供了profiling工具可以dump出中间张量的数值配合Python端的numpy分析可以快速定位是哪一层开始偏差变大。这个手段在排查“为什么我的量化模型只在某种光线场景下失效”这类问题时特别有效。另外一个从实际项目中总结的心得不要只看最终输出和标签是否匹配还要检查输出张量的数值分布是否合理。比如一个分类模型浮点模型给出的top-5置信度通常在0.1到0.9之间平滑分布而量化模型如果输出集中在0.01以下或者全部接近1.0说明softmax之前的那一层量化参数可能有问题。6. 常见问题与排查技巧实录6.1 运行时报错速查表我把实战中遇到的问题整理成了一个表格按频率从高到低排列供大家直接对照排查问题表现可能原因解决思路初始化HTP backend失败libQnnHtpV*.so版本与SoC型号不匹配检查目标机型的DSP固件版本换匹配的V库contextLoadFromBinary报格式错误context二进制编译时使用的QNN版本与运行时不一致尽量保持编译和运行使用同一个QNN SDK版本推理输出全为0或常数输入数据dtype不对或者模型做了端到端量化但JNI层没有做量化预处理确认输入张量类型增加量化/反量化逻辑单帧耗时不达标模型有部分算子落到CPU执行没有充分预热系统调度不稳定检查算子支持情况做子图集中化增加预热固定频率测试偶发native崩溃HTP固件bug或内存越界先加信号处理打印栈再考虑降低并发推理数模型转换时提示Unsupported opONNX导出有动态shape或opset版本太低固定shape升级opset替换等价算子6.2 找算子支持问题的方法和工具QNN提供一个非常实用的工具叫模型验证工具可以在转换阶段就把算子支持情况列出来。另一个思路是直接用QNN的模拟器跑一遍推理它会输出每一层的执行情况和耗时如果某一层被标记成CPU执行或者出现警告那大概率就是性能瓶颈所在。实际工作中我遇到过最烦的一种情况模型转换时一切正常所有的层都显示HTP支持但跑起来之后速度依然很慢。后来定位发现是一两个我以为是激活层的算子内部实现其实非常耗时。这种问题只有通过逐层profiling才能发现如果你的模型在HTP上速度明显低于预期一定要养成先分析层耗时再动手优化代码的习惯。6.3 模型迭代后的重新部署端侧模型的一个现实问题是迭代频繁。如果模型结构不变、只更新权重重新走一遍量化转换就行速度很快。但如果结构变了就要重新检查算子支持情况和量化校准效果不能图省事直接用旧模型转好的context文件。我见过有人改了模型结构之后忘了重新校准结果部署上去精度崩了查了整整一天才找到原因。7. 一点实际经验总结从项目立项到部署上线整个方案最花时间的地方其实不在写代码而是在“判断该不该用QNN”和“精度到底能不能接受”这两个问题上。如果你手头是做高通平台独占的高性能AI应用QNN这条路非常值得投入但如果产品还要覆盖更多芯片平台一开始就必须思考好抽象层怎么设计避免被单一框架绑定。另外有一点想说清楚QNN的学习曲线确实不友好官方文档偏工程化很多细节藏在release notes和sample code里。我建议新手先把自己最熟悉的模型整个流程跑通哪怕是个很小的分类模型也把量化、转换、部署、调优走一遍比单纯看文档有用得多。等你习惯了这个流程再切换到大的目标检测模型或者分割模型只是在数据集和参数上做调整而已。最后分享一个小技巧QNN SDK里自带的示例代码其实比文档值钱很多尤其是跟Android集成相关的sample基本覆盖了完整的JNI调用、库加载和推理流程尽量先把它运行起来再改自己的模型能少走很多弯路。