QNN实战：从模型转换到骁龙平台部署全流程解析

如果你最近在折腾端侧AI，十有八九碰过这么一档子事：模型在电脑上跑得飞快，一放到手机上就卡成PPT，尤其想把YOLO、BERT这类模型塞进骁龙平台设备的时候，基本绕不开高通这套AI Engine SDK，也就是大家常说的QNN。这篇文章把整个链路串一遍，从环境配置、模型转换、量化、推理到性能分析，把我实际操作中踩过的坑和已经验证可走的流程全部写出来，给准备在骁龙平台上部署模型的同学当个参考。

我前后在几个项目里用过QNN跑目标检测、图像分类和语义分割模型，有顺利的时候，也有被版本兼容问题折腾到怀疑人生的时候。这篇不做纯理论堆砌，把能直接落地的步骤和关键参数摆出来。无论是刚接触端侧推理的新手，还是已经在用TFLite、ONNX Runtime、RKNN，想横向对比一下高通工具链的开发者，都能在里面找到能直接用的东西。

1. 整体认知：QNN到底是什么，为什么值得用它

1.1 高通AI Engine Direct的核心架构

高通AI Engine SDK，以前叫Snapdragon Neural Processing Engine（SNPE），后来升级成了Qualcomm AI Engine Direct，里面的开发组件统称QNN。名字变过，底层思路也换过一轮，但核心目标没变：让AI模型高效跑在高通芯片上，吃满CPU、Adreno GPU、Hexagon DSP这些计算单元。

熟悉高通平台的都知道，Hexagon DSP是低功耗推理的关键，它内部有HTA（Hexagon Tensor Accelerator）和HVX（Hexagon Vector Extensions）这类专用计算单元，对INT8量化的卷积、矩阵运算支持尤其好。QNN就是直接面向这些硬件单元暴露计算图API的程序库，你不再需要像老SNPE时代那样转成DLC格式再经过一堆封闭工具，而是可以用相对开放的Graph API来构建和执行计算图。

QNN SDK的核心组件我简单梳理一下，方便后面讲的时候不迷路：

• QNN System / Backend：负责把计算图调度到不同的硬件后端，常见的有CPU backend、GPU backend、HTP（Hexagon Tensor Processor）backend。
• QNN Graph API / Context API：面向开发者的编程接口，用来创建图、张量、配置执行上下文。
• 模型转换工具：把ONNX、TensorFlow、TFLite等格式的模型转成QNN支持的结构。
• 量化工具链：包括离线量化、校准数据生成、量化误差分析。
• Profiling和调试工具：在设备上采集每一层的执行耗时和资源占用。

这套结构早就不只是手机端了，智能座舱、AR/VR头显、智能摄像头、工业手持终端，只要是骁龙平台，都能跑同一套QNN工具链，这也是它比很多各自为战的推理框架更值得投入时间研究的原因。

1.2 相比TFLite、ONNX Runtime、RKNN，QNN强在哪

我在评估端侧推理框架时，通常会从算子覆盖率、性能上限、开发成本和生态闭环四个维度去比。QNN在这四个维度上表现比较均衡，尤其在算子覆盖上，它更贴近高通底层硬件的特性，而不是像TFLite那样为了跨平台通用性牺牲部分算子的执行效率。

具体说几个我印象深刻的点：

• 算子覆盖更直接：TFLite和ONNX Runtime在移动端跑自定义算子往往要写Delegate或Custom Op，工程量不小。QNN提供相对完整的后端算子库，即使遇到不支持的算子，也有GPL（Graph Preparation Library）和OP包扩展机制去补救。
• 异构调度更流畅：QNN允许在同一个模型执行时把不同算子调度到不同后端，比如把卷积丢给HTP，把动态控制流丢给CPU，这种混合调度能力在很多其他框架里需要额外拼装才能实现。
• 量化闭环更成熟：QNN对INT8量化的支持是原生的，从校准到验证有配套工具，配合高通的Hexagon DSP直接起飞。
• 硬件绑定深：天然只服务高通平台，这既是优势也是限制，如果你的产品线是纯骁龙，那QNN基本是性能最优解；如果还需要跨平台，就得在它和通用框架之间做取舍。

1.3 哪些场景适合用QNN，哪些不适合

