Gemma-4がでた

昔取った杵柄

気持ち的にはタイトルにも「!」をつけたい!

一時は「出る出る詐欺」とまで言われてたGemma-4がついに2026年4月3日にリリースされてたということで、朝からアゲアゲです。私この執筆をAM5時から開始しています。

https://huggingface.co/blog/gemma4 にて紹介が書かれてましたので、さっそく確認してまいりましょう。

アーキテクチャ上の特徴

アーキテクチャの特徴としてはこんな模様です。

Alternating local sliding-window and global full-context attention layers.
「局所的スライディングウィンドウ処理と大域的フルコンテキストAttention層を交互に配置したアーキテクチャ」ということで、128kトークン/256kトークンを収容可能としつつもメモリ消費が非常に少ないアーキテクチャを採用しているんだと思います。
小規模な高密度モデルでは512トークンのスライディングウィンドウを使用する一方、大規模モデルでは1024トークンを採用しています。

Dual RoPE configurations:
長いコンテキスト処理を可能にするため、スライディング層には標準的なRoPEを、グローバル層には比例型RoPEを採用しています。

Per-Layer Embeddings (PLE):
デコーダーの各層に小さな残差信号を供給する第2の埋め込みテーブルを実装しています。

Shared KV Cache:
モデルの最終N層では、先行する層からキー・バリュー状態を再利用することで、冗長なKV投影処理を省略しています。

Vision encoder:
学習済みの2次元位置情報と多次元RoPEを採用しています。元のアスペクト比を保持しつつ、画像を70、140、280、560、1120といった複数の異なるトークンバジェット(トークンの予算)で符号化することが可能です。

Audio encoder:
Gemma-3nに採用されている基本アーキテクチャと同じベースアーキテクチャを採用したUSMスタイルのコンフォーマーです。

Switch Reasoning model:
Reasoning, non-Reasoning切り替えが可能なようです。このあたりはjinjaテンプレートをまず見ないといけないなぁ・・・・

ラインナップと性能

モデルのラインアップは E2B, E4B, 26B-A4B, 31Bとなっており、MoEを採用しているのは1種類、残りはDenseモデルですね。E2B, E4BはGemma-3nの系譜から連なるいわゆる「マトリョーシカ製法」のモデルです。

ModelParameter SizeContext WindowCheckpoints
Gemma 4 E2B2.3B effective, 5.1B with embeddings128kbaseIT
Gemma 4 E4B4.5B effective, 8B with embeddings128kbaseIT
Gemma 4 31B31B dense model256KbaseIT
Gemma 4 26B A4Bmixture-of-experts with 4B activated/26B total parameters256KbaseIT

推奨サンプリングパラメータとしては以下が指定されていました。一般的なReasoningモデルと同等ですね。top_kが少しでかめです。

  • temperature=1.0
  • top_p=0.95
  • top_k=64

性能は以下の通り示されておりまして、結構これいいんじゃないでしょうか?
比較対象がGemma3-27Bなのですが、

Gemma 4 31B Gemma 4 26B A4B Gemma 4 E4B Gemma 4 E2B Gemma 3 27B
(no think)
MMLU Pro85.20%82.60%69.40%60.00%67.60%
AIME 2026 no tools89.20%88.30%42.50%37.50%20.80%
LiveCodeBench v680.00%77.10%52.00%44.00%29.10%
Codeforces ELO21501718940633110
GPQA Diamond84.30%82.30%58.60%43.40%42.40%
Tau2 (average over 3)76.90%68.20%42.20%24.50%16.20%
HLE no tools19.50%8.70%
HLE with search26.50%17.20%
BigBench Extra Hard74.40%64.80%33.10%21.90%19.30%
MMMLU88.40%86.30%76.60%67.40%70.70%
Vision
MMMU Pro76.90%73.80%52.60%44.20%49.70%
OmniDocBench 1.5 (average edit distance, lower is better)0.1310.1490.1810.290.365
MATH-Vision85.60%82.40%59.50%52.40%46.00%
MedXPertQA MM61.30%58.10%28.70%23.50%
Audio
CoVoST35.5433.47
FLEURS (lower is better)0.080.09
Long Context
MRCR v2 8 needle 128k (average)66.40%44.10%25.40%19.10%13.50%

