【実測】Gemma 4 は RX 9070 XT 16GBでどこまで動くか。5サイズ全部試したら31Bだけ崖だった

GoogleのGemma 4は、E2B / E4B / 12B / 26B A4B / 31B という5つのサイズで公開されている。だが「自分のGPUではどれが動くのか」を実測した日本語の情報が見当たらない。

そこで、RX 9070 XT（VRAM 16GB）で5サイズ全部を動かして計測した。

結論から言うと、16GBに全部載るのは12Bまでで、26Bと31Bは溢れる。ところが溢れたあとの挙動が両者でまったく違い、26Bは実用範囲の30 tok/sを保つのに、31Bは4 tok/sまで落ちる。溢れ方はほとんど同じなのに、である。

この記事では、その理由まで含めて実測値で示す。

【結論】16GBならE4Bが最適解、31Bは選ぶ意味がない
【最初の誤解】ダウンロード7GBでも、VRAMは1.7GBしか使わない
1. さらに変なこと: 12Bのほうが E2B より小さい
Gemma 4の5サイズとは
計測環境と方法
【本題】溢れたあと、MoEとDenseで7.4倍の差がついた
1. 速度の落ち方は緩やかで、31Bだけが崖
2. 溢れると初回ロードも遅くなる
パラメータ数を見ても速度は分からない
賢さと速度の交換レート
実際の出力を並べてみる
この計測の限界
どうしてもVRAMが足りないと感じたら
まとめ
お断り
参考文献

【結論】16GBならE4Bが最適解、31Bは選ぶ意味がない

サイズ	生成速度	VRAM使用	全部GPUに載るか
E2B	98.5 tok/s	1.70 GB	○
E4B	74.7 tok/s	3.21 GB	○
12B	49.3 tok/s	7.83 GB	○
26B (MoE)	29.5 tok/s	14.57 / 18.54 GB	✗（GPU 78.6%）
31B (Dense)	4.0 tok/s	14.51 / 20.97 GB	✗（GPU 69.2%）

用途で選ぶならこうなる。

やりたいこと	選ぶべきサイズ	理由
常駐させて即答させたい	E2B	98.5 tok/s。VRAMを1.7GBしか使わないので他の作業と同居できる
迷ったらこれ	E4B	74.7 tok/s。速度と賢さのバランスが最も良い
賢さ重視・長文を書かせる	12B	49.3 tok/s。16GBに”全部載る”最大サイズ
品質最優先・長い文脈を扱う	26B	29.5 tok/s。溢れても実用範囲。文脈は256K
—	31Bは非推奨	4.0 tok/s。16GBでは待ち時間が長すぎる

【最初の誤解】ダウンロード7GBでも、VRAMは1.7GBしか使わない

多くの人がつまずくのがここだ。

ollama pull gemma4:e2b で落ちてくるファイルは7.16GBある。「VRAM 16GBだから2つも動かせないな」と思うだろう。ところが実際に動かしてVRAMを見ると、1.70GB しか使っていない。E4Bも9.61GB落として、使うのは3.21GBだ。

理由は公式モデルカードに書いてある。E2B / E4B の「E」はeffective（有効）パラメータの意味で、これらのモデルには PLE（Per-Layer Embeddings） という仕組みが入っている。

PLE は、モデルにレイヤやパラメータを追加するのではなく、各デコーダレイヤにすべてのトークンに対して独自の小さなエンベディングを与えます。これらのエンベディングテーブルは大きいですが、高速ルックアップにのみ使用されます。 — Gemma 4 モデルカード

つまり E2Bは「合計5.1B・有効2.3B」、E4Bは「合計8B・有効4.5B」。ファイルとしては大きいが、推論で実際に抱える量はずっと小さい。

ダウンロードサイズを見て諦めるのは早い。 これが最初に伝えたいことだ。

さらに変なこと: 12Bのほうが E2B より小さい

サイズ	パラメータ	ダウンロード
E2B	5.1B	7.16 GB
12B	11.9B	7.56 GB

パラメータが2倍以上なのに、ファイルサイズはほぼ同じである。

