Ryzen AI Max+ 395環境で、Gemma 4 26Bのq8_0をエージェント用途に使う場合、現時点でかなり実用的だと感じている構成を紹介します。
今回使ったのは llama.cpp の Windows HIP Radeon 向けビルドです。
llama-b9981-bin-win-hip-radeon-x64.zip
モデルは unsloth/gemma-4-26b-a4b の GGUF 版を使います。q8_0なのでQATなどと比べると少し大きいです。またMTP用の draft model も併用します。単にローカルLLMを動かすだけでなく、エージェントのバックエンドとして長時間・長コンテキストで使うことを想定した設定です。
起動バッチファイル
起動用のバッチファイルは次のようにしました。
@echo off
.\llama.cpp\llama-server ^
--host 0.0.0.0 ^
--port 11434 ^
--models-preset presets_26b.ini ^
-np 2 ^
--chat-template-kwargs "{\"enable_thinking\":false}"
pause--models-preset で設定ファイルを読み込みます。ポートは 11434 にしています。
-np 2 は並列処理数の指定です。エージェント用途では、単発のチャットよりも複数セッションやバックグラウンド処理が発生しやすいため、少し余裕を持たせています。
設定ファイル
設定ファイル（presets_26b.ini）は次の通りです。
[*]
ngl = 99
ctx-size = 131072
spec-type = draft-mtp
spec-draft-n-max = 2
temp = 1.0
top-p = 0.95
top-k = 64
cache-type-k = f16
cache-type-v = f16
flash-attn = on
batch-size = 2048
ubatch-size = 2048
no-mmap = true
cache-ram = 32768
[unsloth/gemma-4-26b-a4b]
model = C:\Users\hogehoge\unsloth\gemma4-26b-a4b\gemma-4-26B-A4B-it-Q8_0.gguf
model-draft = C:\Users\hogehoge\unsloth\gemma4-26b-a4b\mtp-gemma-4-26B-A4B-it.gguf
mmproj = C:\Users\hogehoge\unsloth\gemma4-26b-a4b\mmproj-F16.ggufポイントは spec-type = draft-mtp と model-draft です。これにより、Gemma 4のMTPを使った投機的デコードが有効になります。
spec-draft-n-max = 2 にしているので、draft model側で最大2トークン先まで予測します。MTPは常に単純に2倍速になるような仕組みではありませんが、予測が当たる場面では生成ステップをまとめて進められるため、体感レスポンスの改善につながります。なお、ここは=1のほうが良い場合もあるので、気になる方は比較して検証してみてください。
モデルは以下の3つをダウンロードします。この3つで27GBくらいあります。
- gemma-4-26B-A4B-it-Q8_0.gguf
- mtp-gemma-4-26B-A4B-it.gguf
- mmproj-F16.gguf
ダウンロードはこちらから行います。
Ryzen AI Max+ 395の強みはメモリ構成にある
今回の構成で特に効いているのは、Ryzen AI Max+ 395の128GBユニファイドメモリです。
私はこれを64GB:64GBで切って使っています。つまり、GPU側に64GB、CPU側に64GBを割り当てる構成です。
この構成のメリットは大きく2つあります。
1つ目は、Gemma 4 26Bのような大きめの単一モデルを余裕を持って動かせることです。Q8_0のような比較的高精度な量子化でも、メモリ容量に追われにくく、MTP用の draft model や mmproj も含めて運用しやすくなります。
2つ目は、RAM側にセッションキャッシュを多く載せられることです。今回の設定では以下のように32GiBを指定しています。
cache-ram = 32768エージェント用途では、通常のチャットよりもシステムプロンプトが長くなりがちです。また、ツール定義、過去の会話、作業履歴、セッションごとの文脈などが積み上がるため、プロンプト全体がかなり長くなります。
このとき問題になるのがプレフィル時間です。毎回長いシステムプロンプトや履歴を処理し直すと、応答開始までの待ち時間が増えます。
RAMにセッションキャッシュを多く載せられると、このプレフィルの負担を抑えやすくなります。つまり、単に「モデルが動く」だけではなく、複数エージェント・複数セッションで継続利用したときのレスポンスが良くなります。
Ryzen AI Max+ 395の128GBユニファイドメモリは、この用途とかなり相性が良いです。GPU側に十分なメモリを渡してモデルを動かしつつ、CPU/RAM側にもキャッシュの余地を残せるため、ローカルエージェント基盤として扱いやすい構成になります。
KVキャッシュはf16
設定ではKVキャッシュをf16にしています。
cache-type-k = f16
cache-type-v = f16llama.cppではこのあたりが自動設定される場合もありますが、MTPを使う構成ではf16が標準的な選択になります。
f16のKVキャッシュは容量を多く使います。そのため、メモリに余裕がない環境では重くなります。一方で、長いコンテキストを扱うときの品質面では安心感があります。
個人的な体感としては、KVキャッシュを小さくしすぎた構成よりも、長いコンテキストで会話や作業履歴を持たせたときに破綻しにくい印象があります。エージェント用途では、短い一問一答よりも長い文脈を保ったまま作業することが多いため、この点はかなり重要です。
ctx-sizeは131072
コンテキスト長は以下のようにしています。
ctx-size = 131072128Kコンテキストです。
Gemma 4 26Bをエージェントとして使う場合、システムプロンプト、ツール仕様、会話履歴、作業ログがすぐに膨らみます。コンテキストが短いと、過去の指示や作業状態を維持しにくくなります。
もちろん、コンテキストを長くすればそのぶんKVキャッシュの容量も必要になります。ここでも128GBユニファイドメモリの余裕が効きます。
どの用途に向いているか
難しい推論、複雑な設計判断、コードベース全体をまたぐ大規模な修正などは、やはりGPT-5.5のような強力なクラウドモデルのほうが向いています。
一方で、日常的なタスク、軽めの調査、定型的な文章作成、ローカルファイルを前提にした補助、そこまで難しくないエージェント処理であれば、このGemma 4 26B構成でも十分にワークします。
特に、レスポンスの速さ、ローカル実行、長いセッション履歴、キャッシュの効きやすさを重視する場合、Ryzen AI Max+ 395 + llama.cpp + Gemma 4 26B + MTP の組み合わせはかなり現実的です。
まとめ
Ryzen AI Max+ 395でGemma 4 26Bを動かす場合、単に「26Bモデルが載る」というだけでなく、128GBユニファイドメモリを活かしてエージェント用途に最適化できる点が大きいです。
GPU側64GBでモデルを余裕を持って動かし、RAM側64GBでセッションキャッシュを多く持つ。これにより、長いシステムプロンプトや履歴を持つエージェントでも、プレフィル時間を抑えやすくなります。
MTPによる生成速度の改善、f16 KVキャッシュによる長コンテキストでの安定感、128Kコンテキスト、そして十分なメモリ容量。これらを組み合わせることで、ローカルLLMを単なるチャット用途ではなく、実用的なローカルエージェント基盤として使いやすくなります。
コメント