Running LLMs on Dragon Q6A NPU - Setup Guide & Questions

Dragon Series Q6A
1

Goal

Run small LLMs (2-3B parameters like Qwen2.5-3B, Phi-3 Mini, Gemma 2B) using the Qualcomm Hexagon NPU for inference acceleration.

What I’ve Done So Far

1. System Installation

  • :white_check_mark: Flashed Armbian to MicroSD card

  • :white_check_mark: Successfully booted with GNOME desktop

  • :white_check_mark: Verified firmware version (251013 - latest)

  • :white_check_mark: System running stable

2. QAIRT SDK Installation

Following the Radxa NPU development guide:

Qualcomm Software Center:

sudo dpkg -i QualcommSoftwareCenter1.17.2.Linux-arm64.deb
sudo apt --fix-broken install -y

QAIRT SDK 2.40.0.251030:

  • Downloaded from GitHub releases (v2.40.0.251030.zip)

  • Extracted to ~/qairt/2.40.0.251030/

  • Verified SDK structure:

    • lib/aarch64-ubuntu-gcc9.4/ contains libQnnHtp.so and NPU backends

    • lib/hexagon-v68/unsigned/ contains libQnnHtpV68Skel.so

    • bin/aarch64-ubuntu-gcc9.4/ contains CLI tools

Environment Configuration: Added to ~/.bashrc:

bash

# QAIRT SDK
export QAIRT_SDK_ROOT=~/qairt/2.40.0.251030
export LD_LIBRARY_PATH=$QAIRT_SDK_ROOT/lib/aarch64-ubuntu-gcc9.4:$LD_LIBRARY_PATH
export PATH=$QAIRT_SDK_ROOT/bin/aarch64-ubuntu-gcc9.4:$PATH

System Library Setup:

bash

sudo mkdir -p /usr/lib/rfsa/adsp/
sudo cp ~/qairt/2.40.0.251030/lib/hexagon-v68/unsigned/libQnnHtpV68Skel.so /usr/lib/rfsa/adsp/

3. QAI AppBuilder Installation

  • :white_check_mark: Downloaded qai_appbuilder-2.28.0-cp312-cp312-linux_aarch64.whl

  • :white_check_mark: Ready to install with: pip3 install qai_appbuilder-2.28.0-cp312-cp312-linux_aarch64.whl

Questions & Need Help

  1. Has anyone successfully run LLMs on Q6A’s NPU? What models work best?

  2. QAI AppBuilder workflow: After installing the Python wheel, what’s the complete process to:

    • Convert a Hugging Face model (e.g., Qwen2.5-3B) to QNN format?

    • Quantize to INT8 for NPU?

    • Run inference using the NPU backend?

  3. Performance expectations: What’s realistic inference speed (tokens/second) for 2-3B models on the Hexagon NPU?

  4. Model recommendations: Which specific models are confirmed working:

    • Qwen2.5-1.8B/3B?

    • Phi-3 Mini?

    • Gemma 2B?

    • MiniCPM 2B?

Reference Resources

1 Like
2

我在 Radxa Dragon Q6A（QCS6490 平台）上尝试部署 Qualcomm 的 QNN Runtime、QAI Hub 模型以及 Genie LLM 应用时，遇到了如下问题和困难，现整理如下，供你们排查与协助：

一、设备与系统环境

  • 设备：Radxa Dragon Q6A

  • SoC：Qualcomm QCS6490 / QC6094

  • 系统：Radxa OS 25.11（基于 Ubuntu/KDE）

  • 内核：6.17.1-3-qcom

  • Python 环境：conda + mamba

  • QNN SDK 版本：2.41.0.251128（Linux AArch64）

我已经正确安装了完整的 QNN SDK，路径为：



~/qnn/qairt/2.41.0.251128

其中包含：



bin/
lib/
include/
examples/
tools/

QNN 工具可以正常运行，例如：



qnn-net-run
qnn-context-binary-generator
qnn-throughput-net-run

二、QNN SDK 多版本工具目录导致使用困难

QNN SDK 的 bin/ 目录下包含多个平台版本：



aarch64-android
aarch64-oe-linux-gcc11.2
aarch64-oe-linux-gcc8.2
aarch64-oe-linux-gcc9.3
aarch64-ubuntu-gcc9.4
x86_64-linux-clang

最终测试发现：

