高通QNN部署避坑实录：SDK版本矩阵、HTP上下文、NPU串行锁——官方文档没说的9个坑

黑妹天下第一乖 2026-09-30 13:33:49

如果你在部署高通 NPU 时见过 backend initialization failed，然后翻遍官方文档找不到原因——这篇就是为你写的。

我们在一台搭载 QCS8550 的板子上把 YOLO 系列和 LLM 从 ONNX 一路推到 NPU 跑通，全程踩了不下 20 个坑。这里挑出官方文档确实没写、但一定会卡住你的 9 个，每个都给现象、根因和解决代码。

目录

一、环境与验证平台

先说清楚我们用什么机器跑的，避免"你行我不行"。

项配置
开发机（x86_64）Ubuntu 22.04，16GB RAM
目标设备（验证用）搭载 QCS8550 的板子；另有 QCS6490 平台用于交叉验证
目标设备系统Ubuntu 22.04（AidLux 环境）
QNN SDK2.36（与设备端推理 SDK 版本对齐，这个"对齐"是坑 8）
交叉编译aarch64-ubuntu-gcc9.4 / aarch64-android-clang
模型YOLOv8/v10/v11 系列（检测）、Qwen 系小模型（LLM）

QCS6490 是 6nm、12 TOPS 级的边缘平台；QCS8550 算力更高。两者在工具链上完全一致，差异只在性能数字上，所以本文所有坑在两个平台上都成立。

二、先收下这张命令速查表

从 ONNX 到设备端跑起来，全链路就这四条命令。先有全局观，再看坑。

# ============ 环境变量（每个新 shell 都要 source）============
export QNN_SDK_ROOT=/opt/qcom/aistack/qnn2.36
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

# ============ Step 1: ONNX → QNN 中间模型 ============
# 浮点版（先跑通用这个）
qnn-onnx-converter \
  --input_network yolo11n.onnx \
  --input_dim images 1,3,640,640 \
  --output_path yolo11n_fp32 \
  --model_name yolo11n

# 量化版（要上 NPU 必须用这个）
qnn-onnx-converter \
  --input_network yolo11n.onnx \
  --input_dim images 1,3,640,640 \
  --output_path yolo11n_int8 \
  --input_list calibration_list.txt \
  --act_bw 8 --weight_bw 8

# ============ Step 2: 编译成设备端 .so ============
qnn-model-lib-generator \
  -c yolo11n_int8.cpp \
  -b yolo11n_int8.bin \
  -o model_libs/ \
  -t aarch64-ubuntu-gcc9.4

# ============ Step 3: 生成 Context Binary（性能核心）============
qnn-context-binary-generator \
  --model model_libs/aarch64-ubuntu-gcc9.4/libyolo11n_int8.so \
  --backend $QNN_SDK_ROOT/lib/aarch64-ubuntu-gcc9.4/libQnnHtp.so \
  --binary_file yolo11n_int8.ctx.bin \
  --output_dir ./ctx_out

# ============ Step 4: 设备上推理 ============
adb push ctx_out/yolo11n_int8.ctx.bin /home/aidlux/aidcode/models/

看清楚这四步的产物，这是理解后面所有坑的基础：

步骤产物是什么谁用
1*.cpp + *.bin中间表示（API 调用序列 + 静态数据）给工具链，不是给设备
2lib*.so模型库（含拓扑结构）给工具链/运行时
3*.ctx.bin序列化上下文，针对 HTP 优化过设备端实际加载的就是它
4—设备上加载 ctx.bin 推理你的业务代码

记住一句话：设备上跑的从来不是 ONNX，也不是 .so，而是 .ctx.bin。

坑 1：QNN 的版本矩阵——90% 的"初始化失败"都是它

现象

[ERROR] Failed to initialize QnnBackend
[ERROR] backend initialization failed

就这一行。没有版本提示，没有缺哪个库，什么线索都没有。

根因

QNN 生态由四类组件构成，它们之间有严格的版本依赖规则，而且规则不是对称的：

组件作用兼容规则
后端运行时（libQnnHtp.so 等）四种计算单元的实现向下兼容 2 个 minor 版本
模型接口（libQnnModel*.so）模型封装层严格匹配，差一个 minor 就不行
Op 包接口自定义算子向上兼容
系统接口库（libQnnSystem.so）上下文缓存与恢复随 SDK 版本走

你踩的坑通常是这个组合：

