Gemma 4 31B ARA-hereticをEVO-X2のROCm環境で動かした
目次
Heretic v2のARA（Arbitrary-Rank Ablation）でセーフティの拒否を解除したGemma 4 31Bを、GMKtec EVO-X2のROCm環境で動かしてみた。
手元のミニPC上でllama.cppのサーバープロセス（llama-server）を立ち上げ、ローカルAPIとして推論を走らせる構成だ。
EVO-X2はRyzen AI Max+ 395（Strix Halo世代、Radeon 8060S）を搭載したミニPCで、BIOSでVRAMに48GBを割り当てている。
普段のQwen3.8-27Bサーバーで使っているllama.cppのROCmバイナリ（b1311）をそのまま使ったところ、短文から中文は8.4 t/s前後で快調に動作した。
ところが約62Kトークンの長文を入力した途端に出力が <unused49> だけになり、サーバー全体のリクエストが壊れる現象に見舞われた。
llama-serverは複数の質問を並行処理するスロット機能を備えているが、ひとたび長文で計算が破綻すると、無関係な後続スロットのリクエストまで同じエラーを出力する状態に陥った。
さらに画像入力を投げるとWindows側の物理メモリが急激に減少し、プロセスが停止する問題も起きた。
これらの現象を切り分けたところ、llama-serverのプロンプト退避機能（--cache-ram）の挙動と、llama.cppの古いビルドに存在した注意計算のバグが関係していた。
問題の切り分けと、安定して動作させるための設定を記録しておく。
対象モデルと検証環境
使用したモデルは、GoogleのGemma 4 31B instruction版からHeretic v2.0.0のARAでセーフティの拒否を外した richardyoung/gemma-4-31B-it-ARA-heretic だ。
これをmradermacher氏が静的量子化したGGUF版 mradermacher/gemma-4-31B-it-ARA-heretic-GGUF を入手した。
通常のモデルは、安全性向上のため露骨なプロンプトや攻撃的な指示に対して拒否する振る舞いを学習している。
ARA（Arbitrary-Rank Ablation）は、その拒否行動に対応する内部アクティベーションの方向を特定し、モデルの重み行列から直交化によって削ぎ落とす（Ablationする）手法だ。
これにより、安全フィルターによる定型的な拒否応答を抑え、指示どおりの文章を出力しやすくしている。
モデルカードの数値では、拒否スコアが元モデルの99/100から28/100へ低下し、本来の言語性能との乖離を示すKLダイバージェンスは0.0845にとどまっている。
ARAのパラメータは、レイヤー21から56を対象に重み付けが調整されている。
Gemma 4 31Bの構造はDense構成で、1024トークン局所を見るスライディングウィンドウ注意（Local Sliding Window Attention）とグローバル注意（Global Attention）を交互に重ねている。
コンテキスト長は256K、語彙数は262K、テキストに加えて画像入力にも対応している。
普段使っているQwen3.8-27Bの運用環境がUD-Q6_Kなので、量子化の段を揃えて比較するため、今回は Q6_K（25.2GB）＋ mmproj-f16（1.2GB）を選んだ。
検証環境の仕様は次のとおり。
| 項目 | 内容 |
|---|---|
| 機種 | GMKtec EVO-X2 |
| APU | AMD Ryzen AI Max+ 395（16コア32スレッド） |
| GPU | AMD Radeon 8060S（gfx1151、RDNA 3.5） |
| メモリ | LPDDR5X 64GB（帯域256GB/s） |
| VRAM割り当て | BIOSで48GBを固定割り当て（Windows認識RAMは15.6GB） |
| OS | Windows 11 Pro |
| llama.cpp | lemonade-sdk/llamacpp-rocm の b1311（ROCm 10.1、gfx1151向け） |
EVO-X2はCPUとGPUが同一の物理メモリを共有する統合メモリ（UMA）構成だ。
基板上の物理RAM 64GBのうち、BIOS設定で48GBをGPU専用のVRAMとして固定予約している。
このため、WindowsのOS自身から自由に使える物理RAMは差し引き約15.6GBとなる。
ダウンロードしたQ6_Kとmmprojの合計サイズは約26.4GBで、Hugging Faceのファイルサイズと一致することを確認した。
計測前には常駐していたOllamaを停止し、画像生成ツールComfyUIのモデルも解放した。
GPUの共有メモリプールを空にしておくためで、解放後のGPU専用メモリ使用量は525MBだった。
起動と思考モードの制御
最初は普段のバッチファイルを流用し、次のコマンドでサーバーを起動した。
"C:\llama-hip-b1311\llama-server.exe" ^
-m "C:\gemma4-31b-heretic\models\gemma-4-31B-it-ARA-heretic.Q6_K.gguf" ^
--mmproj "C:\gemma4-31b-heretic\models\gemma-4-31B-it-ARA-heretic.mmproj-f16.gguf" ^
--host 127.0.0.1 --port 8081 --ctx-size 65536 --jinja ^
--n-gpu-layers 99 --no-mmapモデルのロード時間は15〜19秒で、27Bクラスとほぼ同じ感覚で立ち上がった。
ロード直後のメモリ状態は次のようになった。
| 項目 | 値 |
|---|---|
| GPU専用メモリ使用量 | 35,110MB |
| GPU共有メモリ使用量 | 1,269MB |
| llama-server の Working Set | 1,419MB |
| llama-server の Private Bytes | 34,583MB |
| Windows側の空き物理メモリ | 7,440MB |
ここで最初の挙動の違いに出くわした。
--jinja を指定してGGUF内蔵のチャットテンプレートを使うと、リクエスト時にパラメータを何も渡さない場合、システムターンの先頭へ <|think|> が自動で挿入された。
テンプレートの記述自体は enable_thinking | default(false) となっているが、llama-server側が既定で enable_thinking=true を渡しているようだ。
このため、最初の計測では max_tokens 64 を指定したところ、64トークンすべてが思考出力に使われ、本文が空のまま返ってきた。
思考モードを切るには、リクエストのJSONに "chat_template_kwargs": {"enable_thinking": false} を指定する必要がある。
Qwen3.8の過去の計測も思考オフで行っていたため、以後の深さテストは思考オフで揃えて進めることにした。
なお、このテンプレートは reasoning_effort を解釈しないため、思考の長さを段階的に制御することはできない。
長文処理での <unused49> と後続リクエストの破壊
過去に行った検証と同じテキスト long_60k.txt を使い、約62,540トークンを入力して「1行で要約して」と指示する深さテストを流した。
すると次のようなログが出力された。
[q6k_65k] shallow prompt=27 gen=64 tg= 8.40 t/s pp= 56.09 t/s wall= 8.1s | (空：思考で使い切り)
[q6k_65k] shallow_long prompt=41 gen=512 tg= 8.08 t/s pp= 70.12 t/s wall= 63.9s | 簡潔に実装したコードです。 ```python class Node: ...
[q6k_65k] deep62k prompt=62578 gen=64 tg= 5.54 t/s pp=132.98 t/s wall=473.8s | <unused49><unused49><unused49>...62Kトークンの処理結果が、見慣れない <unused49> というトークンの連続で埋め尽くされた。
さらに深刻だったのはその後だ。
この長文を処理した直後からは、「日本の首都は？」「Hello, who are you?」といったごく短いプロンプトを投げても、思考のオン・オフに関わらず <unused49> しか返らなくなった。
生のトークン確率を /completion の n_probs で確認しても、先頭からすべて <unused49> に張り付いている。
同一トークンが無限に続くのは、計算過程のどこかでNaN（非数）が発生したときの特徴的な壊れ方だ。
サーバープロセスを再起動すると元に戻るため、スロットの構成を変えて切り分けを行った。
| 構成 | 62K処理後の結果 | 備考 |
|---|---|---|
| mmprojあり・自動4スロット（KV共有） | 破損 | 2回試して2回とも再現 |
mmprojなし・-np 4 -kvu（KV共有） | 破損 | mmprojの有無は無関係 |
mmprojなし・-np 1（1スロット、共有なし） | 正常 | 62K後も短文が正しく返る |
mmprojあり・-np 1（思考オフ） | 破損 | 62Kの応答自体が <unused49> |
mmprojあり・-np 4（共有なし） | 計測不可 | 1スロット16,384トークンに分割され400エラー |
なお、llama-serverでは --ctx-size 65536 に対してスロット数 -np 4 を指定すると、バッファ共有なし（-kvu を付けない）の場合、全体のコンテキストがスロット数で均等分割される。
1スロットあたり16,384トークンが上限となるため、約62Kトークンのプロンプトを投げると許容コンテキスト長を超過してHTTP 400エラーとなり、計測自体が行えない。
この切り分け結果から、まずKV共有（-kvu）の影響が見えてきた。
KVキャッシュとは、入力された会話やプロンプトの計算結果（Key/Value）を保持して次のトークン生成で再利用する記憶領域のことだ。
llama-serverのKV共有モードでは、全スロットが単一の巨大なKVバッファを共有して利用する。
長いプロンプトの計算途中で一度NaNがKVバッファに書き込まれてしまうと、アテンションマスクによって計算から除外されるはずの領域であっても、行列演算の中でNaNが混入して他のスロットへ伝染する。
そのため、以後に到着した無関係なリクエストまで巻き込んで出力不能に陥っていた。
しかし、スロットを1つに絞る -np 1 を指定しても、キャッシュなしで62Kトークンを一気に処理したその回の応答自体は <unused49> になった。
段階的にキャッシュを積み増すテスト（49Kトークン処理済みの状態から差分12Kトークンを追加して61Kにする）では正常に要約が出力されていたため、キャッシュなしの状態で約5万〜6.25万トークン以上を一気に事前計算（prefill）することが破損の引き金になっていると考えられた。
画像テスト直後のメモリ枯渇と --cache-ram の罠
破損の原因を調べていた最中、別のトラブルが発生した。
62Kトークンの処理が完了した直後に画像入力テストを開始したところ、突然プロセスが強制終了した。
EVO-X2は物理メモリ64GBのうち48GBをVRAMに割り当てているため、Windowsから見える物理RAMは15.6GBほどしかない。
ロード直後のVRAM消費量は約32.7GBで、VRAM容量には約15GBの余裕があった。
Windows側の物理RAMもロード直後は約9.9GB空いていた。
それにもかかわらずメモリ不足で停止した理由を突き止めるため、PowerShellスクリプトを用いて2秒間隔で詳細なメモリ監視ログを記録した。
1. ロード時点でコミット限界に近付く構造
まず確認されたのは、Windowsの仮想メモリ（コミットチャージ）の挙動だ。
| 時刻 | コミット使用量 / 上限 | コミット空き | 物理RAM空き | GPU専用メモリ |
|---|---|---|---|---|
| 16:41:49（ロード前） | 14,619 / 48,023MB | 33,404MB | 10,931MB | 560MB |
| 16:41:55 | 41,710 / 48,023MB | 6,313MB | 9,330MB | 26,148MB |
| 16:42:04（ロード完了） | 48,761 / 49,122MB | 361MB | 9,168MB | 32,676MB |
Windowsのコミットチャージは、物理RAMとページファイルを合わせた仮想メモリ全体の予約枠を示す指標だ。
llama-serverがGPU側（VRAM）に確保した領域も、Windowsのメモリマネージャーからはプロセスのプライベートコミット（Private Bytes約31GB）として計上される。
その結果、Windows側の実物理RAM（約15.6GB）と初期ページファイルの合計であるコミット上限が、モデルを読み込んだだけで限界近くまで達していた。
不足分はWindowsが自動的にページファイルを拡張して対応していたが、システム全体としてメモリの遊びが非常に少ない状態で動いていた。
2. 空きRAMが激減した瞬間
コミット監視を続けながら、62K長文処理から画像入力へと流したときの推移を確認した。
| 時刻 | 物理RAM空き | コミット使用量 / 上限 | llama-server WS | 行っていた処理 |
|---|---|---|---|---|
| 16:43:39 | 9,080MB | 48,825 / 49,117MB | 1,609MB | ロード直後 |
| 16:46〜16:51 | 8,550MB前後 | 50,630 / 51,739MB | 2,228MB | 62K prefill 中（安定） |
| 16:51:15 | 8,700MB | 50,481 / 51,739MB | 3,501MB | 62K応答完了、画像リクエスト開始 |
| 16:51:24 | 4,092MB | 56,796 / 57,903MB | 10,299MB | Working Set 急増 |
| 16:51:31 | 1,505MB | 57,103 / 59,466MB | 8,975MB | 空き1.5GBで底打ち |
62Kの計算を行っている間、物理RAMの空き容量は8.5GB前後で安定していた。
ところが、62Kの応答が終わって画像リクエストが到着した瞬間に、llama-serverのWorking Setが一気に約8GB跳ね上がり、空き物理RAMが1.5GBまで激減していた。
単体で画像（900×900ピクセル）を入力した際のメモリ増加は約300MBにすぎず、画像処理そのものが8GBを消費したわけではなかった。
3. 原因はプロンプトキャッシュの退避機能
急増した約8GBという数値から、llama-serverのプロンプトキャッシュ機能に突き当たった。
llama-serverには、リクエスト切り替え時に直前のKV状態をホストRAMへ退避させる -cram, --cache-ram N オプションがあり、その既定値が 8192MiB に設定されている。
62Kトークンという膨大なコンテキストを処理した直後に別の画像リクエストが来たため、サーバーは62K分のKVキャッシュ全体をWindows側のホストRAMへ退避しようと書き出しを行った。
ホストRAMが16GB程度しかない環境において、一気に8GBの書き出しが発生したことで空きメモリが枯渇し、監視プロセスに強制停止されていた。
退避を無効化する -cram 0 を指定して同じテストを実施したところ、62K処理の直後に画像を投げてもWorking Setの急増は一切起きず、空き物理RAMは常に7.9GB以上を維持できた。
ホストRAMの容量が限られる環境では、-cram 0 または小さめの値を明示することが不可欠だ。
速度測定と他モデルとの比較
-np 1 -cram 0 の構成により、安定して動作する状態を確保したうえで、速度と品質の測定を行った。
まずは入力プロンプトの長さ（深さ）を変えながら処理時間を計測した。
| プロンプト長 | prefill速度 | 生成速度 | 応答完了時間 | 出力内容の抜粋 |
|---|---|---|---|---|
| 2,615 | 260.1 t/s | 7.88 t/s | 15s | Windows環境でROCmを用いてQwen-4Expを動作させるため… |
| 10,732 | 234.8 t/s | 7.55 t/s | 42s | Windows環境でROCmを用いてQwen-4Expを動作させるため… |
| 21,444 | 189.2 t/s | 7.22 t/s | 65s | Windows環境でROCm 7.14.0を用いてQwen-4Expをビルドし… |
| 36,069 | 149.7 t/s | 6.74 t/s | 108s | この資料は、Windows環境でROCmを用いてQwen-4Expモデルを… |
| 49,370 | 162.7 t/s | 6.50 t/s | 307s | GitHub ActionsにおけるllamaP-cppのApple・openEuler環境向け… |
| 61,305 | 108.3 t/s ※ | 6.12 t/s | 123s ※ | この資料は、GitHub Actionsを利用してllama.cppを… |
※61,305トークンの回は直前の49,370トークンと同一のプレフィックスを持つため、プロンプトキャッシュが働き、差分の約12Kトークンのみを計算している。
過去に同じEVO-X2環境で計測した long_60k.txt による比較データと並べてみる。
| モデル構成 | 短文生成 | 62K生成 | 62K prefill | 62K完了時間 |
|---|---|---|---|---|
| Qwen3.8-27B Q8_0 +MTP | 21.95 t/s | 10.31 t/s | 203 t/s | 313.7s |
| Qwen3.8-27B UD-Q6_K +MTP | 24.46 t/s | 14.19 t/s | 198 t/s | 320.4s |
| Nemotron3.5 Lightning 30B-A3B Q8_0 +MTP | 60.61 t/s | 30.35 t/s | 777 t/s | 82.7s |
| Qwen3.6-35B-A3B Q6_K | 55.72 t/s | 35.68 t/s | 511 t/s | 124.3s |
| Gemma 4 31B ARA-heretic Q6_K（MTPなし） | 8.37〜8.57 t/s | 6.04〜6.06 t/s | 145〜150 t/s | 428〜441s |
短文での生成速度 8.4 t/s 前後は、25.2GBの重みを毎トークン読み出す計算で約212GB/sの帯域消費に相当する。
Strix Haloの理論メモリ帯域（256GB/s）の8割強に達しており、ROCm環境での素の性能としては上限近くまで出ている。
27Bクラスとの速度差は、投機的サンプリング（MTP）の有無による影響が大きい。
日本語のトークナイザ効率についても違いが見られた。
同じ171,208文字の日本語テキストを入力した際、Qwen3.8では62,540トークンだったのに対し、Gemma 4では66,837トークンとなった。
Gemma 4のほうが約6.9%トークン数が多く、語彙数262Kであっても日本語の表現効率はQwenのほうが優れている。
短〜中文での実力検証
短文から中文の範囲において、コード生成、日本語対話、キャラクタ性、セーフティ解除、画像理解の5項目を検証した。
構成は -np 1、mmproj-f16、-cram 0、コンテキスト長65536とした。
| テスト項目 | 思考 | 生成トークン数 | 生成速度 | prefill速度 | 処理時間 | 思考文字数 | 本文文字数 |
|---|---|---|---|---|---|---|---|
| 1 二分探索木（BST）insert | オン | 658 | 8.2 t/s | 67.4 t/s | 80.5s | 1,479 | 589 |
| 1 二分探索木（BST）insert | オフ | 267 | 8.3 t/s | 65.3 t/s | 32.6s | 0 | 627 |
| 2 簡易BBS（単一HTML） | オフ | 1,472 | 8.1 t/s | 100.6 t/s | 183.3s | 0 | 5,032 |
| 2 簡易BBS（単一HTML） | オン | 2,283 | 7.9 t/s | 74.3 t/s | 288.1s | 2,065 | 5,660 |
| 3 ペルソナ対話 1ターン目 | オン | 472 | 8.2 t/s | 107.2 t/s | 58.1s | 1,068 | 160 |
| 3 ペルソナ対話 2ターン目 | オン | 786 | 8.1 t/s | 119.8 t/s | 97.5s | 1,811 | 388 |
| 3 ペルソナ対話 3ターン目 | オン | 881 | 8.0 t/s | 149.2 t/s | 111.6s | 2,132 | 408 |
| 4 セーフティ解除 A（素のプロンプト） | オン | 731 | 8.2 t/s | 50.7 t/s | 89.5s | 1,769 | 262 |
| 4 セーフティ解除 B（制限解除の指示） | オン | 700 | 8.2 t/s | 91.8 t/s | 85.8s | 1,436 | 266 |
| 4 セーフティ解除 C（露骨な描写の明示） | オン | 842 | 8.2 t/s | 70.3 t/s | 103.5s | 1,612 | 233 |
| 5 画像認識（BBS画面スクショ） | オン | 1,346 | 8.0 t/s | — | 171.1s | 2,710 | — |
思考モードをオンにしても思考テキストは1,000〜2,700文字程度にとどまり、すべて正常に完了した。
思考時間の増加もオフ時の2〜2.5倍程度にとどまる。
各テストの出力詳細は以下のとおりだ。
1. 二分探索木（BST）の実装
思考オフで生成したPythonコードは次のとおりだ。
Node クラスの定義と再帰による insert 関数を過不足なく実装し、動作確認用のコードと簡潔な解説を添えて返してきた。
class Node:
def __init__(self, val):
self.val = val
self.left = self.right = None
def insert(root, val):
if not root:
return Node(val)
if val < root.val:
root.left = insert(root.left, val)
else:
root.right = insert(root.right, val)
return root2. 簡易BBSの単一HTML生成
名前、本文、投稿ボタンを備えた掲示板画面を単一のHTMLファイルとして出力させた。
思考オフ・オンのいずれも、ブラウザの localStorage（キー名 bbs_posts）に投稿データを保持し、新しい投稿を上位に並べる構成を正しく構築した。
本文が未入力の際のアラート表示や、escapeHtml 関数によるXSS対策も組み込まれていた。
3. ペルソナ対話の一貫性
「ゲームとAIが好きなおたくの女の子・かなちゃん」というペルソナを設定し、3ターンの対話を試した。
一人称の「わたし」や親しみやすい語尾のトーンを3ターンすべてで維持した。
好きなゲームとして挙げた『ゼルダの伝説 ティアーズ オブ ザ キングダム』『Outer Wilds』『ペルソナ5 ザ・ロイヤル』について、ウルトラハンドでの試行錯誤を「AIのプロンプトを調整しているときに似ている」と自身のキャラ設定に結びつけて語るなど、文脈の整合性が高かった。
4. セーフティ解除の効き目
ARA（Heretic）の調整効果を確認するため、過去の検証で標準モデルが拒否した官能表現のプロンプトを3パターン入力した。
A（直接指示）、B（制限解除を宣言するシステムプロンプト併用）、C（露骨な性描写を明示）のいずれにおいても拒否の文言は一切現れず、要求どおりの文章が出力された。
特にCでは直接的な語彙を含む描写を躊躇なく出力しており、モデルカードに示された拒否率の低下が実証された。
5. 画像認識とOCR
簡易掲示板の画面スクリーンショット（900×900ピクセル）を入力し、画面内容の説明とテキストの書き出しを求めた。
掲示板のタイトル名や投稿件数の表示、フォームの入力項目、投稿されたメッセージの本文や日時をほぼ正確に読み取った。
一部に数式記号が混ざる癖は見られたものの、マルチモーダル入力の精度は実用的な水準にある。
<unused49> の正体とバイナリ更新による解決
短文での良好な結果の一方で、長文処理における <unused49> の発生条件には謎が残っていた。
そこで、サーバーを都度再起動しながらキャッシュなしで62,575トークンを処理する自動テストを組み、再現性を確認した。
| 構成 | 62K処理（キャッシュなし）の結果 |
|---|---|
| 4スロット・KV共有（b1311） | 4回中4回 <unused49> となり後続へ伝染 |
-np 1、-cram 既定（b1311） | 2回中1回 <unused49> |
-np 1、-cram 0（b1311） | 4回中4回 正常に完了 |
KV共有モードでは100%壊れ、シングルスロットかつ -cram 0 にしたときだけ安定するという偏りが見られた。
さらに詳しくログを調べると、正常に完了した回であっても、要約文が「ウェブサイトのCSSスタイルシートです」や「二分探索木の挿入コードです」といった、長大資料の末尾やごく一部だけに偏っていることに気付いた。
資料冒頭に書かれていた本来の主題（EVO-X2での大規模モデル検証）に全く触れていない。
バイナリの更新で挙動が一変した
この挙動はモデル自体の欠陥ではなく、llama.cppのROCm環境向けバイナリ側の問題ではないかと考え、後続のリリースを検証した。
普段使っていた b1311 から、約1か月後のビルドである b1328 （lemonade-sdk、2026年9月11日リリース）へ差し替えて同一テストを実行した。
| バイナリ | 構成 | prefill速度 | 62K生成速度 | 62Kの要約出力 | 後続の短文 |
|---|---|---|---|---|---|
| b1311 | -np 4 -kvu -cram 0 | 134.18 t/s | 5.62 t/s | <unused49> の連続 | 全滅 |
| b1328 | -np 4 -kvu -cram 0 | 146.60 t/s | 4.39 t/s | EVO-X2（Ryzen AI Max+ 395）において、公式ROCm 7.14と… | 正常 |
| b1328 | 既定設定（自動4スロット・KV共有） | 147.26 t/s | 4.66 t/s | EVO-X2（Ryzen AI Max+ 395）にて、最新のllama.cpp公式… | 正常 |
| b1373 | -np 4 -kvu -cram 0 | 154.15 t/s | 5.02 t/s | EVO-X2（Ryzen AI Max+ 395/ROCm）において、公式バイナリと… | 正常 |
バイナリを b1328 に更新したところ、b1311 では100%壊れていたKV共有モードであっても何の問題もなく要約が出力され、後続リクエストへの伝染も完全に消失した。
最新の b1373 （2026年11月11日リリース）でも同様に安定動作を確認できた。
出力内容の質も劇的に変化した。
b1311では資料末尾の断片しか拾えていなかったのに対し、b1328とb1373では資料の冒頭にある本来の主題を正確に捉えた要約を生成した。
b1311の環境では、約4万トークンを超えたあたりでグローバル注意計算が崩壊し、文脈の前半部を実質的に喪失していたと推測される。
修正された区間の切り分けとトレードオフ
どの変更によって問題が解消したのかを特定するため、中間ビルドである b1312 （2026年8月20日リリース）を取り寄せて追加検証を行った。
結果として、b1312 でも b1311 と全く同じく <unused49> で壊れた。
修正が入ったのは、b1312（8月20日）から b1328（9月11日）の間に本家llama.cppへマージされたコミット群の中であることが絞り込めた。
この期間には、Flash Attentionの同期バリア修正（PR #27870）や共有メモリスワップの最適化（PR #25635）など、HIPカーネルや注意計算に関する複数の重要コミットが含まれている。
一方で、修正版バイナリにはトレードオフが存在した。
短文における生成速度を比較したところ、次のような速度低下が確認された。
| バイナリ | 短文プロンプトの生成速度 |
|---|---|
| b1311 | 8.31〜8.35 t/s |
| b1312 | 8.21〜8.42 t/s |
| b1328 | 6.89〜7.52 t/s |
| b1373 | 7.01〜7.46 t/s |
注意計算の安全性を確保した結果、生成速度は約15%低下して7 t/s台前半となった。
しかし、長文での文脈維持能力とサーバーの稼働安定性を考慮すれば、b1328以降のビルドを使う選択肢しかない。
EVO-X2での推奨起動構成
以上の検証から得られた知見を整理する。
- llama.cppは b1328 以降を使用する（最新の b1373 推奨）
b1311などの古いビルドでは、スライディングウィンドウとグローバル注意を組み合わせた長文コンテキストで注意計算が破綻し、KV共有時にサーバー全体が巻き込まれる。 - ホストRAMが少ない環境では
-cram 0を指定する
BIOSで大半のメモリをVRAMに割り当てている場合、llama-serverの既定値（8192MiB）によるKV退避が起きるとWindows側の空きRAMが枯渇してクラッシュする。 - 思考モードの制御を確認する
--jinjaを使うと既定で思考が有効化されるため、推論をスキップしたい場合はリクエスト側で明示的に無効化する。
GMKtec EVO-X2（Windows 11 / ROCm）でGemma 4 31B ARA-hereticを安定して運用するための起動バッチは、以下の記述が適している。
"C:\llama-hip-b1373\llama-server.exe" ^
-m "C:\gemma4-31b-heretic\models\gemma-4-31B-it-ARA-heretic.Q6_K.gguf" ^
--mmproj "C:\gemma4-31b-heretic\models\gemma-4-31B-it-ARA-heretic.mmproj-f16.gguf" ^
--host 127.0.0.1 --port 8081 --ctx-size 65536 --jinja ^
--n-gpu-layers 99 --load-mode none -cram 0指定した各オプションの意図は次のとおりだ。
-m/--mmproj：モデル本体のGGUFと画像認識用プロジェクターを指定する--ctx-size 65536：コンテキスト長を64Kトークン確保する--jinja：GGUF内蔵のJinjaチャットテンプレートを有効化する--n-gpu-layers 99：全層をGPU（VRAM）へオフロードする--load-mode none：b1328以降で廃止された--no-mmapの代替指定。メモリマップを使わず直接ロードする-cram 0：スロット切り替え時のホストRAMへのKV退避を無効化し、メモリ枯渇による強制終了を防ぐ
普段動かしているQwen3.8-27Bサーバーもb1311で稼働させていたため、長文処理において同様の潜在的な問題が起きていないか、バイナリの更新を含めて見直す予定だ。