これも公式に説明がある。12Bは「Unified」＝エンコーダなしアーキテクチャだ。他のモデルが画像・音声用の専用エンコーダを別に積んでいるのに対し、12Bはそれを廃して、画像パッチと音声波形を軽い線形レイヤでLLMの埋め込み空間へ直接流し込む。だからVisionエンコーダもAudioエンコーダも「-」になっている。

E2Bは「本体は小さいがPLEとエンコーダで嵩む」、12Bは「本体は大きいがエンコーダを持たない」。結果としてファイルサイズが並ぶ、というわけだ。

Gemma 4の5サイズとは

2026年4月にGoogle DeepMindが公開したオープンモデルで、ライセンスはApache 2.0。商用利用も改変も再配布もできる。

項目	E2B	E4B	12B Unified	26B A4B	31B Dense
合計パラメータ	2.3B有効(5.1B)	4.5B有効(8B)	11.95B	25.2B	30.7B
アクティブ	—	—	—	3.8B	—
レイヤ	35	42	48	30	60
コンテキスト長	128K	128K	256K	256K	256K
対応入力	テキスト/画像/音声	テキスト/画像/音声	テキスト/画像/音声	テキスト/画像	テキスト/画像
Visionエンコーダ	約150M	約150M	なし	約550M	約550M
Audioエンコーダ	約300M	約300M	なし	なし	なし

（Gemma 4 モデルカードより）

数字のずれについて。 ollama show は 26B を 25.8B、31B を 31.3B と表示する。これはVisionエンコーダ（約550M）を含んだ値で、上表のGoogle公式値（本体のみ）とは約0.55Bずれる。本記事の表記は公式値に統一した。

音声入力に対応するのは E2B / E4B / 12B の3つだけで、26Bと31Bは非対応。上位モデルほど何でもできる、という単純な話ではない。

そして注目すべきが 26B A4B の構成だ。合計25.2Bのうち、推論時にアクティブになるのは3.8B。128個のエキスパートのうち8個（＋共有1個）だけを使うMixture-of-Experts方式である。

公式はこう書いている。

推論時に 4B のパラメータのサブセットのみをアクティブにすることで、この Mixture-of-Experts モデルは、合計 26B のパラメータよりもはるかに高速に実行されます。4B パラメータモデルとほぼ同じ速度で実行されるため、高密度 31B モデルと比較して高速な推論に適しています。

この記述が16GB環境で本当かどうかを、次で確かめる。

計測環境と方法

環境

項目	値
GPU	AMD Radeon RX 9070 XT（ROCm認識名 `gfx1201`）
VRAM	15.9 GiB（Ollamaが報告した値）
推論バックエンド	ROCm（`rocm_v7_1`）
GPUドライバ	32.0.31035.1003
CPU / RAM	Ryzen 9 7900X / 64GB
OS	Windows 11
Ollama	0.32.5

Ryzen 9 7900Xの内蔵GPUは、ROCm側で「rocblas非対応（gfx1036）」、Vulkan側でも「統合GPUを除外」として自動的に外れている。dGPU 1枚だけを使った計測だ。

方法

すべて Q4_K_M 量子化の既定タグを使用。プロンプトは固定で、日本語の説明文を書かせるもの。

num_predict=256 / temperature=0 / seed=42
ウォームアップ1回のあと3回計測して中央値を採用
モデルを切り替えるたびにアンロードし、VRAMを空にしてから次へ
VRAM配置は生成直後に Ollama の /api/ps から取得（size と size_vram）

3回計測のばらつきは全モデルで±3%以内に収まった。

再現するときの注意点

1つ目。think を切らないと、生成した分が全部消える。

Gemma 4は思考モードが既定で有効になっている。何も指定せずに /api/generate を叩くと、こうなった。

eval_count: 256 / done_reason: length
response : ""
thinking : ""

256トークン生成したのに、本文も思考も空である。思考ブロックが256トークン以内に閉じず、どちらのフィールドにも入らなかったためだ。"think": false を指定して初めて日本語の答えが返る。この記事の計測はすべて think:false で行っている。

2つ目。この環境は OLLAMA_KV_CACHE_TYPE=q8_0 が設定されている。

既定の f16 ではなくKVキャッシュを圧縮した状態なので、素の環境より少し有利に出ている可能性がある。長い文脈を扱うときほど差が出るはずだ。

