gemma4:12bはollamaで動かない — 12GB GPUでllama.cpp実測52t/sの最短ルート

TL;DR: gemma4:12b が ollama で動かないのは上流バグであなたのせいではない。本家 llama.cpp の docker なら 12GB GPU でも実測 52t/s で今日動く（実コマンド掲載）。ただし日本語長文の品質は上流の安定化待ち。

先に結論を書きます。gemma4:12b は 2026-06-04 時点で ollama では動きません。これはあなたの環境のせいではないです。

一方で、本家 llama.cpp の docker 経由なら 12GB GPU でも実際に動き、私の環境では 52t/s まで出ました。 ただし、日本語長文の品質はまだ安定化待ちです。ここは期待を上げすぎない方がいいです。

この記事では、ollama の上流バグを切り分けたうえで、今日動かすための最短ルートをそのまま共有します。

• gemma4:12b が ollama で止まる理由
• 12GB GPU で llama.cpp 経由に逃がす手順
• 途中で詰まりやすい 4 つのポイント
• どこまで実用で、どこから様子見か

• ollama の復旧を前提にした回避策探し
• 公式のきれいな読み物だけで終わる説明
• 日本語品質を過大評価したおすすめ

2026-06-04 時点の実測では、gemma4:12b は ollama で以下のどちらかに当たります。

1. 安定版 v0.30.3 では pull が 412 に落ちる
2. 0.30.4-rc0 / rc1 では pull 後に generate で SIGFPE

RunPod の RTX A4000 で 4 回実走して確認しました。量子化やフラグをいじっても直りません。これは自分の環境の問題ではなく、上流コード側のバグとして扱うのが妥当です。

だから、いま必要なのは「ollama を頑張ること」ではなく、別のランタイムに逃がして今日使える状態を作ることです。

ランタイム対応マップ（2026-06-04 時点）

★実測 = 本記事で実際に検証した行です。それ以外は 2026-06-04 時点の公式情報・コミュニティ報告ベースなので、最新状況は各プロジェクトのリリースノートをご確認ください。

この記事で扱うのは、NVIDIA GPU で最も手軽に動く llama.cpp 経路です。

使うのは本家の docker イメージです。

• イメージ: ghcr.io/ggml-org/llama.cpp:server-cuda
• モデル: -hf ggml-org/gemma-4-12B-it-GGUF:Q4_K_M
• 重要な回避策: --no-mmproj

Q4_K_M は 7.4GB なので、16GB はもちろん、12GB GPU にも収まります。 私の実測では VRAM 9.0GB / 12GB でした。カタログ値より少し地味ですが、実際にはこの「地味に収まる」が大事です。

実行コマンド

docker run --gpus all --rm -it \
  -p 8080:8080 \
  ghcr.io/ggml-org/llama.cpp:server-cuda \
  -hf ggml-org/gemma-4-12B-it-GGUF:Q4_K_M \
  --host 0.0.0.0 \
  --port 8080 \
  --no-mmproj \
  --ctx-size 8192 \
  --reasoning-budget 0 \
  --repeat-penalty 1.1 \
  --repeat-last-n 64

このコマンドの意味

• -hf ... : Hugging Face からモデルを取得します
• --no-mmproj : vision projector を読ませないための回避策です
• --ctx-size 8192 : コンテキストを抑えて KVキャッシュの膨張を防ぎます。これを外すと 12GB に収まらない可能性があります（実測 VRAM 9.0GB はこの設定での値です）
• --reasoning-budget 0 : 思考出力に流れて本文が空になる事故を避けます
• --repeat-penalty 1.1 / --repeat-last-n 64 : 日本語長文の無限ループ対策です

gemma4 はテキストだけのモデルとして扱うなら、vision 機能を無効化した方がむしろ安定します。

ここを外すと、導入したのに server が落ちる、あるいは 502 が延々出る、というやや嫌な流れになります。導入直後は「壊れている」のではなく、まだモデルをダウンロード中というケースも多いので、そこも切り分けが必要です。