:check_mark: 只有 aarch64-oe-linux-gcc11.2 中的工具可以在 Q6A 上运行
其他平台版本（如 android / ubuntu）均无法在系统环境下运行。

三、QAI Hub 模型访问权限严重受限，无法访问任何 LLM 模型

我已成功使用 qai-hub configure 完成身份验证，但执行：



from qai_hub.client import Client
c = Client()
c.get_models()

只能得到以下两个模型：



Real_ESRGAN_x4plus（两个版本）

无法访问任何 LLM 模型，包括：

  • TinyLlama

  • Phi-3 Mini

  • Phi-3.1

  • LLaMA 3.x 系列

  • Gemma 2B

  • Qualcomm 官方提供的 Distilled LLMs

  • Whisper、TTS 等模型

这导致我无法完成 Qualcomm 官方教程《LLM on Genie》中要求的步骤，因为该教程必须导出一个 LLM 模型（如 tinyllama、phi-3-mini 等）。

尝试运行：



python -m qai_hub_models.models.tinyllama.export

会报错：



ModuleNotFoundError: No module named 'qai_hub_models.models.tinyllama'

说明 QAI Hub 返回的模型列表里根本不包含 TinyLlama，因此无法导出，也无法构建 Genie LLM 的 genie_bundle。

四、Genie LLM 应用无法继续下去

《LLM on Genie》教程要求：

  1. 选择一个 LLM（如 TinyLlama、Phi、Llama、Gemma）

  2. 从 QAI Hub 编译/导出 QNN 模型

  3. 生成 genie_bundle

  4. 在设备上运行 Genie（genie-app）

但由于我的 QAI Hub 账号没有任何 LLM 的访问权限，我无法进行：



--target-runtime qnn_context_binary

从而整个 Genie LLM 教程无法继续。

五、平台侧可能的问题与困惑

我怀疑：

1. QCS6490 / Radxa Q6A 是否本身无法访问 Qualcomm AI Hub 的 LLM 模型？

是否 Qualcomm 控制了 LLM 模型的可见性，导致开发板用户无法看到？

2. Radxa 是否需要向 Qualcomm 申请启用 LLM 模型访问权限？

包括：

  • TinyLlama

  • Phi 系列

  • LLaMA 3.1 / 3.2

  • Gemma

  • Qualcomm Distilled LLM

否则开发者无法使用 Genie、QNN LLM 推理、NPU 测试等关键功能。

六、请求 Radxa 官方协助的问题

我希望 Radxa 能协助确认：

:check_mark: 1. QCS6490 的用户是否可以访问 Qualcomm AI Hub 的 LLM 模型？

是否需要 Radxa 官方去申请“白名单”或“模型访问授权”？

:check_mark: 2. Radxa 是否计划提供针对 QCS6490 的 NPU/HTP 驱动？

否则 QNN 无法使用 HTP，加速 LLM 的功能完全无法体验。

:check_mark: 3. Radxa 能否联系 Qualcomm，确认 Q6A 的 QAI Hub 权限配置？

官方教程明确要求可以访问 LLM 模型，但普通用户账号没有权限。

:check_mark: 4. 是否能提供针对 QCS6490 的官方 Genie LLM 示例？

目前官方教程完全无法执行。

七、我已经验证的内容（可帮助定位问题）

  • QNN SDK 已成功安装

  • QNN 工具可在 aarch64-oe-linux-gcc11.2 正常运行

  • ESRGAN 模型可以导出并推理（pipeline 正常）

  • 只有 LLM 模型访问受限

  • 环境变量、PATH、Python 模块均已正确配置

3

Hi, @Hao_Huang

the QNN SDK is provided by Qualcomm for multiple platforms, and on Radxa devices it must be built with aarch64-oe-linux-gcc 11.2.

There is also a misunderstanding regarding QAI Hub access permissions: the QAI Hub library is tied to your personal account, and it only records the models you yourself have converted through QAI Hub.
So if you have only converted Real_ESRGAN_x4plus, then you will only see those two related models — it is not a public model repository.

Regarding the error ModuleNotFoundError: No module named 'qai_hub_models.models.tinyllama':
please refer to the model list in the documentation QAI Hub Models | Radxa Docs . The TinyLlama model has not yet been added in this version.

best,
Morgan

1 Like
4