QNN适合在以下场景使用：产品形态固定为高通平台的边缘设备、对单位功耗AI算力有严格要求（比如摄像头、无人机续航敏感）、团队有硬件和嵌入式Linux经验、需要支持多种模型结构快速迭代。

不太适合的场景也很现实：产品要全平台（Android+iOS+Linux+Windows）覆盖、团队完全没有嵌入式Linux交叉编译经验、模型里大量使用Transformer类自定义算子且每个版本都变。在这些情况下，你可能需要先评估QNN的算子覆盖再决定。

我的习惯是：先用TFLite或ONNX Runtime做原型，验证算法可行性和业务指标，一旦确认目标硬件是高通平台，再花时间切到QNN做正式优化。这套两步走的方法能避开很多来回返工。

2. 环境配置：把QNN SDK跑通是继续操作的前提

2.1 下载SDK与版本选择

QNN SDK目前是在高通Qualcomm AI Hub和Qualcomm Developer Network（QDN）渠道发布，需要注册开发者账号并申请下载权限。注意，这跟通过apt-get下载开源包完全是两码事，申请审核通常需要一两个工作日，做项目排期的时候要把这个时间算进去。

版本选择上我的建议比较直接：不要去追最新版，找自己目标平台的官方支持版本。我记得自己用过v2.4、v2.6、v2.12、v2.17和v3.x系列，每个版本对操作系统、Python版本、Hexagon SDK都有不同要求。如果平台的BSP（Board Support Package）里指定的QNN版本是2.12，那本地开发环境最好也用2.12，不然把模型转到目标板上运行时，会冒出莫名其妙的库不兼容问题。

下载完SDK压缩包后，解压出来的目录结构大概是这样的：

qnn-2.17.0.xxxxxx/ ├── bin/ ├── docs/ ├── examples/ ├── include/ ├── lib/ ├── python/ ├── scripts/ ├── toolchains/ └── share/

bin目录里有模型转换、量化、性能剖析工具；lib里是各个后端的动态库；include是开发头文件；python目录里有QNN Python接口和辅助脚本。先把目录结构认清楚，后面找工具和踩坑定位都会快很多。

2.2 Linux环境变量配置

由于开发和高通平台本身多运行在Linux上，下面以Ubuntu 18.04/20.04/22.04为例说明。第一次配置时，最核心的是把QNN的库路径和Python路径设好，否则后续跑任何工具都会遇到找不到so文件或者import qnn失败的问题。

我习惯把环境变量写成一个setup_qnn.sh脚本，以后每次打开终端source一下，不用重复敲命令：

# setup_qnn.sh export QNN_SDK_ROOT=/opt/qcom/aie/${QNN_VERSION} export PYTHONPATH=${QNN_SDK_ROOT}/python:${PYTHONPATH} export LD_LIBRARY_PATH=${QNN_SDK_ROOT}/lib/x86_64-linux-clang:${LD_LIBRARY_PATH} export PATH=${QNN_SDK_ROOT}/bin/x86_64-linux-clang:${PATH}

这里有个容易踩的坑：SDK里带了很多预编译库，是用指定版本的Clang和libc++编译的，所以系统环境里最好有对应的Clang和LDC++库，否则后面运行qnn-onnx-converter这类工具时，会报GLIBCXX版本不够或者找不到libc++的相关错误。

我在Ubuntu 22.04上遇到过SDK里的so文件需要libc++的情况，系统可能默认没装，这时候执行：

sudo apt-get install libc++-dev libc++abi-dev

一般能解决。

2.3 编译工具链和Hexagon NDK准备

如果只做x86 PC上的模拟推理，有上面那套环境就够了。但要真正在Hexagon DSP上跑HTP后端，还需要高通Hexagon SDK和对应的工具链。涉及的东西比较多，这里先提醒几个容易踩坑的点：

显卡驱动也不容忽视，GPU后端用到Adreno桌面模拟库时，需要目标平台支持OpenCL。x86环境下如果只是CPU或HTP模拟，OpenCL要求可以暂时跳过。

交叉编译的时候，目标板运行的环境可能跟PC不同。常见目标平台是带骁龙芯片的开发板或者工控机，识别ARM64架构，动态库要选lib/aarch64-linux-gnu版本，而不是x86_64。我曾经因为拷贝库时搞错架构，在板子上反复崩溃，排查了很久才发现竟然是库的架构问题，这个低级错误太容易犯。

2.4 Windows和Docker环境配置参考

