8GB VRAMでGemma 4 12Bを動かす:llama-cliのハイブリッドオフロード設定

8GB VRAM のマシンで Gemma 4 12B GGUF を動かすための llama-cli パラメータを整理する。GPU レイヤーオフロード、Flash Attention、8K コンテキスト、mlock、CPU スレッド制御を使い、VRAM が厳しい環境でできるだけ安定させる。

8GB VRAM で Gemma 4 12B を動かすとき、最大の問題はディスク容量ではなく実行時の VRAM です。

Q4_K_M のような GGUF 量子化版では、モデルファイル自体がすでに 8GB 近くになることがあります。実際に動かすと、さらに KV cache、一時計算バッファ、デスクトップ使用分、ドライバのオーバーヘッドが必要です。結果として、「もう少しで入りそう」に見えても、長いコンテキストを開いた瞬間に OOM になりがちです。

マシンが 8GB VRAM しかない場合、すべてを GPU に押し込むより、VRAM とシステムメモリのハイブリッドオフロードを使う方が合理的です。できるだけ多くのレイヤーを GPU に置き、残りを RAM に置いて CPU に参加させます。

推奨スクリプト

モデルパスを次のように仮定します。

1
./models/gemma-4-12b-it-Q4_K_M.gguf

Linux / macOS では run_gemma4.sh を作成します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
#!/usr/bin/env bash
set -e

MODEL_PATH="./models/gemma-4-12b-it-Q4_K_M.gguf"

./llama-cli \
  -m "$MODEL_PATH" \
  -ngl 26 \
  -c 8192 \
  -t 8 \
  --flash-attn \
  --mlock \
  -n -1 \
  --color \
  -i

実行権限を付けます。

1
chmod +x run_gemma4.sh

実行します。

1
./run_gemma4.sh

Windows では run_gemma4.bat を作成します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
@echo off
set MODEL_PATH=.\models\gemma-4-12b-it-Q4_K_M.gguf

llama-cli.exe ^
  -m "%MODEL_PATH%" ^
  -ngl 26 ^
  -c 8192 ^
  -t 8 ^
  --flash-attn ^
  -n -1 ^
  --color ^
  -i

Windows では --mlock をデフォルトで入れない方が無難です。バージョン、権限、システム構成によって挙動が変わります。まずモデルを動かすことが大事です。Linux でシステムメモリに余裕がある場合は、--mlock を優先して試せます。

なぜハイブリッドオフロードが必要か

-ngl はこの設定で最も重要なパラメータです。GPU にオフロードするレイヤー数を制御します。

1
-ngl 26

8GB VRAM では、モデル全体を GPU に入れることが目的ではありません。KV cache と実行時バッファの余裕を残すことが目的です。-ngl 26 は出発点として使えます。一部のモデルレイヤーを VRAM に置き、残りをシステムメモリで受けます。

調整方法はシンプルです。

現象 調整
起動 OOM または生成中にクラッシュ -ngl 2622 または 20 に下げる
VRAM 使用量が 6GB 前後しかない -ngl 2628 または 30 に上げる
安定しているが遅い より低 bit の量子化へ変更、または -ngl を上げる
長文コンテキストで OOM まず -c を下げ、その後 -ngl を下げる

8GB VRAM のマシンでは、モデルサイズだけを見てはいけません。モデルレイヤー、KV cache、VRAM 断片化、デスクトップ使用分を合計しても余裕があるかを見る必要があります。

--flash-attn:8GB VRAMでは有効化推奨

1
--flash-attn

このパラメータは小さい VRAM でかなり役立ちます。attention 計算のメモリ圧力を下げ、長いコンテキストの推論効率を改善します。

llama.cpp のビルド、GPU backend、GPU アーキテクチャが Flash Attention をサポートしていない場合、起動時にエラーになることがあります。その場合はまず --flash-attn を外して動くか確認し、その後で llama.cpp を更新するか CUDA / Metal / Vulkan backend の対応を確認します。

8GB VRAM では、使えるなら使う。使えないなら、まずコンテキストを下げます。

-c 8192:まず8Kコンテキストに抑える

1
-c 8192

コンテキストが長いほど KV cache は大きくなります。多くのモデルは長いコンテキスト対応をうたいますが、小さい VRAM のマシンでは上限をそのまま開くべきではありません。

8GB VRAM では、8192 が安定しやすい出発点です。日常チャット、コード断片の分析、中程度の文書処理に足り、32K や 64K のようにすぐ VRAM を使い切ることも避けやすいです。

それでも OOM する場合は下げます。

1
-c 4096

より小さい量子化版に変えて VRAM に余裕があるなら、次も試せます。

1
-c 12288

最初から最大コンテキストを追わないことです。安定させてから広げます。

--mlock:メモリのスワップアウトを減らす

1
--mlock

システムメモリに比較的余裕がある場合、このパラメータはモデルを物理メモリに常駐させ、遅い swap や pagefile へ追い出されるのを避けようとします。

ハイブリッドオフロードでは一部のレイヤーが RAM に残ります。そのページがスワップアウトされると、応答がかなり遅くなったり、カクついたりします。--mlock はそのリスクを下げます。

注意点は二つです。

  • Linux では ulimit -l や権限調整が必要な場合があります。
  • Windows ではデフォルトで有効にしなくても構いません。まずモデルを動かすことが重要です。

--mlock を有効にして起動できない場合は外します。これは安定性と速度の最適化であり、必須ではありません。