I went down exactly the same rabbit hole. :grinning_face_with_smiling_eyes: Spent weeks trying QAIRT, QNN, AI Hub, ExecuTorch, compiled binaries, and even rented a RunPod instance just to verify I wasn’t losing my mind. Nothing worked. I also found it very difficult to follow the Qualcomm documentation as several examples and workflows either didn’t match reality or simply didn’t work as expected.

Finally got Llama 3.2 1B running on the Hexagon NPU using TrailCurrent’s script, and I can also confirm it works on Armbian 26.2.4 (Ubuntu 24.04 LTS), not just the official Radxa OS.

Qualcomm’s AI ecosystem definitely isn’t for the faint-hearted. It feels like solving an escape room before you can run your first prompt. :sweat_smile:

My only remaining disappointment is the apparent 1024-token context window and ~250-token output limit. Is that a limitation of the compiled QAIRT model, Genie, or the backend itself?

The script I used downloads the precompiled binaries from ModelScope:

At least it finally got the NPU working. Hopefully larger context windows become possible in the future.

5

hi, i took the scripts and did the rewrite in rust, if you can you can take this and try to convert a model with more parameters, keep me updated, thanks

6

HI guys. Thank you!! i done solved NPU reset and nou using problems.

# Bug Report: Q6A NPU FastRPC Session Failure (0x80000600) — Firmware-Shell c4/c3 Mismatch

**Target:** [Radxa Forum — Q6A FastRPC Issues]( Collecting Q6A NPU FastRPC Issues )

**Related:** [FASTRPC_IOCTL_INIT_CREATE 0x80000600 on CDSP]( Dragon Q6A FastRPC/NPU fails: FASTRPC_IOCTL_INIT_CREATE returns 0x80000600 on CDSP )

-–

## Environment

| Item | Value |

|------|-------|

| Board | Radxa Dragon Q6A (12GB RAM / 64GB eMMC) |

| SoC | QCS6490 |

| OS | Ubuntu 24.04 Noble (Gnome R2) |

| Kernel | `6.18.2-3-qcom` |

| `radxa-firmware-qcs6490` | **0.2.41** (Aug 19, 2026 build) |

| `fastrpc` / `libcdsprpc1` | **1.0.7-1** |

| QAIRT (apt) | `libqnn1` / `qnn-tools` **v2.46.0** |

-–

## 1. Root Cause (Olof’s Hypothesis — Confirmed)

The `radxa-firmware-qcs6490` package ships a **mismatched pair** of CDSP firmware and FastRPC user-PD shell:

| Component | Path | Version string |

|-----------|------|----------------|

| **CDSP firmware** (remoteproc) | `/lib/firmware/qcom/qcs6490/radxa/dragon-q6a/cdsp.mbn` | `QC_IMAGE_VERSION_STRING=CDSP.HT.2.5.**c4**-00004-KODIAK-1` |

| **FastRPC shell** (user-PD) | `/usr/share/qcom/qcs6490/radxa/dragon-q6a/dsp/cdsp/fastrpc_shell_unsigned_3` | `CDSP.HT.2.5.**c3**-00103.1-KODIAK-1_20251021_220005` |

Both files are installed by the **same** `radxa-firmware-qcs6490` package (`dpkg -L`).

Shell SHA256 (dragon path = `/usr/lib/dsp/cdsp` symlink target):

```

015e4dcb3b7904ddafde57f76fe4d699e6d877366aa312e4f7ca5f3c2627e578

```

Because of this **c4 firmware vs c3 shell** ABI mismatch, unsigned user-PD session creation fails at `FASTRPC_IOCTL_INIT_CREATE` with **`0x80000600`**. This occurs **before** any QNN/skel logic runs.