不少算法工程师的主力开发机是Windows，QNN SDK也提供Windows版本，基本配置思路一致。把bin、lib、python路径加到系统环境变量即可。需要注意的是，QNN工具链大多是命令行工具，建议配合Git Bash或WSL使用，不然写脚本和调参数会无比痛苦。我自己的做法是：在Windows上统一用WSL2跑Linux版本的QNN工具链，原生Windows版本通常只在需要调用专有库时踩坑较少。

Docker也是好选择。高通官方和一些社区维护了QNN SDK的Docker镜像，可以省去一整套SDK环境安装流程。但需要留意容器里的USB/USB-C调试权限，后续连接目标板时，要先给Docker容器加--privileged或绑定对应设备节点，否则adb连不上设备。

2.5 验证环境是否配置成功

环境配置完成后，先跑一个最简单的验证命令：

qnn-execute --help

如果能正确输出命令帮助，说明动态库和PATH基本没问题。之后可以进一步跑官方自带的一个简单示例模型，这一步能确认后端加载是否正常：

python ${QNN_SDK_ROOT}/examples/Models/InceptionV3/scripts/setup_inceptionv3.py qnn-net-run --backend ${QNN_SDK_ROOT}/lib/x86_64-linux-clang/libQnnCpu.so \ --model ${QNN_SDK_ROOT}/examples/Models/InceptionV3/build/inception_v3.bin \ --input_list input_list.txt

只要跑通这个，说明环境基本OK，后面就可以进入模型转换环节。

3. 模型转换：把ONNX、TFLite格式转成QNN能吃的模型

3.1 支持格式与选择转换器

QNN SDK目前提供几种主要转换器：

• qnn-onnx-converter：处理ONNX模型（会引用onnx和onnxruntime库），主流推荐。
• qnn-tflite-converter：处理TFLite FlatBuffer格式模型。
• 通用QNN模型库构建方法：直接用Graph API从头构造计算图，适合带自定义算子的极端情况，一般很少用。

我的经验是：新项目优先选择ONNX作为中间格式，即便原始训练框架是PyTorch的，也先导出ONNX再转QNN，这样中间环节的排查工具最多、问题最容易定位。

3.2 ONNX转QNN的完整步骤

假设手头有一个PyTorch的YOLOv5s模型，先导出ONNX：

python export.py --weights yolov5s.pt --include onnx --opset 13

然后运行QNN转换器。下面是我常用的命令模板：

qnn-onnx-converter \ --input_network ./yolov5s.onnx \ --output_path ./yolov5s_qnn \ --input_list ./input_list.txt \ --quantization_override ./quantization_config.json \ --backend htp

几个关键参数逐一解释：

• --input_network：输入ONNX文件路径。
• --output_path：QNN输出模型的路径。注意它不仅是单文件，可能生成多个模型文件、配置文件和中间产物目录。
• --input_list：用于校准或推理的输入数据列表，每一行表示一个输入张量的文件路径，格式为二进制或npy。这个文件作用远比想象中大。
• --quantization_override：用JSON配置量化规则，比如指定哪些层用INT16，哪些保留FP16，哪些层强制不量化。QNN模型转换阶段可以直接做权重和激活量化。
• --backend：如果从转换阶段就明确最终运行目标是HTP，就能直接生成更紧凑的HTP模型，同时抑制掉一些只存在于GPU和CPU的算子。

转换完成后，会在output_path目录下看到类似model.qnn、model.qnn.bin、model.serialized.bin的文件。其中model.serialized.bin是把模型结构直接序列化的二进制格式，后续推理主要加载这个文件。

3.3 转换前的模型预处理与算子兼容性检查

QNN对算子的支持情况在SDK文档中有一个算子列表，经常更新。实操中最大的坑是模型里混有自定义算子或太新的算子版本，此时先试着在x86环境用ONNX Runtime加载模型跑一遍，确认onnx模型自身没问题，再转QNN。

几个常踩的问题我列出来：

• opset版本过高：QNN的onnx转换器基于特定onnx版本实现，opset 17以上的新算子不一定全部支持。我一般建议把YOLO系列、分类模型固定到opset 11到13区间，兼容性最稳。
• 动态Shape：QNN虽然支持动态维度，但动态输入会让后续的HTP后端优化大打折扣。转换前尽量固定输入的H/W，常见做法是把batch维固定为1，必要时做resize预处理。
• 不支持的自定义算子：如果模型里用到了如torchvision的NMS这类自定义算子，通常需要在转换前先从图中剥离，或者用非极大值抑制算法改写成ONNX标准算子，再不行就放到后处理阶段用C++或Python实现。

