Google は 2026 年 6 月 3 日に Gemma 4 12B を発表しました。Gemma 4 ファミリーの中では中規模のオープンなマルチモーダルモデルで、より軽量な E4B と、より大きな 26B MoE モデルの間に位置づけられています。目的は、マルチモーダル理解、推論、Agent ワークフローを普通のノート PC やローカル開発環境に持ち込むことです。
一言でいうと、Gemma 4 12B はローカル LLM や開発者向けワークフローに興味があるなら試す価値があります。ただし、「16GB で動く」を「すべての 16GB PC で快適に動く」と読むべきではありません。Gemini、GPT、Claude をすぐ置き換える万能助手というより、適したハードウェア上でローカルのマルチモーダル実験を行うためのモデルです。
今回の発表の要点
Google の説明を見ると、Gemma 4 12B のポイントは次のように整理できます。
- 統一された encoder-free マルチモーダルアーキテクチャを採用し、視覚と音声入力が LLM backbone に直接入る；
- より大きな 26B MoE モデルに近い性能を目指しつつ、メモリ使用量はかなり小さい；
- 16GB VRAM または unified memory のデバイスでローカル実行することを想定している；
- Apache 2.0 ライセンスで公開され、開発者が統合や二次開発をしやすい；
- 生成遅延を下げるために Multi-Token Prediction、つまり
MTPdrafter を備える； - LM Studio、Ollama、Google AI Edge Gallery、LiteRT-LM、Hugging Face、Kaggle、llama.cpp、MLX、SGLang、vLLM、Unsloth などのツールチェーンをサポートする。
ローカル LLM に注目しているなら、Gemma 4 12B の意味は、単なる小型チャットモデルではない点にあります。視覚、音声、コード、Agent のツール利用を、消費者向けデバイスでも動かせる中規模モデルにまとめようとしています。
Encoder-free マルチモーダルアーキテクチャとは
従来のマルチモーダルモデルでは、画像と音声に個別の encoder を用意することがよくあります。画像は視覚 encoder、音声は音声 encoder を通り、その表現が言語モデルに渡されます。成熟した方法ですが、追加の遅延、パラメータ、複雑なメモリ使用を生みます。
Gemma 4 12B はより直接的です。これらの個別 encoder を減らす、または取り除き、視覚と音声入力をできるだけ同じ LLM backbone に直接入れます。
公式 Developer Guide では、次の 2 点が説明されています。
- 視覚部分では、他の中規模 Gemma 4 モデルで使われる多層 vision transformer の代わりに、約
35Mパラメータの軽量 embedder を使います。元の48x48画像 patch は 1 回の行列積で LLM hidden dimension に投影され、座標 lookup で空間位置情報を付与します； - 音声部分では、独立した audio encoder を取り除きます。
16 kHzの生音声を40msframe に分割し、それぞれを線形に LLM 入力空間へ投影します。
狙いははっきりしています。外付けモジュールを減らし、処理を統一することです。開発者にとっては、マルチモーダル遅延の低下、より小さなメモリ footprint、凍結された視覚・音声 encoder を別々に調整しなくてよい微調整のしやすさが期待できます。
なぜ 12B というサイズが重要なのか
Gemma 4 12B はかなり実用的な隙間を埋めています。
小さすぎるエッジモデルはモバイルや軽いタスクには向いていますが、複雑な推論、コード、長い Agent ループでは不安定になりがちです。大きすぎるモデルは能力が高い一方で、普通のノート PC でローカル運用するには重くなります。
12B dense モデルの価値はその折衷にあります。E2B や E4B より推論とマルチモーダルの余裕があり、26B MoE やそれ以上のモデルほど高いハードウェアを要求しません。Google は、16GB VRAM または unified memory のデバイスでローカル実行できることを強調しており、開発者のノート PC、Apple Silicon マシン、独立 GPU を備えたワークステーションを明確に意識しています。
これが Agent シナリオと結びつく理由でもあります。Agent は一度答えるだけではありません。入力を読み、ツールを呼び、コードを書き、結果を確認し、さらに修正します。すべてをクラウドに依存すると、遅延、プライバシー、コスト、制御性が問題になります。マルチモーダル推論の一部でもローカルでできれば、開発体験はかなり変わります。
自分の PC で Gemma 4 12B は動くのか
まず公式の想定を見ると、Gemma 4 12B は 16GB VRAM または 16GB unified memory のデバイスでローカル実行できることを目標にしています。重要なのは VRAM または unified memory であり、Windows のタスクマネージャーに表示される通常の 16GB システムメモリとは同じではありません。
おおまかには次のように考えられます。
- 16GB VRAM の NVIDIA GPU、または 16GB 以上の unified memory を持つ Apple Silicon Mac なら、かなり現実的に試せる範囲です；
- 8GB VRAM の独立 GPU では、より強い量子化が必要になり、速度、コンテキスト長、マルチモーダル入力の規模は妥協が必要です；
- 通常の内蔵 GPU と 16GB システムメモリだけの場合、動くかどうかはツールと量子化版しだいで、読み込めても遅い可能性があります；
- メモリが 16GB 未満なら、日常の主力モデルとして期待しないほうがよく、E2B や E4B のような小さなモデルのほうが現実的です。
もう 1 つ大事なのは、「動く」と「快適に使える」は別だということです。テキストチャット、短いコード質問、単一画像理解は比較的軽い一方で、長いコンテキスト、多数の画像、動画、長い音声、Agent の連続実行はメモリと時間を大きく消費します。
いちばん簡単な試し方
まず感触を知りたいだけなら、最初から推論サービス一式を組む必要はありません。許容できる手間に応じて入口を選ぶのが現実的です。
- LM Studio：コマンドを書きたくない初心者向き。GUI でモデルのダウンロードとチャットができ、まず好みに合うかを見るのに向いています；
- Ollama：コマンドラインに慣れている人向き。モデルの取得、起動、ローカル API の利用が扱いやすいです；
- Google AI Edge Gallery：Google 公式のローカルマルチモーダル demo を試したい人向きで、特に Apple Silicon デバイスと相性があります；
- LiteRT-LM CLI：開発者向き。モデルをローカルの OpenAI-compatible API server として動かし、Continue、Aider、OpenCode などにつなげやすくなります。
目的が「まず触る」なら LM Studio または Ollama からで十分です。目的が「自分のコードアシスタントや Agent ワークフローにつなげる」なら、LiteRT-LM、llama.cpp、MLX、vLLM を見る価値があります。
ローカル実行とクラウドモデルの違い
ローカルモデルの最大の利点は、データを自分のマシンから出さなくてよいことです。ローカルのコード、スクリーンショット、音声、私有ドキュメントを扱うとき、プライバシー面の心理的負担が小さくなります。token 単位課金もないため、たくさん使うほど追加コストは低くなります。
一方でクラウドモデルにも現実的な強みがあります。多くの場合、能力が高く、コンテキストが大きく、ツールエコシステムも成熟しています。複雑な推論、多段の計画、日本語や中国語の文章作成、高信頼性が必要な作業では、Gemini、GPT、Claude のほうがまだ安定しています。
現実的には、どちらか一方ではなく分担です。
- 私有データ、オフライン環境、低遅延のやり取りはローカルモデルを優先する；
- 複雑な文章作成、難しいコード修正、長文書推論、より強い中国語能力が必要な作業はクラウドモデルを使い続ける；
- コマンド実行やファイル変更ができる Agent では、ローカルでもクラウドでも権限制限と人間の確認を入れる。
何に向いているか
Google が挙げている能力は次のようなものです。
- 自動音声認識；
- 話者分離と音声理解；
- 動画理解；
- 画像理解；
- 多段推論；
- コーディングタスク；
- Agent ワークフロー。
Developer Guide では、さらに具体的な例も示されています。
1 つ目は、Gemma 4 12B をローカルで llama.cpp と gemma-skills 経由で使い、OpenCode のような agent harness と組み合わせて、画像処理用の Gradio アプリを作る例です。少しややこしく聞こえますが、要するに同じモデルがアプリを書く Agent にもなり、そのアプリの裏側のマルチモーダルモデルにもなるということです。
2 つ目は、5 分の動画を分析する例です。1 FPS で 313 フレームを抽出し、動画の音声とプロンプトを加えて、場面で何が起きているかを説明させます。Gemma 4 12B が単一画像理解だけでなく、「画像列 + 音声 + テキスト質問」の組み合わせを対象にしていることがわかります。
日常的には、次の用途で試す価値があります。
- ローカルコードアシスタント：プロジェクトを読む、コードを説明する、スクリプトを生成する、Continue や Aider と組み合わせて軽い修正をする；
- 画像 Q&A：スクリーンショット、図表、UI、簡単な画像内容を見る；
- 音声文字起こしと理解：会議の一部、音声入力、短い音声要約を扱う；
- 軽量な動画理解：短い動画を抽出フレームで分析する。長時間動画の精読ではない；
- 私有資料分析：アップロードしにくいドキュメント、画像、社内資料をローカルで扱う。
ローカル開発ツールチェーン
Google は今回、重みだけでなくローカル開発ツールチェーンも強調しています。
試用入口としては次があります。
- LM Studio；
- Ollama；
- Google AI Edge Gallery App；
- Google AI Edge Eloquent；
- LiteRT-LM CLI。
重みは Hugging Face と Kaggle から入手できます。推論と統合には Hugging Face Transformers、llama.cpp、MLX、SGLang、vLLM が使えます。微調整には Unsloth も選択肢です。
ローカル Agent 開発では LiteRT-LM が特に面白いです。Developer Guide によると、litert-lm serve で Gemma 4 12B をローカルの OpenAI-compatible API server として動かせるため、Continue、Aider、OpenCode などを接続しやすくなります。
コマンド例は次のとおりです。
|
|
これは重要な方向です。多くの開発者ツールはすでに OpenAI 風 API を前提に統合を作っています。ローカルモデルが互換サービスを提供できれば、既存のエディタープラグイン、コード Agent、自動化スクリプトをローカル推論バックエンドにつなげられます。
MTP drafter の役割
Gemma 4 12B には Multi-Token Prediction、つまり MTP drafter も用意されています。簡単にいえば、次の token だけでなく、複数の後続 token を先に下書きして待ち時間を減らす仕組みです。
ローカルモデルでは遅延が重要です。コード補完、対話的な編集、音声インタラクション、Agent のツール呼び出しでは、能力があっても遅いモデルは使い心地が悪くなります。MTP は 12B クラスのモデルをローカルデバイス上でよりリアルタイムな操作感に近づけるためのものです。
実際の速度は、量子化、推論フレームワーク、ハードウェア帯域、コンテキスト長、バッチ処理戦略にも左右されます。MTP は魔法の高速化ボタンではありませんが、Google が Gemma 4 12B を単なる benchmark 用モデルではなく、実際のローカルアプリ向けに設計していることを示しています。
開発者にとっての意味
Gemma 4 12B は、特に次の 3 種類の開発者が試す価値があります。
1 つ目はローカル AI ツールを作る人です。ローカルコードアシスタント、ナレッジベース、デスクトップ自動化、画像分析、軽量動画理解などです。すべての入力をクラウドに送りたくないなら、この種のモデルは魅力的です。
2 つ目はエッジまたは私有環境でのデプロイを考える人です。12B モデルはまだ小さいとは言えませんが、より大きなマルチモーダルモデルに比べると導入しやすいです。小規模チーム、研究室、企業内ネットワーク用途では、より現実的なマルチモーダル基盤になり得ます。
3 つ目は Agent ツールチェーンを研究する人です。Google は Gemma Skills Repository も同時に公開しており、単なるモデル呼び出しではなく、Agent が skill、ツール、ローカル実行環境を使ってタスクを完了する方向を意識していることがわかります。
期待しすぎないほうがよいこと
Gemma 4 12B は面白いモデルですが、「ローカルモデルがクラウド大規模モデルを全面的に置き換えた」と考えるべきではありません。
まず、16GB VRAM または unified memory は入口にすぎません。実際の体験は量子化、コンテキスト長、入力モダリティ、推論フレームワークに左右されます。長い動画、多数の画像、長い音声は、メモリと遅延をすぐ押し上げます。
次に、性能が 26B MoE に近いという表現は、標準 benchmark と公式テスト文脈での話です。自分のタスクでは、コード品質、中国語能力、ツール呼び出しの安定性、多ターンの文脈保持を自分で検証する必要があります。
最後に、オープンウェイトと Apache 2.0 ライセンスは利用の敷居を下げますが、安全性評価を不要にするものではありません。モデルがファイルの読み書き、コード実行、OS 操作を伴う自動化ワークフローに入るなら、権限分離、ログ、人間の確認が必要です。
つまり、すぐに次のことを期待しないほうがよいです。
- Gemini、GPT、Claude を全面的に置き換える；
- 小メモリ環境で長い動画や大量の画像を快適に処理する；
- 中国語の文章作成や知識 Q&A でクラウドモデルを自然に上回る；
- 複雑な多ターン Agent タスクを一度で最後まで間違えずに完了する；
- 権限分離なしでローカルコマンドを安全に実行する。
まとめ
Gemma 4 12B の見どころは、ローカル実行、中規模 dense モデル、マルチモーダル入力、encoder-free アーキテクチャ、Agent ツールチェーンをひとつにまとめている点です。最小のエッジモデルほど軽量に振り切っているわけではなく、大型クラウドモデルのように高コスト推論を前提にしているわけでもありません。
開発者にとっては、ローカルマルチモーダル Agent の基盤候補です。ノート PC で試せて、既存ツールチェーンにつなげられ、Hugging Face、llama.cpp、MLX、vLLM、LiteRT-LM といったエコシステムのルートも使えます。
ローカルコードアシスタント、デスクトップ Agent、私有マルチモーダル分析、エッジ AI アプリを作っているなら、Gemma 4 12B は単独でテストする価値があります。