gemma4 の vision projector は gemma4uv 形式ですが、2026-06-04 時点では llama.cpp 側が未対応です。

何が起きるかというと、-hf が自動で落としてきた mmproj を読み込む段階で、こうなります。

unknown projector type: gemma4uv

そのまま server が終了し、フロント側では 502 が続きます。

回避策

テキスト用途なら mmproj を読ませないことです。

--no-mmproj

これだけでいいです。vision を使いたい人には少し残念ですが、現時点ではそこを欲張ると先に進めません。

llama.cpp の -hf は、モデルのダウンロードが先、listen が後です。

つまり、起動してすぐに 502 が返ってきても、必ずしも壊れているわけではありません。モデル本体が 8GB 前後あるので、初回は普通に時間がかかります。

ollama だと「pull が終わってから動く」感覚が強いので、ここで fail-fast に判断すると、少し誤診しやすいです。

確認ポイント

• docker logs に download の進行が出ているか
• curl http://localhost:8080/v1/models が後で通るか
• しばらく待っても unknown projector type が出ていないか

これは驚きの結果でした。少なくとも私の環境では、repeat-penalty を外すと、長文日本語で無限ループが出ました。

具体的には、意 意 意... のような反復が伸びて、8000 トークン級まで暴走する実例を観測しています。

直し方

--repeat-penalty 1.1 --repeat-last-n 64

これを入れると、対照実験で同じ 2 問が 799 / 1036 トークンで正常終了しました。

ollama は既定でこのあたりが効いているので、普段 ollama で触っている人ほど気づきにくい差分です。

gemma4 は思考モデルです。なので、出力が reasoning_content 側に流れることがあります。

max_tokens が小さいと、本文が空っぽに見えることもあります。これ、初見だとかなり嫌です。

回避策

瞬時回答が欲しいなら、reasoning を切ります。

--reasoning-budget 0

また、/completion ではなく /v1/chat/completions を使ってください。raw 系のエンドポイントだとチャットテンプレートが効かず、出力が崩れやすいです。

速度はかなり良かったです。

• RunPod RTX A4000 16GB: 44.77 tokens/s（100% GPU）
• 自宅 RTX 4070 Ti 12GB: 52.4 tokens/s

この数字は、いつも使っている予測式でも筋が通っています。

生成速度(tokens/s) ≒ GPUメモリ帯域(GB/s) ÷ モデルサイズ(GB) × 効率(0.6〜0.85)

A4000（帯域 448GB/s）なら理論値は 448 ÷ 7.4 ≒ 60 tokens/s。実測 44.77 は効率75%でほぼ式どおりです。LLM の文章生成はメモリ帯域律速なので、モデルが VRAM に収まってさえいれば素直にこの式に乗ります。12B 級は 12GB でも体感即時です。

ちなみにこの式と「VRAM にあふれた瞬間の崖」については、BlogRunPodでGPUを時給39円で借りて実測 — 安い16GBが7.5倍割高だった結論RunPodでgemma3:27bを16GBと24GBで実測。借りるのは簡単でも、安いGPUが得とは限らない理由を数字で整理します。→で詳しく検証しています。

ここは大げさに言うより、「普通に速い」と受け取る方が実態に近いです。

品質評価も一応しました。

• 173/240
• 72.1%
• ランクB

内訳を見ると、論理 52/60、コード 52/60 はかなり良いです。なので、モデルの地力が低いわけではないです。

一方で、日本語長文では

• 分かち書きの崩れ
• 固有名詞の崩れ
• 例: 「松尾芭蕉」が「松尾芭人」になる

といった、日常運用では気になる揺れが残りました。

ここは day-one ビルドの成熟度の問題 と見るのが自然です。モデルの知能そのものを否定する材料ではありません。

2026-06-04 時点では、こう考えるのがいちばん実務的です。