3.4 转换后的验证方式

转换不是终点，转换完首先要做的验证是：

• 用qnn-net-run在CPU后端跑同一组输入，判断输出的张量shape和数值范围是否与onnxruntime一致。
• 对比输出特征图，尤其是最后一层logits。对分类模型可以看top-5类别是否一致；对检测模型则要看检测框是否存在数量级异常。
• 如果数值偏差很小但业务指标明显下降，问题大概率出在量化环节而不在结构转换。

我踩过的最大坑是转换时默认把模型输入端做了NHWC转NCHW的逻辑，而我的预处理脚本是按NCHW写的，最终输入完全乱掉，检测框全跑到图像角落。后来我养成了一个习惯：转换清单里严格写明输入布局，并在转换前后用同一条预处理pipeline做端到端验证，而不是只对比网络输出的张量。

4. 量化：从FP32到INT8的性能关键

4.1 为什么量化能让模型在骁龙平台上更快

量化的本质是降低计算精度和存储位宽。常见做法是把FP32或FP16的权重、激活值转换成INT8甚至INT4来存储和计算。

相比FP32，INT8权重内存占用降低4倍，而且Hexagon DSP的HVX和HTA指令对INT8的乘加吞吐是明显高于FP16和FP32的，这就是为什么同样的网络结构INT8量化后的推理速度往往能翻倍以上的原因。但代价是精度损失，特别是对小型网络、超分辨率、深度估计这类输出敏感的任务，INT8量化后可能出现肉眼可见的质量下降。

理解量化前需要抓两个核心概念：

• 量化比例（scale）和零点（zero point）：把一个浮点范围[min, max]映射到整数范围[-128, 127]，scale和zero point把浮点值和整数值互相转换。
• 校准（calibration）：为了确定激活值的动态范围，需要喂一批有代表性的数据看实际激活分布，然后算出合理的scale和zero point。

4.2 用QNN做训练后量化（PTQ）

QNN的PTQ流程不需要重新训练，只需要准备校准数据集。校准数据集最好尽可能贴近真实应用场景，覆盖光线、物体大小、姿态等典型变化。不要用训练集的原图做校准，因为模型在训练集上过于自信，量化后泛化能力评估容易被带偏。

准备校准数据时，我用Python脚本把图片存成raw二进制或npy：

import cv2 import numpy as np def preprocess(img_path, input_size=(640, 640)): img = cv2.imread(img_path) img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img = cv2.resize(img, input_size) img = img.astype(np.float32) / 255.0 img = img.transpose(2, 0, 1) img = np.expand_dims(img, axis=0) return np.ascontiguousarray(img) with open('input_list.txt', 'w') as f: for i in range(200): arr = preprocess(f'calib/{i:04d}.jpg') arr.tofile(f'calib/{i:04d}.raw') f.write(f'calib/{i:04d}.raw\n')

随后调用量化命令。QNN新版本工具链中，量化通常在转换阶段直接完成：

qnn-onnx-converter \ --input_network ./yolov5s.onnx \ --output_path ./yolov5s_int8 \ --input_list ./input_list.txt \ --quantize_full_type int8 \ --backend htp

如果使用专门的量化工具，也可以像下面这样把模型先转成未量化的中间格式，再做量化：

qnn-converter --model yolov5s.onnx --input_list input_list.txt --quantize_full_type int8 --output_path yolov5s_int8

不同版本工具名和参数存在差异，但思路一致：输入校准数据，统计激活分布，生成量化参数，输出量化后模型。

4.3 量化精度下降时的调优手段

PTQ最常见的痛点是量化后精度掉得厉害。我的排查顺序是：

• 校准集是否够有代表性：校准数据太少（少于100张）会让激活范围估算不准，至少要准备300张以上覆盖典型场景。
• 是否应该用per-channel量化：权重用per-channel会比per-tensor效果好很多，如果你的模型很小，强烈建议开启。
• 哪些层需要提高精度：通过分析各层的激活分布和量化误差，找出敏感层（比如检测头、注意力模块），对这些层设置INT16或FP16保留精度。

