Googleが今回Gemma 4を公開した（3）

Wed, 08 Apr 2026 23:56:20 +0800

今回フォーラムを巡回していて、一番印象に残ったのは、「またランキングを出した」というところではなく、「VRAMが足りないから、パラメータがどれだけ大きくても無駄だ」という、かなり生易しい（陳腐な）一言でした。

以前は「モデルが遅い」ことを計算能力の問題だと捉えがちでした。しかし、後になってよく気づいたのは、多くのケースでGPUの計算能力が足りないのではなく、データが適切な場所に留まらないことが原因だということです。メモリのパスが少し変わるだけで、トークン速度は少し落ちるというレベルではなく、直接落ちてしまいます。

前2の記事で、前提となる問題は全て網羅しました。第1回ではリリースとライセンスについて、第2回では3060 12GBでなぜまず26B A4Bを見るのかについて解説しました。そして、今回の記事では、速度が具体的にどのように落ちていくのかだけを扱います。

VRAM不足、慢のはちょっとの問題ではない

推論というプロセスを分解して見ると、特に重要なのが以下の2点です。

モデルの重み（モデルウェイト）
KVキャッシュ重みはモデルそのものを決定し、KVキャッシュはこれまでの文脈の状態を記録します。コンテキストが長くなるほど、KVキャッシュは大きくなります。この2つが安定してGPUのVRAM内に収まっていれば、トークンを生成する際も基本的に高帯域幅なVRAM内でのデータ読み出し、計算、結果書き戻しが行われるため、速度は通常期待できます。本当に厄介なのは、VRAMに乗り切らない場合です。一度容量オーバーになると、推論フレームワークは譲歩せざるを得ません：
一部の重みをシステムメモリに配置する
あるいは一部のKVキャッシュをシステムメモリに配置する
あるいはCPUとGPU間でデータを頻繁に行き来させるこの状況では問題は「少し計算量が増えた」というレベルではなく、「トークンを一つ出すたびにデータ待ちが発生する」というレベルになります。

なぜ急落（断崖）が発生するのか、線形に遅くなるわけではない

この罠に初めて遭遇した多くの人は、「モデルが $14\text{B}$ から $31\text{B}$ になったら、2倍以上遅くなるから、我慢できる範囲だ」と直感的に考えます。

しかし、現実はそうではありません。

真の境界線はパラメータが2倍になることではなく、ワークセットがVRAM（ビデオメモリ）の境界を越えたかどうかです。

まだ越えていない場合、モデルが大きくなることで遅くなるのは、通常予測可能な範囲内です。

一度それを超えると、システムの状態が根本的に変わります：

それまでは「VRAM内でのクローズドループ」だった
今や「VRAM + メインメモリ + バスによるデータ転送」になる

経路が変わるだけで、コストは全く異なります。特にデコード（生成）の段階では、元々トークンを一つずつ順に進んでいき、バッチサイズもそれほど大きくないため、この時最も怖いのは、すべてのトークンに対してデバイスをまたいでデータを待つ必要があることです。

そのため、非常に典型的な現象を目にすることがあります：

モデルが動かないわけではない
GPUも完全に遊んでいるわけではない
しかし、トークン/秒（token/s）の数値が非常に悪い

これが皆が言う「断崖」です。モデルが突然賢さを失ったのではなく、メモリのデータ経路が突然非効率的になったのです。

「26B A4B」がローカルプレイヤーにとってより親切な理由

この点も、なぜ私が前回の記事で一貫して「26B A4B」を重視してきたのかを説明しています。当然ながら総パラメータ数は小さいわけではありませんが、実際にトークンごとにアクティブになるのは約「3.8B」程度です。これは、類似のデプロイメント条件下において、計算リソースやVRAMへの負荷が、密な（dense）大規模モデルよりも管理しやすい場合が多いことを意味します。これも魔法ではありません。もしコンテキストを長くしすぎたり、量子化やフレームワークのサポートが不十分だと、これでも苦労します。ただ、最初からVRAMを使い切ってしまうような密なモデルと比較すると、「26B A4B」は、一般消費者向けのグラフィックカードにとってより現実的な選択肢という側面があります。ですから、多くのケースで「31B」が弱いのではなく、ローカルマシンが誰と長期的に付き合うのに適しているか、という問題なのです。