-t 8:CPUスレッド数をむやみに最大化しない

1
-t 8

-t は CPU スレッド数を制御します。ハイブリッドオフロードでは、VRAM に入らないレイヤーが CPU 計算に回るため、スレッド数が速度に影響します。

論理スレッド数ではなく、CPU の物理コア数を目安にします。

CPU 推奨
6コア12スレッド -t 6
8コア16スレッド -t 8
12コア24スレッド -t 10 または -t 12

スレッド数は多ければよいわけではありません。上げすぎると、スケジューリング、メモリ帯域、デスクトップ応答性が悪化します。物理コア数から始め、実際の tokens/s で微調整します。

-p "<|think|>\n" について

元のスクリプトには次の指定がありました。

1
-i -p "<|think|>\n"

これは慎重に扱うべきです。モデル、GGUF 変換、テンプレートによって thinking marker の扱いは異なります。<|think|> を強制的に prompt に入れても、安定して「深い思考」が有効になるとは限らず、出力形式を汚す可能性もあります。

最初は対話モードだけにする方が安全です。

1
-i

現在の Gemma 4 GGUF のモデルカードが特定のシステムプロンプトや特殊 token を要求している場合だけ、その説明に従って追加します。特定のマーカーを汎用スイッチ扱いしない方がよいです。

初回実行は保守版がおすすめ

8GB VRAM が不安定そうなら、まず保守的なスクリプトを使います。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
#!/usr/bin/env bash
set -e

MODEL_PATH="./models/gemma-4-12b-it-Q4_K_M.gguf"

./llama-cli \
  -m "$MODEL_PATH" \
  -ngl 20 \
  -c 4096 \
  -t 8 \
  --flash-attn \
  --mlock \
  -n 512 \
  --color \
  -i

このバージョンはコンテキストと GPU オフロード数を犠牲にしますが、起動しやすくなります。安定を確認したら、次に戻します。

1
-ngl 26

そして:

1
-c 8192

速度を上げたいなら、まず量子化を変える

Q4_K_M で 8GB VRAM に二十数層しかオフロードできない場合、速度は CPU とメモリ帯域に制限されます。大きく速度を上げたいなら、より小さい量子化版に変えるのが直接的です。

試せる候補は次の通りです。

量子化 特徴
Q4_K_M 品質は安定しやすいが VRAM 圧力が高い
Q3_K_L サイズが小さく、より多くのレイヤーをオフロードできる可能性
Q3_K_M さらに VRAM を節約するが品質は下がりやすい

Q3_K_M または Q3_K_L に変えたら、次を試せます。

1
-ngl 34

さらに:

1
-ngl 38

モデルの大部分が GPU に入れば、速度は大きく改善します。ただし量子化を下げるほど出力品質は下がる可能性があります。同じ prompt で比較し、tokens/s だけを見ないようにします。

メモリ帯域も重要

ハイブリッドオフロードは無料ではありません。VRAM に入らないレイヤーは CPU とシステムメモリを通るため、速度はメモリ帯域に大きく左右されます。

確認すべき点:

  • システムメモリがデュアルチャネルか。
  • DDR5 で XMP / EXPO が有効か。
  • バックグラウンドでメモリ帯域を大量に使うプロセスがないか。
  • ノート PC が高性能電源モードか。

メモリがシングルチャネルだと、ハイブリッドオフロード速度はかなり落ちます。8GB VRAM 構成では、システムメモリ容量が足りることは第一歩にすぎません。帯域も重要です。

トラブルシュートの順番

OOM が出たら、一度に多くのパラメータを変えないでください。次の順で切り分けます。

  1. コンテキストを下げる。
1
-c 4096
  1. GPU オフロードレイヤーを下げる。
1
-ngl 22

それでもだめなら:

1
-ngl 20
  1. --mlock を外す。
1
# --mlock を削除
  1. --flash-attn がエラーになる場合は、まず外して backend 対応の問題か確認する。
1
# --flash-attn を削除
  1. より低 bit の量子化モデルに変える。

毎回一つのパラメータだけ変え、tokens/s、VRAM 使用量、OOM の有無を記録します。そうしないと本当のボトルネックが分かりません。

調整表

目的 パラメータ
最も安定して起動 -ngl 20 -c 4096 -n 512
日常のバランス -ngl 26 -c 8192 -n -1
できるだけ高速化 Q3_K_M に変え、-ngl 34 以上を試す
長いコンテキスト --flash-attn を残し、-c 8192 から少しずつ上げる
メモリのスワップアウト防止 Linux で --mlock を試す

8GB VRAM で一番避けたいのは、最初から全部を最大にすることです。保守的な設定で起動し、-ngl-c を少しずつ上げる方がよいです。

まとめ

8GB VRAMGemma 4 12B Q4_K_M を動かす要点はハイブリッドオフロードです。-ngl 26-c 8192--flash-attn--mlock-t 8 から始めます。OOM する場合は、まずコンテキストを下げ、その後 GPU レイヤー数を下げます。

速度を求めるなら、Q4_K_M に固執するより Q3_K_MQ3_K_L に変える方が効果的なことが多いです。システムメモリはハイブリッドオフロードの一部の圧力を受け止めますが、体感速度を決めるのは GPU オフロードレイヤー数、KV cache サイズ、メモリ帯域です。

记录并分享
Hugo で構築されています。
テーマ StackJimmy によって設計されています。