【追記 2026-04-11】 初版公開後、Gemma 4 31B Dense、Qwen 3.5-27B Dense、Qwen 3.5-122B-A10B MoE の 3 モデルを追加検証しました。「64 GB / 96 GB のメモリがあるのに 26B で十分なのか？」という疑問に対して、Dense モデルは品質こそ高い（97-98%）ものの tg 10-12 t/s で対話には厳しいこと、122B-A10B は 69 GiB を占有しつつ品質向上は限定的であることを実データで確認しています。詳しくは全モデル比較と全モデル品質比較のセクションをご覧ください。

はじめに

先日、DGX Spark 上で Gemma 4 vs Qwen 3.5 のベンチマーク記事を書きました。結論は「速度・効率重視なら Qwen 3.5、ライセンスの自由度なら Gemma 4」というものでした。

今回は同じ比較を EVO-X2（AMD Ryzen AI Max+ 395） で実施しました。Ryzen AI Max+ 395 は CPU と GPU がメモリを共有する統合型の AI チップで、128 GB の LPDDR5X を CPU/GPU で柔軟に割り当てられます。推論エンジンは同じ llama.cpp ですが、バックエンドは CUDA ではなく Vulkan です。

結果は DGX Spark とは 少し違った構図 になりました。Gemma 4 が速度・品質・サイズのバランスで Qwen 3.5 を上回っているように見えます。その理由は、Qwen 3.5 が採用する GDN（Gated DeltaNet） アーキテクチャと Vulkan の相性にあると考えられます。

検証環境

項目	EVO-X2	DGX Spark（参考）
プロセッサ	AMD Ryzen AI Max+ 395（CPU+GPU統合、RDNA 3.5, 40 CUs）	NVIDIA GB10（Grace Blackwell）
メモリ	128 GB LPDDR5X (~256 GB/s)、CPU/GPU共有	128 GB LPDDR5X (~273 GB/s)、統合
VGM (GPU割当)	64 GB / 96 GB（モデルサイズに応じて切替）	128 GB
OS	Ubuntu 25.10 (kernel 6.18.20)	Ubuntu 22.04 (ARM64)
llama.cpp	b8672 (Vulkan)	b8665 (CUDA sm_121)

テストモデル

今回は「64 GB で日常的に使えるモデル」だけでなく、「96 GB にすれば載る大型モデル」や「Dense モデル」も含めて比較しました。「なぜ MoE の 26B-A4B を推すのか」を実データで示すためです。

モデル	タイプ	Active パラメータ	量子化	GGUF サイズ	VGM要件
Gemma 4 26B-A4B	MoE	3.8B	Q4_K_M	15.6 GiB	64 GB
Qwen 3.5-35B-A3B	MoE	3B	Q4_K_M	19.7 GiB	64 GB
Gemma 4 31B	Dense	30.7B	Q4_K_M	17.4 GiB	64 GB
Qwen 3.5-27B	Dense (+GDN)	27B	Q4_K_M	15.9 GiB	64 GB
Qwen 3.5-122B-A10B	MoE (+GDN)	10B	Q4_K_M	69.1 GiB	96 GB

DGX Spark の記事では Gemma 4 を F16（47 GiB）、Qwen 3.5 を MXFP4（20.1 GiB）で評価しましたが、EVO-X2 では Q4_K_M に統一してフェアな比較としました。

なぜ Vulkan なのか — Ryzen AI Max+ 395 の GPU バックエンド事情

Ryzen AI Max+ 395（gfx1151）で llama.cpp を動かすバックエンドは、Vulkan（RADV） と ROCm（HIP） の 2 択です。2026 年 4 月時点では Vulkan が推奨だと思います。

観点	Vulkan (RADV)	ROCm (HIP)
ビルドの容易さ	◎ `apt install libvulkan-dev` のみ	△ ROCm システムインストール必要
MoE モデルの tg 速度	◎ 最近の RADV 改善で高速化	○ 同等かやや遅い
安定性	◎ 安定	△ "GGGG" 出力問題の報告あり
GDN サポート	CPU フォールバック	カーネルあるが RDNA 3.5 で非効率

