Strix HaloのVRAM・メモリ配分を攻略する
EVO-X2でローカルLLM環境を構築したの続き。Strix Haloのメモリ配分でハマったポイントと解決策をまとめた。専用VRAMを増やすほど良いわけではない。むしろ減らしたほうがうまくいく。
関連記事:
Strix Haloのユニファイドメモリ
EVO-X2（Strix Halo）はCPUとGPUで64GB LPDDR5Xを共有するユニファイドメモリ構成。Apple Siliconと同じ発想だが、BIOSで「専用VRAM」と「メインメモリ」に明示的に分割する必要がある。
この配分がLLM推論の安定性と速度に大きく影響する。
BIOSのVRAM配分と罠
出荷時は専用VRAMが32GBに設定されている。LLMを動かすならVRAMを増やしたほうがいいと思いがちだが、実際は逆。
| 配分 | 専用VRAM | メインメモリ | 結果 |
|---|---|---|---|
| 48GB/16GB | 48GB | 16GB | ロード時にメインメモリが足りずクラッシュ |
| 32GB/32GB | 32GB | 32GB | バランス型、安定 |
| 16GB/48GB | 16GB | 48GB | 推奨。ロード安定、溢れても速度変わらず |
| 8GB/56GB | 8GB | 56GB | 実証済み。29.6GBモデルが動作 |
「共有GPUメモリから埋まる」現象
VRAM 48GB構成で起きた現象:
- 専用VRAM（48GB）はガラガラ
- 共有GPUメモリ（メインメモリ側）がパンパン
- 合計ではまだ空いているのにロードエラー
LM Studio（Vulkan）がStrix Haloを統合GPU（iGPU）と判断し、専用VRAMより共有メモリを優先的に使用する。そのためメインメモリの割り当てが小さいと簡単に詰まる。
ロード時の瞬間最大メモリ消費
モデルのロード時、データは必ずメインメモリを経由してVRAMに転送される。
ディスク → メインメモリ(一時展開・変換) → VRAM転送
↑ ここで詰まる20GBモデルをロードする場合の瞬間最大メモリ消費:
| 内訳 | 消費量 |
|---|---|
| OS基本 | 約10GB |
| モデル本体 | 20GB |
| 変換バッファ（一時的） | 20GB |
| 瞬間最大 | 約50GB |
メインメモリが16GBしかない構成では、この一時展開の段階でクラッシュする。モデルの最終的なVRAM消費量ではなく、ロード時の「通路」の広さが問題になる。
解決策
1. VRAM割り当てを減らす（逆転の発想）
BIOSで VRAM 8GB〜16GB / メインメモリ 48GB〜56GB に設定する。
- ロード時の「通路」が広くなり、クラッシュしなくなる
- 専用VRAMに収まらない分は共有メモリ（メインメモリ）に配置される
- Strix Haloはユニファイドメモリなので、共有メモリでも速度は落ちない
BIOS設定手順:
- 再起動時にESCキー連打でBIOS起動
- Advanced → GFX Configuration
- iGPU Configuration → UMA_SPECIFIED
- UMA Frame buffer size → 8G（または16G）に変更
- F10 → Save & Reset
2. 仮想メモリ（ページファイル）を増設
ロード時のスパイク対策として、SSDに仮想メモリを確保する。
- Windows検索 → 「システムの詳細設定」
- 詳細設定タブ → パフォーマンス「設定」
- 詳細設定タブ → 仮想メモリ「変更」
- 「すべてのドライブの…」のチェックを外す
- Cドライブ選択 → カスタムサイズ:
- 初期サイズ: 32768（32GB）
- 最大サイズ: 65536（64GB）
- 「設定」→ OK → 再起動
3. LM Studio設定
| 設定項目 | 推奨値 | 効果 |
|---|---|---|
| mmap（メモリマッピング） | OFF | ロード後にメインメモリ上のコピーを即解放 |
| モデルをメモリに保持 | OFF | メインメモリにバックアップを持たない |
| KVキャッシュをGPUメモにオフロード | 状況次第 | 下表参照 |
VRAM配分によってKVキャッシュの置き場所を変える:
| VRAM配分 | KVキャッシュ | 理由 |
|---|---|---|
| 48GB/16GB | ON（VRAMへ） | VRAMに余裕あり、メインメモリ節約 |
| 8〜16GB/48〜56GB | OFF（メインへ） | メインメモリに余裕あり |
実証: VRAM 8GB / メインメモリ 56GB構成
big-tiger-gemma-27b-v3-heretic-v2（29.6GB Q8_0）での実測:
| 項目 | 値 |
|---|---|
| コンテキスト長 | 35,870 |
| GPUオフロード | 25レイヤー |
| K Cache | Q8_0量子化 |
| メモリ使用 | 共有12.8GB + 専用7.7GB = 約20.5GB |
専用VRAMがたった8GBでも、LM Studioが共有メモリをGPU推論に活用して問題なく動作した。
Gemma 3のメモリ消費問題
Gemma 3は他のモデルと比べて異常にメモリを消費する。
原因は語彙サイズ（Vocab Size）の大きさ。Gemma 3は256kで、Llama 3の128kの2倍ある。コンテキスト長を伸ばすとKV Cacheが爆発的に増加する。
KV Cache量子化で対策
| 設定 | K Cache | V Cache | 備考 |
|---|---|---|---|
| 推奨 | q4_0 | f16 | Vを圧縮すると回答が崩壊しやすい |
| メモリ不足時 | q4_0 | q8_0 | Vはq4_0まで落とさない |
V Cacheの量子化はモデルの出力品質に直結する。q4_0まで落とすと文脈を忘れたり、回答がおかしくなったりする。K Cacheはq4_0まで落としても品質への影響は小さい。
Gemmaの検閲問題
Gemma系は安全性ガードレールが最も厳しいモデルファミリーの一つ。NSFW以前に、軽い話題でも「話したくない」と拒否されることがある。
abliterated/uncensored版にも限界がある。検閲レイヤーを除去しても、学習データ自体からNSFWデータが除外されているため「知識がない」状態になる。
代替モデル候補
Gemma以外でNSFW対応が期待できるモデル:
- Command R（35B）: 従順、日本語流暢、128kコンテキスト
- Mistral Nemo（12B）: 軽量、検閲緩め、日本語良好
- Llama-3.1-70B Abliterated: 最高性能、検閲なし（ただしメモリ大量消費）
現時点ではMS3.2-24B-Magnum-Diamondがバランス的にベスト。