• 今すぐ gemma4 を触りたい → llama.cpp 経由で試す
• コードや英語用途 → かなり実用圏
• 日本語の安定運用が最優先 → 当面は ollama 対応済みの gemma4:e4b が無難（BlogGemma 4 E2B vs E4B：速度5倍差でどちらを選ぶ？24問ベンチマーク比較Gemma 4 E2B（2B）とE4B（4B）を24問実測比較。スコア差9%・速度差5倍の実態と、VRAM 4GBで動く省電力LLMとして選ぶべき条件を整理。→）
• ollama で気持ちよく回したい → gemma4:12b は正式版（0.30.4+）対応を待つ

念のため添えると、これは「12b が e4b より劣る」という話ではありません。計測経路が違ううえ（e4b は ollama・12b は出たての llama.cpp ビルド）、12b の失点の大半は day-one ビルドの文字崩れです。地力は 12b が上、今日の安定は e4b という時点付きの使い分けです。

私は当面、ollama 正式版で再挑戦するつもりです。0.30.4+ の対応と tokenizer の安定化が入ったら、また状況は変わるはずです。

読者が次にやることは、だいたいこの 3 つです。

1. ollama 側で詰まっているなら、環境切り分けをやめて上流バグとして扱う
2. llama.cpp の docker で 12GB GPU に載るか試す
3. 日本語品質はその場で判断し、常用するかは保留する

もしチーム内で共有するなら、

• ollama では現時点で SIGFPE / 412 で止まる
• llama.cpp の docker なら 12GB でも動く
• ただし日本語長文の安定運用はまだ待ち

この 3 行で十分です。盛らない方が後で揉めません。

起動後、最低限ここまで確認してください。

curl http://localhost:8080/v1/models

応答が返れば、次に chat API を叩きます。

curl http://localhost:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gemma-4-12B-it-GGUF:Q4_K_M",
    "messages": [
      {"role": "user", "content": "日本語で一文だけ返して"}
    ],
    "max_tokens": 64
  }'

ここで短い日本語が返れば、最低限の導入は成功です。

gemma4:12b は、2026-06-04 時点では ollama で動きません。これはあなたのせいではありません。

本家 llama.cpp の docker 経由なら、12GB GPU でも実測 52t/s で動きます。 ただし、日本語長文の品質はまだ安定化待ちです。

今は「ollama を直す」より「今日使える経路へ逃がす」が正解です。正式版対応が来たら、そこでまた戻せばいい。私はその再検証も続けます。

• OS・ライブラリのバージョンが異なると手順が変わる場合があります。
• クラウドサービスは設定UIが更新されることがあり、画面が本記事と異なる可能性があります。
• 本番環境への適用前にテスト環境で動作を確認してください。

• 記事の手順を実際に実行して動作を確認しています。
• コマンドの出力例は実際の実行結果を掲載しています。

手順通りに進めても動かない場合は？

エラーメッセージをそのままコピーして検索すると解決策が見つかることが多いです。バージョン違いが原因のケースも多いため、前提条件を再確認してください。

どのOSで動作確認していますか？

記事内に記載の環境で確認しています。他のOSでの差異は適宜読み替えてください。

• BlogGemma 4 E2B vs E4B：速度5倍差でどちらを選ぶ？24問ベンチマーク比較Gemma 4 E2B（2B）とE4B（4B）を24問実測比較。スコア差9%・速度差5倍の実態と、VRAM 4GBで動く省電力LLMとして選ぶべき条件を整理。→
• BlogRunPodでGPUを時給39円で借りて実測 — 安い16GBが7.5倍割高だった結論RunPodでgemma3:27bを16GBと24GBで実測。借りるのは簡単でも、安いGPUが得とは限らない理由を数字で整理します。→
• META-MARK

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績があります。AIツールを使った個人開発や IoT 農園、Raspberry Pi を使ったオートメーション化なども実践中です。エンジニア専門結婚相談所も運営しています。ClaudeCode で解決できない心の課題も、現場目線で一緒にほどいていきます。