---

license: apache-2.0

base_model: google/gemma-4-12B-it

base_model_relation: quantized

tags:

• gguf
• llama.cpp
• lm-studio
• coding
• agentic
• long-context
• 1M-context
• function-calling
• xcloudinfo

language:

• en
• zh

pipeline_tag: text-generation

library_name: gguf

---

<p align="center">

<img src="xgemable.jpg" alt="xGemable-12B-coder" width="520"/>

</p>

xGemable-12B-coder-v1.5 — GGUF

云碩科技（xCloudinfo）代理式程式設計模型——這是一顆為「寫程式」而生的模型，不是通用聊天模型。

這顆模型的程式邏輯從哪裡來

模型的程式邏輯能力以 Anthropic Claude（最頂尖的程式設計模型）為教師蒸餾而來，方法是云碩的執行驗證蒸餾（Execution-Verified Distillation）：

1. 由 Claude 在真實工程任務上實際解題——分析需求、推理邊界條件、寫出完整程式。
2. 每一條教師軌跡都先丟進真實編譯器與測試執行（pytest / dotnet / javac / go / rustc），測試全過才收錄，跑不過的一律丟棄。
3. 通過驗證的解題軌跡再蒸餾進 google/gemma-4-12B-it 底座。

所以它學到的不是「聊程式的口吻」，而是 Claude 面對工程問題時的推理路徑、邊界條件判斷、與可執行的正確實作。訓練資料裡沒有一行未經執行驗證的程式碼。

工程師可以拿它做什麼

• 函式/模組實作：給簽名或 docstring，產出可編譯、可通過測試的完整實作
• 多語言：Python 為主力，C# / Java / Go / JavaScript / Rust 皆可
• 代理式工作流：原生 function calling / tool use，能讀錯誤訊息、迭代修復（agentic coding，非單發問答）
• 長上下文程式理解：256K 原生 / 1M（YaRN）——整個中型 repo 塞進 context 做跨檔案推理
• 地端私有部署：GGUF 量化，單機 16GB RAM 起跑，資料不出內網

底座 google/gemma-4-12B-it。

為什麼寫程式選這顆，而不是更大的 gemma-4-26B / 31B

參數量大，不等於會寫程式。gemma-4-26B / 31B 是通用指令模型——訓練目標是知識問答、對話、摘要等泛用任務，程式碼只是其訓練分佈的一小部分，也沒有針對「可執行的正確性」做過任何驗證式訓練。拿它們寫程式，常見的就是：看起來很像對、實際編譯不過或測試不過的程式碼。

xGemable-12B-coder 相反：整個微調預算全部押在程式設計一件事上，且每條訓練資料都經過真實編譯器與測試把關（上節所述）。結果是：

| | xGemable-12B-coder | gemma-4-26B / 31B（通用版） |

|---|---|---|

| 定位 | 程式設計專用（agentic coding） | 通用對話 / 知識問答 |

| 程式訓練資料 | 100% 執行驗證通過 | 無執行驗證 |

| HumanEval pass@1 | 87.8%（自測，方法公開於下） | 未針對程式設計最佳化 |

| function calling / 工具迭代修復 | 原生，蒸餾自 Claude 代理軌跡 | 基本支援 |

| 部署門檻 | Q4 約 7.4GB，16GB RAM 即跑 | 26B Q4 約 16GB 起，一般開發機吃緊 |

| 產速（同硬體） | 12B，快 | 26B/31B 慢約一倍以上 |

一句話：要聊天查知識，用大顆通用版；要寫會過測試的程式，用這顆。 更小、更快、在程式設計這件事上更準。

量化版本

| 檔案 | 位元 | 大小 | 建議 |

|---|---|---|---|

| xGemable-12B-coder-v1.5-Q4_K_M.gguf | 4-bit | ~7.4 GB | 一般使用，16GB RAM 可跑 |

| xGemable-12B-coder-v1.5-Q5_K_M.gguf | 5-bit | ~8.5 GB | 品質與體積之平衡 |

| xGemable-12B-coder-v1.5-Q6_K.gguf | 6-bit | ~9.8 GB | 高品質 |

| xGemable-12B-coder-v1.5-Q8_0.gguf | 8-bit | ~12.7 GB | 接近無損 |

> 註：本模型底座為 gemma-4，無 MTP（Multi-Token Prediction）變體——MTP 為部分他家架構之特性，本底座不具備。

能力

| 項目 | 分數 |

|---|---|

| HumanEval pass@1 | 87.8%（乾淨取樣解碼，全量 164 題實際執行判分） |

約當 GPT-4-turbo（2024）水準，居 12B 開源程式設計模型第一梯隊。

本模型之數字均為云碩自測、可重現（評測方式與解碼參數如下所述），非引用之宣稱。

上下文長度：1M tokens，開箱即用

