Ryzen AI Max+ 395はユニファイドメモリでRAMとVRAMの配分を調整できます。本記事では64GB-64GBで配分して最高精度のGemma-4-26B-A4Bを動かす試みを紹介します。
ローカルLLMをエージェント用途でいろいろ試している中、速度と賢さの両立を考えるとMoEモデルを使わざるを得ないという結論に行きつきます。そうなるとGemma-4-26B-A4Bが候補に挙がるわけですが、次はどの量子化モデルを使うかという問題が出てきます。
Gemma-4-26B-A4Bの量子化モデル
例えばHuggingfaceのUnsloth版。
それからOllama版。
Unslothのほうが選択肢は多いですが、よく使われるのは4bitか8bitの量子化です。今回扱うBF16と並べるとサイズは以下のようになります。
| 量子化 | モデルサイズ |
|---|---|
| Q4_K_M | 約18GB |
| Q8_0 | 約28GB |
| BF16 | 約52GB |
これらは同じGemma-4-26B-A4Bモデルで、パラメータの数は共通ですが、パラメータ1つを表現するビット数が異なります。
なお、4bit相当ならQATを使うほうが良いと言われています。
ベンチマークでは見えにくい性能
「Q8_0やQATは精度を落とさずに軽量化している」とよく言われていますが、これは半分本当で半分嘘です。
シングルターンのチャットなら差はあまりない
「チャットで何か質問をする」という使い方、つまりユーザが1回プロンプトを送信して、AIが1回回答を返して終了するタスクでは、量子化で軽量化したモデルでも、軽量化しないモデルと同じような答えが返ってくることは多いと思います。
要するに、コンテキスト長がそこまで長くないセッションで性能の違いが出ることは少ないです。精度を落とさずに量子化できていると言えます。
マルチターンのチャットではどうか？
エージェント用途では1往復のチャットで終わることはあまりありません。あったとしても、AIが裏で多数のコマンドを実行し、多往復の入出力をするのが普通です。また、エージェントとして動くための多数のルールがシステムプロンプトとして載っていて、そのうえでユーザとの対話をしていくものです。このとき、パラメータ数が少ないモデルや量子化で軽量化したモデルでは、ルールの一部を忘れてしまったり、チャットセッションの最初に言ったことを忘れたり、めちゃくちゃな回答をしたりしてしまいます。
つまり、コンテキスト量が大きくなってもたくさんの情報を正しく理解したうえでアウトプットをしてくれるかどうかがエージェントとして重要です。このような長文・多ターンのチャットではQ8_0は弱く、QATやQ4_K_Mではさらに弱くなります。
また困ったことに、このロングコンテキストでの粘り強さを評価してくれている情報というのはあまりありません。そもそもどうやって評価したらいいのかもよく分かりません。
デコード速度だけ評価しても仕方なくない？
ベンチマーク項目としてよくあるのはデコード（生成速度）です。
「ローカルモデルとは思えない速度で文章を生成します」のような評価はデコードの速度の話なのですが、実はエージェントのマルチターンのチャットを考えるとこの速度だけではレスポンスは決まりません。デコードと同様にプレフィル（チャット履歴の読み込み）の速度も重要です。
LLMは過去のコンテキストを全て読み込んだうえでトークン生成を開始します。
ユーザがメッセージ送信 → LLMのプレフィル → LLMの思考 → LLMの出力生成＆チャットが届く
のような流れです。思考と出力生成はデコードで、その前処理がプレフィルです。プレフィルは過去の文脈を読み込む作業です。キャッシュが効いていればプレフィルの遅さを感じることはないのですが、次のような場合は遅さが気になることがあります。
- チャットの1回目の応答が遅い。（システムプロンプトの読み込みに時間がかかる）
- 過去のセッションに切り替えた際の応答が遅い。（プレフィルのキャッシュが無いとプレフィルをやり直すのに時間がかかる）
- 長いセッションで急に応答に時間がかかるようになる。（コンテキストの変化が起こる等の理由でキャッシュが利用できなくなりプレフィルをやり直すのに時間がかかる）
この遅さはデコード速度だけでは解消できません。
- デコード速度が速い。
- 生成速度が速い。
- GPU性能。
- プレフィル速度が速い。
- コンテキストの読み込み速度が速い。
- GPU性能。
- キャッシュが大きい。
- プレフィルのやり直しを回避。
- メインメモリの余裕 ※VRAMではない
- エージェントがキャッシュ利用しやすい実装になっている。
- プレフィルのやり直しを回避。
- ハードではなくソフトの話。
この4点で実用上の速度・快適さが決まります。
デカいモデルはロングコンテキストに強い
Gemma-4-26B-A4Bに限らず、ファイルサイズが大きいモデルはロングコンテキストでも安定して動くことができます。
長いセッション、つまり膨大なコンテキストの情報を正確に処理するわけなので、AIの脳の空間が大きいほうが有利だし、脳の空間が小さいと情報が埋もれていったり指示忘れが起こってしまうのは、想像に難くありません。
あるモデルのパラメータ数やレイヤー構造は共通で、そのうえでパラメータ1つ当たりのビット深度が異なるのが量子化モデルです。写真に例えると、解像度は共通で、65,000色か256色か8色か、みたいな違いです。
「パラメータ数」と「量子ビット数」の2軸で考えると、
- パラメータ数が多い（70B以上）
- Q4_K_Mなどの軽量化したモデルでの性能が低下しづらい。
- 「解像度が大きいけど8色の画像」＝「情報量が多い」
- パラメータ数が少ない
- Q8_0やBF16を選ぶことで性能が低下しづらい。
- 「解像度が小さいけど65,000色の画像」＝「情報量が多い」
どちらを選んでもVRAMはそれなりの大きさが必要になります。膨大なコンテキストを正確に把握しようとして必要なメモリ量が増えるのは自然なことです。VRAMを節約して膨大なコンテキストを正確に記録するというのは無理がある話です。
大きいモデルは処理すべき情報量が多いので、必然的に速度は低下します。そこで選ばれるのがMoEモデルです。実際に計算に使用するパラメータ数が少ないので、大きいモデルでも小さい計算量で速度を向上させる技術です。Gemma-4-26B-A4BはGemma4シリーズ唯一のMoEモデルです。
Gemma-4-26B-A4BのBF16は64GBあれば動く
ロングコンテキスト・マルチターンのチャットでも安定して動いて、速度もそれなりに出る量子化モデルはどれか？利用可能なハードウェアで動く精度・速度の最適解を探した結果、Gemma-4-26B-A4BのBF16に辿り着きました。
量子化したら精度は落ちる。なら非量子化の16bitモデルを使えばいい。
実際に動かしてみたものがこちらです。
以下の構成で64GBのVRAMに収まっています。
- Unsloth版のモデル
- gemma-4-26B-A4B-it-BF16-00001-of-00002.gguf
- gemma-4-26B-A4B-it-BF16-00002-of-00002.gguf
- mtp-gemma-4-26B-A4B-it-BF16.gguf
- mmproj-BF16.gguf
- コンテキスト長
- 256k
- KVキャッシュ
- f16
llama.cppで-np 2を指定しており、2セッションの同時処理ができる構成で、この場合コンテキスト長は半分の128kになります。
処理速度は意外と速い
モデルサイズが大きいので速度は遅くなるのですが、実は処理の過程で行われる変数の変換が16bit統一環境では不要になります。したがって処理の効率が良くなり、速度はそこまで遅くなりません。
cache-ramがとても大事
メインメモリも50GBくらい使用されていますが、これはllama.cppでcache-ramを大きく設定しているのが理由です。先ほど出てきたプレフィルを省略するためのキャッシュです。これを大きく確保しておくことで、エージェントが複数セッションを並行して進める場合でも、プレフィルにかかる時間を極力小さくすることができます。
なお、間違えやすいところですが、ここで言うcache-ram はRAM側に確保するキャッシュ領域、cache-type-k/v はKVキャッシュの精度であり、設定項目としては別です。
llama-serverの起動オプション例
llama.cppはHIP版を入れています。以下の起動コマンドで動かしています。Windowsなのでバッチファイルです。
@echo off
.\llama.cpp\llama-server ^
--host 0.0.0.0 ^
--port 11434 ^
--models-preset presets_26b_BF16.ini ^
-np 2 ^
--chat-template-kwargs "{\"enable_thinking\":false}"
pause速度を優先して、デフォルトのReasoning設定をオフにしています。
presets_26b_BF16.iniファイルの内容は次の通りです。
[*]
ngl = 99
ctx-size = 262144
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_BF16\gemma-4-26B-A4B-it-BF16-00001-of-00002.gguf
model-draft = C:\Users\hogehoge\unsloth\gemma4-26b-a4b_BF16\mtp-gemma-4-26B-A4B-it-BF16.gguf
mmproj = C:\Users\hogehoge\unsloth\gemma4-26b-a4b_BF16\mmproj-BF16.ggufこの設定で約60GBのVRAM使用と約32GBのRAMを使用します。
128GBのユニファイドメモリなのでVRAMとRAMをこれだけ利用できますが、96GBのユニファイドメモリであればRAMのほう（cache-ram）を少なめにすれば動くはずです。
コメント