Gemma 4 26B A4B 実測：12GBのGPUで72.9 tok/s、24問テストは過去最高スコア

VRAM 12GB。ローカルLLMを触っていると、この数字がずっと天井として立ちはだかります。

関連記事としては Bloggemma4:12bはollamaで動かない — 12GB GPUでllama.cpp実測52t/sの最短ルートollamaのHTTP 500やSIGFPEで詰まるgemma4:12bを、llama.cpp経由で12GB GPUに載せる実測手順と判断材料をまとめました。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

7Bなら余裕、12Bでもなんとか、でも20Bを超えたあたりから急に選択肢が消える。量子化を下げて頭を悪くするか、CPUに逃がして「1文字ずつ出てくる」速度に耐えるか。どちらも楽しくありません。

先日、うちの検証機（RTX 4070 Ti・VRAM 12GB）で Gemma 4 を一通り走らせたところ、その天井が思っていたより高いところにあることがわかりました。26Bのモデルが、12Bのモデルより速く動いたのです。しかも回答の質は明確に上でした。

結論を先に書きます。12GBのGPUを持っているなら、Gemma 4 の 26B A4B を -ncmoe 9 で動かしてください。 これが今のところ最適解です。

2026年4月2日に公開された Gemma 4 は、5つのサイズで出ています。噂で「34B」という数字を聞いた方がいるかもしれませんが、公式のモデル一覧にも公式のモデルカードにも 34B は載っていません。掲載されているのは次の5つです。

全モデルが Apache 2.0 ライセンスで、テキストと画像、それに動画（フレーム列として処理）を受け取れます。コンテキスト長は超小型のE2B・E4Bが128K、12B以上が256Kです。ライセンスについては、従来の Gemma 独自規約でも商用利用自体は認められていましたが、利用ポリシーによる制限が付いていました。それが業界標準の Apache 2.0 になったのは地味に大きい変更です。

今回の主役は 26B A4B です。「A4B」は Active 4B、つまり26B分の知識を持ちながら、1トークン生成するのに実際に動くのは3.8B分だけ、という意味です。128個の専門家（エキスパート）を用意しておいて、毎回そのうち8個と、常時働く共有の1個だけを呼び出す。これが MoE（Mixture of Experts）という仕組みです。

この「使わない部分が大半」という性質が、VRAMが足りない環境ではものすごく効きます。 使わないなら、VRAMに置いておく必要がないからです。

llama.cpp で MoE モデルをVRAMの少ない環境で動かす方法として、よく紹介されるのが --cpu-moe というオプションです。「エキスパートの重みを全部CPU側（システムメモリ）に置く」という指定で、これを付けると確かに12GBに収まります。

うちでも以前 33B クラスの MoE モデルを、この方法で問題なく動かしていました。だから今回も何も考えずに --cpu-moe から始めたのですが、結果は 35.0 tok/s。悪くはないけれど、期待したほどではありません。

そこで GPU のメモリ使用量を見て、目を疑いました。

3,068 MiB。

12GBのカードで、3GBしか使っていない。9GBが完全に遊んでいたのです。

考えてみれば当たり前で、--cpu-moe は「全部CPUへ」という乱暴な指定です。エキスパート以外の部分（3GB弱）だけがGPUに乗り、残りの空きは何にも使われません。せっかくのVRAMが宝の持ち腐れになっていました。

同じ12GBのカードで、使い切るかどうかだけの差。空いているVRAMはそのまま速度になる

llama.cpp には -ncmoe N（--n-cpu-moe）という、もっと細かい指定があります。「最初のN層ぶんのエキスパートだけCPUに置き、残りはGPUに載せる」という意味です。26B A4B は30層構造なので、-ncmoe 30 が実質 --cpu-moe と同じ。ここからNを下げていけば、GPUに載る量が増えていきます。

7水準を測りました。同じ機械、同じモデルファイル、同じプロンプト、生成256トークンです。

きれいに単調です。GPUに載せれば載せるほど速くなり、9で頭打ち、8で落ちる。ここが崖でした。

