久々にWindowsPCを買い換える機会があった。既に使っていたのは2022年のThinkPad X1 Carbon。処理性能よりもバッテリがもたないことが悩みだったので、バッテリがもつらしいSnapdragon版に手を出してみた。入力デバイスのクオリティ的にメインの仕事PCをThinkPad以外にするのは考えにくかったところに、ちょうどT14sのSnapdragon X2 Elite版が発売開始されたので飛びついてみた。軽い気持ちでこういうことをするからトラブルにあうんやぞ感。（最近はX1が高すぎるのに対して、T14sはアカデミック価格ならギリ手が出せる範囲だったというのもある。）
直後にRTX Sparkが控えているからARM64版Windows11自体には特にでかい地雷は埋まっていないだろう、と思っていたわけだが、実際に使ってみたら思った以上に何も問題なくて拍子抜け。ARM64版バイナリがなくてもx86_64版バイナリが普通に動くので、日常使用には何も問題なし。あまりにも普通の、ちゃんとバッテリがもつWindows。（よく考えたらプリンタのセットアップすらしてないので、まだ油断ならないかもしれないけど……。）
せっかくの、いわゆる「AI PC」というやつなので、ローカルLLMの活用を少し考えてみることにした。とはいえ色々試すのはめんどくさいので、デスクトップ版のClaude CodeをインストールしてAIに自ら調査させてみた。以下、Claude Codeによるレポートを少し調整したもの。誰かの参考になればということで置いておきます。
先に結論的なものを書いておくと、NPUはコンテキスト長が4096固定という制限がキツいこともあり、できることはやや限定的。でも文章の翻訳や要約などはそれなりに使える。色々なモデルを試してみたが、現時点ではQwen3-4B-Instruct-2507が概ね良いらしい。実際に論文をいくつか突っ込んだりしてみたが、時間的にも品質的にも使えそう。RAGで論文蓄積して遊んでみようかな？コード生成はこれから試す……。
Snapdragon X2 Elite ノートPCで動くローカルLLM 動作確認レポート(2026-09-10)
対象読者: Snapdragon X2 Elite(Hexagon NPU)搭載の Windows 11 ARM64 ノートPC(RAM 32GB)で、
機密文書を外に出さずに LLM を使いたい人。翻訳・要約に加えて、コード生成・算数・知識QA・JSON抽出も同じ条件で確かめた。
本書の数値はすべて 2026-09-10 に本機で再計測したもの(1モデル1プロセス、他の負荷なし)。
0. 要点
-
NPU で LLM を全層動かす実用経路は Qualcomm GenieX 0.6.1(pip の
geniex)。 Microsoft Foundry Local の "qnn-npu" モデルは注意層・語彙層が CPU のハイブリッドで、CPU を 6〜7 コア食う(§4.4)。 - GenieX には 2 つのランタイムがあり、用途で使い分ける:
- qairt(AI Hub 配布の W4A16 バンドル): 速い(Qwen3-4B で 37 tok/s)、CPU 1 コア。ただしコンテキスト 4096 固定。
- llama.cpp HTP0(GGUF の Q4_0 を Hexagon で実行): コンテキスト 16k〜32k。速度は qairt の 6〜7 割、CPU 2〜3 コア。
- 推奨モデル(2026-09-10 時点)
| 用途 | 第1候補 | 代替 |
|---|---|---|
| 日⇔英 翻訳(速度重視) | Qwen3-4B-Instruct-2507(qairt, 37 tok/s) | Qwen3-VL-4B(同等速度) |
| 日⇔英 翻訳(品質重視) | Gemma-4 E4B QAT Q4_0(HTP0, 23 tok/s)…英→日が最も自然 | Qwen3-8B(qairt, 22 tok/s) |
| コード生成・修正 | Qwen3-8B Q4_0 GGUF(HTP0, 16 tok/s、自動採点 6/6)または Seed-Coder-8B-Instruct Q4_0(HTP0, 16 tok/s、関数実装 3/3、コード専用)。Qwen2.5-Coder-7B/3B・GLM-4-9B はこれらを上回らず(§4.5, §4.7) | Qwen3-4B-Instruct-2507(qairt、英語仕様なら合格)。CPU 全コアと RAM 16 GB を許せるなら Qwen3-Coder-30B-A3B(CPU、25 tok/s、品質最良) |
| 日本語 知識QA・一般対話 | Gemma-4 E4B QAT(5/5)、Qwen3-8B GGUF(5/5) | Qwen3-4B(4/5) |
| JSON 構造化出力(ツール連携) | Qwen3 系全般(全構成で合格) | Gemma-4 E4B QAT |
| 論文全文(7k トークン)の一括要約・査読 | Gemma-4 E4B QAT(HTP0 ctx16k、46 秒) | Qwen3-4B-Instruct-2507 Q4_0(93 秒、CPU 0.9 コア) |
| 下訳・大量処理の速さ優先 | Qwen3-1.7B(qairt, 67 tok/s) ※コード・QA は不可 | ― |
- メモリ: 1 モデルあたりシステム空きメモリの減少は 3.5〜7.8 GiB。32GB 機なら qairt と HTP0 のモデルを 1 つずつ常駐させても余裕がある。
- 避けるべきもの: K 量子化(Q4_K_M)・MoE・Qwen3.5 系の GGUF は Hexagon に載らず CPU 実行になる(MoE はカーネル自体はあるが VTCM 予算超過で CPU に落ちる。§4.6)。Qwen3-1.7B と ELYZA-JP-8B はコード生成に使えない。
-
コード生成の限界: 関数単位の実装・バグ修正は 4B 以上で合格するが、少し複雑なクラス実装(§4.5
code_class)は全モデル不合格。8B 級ローカルモデルは「生成→テストで検証」の前提で使う。
1. 環境
| 項目 | 内容 |
|---|---|
| 機種 | Lenovo 22A7CTO1WW(ThinkPad系)、BIOS N4PET33W 1.14(2026-08-20) |
| SoC | Snapdragon X2 Elite X2E-80-100: Oryon CPU 12 コア(最大 4.0 GHz)、Adreno X2-85 GPU、Hexagon NPU |
| RAM / SSD | LPDDR5X 32 GB(OS 認識 31.5 GiB)、NVMe 1 TB |
| OS | Windows 11 Pro 10.0.28000(ARM64) |
| ドライバ | Hexagon NPU 30.0.220.11010(2026-01-27)、Compute DSP 685.13804.70.0、Adreno 32.0.152.3 |
| Python | ARM64 版 Python 3.13.15(x64 Python はエミュレーション動作で NPU ランタイムを読めない) |
| GenieX |
geniex 0.6.1(SDK v0.6.1、QAIRT 2.45 同梱、ライセンストークン不要)。venv: venv-geniex
|
| Foundry Local(比較用) | CLI 0.10.3 + foundry-local-sdk 2.0.1、onnxruntime 1.28.0、onnxruntime-genai 0.15.2。venv: venv-arm64
|
2. 実行経路
| 経路 | 仕組み | 何が動くか | ctx | 特徴 |
|---|---|---|---|---|
| A. GenieX qairt | Qualcomm AI Hub が X2 Elite 向けにコンパイル済みの W4A16 コンテキストバイナリを Hexagon で実行 | AI Hub 掲載の LLM/VLM(X2 Elite 対応は 18 種) | 4096 固定 | 全層 NPU。最速・CPU 最小。Llama 系はライセンス上、自前で AI Hub コンパイルが必要(Linux x86-64 ホスト) |
| B. GenieX llama.cpp HTP0 | GenieX 同梱の llama.cpp Hexagon バックエンド(署名済み libggml-htp-v*.so)で GGUF を実行 |
dense モデルの Q4_0 / Q8_0 のみ NPU。K 量子化・MoE・Qwen3.5 は CPU に落ちる | 16k〜32k | 長文向き。Secure Boot 無効化は不要 |
| C. Foundry Local(ONNX Runtime QNN EP) | Microsoft のカタログ(qnn-npu 変種) | Qwen2.5-7B など少数 | モデル依存 | 線形層だけ NPU、注意層・埋め込み・lm_head は CPU。CLI 0.10.3 は QNN EP 登録が壊れており SDK からの回避が必要 |
制約: 同一プロセスで A をロードした後に B はロードできない(B→A の順は可、B の再ロードは落ちる)。A と B は別プロセスで使う(本リポジトリでは llm_worker.py を子プロセスにしている)。
2.1 セットアップ(GenieX)
# ARM64 Python 3.13 で venv を作る(x64 Python は不可)
python -m venv venv-geniex
venv-geniex\Scripts\pip install geniex
venv-geniex\Scripts\geniex-py devices # llama_cpp: GPUOpenCL / HTP0 / CPU、qairt: NPU が見えれば OK
venv-geniex\Scripts\geniex-py pull ai-hub-models/Qwen3-4B-Instruct-2507 # 経路 A(約 3 GiB)
venv-geniex\Scripts\geniex-py pull google/gemma-4-E4B-it-qat-q4_0-gguf --quant Q4_0 # 経路 B(約 6 GiB)
venv-geniex\Scripts\geniex-py pull bartowski/Qwen_Qwen3-8B-GGUF --quant Q4_0 # 経路 B(約 4.5 GiB)
Python からの最小コード:
from geniex import AutoModelForCausalLM
m = AutoModelForCausalLM.from_pretrained("qualcomm/Qwen3-4B-Instruct-2507", device_map="qairt") # 経路 A
# m = AutoModelForCausalLM.from_pretrained("google/gemma-4-E4B-it-qat-q4_0-gguf:Q4_0", device_map="llama_cpp:HTP0", n_ctx=16384) # 経路 B
prompt = m.tokenizer.apply_chat_template([{"role": "user", "content": "こんにちは"}], add_generation_prompt=True, enable_thinking=False)
out = m.generate(prompt, max_new_tokens=512, temperature=0.2, top_p=0.9)
print(out.text, out.profile.decode_speed) # tok/s
3. 計測方法
- 1 モデル 1 プロセス(
bench_all.py→bench_worker.py)。温度 0.2、top_p 0.9、seed 42。各モデルの出力はbench/2026-09-10/<モデル>/<タスク>.mdに保存。 -
短文タスク(9 構成、ctx 4096):
-
ja2en/en2ja: 1,681 字の日本語技術文書 / 1,229 字の英語ガイドを Markdown を保って全訳(人手で品質確認) -
code_py: 英語仕様でtop_k_wordsを実装(単体テスト 5 件で自動採点) -
code_ja: 日本語仕様でparse_duration("1h30m15s")→5415を実装(テスト 10 件、ValueError 要件含む) -
code_fix: バグ入り二分探索(無限ループ・末尾取りこぼし)を修正(テスト 8 件) -
reason: 算数の文章題(連立方程式、答え 9 個) -
jaqa: 日本語の知識・指示 5 問(光速、len、富士山、X2 Elite の NPU 名 "Hexagon"、短文の英日訳) -
json: 英文ガイドから 5 キーの JSON を抽出(妥当な JSON・キー・型を自動判定)
-
- 長文タスク(HTP0 4 構成、ctx 16384): 論文全文(和訳、約 11,000 字 = 6.2k〜7.6k トークン)から日本語の査読メモを一括生成。引用数値が原文にあるかを人手確認。
- 計測値: ロード時間、TTFT、prefill/decode 速度(GenieX の profile)、壁時計時間、CPU 使用コア数(プロセス CPU 時間 ÷ 壁時計)、RAM 増(ロード前からのシステム空きメモリの最大減少 = モデル+ランタイムの実質占有)。
4. 結果
4.1 速度・資源(短文タスク)
| モデル | 経路 | ロード(s) | RAM増(GiB) | decode 日→英 / 英→日 (tok/s) | prefill (tok/s) | CPU(コア) | 英→日 1,229 字の所要(s) |
|---|---|---|---|---|---|---|---|
| Qwen3-4B-Instruct-2507 W4A16 | qairt | 8.5 | 6.2 | 37.1 / 37.1 | 1,750〜2,340 | 1.0 | 10.4 |
| Qwen3-8B W4A16 | qairt | 12.3 | 7.8 | 22.2 / 22.3 | 1,180〜1,570 | 1.0 | 18.9 |
| Qwen3-1.7B W4A16 | qairt | 6.0 | 4.2 | 65.8 / 67.3 | 3,180〜4,330 | 1.0 | 6.1 |
| Qwen3-VL-4B-Instruct W4A16 | qairt | 11.5 | 6.7 | 36.3 / 36.5 | 1,680〜2,230 | 1.0 | 10.3 |
| Llama-3-ELYZA-JP-8B W4A16(自前ビルド) | qairt | 8.9 | 6.1 | 19.9 / 19.8 | 810〜1,090 | 1.0 | 17.5 |
| Gemma-4 E4B QAT Q4_0 GGUF | HTP0 | 6.7 | 7.3 | 22.9 / 23.1 | 1,170〜1,290 | 3.0 | 13.9 |
| Qwen3-4B-Instruct-2507 Q4_0 GGUF | HTP0 | 3.2 | 3.5 | 24.5 / 25.9 | 1,260〜1,460 | 2.2 | 16.1 |
| Qwen3-8B Q4_0 GGUF | HTP0 | 5.4 | 5.5 | 15.6 / 16.0 | 780〜900 | 1.9 | 26.4 |
| Llama-3.1-Swallow-8B v0.5 Q4_0 GGUF | HTP0 | 4.6 | 5.3 | 16.1 / 16.5 | 810〜890 | 1.7 | 24.4 |
| (参考)Qwen2.5-7B-Instruct qnn-npu | Foundry Local | 13.3 | ― | 17.9 / 19.6(prefill 込みの実効値) | ― | 6.4〜6.7 | 20.9 |
- qairt は CPU をちょうど 1 コア(制御スレッド)しか使わない。HTP0 は 2〜3 コア、Gemma は短い応答ほど CPU 比率が上がる(QA では 5 コア)。
- 前回(9/5)計測より qairt 4B は 31→37 tok/s、Gemma QAT は 15→23 tok/s に上がっている。バックグラウンドのダウンロード等がない状態での値。
4.2 タスク別 自動採点
○ 合格 / × 不合格 / (上限) 出力トークン上限に達した / † 出力末尾の欠けを補修すれば合格。合計は 6 点満点(jaqa は 5 問の正答率)。
| モデル | 経路 | code_py | code_ja | code_fix | reason | jaqa | json | 合計 |
|---|---|---|---|---|---|---|---|---|
| Qwen3-8B Q4_0 GGUF | HTP0 | ○ | ○ | ○ | ○ | 5/5 | ○ | 6.0 |
| Gemma-4 E4B QAT Q4_0 | HTP0 | ○ | ×(上限) | ○ | ○ | 5/5 | ○ | 5.0 |
| Qwen3-4B-Instruct-2507 W4A16 | qairt | ○ | × | ○ | ○ | 4/5 | ○ | 4.8 |
| Qwen3-8B W4A16 | qairt | ○ | × | ○ | ○ | 4/5 | ○ | 4.8 |
| Qwen3-4B-Instruct-2507 Q4_0 GGUF | HTP0 | ○ | × | ○ | ○ | 4/5 | ○ | 4.8 |
| Qwen3-VL-4B-Instruct W4A16 | qairt | ○ | ×(上限) | ○ | ○ | 3/5 | ○ | 4.6 |
| Llama-3.1-Swallow-8B v0.5 Q4_0 | HTP0 | ○ | × | ○ | × | 4/5 | ○ | 3.8 |
| Qwen3-1.7B W4A16 | qairt | × | × | × | ○ | 3/5 | ○ | 2.6 |
| Llama-3-ELYZA-JP-8B W4A16 | qairt | × | × | × | × | 4/5 | ○† | 1.8 |
補足(採点の中身):
-
code_jaは「単位は 0 回か 1 回、h→m→s の順、少なくとも 1 つ」という仕様の読み取りが要る。合格したのは Qwen3-8B GGUF だけ。Qwen3-4B は"1h30m15s"の固定形式しか受けない実装、Qwen3-8B(qairt)はs.split(unit)の誤用。 - Gemma-4 は
code_jaでロジック自体は正しい方向だが、日本語コメントで自問自答を延々と書き、600 トークンでも 1,200 トークンでも完結しなかった(別途再試行済み)。Qwen3-VL-4B は同じ課題で同一 if 文の反復ループ。 -
jaqaで多くのモデルが落としたのは Q4「X2 Elite の NPU 名」。正答 Hexagon を出せたのは Gemma-4 と Qwen3-8B GGUF だけで、他は Adreno / Qualcomm / Snapdragon NPU 等と誤答。Q1 光速は Qwen3-VL が 3×10⁸(単位 m/s のまま)、Swallow が 299,792,458 km(単位誤り)。 - ELYZA は出力の末尾トークンが欠ける癖があり(閉じ ``` や
}が出ない)、`code_py` は空のコードブロックのみを返した。算数も誤答(3 個)。Swallow は算数で 1560−1200 を 240 と計算ミス。 -
jsonは 9 構成すべてでキー・型が正しい JSON を返した(ELYZA のみ閉じ括弧欠け)。ツール連携用途では Qwen3 系はどれも使える。
4.3 長文一括要約(論文 約 11,000 字、ctx 16384、HTP0)
| モデル | 入力 tok | TTFT(s) | prefill (tok/s) | 出力 tok | decode (tok/s) | 所要(s) | CPU(コア) | RAM増(GiB) |
|---|---|---|---|---|---|---|---|---|
| Gemma-4 E4B QAT Q4_0 | 6,221 | 4.9 | 1,278 | 837 | 20.4 | 45.9 | 2.7 | 7.3 |
| Qwen3-4B-Instruct-2507 Q4_0 | 7,320 | 8.1 | 900 | 900(上限) | 10.6 | 92.7 | 0.9 | 5.2 |
| Qwen3-8B Q4_0 | 7,324 | 10.9 | 674 | 706 | 8.5 | 93.9 | 0.9 | 7.1 |
| Llama-3.1-Swallow-8B v0.5 Q4_0 | 7,573 | 11.1 | 682 | 617 | 7.9 | 89.6 | 0.8 | 6.8 |
- Gemma-4 は語彙が大きくトークン数が 15% 少ないうえ、7k 級コンテキストでも decode が 20 tok/s に留まり、Qwen3 系(10 tok/s 前後)の 2 倍速。
- 4 モデルとも、要約に引いた数値(最大 5%、C=8/R=4/T=2、181 通り、Pascal/Volta 等)は原文に実在した(創作なし)。Gemma-4 は指摘が最も具体的で構成も整う。Qwen3-8B は一般論寄り、Swallow は要約の一部が「機械学習などの応用」と原文の趣旨から少しずれる。
- qairt(ctx 4096)ではこの長さは入らない。長文は経路 B、短文は経路 A、が使い分けの基本。
4.4 参考: Foundry Local(旧経路)の現状
- CLI 0.10.3 のデーモンは QNN EP 登録に失敗する既知バグ(microsoft/foundry-local#1023)が残っている。SDK 2.0.1 をプロセス内で使い
download_and_register_eps(names=["QNNExecutionProvider"])を呼ぶと(2 つ目の同名 EP は "already registered" で無害に失敗)NPU 変種qwen2.5-7b-instruct-qnn-npu:3がロードできる。 - 翻訳の実効速度は 18〜20 tok/s で品質も良いが、CPU を 6.4〜6.7 コア消費する(GenieX qairt は 1 コア)。「NPU で CPU を空ける」目的には合わない。
4.5 追加評価: コード特化モデル(Qwen2.5-Coder)と、より難しいクラス実装課題
「コード生成は NPU モデルでは弱いのか」を確かめるため、コード特化の Qwen2.5-Coder-7B / 3B(Q4_0 GGUF、HTP0)を同じ課題で計測し、
さらに難度を上げた code_class(区間集合クラス IntervalSet: 端点が触れる区間の結合・隣接は非結合・点区間・長さ計算、テスト 13 件)を全モデルに追加した。
| モデル | 経路 | decode (tok/s) | CPU(コア) | code_py | code_ja | code_fix | code_class | reason | jaqa | json |
|---|---|---|---|---|---|---|---|---|---|---|
| Qwen2.5-Coder-7B-Instruct Q4_0 | HTP0 | 17.8 | 1.8 | ○ | × | ○ | × | × | 5/5 | ○ |
| Qwen2.5-Coder-3B-Instruct Q4_0 | HTP0 | 32.1 | 2.6 | ○ | × | ○ | × | ○ | 3/5 | ○ |
| Qwen3-8B Q4_0 GGUF(汎用、参考) | HTP0 | 16.0 | 1.9 | ○ | ○ | ○ | × | ○ | 5/5 | ○ |
| Qwen3-8B W4A16 | qairt | 22.3 | 1.0 | ○ | × | ○ | × | ○ | 4/5 | ○ |
| Qwen3-4B-Instruct-2507(qairt / GGUF) | 両方 | 37 / 26 | 1.0 / 2.2 | ○ | × | ○ | × | ○ | 4/5 | ○ |
| Gemma-4 E4B QAT Q4_0 | HTP0 | 22.6 | 2.9 | ○ | ×(上限) | ○ | × | ○ | 5/5 | ○ |
-
コード特化モデルは汎用の Qwen3-8B を上回らなかった。 Coder-7B は日本語仕様・クラス実装・算数で不合格、Coder-3B は速い(32 tok/s)が同様。
Qwen2.5 世代の Coder より Qwen3 世代の汎用 Instruct の方が指示追従が良い、という前節の傾向(2 節「大きさより世代」)がここでも出た。 -
クラス実装課題は 7 構成すべて不合格。 失敗の型は 2 つ:
(a) 属性self.intervals(リスト)とメソッドintervals()の名前衝突でTypeError(Coder-7B、Qwen3-8B qairt/GGUF)、
(b) 区間結合のロジック誤り: 新区間が 2 つの既存区間を橋渡しするケースでマージが 1 回で止まる(Qwen3-4B 系、Coder-3B)、hi - lo + 1と仕様を読み違える(Gemma-4)。
いずれも人間のレビューなら一目で分かる種類のバグで、8B 級ローカルモデルは「書かせてテストで弾く」前提で使うものと考えるのが安全。 - Coder-3B は英→日翻訳で反復ループ(出力上限到達)。コード特化モデルを翻訳や文章に流用するのは避ける。
4.6 追加評価: MoE(Mixture of Experts)は NPU に載るか
- GenieX 同梱の Hexagon バックエンド(
ggml-hexagon.dll/libggml-htp-v81.so)のバイナリには、MoE 用の行列積カーネル(op_matmul_id、hvx_mm_id、scan_expert_ids、"HMX matmul failed for expert %u")と、
「supported MUL_MAT_ID VTCM size needed (%d) > budget (%zu)」という判定メッセージが含まれている。つまり MoE 演算は実装されているが、エキスパート行列が NPU 内の高速メモリ(VTCM)の予算に収まらないと CPU に落とす設計。 - 実測(Granite-3.1-3B-A800M、40 エキスパート、Q4_0 1.8 GB、同じ英→日プロンプト):
| device_map | prefill (tok/s) | decode (tok/s) | CPU(コア) |
|---|---|---|---|
| llama_cpp:CPU | 150 | 48.5 | 11.1 |
| llama_cpp:HTP0 | 905 | 30.6 | 6.6 |
prefill は NPU で 6 倍速くなる(注意層など dense 部分は載っている)が、decode は CPU 実行より遅く、しかも 6.6 コアを使う。
1 トークンずつのデコードではエキスパート行列積が CPU 側に残り、NPU との往復コストだけが増えている。gpt-oss-20b(MXFP4、CPU 10.8 コア)で見た結果と同じ。
-
結論: 現時点(GenieX 0.6.1)では「MoE は実質 CPU 実行」と考えてよい。 ただし理由はハード非対応ではなく VTCM 予算のフォールバックなので、
バックエンドの更新でエキスパートのタイル化が進めば変わり得る。Qwen3-Coder-30B-A3B / Qwen3-30B-A3B(Q4_0 17 GB)を試す価値が出るのはその時。
4.7 追加評価: 他のコード系モデル(Seed-Coder、GLM-4、Qwen3-Coder、DeepSeek、Codestral)
「DeepSeek や Codestral、Qwen3-Coder はどうか」への回答。まず候補を本機の条件(dense・Q4_0・8〜9B まで・非 thinking)でふるい、残ったものを計測した。
| モデル | 構造 / サイズ | ライセンス | 本機での扱い |
|---|---|---|---|
| DeepSeek-V3 / R1(671B)、DeepSeek-Coder-V2-Lite(16B-A2.4B MoE) | 巨大 or MoE | MIT | × 対象外 / MoE は CPU |
| DeepSeek-R1-Distill-Qwen-7B / Llama-8B | dense、thinking 型 | MIT | × 長考型で 10〜20 tok/s のローカルには不向き |
| DeepSeek-Coder-6.7B-Instruct(2023) | dense | DeepSeek License | △ 動くが世代が古い(未計測) |
| Codestral 22B | dense 22B(Q4_0 で 12 GB 超) | MNPL-0.1(非商用) | × サイズ・速度・ライセンス |
| Devstral Small 24B | dense 24B | Apache 2.0 | × サイズ |
| Qwen3-Coder 系 | 480B-A35B / 30B-A3B / Coder-Next 80B-A3B、すべて MoE(Coder-Next は Gated DeltaNet ハイブリッド) | Apache 2.0 | 30B-A3B のみ計測(下表) |
| Seed-Coder-8B-Instruct(ByteDance、2025-06) | dense 8B | MIT | ○ 計測 |
| GLM-4-9B-0414(Zhipu、2025-04) | dense 9B | MIT | ○ 計測 |
| Yi-Coder-9B、NextCoder-7B、Phi-4-mini | dense | Apache / MIT | 未計測(候補) |
計測結果(同じ課題。比較行として汎用 Qwen3-8B GGUF を再掲):
| モデル | 実行 | decode (tok/s) | CPU(コア) | RAM増(GiB) | code_py | code_ja | code_fix | code_class | reason | jaqa | json |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Seed-Coder-8B-Instruct Q4_0 | HTP0(NPU) | 16.1 | 1.7 | 5.4 | ○ | ○ | ○ | ×(隣接区間を結合、長さ +1) | × | 3/5 | ○ |
| GLM-4-9B-0414 Q4_0 | HTP0(NPU) | 14.2 | 1.5 | 5.6 | ○ | × | ○ | ×(名前衝突) | ○ | 4/5 | ○ |
| Qwen3-Coder-30B-A3B Q4_0(16 GB) | CPU(全層 NPU はロード失敗) | 21〜28 | 11.3 | 16.1 | ○ | ○ | ○ | ×(隣接区間を結合、13 件中 11 件通過) | ○ | 未 | ○ |
| Qwen3-Coder-30B-A3B、12 層だけ HTP0 | 部分オフロード | 27.6 | 10.4 | ― | (code_py のみ確認) | ||||||
| Qwen3-8B Q4_0 GGUF(汎用、参考) | HTP0(NPU) | 16.0 | 1.9 | 5.5 | ○ | ○ | ○ | ×(名前衝突) | ○ | 5/5 | ○ |
所見:
- NPU で動くコード系の最有力は Seed-Coder-8B。関数実装 3 課題は日本語仕様を含めて全合格(Qwen3-8B GGUF と同じ)。ただし算数と一般知識は Qwen3-8B より弱く、コード専用と割り切る。英→日翻訳は意外に自然だった。
- GLM-4-9B は Qwen3-8B と同等以下(日本語仕様の関数で不合格)。速度も 14 tok/s と最も遅い部類。
-
Qwen3-Coder-30B-A3B はコード品質は最良(クラス実装課題でも 13 件中 11 件通過と唯一の惜敗)だが、本機では CPU モデル。全層 HTP0 は
GenieXError(-100201)でロードできず、12 層だけ載せても CPU 10.4 コアで速度も変わらない(エキスパート計算が CPU に残るため)。CPU 実行で 21〜28 tok/s は出るものの、12 コアすべてと RAM 16 GB を占有し、prefill は 100 tok/s と遅い(NPU 経路の 1/8〜1/10)。「NPU で CPU を空ける」目的とは両立しない。 - 仕様の細部(「隣接するが触れない区間は結合しない」「長さは hi − lo」)は 30B-A3B でも読み落とした。この種の仕様はテストで縛るか、仕様文に反例を明示する運用が必要。
5. 品質所見(人手確認)
- 日→英: 9 構成すべて実用品質。ELYZA だけが最終節「期待される効果」を丸ごと欠落(前回計測と同じ癖)。1.7B は「未発表→unsubmitted」など語の選択が甘い。
-
英→日: Gemma-4 QAT と Swallow-8B が完全で自然。Qwen3-8B(qairt/GGUF)も良好だが「機械上(machine)」「神経プロセッサ」など直訳語がまれに残り、qairt 版で 1 語の文字化け(
�iquer)が出た。Qwen3-4B 系は "15–60 tokens per second" を「15〜60トークごとに秒を消費」と崩す癖が qairt/GGUF 両方で再現。1.7B と ELYZA は「7 billion→7億」の数値誤りと段落の欠落。 - コード: 英語仕様の実装・バグ修正は 4B 以上なら概ね合格。日本語仕様の細かい制約(0 回/1 回、順序、例外)を守れたのは Qwen3-8B GGUF のみ。コーディング支援に使うなら 8B 級、仕様は英語で書く方が安全。
- 算数・QA: 4B 以上の Qwen3 と Gemma-4 は文章題を正しく解く。事実知識は 4B 級でも 3〜4/5。専門的・新しい固有名詞(Hexagon)は Gemma-4 と Qwen3-8B GGUF だけが正答。
- JSON 抽出: 全構成合格。フェンス無し・余計な前置き無しの指示に全モデル従った。
6. モデル別の判定(2026-09-10 更新)
| モデル | 判定 | 一言 |
|---|---|---|
| Qwen3-4B-Instruct-2507(qairt W4A16) | ◎ 標準 | 最速クラス・CPU 1 コア・全タスク中庸。翻訳の既定 |
| Gemma-4 E4B QAT Q4_0 GGUF(HTP0) | ◎ 品質・長文 | 英→日と長文要約で最良、QA 5/5。CPU 3 コア、日本語仕様のコードでは冗長化 |
| Qwen3-8B Q4_0 GGUF(HTP0) | ◎ コード・QA | 唯一の自動採点 6/6。16 tok/s で遅め。長文は一般論寄り |
| Qwen3-8B(qairt W4A16) | ○ | 翻訳は堅実、22 tok/s。GGUF 版より採点は下(サンプリング差を含む) |
| Qwen3-4B-Instruct-2507 Q4_0 GGUF(HTP0) | ○ 長文の代替 | 短文 25 tok/s、長文 10.6 tok/s・CPU 0.9 コア。qairt 4B と同じ癖 |
| Qwen3-VL-4B-Instruct(qairt) | △ | テキストは 4B 同等。画像入力の予備(未活用)。反復ループが出た |
| Llama-3.1-Swallow-8B v0.5 Q4_0(HTP0) | △ | 日本語の文体は自然で英→日は完全。算数ミス、コード仕様の読み違い、長文で指示追従が弱い |
| Qwen3-1.7B(qairt) | △ 下訳専用 | 67 tok/s。コード・QA は不可、数値誤り |
| Llama-3-ELYZA-JP-8B(qairt、自前ビルド) | × | 訳し落とし、末尾欠け、コード不可。ビルド手順の実証としての価値のみ(docs/elyza_jp_8b_export_guide.md) |
| Qwen2.5-7B qnn-npu(Foundry Local) | × 旧経路 | 動くが CPU 6〜7 コア |
| Qwen3.5 系 / Gemma-3 12B / Qwen3-14B / gpt-oss-20b / Q4_K_M 全般 | × | NPU に載らない、または不安定・品質不足(docs/model_catalog.md 参照) |
7. 落とし穴と回避策
- x64 Python では動かない。ARM64 版 Python 3.13 を入れる。torch / brotli / pyarrow に arm64 wheel が無い(Gradio は brotli スタブで回避)。
- qairt → HTP0 の順で同一プロセスにロードできない。モデルごとにプロセスを分ける。
-
GGUF は Q4_0(または Q8_0)の dense モデルだけ選ぶ。unsloth / bartowski / mmnga のリポジトリに Q4_0 がある。google 公式 HF リポジトリは gated で
pull不可だがgoogle/gemma-4-E4B-it-qat-q4_0-ggufは取得できた。 - VLM 型 GGUF(Qwen3.5)は同一プロセスで 2 回目の
generate()が失敗する。Gemma-4 GGUF(VLM 型)はreset()を挟めば連続生成できた。 -
geniex-py pullは進行中ファイルをキャッシュフォルダ外に書く。フォルダサイズで進捗を見ない。中断しても再実行で再開。 - Windows コンソール(cp932)に置換文字を含む出力を print すると落ちる。
PYTHONIOENCODING=utf-8を付けるか、標準出力を UTF-8 でラップする(bench_all.py参照)。 - 短い応答では TTFT が 0.1〜0.5 s、ロードは 3〜13 s。対話用途はモデルを常駐させる(
npu_translate_gui.pyのEnginesが実装例)。 - 温度 0.2 でも生成は毎回同じではない(seed 指定でも実行間で揺れる)。合否の 1 件差は誤差の範囲として読む。
8. 再現手順
venv-geniex\Scripts\python.exe bench_all.py # 全 13 構成(短文 9 + 長文 4)、約 45 分
venv-geniex\Scripts\python.exe bench_all.py --only Qwen3-8B --skip-long # 一部だけ
venv-geniex\Scripts\python.exe bench_regrade.py bench\2026-09-10 # 保存出力の再採点と summary.md 生成
venv-arm64\Scripts\python.exe bench_foundry.py npu # Foundry Local(旧経路)の比較行
-
bench_worker.pyにタスク定義(プロンプト・テスト)がある。タスク追加はこのファイルのTASKSに足す。 -
BENCH_MAX_NEW=1200で出力上限を変えられる。
9. 今回確認していないこと
- 画像入力(Qwen3-VL-4B、Gemma-4 の視覚)、音声(Whisper 系)、埋め込みモデル(nomic-embed-text)は未評価。
- 複数ユーザ・同時実行、バッテリー駆動時の電力、長時間連続運転の安定性は未測定(Gemma-3 12B クラスで 16k ctx が落ちた事例は
model_catalog.md§2.2)。 - AI Hub に Qwen3.5 系の qairt バンドルが出れば翻訳品質の上積みが見込める(現状は GGUF が Hexagon 非対応)。