QNN的量化配置支持很细，可以用JSON文件覆盖特定层：

{ "quantization_overrides": [ { "tensor_name": "model.24.m.0.cv2.conv.weight", "dtype": "int16", "encoding": { "granularity": "per_channel", "axis": 0 } } ] }

实际操作中发现，混合精度方案通常能解决95%的精度掉点问题，而且性能影响在可控范围。

4.4 量化效果验证与最终模型生成

量化完成后，需要验证量化模型在测试集（而不是校准集）上的指标，并对比原始FP32模型：

• 分类模型关注top-1/top-5准确率差；
• 检测模型关注mAP@0.5和mAP@0.5:0.95；
• 语音模型关注WER；
• 生成模型关注输出质量对比。

如果量化模型的精度与FP32差距小于1%或你业务允许的范围，就可以进入下一步。最终使用中，我通常把模型和量化参数一起放到应用包里，让目标板加载时直接使用量化后的图。

5. 推理部署：加载模型跑一次前向

5.1 QNN推理流程与API结构

QNN推理的核心API概念包括Context、Graph、Tensor和Profile。整体流程是：

1. 加载Backend动态库，创建QnnBackend。
2. 创建QnnContext并配置，比如选择哪个后端设备，设置线程数。
3. 从序列化模型创建Graph（或者直接加载离线context二进制）。
4. 创建输入输出Tensor并绑定内存。
5. 执行QnnGraph_execute，读取结果。

如果用C++ API，代码骨架大致长这样：

#include "QNN/QnnInterface.h" #include "QNN/QnnContext.h" #include "QNN/QnnGraph.h" #include "QNN/QnnTensor.h" // 1. Load backend auto handle = dlopen("libQnnHtp.so", RTLD_NOW); auto qnn_func = dlsym(handle, "QnnInterface_getProviders"); // 2. Setup backend & context const QnnContext_Config_t context_config = { { QNN_CONTEXT_CONFIG_TYPE_RUNTIME, 0 } }; QnnContext_handle_t context = nullptr; qnn_interface->contextCreate(backend, &context_config, &context); // 3. Load graph from binary or create from model QnnGraph_handle_t graph = nullptr; // 4. Setup tensors QnnTensor_handle_t inputTensor; // bind with allocated buffer // 5. Execute qnn_interface->graphExecute(graph, inputTensors, outputTensors, nullptr, nullptr);

实际项目里更推荐使用高通提供的应用程序接口封装层。QNN SDK也提供了Python版本的wrapper，即pyqnn，便于快速验证流程：

import pyqnn model = pyqnn.QnnModel('/path/to/model.serialized.bin', backend='HTP') output = model.infer(input_data)

这套Python接口对验证和调试很有帮助。

5.2 使用离线Context二进制提升启动速度

每次从serialized模型创建Graph是一个比较重的过程，尤其模型较大时，初始化要消耗几百毫秒甚至数秒。所以实际产品中通常不会动态创建图，而是提前在PC端利用QNN工具链生成离线Context二进制文件。

生成命令大致如下：

qnn-context-binary-generator \ --model ./yolov5s_int8.serialized.bin \ --backend libQnnHtp.so \ --output_dir ./context_bins \ --binary_file yolov5s_int8.serialized.bin

生成之后，在板端加载context二进制，推理初始化的时间可以压缩到几十毫秒甚至更低，对实时性要求高的场景非常关键。

5.3 目标板上部署起来要注意哪个动作

板端部署的最小闭环是：把context二进制和HTP后端库拷贝到目标板，在应用里加载libQnnHtp.so和libQnnHtpV*.so系列库，创建上下文并执行推理。

实际操作里最容易出问题的点：

• 库版本不一致：板端和PC端的QNN库要完全同版本，否者context二进制可能无法加载。
• 权限和签名：某些量产板的HTP后端有签名校验，需要走高通的安全签名流程。
• 内存分配：Hexagon上的IO缓冲通常需要对齐到128字节，否则执行会报错或性能下降。QNN的tensor创建接口提供了buffer分配属性，应明确指定。
• DMA缓冲分配：为达到最优性能，输入输出缓冲尽量分配在共享内存或DMA Buffer中，避免CPU与DSP之间拷贝数据。QNN SDK中有示例代码可以参考。

5.4 与TFLite/ONNX Runtime的实测对比