2026 年 3 月の llama.cpp Discussion #10879 では、RADV Vulkan が ROCm HIP を MoE モデルで上回った ことが報告されています。Wave32 対応 Flash Attention（PR #19625）や AMD グラフィックスキューの利用（PR #20551）といった Vulkan 固有の改善が効いています。

4 月 2 日の Phoronix の記事でも、Ubuntu 26.04 のソフトウェアスタック更新で Strix Halo の Vulkan バックエンドに大きな性能向上があったと報告されています。

Vulkan ビルド

sudo apt install -y libvulkan-dev

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp && git checkout b8672

cmake -B build-vulkan -DGGML_VULKAN=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build-vulkan --config Release -j$(nproc)

CUDA や ROCm のような GPU SDK のインストールが不要で、ビルドが非常にシンプルです。

GDN 問題 — Qwen 3.5 が Vulkan で不利な理由

ここが DGX Spark との違いを生む最大のポイントだと考えています。

Qwen 3.5 は Gated DeltaNet（GDN） というアーキテクチャを採用しています。llama.cpp の PR #19504（b8233 でマージ）で GGML_OP_GATED_DELTA_NET として実装されましたが、Vulkan 用のコンピュートシェーダーが存在しません。そのため GDN 演算は CPU にフォールバックします。

HIP（ROCm）にはカーネルが存在しますが、RDNA 3.5 では hipMemcpyWithStream がボトルネックとなり、実効性能は CPU フォールバックと同等の約 12 t/s にとどまるようです（Issue #20354）。

Gemma 4 は GDN を使いません。 標準的な Transformer + MoE アーキテクチャなので、Vulkan の性能がフルに発揮されます。この構造的な差が、EVO-X2 での比較結果を大きく左右していると思われます。

llama-bench 速度ベンチマーク

以下のコマンドで純粋な推論速度を計測しました。

llama-bench -m <model.gguf> -ngl 99 -fa 1 -mmp 0 -p 2048 -n 32 -ub 2048

-mmp 0 は mmap を無効にするオプションです。ネットワーク越し（Samba）にモデルファイルを配置しているため、mmap ではなく全量を VRAM にロードする設定としました。-ngl 99 で全レイヤを GPU にオフロード、-fa 1 で Flash Attention を有効化しています。

MoE モデル（日常利用候補）

モデル	タイプ	Active	サイズ	pp2048 (tok/s)	tg32 (tok/s)
Gemma 4 26B-A4B	MoE	3.8B	15.6 GiB	1,348	65.4
Qwen 3.5-35B-A3B	MoE	3B	19.7 GiB	730	72.9

Prompt Processing で Gemma 4 が 1.8 倍速い（1,348 vs 730 tok/s）。GDN を使わないため、Vulkan のコンピュートパイプラインがフルに活用されていると考えられます。

Token Generation では Qwen 3.5 がわずかに速い（72.9 vs 65.4 tok/s）。これは Active パラメータの差（3B vs 3.8B）によるもので、帯域律速環境では読み出すウェイト量が少ない方が有利です。

全モデル比較 — なぜ MoE を選ぶのか

モデル	タイプ	Active	サイズ	pp2048 (tok/s)	tg32 (tok/s)
Gemma 4 26B-A4B	MoE	3.8B	15.6 GiB	1,348	65.4
Qwen 3.5-35B-A3B	MoE	3B	19.7 GiB	730	72.9
Qwen 3.5-122B-A10B	MoE (+GDN)	10B	69.1 GiB	381	28.6
Qwen 3.5-27B	Dense (+GDN)	27B	15.9 GiB	267	12.1
Gemma 4 31B	Dense	30.7B	17.4 GiB	234	10.9

EVO-X2 のような統合メモリ環境では、Active パラメータの大きさが速度を決定的に左右します。Token Generation ではトークンごとに Active パラメータ分のウェイトをメモリから読み出す必要があるため、帯域がボトルネックになります。

MoE 小型（Active 3-4B）: 65-73 t/s — 対話に十分快適
MoE 大型（Active 10B）: 28.6 t/s — 使えるが体感は遅め
Dense（Active 27-31B）: 10-12 t/s — 対話用途には厳しい

