Google、Gemma 4を版番号据え置きで更新　H100以降で高速化、再取得で反映

GoogleはGemma 4のオープンウェイトモデル群に対し、版番号を変えないまま大幅な更新を適用した。2026年7月16日以前にGemma 4を取得していた場合、手元の重みは現在配布されているものと実質的に異なり、改善を反映するにはHugging Faceから再取得する必要がある。主な恩恵はH100以降のHopper世代GPUでの高速化だが、全モデルサイズでツール呼び出しの不具合修正や視覚処理の拡張も入っている。

■更新の概要

Googleは7月15日、公式GemmaアカウントのX投稿でGemma 4の更新を告知した。翌日にはThe Decoderもこれを裏付け、Googleが公表した性能値を独自に確認したとしている。

今回の更新は、Flash Attention 4（FA4）対応、ツール呼び出しの不具合修正、視覚処理能力の拡張、応答が途中で途切れる事例の低減という4点が中心である。版番号は据え置きのままで、以前にダウンロードした同名モデルと現在配布中の重みが異なる状態になっている。

■H100以降で有効になるFlash Attention 4対応

Googleの公表値によると、NVIDIA HopperアーキテクチャGPU、つまりH100以降でFA4を有効にすると、プロンプト処理のスループットは25〜70％向上し、最初のトークンが返るまでの時間は最大31％短縮する。The Decoderはこれらの数値を独自に確認したとしている。対話型エージェント、企業向けパイプライン、高スループットのバッチ推論のように、推論速度が重要な用途では実質的な遅延低減になる。

ただし、この高速化はHopper世代に限られる。Ada Lovelace世代のRTX 4090、L40、L40SでGemma 4を動かしている開発者は、今回の更新で掲げられた主な性能向上の恩恵を受けない。広告されたスループット改善値は、こうした環境には当てはまらない。

■なぜHopper限定なのか

理由はGemma 4の注意機構の構造にある。Gemma 4は同一モデル内で2種類のヘッド次元を使うハイブリッド構成を採っており、30層の注意層のうち26層はhead dimension 256で、標準的なFlashAttention 2に対応する。残る4層はグローバルアテンションでhead dimension 512を使っており、これはFA2の対応上限を超えるため、全層にFA2を指定するとHugging Face Transformersの既知の問題として記録されているようにクラッシュする。

この更新以前は、最も簡潔な回避策は30層すべてをSDPAに戻すことだった。その場合、本来FAを使えた26層で得られるはずだった高速化の約87％を失う計算になる。

2026年3月の技術論文で公開されたFA4は、HopperのTensor Memory Acceleratorや完全非同期のMMAパイプラインに対応し、Gemma 4で層ごとに処理を切り替える実装を可能にした。7月の更新は、Hopper GPU（SM 9.0以上）向けにこれを実装したものとみられる。

FA4はcompute capabilityのSM 8.0以上で有効化条件を持つ一方、SM 8.6とSM 8.9は明示的に除外されている。SM 8.9はRTX 4090や業務向けL40Sを含むAda Lovelace GPUの世代に当たる。2026年5月には、Dao-AILabのflash-attentionリポジトリでAda向けにhead_dim=512を別経路で扱うSM 8.9対応カーネルを求める公開Issueが作成されたが、7月16日時点では未解決のままだ。

Turing世代のGPU（RTX 2000シリーズ、SM 7.5）では制約がさらに厳しい。Gemma 4のグローバルアテンション層は、各ストリーミングマルチプロセッサ当たり96KBの共有メモリを必要とするのに対し、Turing側の上限は64KBである。

■全モデルサイズで入った修正

ツール呼び出しの信頼性も改善された。ツール呼び出しは、複数段階のタスクの一部として外部機能を自律的に実行する機能である。これまでエージェント型ワークフローで失敗や不正な出力を起こしていた不具合は解消されたとされる。特に自律エージェント用途では、不正な関数呼び出しが単なる誤文では済まず、外部システムに意図しない操作を引き起こす可能性があるため影響が大きい。

Googleによれば、応答が途中で切れる事例も「大幅に減少した」という。

