この記事ではLLMに特化して解説します。LLM全般の仕組み・比較・ローカル実行は LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 をご覧ください。

この記事のポイント
  • Gemma 4 12BはGoogle DeepMindが2026年6月3日に公開したApache 2.0のオープンモデル。総パラメータ11.95Bで16GBノートに収まる
  • Vision/Audioエンコーダを廃した「エンコーダレス・マルチモーダル」設計。画像も音声も線形射影でLLM本体へ直送し、256K文脈とネイティブ音声を実現
  • 公式ベンチ・量子化サイズ・Ollama/vLLM実行・落とし穴まで、採用判断に必要な事実を一次ソースで整理する

30秒で理解するGemma 4 12B

Gemma 4 12Bは、Google DeepMindが2026年6月3日に公開したオープンウェイトのマルチモーダルモデルだ。要点を先に押さえる。

・Gemma 4 12BはApache 2.0で公開され、16GBのRAM/ユニファイドメモリを積んだノートPCでローカル動作する
・最大の特徴はエンコーダレス・マルチモーダル設計。画像・音声を線形射影でLLM本体へ直送する
・256Kトークンの長文脈に対応し、Gemma系で初めてネイティブ音声入力を備えた中サイズモデル
・総パラメータは11.95B。公式は「26BクラスのMoEに迫る性能を半分以下のメモリで」と主張
・Ollama・llama.cpp・vLLM・MLX・LM Studioなど主要ランタイムに対応

商用APIに頼らずローカルで画像と音声を扱いたい開発者に直撃する内容だ。クラウドAPIのコストやデータ持ち出しの懸念を避けつつ、マルチモーダルを手元で完結させたい現場にとっては待望のサイズ感と言える。オフライン環境やオンプレ要件のある業務でも、有力な選択肢に入ってくる。本記事では公式の主張と、裏取りできた事実とを明確に分けて整理する。

何が発表されたか：Gemma系譜とGemma 4の位置づけ

Gemmaは、Googleが商用大規模モデルGeminiと同じ研究基盤から派生させたオープンウェイト系列だ。Gemma 2、Gemma 3と世代を重ね、ローカルで動く軽量モデルとして開発者に広く使われてきた。

Gemma 4 12Bの新しさは、これまで「別モジュール」だったマルチモーダル処理をLLM本体に溶かし込んだ点にある。従来の画像エンコーダ（約550M）や音声エンコーダ（約300M）を切り離し、軽量な線形変換だけで多モダリティをまかなう構成へ振り切った。

Apache 2.0での公開も大きな意味を持つ。Gemma 3まではGoogle独自のGemmaライセンスで、利用範囲に独自の条件が付いていた。Gemma 4でApache 2.0に切り替えたことで、商用組み込みや派生モデルの再配布がぐっと扱いやすくなり、エコシステムの広がりを本気で狙う姿勢が見える。

この方向性は、クラウド前提で総パラメータを積み増す競合とは逆を行く。Microsoftの自社モデル戦略を扱った Microsoft MAI-Thinking-1とMAIファミリー7モデル や、1M文脈の開放重みを狙う MiniMax M3｜SWE-Bench Pro 59.0%のオープンウェイトモデル と読み比べると、各社の力点の違いが見えてくる。

Gemma 4 12Bが狙うのは「フロンティアの最高峰」ではなく、「手元の1台で完結する実用的なマルチモーダル」という現実的な立ち位置だ。

背景には、ローカル推論の主戦場が「テキスト専用の軽量LLM」から「画像・音声まで扱えるマルチモーダル」へ移りつつある流れがある。これまでマルチモーダルは重いエンコーダのせいでクラウド寄りだったが、Gemma 4 12Bはそこを軽量化で崩しにきた。総パラメータ11.95Bという数字は、16GBという量産ノートの現実的なメモリ枠から逆算された設計判断と読める。

エンコーダレス・マルチモーダル設計の中身

従来のマルチモーダルLLMは、画像や音声をまず専用エンコーダで特徴量に変換し、それをプロジェクタでLLMの埋め込み空間に橋渡ししていた。エンコーダが処理を終えるまでLLM本体は待たされる。

Gemma 4 12Bはこのエンコーダを丸ごと外した。画像は48×48ピクセルのパッチに分割し、各パッチを1回の行列積でLLMの隠れ次元へ射影する。アテンション層はなく、パッチは独立に処理される。