Dense モデルは総パラメータのほぼ全てを毎トークン読み出すため、16 GiB 程度のモデルでも tg が 10-12 t/s にとどまります。「サイズが小さいから速い」わけではなく、Active パラメータが速度を支配する という点が重要です。

Qwen 3.5-122B-A10B は 96 GB の VGM を使えば載りますが、69 GiB を占有するため他のツールとの同居は困難です。そして 28.6 t/s は快適とは言いにくいと思います。

DGX Spark との比較

モデル	量子化		DGX Spark	EVO-X2
Gemma 4	F16 / Q4_K_M	pp2048	2,273	1,348
Qwen 3.5	MXFP4 / Q4_K_M	pp2048	2,828	730
Gemma 4	F16 / Q4_K_M	tg32	26.5	65.4
Qwen 3.5	MXFP4 / Q4_K_M	tg32	58.0	72.9

Prompt Processing は DGX Spark が圧倒的に速い（2-4 倍）。CUDA の成熟度と Blackwell のハードウェアサポート（MXFP4 ネイティブ演算など）が効いていると考えられます。

一方、Token Generation では EVO-X2 が上回っています。メモリ帯域は DGX Spark の方が上（273 vs 256 GB/s）ですが、Vulkan RADV ドライバの効率が高いようです。量子化の差（DGX の F16/MXFP4 vs EVO の Q4_K_M）も寄与しており、Q4_K_M の方がトークンあたりの読み出しデータ量が少ないため tg では有利に働きます。

なお、DGX Spark の Gemma 4 31B Q4_K_M も 10.43 t/s で、EVO-X2 の 10.88 t/s とほぼ同じでした。Dense 30.7B の帯域律速は環境を問わず同じ結果になるようです。

実用上、対話的な利用では tg 速度（= 体感のレスポンス速度）が重要なので、EVO-X2 の 65-73 t/s は十分快適だと感じています。

テキストベンチマーク: JCommonsenseQA

DGX Spark の記事と同じ JCommonsenseQA v1.1 を使用しました。1,119 問の日本語 5 択常識推論問題を 3-shot プロンプトで評価しています。検証スクリプトは GitHub で公開しています。

全モデル品質比較

モデル	タイプ	Active	サイズ	正解率	tg32
Gemma 4 31B	Dense	30.7B	17.4 GiB	97.68%	10.9
Qwen 3.5-27B	Dense (+GDN)	27B	15.9 GiB	97.32%	12.1
Qwen 3.5-122B-A10B	MoE (+GDN)	10B	69.1 GiB	97.05%	28.6
Gemma 4 26B-A4B	MoE	3.8B	15.6 GiB	96.16%	65.4
Qwen 3.5-35B-A3B	MoE	3B	19.7 GiB	94.64%	72.9

品質トップは Gemma 4 31B Dense（97.68%）ですが、tg 10.9 t/s で対話には不向きです。Qwen 3.5-27B（97.32%）や 122B-A10B（97.05%）も品質は高いものの、速度面で実用性に課題があります。

Gemma 4 26B-A4B（96.16%）はトップから 1.5pt 劣るだけで、65.4 t/s の快適な速度を実現しています。 この 1.5pt のために 6 倍遅くなることを受け入れるかどうか — 多くの場合、26B-A4B で十分ではないかと思います。

興味深いのは Qwen 3.5-122B-A10B（97.05%）が Gemma 4 31B Dense（97.68%）を下回っている点です。122B のパラメータ数と 69 GiB の VRAM 消費に見合うほどの品質向上は得られていないように見えます。

量子化耐性の比較

DGX Spark の結果と合わせると、量子化による品質低下にも差があります。

モデル	DGX Spark (高精度)	EVO-X2 (Q4_K_M)	低下幅
Gemma 4 26B-A4B	96.51% (F16)	96.16%	-0.35pt
Qwen 3.5-35B-A3B	96.16% (MXFP4)	94.64%	-1.52pt

Gemma 4 は量子化に対して非常に頑健です。F16 → Q4_K_M でわずか 0.35 ポイントの低下にとどまっています。一方 Qwen 3.5 は 1.52 ポイント低下しており、量子化の影響がやや大きいようです。

Thinking モードの効果

