はじめに
Hugging FaceユーザーのYuxinlu氏が2026年6月、Googleの「Gemma 4 12B」をベースにコーディング特化でファインチューニングした量子化モデル「gemma-4-12B-coder-fable5-composer2.5-v1-GGUF」を公開しました。VRAM 4.5GBから動作するQ2_Kクォントから用意されており、llama.cppやLM Studioなど一般的なローカル推論ツールで手軽に実行できます。本稿では、このモデルの概要・仕様・実行手順を解説します。
参考記事
- タイトル: Gemma4-12B-Coder (GGUF) — Composer 2.5 × Fable 5 ✨
- 著者: yuxinlu1
- 発行元: Hugging Face
- 発行日: 2026年6月（公開日記載なし、v2更新メモは2026年6月14日付）
- URL: https://huggingface.co/yuxinlu1/gemma-4-12B-coder-fable5-composer2.5-v1-GGUF
関連記事
要点
- VRAM 4.5GB（または統合メモリ）から動作する量子化済みコーディングモデルで、Q2_K〜Q8_0の5段階のクォントが用意されている
- 学習データはPythonコーディングタスクに特化したChain-of-Thought（CoT）データで、実際にテストを通過したコードのみを採用している
- ベースモデルのGemma 4 12Bに存在したメタデータバグが修正され、実際のコンテキスト長は256K（26万2144トークン）である
- llama.cppのllama-serverを使ったサーバー起動のほか、LM Studio・Jan・Ollamaなどのワンクリックアプリでも動作する
- 安全性アライメントは行われておらず、Pythonとアルゴリズム問題に特化した英語中心のモデルである
詳細解説
モデルの概要と学習データ
このモデルは、Google製のオープンモデル「Gemma 4 12B Instruct」をベースに、Pythonコーディングタスクに特化してファインチューニングした個人・ホビープロジェクトです。
学習データは2種類のChain-of-Thought（CoT：問題を解く前に思考を展開する手法）ソースを組み合わせています。メインセットには「Composer 2.5」が生成した正真正銘の推論トレース（テスト通過を確認済みのコードのみ採用）を使用し、補助セットには「Fable 5」が難問を再解答して生成した合成CoTデータを加えています。双方ともに実行検証済みのデータのみを学習に使っているため、推論がコードとして整合していることが特徴です。
なお、v2の開発に向けたアップデートとして、2026年6月14日付でFable 5のアクセスが停止されたことが報告されています。v2ではComposer 2.5の検証済みCoTを主軸としつつ、GLM-5.2を追加ティーチャーとして検討中とのことです（Gemma 4の推論速度高速化についての過去記事では、Gemma 4ベースモデルのパフォーマンス特性を整理していますので、あわせてご覧いただければと思います）。
コンテキスト長の修正（256K）
Gemma 4シリーズには、上流の config.json に max_position_embeddings: 131072 と誤記された既知のメタデータバグがあり、本モデルの初期版もその影響を受けて131Kとして配布されていました。コミュニティからの指摘を受け、すべてのGGUFクォントは256K（262,144トークン）に修正済みです。モデルの重み自体は最初から正しく、メタデータフィールドのみの問題でした。早期にダウンロードした場合は再ダウンロードが必要です。
クォント（量子化）の選び方
量子化（クォント）とはモデルの重みを低精度に圧縮してファイルサイズとVRAM消費を削減する技術です。精度とサイズはトレードオフになります。
| クォント | ファイルサイズ | 目安 |
| Q2_K | 4.5 GB | 最小構成・ほぼどこでも動く |
| Q3_K_M | 5.7 GB | 8 GB VRAM向け・Q2より大幅に品質が上がる |
| Q4_K_M | 6.87 GB | 推奨・品質とサイズのバランスが最良 |
| Q6_K | 9.11 GB | ほぼ無損失 |
| Q8_0 | 11.8 GB | フルクオリティに近い |
Apple SiliconなどのCPU・GPU統合メモリも同様の数値で見積もれますが、専用GPUよりも推論速度は遅くなります。
VRAM別の利用可能なコンテキスト長の目安
以下は、Q8_0のKVキャッシュ（key-valueキャッシュ：過去トークンの計算結果を保持するメモリ領域）と約1.5 GBのオーバーヘッドを想定した場合の目安です。KVキャッシュをq4_0に変更するとコンテキスト長をおよそ2倍に増やせます。
| VRAM / 統合メモリ | Q2_K | Q3_K_M | Q4_K_M | Q6_K | Q8_0 |
| 8 GB | ~16K | ~10K | ~2–4K | — | — |
| 12 GB | ~48K | ~38K | ~30K | ~12K | — |
| 16 GB | ~80K | ~72K | ~64K | ~44K | ~22K |
| 24 GB | ~200K | ~160K | ~128K | ~110K | ~88K |
| 32 GB | 256K | 256K | 256K | ~230K | ~190K |
前提条件・環境
- 十分なVRAMまたは統合メモリ（最低4.5 GB以上）
- 最新ビルドのllama.cpp（gemma4_unifiedアーキテクチャ対応版が必要。古いビルドではモデルが読み込まれません）
- または LM Studio / Jan / Ollama など対応アプリ
Option A：llama.cppでサーバーを起動する方法
llama.cpp（オープンソースのローカルLLM推論ライブラリ）を使ってAPIサーバーを立ち上げる方法です。
手順：
- Hugging Faceから使用するクォントの .gguf ファイルをダウンロードします（推奨はQ4_K_M）。
- llama.cpp公式リポジトリから最新の llama-server をダウンロードまたはビルドします。
- 注意: gemma4_unified アーキテクチャに対応した最新ビルドが必要です。古いバージョンではモデルが読み込まれません。
- 以下のコマンド（Windowsの .bat ファイル例）でサーバーを起動します。
@echo off
cd /d C:\llama.cpp
:: llama-serverを起動するコマンドです
llama-server.exe ^
-m C:\models\gemma4-coding-Q4_K_M.gguf ^ :: 使用するモデルファイルのパス
--ctx-size 16384 ^ :: コンテキスト長（VRAM表に合わせて調整）
--n-gpu-layers 99 ^ :: GPUにオフロードするレイヤー数（99でほぼ全部）
--no-mmap ^ :: メモリマップを使わない（安定性向上）
-fa on ^ :: Flash Attentionを有効化（速度改善）
--cache-type-k q8_0 --cache-type-v q8_0 ^ :: KVキャッシュの精度（q4_0にすると2倍のコンテキストが使える）
--temp 1.0 --top-p 0.95 --top-k 64 ^ :: サンプリングパラメータ（推奨値）
--host 0.0.0.0 --port 18080 :: サーバーのアドレスとポート番号
pause- 起動後、ブラウザで http://localhost:18080 を開くとチャットUIが表示されます。
- コンテキスト長は上記の表を参考に –ctx-size を調整してください。
- KVキャッシュを q4_0 に変更するとコンテキスト長をおよそ2倍に増やせます。
注意: Macの場合はパスを /Users/yourname/models/… のように変更し、.bat の代わりにシェルスクリプト（.sh）として保存してください。
Option B：ワンクリックアプリ（LM Studio / Jan / Ollamaなど）
LM Studio（GUIで簡単にローカルモデルを管理・実行できるアプリ）、Jan、Ollamaなどの対応アプリに .gguf ファイルをインポートするだけで動作します。コマンドラインに不慣れな場合はこちらが手軽です。
思考モード（Thinking Mode）のサンプリング設定
このモデルはGemma 4のネイティブ思考チャンネルを使い、回答を生成する前に問題を推論してから解答を出力するよう訓練されています。デフォルトのチャットテンプレートで enable_thinking=true が設定されているため、変更は不要です。
推奨サンプリング設定（参考記事のサンプルをもとにしています）：
temperature: 1.0
top_p: 0.95
top_k: 64コーディング用途で決定論的な出力を好む場合は temperature: 0（greedy）も選択肢となります。
利用上の注意点
- 安全性アライメントなし: 学習データはタスク中心で安全性ヘッジが行われていないため、ベースモデルよりも拒否応答が少なくなっています。本番環境で使用する場合は独自のガードレールを追加してください。
- Python・アルゴリズム特化: 推論品質はPythonおよびアルゴリズム問題で最も高く発揮されます。一般知識や数値データは別途確認することをお勧めします。
- 英語中心: 日本語での精度はPython・英語タスクより低いと考えられます。
まとめ
VRAM 4.5GBから動作するコーディング特化の量子化モデルが、個人開発者によって無償公開されました。llama.cppやLM Studioで手軽に実行でき、256KトークンのコンテキストとChain-of-Thought推論を活用したPythonコーディング支援が手元で完結します。ローカルLLM導入の参考として、GLM-5.1の実装ガイドもあわせてご覧いただければと思います。