【本題】溢れたあと、MoEとDenseで7.4倍の差がついた

ここが今回いちばん面白かったところだ。

項目	26B A4B (MoE)	31B (Dense)
必要メモリ	18.54 GB	20.97 GB
VRAMに載った量	14.57 GB	14.51 GB
GPU占有率	78.6%	69.2%
CPU側に溢れた量	3.97 GB	6.46 GB
生成速度	29.5 tok/s	4.0 tok/s

VRAMに載った量は0.06GBしか違わない。 どちらも同じように16GBの壁を越えて、CPU側に溢れている。それなのに速度は7.4倍違う。

理由はMoEの構造にある。26Bは毎トークンで3.8B分のエキスパートしか使わないので、CPU側に置かれた重みを読みに行く回数がそもそも少ない。一方31B Denseは毎トークンで全30.7Bを使うため、CPU側の6.46GBに毎回アクセスする。PCIe越しの往復が1トークンごとに発生し、それがそのままボトルネックになる。

Googleが「4Bモデルとほぼ同じ速度で走る」と書いていたのは、VRAMからはみ出した状態でも成り立つということだ。

速度の落ち方は緩やかで、31Bだけが崖

遷移	速度の残り
E2B → E4B	76%
E4B → 12B	66%
12B → 26B	60%
26B → 31B	13%

E2Bから26Bまでは、サイズを上げても6〜7割ずつ緩やかに落ちていくだけだ。ところが26B→31Bで一気に13%になる。16GB環境における実質的な限界は、ここにある。

溢れると初回ロードも遅くなる

全部GPUに載る3モデルの初回ロードは18〜23秒。対して26Bは48秒、31Bは54秒かかった。2倍以上である。使い始めの待ち時間としても効いてくる。

パラメータ数を見ても速度は分からない

26B（25.2B）が31B（30.7B）より7.4倍速い時点で、パラメータ数と速度は比例しないことが分かる。16GB機でモデルを選ぶときに見るべきは、パラメータ数ではなく次の2つだ。

実行時サイズが VRAM に収まるか（収まれば速い）
収まらないなら、MoEかDenseか（MoEなら溢れても戦える）

賢さと速度の交換レート

Googleが公開しているベンチマーク値と、今回の実測速度を並べるとこうなる。

サイズ	MMLU Pro	LiveCodeBench v6	実測速度
E2B	60.0%	44.0%	98.5 tok/s
E4B	69.4%	52.0%	74.7 tok/s
12B	77.2%	72.0%	49.3 tok/s
26B	82.6%	77.1%	29.5 tok/s
31B	85.2%	80.0%	4.0 tok/s

（ベンチマーク値はGemma 4 モデルカードより）

31Bは26Bより MMLU Pro で2.6ポイント賢いだけなのに、7.4倍遅い。 16GBのGPUでこの交換レートを受け入れる理由は、ちょっと思いつかない。

逆に12Bの位置づけが良い。MMLU Proで77.2%とE4Bを7.8ポイント上回りながら、49.3 tok/sを保っている。しかもLiveCodeBenchでは72.0%と、26B（77.1%）に肉薄する。コードを書かせるなら12Bは有力だ。

実際の出力を並べてみる

同じプロンプト（「ローカルLLM初心者にVRAMの重要性を専門用語なしで説明して」）に対する冒頭部分。

E2B（98.5 tok/s）

ローカルLLMを始めるにあたって、GPUのVRAM容量がなぜ重要なのかを、専門用語をなるべく使わずにご説明しますね。

まず、LLM（大規模言語モデル）というのは、たくさんの言葉や知識を学習して人間のように自然な文章を作ったり、質問に答えたりするような、非常に賢いコンピュータープログラムのことです。この賢いプログラムを自分のパソコンの中で動かすためには、そのプログラムが使う「作業スペース」が必要になります。

この「作業スペース」のことをVRAM（ビデオメモリ）と呼びますが、これはGPUという高性能な部品が持っている、データを一時的に置いておくための非常に重要な場所だと考えてください。

LLMを動かすというのは、たくさんの知識や計算を同時に行う作業に似ています。この作業を行うためには、その情報や計算結果を一時的にどこかに保存しておく必要があります。VRAMの容量は、この「作業スペース」の