在骁龙888或骁龙8 Gen系列平台上，我用MobileNetV2和YOLOv5s做过对比测试。同款模型、相同输入分辨率，使用QNN INT8在HTP上的推理耗时往往比TFLite CPU快数倍，比GPU快一到数倍，同时单位推理能耗明显更低。

这里要特别提醒，跑分结果非常依赖平台、模型结构、热量限制与CPU频率设置。QNN的优势在INT8量化与HTP组合下最为明显，如果模型结构里大量动态分支、动态shape，优势会被削减很多。

6. 性能分析与调优：用数据说话

6.1 Profiling工具怎么用

QNN SDK提供了性能分析工具和profile机制，可以采集模型每一层的执行时间、访存开销、后端占用率等数据。

启用Profile最简单的方式是在qnn-net-run命令加profile输出选项，例如：

qnn-net-run --backend libQnnHtp.so --model yolov5s_int8.serialized.bin --input_list input_list.txt --profiling_level detailed --output_path profile_output

生成的结果会把每层的耗时、DSP周期、cache miss率等记录下来。

6.2 拿到Profile后怎么看关键指标

重点关注几个信息：

• Layer execution time：找出耗时占比最大的层，通常是Conv和Depthwise Conv。
• Backend computation time vs overhead：如果overhead占比高，说明多数时间花在CPU与DSP数据拷贝上，这时要做算子融合或内存复用优化。
• Graph execution total time：这是业务直接感知的延迟。
• Memory usage：确认输入输出缓冲是否落在DSP可访问的内存区域。

这类数据对模型选型、输入分辨率调整和后端选择都有直接指导意义。

6.3 实际优化案例：把YOLOv5s的推理时间压掉40%

我之前把一个YOLOv5s部署到某骁龙平台上，初始推理延迟约18ms，还不能满足需求。逐层分析发现，耗时主要集中在前几层大分辨率卷积上，且图中有大量Repeat和Reshape节点，DSP上执行效率差。

优化步骤：

• 把输入分辨率从640x640降到512x512，延迟降到约12ms（业务mAP只下降0.2%）。
• 把一些Reshape和Permute操作移到CPU后处理环节，删除图中的纯数据搬运层，延迟进一步降到9ms。
• 开启multi-thread并行和HTP的partition配置，最终稳定在8ms左右。

这个案例说明，QNN性能调优不只是一个工具的事，要结合算法、数据流和硬件特性共同调整。

7. 常见问题与排查技巧实录

7.1 典型报错速查表

7.2 最容易忽视的三个经验性陷阱

第一个是HTP模拟器与真机差异。QNN提供x86平台上的HTP模拟后端，可以让你在PC上验证功能和大致延迟，但模拟器频率、内存带宽、调度策略与真机差别很大。因此性能基准一定要在目标板上测，不能把模拟器数据写进汇报里。

第二个是开发期过度依赖Python接口。pyqnn适合快速验证，但在量产系统里，模型加载、上下文管理、异步执行、多线程调度都需要C++层定制。建议从项目开始就保持C++集成的最小可行Demo同步演进，避免最后接口迁移时手忙脚乱。

第三个是模型更新频繁时量化流程没自动化。量化、校准、验证、生成context二进制这套流程如果纯手工操作，后续模型每迭代一版都要花大量时间重跑。最好把流程固化成CI脚本，模型一更新就自动跑完整链路并输出精度报告，省时且不犯错。

7.3 既然绕不开，就把QNN这套玩透

高通平台的AI部署生态已经非常成熟，QNN作为核心SDK，学习成本确实不高但门槛在于环境调试和细节的把控。环境配置多花点时间确认版本和路径，后续的模型转换和量化就会顺畅很多。

我个人在实际操作中最大的心得是：永远不要跳过模型转换后的端到端验证，很多看似晦涩的推理问题和精度问题，根源只是输入数据管道的某个细节没对齐。先把最小可运行的闭环跑通，再逐步优化性能，这也是我在所有嵌入式AI项目里一直坚持的顺序。

如果你正准备把手头的模型迁移到骁龙平台，建议先拿一个小模型比如MobileNetV2完整跑一遍流程，熟悉每个环节的关键命令和参数，再去碰大模型。这样能降低很多试错成本。后面如果再有人问我QNN部署怎么样，我大概还是会说：这东西文档有点散，版本有点乱，但一旦把手感找到，它在端侧的效率和能效表现确实值得花时间。