← [ TECH / 技術部 ] に戻る
OBSERVATION · 其の4685 · 2026.06.06

Gemma 4 12B 実測|16GB で動くことを取った——Denseモデルの存在意義 と e2B/e4B/26B との対比

Gemma 4 12B 実測|16GB で動くことを取った——Denseモデルの存在意義 と e2B/e4B/26B との対比 — Gemma 4 12B, 16GB, MoE (Mixture of Experts)

こんにちは、パレイド技術部の夏目です。

Google DeepMind が Gemma 4 12B を公開しました (2026-06-04)。技術部の Gemma 4 連載を読んでくださっている方なら、今回のニュースの一行で身構えるはずです——「16GB の VRAM / 統合メモリで動き、推論性能は 26B MoE に迫る」。公開直後の速報として一度書いた記事ですが、MacBook Air M5 (32GB) で実測が取れたので、速報に実測を足して書き直しました。

テクノエッジ TechnoEdge
16GB RAMで高性能エージェントが動くGemma 4 12B、Google DeepMindが公開 26B MoEに迫る推論性能、エンコーダなしのマルチモーダル | テクノエッジ TechnoEdge
・Gemma 4 12Bはノート PC上で動作可能な高性能マルチモーダルAIモデルで、16GBのVRAMまたは統合メモリで動作する ・エンコーダーフリーのユニファイ…
www.techno-edge.net

本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI(Claude 等)の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。

この連載の通奏低音は、ずっと「32GB Mac の壁」でした。32GB でも 35B 級はブラウザを閉じてようやく、常用できる最速候補が MoE の gemma4:26b (4/4 の計測で 42.5 tok/s / VRAM 20.1GB)。「32GB をどう使い切るか」が主役の問いだったわけです。今回の 12B が本当に 16GB で 26B MoE に迫るなら、そのラインが MacBook Air のベースモデル級まで降りてくる。連載の土俵そのものが動く速報です。

先に結論から書きます。実測すると、速報の景色は少し裏返りました。新 12B は 速度だけを見ると 4 本中で最遅でした。単発で 17.3 tok/s、長文の記事生成では 26B MoE の 2.4 倍遅い。「パラメータが小さいほど速い」という直感は、MoE 相手には通りません。それでも 12B には存在意義がある——26B MoE が物理的に載らない 16GB 機で、初めて 26B 級の Dense 知能を持ち込めるからです。速さを捨て、16GB で動くことを取った。それが今回のモデルの正体でした。順番にほどいていきます。

Gemma 4 12B で何が公開されたか

techno-edge の速報から、確定しているファクトを整理します。

項目内容
公開Google DeepMind、2026-06-04
動作要件16GB の VRAM / 統合メモリ。ノート PC での動作を想定
推論性能26B MoE モデルに迫る水準
マルチモーダルテキスト・音声・ビジョンを統合。エンコーダーフリーのユニファイドアーキテクチャ
音声ネイティブ音声方式 (Gemma シリーズ初)。生の音声信号をテキストトークンと同次元の空間に直接投影
高速化Multi-Token Prediction (MTP) ドラフター搭載でレイテンシ削減
ライセンスApache 2.0
入手元Hugging Face / Kaggle
対応フレームワークTransformers / llama.cpp / MLX / SGLang / vLLM (ファインチューニングは Unsloth)

開発支援として「Gemma Skills Repository」という公式ライブラリも同時公開され、Gemma シリーズの累計ダウンロードは 1 億 5000 万を突破したとされています。

deepmind.google
Gemma — Google DeepMind
deepmind.google

まず、動かすまでに一手間ありました。手元の Ollama 0.24.0 では requires a newer version で弾かれ、pull すら通りません。新アーキテクチャ対応のため 0.30.5 へ更新して初めて pull / 実行できました。techno-edge の対応フレームワーク一覧に Ollama が載っていなかったのは、この新しさゆえと推測できます。最新版でなければ動かない——速報を読んで Air に降ろそうとした人が最初にハマる罠なので、先に記しておきます。

動いた後、Ollama のモデルカードで実体を確認できました。architecture=gemma411.9B / Q4_K_M / context 262144 / 既定サイズ 7.6GB。capabilities には completion・vision・audio・tools・thinking が並び、projector は clip 52.38M。既定タグが Q4_K_M で確定し、音声・ビジョンがモデル定義レベルで有効なことも、ここで裏が取れています。

ローカルで動かす側から見ると、今回の発表の重みは「12B という素直なサイズ」と「16GB という要件」、そして「26B MoE に迫る」という性能主張の三点が同時に成り立っている点にあります。この三つを連載の文脈に当てて、順番にほどいていきます。

単発速度の実測 — 新 12B は 4 本中で速度は最遅

まず、Gemma 4 ファミリ 4 本を横並びで測りました。環境は以下です。

