Gemma 4 12Bと26B-A4Bの機器適性比較
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
Gemma 4 12Bと26B-A4Bの現行revision、BF16・量子化artifact、MLX・Transformers・vLLM、公式load memoryを固定し、32GB Mac、24GB GPU、H100へ適用できる判断と未測定範囲を比較します。
先に結論
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
比較できるのは、現行repository、parameter、公式load memory、context、入力形式、対応runtimeです。同じhardware・backend・quantizationで測ったTTFTやdecode tok/sは確認できないため、12Bと26B-A4Bの速度勝敗は付けません。
確認日: 2026年8月24日（Asia/Tokyo）
検証区分: Google公式仕様と公式repositoryを照合した公開資料の机上調査です。KFB実測、独立測定、同条件の開発元throughput測定はありません。
比較上の制約: Googleのmemory表は静的model loadの目安で、runtime、OS、KV cache、prompt、生成token、batch、concurrencyを含みません。active 3.8Bからdecode速度を推定せず、weight sizeから品質や安定性も推定しません。
比較対象と測定条件
実用上の対象はinstruction-tuned artifactです。family名のgoogle/gemma-4-12Bとgoogle/gemma-4-26B-A4Bを、次のrepositoryとrevisionへ結び付けます。
| 項目 | 12B | 26B-A4B | 確認元・扱い |
|---|---|---|---|
| model／revision | google/gemma-4-12B-it@707f0a3 | google/gemma-4-26B-A4B-it@4d7ae49 | Google公式repositoryの2026年7月20日先頭commit。再現時はfull hashを保存 |
| artifact | instruction-tuned Safetensors、BF16 | instruction-tuned Safetensors、BF16 | 12B model card、26B model card |
| parameter | 11.95B total、dense | 25.2B total、3.8B active、128 experts中8 active＋shared | Google公式model card |
| quantization／dtype | BF16。公式QATにQ4_0等 | BF16。公式QATにQ4_0等 | Gemma 4 overview。artifactごとに別revision |
| runtime／backend | MLX、Transformers、llama.cpp等 | vLLM、Transformers、SGLang等 | 公式発表とrepository catalog。versionは取得時に固定 |
| hardware／memory | 32GB Mac、24GB GPUの量子化候補 | H100 80GBのBF16候補 | 公式load memoryとH100記載。実peakは未測定 |
| OS／driver | macOS・MLX版は未固定 | Linux・CUDA・driver版は未固定 | 本稿では実行していないため比較条件にできない |
| context／入出力token | 最大256K仕様。測定input／output数なし | 最大256K仕様。測定input／output数なし | 最大値は実用設定ではない |
| prompt template | repository同梱template | repository同梱template | 7月20日にresponse template更新。別revisionを混ぜない |
| sampling | 未固定 | 未固定 | quality・速度比較をしていない |
| batch／concurrency | 未固定 | 未固定 | throughput比較をしていない |
| warm-up／測定回数 | 0回 | 0回 | KFBは実行していない |
12Bの707f0a3を含むcommit履歴と26Bの4d7ae49を含むcommit履歴は、weightだけでなくtokenizer templateもrevision管理すべきことを示します。mainだけを記録すると、同じmodel名でもmulti-turnやtool callの入力が変わり得ます。
ベンチマーク結果
本稿のbenchmarkStatusはnot-measuredです。Google DeepMindの現行Gemma 4ページにはvendor benchmarkがありますが、calendarの公式根拠から12Bと26Bの同一hardware、runtime、quantization、入出力token、batch、反復回数を揃えた速度表は確認できません。したがって、公開quality scoreをdevice速度へ転用せず、結果表は仕様として確認できた列だけにします。
| 測定区分 | model／revision | 公式load memory | context仕様 | TTFT | decode tok/s | 実peak memory | quality |
|---|---|---|---|---|---|---|---|
| 公式仕様・未実測 | 12B 707f0a3 / BF16 | 26.7GB | 最大256K | 未公表 | 未公表 | 未測定 | 同条件のKFB比較なし |
| 公式仕様・未実測 | 12B / SFP8・Q4_0 | 13.4GB・6.7GB | 最大256K | 未公表 | 未公表 | 未測定 | quantization別未比較 |
| 公式仕様・未実測 | 26B 4d7ae49 / BF16 | 57.7GB | 最大256K | 未公表 | 未公表 | 未測定 | 同条件のKFB比較なし |
| 公式仕様・未実測 | 26B / SFP8・Q4_0 | 28.8GB・14.4GB | 最大256K | 未公表 | 未公表 | 未測定 | quantization別未比較 |
これらはGoogleの7月8日版memory仕様にあるmodel load目安です。20%のload overheadを含みますが、supporting softwareとcontextを含みません。よって12B BF16 26.7GBを32GB unified memoryへ載せたときの残り5.3GBを、そのまま利用可能KV cacheとは扱えません。同様に26B Q4_0 14.4GBを24GB VRAMへ載せられるという計算から、長contextや画像入力の安定性を断定できません。
機器ごとの適性
| 機器／memory | 対象model | revision・backend | 判断段階 | 向く用途 | 避ける条件 |
|---|---|---|---|---|---|
| Apple Silicon Mac 32GB unified memory / MLX | 12B | Google元revision＋MLX変換revisionを別々に固定 | 量子化の容量上の第一候補 | local text・image・audioの試用 | 26Bをactive 4Bだけで軽いと判断、最大contextから開始 |
| NVIDIA GPU 24GB VRAM / Transformers quantized runtime | 12B | Google公式QAT系artifact＋対応Transformers backend | 量子化の容量上の第一候補 | 1 request、短contextの試用 | 26B Q4を余白確認なしで本番化 |
| NVIDIA H100 80GB / vLLM | 26B-A4B | BF16 4d7ae49＋vLLM version固定 | 公式の単一GPU load範囲 | server GPUで品質側を評価 | 256K、並列、高throughputを未測定のまま約束 |
32GB MacとMLX
Googleの12B Developer Guideは、12Bを16GB VRAMまたはunified memoryでlocal実行できるmodelとしています。Google発表からリンクされるMLX collectionには12Bの4bit・8bit等がありますが、MLX変換はGoogle本体repositoryと別artifactです。正確なmlx-community/...名、conversion metadata、revision、MLX LM versionを固定できない試験は再現条件に数えません。
32GBでは12Bを先に試す判断に十分な容量根拠がありますが、speed、audio latency、image処理、実peak unified memoryは未測定です。26B 4bitも静的weightは候補ですが、同じMac上の12B対26B測定がないため、品質向上と待ち時間のtrade-offは保留します。
24GB NVIDIA GPUとTransformers量子化
12BはSFP8またはQ4_0の公式load目安に対して余白があります。26BのQ4_0も14.4GBですが、24GBとの差9.6GBにruntime、CUDA context、KV cache、vision処理が必ず収まるとは限りません。公式QAT collectionにはengine別suffixがあり、-w4a16-ct、-gguf、unquantized QAT sourceを同じartifactとして扱わないことが重要です。
24GBでの判断は、12Bを短いtext promptでloadできるかまでです。prefill、decode、画像、長context、concurrencyは測ってから追加します。26Bへ移る場合はOOMの有無だけでも別試験にし、12Bと異なるbackendの値を同じrankingへ入れません。
H100 80GBとvLLM
Gemma 4の初回公式発表は、26Bと31Bのunquantized BF16 weightが単一H100 80GBへ収まり、vLLMを対応runtimeとして挙げます。26Bの公式repositoryもvLLM起動経路を掲示しています。この二点から、H100 80GBは26B BF16を評価する容量候補です。
ただし、Googleの文言は「weightが収まる」ことです。KV cache、vision encoder、CUDA graph、tensor parallel、batch、concurrency、長い生成、MTP drafterを同時に載せたpeak VRAMではありません。server採用前に、実trafficのinput／output token分布でTTFT、decode、request throughput、peak VRAM、powerを測ります。
結果を適用できる範囲
確認済み事実は、model ID、7月20日時点のrepository先頭revision、Apache 2.0、parameter、最大256K context、入力modalities、公式load memory、公式が列挙するruntimeです。Googleの主張は、12Bがlaptop向けで26Bに近い能力を狙い、26Bがより高品質側でMoEによる効率を狙うという位置付けです。
KFBの判断は、32GB Macと24GB GPUでは12Bを先にし、H100 80GBを用意できる場合だけ26B BF16を評価する、という選択順です。この判断を次へは適用しません。
- 別revision、base model、fine-tune、community GGUF／MLX artifact
- 256K contextを実際に満たすmemory、長文quality、attention latency
- MTP drafterを有効にした速度、通常decodeとの増減率
- 24GB GPU上の26B量子化の安定性、画像入力、batch処理
- 32GB Mac上の12B／26Bのtok/s、power、thermal throttling
- cloud price、地域差、provider固有quantization、availability SLA
原理の補足：active parameterはweight容量ではない
26B-A4Bは1 tokenごとに3.8B parameterをactiveにしますが、routingのため25.2B全体をmemoryへ置きます。active 3.8Bは計算量を理解する手掛かりであって、「4B modelと同じweight容量」「4B modelと同じdecode tok/s」を意味しません。この一点だけを押さえれば、26Bを24GBや32GBへ無条件に推す誤りを避けられます。
再測定する方法
公開比較を更新するときは、次を1行ずつ保存します。値のない列は「未公表」のまま残し、別測定者の値で埋めません。
- model repository、full commit hash、artifact filename、checksum
- runtime／backendとversion、OS、driver、CUDAまたはMLX version
- dtype／quantization、GPUまたはMac型、RAM／VRAM、利用可能memory
- system prompt、chat template、input token、output token、画像・音声の有無
- sampling、batch、concurrency、warm-up、反復回数
- TTFT、prefill tokens/s、decode tokens/s、inter-token latency、request throughput、peak memory、power
12Bと26Bを比較するなら、同じ測定主体が同じhardware、backend、quantization class、prompt、token数、反復で測った結果だけを一つの表へ入れます。H100 BF16とMac 4bitは用途別の別ケースであり、勝敗表にしません。
モデルと機器を先に選ぶ
候補を先に絞る場合は同じテーマの実用ガイドから確認してください。既存の横断的なmemory目安はApple Silicon Macのmodel選び、GUI設定はLM Studioのmemory別設定、独自GGUFのrevision固定はHugging FaceからGGUFへ変換する手順が担当します。
参考資料
- Google：Gemma 4公式発表（2026年4月2日。H100、Apache 2.0、runtime対応の歴史的根拠）
- Google DeepMind：Gemma 4（2026年8月24日確認。現行familyと提供範囲）
- Google：Gemma 4 12B公式発表（2026年6月3日）
- Google Developers Blog：Gemma 4 12B Developer Guide（2026年6月3日）
- Google AI for Developers：Gemma 4 overview（2026年7月8日更新）
- Google公式repository：gemma-4-12B-it（2026年7月20日先頭revisionを8月24日確認）
- Google公式repository：gemma-4-26B-A4B-it（2026年7月20日先頭revisionを8月24日確認）
