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

こんにちは。ツクツクボウシが鳴き始めても、GPU はなかなか休ませてもらえませんね。

結論からお伝えします。VRAMVRAMグラフィックボードに載っている、GPU 専用の高速なメモリ。詳しく →（GPU に載っている作業用メモリ）が 12GB のカードなら、Gemma 4 の 26B A4B を llama.cpp の -ncmoe 9 で動かすのが、今のところの最適解です。 うちの検証機（RTX 4070 Ti・12GB）では 72.9 tok/s（1秒に出てくる文字のかたまりの数）が出て、12B を丸ごと GPU に載せたときの 58.6 tok/s より速く、24問テストの点数もこれまでで一番でした。26B のモデルが 12B より速く、しかも回答の質ははっきり上だったのです。

ローカル LLMLLM（大規模言語モデル）大量の文章で学習し、人のように文章を読み書きできる大きな AI のモデル。詳しく → を触っていると、12GB という数字はずっと天井として立ちはだかります。7B なら余裕、12B でもなんとか、でも 20B を超えたあたりから急に選択肢が消える。量子化量子化（Quantization）AI モデルの数値を少ない桁数で表し直して、ファイルと必要なメモリを小さくする手法。詳しく →を下げて頭を悪くするか、CPU に逃がして「1文字ずつ出てくる」速度に耐えるか。どちらも楽しくありません。今回は、その天井が思っていたより高いところにあった、という話です。ただし長考させると空の答えを返す弱点もあるので、それも後半で正直に書きます。導入の手順から知りたい方は、先に gemma4:12bはollamaで動かない — 12GB GPUでllama.cpp実測52t/sの最短ルート を読んでおくと、今回の話とのつながりが分かりやすくなります。

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

どれも Apache 2.0 ライセンスで、テキストと画像、それに動画（フレーム列として処理）を受け取れます。コンテキスト長コンテキスト長（Context Length）AI が1回のやりとりでまとめて扱える文章の長さの上限。トークン数で表す。詳しく →（一度に読める文章の長さ）は、超小型の 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 に載る量が増えていきます。

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

きれいに単調です。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 以上での挙動、複数のリクエストを同時に投げたときの落ち込み、OllamaOllama（ローカルLLMランタイム）手元の PC でオープンウェイトの LLM を手軽に動かすための、無料のソフト。詳しく → など 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問テストは当方の非公開セットのため、設問文と正解は掲載していません

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