Gemma on 向叔の手帳

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をそれぞれ異なる側面から語り分け、一方は「安定性重視」、もう一方は「速度重視」という形で対比させる。
結論ではハードウェアの判断のみに留め、シリーズ分割の理由付けは繰り返さない。

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

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

ランキングだけを見ると、一番心が動くのは間違いなく 31B です。しかし、実際にマシンを前にすると、やはりアップグレードされていない RTX 3060 12GB の方が、判断はすぐに変わります。どう言えばいいか、ローカルにデプロイするということは、最後に一番派手なものが勝つのではなく、長く一緒にいられそうなものを選ぶことなんです。私にとっては、今回まず試す価値があるのは 31B ではなく、26B A4B です。

前回の記事 GoogleがGemma 4を公開した件（一）：急いでローカルに動かす前に、モデル名とプロトコルを理解すべきでは、リリースとプロトコルについて説明しました。今回の記事ではローカルでの体験そのものに焦点を当てています。最後の記事では GoogleがGemma 4を公開した件（三）：VRAM不足でなぜ急落するのか、Macはなぜバックアップになり得るのに速くないのかを続けます。

なぜ先に「26B A4B」を試すのか

理由は実はかなり現実的、つまりハードウェアの制約によるものです。「31B」はもちろん強力で、公式ランキングやコミュニティからの初期フィードバックも非常に高いです。しかし、それを「RTX 3060 12GB」のようなマシンに載せると、問題はすぐに「どれだけ強いか」から「待つ価値があるか」へと変わってきます。モデルやキャッシュがシステムメモリに退避してしまうと、速度が急激に落ちてしまうことがあり、この件については第3弾で詳しく解説します。「26B A4B」は違います。総パラメータ数は「25.2B」ですが、実際にトークンごとにアクティブになるのは約「3.8B」程度です。平たく言えば、これは今回のGemma 4の中で、「ローカルユーザー向けに特別に用意された」モデルと言えます。ですから、もしあなたのマシンが私と同じような、コンシューマーグレードの古いグラボであるなら、判断はシンプルになります：

ランキングを見たいだけなら、「31B」を試す
本格的に長期でローカルに使いたいなら、まず「26B A4B」から始める

五芒星の問題、今回はついに誰かが私が罠を仕掛けていることに気づいた

私自身がずっと持っている、かなり原始的なテスト問題があります。モデルに C++ コードを書いて、コンソールに五芒星を出力させるというものです。

この問題は冗談のように見えますが、実際には結構厄介です。なぜなら、多くのモデルはこれを純粋な数学的な描画問題だと誤解し、座標系や三角関数、ループ処理などを持ち出してきてしまい、最終的にテキストコンソール上に、全く見づらい文字の塊を出力してしまうからです。

去年の小規模パラメータのオープンソースモデルの多くが、この点でつまずきました。

しかし、今回 Gemma 4 の最初の反応は、逆に私を驚かせました。すぐに理解したふりをするのではなく、制約条件を先に認識し、以下の判断を出してくれたのです：

純粋なテキストコンソール（Console）上で、正確な幾何学的構造を持つ五芒星を数学的なロジックだけで描画するのは非常に複雑です（座標変換やピクセル充填が関わってきます）。最も古典的で視覚的に効果的な方法は、ASCII Art（文字アート）を使用することです。

五芒星の問題、今回はついに誰かが私が仕掛けた罠を理解してくれた

端的に言うと、まず問題の背後にある環境的な制約を理解した点だ。コンソールはキャンバスではなく、文字グリッドもピクセルグリッドではない。先に「どうすれば安定して五芒星を出力できるか」を考え抜いてから、数学的な描画について語るべきだった。

そして、最初のバージョンではいきなりハードコーディングされた五芒星の文字列を提示した。この行動は非常に的確だ。推論を見せるためではなく、まず問題を正しく解くことを優先した。

さらに驚いたのは、それがさらに進んでいくことだった

単にASCIIアートで止まっていただけなら、この問題はトラップを認識したとしか言えない。私が高く評価したのは、その後も数学的な計算を要求し続けた際にも、それが失敗せず、むしろ幾何学的な関係性を文字のグリッド上にマッピングし、最終的に五芒星を算出した点だ。これは「コードを書ける」ということではなく、この問題が実際には二層構造になっていることを理解している証拠だと考える。