Thinking ON/OFF は日常利用候補の MoE 2 モデルで検証しました。

モデル	量子化	環境	nothink	think	差分
Gemma 4 Q4_K_M	llama.cpp	EVO-X2	96.16%	95.98%	-0.18pt
Gemma 4 Q4_K_M	llama.cpp	DGX Spark	—	95.80%	—
Qwen 3.5 MXFP4	llama.cpp	DGX Spark	96.16%	89.28%	-6.88pt
Qwen 3.5 Q4_K_M	llama.cpp	EVO-X2	94.64%	83.91%	-10.73pt
Gemma 4 Q4_K_M	Ollama	DGX Spark (元記事)	96.4%	87.2%	-9.2pt

Gemma 4 の Thinking 劣化がほぼゼロ（-0.18pt） という結果は、今回の検証で最も驚いた発見です。

元記事（Ollama）では Gemma 4 でも -9.2pt の劣化が報告されていました。今回 llama.cpp b8672 + Q4_K_M の組み合わせでほぼ劣化しなかったのは、ランタイムの Thinking 処理の違いが影響しているのかもしれません。

一方、Qwen 3.5 は Q4_K_M だと -10.73pt と DGX Spark の MXFP4（-6.88pt）より悪化しています。量子化が Thinking の推論品質にも影響しているように見えます。

DGX Spark の記事と同じく、知識系 5 択問題では Thinking モードは無効にした方がよい という結論は変わりませんが、Gemma 4 + llama.cpp の組み合わせでは劣化が極めて小さいという点は注目に値すると思います。

Gemma 4 Thinking バグの追試 — F16 固有の問題だった

DGX Spark の記事では、llama.cpp b8665 で Gemma 4 の Thinking モードが <unused49> トークンを出し続けるバグを報告し、GitHub Discussion #21338 に投稿しました。

今回 EVO-X2 で b8672 にアップデートしたところ、Q4_K_M では Thinking ON が正常に動作。これを受けて DGX Spark でもクリーンリビルド（b8672）して追試した結果、バグの原因はバージョンではなく F16 GGUF 固有の問題 であることが判明しました。

モデル	量子化	バックエンド	Thinking ON
Gemma 4	F16	CUDA (DGX Spark, b8672)	❌ `<unused49>` 発生
Gemma 4	Q4_K_M	CUDA (DGX Spark, b8672)	✅ 正常動作
Gemma 4	Q4_K_M	Vulkan (EVO-X2, b8672)	✅ 正常動作

この追試結果は Discussion #21338 にフォローアップコメントとして報告し、GitHub リポジトリの README も更新しました。

回避策: Thinking モードを使いたい場合は、F16 ではなく量子化 GGUF（Q4_K_M で確認済み）を使用してください。

マルチモーダルベンチマーク

DGX Spark の記事と同じ画像セット（展示会写真 5 枚 + PPE 検出用 3 枚）で、日常利用候補の MoE 2 モデルについて 3 つのタスクを実施しました。Dense モデルは tg 10-12 t/s のため、VLM（画像のプリフィル処理が追加される）ではさらに時間がかかると予想されます。速度比較は llama-bench のデータで十分と判断し、VLM は MoE モデルに絞りました。

# mmproj（マルチモーダルプロジェクタ）を指定して起動
llama-server \
  -m gemma-4-26B-A4B-it-Q4_K_M.gguf \
  --mmproj mmproj-gemma-4-26B-A4B-it-f16.gguf \
  -ngl 99 --jinja \
  --chat-template-kwargs '{"enable_thinking":false}' \
  --port 8080 --temp 1.0 --top-p 0.95 --top-k 64

テスト	Gemma 4 Q4_K_M	Qwen 3.5 Q4_K_M
キャプション平均	10.29s	15.56s
JSON 抽出平均	3.70s	5.54s
JSON parse 率	100%	100%
PPE 検出平均	5.46s	6.00s
PPE parse 率	100%	100%

Gemma 4 が全タスクで高速でした。 キャプション生成で 1.5 倍、JSON 抽出で 1.5 倍の差がついています。JSON parse 率は両モデルとも 100% で、構造化データ抽出の信頼性は互角のようです。