Downstream cascade (same as forum thread #31078):

```

0x80000600 (FastRPC session)

→ skel load error 1002

→ Transport layer setup failed 14001

→ Device Creation failure (qnn-net-run / HTP-CTX)

```

Filesystem/DSP symlink layout (`/usr/lib/dsp/cdsp` → dragon `cdsp`) was verified correct; failure persists on **cold boot** with clean layout.

-–

## 2. Reproduction Steps

```bash

# After cold boot — remoteproc up, layout OK

cat /sys/class/remoteproc/remoteproc1/state # running

ls -la /usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3

# Version check

strings /lib/firmware/qcom/qcs6490/radxa/dragon-q6a/cdsp.mbn | grep QC_IMAGE_VERSION_STRING

strings /usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3 | grep -m1 CDSP.HT

# FastRPC smoke (fails without any QNN involvement)

export HEXAGON_UNSIGNED_PD=1 CDSP_UNSIGNED_PD_ENABLE=1

export ADSP_LIBRARY_PATH=/usr/lib/dsp/cdsp:/usr/lib/dsp/adsp:/usr/lib/rfsa/adsp

export CDSP_LIBRARY_PATH=$ADSP_LIBRARY_PATH

/usr/bin/fastrpc_test -a v68

# → ERROR 0x80000600 on domain 3, 3 tests FAILED

```

-–

## 3. Diagnostic Logs

### A. `journalctl -b -u cdsprpcd` (cold boot)

```text

remote_handle64_invoke failed, method 5 on domain 3 (sc 0x5000000) → 0x80000600

remotectl1 domains not supported for domain 3

adsp_default_listener: Successfully opened handle … on domain 3 (spawn ~446ms)

```

### B. `dmesg | grep -iE ‘fastrpc|dma|remoteproc’`

```text

remoteproc remoteproc1: Booting fw image qcom/qcs6490/radxa/dragon-q6a/cdsp.mbn, size 3612672

remoteproc remoteproc1: remote processor cdsp is now up

qcom,fastrpc … no reserved DMA memory for FASTRPC

```

(CMA pool present: `CmaTotal: 32768 kB`, `CmaFree: ~21 MB` at time of test.)

### C. `fastrpc_test` output

```text

Allocate 4000 bytes from ION heap

Creating sequence of numbers from 0 to 999

Compute sum on domain 3

Retry attempt unsuccessful. Timing out…

ERROR 0x80000600: Failed to compute sum on domain 3

ERROR 0x80000600: Unable to create FastRPC session on domain 3

RESULT: 3 test(s) FAILED

```

### D. `qnn-net-run` (same root cause)

```text

DspTransport.openSession qnn_open failed, 0x80000600

Failed to load skel, error: 1002

Transport layer setup failed: 14001

Failed to parse platform config: 14001

Device Creation failure

```

-–

## 4. Request to Radxa Team

Please provide **one** of the following as a matched set in `radxa-firmware-qcs6490`:

1. **`fastrpc_shell_unsigned_3` built from `CDSP.HT.2.5.c4`** (matching current `cdsp.mbn`), **or**

2. **`cdsp.mbn` downgraded to `CDSP.HT.2.5.c3`** (matching current shell), **or**

3. A documented, version-locked firmware+shell bundle with a verification script (compare `QC_IMAGE_VERSION_STRING` / build paths).

Without a matched **c4↔c4** or **c3↔c3** pair, Hexagon CDSP user-PD cannot be created on Dragon Q6A under Linux.

-–

## 6. Workaround Applied (2026-09-02) — Plan B SUCCESS

**Scan result:** No `c4` shell on disk. Matched `c3` firmware found:

`/lib/firmware/updates/qcom/qcm6490/cdsp.mbn` → `CDSP.HT.2.5.c3-00103.1-KODIAK-1`

**Steps:**

1. Backup c4 firmware → `/opt/scanlog/backup/cdsp.mbn.c4.bak`

2. Copy c3 `cdsp.mbn` → `/lib/firmware/qcom/qcs6490/radxa/dragon-q6a/cdsp.mbn`

3. **CDSP remoteproc stop/start** (required — reboot alone was insufficient)

4. `fastrpc_test -a v68` → **All applicable tests PASSED** (`Sum = 499500`)

5. `plate_det_htp.bin` / `vehicle_det_htp.bin` → **rc=0**, `.raw` output

**Boot persistence:** `qcom-cdsp-fw-align.service` + `/usr/local/sbin/qcom-cdsp-fw-align.sh`

Deploy: `python JP_LPR_Project_2026/tools/_deploy_c3_fw_align.py`

Scan: `python JP_LPR_Project_2026/tools/scan_c4_shells.py` (on board via `_run_c4_scan_and_fix.py`)

-–

## 5. Additional Notes

- `soc_id` in QNN `htp_ext.json` is `35`; sysfs `/sys/devices/soc0/soc_id` reports `498` on this board — to be re-validated **after** FastRPC passes.

- Full machine diagnostic log: `JP_LPR_Project_2026/tools/pipeline_logs/fastrpc_lowlevel_diag.txt`

- Collector script: `JP_LPR_Project_2026/tools/_fastrpc_lowlevel_diag.py`

-–

*Captured: 2026-09-02 · scanlog.kr