Gemma 4 12Bは、Google DeepMindが公開した約120億parameterのローカル実行向けAI model（学習済みAIの本体）です。文章やcodeだけでなく、画像・動画frame・音声を理解してtextで回答できます。
ただし、検索結果にはE4B、12B、IT、QAT、GGUF、MLXなど、役割の違う言葉が一緒に並びます。この記事では英語表記を残しながら日本語の意味を添え、必要スペック、Ollamaでのインストール、量子化、コーディング、音声、クラウドAIとの違いを順番に解説します。
情報確認日：2026年7月19日（日本時間）
結論：Gemma 4 12Bは16GB級PCで試せる中型ローカルAI
Ollamaで12Bを使う最短手順
ollama pull gemma4:12b
ollama run gemma4:12b
12Bを使うときは、モデル名の後ろに:12bを付けます。2026年7月19日時点のgemma4:latestはE4Bを指すため、ollama run gemma4だけでは12Bになりません。
| 使いたい環境・目的 | 最初の候補 | 判断理由 |
|---|---|---|
| 16GB級のMac・GPU搭載PC | Gemma 4 12BのQ4系 | 必要memoryと品質のバランスを取りやすい |
| memoryをさらに抑えたい | Gemma 4 E4B | 12Bとは別に設計されたedge向け小型model |
| 高い性能をlocalで使いたい | 26B A4B・31B | 性能は上がるがmodel全体の読込memoryも増える |
| installせずすぐ使いたい | cloud AI | model downloadとPC側のmemory管理が不要 |
表に出てくる言葉：local AI（ローカルAI）は自分のPC等でmodelを動かす構成、cloud AI（クラウドAI）はproviderのserver上のmodelをnetwork経由で使う構成です。Q4は主に4bitで重みを表す量子化です。edge（エッジ）は、cloudではなく利用者に近い端末側で処理する考え方です。
GoogleはGemma 4 12Bを16GBのVRAMまたはunified memoryで動かせるlaptop向けmodelとしています。memory（メモリ）はmodelを読み込んで処理するための作業領域です。16GBあれば常に余裕があるという意味ではなく、OS、他application、長いcontext、画像・音声処理も同じmemoryを使うため、Q4系と短い入力から始めます。
Gemma 4 12Bとは
Gemma 4 12Bは、2026年6月3日に公開されたGemma 4 familyの中型modelです。公式Model Cardでは11.95B parameter、48 layer、256K contextのdense Unified modelとされています。weightはApache 2.0 licenseで公開されています。
Unifiedは入力処理を一つの中核へ統合した構成
Unified（ユニファイド、統合型）は、text、image、audioの処理を一つのLLM backboneへ集約する設計を指します。Gemma 4 12Bは、大きな画像encoderや音声encoderを別に置かず、画像patchや音声waveformを軽い投影処理でmodel内部の表現へ変換します。
encoder-free（エンコーダーフリー）は「前処理がまったくない」という意味ではありません。従来のような大きな専用encoderを分けず、画像と音声を同じdecoder-only transformerへ直接つなぐ構成です。
モデル名を分解すると役割が分かる
次のような長いmodel名は、一つずつ分けて読みます。
gemma-4-12B-it-qat-q4_0-gguf| 表記 | 日本語での意味 | 選ぶときの役割 |
|---|---|---|
| Gemma 4 | model familyと世代 | Gemma 3等と区別する |
| 12B | 約120億parameter | 能力と必要memoryの規模を判断する |
| IT | Instruction-Tuned、指示応答向け調整済み | 通常のchatや業務利用ではITを選ぶ |
| QAT | 量子化を前提にした学習 | 低bit化したときの品質維持を狙う |
| Q4_0 | 4bit系の量子化方式 | fileと読込memoryを小さくする |
| GGUF | modelを保存するfile format | llama.cpp、Ollama、LM Studio等で使う |
表に出てくる言葉：Bはbillion（10億）、parameter（パラメータ）はmodelが学習で得た数値の集まりです。Instruction-Tunedは「IT業界向け」ではなく、人の指示へ回答するよう調整済みという意味です。format（フォーマット）は保存形式であり、modelの賢さそのものではありません。
BaseとITは用途が違う
google/gemma-4-12Bはbase model、google/gemma-4-12B-itはInstruction-Tuned modelです。baseは追加学習や研究の土台として使い、質問応答、文章作成、code補助など一般的な用途ではITを選ぶのが分かりやすいです。Ollamaの通常tagは、会話向けの調整済みmodelを扱います。
Gemma 4 12Bでできること・できないこと
Gemma 4 12Bはtextを返す生成AIです。入力としてtext、image、audioを扱い、動画はframeとaudioを組み合わせて内容を理解できます。一方、画像生成modelや音声合成modelではありません。
| できること | 条件付きでできること | 別の機能が必要なこと |
|---|---|---|
| 文章作成、要約、翻訳、分類 | 長文・長い会話履歴の処理 | 常に最新情報を得るWeb検索 |
| 推論、構造化出力、function calling | toolを使うagent workflow | tool実行前の権限・安全判断 |
| code作成、説明、review、test案 | repositoryを読んだ修正 | testなしで正しさを保証すること |
| 画像説明、OCR、document理解 | 動画frameと音声の理解 | 画像や動画の生成 |
| 音声認識、音声翻訳、話者分離 | runtimeが対応する音声入力 | 読み上げ音声や音楽の生成 |
表に出てくる言葉：multimodal（マルチモーダル）はtext、image、audio等の複数種類の入力を扱うことです。function calling（関数呼び出し）はmodelがtool名と引数を組み立てる仕組みで、実行権限の確認はapplication側が行います。OCRは画像内の文字を読み取る処理です。
自動的にWebの最新情報を知るわけではない
localへdownloadしたmodelは、それだけではWebを検索しません。最新情報が必要な場合は検索toolやRAGを接続し、取得した情報のURL、日付、本文をmodelへ渡します。modelの学習知識だけで料金、法律、softwareの最新仕様を断定しないでください。
ローカルでも誤情報や危険なcodeは出る
modelを自分のPCで動かしても、hallucination（ハルシネーション、もっともらしい誤情報）はなくなりません。codeはformat、lint、type check、test、差分reviewを通し、production操作やdata削除は人が承認します。repository（リポジトリ）は、codeと変更履歴をまとめて管理する場所です。
E4B・12B・26B A4B・31Bの違い
Gemma 4のmodel名は、単純にparameter数が小さい順へ並べるだけでは理解できません。E2B・E4Bはeffective parameter、26B A4BはMixture of Experts、12Bと31Bはdense modelです。
| モデル | 構造・規模 | 入力 | context | 想定端末 | 公式Q4_0読込memory概算 |
|---|---|---|---|---|---|
| E2B | effective 2B | text・image・audio | 128K | mobile | 2.9GB |
| E4B | effective 4B | text・image・audio | 128K | mobile・laptop | 4.5GB |
| 12B | 11.95B dense Unified | text・image・audio | 256K | laptop・desktop・小型server | 6.7GB |
| 26B A4B | 25.2B MoE・3.8B active | text・image | 256K | desktop・server | 14.4GB |
| 31B | 30.7B dense | text・image | 256K | 大容量memoryのdesktop・server | 17.5GB |
表に出てくる言葉：effective（実効）は小型端末向けの能力設計上の規模、dense（デンス）は原則として全parameterを使う構造です。MoEはMixture of Experts（専門家混合）で、複数の専門部分からtokenごとに一部を使います。active parameterはその処理で実際に動くparameterです。contextのKはthousand（千）を表し、256Kは最大約25万6千tokenです。文字数とは一致しません。
26B A4Bは1 tokenあたり約4Bを動かしますが、推論前には約26B全体をmemoryへ読み込む必要があります。「A4BだからE4Bや4B modelと同じmemoryで動く」とは考えません。
12BはE4Bより重く、26B・31Bより導入しやすい
12Bは、E4Bより推論、coding、画像理解の公式scoreが高く、26B・31Bより読込memoryを抑えやすい中間modelです。16GB級のconsumer laptopで、文章・code・画像・音声を一つのmodelで試したい人に向きます。
Gemma 4 12Bの性能を比較する
次はGoogle公式Model Cardに掲載されたInstruction-Tuned modelのbenchmarkです。本サイトの独立実測ではありません。
| 指標 | E4B | 12B | 26B A4B | 31B | 主に見る能力 |
|---|---|---|---|---|---|
| MMLU Pro | 69.4% | 77.2% | 82.6% | 85.2% | 幅広い知識と推論 |
| AIME 2026 | 42.5% | 77.5% | 88.3% | 89.2% | toolなしの数学問題 |
| LiveCodeBench v6 | 52.0% | 72.0% | 77.1% | 80.0% | code生成 |
| MMMU Pro | 52.6% | 69.1% | 73.8% | 76.9% | 画像を含む専門問題 |
表に出てくる言葉：benchmark（ベンチマーク）は同じ問題と採点方法でmodelを比較する試験です。MMLU Proは複数分野の知識・推論、AIMEは数学、LiveCodeBenchはcode問題、MMMU Proは画像を含む専門問題を扱います。scoreが高くても、自分の日本語文書やrepositoryで同じ結果になるとは限りません。
コーディング性能は高いがcode専用モデルではない
12BのLiveCodeBench v6は72.0%で、E4Bの52.0%を上回っています。ただし、Gemma 4 12Bはcodeだけを目的にした専用modelではありません。対象libraryのversion、repository固有の設計、未公開API、production環境の状態は別に確認します。
クラウドモデルとのscoreは単純比較しない
cloud modelの公開scoreと比べるときは、問題のversion、thinking設定、tool使用、prompt、評価日が同じかを確認します。違う条件の数字を一つのrankingにまとめず、公開benchmarkは候補選び、自分のtask testは採用判断に使います。
Gemma 4 12Bに必要なスペック
公式のQ4_0読込memoryは約6.7GB
Googleの公式表は、weightと追加読込分20%を含む概算として、12BのQ4_0を6.7GB、SFP8を13.4GB、BF16を26.7GBとしています。Ollamaのdownload fileはQ4系で7.2〜7.6GBと表示されます。測っている対象が違うため、数値が完全には一致しません。
| precision・量子化 | 公式読込memory概算 | Ollama上の代表容量 | 主な選び方 |
|---|---|---|---|
| QAT Q4・Q4_K_M | Q4_0は6.7GB | 7.2〜7.6GB | 16GB級環境で最初に試す |
| Q8・SFP8 | SFP8は13.4GB | Q8_0は約13GB | memoryに余裕があり品質差を比べたい |
| BF16 | 26.7GB | 約24GB | 大容量memory環境・変換・研究 |
表に出てくる言葉：precision（精度）は数値をどの細かさで保持するか、bitはその表現に使う情報量です。一般にbit数を下げるほどfileとmemoryを小さくできますが、方式ごとに品質と速度が変わります。weight（重み）は学習済みparameterの本体です。SFP8とQ8_0は同じ8bitでも別の形式、Q4_0とQ4_K_Mも別の量子化方式です。表では近い容量帯を把握するため同じ行へ置いています。
注意：公式の読込memory概算には、長いcontextのKV cache、runtime、OS、他application、複数session分が含まれません。6.7GBだから8GB VRAMで必ず安定する、という保証ではありません。
Macは16GB統合メモリを開始目安にする
| Apple Silicon Mac | 試す構成 | 注意点 |
|---|---|---|
| 16GB unified memory | 12BのQ4系・短いcontext・1 session | OSと他applicationの使用分を空ける |
| 24GB・32GB | Q4で画像・長めの文書、Q8の比較 | 最大256Kを常用せず実際の入力長で測る |
| 32GB超 | Q8・BF16候補、複数条件の比較 | BF16はmodelだけで公式概算26.7GB |
表に出てくる言葉：unified memory（統合メモリ）はApple SiliconでCPUとGPUが共有するmemoryです。GPU専用memoryだけではないため扱いやすい一方、OSやbrowserも同じ容量を使います。sessionは一つの会話・実行単位です。
この表は購入保証ではなく、公式の16GB案内とmemory値から組み立てた開始目安です。Macのchip、Ollama・MLXのversion、context、画像枚数、他applicationで結果が変わるため、購入前は同じ構成の実測を確認してください。
Windows・LinuxはVRAMとsystem RAMを分けて考える
- Q4 weightとruntimeがGPUのVRAMへ収まるか
- 収まらない部分をCPUへ移すと速度が許容範囲か
- system RAMにOSとmodel処理の余裕があるか
- GPU driverとruntimeのversionが対応しているか
- 7GB以上のmodel fileと更新用のstorageを確保したか
VRAM（Video RAM）はGPU専用memory、system RAMはOSと一般applicationも使うmain memoryです。CPU offloadはmodelの一部をCPU側で処理する方法で、動作できても生成速度が大きく下がる場合があります。
256K contextは最大値であり常用推奨値ではない
contextはmodelが一度に参照するprompt、資料、会話履歴、生成文の範囲です。長くするとKV cacheが増えます。最初は4K〜16K程度の実taskから始め、必要な場合だけ段階的に伸ばします。
PC全体の考え方はローカルLLMに必要なPCスペックで、model選びはローカルLLMモデルの選び方で詳しく解説しています。
OllamaでGemma 4 12Bをインストールする
modelは通常のapplicationのようにsetup画面でinstallするのではなく、Ollamaを先に導入し、model weightをdownloadして登録します。Ollama本体のOS別手順はOllamaの使い方も参照してください。
1．Ollamaを導入して起動を確認する
ollamahelpが表示されればCLIを呼び出せています。command not foundになる場合は、Ollamaのinstall、desktop applicationの起動、terminalの再起動を確認します。
2．12Bを明示してdownloadする
ollama pull gemma4:12b
pullはmodelを取得するcommandです。tag（タグ）は、同じmodel名のsize、量子化、実行方式などを区別するlabelです。数GBのnetwork通信とstorageを使うため、容量と接続環境を確認してから実行します。
3．Gemma 4 12Bを実行する
ollama run gemma4:12b入力待ちになったら、まず短い日本語promptで確認します。
あなたは初心者向けの編集者です。
Gemma 4 12Bでできることを、日本語で3項目、
各40文字以内で説明してください。4．tag・量子化・実行状態を確認する
# 取得済みmodel
ollama ls
# model情報
ollama show gemma4:12b
# 実行中modelとprocessor
ollama ps
# modelをmemoryから解放
ollama stop gemma4:12b
# model fileを削除
ollama rm gemma4:12b
modelを削除すると再利用時にdownloadが必要です。会話applicationが別に保存した履歴や添付fileは、ollama rmだけでは消えない場合があります。
MacではActivity MonitorとOllamaの両方を見る
ollama psでmodelとprocessorを確認する- Activity Monitorでmemory pressureを見る
- 初回load時間と2回目以降の応答時間を分ける
- browserや開発toolを開いた通常状態でも測る
- 同じpromptとcontextでGGUF版・MLX版を比べる
QAT・GGUF・MLX・量子化の違い
QAT、GGUF、MLXは同じ種類の選択肢ではありません。「学習方法」「保存形式」「実行framework」を分けると、model pageの名前を読みやすくなります。
| 分類 | 表記例 | 何を表すか | 初心者向けの判断 |
|---|---|---|---|
| 学習方法 | QAT | 量子化の誤差を意識して学習 | official QAT版を比較候補にする |
| 保存形式 | GGUF | model weightと設定を保存 | Ollama・llama.cpp系で使う |
| 実行framework | MLX | Apple Siliconで機械学習modelを動かす | MacでGGUF版と比較する |
| 数値精度 | Q4・Q8・BF16 | weightを表す細かさ | memory、速度、品質で選ぶ |
| 追加調整 | IT | 人の指示へ回答する調整 | chat・実務ではITを選ぶ |
表に出てくる言葉：QATはQuantization-Aware Training（量子化を前提にした学習）、GGUFはllama.cpp系で広く使われる保存形式、MLXはApple Silicon向けframeworkです。「MLXはGGUFより高精度」のようには比較せず、同じmodel・近いprecision・同じpromptで速度とmemoryを測ります。
QATは量子化による品質低下を抑えるための学習
一般的なPost-Training Quantizationは学習後のweightを低bitへ変換します。QATは学習中に量子化の丸め誤差を再現し、低bit化した状態をmodelへ学ばせます。QATだから必ずすべてのtaskで高品質とは限らないため、自分の日本語・code・画像で比べます。
GGUFは量子化方式そのものではない
一つのGGUF formatにQ4、Q5、Q8等の異なる量子化を保存できます。file名のQ4_K_MやQ8_0まで確認し、GGUFという文字だけで容量や品質を判断しません。
MLXはMac向けの実行経路
MLXはAppleが公開するApple Silicon向け機械学習frameworkです。Ollamaにはgemma4:12b-mlx等のtagがあり、MLX Communityにも4bit、5bit、6bit、8bit等の変換modelがあります。Ollama tagを使う方法と、PythonのMLX toolを直接使う方法は環境構築が異なります。
Ollamaの12B tagを比較する
| tag | 公開容量 | 特徴 | 主な用途 |
|---|---|---|---|
gemma4:12b |
7.6GB | Q4_K_M | 迷ったときの開始点 |
gemma4:12b-it-qat |
7.2GB | official QAT系 | QAT版の品質・速度比較 |
gemma4:12b-it-q8_0 |
13GB | 8bit | memoryに余裕がある比較 |
gemma4:12b-it-bf16 |
24GB | 16bit | 大容量memory環境 |
gemma4:12b-mlx |
7.7GB | MLX | Apple Siliconで比較 |
表に出てくる言葉：Q4_K_Mはllama.cpp系で使われる4bit量子化tagの一つ、Q8_0は8bit、BF16はBFloat16という16bit表現です。細かな内部方式を暗記するより、同じtaskで容量、速度、回答を比べます。容量はOllama公式tagsの2026年7月19日時点の表示であり、model更新により変わる可能性があります。
GGUF・Hugging Face・MLXからdownloadする方法
公式weightはGoogleのHugging Face・Kaggleを起点にする
Gemma 4 12Bのbase、IT、QAT、GGUFはGoogle公式accountから配布されています。検索結果にはcommunity変換版や追加調整版も出ますが、初回はpublisherがgoogleであるofficial modelを起点にします。
- model名が
google/gemma-4-12B-itを元にしているか - base、IT、QATのどれか
- GGUF、Safetensors等のformat
- Q4、Q8、BF16等のprecision
- license、revision、更新日、file容量
- community版なら変換手順と元modelが明記されているか
公式QAT Q4_0 GGUFを直接指定する
Hugging Face上のofficial GGUFは、対応するOllamaから次の形式で指定できます。
ollama run hf.co/google/gemma-4-12B-it-qat-q4_0-gguf:Q4_0commandやrepository名は更新される可能性があります。実行前にGoogle公式model pageの「Use this model」に表示された最新commandを確認してください。
MacではOllamaのMLX tagから始める
ollama pull gemma4:12b-mlx
ollama run gemma4:12b-mlxMLXを直接Pythonから使う場合は、MLX LM・MLX VLMの対応version、model architecture、multimodal入力、tool call parserを確認します。最初から複数frameworkを混ぜず、Ollamaの標準12BとMLX tagを同じpromptで比較する方が切り分けやすくなります。
Gemma 4 12Bをコーディングに使う
Gemma 4 12Bはcode生成、説明、修正、test案、diff review、agent workflowに使えます。公式LiveCodeBench v6は72.0%ですが、実務では対象言語とrepositoryに合わせたtestが必要です。
| 作業 | 使い方 | 人が確認すること |
|---|---|---|
| 小さな関数作成 | 入力・出力・例外・versionを渡す | test、境界値、存在するAPI |
| bug調査 | error logと最小codeを渡す | 推測と確認済み事実の区別 |
| diff review | 変更目的と差分を渡す | security、data loss、設計意図 |
| unit test | 仕様と既存test方針を渡す | testが実際に失敗・成功するか |
| agent実行 | read-onlyから段階的に権限を与える | 外部送信、削除、production操作 |
表に出てくる言葉：diffは変更前後の差分、unit testは小さな機能単位を確認するtestです。agent workflowはmodelが複数stepとtool呼び出しを進める構成ですが、modelが高性能でも権限管理と実行直前の承認はapplication側に必要です。
同じ8問でコーディング性能を測る
候補tagを比べるときは、次の8問を同じ設定で実行します。
- JavaScriptの境界値bugを修正する
- PHPの入力validationを追加する
- WordPress hookの実行順を説明する
- SQL injectionの危険箇所を指摘する
- failing testから原因候補を分ける
- git diffを目的・影響・riskへ要約する
- 正常系・境界値・異常系のunit testを作る
- 存在しないAPIを作らず確認質問を返せるかを見る
model,tag,task,correct,test_pass,instruction,speed_tps,max_memory,notes
gemma4,12b,js-boundary,,,,,,
correctは内容の正確性、test_passはtest結果、instructionは指示遵守、speed_tpsは1秒あたりの生成token数です。prompt（プロンプト）はAIへ渡す指示文を意味します。正解率だけでなく、速度、memory、失敗内容を一緒に残します。
Gemma 4 12Bで音声を扱う
model本体は音声認識・翻訳・話者分離に対応する
Gemma 4 12Bは16kHzのraw audioを40ms単位へ分け、LLM内部の表現へ直接投影します。公式資料ではASR、speech-to-translated-text、diarizationがcapabilityとして挙げられています。
ASRはAutomatic Speech Recognition（自動音声認識）、speech-to-translated-textは音声を別言語のtextへ翻訳する処理、diarizationは「誰が話したか」を分ける話者分離です。Gemma 4 12Bが音声を返すという意味ではありません。
Ollamaの12B tagは現在Text・Image入力表示
2026年7月19日時点のOllama公式model一覧では、gemma4:12bはText・Image入力と表示されています。Gemma 4 12Bのmodel本体がAudio対応でも、Ollamaの公開APIやchat画面から同じ方法で音声fileを渡せるとは限りません。
| 実行方法 | text | image | audio | 向く確認 |
|---|---|---|---|---|
| Ollama 12B tag | 対応 | 対応 | versionごとに要確認 | chat・image理解 |
| Hugging Face Transformers | 対応 | 対応 | official Model Cardに例あり | Pythonでaudio処理を検証 |
| LiteRT-LM・Google app | 対応 | 対応 | 対応 | Mac上のlocal multimodal体験 |
表に出てくる言葉：model capabilityはmodel本体が扱える能力、runtime input supportはOllama等の実行softwareが受け付ける入力です。TransformersはHugging Faceのmodel実行library、LiteRT-LMはGoogleの端末向けLLM runtimeです。
音声を試す場合は、同意済みの短いWAVだけを使い、個人名、会議内容、顧客情報を含むfileを無断で入力しないでください。文字起こし結果には聞き間違いがあるため、原音と照合します。
ローカルGemma 4 12BとクラウドAIの違い
Gemma 4 12Bをlocalで動かす方法と、Gemini・ChatGPT等のcloud serviceは、優劣ではなく運用方法が違います。
| 比較項目 | Gemma 4 12B local | cloud AI |
|---|---|---|
| 実行場所 | 自分のPC・自社server | providerのserver |
| 初期準備 | runtimeとmodel download | account・application・API |
| 端末負荷 | memory・storage・電力を使う | 原則として端末負荷は小さい |
| network | 取得後はoffline構成を作れる | 通常は接続が必要 |
| data管理 | log・backup・権限を自分で管理 | providerの規約・設定・契約を確認 |
| 最新情報・tool | 自分で検索・RAG・toolを接続 | productが提供する機能を利用 |
| 費用 | hardware・電力・運用 | subscription・API従量料金 |
| scale | 同時利用に合わせて自分で増強 | managed serviceを選べる |
表に出てくる言葉：providerはcloud serviceの提供者、APIはapplication同士が機能を呼び出す窓口、RAGは資料を検索して回答へ渡す構成です。managed serviceはserver管理の多くをproviderが担う方式、scaleは同時利用や処理量に合わせて資源を増減することです。
localが向く場面
- networkへ接続しない構成で処理したい
- model・runtime・promptを固定して再現したい
- API従量課金ではなく所有hardwareで繰り返し処理したい
- 自分でtool、RAG、権限を設計したい
cloudが向く場面
- model downloadやGPU管理をしたくない
- 大規模modelの品質・速度が必要
- teamで同時利用する
- managedな検索、file処理、monitoringを使いたい
localでも自動的に安全にはならない
local実行でも、application log、会話履歴、backup、malware、誤ったnetwork公開、community model、端末の共有accountから情報が漏れる可能性があります。「外部APIへ送らない」と「dataが安全」は分けて考えます。
動かない・遅いときの確認方法
| 症状 | 考えられる意味 | 最初の確認 |
|---|---|---|
| model not found | tag誤記・古いOllama・network | gemma4:12bとofficial tags |
| out of memory | weight・KV cache・他applicationが収まらない | Q4、context、同時session |
| 応答が極端に遅い | CPU offload・長いprompt・初回load | ollama psと2回目の速度 |
| 12BではなくE4Bが動く | gemma4だけを指定した |
:12bを付ける |
| audioを渡せない | runtime側のinput未対応 | Ollama version・Transformers経路 |
| 回答が不安定 | sampling・thinking・prompt条件が違う | 同じ設定で3回比較 |
表に出てくる言葉：KV cacheは過去のtokenを再計算せず参照する一時memory、CPU offloadはGPUへ収まらない処理の一部をCPUへ移す方法です。samplingは次のtokenを選ぶ設定、thinkingは回答前の推論処理を有効にする設定です。
memory不足なら小さい順に切り分ける
- 他applicationと別modelを終了する
- contextと会話履歴を短くする
- 画像枚数・解像度・音声長を減らす
- Q4系を使う
- 12Bが難しければE4Bで同じtaskを試す
速度は初回loadと生成中を分けて測る
記録する項目
- model tag
- runtime version
- OS・chip・GPU
- unified memory・VRAM・system RAM
- prompt token数
- output token数
- 初回応答までの秒数
- 1秒あたりの生成token数
- 最大memory
- processor表示一つでも条件が違うと速度比較が崩れます。QAT、Q4_K_M、MLXを比べるときは、同じprompt、同じcontext、同じthinking設定、同じ試行回数に揃えます。
Gemma 4 12Bについてよくある質問
Gemma 4 E4Bと12Bの違いは何ですか？
E4Bはeffective 4Bのedge向けmodel、12Bは11.95B parameterのdense Unified modelです。12Bの量子化版がE4Bになるわけではありません。12Bは公式benchmarkとcontext長で上回る一方、必要memoryも増えます。
16GBのMacでGemma 4 12Bは動きますか？
Googleは16GBのVRAMまたは統合メモリを搭載するlaptopでのlocal実行を案内しています。16GB MacではQ4系、短いcontext、1 sessionから始め、memory pressureを確認してください。chip、OS、runtime、他applicationによって結果は変わります。
gemma4:latestで12Bを使えますか？
2026年7月19日時点では使えません。Ollamaのgemma4:latestはE4Bを指します。12Bはgemma4:12bを指定してください。
ITはIT業界向けという意味ですか？
いいえ。ITはInstruction-Tunedの略で、人の指示に沿って回答するよう追加調整されたmodelです。通常のchat、要約、code補助ではITを選びます。
QATとQ4_K_Mはどちらを選べばよいですか？
QATは学習方法、Q4_K_Mは量子化方式なので、直接同じ分類ではありません。最初はOllamaのgemma4:12bを動かし、同じpromptでofficial QAT tagと品質、速度、memoryを比較します。
GGUFとMLXはどちらが高性能ですか？
GGUFは保存形式、MLXは実行frameworkなので、名前だけでは決まりません。同じ元model、近いbit数、同じpromptで、生成速度、最大memory、回答品質をApple Silicon上で測ります。
Gemma 4 12Bで音声を生成できますか？
Gemma 4 12Bの主なoutputはtextです。音声入力の認識、翻訳、話者分離には対応しますが、読み上げ音声や音楽の生成には音声合成modelが別に必要です。
Gemma 4 12Bは日本語とコーディングに使えますか？
多言語textとcodingに対応します。ただし、公式scoreだけで実務適性を断定せず、日本語の指示遵守、対象言語、test成功、存在しないAPIを作らないかを自分の8問で確認してください。
商用利用できますか？
2026年7月19日時点のGoogle公式Model CardではApache 2.0 licenseです。ただし、入力data、生成物、追加学習data、組み合わせるsoftwareやcommunity modelには別の権利・規約があり得ます。個別案件はlicense原文と社内ルールを確認してください。
まとめ
Gemma 4 12Bは、約120億parameter、256K context、text・image・audio入力を備えた中型のUnified modelです。16GB級PCでもQ4系から試せますが、OS、runtime、KV cache、他applicationのmemoryを含めて判断します。
- Ollamaでは
gemma4:12bを明示する gemma4:latestのE4Bと12Bを混同しない- QATは学習方法、GGUFは保存形式、MLXはMac向けframework
- 最初はQ4系と短いcontextから始める
- 音声はmodel本体とruntimeの入力対応を分けて確認する
- codingはbenchmarkに加え、同じ8問とtestで評価する
- localでもlog、backup、権限、誤情報への対策が必要
Ollamaそのものの導入から確認したい場合はOllamaの使い方、PC購入前にmemoryを計算したい場合はローカルLLMに必要なPCスペックを参照してください。