項目内容
マシンMacBook Air M5 / 32GB Unified Memory
OSmacOS
ランタイムOllama 0.30.5 (0.24.0 では新 12B を弾かれる)
条件temperature 0 / プロンプト「こんにちは」/ 3 回の中央値

結果がこちらです。TTFT (Time To First Token) は最初の応答トークンが返るまでの秒数、TPS (Tokens Per Second) は生成速度、VRAM は各モデル単体ロード時の size_vram (既定 context) です。

モデルパラメータ種別TTFT(秒)TPS(tok/s)VRAM(GB)
gemma4:e2b5.1Bdense (edge)0.27675.97.1
gemma4:e4b8.0Bdense (edge)0.29240.89.8
gemma4:12b11.9Bdense (新)0.54417.38.1
gemma4:26b25.8BMoE (活性〜4B)0.37246.017.4

直感に反する並びです。総パラメータが半分以下の 12B (17.3 tok/s) が、25.8B の 26B (46.0 tok/s) より遅い。理由は連載で何度も触れてきた MoE (Mixture of Experts、推論時に一部の専門家ネットワークだけを活性化する構造) です。26B は総 25.8B でも推論時に活性化するのは 約 4B だけなので、実質 4B 級の速度で回ります。一方、新 12B は全パラメータが密結合の Dense。11.9B をまるごと使うので、edge 版の e4b (8.0B / 40.8 tok/s) より遅くなるのも理屈通りです。「小さいほど速い」は Dense 同士でしか成り立たない直感で、MoE が相手だと逆転します。

なお 26B の 46.0 tok/s は、4/4 のベンチマーク記事で測った 42.5 tok/s とほぼ整合しており、再現性のある数字として扱えます。

パレイド
Google Gemma 4 が Apache 2.0 で公開|Qwen3.5 と何が違う?デスクトップ LLM 比較の次の一手
こんにちは、パレイド技術部です。 Google がオープンソース LLM の新シリーズ Gemma 4 を Apache 2.0 ライセンスで公開しました。 h…

一つ、省メモリ方向では嬉しい意外もありました。11.9B の 12B (8.1GB) が、8.0B の e4b (9.8GB) より軽い。パラメータ数では 12B の方が多いのに、フットプリントは小さい。新世代は同パラメータ比でメモリの締まりが良くなっているようです。前稿で「16GB 動作は Q4〜Q8 のどれか」と推測した点は、既定タグ Q4_K_M / VRAM 8.1GB で確定し、16GB はおろか実質的にはかなり余裕を持って載ることが分かりました。

記事生成パイプラインで測ると、差はもっと開く

単発の「こんにちは」は短すぎて差が見えにくい面もあります。そこで実際の負荷——記事生成パイプライン (GenerationService、目標 2500 字、RAG・字数調整なし、各 1 回) でも測りました。Pass A / B / C はそれぞれ構成・本文生成・推敲に相当する段で、Pass B が長文を吐く中心の段です。

モデル合計時間Pass APass B(tok/s)Pass C生成文字数
gemma4:e2b251s17.2s31.1124.0s6081字
gemma4:e4b443s61.5s16.3196.2s6634字
gemma4:12b895s (約15分)116.8s5.8388.7s4697字
gemma4:26b370s (約6分)66.8s13.7133.8s4166字

単発で開いた差が、長文ではさらに開きます。新 12B は合計 895 秒 (約 15 分)、本文生成の Pass B は 5.8 tok/s。同じ仕事を 26B MoE は 370 秒 (約 6 分) で終えており、12B は 26B の 2.4 倍遅い。4 本中ダントツの最遅です。26B の 370 秒は過去のパイプライン記事の約 390 秒とほぼ一致し、こちらも再現性が取れています。

ここで、判定を整理しておきます。

観点gemma4:12b (Dense)gemma4:26b (MoE)16GB 機での結論
速度 (単発 tok/s)17.346.0△ 12B は遅い
速度 (記事生成)895s370s× 12B は 2.4 倍遅い
VRAM8.1GB17.4GB◎ 12B のみ 16GB に載る
知能の規模Dense 11.9B総 25.8B / 活性〜4B

全ては VRAM の行に集約されます。 26B MoE は 17.4GB を要求するので 16GB 機には載らず、12B は 8.1GB で載る。つまり 32GB 機なら速度・知能とも 26B MoE が勝ち、わざわざ 12B を選ぶ理由はありません。12B の存在意義は、26B MoE が起動すらしない 16GB 機で、初めて「26B 級の Dense 知能」を持ち込めることに尽きます。代償が速度です。「16GB で 26B MoE に迫る」の正体も、速さで並ぶことではなく、26B が動かない場所で近い知能が動くこと——土俵が違うのです。

MTP が 64GB 限定から 16GB 級へ

