Snapdragonでllama.cpp OpenCLを使う方法｜AdrenoでローカルLLMを動かす

llama.cppには、Qualcomm Adreno GPUを使って推論するためのOpenCL経路が用意されている。現行の公式ドキュメントにはAndroidとWindows 11 Arm64のビルド手順があり、Snapdragon 8 Gen 3 / 8 EliteやSnapdragon X Eliteを使った検証環境も掲載されている。

導入前に確認したいのは、Snapdragonという製品名だけではない。Adrenoの世代、OS、ドライバー、OpenCLを有効にしたllama.cppを用意できるかの4点が重要になる。古いSnapdragon端末まで一律に対応しているわけではない。

検証済みのAdrenoを確認する

llama.cppのOpenCLドキュメントでは、次のAdreno GPUが検証済みとして挙げられている。

Adreno GPU	Snapdragon	公式ドキュメント上の状態
Adreno 750	Snapdragon 8 Gen 3	対応
Adreno 810	Snapdragon 7s Gen 3	対応
Adreno 830	Snapdragon 8 Elite	対応
Adreno 840	Snapdragon 8 Elite Gen 5	対応
Adreno X1-85	Snapdragon X Elite	対応
Adreno X2-90	Snapdragon X2 Elite	対応

OSの検証例では、AndroidはSnapdragon 8 Gen 3 / 8 Elite、WindowsはWindows 11 Arm64 + Snapdragon X Eliteが掲載されている。

A6x系も新しいドライバーやコンパイラを備えたIoT環境では使える場合がある。一方、古いドライバーやコンパイラを使うスマートフォンでは対応しにくいと説明されている。検証済み一覧にない端末は、SoC名だけで可否を決めず、実際にOpenCLデバイスとして認識されるかまで確認したい。

AndroidではOpenCLを有効にしてarm64-v8a向けにビルドする

現行の公式手順では、Ubuntu 22.04をビルド環境としてAndroid向けバイナリを作成する。Git、CMake、Ninja、Python、Android NDKに加えて、OpenCL HeadersとICD Loaderが必要になる。

公式例ではNDK 26.3.11579264を使い、OpenCL Headers / ICD LoaderをNDK側へ用意してからllama.cppを次の条件でビルドする。

mkdir build-android
cd build-android

cmake .. -G Ninja \
  -DCMAKE_TOOLCHAIN_FILE=$HOME/android-sdk/ndk/26.3.11579264/build/cmake/android.toolchain.cmake \
  -DANDROID_ABI=arm64-v8a \
  -DANDROID_PLATFORM=android-28 \
  -DBUILD_SHARED_LIBS=OFF \
  -DGGML_OPENCL=ON

ninja

OpenCL HeadersとICD Loaderの配置は、端末上の設定ではなくビルド環境の準備にあたる。-DGGML_OPENCL=ONだけを付けても、必要なOpenCL環境が解決されなければビルドは完了しない。

初回確認には1B〜4B級の小さなGGUFが向いている。大きなモデルから始めると、メモリ不足とOpenCL側の問題を切り分けにくくなるためだ。

Windows 11 Arm64ではClangとOpenCL環境を揃える

Windows側も、x64向けバイナリをそのまま使うのではなくArm64向けにビルドする。

Windows向けの公式文書では、OpenCL専用ガイドとSnapdragon Windows共通ガイドでVisual Studioの記載が異なる。OpenCL専用ガイドはVisual Studio 2022（またはBuild Tools）とClang 19を挙げ、Snapdragon Windows共通ガイドはVisual Studio 2026のArm64標準環境と実行時ライブラリを案内している。

OpenCLだけを構築する場合はOpenCL専用ガイドを基準にしつつ、共通ガイドのOpenCL SDK 2.3以降とsetup-sdk.pyも確認する。

python scripts\snapdragon\setup-sdk.py --list-sdk-releases
python scripts\snapdragon\setup-sdk.py --opencl

OpenCLを手動でビルドする例では、KhronosのOpenCL Headers / ICD Loaderを用意し、Arm64 Windows用LLVMツールチェーンとGGML_OPENCLを指定する。