E4B（74.7 tok/s）

ローカルLLMの世界へようこそ！これから「VRAM」という言葉が出てきて戸惑うかもしれませんが、これは難しく考える必要はありません。一番身近な例えを使って、なぜこの「VRAMの容量」が大切なのかを説明しますね。

まず、LLM（大規模言語モデル）というのは、とても賢いけれど、同時にものすごく大きな計算をする機械だとイメージしてください。そして、その計算を行うためのメインの作業スペースが、お使いのグラフィックボード（GPU）に搭載されている「VRAM」なんです。

このVRAMを、あなたが机の上で何か作業をするための「机の広さ」だと考えてみてください。

もし、あなたがすごく大きな企画書や、たくさんの資料を同時に開いて、それらを組み合わせて新しいアイデアを出そうとしているとしますよね？そのとき、机が狭すぎるとどうなりますか？必要な資料を出すたびに、他のものを片付けたり、どこに置いたか

12B（49.3 tok/s）

ローカルLLM（自分のPC内で動かす人工知能）の世界へようこそ。これから学習を始めるにあたって、まず最初に突き当たる壁が「GPUのVRAM（ビデオメモリ）」という言葉です。なぜこの容量がこれほど重要視されるのか、その理由を分かりやすくお話しします。

一言で言うと、VRAMは「AIが思考するための作業机の広さ」だと考えてください。

私たちが文章を書くとき、頭の中にある知識をすべて一度に机の上に広げて整理しながら書くことはできませんよね。しかし、AI（LLM）の場合、モデルそのものが非常に巨大なデータとして存在しています。この「モデル」という巨大なデータを動かすためには、PCのメインメモリ（RAM）ではなく、GPU専用のメモリであるVRAMの中に、そのデータを丸ごと載せ込む必要があるのです。

もし、あなたが使いたいAIモデルのサイズが10GBで、あなたのGPUのVRAMが8GBし

26B（29.5 tok/s）

ローカルLLM（自分の手元のコンピュータで動かすAI）を始める際、もっとも注目すべきパーツは、計算を行う能力そのものよりも、実は「VRAM」と呼ばれるメモリの容量です。

まず、AIが言葉を生成する仕組みをイメージしてみてください。AIは膨大な量の「知識」を詰め込まれた巨大な辞書のようなものです。この辞書の中身（モデル）を読み込んで、質問に対して答えを考え出すためには、その辞書の内容をすべて、計算を行う場所のすぐ隣にある「作業机」の上に広げておく必要があります。

この「作業机」の広さに相当するのがVRAMです。AIが動いているとき、その巨大な知識データはすべてこのVRAMの中に展開されます。もし、AIのサイズ（知識量）に対して、作業机の広さが足りない場合、どうなるでしょうか。辞書の一部しか机に載せられないため、計算を途中で中断したり、あるいは机の代わりに、もっと遠くにある「倉庫（メインメ

31B（4.0 tok/s）

ローカルLLMの世界へようこそ。まず結論からお伝えすると、GPUのVRAM（ビデオメモリ）は、AIにとっての「作業机の広さ」のようなものだからです。

AIが言葉を生成するとき、AIの知能にあたる膨大なデータ（モデル）をどこかに置いておく必要があります。このデータを保存し、高速に読み書きできる場所がVRAMです。もし、使いたいAIのサイズに対してVRAMという「机」が十分に広ければ、AIはスムーズに思考し、スラスラと回答を書き出すことができます。

しかし、もしVRAMが足りない状態で無理にAIを動かそうとすると、机に乗り切らなかったデータを、わざわざ遠くにある「倉庫（メインメモリやストレージ）」まで取りに行かなければなりません。この往復には非常に時間がかかるため、回答が1文字ずつゆっくり出てくるなど、動作が極端に遅くなってしまいます。

また、VRAMは単にAIを置くだけでなく、「一度に

正直なところ、この程度の課題では5サイズとも十分に読める日本語を書く。差が出るのはもっと難しい推論やコードのはずで、そこは上のベンチマーク値を参考にしてほしい。

面白いのは、5モデルとも申し合わせたように「作業机」「作業スペース」という比喩を選んだことだ。同じ系譜のモデルらしさが出ている。