Mac が「爆発しにくい」理由

Mac の最も異なる点は、モデルではなくメモリ構造にあります。 Apple silicon はユニファイドメモリを採用しています。CPU と GPU が同じメモリプールを共有するため、専用GPU搭載機のように、片方がVRAM、もう片方がメインメモリで、間にバスを介してデータを移動させるという構造ではありません。この構造の最大の利点は、専用GPU搭載機では「VRAMにそもそも収まらない」モデルでも、Mac 上では別の状態になることです：

必ずしも速くはないが
まずは格納できる可能性が高いということです。つまり、Mac は最初から非常に硬い「VRAMの壁」にぶつかりにくいのです。これが、多くの人が Mac がローカルでの大規模言語モデル（LLM）において特に適していると感じる理由です。それは、「まずワークセット全体を同じメモリプールに詰め込めるか否か」という問題を解決してくれるからです。

しかし、ユニファイドメモリが高速を保証するわけではない

この部分は分けて考える必要があります。ユニファイドメモリは何を解決したのか？

専用GPUメモリとメインメモリの物理的な分離の問題を解決した
小容量のVRAMでは直接搭載できなかった多くのモデルに対応できるようになった
非常に煩雑な、デバイス間でのデータの往復移動の問題を解決したしかし、何が解決されていないのか？
大規模モデルの推論を「大量のメモリ読み出し」から別のものに変えていない
大規模モデルが突然帯域幅を消費しなくなるわけではない
すべての推論フレームワークが自動的にCUDAのような成熟したエコシステムを持つわけではないしたがって、Macの快適さとNVIDIAの大容量VRAMカードの速さは、同じものではありません。 Macはむしろ以下のようなものです：
機械が静かであること
総メモリが大きいこと
統一されていること
これまで搭載できなかった多くのモデルを、とりあえず動かすことができるようになったこと NVIDIAの大容量VRAMカードはむしろ以下のようなものです：
エコシステムが成熟していること
CUDAツールチェーンが完全であること
モデルとキャッシュをGPU内に留め込むことができれば、速度を上げやすいこと

なぜスピードを求めるのか、結局はNVIDIAのVRAM容量が重要になる

これは感情的な判断ではなく、ローカルにデプロイする過程で容易にたどり着く現実的な結論です。もしあなたが以下のようなものを追求しているなら：

ローカルアシスタントの常駐化
多回の長文対話
長いコンテキストウィンドウ
より高いトークン/秒 (token/s)
待ち時間を極力減らすことそれらの場合、結局はVRAM容量の大きなNVIDIA製GPUが重要になります。なぜなら、あなたが真に購入しているのは、モデルとキャッシュをできるだけ安定してGPU上に保持する能力だからです。 Macももちろん当てはまりますが、こちらは別の種類の要求に適しています：
大きなモデルを一度に搭載したい
速度は平均的でも良いが、ドライバや周辺機器の設定で手間をかけたくない
全体的な体験、消費電力、騒音を重視するこれら二つのアプローチはいずれも合理的ですが、解決しようとしている問題点が異なります。

Gemma 4 に戻る、私の最終判断

今回、Gemma 4 は、ローカルでオープンソースのモデルが、より真剣にハードウェアについて議論すべき段階に入ったと感じさせられました。しかし、モデルが強くなっても、物理法則まで緩むわけではありません。どれだけ強力な 31B でも、VRAM が不足すれば速度は落ちます。どんなに現実的な 26B A4B でも、コンテキストが長すぎれば負荷がかかります。 Mac のユニファイドメモリは快適ですが、それは単に「とりあえず動かす」のが容易になるだけであり、大容量の VRAM を持つ CUDA カードの速度を無償で提供してくれるわけではありません。そのため、結局やはりこの地味な結論になります：

