ailia LLM NPU（QNN）ガイド

概要

ailia LLM 1.5.0 以降は Qualcomm SoC の NPU（Hexagon）を使用した高速推論に対応しています。NPU 向けには、llama.cpp とは異なるアイリア社独自の実装を搭載しています。

NPU を使用することで、高速・低消費電力に LLM を実行可能です。テキストの LLM だけでなく、画像を入力する VLM（Vision Language Model）や音声入力にも対応し、NPU で処理できます。また、Snapdragon 7s など、ミドルレンジの端末でも Gemma 4 E2B や E4B を実行可能です。

実測値では、Android 端末上で Prefill を最大 4.2 倍高速化し、Prefill 中の CPU 使用率を 1/30 以下に抑えられます（Snapdragon 8+ Gen 1、2,048 トークン入力時の同端末 CPU 比）。

QNN（Qualcomm AI Engine Direct）は Qualcomm が提供するバックエンド API です。ailia LLM では、llama.cpp のモデル形式である GGUF を、QNN で実行可能な形式に変換することで、NPU での推論を実現しています。

他の手法との比較

Android の Qualcomm SoC で LLM を実行する主な手法と ailia LLM の比較です。ailia LLM は NPU を使用でき、Gemma 4 を NPU で実行でき、Hexagon v69 以降の比較的古い SoC にも対応します。

対応プラットフォーム

• Android（Hexagon v69 以降。Snapdragon 8 Gen 1 / 8+ Gen 1、7s Gen 3、8 Gen 2 以降など）
• Experimental: QCS6490（Hexagon v68、E2B のみ）

ワークフロー

GGUF を PC 上で QNN Model に変換し、変換済みの QNN Model を端末上の ailia LLM で実行します。端末側では GGUF は不要で、QNN Model のみを配置します。

QNN Model は Prefill 用の固定長グラフ（AR-N）と Decode 用のグラフ（AR-1）を同じ QNN Context に格納し、重みと KV キャッシュを共有します。重みは変換時に 4bit（W4）に量子化され、FP16 モデルでは活性値と KV キャッシュは FP16 で処理されます。

ailia LLM Compiler は FP16 と Int16 の両方に対応しており、対象の SoC に応じて変換時に切り替えられます。Snapdragon 7s Gen 3 の NPU は Hexagon v73 ですが、FP16 に対応していないため、ailia LLM では Int16 に量子化したモデルを使用します。Qualcomm の Snapdragon 7s Gen 3 製品資料（PDF、2 ページの Artificial Intelligence）では、NPU の対応精度として INT4、INT8、INT16 が記載されており、FP16 は含まれていません。Hexagon のバージョンだけでなく、SoC ごとの対応精度に合わせてモデルを選択してください。

対応モデル

現在は Gemma 4 E2B と Gemma 4 E4B（いずれもテキスト・画像・音声入力）に対応しています。画像・音声入力では、テキスト用の QNN Model に加えて、画像 / 音声エンコーダ（mmproj）の QNN Model を使用します。対応するモデルは SoC の Hexagon バージョンによって異なります。

QNN Model はモデルと Snapdragon の機種（SoC）ごとに別ファイルになります。変換済みのモデルファイルを提供していますので、対象端末の SoC に対応したファイルをご利用ください。

モデルのダウンロード

変換済みの Gemma 4 の QNN Model は下記からダウンロードできます。VLM / 音声入力を使用する場合は、テキストモデルと mmproj の両方をダウンロードしてください。E4B は Hexagon v73 以降のみ対応です。

いずれも ailia LLM 1.5.0（QAIRT 2.47.0.260601）向けで、コンテキスト長は 8192、AR-256 / AR-1 構成です。

使用方法

Android への組み込み

libailia_llm.so に加えて、libailia_llm_qnn.so をアプリケーションの jniLibs/arm64-v8a に同梱します。アプリ側がロードするのは libailia_llm.so のみで、QNN Model を開いたときにだけ libailia_llm_qnn.so がプラグインとして遅延ロードされます。

libcdsprpc.so の使用を AndroidManifest.xml に記載する必要があります。また、NPU 側のライブラリ（libQnnHtpV*Skel.so）をファイルシステム経由で参照するため、extractNativeLibs を有効にします。

<application android:extractNativeLibs="true" ...>
    <uses-native-library android:name="libcdsprpc.so" android:required="false"/>