35.0 から 72.9。オプションの書き方を変えただけで、倍以上になりました。

比較のために、同じ機械で 12B dense を全部GPUに載せた場合も測りました。

26Bのほうが速い。 12Bを丸ごとVRAMに収めて余裕を持たせるより、26Bを限界まで押し込んだほうが速く動きます。直感に反しますが、実際にそうなりました。動いている部分が3.8B分しかないので当然といえば当然です。

なお 31B dense も試しましたが、こちらは 4.4 tok/s でした。denseモデルには「使わない部分」が存在しないため、VRAMに入りきらない分をCPUに逃がすと、その遅さがそのまま全体の遅さになります。12GB級のカードでは、31B は諦めるのが賢明です。

速さだけでは意味がないので、うちで使っている24問の日本語テストセットにかけました。引っかけ問題・論理パズル・コーディング・日本語力の4分野で、240点満点です。

同じ採点基準で測った過去のモデルの最高点が 199/240（82.9%）でしたので、明確に更新です。12GBのカードに載るモデルとしては、これまでで一番賢いという結果になりました。

論理・推論が満点だったのが印象的でした。モンティ・ホール問題、100人の囚人と帽子、12枚のコインを天秤3回で判定する問題。どれも手順を最後まで詰めて、分岐を取りこぼさずに書き切っています。特にコイン問題は、2回目の計量で「重い側と軽い側のコインを入れ替え、本物を混ぜる」という核心部分を、全分岐にわたって正しく構成していました。

正規表現の問題では、こちらが用意した正解集のほうが間違っていた箇所を、モデルが正しく答えるという場面もありました。「一見不正なメールアドレスだが、その正規表現では弾けない」という引っかけで、我々の解答キーは2ヶ月間このミスを載せていたものです。

ここからは正直な但し書きです。このモデルには、はっきりした壊れ方があります。

上の24問とは別枠で、「敵対的デバッグ」と呼んでいる高難度の追加問題を5問用意しています。JavaScriptのイベントループの出力順序、浮動小数点の誤差でループ回数が変わる問題、といったものです。ここでの得点は 50点満点で6点。ほぼ全滅でした。

しかも、間違えたのではありません。何も返ってこなかったのです。

Gemma 4 は思考プロセスを内蔵しています。難しい問題を与えると、内部で長々と検討してから答えを書く。ところが難問になるほどこの検討が止まらなくなり、出力できる上限に達したところで、答えを一文字も書かないまま終了します。

最初は私の設定が悪いのだと思いました。出力の上限を6,000トークンにしていたので、それを 4倍の24,000トークンに広げて測り直しました。結果は同じです。ある問題では思考部分だけで67,000字ぶん考えた挙句、回答欄は空でした。慣用句の誤用を指摘させる日本語の問題でも、同じことが起きています。

厄介なのは、この時APIはエラーを返さないことです。正常終了として、中身が空の応答が返ってきます。呼び出し側で finish_reason を確認していないと、「なぜか黙っている」という形でしか気づけません。空の応答を見たら、まず finish_reason を見てください。

もう一つ、実行ごとのブレが大きいという性質もあります。先ほど褒めた正規表現の問題は、実は1回目の測定では無回答でした。設定を変えて測り直したら、1,736トークンであっさり満点を取っています。同じモデル、同じ問題です。1回の結果でこのモデルの実力を断定するのは危険だと感じました。

長い思考を許すには、その分の作業メモリ（KVキャッシュ）も要ります。コンテキスト長を32,768に広げようとすると -ncmoe 9 では起動しませんでした。-ncmoe 12 まで戻せば載ります（速度は65.3 tok/s）。長考させたいなら、速度を少し譲る必要があります。

用途で分けるのが素直だと思います。

日常の相棒として使うなら -ncmoe 9。 会話、要約、翻訳、日本語の推敲、ちょっとしたコード。この範囲なら72.9 tok/s で気持ちよく動き、賢さも十分です。12Bに戻る理由がありません。