視覚処理では、max_soft_tokensの既定値280を手動で1120まで引き上げられるようになり、最大2.51メガピクセルの解像度でOCR処理を行えるようになった。GoogleはHugging Face上で、用途に応じた設定を調整するためのインタラクティブなコンフィギュレータも公開している。soft tokenを増やせばより高精細な画像を扱えるが、メモリ消費は増え、推論も遅くなる。このトレードオフを固定値ではなく調整可能にした格好だ。

■ベンチマークで示された改善幅

Googleは31BとE4Bについて、更新前との比較ベンチマークを公表した。31Bはτ2-benchのエージェント推論スイートで全テスト項目が改善し、単一タスクでは通信分野のユースケースで10.1ポイントの上昇が最大だった。Berkeley Function-Calling Leaderboardでは31Bのスコアが0.4ポイント上がった。Tau2-BenchのAirlineとRetailのシナリオでも、それぞれ2.0ポイント、3.1ポイント改善した。

一方で、E2B、比較詳細が追加公開されていないE4B、6月に公開された12B unified variantについては、個別の詳細結果は示されていない。ただしHugging Faceのリポジトリでは、全サイズが同じ重み更新を受けたことが確認できる。小さいモデルの改善幅を把握したい開発者は、再取得した重みを使って自分の用途で評価し直す必要がある。

Gemma 4 31Bは2026年4月の公開時点で、Arena AIリーダーボードのオープンモデル部門でELO 1,452の3位に入っていた。今回の7月更新は、その立ち位置を大きく変えるというより、既存の基盤を底上げするものといえる。

■初めてではない静かな改訂

今回の7月改訂は、Gemma 4公開後では最大規模の重み更新だが、初めてではない。2026年4月2日の初回公開後、Hugging Face経由で配布された量子化GGUFビルドは、壊れたチャットテンプレート、トークナイザー破損、ツール呼び出しの不具合、誤ったlogit softcappingに対応するため、最初の2週間で複数回の再ダウンロードが必要だった。

またUnslothチームは、CUDA 13.2ランタイムでGemma 4 GGUFを使うと、エラーを出さないまま出力品質が低下するという警告を記録している。見かけ上は正常動作しながら結果だけが悪化するため、特に厄介な種類のサイレント障害だ。

2026年5月初旬には、こうした問題を取り上げたr/LocalLLaMAのスレッドが8時間で277件のupvoteを集めた。最初の修正から数週間後の時点でも、壊れたビルドを使い続けていた開発者が相当数いた可能性を示している。公開直後にGemma 4を取得して以来、重みを更新していない場合、現在文書化されているものとは実質的に異なるモデルを動かしている可能性がある。

■版番号を変えない更新が招く再現性の問題

今回の改善そのものは広く歓迎されているが、命名規則には批判が集まっている。X上の反応や開発者コミュニティで最も厳しく指摘されているのは、何が変わったかではなく、同じモデル名のまま変更を出荷する運用である。

問題は具体的だ。ある研究者が今日「Gemma 4 31B on τ2-bench」の結果を公開しても、別の研究者が来週「Gemma 4 31B」をダウンロードして、同じモデルを評価していると確信することはできない。学習コードやデータを公開しないオープンウェイトモデルでは元々再現性に限界があるが、少なくとも固定重みに対する推論結果は再現できるという前提まで、サイレントな重み更新は崩してしまう。

この問題はGoogle固有ではなく、他のオープンモデル提供者でも版文字列を変えずに改訂を配布した例はある。ただ、Gemma 4はエージェント評価の文脈で広く使われているため影響は大きい。たとえば、ある時点で観測されたτ2-bench通信分野の10ポイント改善は、元の重みが告知なく変わるなら比較の基準として不安定になる。

DigitalOceanコミュニティは2026年4月、この問題を「技術的制約ではなく開示の欠落」と表現し、重みの変更を追跡して開発者に見せる仕組み自体は既に存在するのに、プラットフォーム側が表に出していないと論じた。現時点でコミュニティが採っている実務的な暫定策は、各ベンチマーク結果に重みのダウンロード日を併記し、それを事実上の版識別子として扱うことだ。

Googleはこの展開を「コミュニティからの素晴らしいフィードバックと貢献に支えられた、Gemma 4への大きな改善」と説明した。この表現は、更新を破壊的変更ではなく応答的な改善として位置付ける一方で、命名の問題には触れていない。X投稿でもその後のGoogleの発信でも、「Gemma 4.1」にすべきだという提案に直接答えてはいない。