DGX Spark の記事と比較すると、EVO-X2 の方が全体的にレイテンシが短くなっています。Q4_K_M の軽量さと Vulkan の tg 速度の高さが効いていると思われます。

全体まとめ

MoE モデル直接比較（日常利用候補）

指標	Gemma 4 Q4_K_M	Qwen 3.5 Q4_K_M
llama-bench pp2048	1,348 t/s	730 t/s
llama-bench tg32	65.4 t/s	72.9 t/s
JCQ 正解率（nothink）	96.16%	94.64%
JCQ 正解率（think）	95.98%	83.91%
VLM キャプション	10.29s	15.56s
VLM JSON parse	100%	100%
VLM PPE 検出	5.46s	6.00s
GGUF サイズ	15.6 GiB	19.7 GiB
ライセンス	Apache 2.0	独自（制限あり）

全モデル品質 vs 速度

右上（高品質・高速）ほど理想的です。バブルの大きさは GGUF サイズを表しています。Gemma 4 26B-A4B が品質と速度のスイートスポットに位置していることがわかります。30 t/s を下回ると対話での体感が遅くなり始めると感じています。

モデル	タイプ	JCQ	tg32	実用性
Gemma 4 31B	Dense	97.68%	10.9	△ 品質最高だが対話には遅い
Qwen 3.5-27B	Dense+GDN	97.32%	12.1	△ 同上。GDN問題で pp も遅い
Qwen 3.5-122B-A10B	MoE+GDN	97.05%	28.6	○ 96GB必要、他ツール同居困難
Gemma 4 26B-A4B	MoE	96.16%	65.4	◎ 品質と速度のベストバランス
Qwen 3.5-35B-A3B	MoE	94.64%	72.9	○ tg最速だが品質でやや劣る

DGX Spark とは少し違った構図

DGX Spark（CUDA）では Qwen 3.5 の MXFP4 量子化が効いて速度面で優位でしたが、EVO-X2（Vulkan）では GDN 問題のない Gemma 4 の方が総合的に優れている という結果になりました。

この違いは GPU やハードウェアの優劣ではなく、モデルアーキテクチャとバックエンドの相性 に起因していると考えています。

CUDA 環境: GDN が効率的に動くため Qwen 3.5 のポテンシャルが発揮される。MXFP4 量子化も Blackwell のハードウェアサポートで高速
Vulkan 環境: GDN シェーダーが未実装のため Qwen 3.5 の pp が律速される。一方 Gemma 4 は標準的な Transformer で Vulkan の性能をフル活用

EVO-X2 / Ryzen AI Max ユーザーへの推奨

Gemma 4 26B-A4B Q4_K_M が現時点での最良の選択肢だと思います。

15.6 GiB と軽量で、他のツールとの同居も容易
pp/VLM で Qwen 3.5 を大きく上回る
JCQ 品質で 1.5pt 優位、Thinking 劣化もほぼゼロ
Apache 2.0 ライセンスで商用利用も自由

「96 GB にすればもっと大きなモデルが載るのでは？」という疑問については、Qwen 3.5-122B-A10B（69 GiB）を試しましたが、品質は 97.05% と Gemma 4 31B Dense（97.68%）を下回り、tg 28.6 t/s で快適とは言い難い結果でした。大容量メモリは「大きなモデルを載せる」よりも「長いコンテキスト」や「他ツールとの同居」に活かす方が実用的ではないかと感じています。

ただし、今後 llama.cpp の Vulkan バックエンドに GDN シェーダーが実装されれば、Qwen 3.5 の pp 速度が大幅に改善する可能性があります（Issue #20354 で追跡中）。また、Ubuntu 26.04 LTS（4 月 23 日リリース予定）で Mesa RADV ドライバのさらなる改善も見込まれるため、定期的な再評価をおすすめします。

検証スクリプト・データ

EVO-X2 ベンチマーク: GitHub: gemma4-vs-qwen35-evo-x2
DGX Spark ベンチマーク: GitHub: gemma4-vs-qwen35-dgx-spark
元記事: Gemma 4 を DGX Spark で動かして日本語とマルチモーダルをベンチマークしてみた（DevelopersIO）

参考リンク