flowchart LR subgraph 従来["従来のMM-LLM"] I1["画像"] --> VE["Vision Encoder
約550M"] VE --> PJ["Projector"] PJ --> L1["LLM本体"] A1["音声"] --> AE["Audio Encoder
約300M / Conformer"] AE --> PJ2["Projector"] PJ2 --> L1 end subgraph G4["Gemma 4 12B"] I2["画像"] --> EM["軽量埋め込み
約35M / 行列積のみ"] EM --> L2["LLM本体
11.95B"] A2["音声 16kHz"] --> LP["40msフレームを
線形射影"] LP --> L2 end

位置情報も簡素だ。パッチ(x, y)に対して、学習済みのX行列とY行列から2つの埋め込みを引いて足し合わせる「分解された座標ルックアップ」を使う。これがGemma 3までの約550Mの画像エンコーダを、約35Mの軽量埋め込みに置き換えた中身だ。

音声はさらに大胆だ。Conformerなどの音声エンコーダを完全に撤去し、16kHzの生波形を40msのフレーム（各フレーム640サンプル）に切り、テキストトークンと同じ埋め込み空間へ線形射影する。特徴抽出は挟まない。

時間方向の並びは、LLMがもともと持つRoPE（Rotary Position Embedding）がそのまま処理する。音声専用の仕組みを足さずに、テキスト用の位置エンコーディングを1次元の時系列に流用しているわけだ。

エンコーダレスの利点
エンコーダの完了を待たずにLLM本体が即座に処理を始められるため、マルチモーダルのレイテンシが下がる。パラメータも軽くなり、画像エンコーダ550M＋音声エンコーダ300Mぶんがほぼ不要になる。

ただし制約もある。重い専用エンコーダが担っていた高密度な特徴抽出を軽量射影で代替するため、極端に細かい画像理解や雑音の多い音声では、専用エンコーダ型に劣る場面が出る可能性がある。ここは実タスクでの検証が要る。

設計思想としては「モダリティを特別扱いしない」という割り切りが核にある。画像パッチも音声フレームも、いったんLLMの埋め込み空間に射影してしまえば、あとは同じTransformerが等しく処理する。エンコーダという「翻訳係」を挟まないぶん、学習も推論もシンプルになり、テキスト・画像・音声を混ぜたプロンプトを自然に1本のシーケンスとして扱える。

この割り切りは、Gemmaの設計者が「中サイズで実用」という制約を最優先した結果でもある。エンコーダを残したまま12Bに収めると、肝心の言語性能に割けるパラメータが削られる。エンコーダを外してその予算をLLM本体に回すことで、MMLU Pro 77.2%という言語性能とマルチモーダル対応を両立させた、という構図だ。

裏を返せば、エンコーダレスは「軽量なノートで動かす」という目標があったからこそ採れた設計でもある。潤沢なGPUを前提にできるクラウドモデルなら、重いエンコーダで特徴抽出の精度を上げる方が素直だ。制約が設計を決めた好例と言える。

ベンチマーク比較：公式値と保留点

Gemma 4のモデルカードに掲載された12B（Unified）の公式スコアは以下の通りだ。いずれもGoogle自身の実測値である。

ベンチマーク Gemma 4 12B（公称） 測定領域
MMLU Pro 77.2% 一般知識・推論
MMMU Pro 69.1% マルチモーダル理解
GPQA Diamond 78.8% 大学院レベルQA
LiveCodeBench v6 72.0% コード生成
MATH-Vision 79.7% 視覚的数学
CoVoST 38.5 音声翻訳

世代比較として、Gemma 4のモデルカードはGemma 3 27B（no think）のMMLU Proを67.6%と記載している。総パラメータで半分以下のGemma 4 12Bが77.2%を主張しており、これが「26B級MoEに迫る」という説明の根拠になっている。

裏取りの注意
上記はすべてGoogleが選んだ条件での自社実測だ。Artificial AnalysisやLMArenaのような第三者の横並び評価は本記事執筆時点で揃っていない。数値は「ベンダー公称」として読み、自分のタスクでの実測で確かめてほしい。

数値の読み方として注目したいのは、MMLU Pro 77.2%という言語性能とMMMU Pro 69.1%というマルチモーダル性能が、同じ11.95Bのモデルに同居している点だ。エンコーダを外してパラメータ予算をLLM本体に集約した設計が、言語とマルチモーダルのどちらも極端に犠牲にせず両立できていることを示している。

GPQA Diamond 78.8%は大学院レベルの難問QA、MATH-Vision 79.7%は図やグラフを伴う数学問題で、いずれも単なる暗記では解けない推論寄りのベンチだ。これらが7割台後半に乗っているなら、12Bという軽量級としては推論性能も健闘していると評価できる。一方でCoVoST 38.5という音声翻訳スコアは、専用の音声特化モデルと比べれば控えめで、エンコーダレス音声の「割り切り」が出やすい領域だと読める。

Llama 4やQwen 3系との直接比較は、同一サイズ・同一条件の公式数値が揃わないため、本記事では数値の断定を避ける。後段の比較表で軸ごとの定性比較として整理する。

256Kコンテキストの実装と実用上の制約

Gemma 4 12Bは最大256Kトークンの文脈に対応する。長文脈の鍵は、RoPEのような相対位置エンコーディングをスケーリングし、学習時より長い系列でも位置関係を保つ手法にある。

ただし「対応している」ことと「実用速度で使える」ことは別だ。長文脈はKVキャッシュのメモリを線形に食う。256K近くまで詰めると、モデル本体とは別に無視できない量のメモリが必要になる。

長文脈で効くポイント
・KVキャッシュは文脈長に比例して増える。16GB機では量子化版でも実効文脈が頭打ちになりやすい
・KVキャッシュ自体の量子化（int8など）で実効文脈を伸ばせるが、精度とのトレードオフがある
・全256Kを毎回使うのではなく、RAG等で必要箇所だけ詰める設計の方が安定する

量子化との相互作用も見落としやすい。重みをQ4まで落として本体メモリを削っても、長文脈のKVキャッシュが膨らめば結局メモリが足りなくなる。「重みの量子化」と「KVキャッシュ」は別々に効くと覚えておきたい。

具体的に考えると、16GB機でQ4_K_M（約7GB）を載せた場合、OSやランタイムのオーバーヘッドを引いた残りでKVキャッシュをまかなう。テキストだけなら数万トークンは現実的だが、256K近くまで攻めるとキャッシュが本体より重くなり、スワップが発生して実用速度を割る。長文脈の公称値はあくまで「アーキ上の上限」で、手元のメモリが実効上限を決めると考えるのが正しい。

実務では、文脈を闇雲に詰めるより、RAGで関連箇所だけを抽出して数千〜数万トークンに収める設計の方が、速度・コスト・精度のバランスが良い。256Kという数字は「巨大な単一文書を一括投入できる保険」として捉え、常用するものではない、というのが現実的な向き合い方だ。

ローカル実行手順

公式エコシステムは LM Studio・Ollama・Hugging Face Transformers・llama.cpp・MLX・SGLang・vLLM・Unsloth に対応する。ここでは代表的な3経路を示す。

まずOllama。GGUF量子化版をそのまま起動できる。

# Ollama でQ4量子化版を起動（約7GB）
ollama run hf.co/unsloth/gemma-4-12b-it-GGUF:UD-Q4_K_XL

# 起動後、対話プロンプトでそのまま質問できる
>>> このコードの計算量を説明して

次にllama.cpp。OpenAI互換のサーバを立てて既存アプリから叩ける。

# macOS / Linux（Homebrew）
brew install llama.cpp

# OpenAI互換サーバを起動（ポート8080）
llama-server -hf unsloth/gemma-4-12b-it-GGUF:UD-Q4_K_XL

# 単発のCLI推論
llama-cli -hf unsloth/gemma-4-12b-it-GGUF:UD-Q4_K_XL

GPUサーバでスループットを出すならvLLM。Transformers系の重みを読み込み、OpenAI互換APIを提供する。

# vLLM でOpenAI互換サーバを起動するPython例
from vllm import LLM, SamplingParams

llm = LLM(model="google/gemma-4-12B-it", max_model_len=131072)
params = SamplingParams(temperature=0.7, max_tokens=512)

out = llm.generate(["Gemma 4のエンコーダレス設計を一言で説明して"], params)
print(out[0].outputs[0].text)

量子化の目安は次の通り。16GB機ではQ4〜Q5、24GB以上ならQ8やBF16も現実的だ。

量子化 ファイルサイズ 想定用途
UD-IQ2_M 約4.2GB 8GB級・速度優先（精度は妥協）
Q4_K_M 約7.1GB 16GBノートの標準解
Q5_K_M 約8.4GB 16GBで精度寄り
Q8_0 約12.7GB 24GB級・高精度
BF16 約23.8GB 無量子化フル精度

ハードウェア別のざっくりした目安はこうだ。16GBのMacBook AirやWindowsノートならQ4_K_Mが標準解で、テキスト中心なら快適に動く。32GBのMac/PCならQ8_0で精度を引き上げつつ長めの文脈も握れる。GPUを積んだ環境ではvLLMでBF16を載せ、複数リクエストの同時処理でスループットを稼ぐ構成が向く。

AppleシリコンではMLX版を使うとMetal最適化が効き、ユニファイドメモリの利点を活かせる。NVIDIA GPU環境ではllama.cpp（CUDA）かvLLMが定番だ。いずれの経路でも、まずは小さい量子化で起動確認し、速度と精度を見ながら段階的に上のビット幅へ上げていくのが安全な進め方になる。

マルチモーダルの実用範囲

公式が明言するネイティブ入力はテキスト・画像・音声、出力はテキストだ。それぞれの実用範囲を押さえておく。

・画像入力：ファイル／URL／base64で渡せる。48×48パッチで処理されるため、超高解像度の細部読み取りより、図表・スクショ・写真の概要理解に向く
・音声入力：Gemma系で初のネイティブ音声対応。16kHzの波形を直接受け取り、書き起こしや音声翻訳（CoVoST 38.5）に使える。最大30秒が目安で、長尺は分割が必要
・動画入力：独立モダリティとしては非対応。フレームを画像として切り出し、音声トラックを30秒区切りで渡す前処理で擬似的に扱う
・出力モダリティ：出力はテキストのみ。画像生成や音声合成はこのモデルの守備範囲外

音声を「特別扱いせず」テキストと同じ埋め込み空間に流す設計のおかげで、音声・画像・テキストを混在させたプロンプトを1モデルで処理できるのが強みだ。

画像入力はTransformers経由なら数行で試せる。チャットテンプレートに画像とテキストを並べて渡す形だ。

# Transformers で画像＋テキストを入力する例
from transformers import pipeline

pipe = pipeline("image-text-to-text", model="google/gemma-4-12B-it")
messages = [{
    "role": "user",
    "content": [
        {"type": "image", "url": "https://example.com/chart.png"},
        {"type": "text", "text": "このグラフの要点を3つに要約して"},
    ],
}]
print(pipe(text=messages, max_new_tokens=300)[0]["generated_text"])

音声を扱うときは30秒以内に区切るのが要点だ。長尺はチャンクに分割し、結果を後段で結合する設計にする。

# 長尺音声を30秒チャンクに分割して処理する素朴な方針
import math

def split_chunks(duration_sec, size=30):
    return [(i * size, min((i + 1) * size, duration_sec))
            for i in range(math.ceil(duration_sec / size))]

# 例: 95秒の音声 -> [(0,30),(30,60),(60,90),(90,95)]
print(split_chunks(95))

Gemma 3 / Llama 4 / Qwen 3 との比較

同一条件の公式数値が揃わないため、ここでは採用判断に効く軸での定性比較にとどめる。各モデルのサイズや方針が違う点に注意してほしい。

軸 Gemma 4 12B Gemma 3（前世代） Llama 4系 Qwen 3系
MM対応 テキスト＋画像＋音声 テキスト＋画像 テキスト＋画像 テキスト＋画像（VL系）
文脈長 256K 世代により128K前後 大規模（モデル依存） 長文脈対応
総パラメータ 11.95B 12B/27B等 より大規模 多サイズ展開
ローカル必要メモリ 16GBで動作（Q4で約7GB） 同等サイズ相当 単機ローカルは重い サイズ次第
ライセンス Apache 2.0 Gemma独自ライセンス コミュニティライセンス Apache 2.0等
設計の力点 16GB単機でMM完結 軽量・実用 クラウド/スケール 多サイズ・多用途

ローカル単機で画像と音声まで含めて完結させたいなら、Apache 2.0かつ16GBで動くGemma 4 12Bの取り回しが際立つ。生のスコア最高峰やクラウドスケールを狙うなら、より大きな競合モデルが候補になる。

商用利用とライセンス

Gemma 4 12BはApache 2.0で公開された。これはGemma 3までの「Gemma独自ライセンス」からの大きな転換で、商用利用・改変・再配布の自由度が格段に上がっている。独自ライセンスは利用規約の解釈で法務が止まりがちだが、Apache 2.0は広く理解された標準ライセンスのため、社内導入の合意形成が進めやすいという実務上のメリットも大きい。

・商用利用：条件付きで広く許可。Apache 2.0なので利用分野の制限が少ない
・派生モデル・ファインチューニング：LoRA/QLoRA等での追加学習、派生モデルの再配布が可能。公式エコシステムにUnslothが含まれる
・配布時の義務：著作権表示の保持、ライセンス本文の同梱、変更点の明示などApache 2.0固有の義務はある
・データプライバシー：ローカル実行ならプロンプトや音声・画像を外部APIに送らずに処理でき、機微データの取り扱いで有利

ライセンスの実務
Apache 2.0はMITに近い寛容なライセンスだが「無条件」ではない。配布物にNOTICEファイルやライセンス文を含める義務があるため、製品に組み込む前に正式なライセンス本文を確認しておくと安全だ。

よくある落とし穴

ローカルマルチモーダルを初めて触る人がつまずきやすい点を整理する。

・「動く」と「実用速度」は別：16GBで起動はできても、長文脈や音声併用ではトークン生成が遅くなる。体感速度はメモリ帯域とプロセッサに大きく依存する
・量子化での精度劣化：Q2やIQ系まで落とすとサイズは小さくなるが、推論や細かい指示追従が崩れやすい。標準はQ4_K_M前後を起点にする
・MM併用時のメモリ計算：画像・音声を入れると、本体の重みに加えてマルチモーダル入力分のメモリが乗る。重みサイズだけ見て16GBに収まると判断すると足が出る
・Ollama版とHF版の挙動差：GGUF量子化版（Ollama/llama.cpp）とTransformers/vLLM版では、デフォルトのテンプレートやサンプリング設定が違い、出力が一致しないことがある。比較検証は条件を揃える
・動画を期待しすぎない：動画はネイティブ非対応。フレーム分割と音声分割の前処理が前提になる
・学習データのカットオフ：事前学習の知識は2025年1月までが目安。それ以降の出来事はRAGや検索ツールで補わないと、古い情報や推測で答えることがある

特にメモリ計算は事故が起きやすい。たとえば「Q4_K_Mは7GBだから16GBに余裕で収まる」と考えても、画像を数枚と長めのシステムプロンプト、KVキャッシュを足すと一気に12〜14GBに達することがある。本体の重みサイズは「最低ライン」であって「実使用メモリ」ではない、と捉えるのが安全だ。

Ollama版とHF版の差も実害につながりやすい。同じプロンプトでも、GGUF版はチャットテンプレートの改行やBOSトークンの扱いが微妙に違い、指示追従の精度が変わることがある。評価や回帰テストをするなら、必ず同じランタイム・同じテンプレート・同じサンプリング設定で揃えてから比較する。

ローカルLLMを動かす全体像は Ollama × Codex CLIでローカルLLMを使う も参考になる。1兆パラメータ級の開放重みと比べた立ち位置は Kimi K2.6｜Moonshot AIの1兆パラメータLLM で確認できる。

まとめ：Gemma 4 12Bが向いているユースケース

Gemma 4 12Bは「最強のスコア」ではなく「手元の1台で完結するマルチモーダル」を取りにきたモデルだ。向き不向きを整理する。

・向いている：16GBノートでローカル完結したい／画像と音声を1モデルで扱いたい／Apache 2.0で商用組み込みしたい／機微データを外部に出したくない
・慎重に：フロンティア級の最高スコアが要る／超低レイテンシの大量音声処理が必要／動画をネイティブに扱いたい
・判断軸：公称ベンチは参考にしつつ、必ず自分のタスクで小規模に実測してから本採用する

エンコーダレス設計という構造的な賭けが、軽量さとネイティブ音声を同時に実現した。ローカルAIを本気で運用に乗せたい開発者にとって、有力な選択肢が一つ増えたと言える。

実装の最初の一歩としては、Q4_K_M量子化版をOllamaで起動し、まずテキストで指示追従と日本語の質を確かめるのがおすすめだ。そのうえで画像入力、必要なら30秒区切りの音声入力へと段階的に広げ、各段階でメモリと速度を実測しながら本番構成を固めていく。公称スペックを鵜呑みにせず、自分のハードと自分のタスクで一つずつ裏を取ることが、ローカルマルチモーダルを安定運用に乗せる近道になる。

参照ソース

・Introducing Gemma 4 12B — Google公式ブログ
・Gemma 4 model card — Google AI for Developers
・google/gemma-4-12B — Hugging Face
・unsloth/gemma-4-12b-it-GGUF — Hugging Face（量子化版）
・Google DeepMind Releases Gemma 4 12B — MarkTechPost