速度を求めるなら、最優先は NVIDIA の大容量 VRAM です。
万全を期すなら、Mac のユニファイドメモリは確かに快適です。
3060 12GB のようなマシンで長期的に遊ぶのであれば、常に巨大なモデル（dense model）ばかりを気にするのではなく、26B A4B のようなアプローチの方が現実的です。この一連の記事は、ここまでで締めくくりとします。

参考資料

作成上の注記

元のプロンプト

$blog-writer Googleが1年ぶりにGemma4モデルをリリースしました。いつものように、ローカルデプロイメントを試します。使用するのはアップグレードされていないデスクトップPCに搭載されている3060 12GB NVIDIAグラフィックボードです。今回は初出陣でしたが、以前よく使っていたGemma3のアップグレード版が見つかりませんでした。しかし、類似のバージョンであるGemmaE4bというものがあるので、まずこれを検索して紹介してください。今回リリースされた全モデルについて、含まれる略語アルファベットがそれぞれ何を意味するのかを説明し、さらにオンライン上のGemma4に関する評価を検索してください。重要な点として、今回のGoogleによる更新でモデルのプロトコルが変更され、利用時の制限が緩和されました。最大の驚きは、私がよく使うテスト問題です。「C++コードを書いて、コンソールに五芒星を出力しなさい」というものでした。昨年の小規模パラメータのオープンソースモデルではこの問題をクリアできませんでしたが、Googleはこの回で成功させました。最初の回答は私の予想を完全に超えており、私の意図（トラップ）を理解していました。コンソールへの五芒星の出力は非常に厄介なため、直接アスキーアートとして文字列をハードコーディングし、コンソールに出力しました。これが原文です：「純粋なテキストのコンソール（Console）で数学的なロジックだけで正確な幾何学的構造を持つ五芒星を描画するのは非常に複雑である（座標変換やピクセル充填が関わるため）。最も古典的で視覚効果が高い方法は、アスキーアート（文字芸術）を使用することである。私が計算を強制的に要求した後も、それは成功しました。数学的な計算を通じて、五芒星を描画したのです。」以前はローカルでの翻訳タスクにGemma4をよく使用していました。現在のブログの多くの過去の記事の多言語版がこのようにして作られています。ローカルテストに使用したのは：gemma-4-26b-a4bモデルで、31bバージョンは本当に遅すぎます。しかし、レビューを見ると31bの効果は非常に良く、ランキングの成績も優れています。同時にフォーラムを閲覧し、私は「VRAMが不足している場合、モデルパラメータを上げると、生成トークンの速度が急激に低下する」ということに気づきました。なぜそうなるのか説明してください。Macではこの問題は発生しません。ユニファイドメモリを使用しているため、技術的な理由を説明してください。また、速度が必要な場合は、やはりNVIDIAのVRAM大容量グラフィックボードが必要です。Macのソリューションはバックアップにはなりますが、速度が出ません。今回の内容は多岐にわたるので、シリーズ記事に分割すべきか評価してください。

ライティングの骨子まとめ

第3編では、「なぜスピードが落ちるのか」と「Macが速さ＝ではない理由」の2つの論点のみを残し、前2編の内容への回帰的な説明は行わない。
まずVRAM（ビデオメモリ）の限界について述べ、次に非線形な速度低下について述べることで、前回版よりも論理の流れがスムーズになる。
MacとNVIDIAをそれぞれ異なる側面から語り分け、一方は「安定性重視」、もう一方は「速度重視」という形で対比させる。
結論ではハードウェアの判断のみに留め、シリーズ分割の理由付けは繰り返さない。

Mac on 向叔の手帳