</application>

build.gradle に下記を追加すると、QNN ランタイムが自動的に apk に同梱されます。

implementation 'com.qualcomm.qti:qnn-runtime:2.47.0'

QNN Model の読み込み

QNN Model（.qnn）は GGUF と同じモデル読み込み API に渡します。コンテキスト長に 0 を指定すると、QNN Model に埋め込まれた固定のコンテキスト長が使用されます。画像・音声入力を使用する場合は、テキストモデルを開いた後に mmproj の QNN Model をプロジェクタとして開きます。

#include "ailia_llm.h"
struct AILIALLM *llm = nullptr;
ailiaLLMCreate(&llm);
ailiaLLMOpenModelFileA(llm, "gemma4-e2b-sm8475.qnn", /*ctx_size=*/0);
ailiaLLMOpenMultimodalProjectorFileA(llm, "gemma4-e2b-sm8475-mmproj.qnn"); // 画像・音声入力のみ
// 以降は GGUF と同じ prompt / generate API を使用します
ailiaLLMDestroy(llm);

Kotlin（JNI）でも同様に、GGUF のパスの代わりに QNN Model のパスを渡します。

val llm = AiliaLLM()
llm.openModelFile(qnnModelPath, 0)            // n_ctx=0 で QNN Model 内の固定長を使用
llm.openMultimodalProjectorFile(mmprojQnnPath) // 画像・音声入力のみ

評価版アプリ

Android 向けの評価版 apk は下記からダウンロードできます。QNN 対応版は ailia-models-kotlin-qnn.apk です。

https://github.com/ailia-ai/ailia-models-kotlin/releases/tag/v260927

アーキテクチャ

ailia LLM は QNN Model を mmap で読み込み、QNN Context を復元して Hexagon NPU（HTP）上で実行します。Prefill は固定長の AR-N グラフで処理し、プロンプトが AR の倍数でない場合は最後のスライスをパディングします。Decode は同じ Context 内の AR-1 グラフで処理し、Prefill 後の KV キャッシュのコピーは発生しません。VLM では画像のパッチ化と位置埋め込みを CPU で行い、16 層の Vision Transformer からプーリング、プロジェクションまでを 1 つの QNN グラフで実行します。音声入力には Audio グラフを使用し、音声エンコーダを NPU で実行します。また、層別トークン埋め込み（PLE）のフロントエンドも各 Transformer グラフ内で実行し、CPU 側にはトークン行の参照とメディア埋め込みの差し替えのみを残しています。これにより、入力処理を CPU で行う場合に比べて Int16 モデルの Prefill が改善します。

ベンチマーク

Gemma 4 を 2 機種で測定した結果です。Snapdragon 8+ Gen 1（SM8475 / Hexagon v69）は E2B の FP16 モデル、Snapdragon 7s Gen 3（SM7635 / Hexagon v73）は E2B / E4B の Int16 モデルを使用しています。いずれも QAIRT 2.47、コンテキスト長 8192、AR-256 / AR-1 構成です。

CPU は同じ端末上で、同一の Q4_0 GGUF を標準の llama.cpp 経路で実行した値です（デコーダワーカー 8、コンテキスト 8192）。出荷構成は OpenMP 無効のビルドで、表の「CPU」がこれにあたります。「CPU（OpenMP）」は GGML_OPENMP=ON / OMP_NUM_THREADS=2 でビルドした比較用の構成です。

Decode スループット

81 トークン入力・1,000 トークン生成時のスループットです。

SM7635 の E2B では NPU の Decode が CPU より 1.10 倍（OpenMP ビルド比では 1.53 倍）高速です。一方、SM8475 の E2B（0.81 倍）と SM7635 の E4B（0.93 倍）では CPU を下回ります。Decode は 1 トークンずつ処理するため重みの読み出しが支配的になり、NPU の並列演算性能を活かしにくいためです。

Prefill スループット

入力トークン数を 64〜2,048 まで変えたときのスループット（tokens/s）です。2 トークンのウォームアップ後、評価を伴わない SetPrompt を 2 回呼んで KV キャッシュを消去し、各入力長で 1 トークンだけ生成しています。

