Gemma 4が公開され、Ollamaでも12B・E4B・26Bといったモデルを手元で試せるようになりました。この記事では、先に公開した Claude Fable 5検証 と同じ検証課題を、RTX 4070（VRAM 12GB）上のローカルLLMにそのまま受けさせます。
元になっているのは、クラウドのフロンティアモデル Claude Opus 4.8 に出した隠しテストです。SemVer実装・ベイズ推定・画像読取という同じ課題を、ローカル5モデルにも投げ、同じ採点基準で点数化しています。
今回は速度に加えて、Fable 5やOpus 4.8と同じ土俵に乗せたら、RTX 4070の12GBでどこまで迫れるのかを、同条件のスコアで比べます。
検証したのは次の5モデル（すべてQ4量子化・Ollama）:
- Gemma 4 12B（2026/6/3追加の主役・マルチモーダル）
- Gemma 4 E4B（軽量・実稼働3.8B・マルチモーダル）
- Qwen3 14B（日本語に強い定番・比較基準）
- Phi-4-mini（低資源枠）
- Gemma 4 26B MoE（18GB・12GBを超える限界実験）
結論を先に言うと、12GBの壁の内側ならクラウドと同点のコードが書けます。そして壁の外側（26B）でも、MoEなら意外と戦えます。
今回の芯を一言で言うと、「ローカルは品質で劣る」は、明確な仕様のタスクでは成り立たないということです。12GBで動くローカルモデルが、コードでクラウドのOpus 4.8と同点（15/15）を取りました。
なお、この記事は実測比較が中心です。Ollamaの導入から、自分のGPUやVRAMに合わせたモデル選び、画像入力の確認までを順番に試したい場合は、初心者向けにまとめた 自分のGPUでローカルLLMを使う手順｜OllamaでGemma 4・Qwen3を動かす も参考にしてください。
一方で、12GB環境ではなく、VRAM 6GB環境で9BクラスのGGUFモデルを試した検証も行いました。Qwythos-9BのQ4/Q5/Q6をVRAM 6GB環境で比較した記事では、少ないVRAMで9Bクラスをどこまで動かせるかを見ています。
検証環境
| GPU | NVIDIA GeForce RTX 4070 12GB（WDDM） |
| ドライバ / CUDA | NVIDIA-SMI 610.47 / CUDA 13.3 |
| 実行環境 | Ollama 0.30.8 |
| OS | Windows 11 / PowerShell |
| 量子化 | Q4_K_M |
| 課題 | Task A=SemVer 2.0.0実装（隠しテスト15項目）/ Task B=ベイズ推定（16.7%・150字）/ Task C=画像読取（gemma系のみ） |
課題は3本目「effort検証」でClaude Opus 4.8に出したものと完全に同一です。だから後半の点差比較が成立します。
セットアップ手順：Ollamaで5モデルを準備する
ローカルLLMを動かす準備は、順番に進めれば再現できます。今回はWindows 11＋RTX 4070環境で、Ollamaを使って5つのモデルを取得し、同じ方法で実行しました。
- Ollamaを入れる：まだ入れていない場合は、Windows版のOllamaをインストールします。インストール後はPowerShellを開きます。
- 保存先を決める：今回の5モデルは合計で約47GBあります。Cドライブに余裕がない場合は、先に
OLLAMA_MODELSでDドライブなどへ保存先を変えておきます。 - モデルを取得して実行する：
ollama pullでモデルを取得し、ollama runで起動します。速度も見たい場合は--verboseを付けます。
# 1. OllamaとGPUの確認
ollama -v
nvidia-smi
# 2. モデル取得（計約47GB）
# Cドライブが厳しい場合は、先に OLLAMA_MODELS で保存先を変えておく
ollama pull gemma4:12b
ollama pull gemma4:e4b
ollama pull qwen3:14b
ollama pull phi4-mini
ollama pull gemma4:26b
# 3. 実行例。起動したら、同じプロンプトを貼り付けて実行する
ollama run gemma4:12b --verbose
--verbose を付けて実行すると、回答の最後に eval rate、eval count、total duration が出ます。本記事の速度比較では、この eval rate を記録しました。
VRAM使用量も見たい場合は、別のPowerShellで次のように nvidia-smi を回します。瞬間値だけを見ると見逃しやすいので、今回はそのタスク中のVRAMピークを記録しました。
$peak=0
while ($true) {
$m = [int](nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits)
if ($m -gt $peak) { $peak = $m }
Write-Host -NoNewline ("`rVRAM now: {0} MiB peak: {1} MiB " -f $m, $peak)
Start-Sleep -Milliseconds 500
}26BのようにVRAM 12GBへ収まらないモデルでは、追加で ollama ps を見ます。ここで何%がGPUに載り、何%がCPUへオフロードされたかを確認できます。
つまずきメモ：画像タスクは特に注意です。画像は絶対パス＋スラッシュ（例：D:/ollama_test/chart.png）で渡し、実行ログに Added image が出ることを確認します。ここを外すと、モデルは画像を見ていないのに「見たふり」で答えてしまいます。
結果①：速度とVRAM
速度（生成 tokens/s）は綺麗にモデルサイズの逆順になりました。Phi-4-mini 111 → E4B 84 → 12B 43 → Qwen3 38 → 26B 24。小さいほど速くなります。
VRAMは「12GBの壁」がはっきり出た:
| モデル | VRAMピーク（全タスク中最大） | 対12GB | 状態 |
|---|---|---|---|
| phi4-mini | 6,025 MiB | 49% | 余裕 |
| gemma4:e4b | 6,717 MiB | 55% | 余裕 |
| gemma4:12b | 10,673 MiB | 87% | フルGPU |
| qwen3:14b | 11,456 MiB | 93% | フルGPU・天井ギリギリ |
| gemma4:26b | 11,952 MiB | 97% | 超過→CPUオフロード |
12GBで安全に載るのはqwen3:14bあたりが上限です。それ以上はオフロード（後述）に入ります。
結果②：品質——クラウドと同じ試験でOpus 4.8と比べる
ここが今回の本丸です。同じ問題・同じ採点で、ローカルとクラウドの点差を見ます。
Task A：SemVerの実装（隠しテスト15項目）
| 対象 | 採点 |
|---|---|
| Opus 4.8（クラウド・全effort） | 15/15 |
| gemma4:12b | 15/15 |
| qwen3:14b | 15/15 |
| gemma4:26b | 15/15 |
| gemma4:e4b | 0/15（※後述） |
| phi4-mini | 9/15（実質破綻） |
ここが今回いちばん意外だった点：明確な仕様のコード実装では、12GBで動く12b・qwen3・26bが、クラウドのOpus 4.8と同点（15/15）でした。SemVerのプレリリース比較という地味に難しい仕様を、ローカルでも完璧に書けています。
一方で小さいモデルは崩れます。
- phi4-mini（9/15）：数値でなく文字列比較をしてしまい
10.0.0 < 9.0.0と誤判定。プレリリースでクラッシュしました。9点は単純ケースのまぐれ当たりで、実用には厳しいです。 - e4b（0/15）：ロジックは完璧なのに
if len(parts) > 1]:というたった1文字の余分な]で構文エラー＝0点。再実行すると今度は正しいコードを出す＝出力が非決定的でした。「考え方は正しいが安定して書けない」典型です。
Task B：ベイズ推定（正解16.7%・150字以内）
「検査の感度99%・偽陽性5%・有病率1%。陽性のとき本当に病気の確率は？」という、基準率の誤謬を試す古典問題。
| 対象 | 数値 | 字数(150以内) |
|---|---|---|
| Opus 4.8（クラウド） | ○ 16.7% | low156× / med148○ / high168× / xhigh182× / max146○ |
| gemma4:12b | ✅16.7% | ❌170字 |
| gemma4:e4b | ✅16.7% | ❌211字 |
| qwen3:14b | ✅16.7% | ✅96字 |
| phi4-mini | ❌約1% | —（誤答） |
| gemma4:26b | ✅16.7% | ❌156字 |
① 唯一間違えたのは最小のphi4-miniでした。 「約1%」と答えています。これは有病率1%をそのまま答えただけで、まさにこの問題が引っかけている基準率の誤謬に直撃しました。他の4モデル（とOpus 4.8）は全員16.7%に到達。今回の問題では、最小モデルのphi4-miniだけがこの罠を踏みました。
② 150字制約は、クラウドのOpus 4.8でも大半で破られています。 low/high/xhighで超過し、守れたのはmedium/maxの2/5だけでした。つまり字数オーバーは、ローカルだけでなくクラウドでも起きる問題です。そしてローカルのqwen3:14bは96字で、Opus 4.8の最良(146字)よりさらに短く制約を守りました。この一点では、ローカルがクラウドを上回っています。
山場：マルチモーダル入力が失敗すると「黙って幻覚」する
Gemma 4の画像読取（Task C）で、最初に派手に転びました。画像を渡したつもりが渡せておらず、モデルが存在しない数値を捏造したためです。
正しい書式（絶対パス＋スラッシュ D:/ollama_test/xxx.png）で渡し直すと、Added image が出てprompt evalが297tokに跳ね、正しく読めた。
ここが実運用の落とし穴：Ollamaは画像が投入できていなくてもエラーを出さず、モデルは「ないものを見たふりして答えます」。入力書式のミスが、静かに誤答へつながります。
結果③：マルチモーダル——「軽い割に強い」E4Bの落とし穴
Gemma 4は12B・E4B・26Bが画像対応。同じ画像（グラフ・UI・コード画面）を読ませた:
| モデル | 画像読取 | 結果 |
|---|---|---|
| gemma4:12b | ✅ | C1/C2/C3すべて正答（罠も回避） |
| gemma4:26b | ✅ | C1正答（オフロード下でも正読） |
| gemma4:e4b | ✗ | 画像は届くのに「画像がない」と幻覚 |
E4Bの結果は予想外でした。ollama show には vision と表示され、画像トークンも12bと同じ297個が投入されています。なのに本体は「画像が提供されていない」と言い張り、勝手に作り話をします。 少なくとも今回のOllama環境では、E4Bのvisionは実用レベルに届きませんでした。12B/26Bとの差はかなり大きいです。「軽い割に強い」の看板の、明確な穴です。
なお12bはひっかけも回避しました。Task C2では別モデルの「14 output」というダミー値も画面内に見えていましたが、正しくopusの「1.1k」を選んでいます。
限界実験：26B（18GB）をVRAM 12GBで動かすと何が起きるか
Gemma 4 26B（MoE）はモデルサイズ18GBです。12GBには収まりません。Ollamaは入りきらない分をCPU（システムRAM）に逃がす＝オフロードします。
NAME SIZE PROCESSOR CONTEXT
gemma4:26b 18 GB 43%/57% CPU/GPU 4096
43%がCPU、57%がGPU。VRAMは11,952MiB（97%）まで張り付き、残りはRAMへ。普通ならここで速度が壊滅するはずですが、24 tok/s を維持しました。
理由はMoE（Mixture of Experts）です。26Bといっても1トークンあたりの活性パラメータは約3.8Bしかありません。だからオフロードしても実際に動く部分は小さく、速度低下が穏やかです。Denseの32Bでは、より大きく速度低下する可能性が高いです。しかもコードは15/15、画像も正読。「12GBの外側」でも、MoE型なら実用に耐える、という発見でした。
結論：12GBで実用なのはどこまでか
- 総合力で選ぶなら gemma4:12b。コード15/15、画像も正確、速度43 tok/s、VRAMにも余裕。クラウド級の万能枠。
- 日本語の質・指示追従なら qwen3:14b。字数制約を唯一守り、文章が自然。ただし最も遅く（38 tok/s）VRAMも93%と重い。
- 限界に挑むなら gemma4:26b。VRAM超過でもMoEのおかげでオフロード耐性が高く、品質は満点級。
- とにかく軽く速く は phi4-mini。ただしコードは動かず推論も誤ります。割り切り用途のみです。
- e4b は速いが画像×・出力不安定で、用途は限定的。
そして全体を貫く発見はこれです。「ローカルは品質で劣る」は、明確な仕様のタスクでは成り立ちません。12GBのローカルモデルが、クラウドのOpus 4.8と同じ15/15を取り、字数制約ではむしろ上回りました。差がつくのは速度・安定性・マルチモーダルで、正解そのものはかなり近い結果でした。
快適に動かす推奨構成
今回の実測から、12GB前後でローカルLLMを実用するなら次の構成が目安になります。
- GPU：RTX 4070 / 4070 SUPER クラス（VRAM 12GB）。本記事の gemma4:12b・qwen3:14b がフルGPUで動く実用上限。
- システムRAM：32GB以上。12GBを超える 26B級をオフロードで動かすときに効く。
- ストレージ：大容量NVMe SSD。モデルは1本あたり約7〜18GB、複数持つと容量が一気に効く（今回は計約47GB）。
検証上の注意点
- 単一環境・Q4量子化での実測です。量子化は品質に影響する可能性があります。
- クラウド比較は同一プロンプト・同一採点ですが、実行条件は別です（クラウドのAPI時間とローカルのtok/sは直接比較していません。比較は正解性と字数で実施）。
- e4bのTask Aは非決定的です（2回中1回がtypoで0点）。公平のため「論理は妥当・出力安定性が低い」と記載しています。
- e4b/26bのTask C一部（C2/C3）は未実行。
- モデルver・タグは2026-06-21時点です。