第一層：コンソール上で最も確実な答えは何か
第二層：もし計算をしなければならない場合、どのように幾何学の問題を文字のグリッド上に落とし込むか以前の多くのローカル小規模モデルは、最初から第二層に飛びつき、結局第一層ができていないことが多かった。Gemma 4 は今回、逆の手順を踏み、まず境界線を見極め、それからどう解くかを決定した。私はこの点の方が、単体のベンチマークスコアよりも価値があると思う。

今回のコーディング能力の向上は、「賢くなった」だけではない

この五角星の問題が使いやすいのは、単に文法を問うものではないからです。本当に試しているのは以下の点です：

出力環境を先に理解できるか
直感的な解法が不適切であることを認められるか
「最適な表示効果」と「ユーザーによる強制計算要求」の間を切り替えられるかこのような問題を正しく解けるということは、モデルが単にコードスニペットを補完するだけでなく、現実の制約を処理できる開発アシスタントらしくなり始めたことを示しています。だからこそ、私にとって Gemma 4 の第一印象は、去年の小規模パラメータのオープンソースモデル群よりも格段に良いのです。昨年の多くのモデルは、チャットができる、補完できる、なんとかこなせるレベルでしたが、このような少し境界線を感じさせる問題に直面すると、脆さが露呈しがちでした。今回、Googleはこの弱点を少なくとも補ってくれました。

この一文を翻訳すると、「Gemma 4 が全面的に引き継ぐ」と単純には言えない

あなたが以前指摘した点は非常に重要です。これまでローカルで翻訳を行う際によく Gemma を利用していましたよね。

この件は、Gemma 4 になると、実はそれほど直線的ではありません。なぜなら、Google は 2026 年 2 月に単独で TranslateGemma をリリースし、しかもそれは Gemma 3 のアーキテクチャをベースにしているからです。

これはどういう意味か？ということです。もしあなたがすでにローカルでの翻訳パイプラインを確立していて動いているなら、短期間で全てを Gemma 4 に切り替える必要はないかもしれません。特に、目的が非常に限定的で、単に安定した多言語変換だけを求めるシナリオにおいては、専用の翻訳モデルには依然として価値があります。

しかし、もしあなたが求めているのが、翻訳、質問応答、コード、一般的なテキストタスクなど、複数の用途を可能な限りカバーできるローカルモデルセットであるならば、26B A4B のようなより万能なアプローチの方がスムーズでしょう。

これが最も特化しているわけではないかもしれませんが、「とりあえず動く、十分なメインストリームモデルが欲しい」という現実的な選択肢に近いと言えます。

なぜ第2回で「31B」を褒め続けたくないのか

「31B」がダメだからというわけではない。むしろ、良すぎるからこそ、注意が逸れやすいのだ。ずっと「31B」のベンチマークスコアばかり見ていると、「強力なモデルは本当にすごい」という記事になりがちだ。しかし、ローカル環境で最も怖いのは、そういった謳い文句である。なぜなら、あなたが毎日使い続けるかどうかを決定するのは、ランキングではなく、以下の点だからだ：

起動が遅すぎないか
回答速度が著しく落ちないか
長いコンテキストを扱うとすぐに体験を台無しにしないか
自分自身のマシンで本当に支えられるか「3060 12GB」のようなマシンでは、これらの現実的な問題の方が、ランキングよりもずっと重要だ。そのため、第2回の締めくくりはシンプルにした。「31B」は見る価値があるが、「26B A4B」は使う価値がある。ローカルユーザーにとって、この二つの文は全くの別物なのだ。

私のローカルでの第一印象

今回の実測感触を一言でまとめると、それは以下の通りです。 Gemma 4 はついにシーンを考慮できるローカルモデルになり始めた。特に 26B A4B がそうですね。これはベンチマーク表を飾るためのモデルというよりは、古いマシンやコンシューマー向けのグラフィックボード、ローカルでの長期利用といった現実的な制約の下では、かえって真の主力選択肢のように感じられます。少なくとも今回の五角星テストに関しては、Googleは合格点を超えました。

参考資料

作成上の注記

元のプロンプト

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

ライティングの骨子要約

第2編はローカル体験のみに留め、第1編の総括や第3編のVRAM原理の説明は行わない。
まず「なぜ先に 26B A4B を実行するのか」という明確な判断を提示し、その後で五芒星テストを展開する。
五芒星の問題が主軸となるのは、ベンチマークスコアよりもコーディングシナリオにおける限界点をよりよく示せるからである。
翻訳タスクは独立したセクションとして扱い、Gemma 4 が全ての旧プロセスを線形的に引き継いでいるという印象を避ける。

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

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