難しい問題を長考させたいなら -ncmoe 12 + コンテキスト長を広げる。 速度は落ちますが、途中で打ち切られて空手で帰ってくる確率は下がります。それでも返ってこない問題は返ってきません。

厳密な出力順序や桁レベルの正確さが要る作業には向きません。 敵対的デバッグの結果がそのまま出ています。そういう用途は素直に大きいモデルか、クラウドのAPIに任せたほうが早いです。

最後に、この記事で測っていないことも書いておきます。検証したのは RTX 4070 Ti の1台だけです。 同じ12GBでも 3060 や 4070 はメモリ帯域が違うので、最適な -ncmoe の値も、そこで出る速度も変わるはずです。ここは未実測で、推測でしかありません。VRAM 16GB 以上での挙動、複数リクエストを同時に投げたときの落ち込み、Ollama など llama.cpp 以外のランタイムでの再現性も今後の検証候補として残しています。読者の環境で数字が違っても、それは失敗ではなく、単に条件が違うだけだと思ってください。

VRAM 12GB は、もう「12Bまでの世界」ではなくなりました。MoEという構造と、-ncmoe というオプション1つで、26Bクラスが実用速度で手元に降りてきています。同じカードをお持ちなら、一度 --cpu-moe を -ncmoe 9 に書き換えて、GPUのメモリ使用量を眺めてみてください。まだ余っているなら、それはそのまま速度になります。

仕様・ライセンス・公開日は、2026年8月28日時点で以下の一次情報を実際に開いて確認しています。

• Gemma 4 公式発表
• モデル概要 — サイズ構成・コンテキスト長
• モデルカード — エキスパート構成・モダリティ別の対応範囲
• Apache 2.0 化の告知（公開日 2026年4月2日） — URLに 2026/03 と入っていますが、記事に表示される公開日は2026年4月2日です
• 使用したモデル: google/gemma-4-26B-A4B-it-qat-q4_0-gguf および google/gemma-4-12B-it-qat-q4_0-gguf（Hugging Face・公式QAT量子化版）、31B は unsloth/gemma-4-31B-it-qat-GGUF
• 検証日: 2026年8月27日
• 検証環境: NVIDIA GeForce RTX 4070 Ti（VRAM 12GB）/ システムメモリ 32GB / Ubuntu 24.04 / llama.cpp（CUDAビルド・Gemma 4 対応版）
• 速度計測: llama-server の /completion が返す timings.predicted_per_second。生成256トークン・temperature 0.1・Flash Attention 有効
• 24問テストは当方の非公開セットのため、設問文と正解は掲載していません

• Bloggemma4:12bはollamaで動かない — 12GB GPUでllama.cpp実測52t/sの最短ルートollamaのHTTP 500やSIGFPEで詰まるgemma4:12bを、llama.cpp経由で12GB GPUに載せる実測手順と判断材料をまとめました。→
• BlogOllama導入の罠と解決手順——GPU認識・日本語チャットまでの全記録と結論RTX 4070 Ti搭載の自宅サーバーにOllamaをSSHでセットアップした実録。非対話環境でのインストール罠、バイナリ直接DL、systemdサービス化、qwen2.5:7bでの日本語チャットまで。→
• BlogGoogle Gemma 4が変えたこと——Apache 2.0と本格マルチモーダルで「使えるオープンモデル」の基準が上がったGoogle DeepMindが2026年4月にリリースしたGemma 4の実力を整理する。Apache 2.0への変更、E2B〜31Bの4モデル構成、画像・動画・音声対応のマルチモーダル実装、そしてQwen 3.5やDeepSeek V3.2との比較まで。「ローカルで動かして本当に使えるか」という目線で書く。→

• 実際の構成を探すなら、GPU 比較ページやローカルLLM向け構成記事もあわせて見ると判断しやすいです。
• ハードウェア候補は用途別の AI 構成ガイドからたどると、単体製品より違和感なく検討できます。

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