Gemma 4 12Bと26B-A4Bの選び方
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
Gemma 4 12Bと26B-A4Bを、32GB Mac、24GB GPU、H100 80GBで選ぶ実用ガイドです。公式memory表、現行revision、対応runtime、未実測範囲を分けて判断できます。
先に結論
calendarの判断: ノートPCでまずGemma 4を試す読者はgoogle/gemma-4-12Bから容量とruntimeを確認し、より高い品質を優先してサーバーGPUを使える読者だけがgoogle/gemma-4-26B-A4Bへ進む。
対象model: google/gemma-4-12B、google/gemma-4-26B-A4B
対象機器: Apple Silicon Mac 32GB unified memory / MLX、NVIDIA GPU 24GB VRAM / Transformers quantized runtime、NVIDIA H100 80GB / vLLM
32GB Macや24GB GPUで最初に試すなら、音声も入力できる12Bを選びます。26B-A4Bはactive parameterが約4Bでも全weightを読み込むため、品質を優先し、80GB級GPUとserver runtimeを用意できる場合の次候補です。
確認日: 2026年8月24日（Asia/Tokyo）
検証区分: Google公式仕様、Google公式model repository、runtime catalogを照合した机上調査です。KFBではmodelをdownloadせず、速度、TTFT、decode tok/s、実peak memory、消費電力、品質を実測していません。
数値の読み方: memory値はGoogleの静的model load目安です。runtime、OS、KV cache、画像・音声処理、長いcontextの追加分を含まないため、「搭載量以内なら快適」という意味ではありません。
今回比較するモデル
calendarのmodel名はfamilyを示します。実際に会話用途で取得するinstruction-tuned repositoryは、12Bが google/gemma-4-12B-it、26Bが google/gemma-4-26B-A4B-it です。本稿は8月24日に確認したmainの先頭、12Bの707f0a3と26Bの4d7ae49を監査基準にします。どちらも7月20日のtokenizer template更新を含む短縮revisionで、再現するときは取得時にfull commit hashを保存してください。
| 項目 | google/gemma-4-12B | google/gemma-4-26B-A4B |
|---|---|---|
| 実用repository | google/gemma-4-12B-it | google/gemma-4-26B-A4B-it |
| 構造・parameter | dense、11.95B total | MoE、25.2B total / 3.8B active |
| 公式weight dtype | BF16 | BF16 |
| context仕様 | 最大256K | 最大256K |
| 入力→出力 | text・image・audio→text | text・image→text |
| license／費用 | Apache 2.0。weight取得は無償、実行機器・cloud費用は別 | Apache 2.0。weight取得は無償、実行機器・cloud費用は別 |
| 公式が案内するruntime | Transformers、MLX、llama.cpp、Ollamaなど | Transformers、vLLM、SGLang、MLX、llama.cppなど |
| 向く入口 | laptop、desktop、小型server | desktop、小型server、server GPU |
| 避ける条件 | 最高品質だけを優先し、80GB級GPUを用意済み | 24〜32GBに長context込みで余裕を残したい、音声入力が必要 |
Gemma 4の現行overviewは12Bをdenseかつencoder-free、26BをMoEとし、両方を256K contextとして整理しています。Gemma 4 12Bの公式発表は、12Bを16GBのVRAMまたはunified memoryでlocal実行できるmodelとして位置付けます。ただし、どのprecision、context、runtimeで16GBに収めたかを全構成へ一般化しません。
機器ごとの適性
Googleの2026年7月8日版memory表は、model load時の目安を次のように示します。表には追加物のload overhead 20%が含まれますが、runtimeとcontext用memoryは含まれません。peak RAM／VRAMの実測ではありません。
| model／variant | BF16 | SFP8 | Q4_0 | 向く機器 | 判断段階 |
|---|---|---|---|---|---|
| google/gemma-4-12B | 26.7GB | 13.4GB | 6.7GB | 32GB Mac、24GB GPU | 量子化を選ぶ容量上の第一候補 |
| google/gemma-4-26B-A4B | 57.7GB | 28.8GB | 14.4GB | H100 80GB、余裕あるserver | BF16は公式の単一H100起動範囲、他は容量候補 |
Apple Silicon Mac 32GB unified memory / MLX
まず12Bです。Googleは12Bのlocal runtimeとしてMLXを案内し、Googleの発表から辿れるmlx-communityのGemma 4 collectionには12Bの4bit・8bit変換があります。ただし、変換artifactはGoogle本体repositoryとは別revisionです。model元revision、MLX artifact revision、MLX LM versionを一組で保存し、4K程度の短いcontextから始めます。
26Bの4bitは静的load目安だけなら14.4GBですが、MoEは全weightを常駐させ、画像処理やKV cacheも必要です。32GBへ「収まる可能性」と、応答速度・長時間安定性・256K contextの実用性は別です。12Bで用途を満たせないと確認する前に26Bへ進みません。
NVIDIA GPU 24GB VRAM / Transformers quantized runtime
ここも12Bを先に選びます。12BのSFP8 13.4GBまたはQ4_0 6.7GBという仕様上の余白を、Transformers、CUDA、入力token、出力token、画像処理へ使えます。26B Q4_0の14.4GBも静的loadは候補ですが、Googleの表はTransformers上の実peak VRAMを保証しません。24GBで26Bを選ぶ場合は、公式QAT artifactと対応quantized backendを固定し、contextを小さくしてOOMの有無だけを先に確認します。
NVIDIA H100 80GB / vLLM
26B-A4BをBF16で扱う本命です。2026年4月のGemma 4公式発表は、26Bと31Bのunquantized BF16 weightが単一H100 80GBに収まり、vLLMを対応runtimeに含むとしています。これは起動容量の説明であり、TTFT、decode速度、同時request数、256K context、peak VRAMの保証ではありません。12Bの実機結果と同じprompt・dtype・runtimeで比較していない限り、MoEのactive 3.8Bから速度を推定しません。
性能データの見方
Google DeepMindのGemma 4ページは26B-A4Bを高品質側、12B発表は12Bを26Bに近いbenchmark performanceと位置付けています。ただし、calendarの公式根拠には12Bと26Bのhardware、runtime、quantization、input／output token数、反復回数を揃えた速度測定がありません。そのため本稿のbenchmarkStatusはnot-measuredです。
選択に使うのは、同じGoogle資料で確認できるparameter、context、入力形式、静的load memory、runtime対応だけです。quality scoreを使って勝敗を作らず、次の値は未公表・未測定として残します。
- TTFT、prefill tokens/s、decode tokens/s、inter-token latency、request throughput
- 32GB Mac、24GB GPU、H100 80GBそれぞれの実peak memoryと消費電力
- 同じ日本語prompt、同じquantization、同じruntimeでの12B対26B品質差
- local実行とcloud endpointの総費用、地域別提供、長時間安定性
どれを選ぶか
| 読者の条件 | 最初の選択 | 理由 | 次へ進む条件 |
|---|---|---|---|
| 32GB Macで音声・画像も試す | 12BのMLX量子化 | 12Bだけが音声入力を持ち、memory余白を取りやすい | artifact revisionを固定し、実promptで不足を確認 |
| 24GB NVIDIA GPUでTransformersを使う | 12Bの公式QAT系量子化 | runtimeとKV cacheの余地を残しやすい | 12Bで品質不足、26Bの短context load検証を別に実施 |
| H100 80GBとvLLMを用意できる | 26B-A4B BF16 | Googleが単一H100のload範囲を明記 | 実traffic条件でTTFT・decode・peak VRAMを測定 |
| 音声入力が必須 | 12B | 26Bはtext・image入力 | 音声前処理と長さの実機確認 |
| 速度値だけで選びたい | 保留 | 同条件の公開測定がない | 同じrevision・dtype・runtime・機器の測定を得る |
試す場合の最短手順
- 12Bのinstruction-tuned repositoryと
707f0a3を記録します。MLXを使う場合は変換artifact側のfull revisionも別に記録します。 - 32GB Macは4bit、24GB GPUは対応する公式QAT系quantized artifactを第一候補にし、contextは4K、batch 1、同時実行1から始めます。
- textを1件だけ入力し、model ID、revision、runtime version、実際のpeak memory、出力完了を記録します。画像・音声はtext成功後に別試験へ分けます。
- OOM、template error、崩れた出力が出たらprocessを停止し、download済みartifactを隔離します。contextを短くするか、Google本体repositoryとruntimeの対応表へ戻り、別model名へ推測で置き換えません。
本稿はcommand outputを作っていません。MLXの導入とcache運用を先に確認する場合はApple Silicon Macのmemory別model選びを、GUIで量子化とcontextを調整する場合はLM Studioのmemory別設定を参照してください。GGUFを自分で作る場合はHugging FaceからGGUFへ変換する手順で変換元revisionを固定します。
公開ベンチマークを詳しく見る
同じテーマの比較記事では、model revision、artifact、backend、機器条件を固定し、公開されていない速度値を空欄のまま残して適用範囲を整理します。
参考資料
- Google：Gemma 4公式発表（2026年4月2日。歴史的発表とH100／runtime対応の確認に使用）
- Google DeepMind：Gemma 4（2026年8月24日確認。familyの現行提供範囲に使用）
- Google：Gemma 4 12B公式発表（2026年6月3日）
- Google AI for Developers：Gemma 4 overview（2026年7月8日更新）
- Google AI for Developers：Gemma model選択（2026年6月3日更新）
- Google公式repository：gemma-4-12B-it commit履歴（先頭revisionは2026年7月20日）
- Google公式repository：gemma-4-26B-A4B-it commit履歴（先頭revisionは2026年7月20日）