初日に私がやりたかったことはとてもシンプルでした。Gemma 3 に対応するアップグレード版を見つけて、まずダウンロードして動かしてみることです。しかし、全体をざっと見ていくと、少し戸惑いを覚えました。以前慣れていた 4B / 12B / 27B という命名規則がなくなり、代わりに E4B、26B A4B、31B といったものが現れたのです。どう言えばいいか、今回Googleが真に変わったのは、単にモデルのサイズだけではなく、「この一連のモデルをどう理解すべきか」という部分まで変わってしまったからです。

この記事群は3つの記事に分けて書きました。現在の記事では、リリース情報、モデル名、プロトコルを明確に説明します。次の記事では Googleが今回Gemma 4を公開した（2）：RTX 3060 12GBでローカル実行してみた、真の現実的なのは26B A4B を書きます。そして最後の記事では Googleが今回Gemma 4を公開した（3）：VRAM不足でなぜ急落するのか、Macはなぜバックアップになり得るのに速くないのかで締めくくります。

まず、今回具体的に何がリリースされたのかを明確にしましょう

昨年の Gemma 3 は 2025年3月12日にリリースされ、今回の Gemma 4 は 2026年4月2日と、確かに約1年空いています。しかし、今回は「27Bの次は何だろう」という考え方で探すのはやめましょう。公式が提示した主要な4つのサイズは、もはや単に総パラメータ数で区分けされているわけではありません。 | E2B | Dense | 2.3B effective，5.1B 含 embeddings，128K context | デバイス側、超軽量ローカル |

今回、結局何を発行したのかを明確にする

モデル名	構造	主要な数値	代表的なユースケース
`E4B`	Dense	有効パラメータ 4.5B、埋め込み込み含む 8B、コンテキスト長 128K	元の 4B の小型モデルをメインラインとして展開

今回到底发布了什么说清楚

モデル名	構造	主要な数値	代表的なユースケース
`26B A4B`	MoE	合計 25.2B、アクティブ約 3.8B、コンテキスト 256K	コンシューマー向けGPU、ローカルデプロイメント、品質と速度の両立

まず、今回具体的に何を出したのかを明確にする

モデル名	構造	主要な数値	代表的なユースケース
`31B`	Dense	30.7B dense、256K context	最高性能の追求、ランキングでの優位性、より安定した品質

今回、結局何を出したのかを明確にする

表面だけを見ると、今回のネーミングはより混乱していると感じるかもしれません。しかし実際は混乱しているのではなく、Googleが意図的に3つの異なるアプローチに分割しているのです：

小規模モデル・デバイス側向けに E2B / E4B を提供
ローカルプレイヤー路線として 26B A4B を提供
品質と上限を重視した路線として 31B を提供これが、多くの人が最初に「以前の馴染んだアップグレードパスが途切れた」と感じる理由です。アップグレード版を提供していないわけではなく、Googleはもはや総パラメータ数という単一の次元だけで製品を売りたいわけではないのです。

「E」と「A」は今回、装飾文字ではありません

このモデル名の中で、最も誤解を招きやすいのが E4B と A4B です。 E2B や E4B に含まれる E は、公式では effective parameters（実効パラメータ）を指します。これら2つのモデルは Per-Layer Embeddings を使用しているため、総パラメータ数と真の有効パラメータ数が同じ基準ではありません。平たく言えば、Googleは「これは過去のような『単なる 4B の密なモデル』ではない」と注意喚起しています。一方、26B A4B に含まれる A は active parameters（アクティブパラメータ）を指します。総容量は 25.2B ですが、各トークンで実際に活性化するのは約 3.8B です。これがMoE（Mixture of Experts）の鍵であり、モデル全体のサイズは大きいものの、実行時に実際に計算に参加する部分はかなり小さいということです。そのため、この2つの名前はどちらも「4B」を含んでいますが、その意味合いは全く異なります。

E4B は小規模モデルのメインラインです。
26B A4B は大規模なMoEであり、ローカル推論時には「アクティブな規模が約 4B 程度」というイメージに近いです。この命名規則は当初は確かに不自然ですが、過去のものよりも実際のデプロイ体験により近くなっています。

