由 Claude 在真實工程任務上實際解題——分析需求、推理邊界條件、寫出完整程式。
每一條教師軌跡都先丟進真實編譯器與測試執行（pytest / dotnet / javac / go / rustc），測試全過才收錄，跑不過的一律丟棄。
通過驗證的解題軌跡再蒸餾進 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（建議）

bash

./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

bash

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・地端部署・資料不離企業內網

xCloudinfo/xGemable-12B-coder-v1.5-GGUF

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

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