cmake .. -G Ninja `
  -DCMAKE_TOOLCHAIN_FILE="$HOME/dev/llm/llama.cpp/cmake/arm64-windows-llvm.cmake" `
  -DCMAKE_BUILD_TYPE=Release `
  -DCMAKE_PREFIX_PATH="$HOME/dev/llm/opencl" `
  -DBUILD_SHARED_LIBS=OFF `
  -DGGML_OPENCL=ON

ninja

Snapdragon Windows向けドキュメントにはHexagon NPUの設定も並ぶが、NPU向けのテスト署名はAdreno GPUのOpenCL利用には不要と明記されている。OpenCLだけを使う場合は、NPU用の証明書設定まで混ぜない方が原因を切り分けやすい。

ビルド後はAdrenoが認識されているか確認する

ビルドが成功しても、実際にGPUが使われているとは限らない。llama.cppには利用可能なデバイスを列挙する--list-devicesがあるため、まずOpenCL / Adrenoが候補に出るかを確認する。

llama-cli --list-devices

次に小型GGUFを指定し、GPUへ配置する層を増やして起動する。現在の共通引数では--n-gpu-layers / --gpu-layersを利用でき、allまたは大きな値を指定するとGPUへ置ける範囲を最大化できる。

llama-cli -m model.gguf --gpu-layers all -p "Hello"

確認したいのは、文章が生成されたかだけではない。デバイス一覧と実行ログを見て、OpenCLが選ばれ、想定したモデルの一部がGPUへ配置されているかを確認する。

SnapdragonはCPUとGPUでメモリを共有するため、GGUFファイルの容量をそのまま「必要VRAM」とは扱えない。実行時にはOS、KVキャッシュ、OpenCL側のバッファなどもメモリを使い、コンテキスト長によっても余裕が変わる。

量子化とファイル容量、実行時メモリの違いはGGUF量子化とVRAM・品質の関係でも整理している。

OpenCLへの対応と9月3日の高速化は別に考える

OpenCLが扱えるデータ形式にはQ4_0、Q8_0、Q4_K、Q5_K、Q6_K、MXFP4などが含まれる。一方、2026年9月3日に取り込まれたPR #26477は、K量子化を使う密な構造のモデルで、生成処理を高速化する変更だ。

上流開発者の測定では、Adreno 840上のQwen3-4B-Q4_K_Mでtg128が14.45 tok/sから16.91 tok/sへ上がり、16.99%の改善が報告された。これは特定のGPU、モデル、量子化、測定条件で得られた値であり、独自実測値でもSnapdragon全体の性能保証でもない。

PRでは改善対象を長い入力の処理ではなく、生成時のGEMVと中程度のバッチで使うGEMMとして説明している。Q8_0やMXFP4、MoEモデルはこの最適化の対象外とされている。

したがって、OpenCLで読み込める形式と、今回の高速化が効く形式は一致しない。Q8_0やMXFP4がOpenCL非対応という意味ではない。

Snapdragon X2には任意のバイナリカーネルもある

現行のOpenCLドキュメントには、Snapdragon X2世代向けの配布済みバイナリカーネルも記載されている。対象はX2-90 / X2-85 / X2-45で、Q4_0、Q4_1、Q4_K、MXFP4のMUL_MAT_ID用カーネルが含まれる。

これは標準で必須ではない。利用する場合はカーネルライブラリを別途取得し、CMakeで次を有効にする。

-DGGML_OPENCL_USE_ADRENO_BIN_KERNELS=ON

対応するカーネルが見つかった場合だけ読み込まれる。X2以外の端末でこの設定を有効にすれば一律に高速化する、という機能ではない。

CPUのみの場合と同じ条件で比較する

OpenCLの導入後は、同じGGUF、同じプロンプト、同じコンテキスト長でCPUのみの場合とOpenCL利用時を比較する。

確認したいのは次の4点だ。

• OpenCL / Adrenoがデバイス一覧に表示されるか
• 実行ログでGPUへの配置を確認できるか
• 同じ条件でトークン生成速度が改善するか
• 数分以上使ってもエラーや大きな速度低下が起きないか

スマートフォンや薄型Arm PCでは、短い1回の測定だけから継続性能を一般化しない。電力制御や温度条件によって速度が変わるため、実際に使う時間幅で確認する方がよい。

OpenCLが認識されない場合は、モデルを変える前にドライバー、OpenCL環境、ビルド設定の順に戻る。生成はできるのに遅い場合は、GPUへの配置量、量子化、コンテキスト長、端末の状態を分けて確認する。

対応Adrenoを持っているなら、最初の目標は大きなモデルを動かすことではなく、小型GGUFでOpenCLデバイス認識とGPUオフロードを再現することになる。そこまで確認できれば、モデルサイズやコンテキスト長を増やしたときも、OpenCL側とメモリ側の問題を切り分けやすい。