以前 Gemma 3 を使っていた場合、今回どういう対応関係で探せばいいか

私が思うに、この世代で最も誤解しやすいのは、これを Gemma 3 の線形なアップグレードだと捉えてしまう点です。

使用する習慣から考えると、だいたい以下のように理解できます：

これまで 4B で軽いタスクを動かしていた人は、まずは E4B を見てください。
これまで 27B でモデルの限界値を見ていた人は、今度は 31B を見てください。
これまでコンシューマー向けのグラボで「十分強力だけど、完全に動かせなくなるほどではない」というバランス点を探していた人は、重点的に 26B A4B を見てください。

この部分を先に整理しておかないと、後からローカルにデプロイする際に非常に迷いやすいです。「いつものアップグレード版がないな」と文句を言いながら、実際自分に合っているモデルを見逃してしまう可能性があります。

今回最も価値のあるアップデートは、実はパラメータではない

今回「ようやく腑に落ちた」と感じさせたのは、ランキングではなくプロトコル（ライセンス）でした。以前のバージョンの Gemma の利用規約が全く使えないわけではありませんが、ずっとどこか引っかかる部分がありました。特に以下のようなことを気にされている場合：

再配布
蒸留や二次加工を行う
モデルを自社の製品ラインに組み込む
商用展開を行うといった場合、常にライセンス条項内の通知（notice）、下流利用の制限、付帯する契約などをどう処理すべきかを確認する必要がありました。 Gemma 4 が今回直接 Apache 2.0 に変更されたことで、状況が非常にクリアになりました。核となるメッセージは極めて明確です：
商用利用が可能である
改変が可能である
再配布が可能である義務は主に、ライセンス、通知（notice）、改変の説明といったオープンソースの世界で馴染み深いものに留まるというものです。つまり、Googleが今回単にモデルをオープンソースにしたのではなく、「皆が安心して使えるかどうか」という点まで含めて整備してくれたのです。

コミュニティからの初期評価は、基本的に2つのラインに集約される

最初の週の口コミだけを見ると、大まかに2つの声があります。

1つ目のラインは、「31B は確かに実力がある」というものです。公式が発表したスコアは非常に強力です。Arena AI のテキストランキングでは、31B がリリースされた時点でオープンソースモデルの上位にランクインし、LiveCodeBench v6 でも Gemma 3 27B よりかなり向上しています。多くの人が最初に抱く感想は、「このサイズでこれだけの性能が出せるのは、期待を上回っている」というものです。

2つ目のラインは、「26B A4B はローカルユーザーのための生命線のようなものだ」というものです。一見して最も華やかなフラッグシップモデルというわけではありませんが、非常に現実的です。特にデータセンターではなく、コンシューマー向けのグラフィックボードやワークステーション、さらには古いマシンで動かす場合、ローカルでの体験はむしろこのラインに落ち着きやすいのです。

もちろん、最初の口コミには非常に現実的な前提があります。それはエコシステムがまだ追いついている最中だということです。テンプレート、量子化、推論フレームワーク、フロントエンドツールなど、多くのものがまだ完全に追いついていません。そのため、現段階で目にするレビューは、以下の2つのレイヤーに分けて見るのが最善です。

モデル本体: 今回は確かに大きな進歩があった
ローカル体験: 今後もツールの成熟度に影響され続けるだろう

第1回の結論について

単に今回のGoogleが何を発表したのかを知りたいだけであれば、一言で十分です。「Gemma 4」は、「小さいものから大きいものまで並べる密度の高いモデル」という古い考え方ではなく、デバイス側、ローカルデプロイ、品質の上限という3つの道を分離しました。「E4B」、「26B A4B」、「31B」と名前は奇妙ですが、背後にあるのは非常に現実的なデプロイメントの分業です。しかし、もし私に今回の最大の変化は何だと尋ねられたら、やはりこの判断になります。パラメータでも、ベンチマークスコアでもなく、Googleがようやく「Gemma 4」を皆がより安心して使えるオープンソースライセンスに組み込んだことです。この一歩こそが、表の数字以上に重要です。次の記事では、発表会の論調は語らず、直接ローカルマシンに戻ります。やはりアップグレードされていない「RTX 3060 12GB」を使い、なぜ私が最初に注目したのは「31B」ではなく「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のソリューションはバックアップにはなりますが、速度が出ません。今回の内容は多岐にわたるので、シリーズ記事に分割すべきか評価してください。

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