用 SDK 2.14 生成的模型接口，去跑 2.12 的后端 → 模型接口版本高于后端运行时 → 直接失败。
报错信息不会告诉你原因，只会说 backend initialization failed。

解决

# 第一步永远是核对版本，而不是瞎改参数
echo "SDK 版本: $QNN_SDK_ROOT"
ls -l $QNN_SDK_ROOT/lib/*/libQnnHtp.so
strings $QNN_SDK_ROOT/lib/x86_64-linux-clang/libQnnHtp.so | grep -i "version" | head -20

# 设备端也要查（如果是 AidLux/AidLite 环境）
python3 -c "import aidlite; print(aidlite.get_library_version())"
python3 -c "import aidlite; print(aidlite.get_py_library_version())"

最稳的做法：转换、编译、生成 context、设备端推理，全部用同一个 SDK 版本。

一条经验法则：当必须混用版本时，让模型接口版本 ≤ 后端运行时版本。这是唯一安全的方向。

💡 我见过最省时间的调试方式，就是在项目 README 第一行写上"本项目使用 QNN x.xx.x"。团队多人协作时，这一行能省下几十小时的排查。

坑 2：HTP 后端只吃量化模型，还要额外的 context binary

现象

浮点模型在 CPU 后端跑得好好的，一切到 HTP：

[ERROR] QnnHtp backend requires quantized model

或者跑起来了但速度和不加速差不多。

根因

HTP（Hexagon Tensor Processor）是专用张量处理器，只接受量化模型。而且它还需要一个额外步骤：把图序列化成 context binary。

这两个前提任何一个缺失都不会有明显报错，最容易的情况是"静默降级"——你以为在用 NPU，其实在跑 CPU。

解决

# ① 转换时必须给校准集，才会发生量化
qnn-onnx-converter \
  --input_network yolo11n.onnx \
  --input_dim images 1,3,640,640 \
  --output_path yolo11n_int8 \
  --input_list calibration_list.txt \
  --act_bw 8 \
  --weight_bw 8

# ② 必须生成 context binary
qnn-context-binary-generator \
  --model model_libs/aarch64-ubuntu-gcc9.4/libyolo11n_int8.so \
  --backend $QNN_SDK_ROOT/lib/aarch64-ubuntu-gcc9.4/libQnnHtp.so \
  --binary_file yolo11n_int8.ctx.bin \
  --output_dir ./ctx_out

怎么确认真的在跑 NPU？

别信日志，看速度和精度：

后端预期延迟（YOLO 类模型，QCS6490）
CPU200~400ms
GPU100~200ms
HTP/NPU（量化后）10~60ms

如果你的量化模型跑出来还是 200ms 以上，那基本可以确定没走 HTP。 回去查坑 1、坑 4。

坑 3：libQnnHtp.so 失败时，换 libQnnDsp.so 再试

现象

所有配置都对，但加载 HTP 后端就是失败。

根因

不同 QNN 版本的后端库名不统一。 常见的有：

  • libQnnHtp.so
  • libQnnDsp.so
  • （不同 SDK 版本混用时会看到两种都存在）

解决

# 列出这个 SDK 到底提供了哪些后端
ls $QNN_SDK_ROOT/lib/aarch64-ubuntu-gcc9.4/libQnn*.so

# 典型输出：
#   libQnnCpu.so      ← CPU
#   libQnnGpu.so      ← GPU
#   libQnnHtp.so      ← HTP（NPU）
#   libQnnDsp.so      ← DSP（同一硬件，旧命名）
#   libQnnSystem.so   ← 系统接口

如果 libQnnHtp.so 报错，直接换 libQnnDsp.so 试一次。同一个 NPU 硬件，不同版本的命名不同，功能一致。

qnn-context-binary-generator \
  --model model_libs/.../libyolo11n_int8.so \
  --backend $QNN_SDK_ROOT/lib/aarch64-ubuntu-gcc9.4/libQnnDsp.so \
  --binary_file yolo11n_int8.ctx.bin \
  --output_dir ./ctx_out

⚠️ 注意：换后端库时必须重新生成 context binary。ctx.bin 是绑定后端的，不能跨后端复用。

坑 4：LD_LIBRARY_PATH 不设，加载到的是系统同名库

现象

x86 开发机上 qnn-net-run 报找不到符号，或者行为诡异。

根因

Linux 动态库加载顺序取决于 LD_LIBRARY_PATH 的顺序。系统里可能已经装了同名的库（比如别的 AI 框架带的），优先加载到了错误的那一份。

这个坑在装了多个 AI 框架的机器上必踩。

解决

# ❌ 错误写法：追加到后面
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$QNN_SDK_ROOT/lib/x86_64-linux-clang

# ✅ 正确写法：QNN 的路径放最前面
export LD_LIBRARY_PATH=$QNN_SDK_ROOT/lib/x86_64-linux-clang:$LD_LIBRARY_PATH

验证加载的到底是哪一个：

ldd $(which qnn-net-run) | grep Qnn
# 输出会显示实际加载路径，确认是 $QNN_SDK_ROOT 下的

# 直接查某个 .so 的依赖
ldd $QNN_SDK_ROOT/bin/x86_64-linux-clang/qnn-net-run | head -30

顺带一个验证结果形状的小技巧（在 PC 端先验证，避免在设备上瞎猜）：

qnn-net-run \
  --model model_libs/x86_64-linux-clang/libyolo11n_int8.so \
  --backend $QNN_SDK_ROOT/lib/x86_64-linux-clang/libQnnHtp.so \
  --input_list raw_list.txt \
  --output_dir ./output

# YOLO 检测模型输出形状通常为 [1, 8400, 84]（或 split 成两个输出）
# 形状不对 → 回去看坑 7

坑 5：--input_list 不给，量化根本没发生

现象

转换命令跑完了，没有任何报错。丢到 NPU 上跑，精度崩了，或者干脆报"未量化"。

根因

qnn-onnx-converter 只有在你提供 --input_list 时才会执行量化。不给就默认输出浮点模型，但文件名你想叫 int8 也能叫 int8——于是你以为量化了，其实没有。

解决

# calibration_list.txt 的格式：每行是「raw 输入文件路径 + 输入维度」
# 注意：是裸二进制 .raw，不是 jpg/png！
./calib/input_0000.raw images 1,3,640,640
./calib/input_0001.raw images 1,3,640,640
./calib/input_0002.raw images 1,3,640,640

生成校准数据：

# make_calibration.py
import numpy as np
from pathlib import Path
import cv2

def make_raw_bin(img_path: str, out_path: str, shape=(1, 3, 640, 640), layout="nhwc"):
    """把图片转成 QNN 校准用的裸二进制"""
    img = cv2.imread(img_path)
    img = cv2.resize(img, (shape[2], shape[3]))
    img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB).astype(np.float32) / 255.0
    img = np.expand_dims(img, axis=0)          # [1, 640, 640, 3]

    if layout == "nchw":
        img = img.transpose(0, 3, 1, 2)        # [1, 3, 640, 640]

    Path(out_path).parent.mkdir(parents=True, exist_ok=True)
    img.astype(np.float32).tofile(out_path)
    print(f"{out_path}  shape={img.shape}")

if __name__ == "__main__":
    # 建议 100~500 张，覆盖你的真实场景分布
    imgs = list(Path("./calib_imgs").glob("*.jpg"))
    with open("calibration_list.txt", "w") as f:
        for i, p in enumerate(imgs):
            out = f"./calib/input_{i:04d}.raw"
            make_raw_bin(str(p), out)
            f.write(f"{out} images 1,3,640,640\n")
    print(f"共生成 {len(imgs)} 条校准数据")

校准集的质量直接决定量化后的精度：

校准集问题后果
数量太少（< 20 张）量化区间估计不准，精度崩
分布单一（全是白天）夜间场景精度骤降
预处理不一致量化参数错位，全面崩

建议 100~500 张，且必须覆盖你真实部署的场景分布。

坑 6：交叉编译的 -t 参数选错，.so 在设备上跑不起来

现象

设备上报：

cannot open shared object file
Exec format error

根因

qnn-model-lib-generator 的 -t 参数指定目标平台的 ABI。选错就是编译出了一个跑不起来的二进制。

而且它默认会为所有目标都编译一遍，你如果没注意输出目录里到底是哪个，很容易 push 错文件。

解决

# 常用 -t 取值
#   aarch64-ubuntu-gcc7.5    → Ubuntu 18.04 类系统（如 RB5）
#   aarch64-ubuntu-gcc9.4    → Ubuntu 20.04/22.04 类系统
#   aarch64-android          → Android 设备
#   aarch64-android-clang    → Android + clang 工具链
#   x86_64-linux-clang       → PC 端验证用
#   arm-android              → 32 位 Android（少用）

qnn-model-lib-generator \
  -c yolo11n_int8.cpp \
  -b yolo11n_int8.bin \
  -o model_libs/ \
  -t aarch64-ubuntu-gcc9.4

在设备上确认架构是否匹配：

# 设备上执行
file libyolo11n_int8.so
# 期望：ELF 64-bit LSB shared object, ARM aarch64, ...

# 确认设备 glibc 版本（决定 gcc7.5 还是 gcc9.4）
ldd --version

glibc 版本对应关系（经验值）：

设备 glibc建议 -t
2.27 及以下aarch64-ubuntu-gcc7.5
2.31 ~ 2.35aarch64-ubuntu-gcc9.4
Androidaarch64-android-clang

坑 7：AIMO 转换时输出节点填错，模型"能转不能跑"

现象

用图形化转换工具（如 AIMO）转换成功，拿到 .aidem 模型文件，加载后：

  • 输出张量数量不对
  • 或者后处理代码崩在 reshape

根因

YOLO 类模型的输出结构在 ONNX 里经常是被拆散的。以 YOLOv11 为例，最终输出节点往往由 Mul 和 Sigmoid 两个节点 Concat 而成。如果你只填了其中一个的输出名，转换出来的模型就少一半输出。

解决（AIMO 操作步骤）

Step 1  选择「模型优化」，模型格式选 onnx，上传模型
Step 2  选择芯片型号 + 目标框架（例如 QCS8550 + Qnn2.31）
Step 3  点「查看模型」，用 Netron 打开模型结构
        →  找到 output 节点，由 Mul 和 Sigmoid 两个节点 Concat 而成
        →  分别点击两个节点，复制各自的 OUTPUTS name
        →  粘贴到转换表单的输出节点栏（两个都要填）
        →  开启量化，数据精度选 int8，开启自动量化
Step 4  提交，转换完成后下载，解压得到 .bin / .aidem 模型文件

转换前先在 Python 里把输出节点确认清楚：

# check_outputs.py
import onnx

model = onnx.load("yolo11n.onnx")
graph = model.graph

print("=== 图的最终输出 ===")
for out in graph.output:
    print(f"  name={out.name}  shape={[d.dim_value for d in out.type.tensor_type.shape.dim]}")

print("\n=== 所有候选输出节点（无下游消费者）===")
consumed = set()
for node in graph.node:
    consumed.update(node.input)
for node in graph.node:
    for o in node.output:
        if o not in consumed:
            print(f"  {node.op_type:12s} -> {o}")

这个脚本能帮你一眼看出该填哪几个节点。YOLOv11 常见的是两个输出节点，YOLOv10 是 split 布局的 [1,4,8400] + [1,80,8400]。

坑 8：推理 SDK 版本与转换时的 QNN 版本必须对齐

现象

模型转换时选了 Qnn2.31，设备上装的却是别的版本，加载时报错或行为异常。

根因

设备端的推理 SDK（如封装 QNN 的统一推理框架）内部绑定特定 QNN 版本。转换时用的 QNN 版本必须与设备端 SDK 的版本一致。

解决

# 设备上先查装了什么
sudo aid-pkg installed | grep aidlite

# 返回类似：aidlite-qnn231  → 对应 QNN 2.31
# 那你的模型就必须用 QNN 2.31 转换

# 如果没有，或版本不对：
sudo aid-pkg update
sudo aid-pkg install aidlite-sdk
sudo aid-pkg install aidlite            # 装最新版（对应最新 QNN 版本）

# 装指定版本（关键）
sudo aid-pkg install aidlite-{QNN版本}   # 例如 aidlite-231

版本对照表（务必核对）：

设备端 SDK 包名对应 QNN 版本转换时的后端选择
aidlite-qnn2292.29Qnn2.29
aidlite-qnn2312.31Qnn2.31
aidlite-qnn2362.36Qnn2.36

校验命令：

python3 -c "import aidlite; print(aidlite.get_library_version())"

这一步必须在转换模型之前做。 先查设备、再转模型，顺序反了就是白转。

坑 9：NPU 是串行的——并发调用必然 429

现象

单线程跑得好好的。一上多线程/多 Agent 并发：

HTTP 429 Too Many Requests

或者延迟从 50ms 飙到 3s。

根因

NPU 的推理是串行执行的。它不像 CPU 可以多核并行，多个请求打进来只能在硬件层面排队。

这个特性会引发两个连锁问题：

  1. 排队延迟叠加：8 个并发请求，每个 50ms，最后一个要等 350ms
  2. 上层误判为限流：如果走的是 HTTP 服务封装（不少端侧推理服务是这么做的），排队会被转成 429

解决：在应用层加全局串行锁，主动排队

# npu_lock.py
import asyncio
import logging
import httpx

logger = logging.getLogger(__name__)

# 全局 NPU 串行锁：同一时刻只允许一个请求进入 NPU
_NPU_LOCK = asyncio.Lock()


async def call_npu(prompt: str, endpoint: str = "http://127.0.0.1:8910/v1/chat/completions"):
    """
    所有 NPU 调用都从这里走。
    用全局锁主动排队，避免并发打到硬件层再被动 429。
    """
    async with _NPU_LOCK:                       # ← 关键：串行化
        for attempt in range(3):
            try:
                async with httpx.AsyncClient(timeout=120.0) as client:
                    resp = await client.post(
                        endpoint,
                        json={
                            "messages": [{"role": "user", "content": prompt}],
                            "size": 1024,
                            "temp": 0.7,
                        },
                    )
                    resp.raise_for_status()
                    return resp.json()["choices"][0]["message"]["content"].strip()

            except httpx.HTTPStatusError as e:
                if e.response.status_code == 429:
                    wait = (attempt + 1) * 2      # 2s / 4s / 6s 退避
                    logger.warning("NPU 429，%ss 后重试（第 %d 次）", wait, attempt + 1)
                    await asyncio.sleep(wait)
                    continue
                raise
        return ""

两个必须注意的细节：

# ❌ 错误：在 async 函数里用同步 HTTP，会阻塞事件循环
import requests
resp = requests.post(url, json=data)       # 整个服务卡住

# ✅ 正确：用异步客户端
async with httpx.AsyncClient() as client:
    resp = await client.post(url, json=data)

如果你用 FastAPI 这类全异步框架，_NPU_LOCK 必须是模块级全局变量。每个请求里新建锁等于没锁。

# ❌ 错误：锁的作用域错了，等于并发
async def handler():
    lock = asyncio.Lock()        # 每次请求都新建，锁了个寂寞
    async with lock:
        ...

# ✅ 正确
_NPU_LOCK = asyncio.Lock()       # 模块级

async def handler():
    async with _NPU_LOCK:
        ...

补充：还有几个同类的"静默坑"

现象根因解决
自定义角色/系统提示词失效，模型回答"我是通用助手"部分端侧推理服务的 prompt 模板会覆盖或忽略 system 字段把角色指令拼到 user 内容开头，不依赖 system 字段
脚本报找不到模型/图片示例脚本默认用相对路径在解压包根目录执行，或传绝对路径
mms get 下载失败需要先登录先 mms login 再 mms get

附：一个真实的时间账

把上面的坑都趟完之后，我们在两类模型上拿到的实测数字（QCS8550 平台，INT8 量化，HTP/NPU 后端）：

视觉模型

模型输入后端延迟
YOLOv5s640×640ONNX Runtime（CPU）~300ms
YOLOv5s640×640TFLite~200ms
YOLOv5s640×640QNN / NPU（INT8）~1.6ms
YOLOv10n640×640QNN / NPU（INT8）~50ms（含前后处理）

1.6ms 是纯推理耗时（多次调用的平均值，方差约 0.06ms），不含前后处理。ONNX 和 TFLite 那两个数是端到端。对比时要注意口径。

加速比速览

ONNX Runtime  ████████████████████████████████ 300ms
TFLite        ████████████████████████ 200ms
QNN / NPU     █ 1.6ms  ← 快两个数量级

这就是为什么值得趟这些坑。 从 300ms 到 1.6ms，不是优化，是换了一个世界——原来只能做"检测后画框"，现在可以做实时视频流。

总结

9 个坑，按"会卡你多久"排序：

#坑卡人程度一句话解法
1版本矩阵🔴🔴🔴🔴🔴全链路用同一 SDK 版本；必须混用时模型接口 ≤ 后端
5量化没发生🔴🔴🔴🔴不给 --input_list 就不会量化
8推理 SDK 与转换版本不匹配🔴🔴🔴🔴先查设备版本，再转模型
2HTP 要量化模型 + context🔴🔴🔴两个前提缺一不可，缺了会静默降级
9NPU 串行🔴🔴🔴应用层加全局锁，主动排队
7输出节点填错🔴🔴用脚本先列出所有候选输出节点
6交叉编译 -t 选错🔴🔴按 glibc 版本选，设备上 file 验一下
4LD_LIBRARY_PATH 顺序🔴🔴QNN 路径放最前，ldd 验证
3后端库名差异🔴HTP 失败就换 DSP 试

三条通用心法：

  1. 先查版本，再改参数。90% 的诡异报错都是版本问题，报错信息永远不会告诉你这一点。
  2. 别信日志，信延迟。端侧部署最大的陷阱是"静默降级"——代码没报错，但根本没走 NPU。用延迟数字来判断。
  3. PC 端先验证，再上设备。qnn-net-run 在 x86 上就能验证模型正确性，别把调试成本花在板子上。

参考

  • Qualcomm AI Engine Direct (QNN) SDK 官方文档
  • Qualcomm Innovation Developer Kit (QIDK) 示例工程
  • YOLOv8 移植到高通 RB5 平台的技术资料
  • 端侧推理 SDK 版本兼容性实践记录（QCS6490 / QCS8550 平台）

数据说明：文中延迟数据来自 QCS8550 / QCS6490 平台实测，具体数值受模型、量化精度、散热条件影响，仅供量级参考。不同 QNN 版本的工具参数可能有差异，请以你所用版本的 --help 输出为准。

如果这 9 个坑帮你省下了几个小时，点个赞让更多做高通端侧的同学看到。评论区聊聊你踩过最离谱的一个坑是什么——我猜版本矩阵能排第一。

...全文
34 回复 打赏 收藏 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
避坑指南：高通QNN工具链性能分析常见问题解决方案（含qnn-net-run错误排查）
本文为开发者提供了在高通平台上进行大模型性能分析的完整避坑指南。针对使用QNN工具链时常见的qnn-net-run数据获取失败、profiling级别选择不当、性能数据解析错误以及系统级瓶颈定位等问题，给出了详细的排查步骤与实战解决方案，帮助工程师高效释放硬件潜能。
高通端侧AI实战(1): 高通端侧AI全景解析与QNN SDK实战入门
摘要：高通端侧AI技术栈解析 2025-2026年端侧AI成为移动与嵌入式领域核心技术。相比云端推理，端侧AI具备低延迟（5-50ms）、强隐私（数据不出设备）、离线可用等优势。高通通过Hexagon NPU异构架构（HTA/HVX/Scalar三级计算单元）和QNN SDK构建成熟生态，支持从手机（骁龙8 Elite 75TOPS）到车载（SA8295P）等多平台。QNN SDK提供统一接口，支持模型跨NPU/GPU/CPU部署，典型流程包括模型转换（PyTorch→ONNX→QNN）、量化优化和离线编译
yolov11_obb在高通QCS6490上的QNN部署实战：从ONNX到HTP的完整流程
在边缘计算与端侧AI部署场景中，如何将旋转目标检测模型高效迁移到专用NPU平台是工程落地的重要课题。传统水平框检测仅需回归中心点与宽高，而OBB检测引入了角度参数，使得模型输出、解码逻辑与NMS算法均需重新设计。高通QCS6490平台内置Hexagon张量处理器（HTP），通过QNN SDK工具链可实现从ONNX到INT8量化context binary的完整转换。借助QNN的模型转换器与context binary生成器，能够将YOLOv11-OBB模型部署到HTP上运行，并利用CPU完成旋转NMS后处理
Android本地跑LLaMA-7B：QNN框架部署实战与避坑指南
边缘计算与端侧智能正在改变AI应用形态，大模型不再局限于云端。高通QNN框架作为芯片NPU的调度中枢，能高效调用Hexagon DSP的算力，为移动端大模型推理提供了新路径。通过INT4量化，7B参数模型可压缩至3GB左右，配合8GB以上运存手机即可落地。从PyTorch导出ONNX，再用qnn-onnx-converter转换为QNN模型库，最后集成到Android工程，整个链路虽有诸多陷阱，但实测骁龙8 Gen2上可达每秒7个token，满足实时对话需求。这一方案在离线助手、隐私计算、低延迟交互等场景价
高通开发者论坛

7,745

社区成员

6,466

社区内容

发帖
与我相关
我的任务
社区描述
本论坛以AI、IoT、PC 、XR、Auto等核心板块组成，为开发者提供便捷及高效的学习和交流平台。 高通开发者专区主页：https://qualcomm.csdn.net/
物联网人工智能开源 企业社区 北京·东城区
社区管理员
  • csdnsqst0050
  • chipseeker
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章