もちろんのこと早速ダウンロードしたのはE2Bですけれども、これまた超高速にリリースしたUnsloth版からお送りします。

llama.cppの対応状況

ペーパーの中でこう書かれてました。

Gemma 4モデルは、最初から llama.cpp で画像+テキストのサポートが利用可能です!
これにより、お気に入りのローカルアプリケーションすべてで Gemma 4を活用できます:
llama-cppサーバー、lmstudio、Jan、さらにはPiなどのコーディングエージェントを、MetalやCUDAを含む多様なバックエンド環境で使用できるようになります。

なんやてΣ(  Д )ﻌﻌﻌﻌ⊙ ⊙
最新化させようと再コンパイルしちゃったじゃない・・・・バカぁ

Unsloth版E2Bモデルをllama.cppで試す

早速動かしてみた結果は以下の通りです。
推論がきちんとできている点、Qwen3.5とは異なりダラダラとReasoningが続きすぎない点がいい感じです。

ただ、当初は出力速度5tok/s出てたのが、途中から3tok/s付近まで低下したのが少し気になります。
今のところこの部分については、gemma tokenizerの功というべきか、1単語1トークンの構成があることで一定量相殺できてるように見えます。

コンソール上では以下の通り記録されていました。

prompt eval time = 2803.06 ms / 27 tokens ( 103.82 ms per token, 9.63 tokens per second)
eval time = 104441.38 ms / 389 tokens ( 268.49 ms per token, 3.72 tokens per second)
total time = 107244.44 ms / 416 tokens

若干不器用そうですが、内容的にも大丈夫そうですね。絵文字持ってくるとか粋なことするじゃぁないか。

メモリ使用量

128kコンテキスト使用時の状況を確認してみました。およそ4.1GBほど使用してるようです。

2645150 aiuser    20   0 5733528   4.1g   3.0g S   0.0  17.7   0:04.80 llama-server

Qwen3.5の時が以下でしたので

 98106 aiuser    20   0 7091596   5.1g   1.2g S   0.0  21.6   0:07.65 llama-server

意外にもメモリ使用量はパラメータ全量は多いわりにいい感じではないでしょうか(パラメータ全量としては5.1B)

では64k使用時の場合はどうでしょうか。

2647238 aiuser    20   0 5205660   3.8g   3.0g S   0.0  16.1   0:04.23 llama-server

あまり下がっていませんね。RESが3.8gとなっています。
下がらない理由はsliding windowです。本来は少ないトークン量から試していくものですが、CPU推論を必要とする現状だとどうしても小さくしていく方向にチューニングしがちなのでそこはご勘弁を。つまり、これって「コンテキストが膨れ上がっても小さなメモリ消費で済む」ということなんですね。SlidingWindowの存在意義は非常に多く、いまだにOpenAIのGPT-OSSモデルが人気な理由はこれです。

同時接続数やコンテキスト長を最大にしてもメモリ消費が少ないんです。ただ、どうしても1つの決められたサイズのウィンドウをずらしながらInputトークンを取り込む仕様なので、忘却が起きやすいのが難点です。
OpenAIのモデルやGoogleDeepMindのモデルは積極的にSliding Windowの仕組みを取り込んでいて、その忘却リスクをカバーする学習ができているという証左になるのかなと思っています。

そういう意味で、Gemma3から格段にパワーアップしたGemma4が登場したのは非常に大きいんですね。

実際のメモリ確保状況を取り上げてみる

Qwen3.5とGemma4とで見比べてみましょう。