• 1,048,576（1M）tokens，預設啟用——YaRN rope-scaling 已直接寫入 GGUF metadata（rope.scaling.type=yarn, factor=4），llama.cpp / LM Studio 載入即生效，不需要任何額外參數。
• 底子是 256K 原生視窗（gemma4.rope.scaling.original_context_length = 262144，已驗證未截斷）——1M 只是 4 倍溫和外推。同級距多數模型的 1M 是從遠小的原生視窗高倍外推而來，長文品質衰減遠大於 4 倍外推。原生視窗大小，才是長上下文品質的硬實力。
• 整個中型 repo、數十篇文件一次塞進 context 做跨檔案推理都放得下。
• 注意：實際可用長度受你的 RAM 限制（KV cache 隨長度線性成長）；一般 16GB 機器建議 num_ctx 32K 以內，1M 需要大記憶體機器。

解碼參數（務必遵守）

gemma-4 對解碼參數極度敏感，設定錯誤會使表現大幅劣化。

• 溫度：程式設計 0.2、代理／工具呼叫 0.7
• 搭配：top_p 0.95、top_k 64
• 禁止：貪婪解碼、repetition_penalty、no_repeat_ngram

（這些會使模型無法重現題目給定的函式簽名與工具語法）

重要：務必使用附帶的解碼參數與模板（否則分數會腰斬）

gemma-4 這顆底座是「帶思考通道的對話模型」，部署工具鏈若不知道它的回合/通道標記，會出現三類劣化——這不是模型變笨，是部署設定不對。本 repo 的 GGUF 與附帶檔案已經全部修好，逐一說明：

| 根因 | 沒修的症狀 | 本 repo 的修法 |

|---|---|---|

| 推理端自動開啟思考模式（偵測到模板支援 thinking 就啟用） | 寫完程式又「Wait, let me re-check…」二次推敲、內部標記洩漏到回覆 | llama.cpp / vLLM：加 --chat-template-kwargs '{"enable_thinking":false}'；**

| 舊版 GGUF 缺回合結束標記（eot_token_id） | 回合結束不停、越界生成出殘缺程式碼 | 已烙入 eot_token_id=106（<turn|>），載入即生效 |

| Q4 量化損傷特殊 token 判斷 | Q4 版在短補全中隨機吐出模板標記、截斷程式碼 | Q4 已重新量化（embedding/output 層保 q8 精度），實測回到全精度行為 |

| 部分推理端預設帶 repeat_penalty / 過小的 num_predict | 不准照抄函式簽名 → 亂改；函式寫不完就截斷 | 解碼設 repeat_penalty 1.0、max_tokens 1024（見〈解碼參數〉） |

實測對照（同一組 C# 編譯測試，各跑 3 輪）：修復後 Q4/Q5/Q6/Q8 全部 3/3（= bf16 本尊水準）；修復前 Q4 僅 1/3。HumanEval：本 repo 的 Q4 GGUF 實測 88.4%（145/164，全量 164 題、無任何 stop 序列輔助），與 bf16 全精度（87.8%）持平——量化部署版即本尊水準；未關思考的部署則僅 62~77%。

使用方式

> 本模型底座 gemma-4 帶「思考通道」，任何推理端都務必關思考（下方指令已含旗標），否則思考會漏進輸出、分數腰斬。

llama.cpp（建議）

./llama-server -m xGemable-12B-coder-v1.5-Q4_K_M.gguf -c 8192 --jinja \
  --chat-template-kwargs '{"enable_thinking":false}' \
  --temp 0.2 --top-p 0.95 --top-k 64

--chat-template-kwargs '{"enable_thinking":false}' 必加——推理端偵測到模板支援思考會自動開啟，導致回覆夾雜推敲過程。1M 上下文已是預設（YaRN 烙入 metadata），把 -c 調大即可，無須額外 rope 參數。

啟動後即為 OpenAI 相容端點（預設 http://localhost:8080/v1），可直接接你的編輯器外掛、Continue、或任何 OpenAI SDK。

vLLM

vllm serve xCloudinfo/xGemable-12B-coder-v1.5 \
  --tool-call-parser gemma4 --enable-auto-tool-choice \
  --chat-template-kwargs '{"enable_thinking":false}'

（vLLM 需全精度權重，非本 GGUF repo；GGUF 請走 llama.cpp / LM Studio。）

能力範圍

• 擅長：函式與演算法實作、單元測試、程式碼解釋與審查、多輪工具使用探索。
• 限制：完整倉庫級自動除錯（在整個專案中定位並修復真實 bug）尚未達實用門檻，此為當前 12B 級模型之共通限制。

訓練

以 LoRA 監督式微調，採「保存底座程式設計能力、疊加代理行為」之最少擾動策略；

訓練軌跡均經 pytest 執行驗證（通過測試方才收錄）。

授權

Apache-2.0（底座 gemma-4-12B-it 之授權）。訓練所用之蒸餾軌跡為一次性輸入，不改變產出權重之授權狀態。

---

云碩科技股份有限公司　xCloudinfo Corp. Limited

台北・台中・新竹　│　自主 AI・地端部署・資料不離企業內網