第1の記事では、「今回具体的に何がリリースされたのか」と「プロトコルがなぜ重要なのか」を明確に伝えることに専念し、ローカル体験に関する話題は取り上げないようにする。
モデルラインナップの説明は、まずモデル群を分解してからアルファベットの意味を説明するという順序にし、前回のバージョンよりも論理的な流れを重視する。
プロトコルに関する部分は、「今回緩和されたのはパラメータではなく、利用制限である」という判断軸を維持する。
コミュニティの評価については、まとめに留め、ローカル体験に関する記述は過度に盛り込まないようにする。

弱いモデルに無理に強いものを適用しない

Thu, 02 Apr 2026 22:05:00 +0800

最近、いくつかの端的な作業を MiniMax やローカルモデルに移行させているが、使うほど「最強モデル」という基準で物事を測るのは違うと感じるようになった。

私の判断は非常にシンプルだ。弱いモデルに無理に難しいタスクを割り当ててはいけない。「MiniMax」のようなモデルは、能力が劣っているのは事実だが、複雑なコーディング、長尺の推論、曖昧な要件の分解といった作業には確かに物足りない。しかし、データクレンジング、ドキュメント作成、提案資料の検索といったタスクであれば、これらは十分にこなせる。同じロジックで、ローカルの12Bクラスのモデルも同様だ。翻訳、フォーマットの書き直し、バッチ処理でのクレンジングなど、むしろそちらが本来適している場所なのだ。

端的に言えば、モデルに価値がないのではなく、単に間違った場所に配置されているだけだ。

本当の問題は、モデルがどれだけ強力かではなく、どれだけ「生きている」かである

多くの人が大規模言語モデルについて話すとき、頭の中では最も難しいタスクを思い浮かべがちです。

複雑なエンジニアリングを単独で書くこと
システム全体を一度に分解すること
長いコンテキスト内での複数ターンにわたる推論の処理
検索しながら計画し、実行するこれらはもちろん重要です。しかし、現実の業務で机の上に積み重なっているものの多くは、このような作業ではありません。むしろ多いのは以下の類です：
一連の汚れたフィールドをクリーンアップすること
ばらばらの資料を読みやすいドキュメントに整理すること
長文を要約、FAQ、アウトラインに変更すること
中文と英文が混在する内容を統一フォーマットにすること
複数のウェブページから資料を探し出し、ついでに提案書の草稿としてまとめることこのようなタスクで最も必要なのは、「モデルが天才のように考える」ことではなく、以下の3点です：
指示追従性が極端すぎないこと（常識的であること）
出力構造が可能な限り安定していること
コストが十分に低く、何度も使いたくなるほど低いことだからこそ、私は弱いモデルは役に立たないのではなく、単にフラッグシップモデルと同じ戦場に持ち出せないだけだと考えているのです。

MiniMax が真に得意なこと

まず MiniMax についてです。

公式は MiniMax-M2.5 の位置づけを非常に高く設定しており、プレスリリースやオープンプラットフォームのドキュメントでは、プログラミング、ツール呼び出し、検索、オフィス生産性といったシナリオに重点を置いています。さらには速度と価格の優位性を強調しています。これらの主張を完全に信じられないわけではありませんが、私はそれを分解して見る方が好みです。

私にとって、MiniMax が真に使いやすいのは、「最も複雑な開発タスク」ではなく、以下の点です：

データクレンジング

データクレンジングと一口に言っても、半構造化テキストの肉体労働です。

名称の統一
フィールドのマッピング
外れ値のアノテーション
分類ラベル付け
表形式フィールドの補完このような作業が最も恐れるのは、モデルが「愚か」なことではなく、フォーマットが不安定であったり、出力が拡散したりすることです。モデルが JSON、表、固定テンプレートに従って結果を出力できれば、実は十分な場合が多いです。高性能なモデルももちろん可能ですが、最も高価なモデルをフィールドクレンジングに使うのは、多くの場合費用対効果が悪いです。

ドキュメント作成

ドキュメント作成は面倒くさい、難しいわけではない。インターフェースが変わる、プロセスが変わる、フィールドが変更される、といったたびに説明書を修正しなければならない。この過程には、モデルに高い創造性が求められるというよりは、むしろ余計なことをして元の明確な情報を曖昧にしてしまわないように注意することが重要だ。 MiniMax はこのような作業において、想像以上に信頼できることが多い。特にコンテキスト（文脈）を準備しておけば、真のエンジニアというよりも、実務ができるドキュメントアシスタントのような存在になる。