model name Qwen3.5-2B Gemma-4-E2B-It
Main Model
CPU _Mapped model buffer size1267.23 MiB3011.92 MiB
context:n_seq_max44
context: n_ctx262,144131,072
context:n_ctx_seq262,144131,072
context: n_batch2,0482,048
context: n_ubatch512512
context: causal_attn11
context: freq_base10,000,0001,000,000
context: freq_scale11
CPU KV Buffer size3072.00 MiB768.00 MiB
CPU RS Buffer size77.06 MiB
SWA KV Buffer size30.00 MiB
Reserve Fused Gated Delta Net (autoregressive)enabledenabled
Reserve Fused Gated Delta Net (chunked)enabledenabled
CPU compute buffer size792.02 MiB779.02 MiB
reserve: graph nodes1,3771,500
reserve: graph splits11
GGUF version:33
alignment3232
n_tensors2981,411
n_kv3236
Vision Encoder
projectorqwen3vl_mergergemma4v
n_embed1,024768
n_head1612
n_ff4,0963,072
n_layer2416
ffn_opgelugelu_quick
projection_dim2,0481,536
image_size768224
patch_size1616
has_llava_proj00
minicpmv_version00
n_merge23
n_wa_pattern00
image_min_pixels8,192580,608
image_max_pixels4,194,304645,120
model size637.25 MiB939.89 MiB
metadata size0.10 MiB0.50 MiB
warmup with image size1472×1472768×768
CPU compute buffer size223.30 MiB94.52 MiB

まずはモデルサイズの差です。Gemma4-E2Bモデルは名称こそ2Bですが、実際には5.1Bモデルです。このことが色濃く反映されています。そういう意味では、それほどQwen3.5-2Bとトークン出力速度に差がない点は特筆すべきポイントなのではないかなと思います。

そして、メモリ使用量はGemma4-E2Bのほうが小さかったですが、それはKVキャッシュの差です。
Qwen3.5では最大コンテキストサイズ256k実装時は3072MiBなので、コンテキストサイズを128kに落とした場合、その半分となる1536MiBが想定される使用量になります。

これに対してGemma4-E2Bモデルの場合、たったの768MiBしかありません。128kトークンの最大コンテキストサイズを設定しても、Qwen3.5におけるその1/2のメモリ消費しかしないのは、さすがGoogle Deep Mindといったところでしょうか。つまりは、このコンテキストサイズどこまで伸ばしてもメモリ消費のオーバーヘッドはQwen3.5ほど広がらず最小限で済むということを示しています。
これは観点を変えれば、128kコンテキスト長の同時接続数を増やしても同じことが言えます。

同じ方式のローカルLLMトップモデルはそれまでgpt-ossシリーズでしたが、それよりも進んだモデルで同時接続数が稼げるようになるということですよね。これは特に個人向けではなく、企業内でローカルLLMモデルを組むときに挙げられる大きなポイントと言えるでしょう。

しかも、GPU基盤向けに提供されている31Bモデルや26B-A4Bモデルは最大コンテキスト長256kです。
これは非常に強烈なインパクトをもたらすんじゃないでしょうか。正直、私が退職する間際に実装したモデルがQwen3.5でした。できるだけ同時リクエスト受付できるようチューニングして更新に託しましたがこれは・・・あー、なんだか悔しいです。タイムスリップしてこの日まで耐えられるようにすればよかったです。私。

言えること:メモリ節約が得意なGPT-OSSを凌駕するモデル

今のところ分かっているのはメモリの利用効率が非常に高いこと、そしてGemmaらしい丁寧な返答が得意なこと、Qwen3.5ほどに悩まないちょうどいいReasoningが出来ることが言えるのかなと思いました。

ただやっぱりCPUで動かすとなると、最近のCPU性能を鑑みてみないとわかりません。Sandyさんではトークンの「読み込み」が遅すぎて現実的ではなく、なかなかどうして、もう少し扱ってみないことには何とも言えませんです。とはいえ、GPUで動かすと旧型でもそれなりの速度は出るのではないか?という気がします。

くそー、こういうことならGTX 1050Tiでもいいから買っておけばよかった・・・ちょっとばかり無念です・・

コメント

タイトルとURLをコピーしました