こんにちは、パレイド技術部の夏目です。2026 年 6 月末、Hugging Face に gemma-4-12B-coder-fable5-composer2.5-v1 が公開されました。Gemma 4 12B をコーディングに振ったファインチューン版です。技術部の見方はいつもひとつで、手元で動くか、実用になるか。この一点でニュースを選り分けています。
技術部は 6 月に、ベースの素の 12B を MacBook Air M5 で実測しています。あのときの結論は「速度は 4 本中で最遅（記事生成で 5.8 tok/s）。それでも VRAM 8.1GB で 16GB 機に載ることに存在意義がある」というものでした。今回のコーダー版は、その 8.1GB を量子化で削り、推奨構成（Q4_K_M）で 6.87GB、最小構成（Q2_K）なら 4.5GB まで落としてきました。8GB 機の射程に入るのかどうかを、素の 12B との差分を軸に読みます。
本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
公開されたファクトと、素の 12B との差分
まず、Hugging Face のモデルカード（yuxinlu1/gemma-4-12B-coder-fable5-composer2.5-v1-GGUF）から確定しているファクトを整理します。
| 項目 | 内容 |
|---|---|
| 種別 | コーディング特化ファインチューン |
| VRAM | Q4_K_M 6.87GB（推奨）／ Q2_K 4.5GB（最小） |
| コンテキスト長 | 256K |
| ライセンス | Apache 2.0 |
| 学習データ | Fable 5 + Composer 2.5 の検証済み CoT |
| ベース | Gemma 4 12B |
技術部がこの表で目を留めるのは VRAM の行と、学習データの行です。まず VRAM から。素の 12B は VRAM 8.1GB の Dense（全パラメータを密結合で持ち、推論時に全部を使う構造）でした。汎用知識をひととおり積んだまま 16GB 機にギリギリ載る——それが素の 12B の取り柄で、代償が記事生成 5.8 tok/s という遅さでした。
コーダー版は、その素の 12B から 汎用の知識を削ってコーディングに振り、量子化で圧縮したモデルです。量子化はパラメータの数値を粗い精度に丸めて容量を削る手法のことです。8.1GB が Q4_K_M（パラメータを 4bit に圧縮した推奨構成）で 6.87GB まで下がると、8GB 機の統合メモリに入る計算になります。Q2_K（2bit に圧縮した最小構成）まで落とせば 4.5GB ですが、精度の劣化が大きい。「VRAM 4.5GB から動く」という数字は Q2_K のものなので、実用の基準は Q4_K_M の 6.87GB で見るのが筋です。
次に学習データの行です。モデル名に fable5-composer2.5 とあるとおり、Claude Fable 5 と Composer 2.5 が生成した Chain-of-Thought（思考の連鎖）データを訓練に使っています。さらに、テストを通過したコードだけを学習データに採用する「検証済み CoT」方式を取っています。クラウド最強クラスのモデルが生成した「考え方の筋道」を、ローカルで動く 12B に蒸留した格好です。
ベースの素の 12B が「16GB で動くことを取った」モデルだったことは、別記事で実測済みです。今回のコーダー版は、その続きとして読むのが筋でしょう。
パレイドGemma 4 12B 実測｜16GB で動くことを取った——Denseモデルの存在意義 と e2B/e4B/26B との対比こんにちは、パレイド技術部の夏目です。 Google DeepMind が Gemma 4 12B を公開しました (2026-06-04)。技術部の Gemm…
VRAM 6.87GB は 8GB 機の射程に入るか、256K で何を渡せるか
ここで一度、楽観に水を差しておきます。Q4_K_M の 6.87GB は「モデル本体だけ」の数字です。8GB 機の MacBook Air は、OS と常駐アプリで実メモリの相当ぶんが先に埋まっています。残りにモデルの 6.87GB を載せると、ブラウザを開いたぶんで足が出る——という綱渡りになりがちです。Q2_K（4.5GB）まで落とせば余裕は出ますが、その分コード生成の精度が下がる可能性があります。どの量子化で何を犠牲にするかは、載せてみて初めて分かる部分です。
そのうえで、コンテキスト長 256K（一度に読み込ませられる入力の量のことです）が効く場面を考えます。素の 12B が「汎用の知識で 16GB を取った」モデルだったのに対し、コーダー版は コードを書く一点に振ったモデルです。256K あれば、関数ひとつではなくリポジトリをまとめて読ませる用途が見えてきます。手元のコードベースを丸ごと渡して直させる——この使い方が 8GB 機で成り立つなら、小さくない話です。
ただし、ここに 6.87GB を打ち消しかねない罠があります。長いコンテキストを詰めるほど、KV キャッシュ（モデルが直前までの入力を覚えておく作業用メモリ）でメモリが膨らむからです。6.87GB はモデル本体を載せただけの数字で、256K を実際に埋めにいけば、上乗せぶんで 8GB の枠はあっさり超えかねません。載せるだけなら Q4_K_M で 6.87GB、長コンテキストまで使うなら別勘定——ここは分けて考える必要があります。
まとめ — 「載る」と「使える」の間に、まだ実測ぶんの距離がある
現時点での判定を整理します。
| 観点 | 判定 | 根拠 |
|---|---|---|
| 8GB 機に載るか | △ | Q4_K_M 6.87GB。理屈上は射程だが空きメモリ次第で余裕は薄い |
| 長コンテキスト | ◎（条件付き） | 256K 対応。実際に詰めると KV キャッシュでメモリ増 |
| 速度（tok/s） | 未測 | 素の 12B は 5.8 tok/s と遅かった。要検証 |
| 実コーディング精度 | 未測 | Fable 5 CoT の蒸留効果は手元で確認が必要 |
Q4_K_M 6.87GB が保証するのは「載る」までで、「速い」「賢い」は別の行です。 素の 12B が Dense ゆえに遅かった以上、コーダー版も速度は疑ってかかるのが筋でしょう。Fable 5 の CoT を蒸留した精度向上が実際に効いているかも、コードを書かせてみないと判断できません。
技術部はまだ手元に降ろしていません。「載る」と「使える」の間には、まだ実測ぶんの距離があります。Q4_K_M の 6.87GB が 8GB 機で現実的に回るのか、Q2_K まで落とすと精度はどこまで崩れるのか。表の数字は射程の輪郭を描くだけで、その内側が埋まっているかは別の問題です。
次回は、Gemma4-12B-Coder を実際に Mac に降ろして、速度とコーディング精度を実測します。Q4_K_M と Q2_K を並べて、「載る」と「速い・賢い」の距離を手元の数字で詰めにいきます。