■開発チームが取るべき対応

Gemma 4を本番運用しているチームや、評価対象として使っているチームは、Hugging Faceリポジトリから重みを再取得すべきである。これは全パラメータサイズに当てはまる。H100などHopper世代のハードウェアでは、重みを更新すればFA4による高速化は自動的に有効になり、別途の設定変更は不要だ。

量子化GGUFビルドを使っている開発者は、Hugging Face、llama.cpp、Ollama、LM Studioといった配布元で更新ファイルを確認した方がよい。公開後に静かな改訂が繰り返されているため、2026年4月や5月のキャッシュ済みコピーは、今回の更新だけでなく以前の修正も取り込めていない可能性がある。

『Gemma 4』を参照するベンチマーク記録を維持しているチームは、結果と一緒に重みのダウンロード日を記録しておく必要がある。Googleが公開後改訂に別の版番号を採用しない限り、ダウンロード日は、実際にどのモデルを試験したかを識別する最も信頼できる代替指標になる。

Gemma 4の重みを土台にファインチューニングした派生モデルを持つ場合は、基盤モデルの変更が出力に影響するか検証した方がよい。今回の変更は主にアテンションカーネルと出力長の挙動に集中しており、タスク固有の学習層自体は影響を受けないはずだが、ホールドアウトテストセットでの確認が望ましい。

Gemma 4は2026年4月の公開以来、1億5,000万回超ダウンロードされている。Gemmaファミリー全体では、全世代合計で4億回を超えた。この配備規模を踏まえると、版管理の問題と、重みを再取得するかどうかの運用判断は、オープンモデル開発者コミュニティのかなり大きな範囲に関わる。

■注目ポイントQ&A

●Gemma 4の更新はRTX 4090でも効きますか？

FA4による高速化、つまり最大70％のプロンプト処理向上と最大31％のtime-to-first-token短縮は、NVIDIA Hopper世代のハードウェア（H100、H200、その後継）向けです。RTX 4090はAda Lovelace世代（SM 8.9）で、FA4の対応範囲から明示的に除外されています。そのため、RTX 4090で更新済みの重みを再取得しても、ツール呼び出しの不具合修正や視覚設定の改善は受けられますが、FA4のスループット向上は得られません。Ada対応カーネルを求める別Issueは公開されていますが、解決時期は示されていません。

●なぜGoogleはGemma 4.1として出さなかったのですか？

Googleは、公開後の重み改訂に関する版管理方針を公には説明していません。コミュニティの批判は再現性の問題に集中しており、ある日に公開された「Gemma 4 31B」の結果と、別の日に同名モデルで得た結果が同じ成果物を指すとは限らない、という点が問題視されています。GoogleのX投稿は、更新をコミュニティ主導の改善として説明しましたが、版更新としては扱いませんでした。明示的な版タグが導入されるまで、AI研究コミュニティでは重みのダウンロード日を結果に併記し、事実上の版識別子として扱う方法が推奨されています。

●すでにGemma 4を持っていても再取得は必要ですか？

必要です。改善は設定変更やツール更新ではなく、モデル重み自体に入っています。Hugging Faceリポジトリから再取得しない限り、対応ハードウェアでのFA4サポート、ツール呼び出し修正、途中で切れる応答の低減、視覚解像度拡張は反映されません。GGUFビルドを使っている場合も、配布元で更新済みの量子化ファイルを確認する必要があります。これは、Gemma 4公開直後にも複数回の再ダウンロードが必要だったのと同じ種類の重み更新です。

●エージェント推論の改善は本番運用でどの程度重要ですか？

Google公表のベンチマークでは、31Bモデルのツール呼び出し性能はτ2-benchの全シナリオで改善し、通信分野では最大10.1ポイント上昇しました。Gemma 4をエージェント型パイプラインで使っているチームにとっては、更新前のツール呼び出し不具合がワークフロー失敗や不正な関数呼び出しの原因になり得ました。7月更新はその失敗モードを解消したとされています。ただし、個別の本番ワークロードでベンチマーク上の改善がどう出るかを検証する責任は、導入側にあります。

元記事: Gemma 4 Gets Stealth Update: H100 Speed Gains and Tool-Calling Fixes, No Version Bump