方案資料検索

公式側も検索やツール呼び出しを推進しているので、この方向性は問題ありません。多くの場合、私たちが求めているのはモデルに「空から答えを思いつかせる」ことではなく、ウェブページ、ドキュメント、お知らせ、資料などをまず探し出してきて、それから整理してもらうことです。このようなシナリオでは、MiniMax のような安価なモデルの価値が非常に高くなります。なぜなら、検索、要約、統合といった作業は元々頻繁に行う雑務だからです。したがって、私の実際の見解は以下の通りです：MiniMax がダメなのではなく、むしろ生産パイプラインの中での「汚い仕事」「面倒な仕事」「繰り返しの仕事」に向いているということです。雑用をさせるなら、合格点であることが多いですが、すべてを包括的に担当させようとすると、がっかりする確率が高くなります。

ローカルの12Bモデルは、持ち帰るのに最も適したタスクがある

さらに下を見ると、ローカルデプロイメントは基本的に同じロジックです。多くの人が「ローカルモデル」と言うと、どうしても一つの疑問が浮かびます。「クラウド上のフラッグシップに取って代われるのか？」と。しかし、この質問自体が最初から偏っていると思います。ローカルの12B程度のモデルが持つ真の価値は、「自分も最強クラスのタスクをこなせることを証明する」ことではなく、安定していて、反復的で、機密性が高く、利益率は低いが頻度の高い作業を持ち帰ることなのです。

翻訳

これはローカルモデルにとって得意なシナリオの一つです。 Qwen2.5 の公式ブログでも明記されているように、長文生成、構造化データ理解、JSON 出力などが強化されており、さらに29以上の言語をサポートしています。この組み合わせは、翻訳、バイリンガルでの書き直し、フォーマットの統一、専門用語の標準化といった作業に本質的に適しています。技術ドキュメント、フィールドの説明、製品紹介、インターフェースコメントなどは、構造が安定しており、専門用語が固定されていることが多いため、ローカルモデルが最もエレガントに翻訳できるとは限りませんが、通常は十分な品質です。

データクレンジング

ここがローカルモデルが特に現実味を帯びている点です。多くの表、ドキュメント、業務資料は、クラウドにアップロードしたくないものがあります。特に内部データ、顧客情報、議事録、未完成の提案書などは、プライバシーや権限が関わるため、ローカルで実行する方がずっと安心できます。このような状況において、ローカルの「12B」程度のモデルの意義は、「どれだけ賢いか」ではなく、「自分のマシン上で動作し、こうした面倒な作業を安定してこなせるか」という点にあります。

固定フォーマットへの書き換え

例えば：

会議議事録を固定テンプレートに整理する
商品タイトルを統一の命名規則にクレンジングする
バグの説明を工單形式に書き直す
中英が混在したテキストを単語バージョンにクレンジングするこのようなタスクは共通の特徴を持っています：ルールが明確、バッチ処理が大きい、繰り返しが多い、単発あたりの価値は高くないが、総量が多いのが面倒。これこそがローカルモデルが最も適している仕事です。

3060 12GB で 12B クラスのモデルを動かせるのか

この件については、もっと現実的に書く方が良いと思います。「動かすことはできるが、あまり期待しすぎないでください。」という感じです。

Google は Gemma 3 の公式ドキュメントで、非常に参考になるVRAM使用量の表を公開しています。Gemma 3 12B を動かすには、おおよそ以下のメモリが必要です：

全精度バージョンをロードする場合：約 20 GB
中程度の量子化バージョンをロードする場合：約 12.2 GB
より低いVRAM使用量のバージョンをロードする場合：約 8.7 GB

公式はまた、これがモデルのロードに必要なメモリ量のみであり、プロンプトや実行時の追加オーバーヘッドは含まれていないと注意喚起しています。

この一文が非常に重要です。

これはどういう意味か？ 3060 12GB のようなグラボで 12B クラスのモデルを動かすことが不可能だということではなく、前提条件があるということです。その前提とは通常以下の通りです：

量子化されたバージョンを使用していること
コンテキスト（プロンプト）を長すぎないようにすること
タスクが複雑すぎないこと
速度が平均的、あるいは遅くても許容できること