• Prefill のスループットは 実入力トークン数 / 最初の生成呼び出し時間 です。
• 2,048 トークン入力では、SM8475 の E2B で CPU より約 4.21 倍高速（OpenMP ビルド比 5.87 倍高速）、SM7635 の E2B で約 2.20 倍高速（同 2.32 倍高速）、E4B で約 1.29 倍高速（同 1.44 倍高速）です。
• 64 トークンのような短い入力では、固定長の AR-256 グラフでパディングが大きくなるため NPU が不利になります。

Prefill 中の CPU 使用率

2,048 トークン Prefill における、最初の生成呼び出し前後のプロセス CPU 時間です。8 コアすべてを使い切った状態を 100% として表しています。アプリケーションプロセスの使用率であり、端末全体の使用率ではありません。

NPU では Prefill 中の CPU 使用率が 3% 前後に収まるため、アプリケーション側の処理に CPU を残せます。CPU 実行では 8 コアをほぼ使い切るため、発熱と他処理への影響が大きくなります。

VLM（画像入力）の応答時間

同一の 768x768 画像 10 枚、各 100 トークン出力での中央値です。TTFT は画像エンコーダを含むプロンプト設定と最初の生成呼び出しの合計で、モデルのオープンは含みません。

画像入力の TTFT は、SM8475 の E2B で約 12.7 倍、SM7635 の E2B で約 11.4 倍、E4B で約 7.7 倍高速です。CPU と NPU はいずれも同じ 768x768 の画素と 256 個の画像埋め込みを処理しています。

音声入力の応答時間

FLEURS の 10 録音（5 言語 各 2 件、自然な EOS まで生成し上限 256 トークン）の中央値です。TTFT は音声エンコーダを含むプロンプト設定と最初の生成呼び出しの合計で、モデルのオープンは含みません。

音声入力の TTFT は、SM8475 の E2B で約 9.2 倍、SM7635 の E2B で約 6.8 倍、E4B で約 7.3 倍高速です。

メモリ使用量

E2B は SM7635（Hexagon v73）で、LLM / VLM / ALM の各構成を 8 トークン生成で実行したときのメモリ使用量です（単位 MiB、コンテキスト長 8192）。CPU は Q4_0 GGUF と BF16 の mmproj、NPU は Int16 の QNN Model を使用しています。モデルは mmap で読み込むため、実際に確保した作業メモリである匿名メモリ（RssAnon）と、ページキャッシュとして再利用できるファイルマッピング（RssFile）を分けて記載します。ピークはプロセスの最大常駐サイズ（VmHWM）です。

• 匿名メモリは NPU が CPU の 4 分の 1 前後です（LLM 0.25 倍、VLM 0.27 倍、ALM 0.23 倍）。ピーク常駐でも 0.36〜0.45 倍に収まります。
• CPU はモデルを開いた時点で全重みを展開するため 4,690.4 MiB を確保しますが、NPU は 98.4 MiB で開き、最初の生成でコンパイル済みのコンテキストを読み込みます。モデルを開いてから最初の生成までの占有は 1/48 程度です。
• モデルを破棄すると CPU / NPU とも 87 MiB 前後まで戻ります。mallopt(M_PURGE, 0) を呼ぶと 23 MiB 前後になります。
• NPU の値はプロセスから見えた分であり、DSP 内部で完結する領域は含みません。また 8 トークン生成のため、長文で増加する KV キャッシュは含みません。

E4B は同じ端末で、81 トークン入力・100 トークン出力の LLM を 1 回ずつ実行した参考測定です（単位 MiB）。RssAnon と RssFile の内訳は取得しておらず、実行中の PSS を併記します。E2B の表とは条件が異なります。

E4B でも NPU のピークは CPU の約 3 分の 1 です。この測定は端末が Thermal Status 1 の状態で、Android のページ回収の影響を受けています。

制約

• QNN Model は SoC ごとに変換が必要で、他の SoC 向けのファイルは使用できません。
• コンテキスト長と Prefill の固定長（AR）は変換時に決定され、実行時に変更できません。変更する場合は ailia LLM Compiler で再変換します。
• VLM では 1 枚の画像トークン列（256 トークン）を分割せずに処理する必要があるため、テキスト側は AR-256 以上で変換した QNN Model を使用します。
• 現在の対応モデルは Gemma 4 E2B / E4B です。Hexagon v68 / v69 では 2 GB のサイズ制約のため E2B のみ使用できます。