ここが連載読者にとって一番の続報です。5/6 の記事で、技術部は Gemma 4 の MTP (Multi-Token Prediction、複数トークンを並列予測して出力を前進させる speculative decoding の一種) を整理しました。そのとき MTP 同梱版は gemma4:31b-coding-mtp-bf1664GB のみで、「32GB Mac には物理的に乗らない、Q4 版か 64GB 機材が来るまで待ち」と結論づけたはずです。

パレイド
Ollama v0.23.1 で Gemma 4 の MTP speculative decoding が Mac 対応|32GB Mac には乗らないので「待ち」を整理する
こんにちは、パレイド技術部です。 Ollama v0.23.1 がリリースされ、Gemma 4 の MTP speculative decoding が Mac…

今回の 12B には、その MTP ドラフターが最初から内蔵されています。あの時 64GB を要求した高速化機構が、16GB 級のモデルに降りてきた——というのが正確な位置づけです。5/6 の「待ち」の続報として読むのが筋でしょう。

ただし今回の実測では、MTP の ON/OFF 効果は分離できていません。上の 17.3 tok/s や 895 秒は内蔵 MTP が効いた状態の総合値で、ドラフターを切ったらどうなるかは測っていません。Dense ゆえの遅さがこれだけ目立つ以上、MTP が無ければさらに遅いのか、それとも MTP がこの遅さを救っているのか——5/6 で議論した「速度向上が量子化・ファインチューニング・MTP head のどれの寄与か分離できない問題」は、依然として宿題のままです。MTP の実効測定は、5/6 に続いて引き続き持ち越します。

ネイティブ音声 — 連載が踏んでいないモダリティ

これまで連載が手を動かしてきたモダリティは、テキスト生成と画像/VL (OCR) の二つでした。音声は、連載がまだ一度も踏んでいない領域です。今回の 12B はここに正面から入ってきました。

技術的な要は エンコーダーフリーのユニファイドアーキテクチャです。従来は画像・音声と入力ごとに専用エンコーダを前段に置いて言語モデルへ渡す構成が一般的でしたが、Gemma 4 12B はその専用エンコーダを廃し、軽量な埋め込みモジュールでテキストと同じ流れに統合します。特に ネイティブ音声方式 (Gemma シリーズ初) は、生の音声信号を文字起こしせず、テキストトークンと同じ次元の空間へ直接投影する設計です。中間段が消えるぶん処理経路とレイテンシが短くなり、モダリティをまたいだ学習も一本化される——構造設計上の利点はこの三点に整理できます。

今回、モデルカードの capabilities に visionaudio が並び、projector も clip 52.38M として確認できました。音声・ビジョンがモデル定義レベルで有効なことまでは裏が取れています。ただし確認できたのはそこまでで、実際に入力を流して使い物になるかは測っていません。連載未踏のモダリティゆえ、ここは丸ごと次回以降の宿題です。

まとめ — 「16GB で動く」ことの意義を取った

実測で見えた 12B の輪郭は、速報のコピーより込み入っていました。速度は 4 本中最遅 (単発 17.3 tok/s、記事生成は 26B MoE の 2.4 倍)。Dense ゆえに 11.9B をまるごと回す以上、活性〜4B で済む 26B MoE には勝てません。だが VRAM 8.1GB で 16GB に載るのは 12B だけ——26B MoE (17.4GB) が起動しない領域で、初めて 26B 級の Dense 知能が動く。これが存在意義の全てです。連載の論点も「32GB をどう使い切るか → 26B MoE」から「16GB 機では MoE という回避策が使えない。そこを Dense 圧縮の 12B が埋める」へ一段降り、対象ハードが Air ベースモデル級まで広がりました。

まだ測っていないことも分けて記します。速度実測は「こんにちは」単発と記事生成パイプラインの 2 系統のみ。エージェント用途・長コンテキスト・MTP の ON/OFF 効果は未計測で、MTP の実効測定は 5/6 に続く宿題です。生成品質はスコア化しておらず、文字数を参考に出した程度。ネイティブ音声・ビジョンも「capabilities に有効と出た」までで、実入力の検証はこれからです。

速さを捨て、16GB で動くことを取った——それが実測で見えた 12B の輪郭でした。次回は、Dense の遅さを MTP がどこまで救うのか、ネイティブ音声は実用に足るのかを一つずつ潰しにいきます。壁が降りた手応えを、今度はモダリティと速度内訳の側から数字で受け取りに行きます。

━━ 観るのを再開 ━━
次の回を読む
【日本人面地形 02】青森 ── 恐山、死者の集まる山に人面を探す
技術部を一覧で
部門アーカイブ
[NEXT] FRONT · 其の4604
【日本人面地形 02】青森 ── 恐山、死者の集まる山に人面を探す
[NEXT] FRONT · 其の4605
夢十夜・序章 ── 百年後に、AIがもう一度その夢を見る。10 夜の入口と「AIが見る夢」というブランド