もしあなたがこれらの前提を受け入れる意思があるなら、ローカルで 12B クラスのモデルを動かすことは確かに可能です。少なくとも翻訳、要約、表のクレンジング、固定フォーマットへの変換といったタスクであれば、大げさな要求ではありません。

また、Qwen2.5-14B-Instruct-GGUF の公式リポジトリ自体が複数の量子化形式を提供しており、これはすでに考え方を非常に明確に示しています。このクラスのモデルは、本来ローカル推論のエコシステムを念頭に置いて適応されているのです。

したがって、私の結論は一貫して「3060 12GB が 12B モデルを楽々こなせる」というものではなく、むしろ： **「このようなモデルを動かすことはできるが、期待値が低く、反復性が高く、プライバシーが重要な作業に向いている」**ということです。

安価なモデルとローカルモデルを使うことで節約できるのはAPI費用だけではない

この件について話している人の多くは、まず「お金を節約できる」という反応をします。もちろん、お金の節約は重要です。しかし、私が思うより大きな価値は、以前は面倒だと避けていた雑務を、思い切って外部に委託できるようになることです。以前なら、数百件のデータクレンジングのために専用のスクリプトを書くことはなかったかもしれませんし、数十ページの日英資料のフォーマット統一のために手作業で少しずつ修正することもなかったでしょう。また、一時的な提案書のために資料を集める際も、ウェブページを一つ一つ読み込んで整理することさえなかったはずです。しかし、今は違います。コストが十分に低く、ハードルが十分に低い限り、「やる価値がない」と思われていたこれらの作業が一気に「やる価値がある」ものになります。あなたは「やるべきか？」と悩むのではなく、まず安価なモデルやローカルモデルに実行させるだけです。これが私が目にする最も現実的な変化です。強力なモデルは難題に取り組むことに専念し、弱いモデルは雑務をこなし、ローカルモデルが最終的な保証とバッチ処理を担当する。このように役割分担することで、ワークフロー全体がスムーズになるのです。

まとめ

だから最後に言いたいのは、一つのモデルで全てを解決しようと考えすぎるなということです。 MiniMax のようなモデルは、能力が弱いという点はあるものの、使い物になりません。これを複雑なエンジニアリング、曖昧な要件定義、多段階の推論にぶつけても、当然ながらがっかりさせられるでしょう。しかし、データクレンジング、ドキュメント作成、ソリューション資料の検索といった作業に使えば、かえって非常に扱いやすいことが多いです。ローカルで動作する 12B 程度のモデルも同じです。これらは「もうクラウド上のフラッグシップは必要ない」と証明するためではなく、安定していて、反復的で、機密性が高く、バッチ処理の大きいタスクを、地道に自分自身のマシン上に持ち帰るためにあるのです。つまり、苦手なことを弱いモデルにやらせてはいけないということです。適切な場所（用途）に置けば、それ自体が現実的な価値を持つわけです。

参考資料

作成上の注記

元のプロンプト

minimax の大規模言語モデルは、能力が弱いのは弱いが、データクレンジング作業やドキュメント作成、提案資料の検索などを行う分には問題ない。同じロジックで、ローカルに大規模言語モデルをデプロイし、翻訳などの作業やデータクレンジング作業を行うのも良い。モデルのパラメータ数は12b程度で、ローカルの3060 12GBのグラフィックボードでも動かせるはずだ。

ライティングの思考プロセス要約

「弱いモデルに無理なタスクを割り当てない」という核となる判断は維持し、モデルランキング比較としては記述しませんでした。
MiniMax の部分は、公式が定義するプログラミング、検索、オフィス作業といった用途に基づき、その判断をデータクレンジング、ドキュメント作成、資料検索といった現実的なタスクに落とし込みました。
ローカルモデルの部分では、公式ソースから Qwen2.5 と Gemma 3 の2つを選択しました。一方は多言語対応と構造化出力をサポートし、もう一方は 12B パラメータとVRAM使用量を考慮したものです。
3060 12GB に関する記述は、「帯域幅はあるが、あまり期待しすぎないでほしい」というニュアンスを意図的に含め、量子化推論を絶対的な結論として扱わないようにしました。
最後に、強力なモデル、弱いモデル、ローカルモデルという分類を用いて締めくくり、メインの論旨に焦点を絞りました。