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

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

量化版本

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

能力

約當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與附帶檔案已經全部修好，逐一說明：

實測對照（同一組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）專注於地端私有化人工智慧解決方案。xVITA是云碩自研模型的品牌名稱。

據點：台北、台中、新竹。

其他模型請見 https://hf.co/xCloudinfo。

---

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

An agentic coding model from xCloudinfo (云碩科技). This model was built for writing code; it is not a general-purpose chat model.

Where this model's coding logic comes from

The model's coding logic was distilled with Anthropic Claude (a state-of-the-art coding model) as the teacher, using xCloudinfo's Execution-Verified Distillation:

1. Claude actually solves real engineering tasks: analyzing requirements, reasoning about edge cases, and writing complete code.
2. Every teacher trajectory is first run through a real compiler and test execution (pytest / dotnet / javac / go / rustc). It is kept only if all tests pass; anything that fails is discarded.
3. The verified solution trajectories are then distilled into the google/gemma-4-12B-it base.

So what it learns is not "the tone of talking about code" but Claude's reasoning path, edge-case judgment, and correct, executable implementations when facing engineering problems. There is not a single line of code in the training data that has not been execution-verified.

What engineers can use it for

• Function/module implementation: given a signature or docstring, it produces a complete implementation that compiles and passes tests
• Multiple languages: Python is the main focus; C# / Java / Go / JavaScript / Rust are all supported
• Agentic workflows: native function calling / tool use; it can read error messages and iterate on fixes (agentic coding, not single-shot Q&A)
• Long-context code understanding: 256K native / 1M (YaRN), so an entire mid-sized repo fits into the context for cross-file reasoning
• On-premises private deployment: GGUF quantization, runs on a single machine starting from 16GB RAM, data stays inside the internal network

Base model: google/gemma-4-12B-it.

Why pick this one for coding instead of the larger gemma-4-26B / 31B

More parameters do not mean better coding. gemma-4-26B / 31B are general-purpose instruction models: their training targets general tasks such as knowledge Q&A, conversation, and summarization. Code is only a small part of their training distribution, and they have not gone through any verification-based training for "executable correctness". When they are used for coding, the common result is code that looks right but in practice fails to compile or fails the tests.

xGemable-12B-coder is the opposite: the entire fine-tuning budget is spent on one thing, programming, and every training example is gated by a real compiler and tests (as described in the previous section). The result:

In one sentence: for chatting and looking up knowledge, use the large general-purpose models; for writing code that passes tests, use this one. It is smaller, faster, and more accurate at programming.

Quantized versions

Note: this model's base is gemma-4, which has no MTP (Multi-Token Prediction) variant. MTP is a feature of some other vendors' architectures; this base does not have it.

Capabilities

Roughly at the level of GPT-4-turbo (2024), in the first tier of 12B open-source coding models.

All numbers for this model are self-measured by xCloudinfo and reproducible (the evaluation method and decoding parameters are described below); they are not cited claims.

Context length: 1M tokens, out of the box

• 1,048,576 (1M) tokens, enabled by default: YaRN rope-scaling is written directly into the GGUF metadata (rope.scaling.type=yarn, factor=4), so it takes effect as soon as llama.cpp / LM Studio loads the file, with no extra parameters needed.
• The foundation is a 256K native window (gemma4.rope.scaling.original_context_length = 262144, verified not truncated); 1M is only a mild 4x extrapolation. For most models in the same size class, 1M is extrapolated by a large factor from a much smaller native window, and long-text quality degrades far more than with a 4x extrapolation. The size of the native window is what really determines long-context quality.
• An entire mid-sized repo or dozens of documents can be put into the context at once for cross-file reasoning.
• Note: the length you can actually use is limited by your RAM (the KV cache grows linearly with length). On a typical 16GB machine, keeping num_ctx within 32K is recommended; 1M requires a machine with a large amount of memory.

Decoding parameters (must follow)

gemma-4 is extremely sensitive to decoding parameters; wrong settings degrade performance substantially.

• Temperature: coding 0.2, agents / tool calls 0.7
• Together with: top_p 0.95, top_k 64
• Do not use: greedy decoding, repetition_penalty, no_repeat_ngram (these prevent the model from reproducing the function signatures and tool syntax given in the task)

Important: use the bundled decoding parameters and template (otherwise scores are cut in half)

The gemma-4 base is a "conversational model with a thinking channel". If the deployment toolchain does not know its turn/channel markers, three kinds of degradation appear. This is not the model getting dumber; it is a wrong deployment setting. The GGUF and bundled files in this repo have all been fixed; each item is explained below:

Measured comparison (the same C# compile-test set, 3 rounds each): after the fix, Q4/Q5/Q6/Q8 all score 3/3 (= the level of the bf16 original); before the fix, Q4 scored only 1/3. HumanEval: this repo's Q4 GGUF measured 88.4% (145/164, all 164 problems, without any stop-sequence assistance), on par with bf16 full precision (87.8%), so the quantized deployment build is at the level of the original. Deployments that do not turn thinking off score only 62~77%.

Usage

This model's base, gemma-4, has a "thinking channel". Turn thinking off on every inference engine (the commands below already include the flag); otherwise thinking leaks into the output and scores are cut in half.

llama.cpp (recommended)

./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}' is required: the inference engine turns thinking on automatically when it detects that the template supports it, which mixes the deliberation process into replies. 1M context is already the default (YaRN is baked into the metadata); just raise -c, with no extra rope parameters needed.

Once started, it is an OpenAI-compatible endpoint (default http://localhost:8080/v1) that you can connect directly to your editor plugin, Continue, or any 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 requires the full-precision weights, not this GGUF repo; for GGUF, use llama.cpp / LM Studio.)

Scope of capabilities

• Strong at: function and algorithm implementation, unit tests, code explanation and review, multi-turn tool-use exploration.
• Limitations: full repository-level automated debugging (locating and fixing real bugs across an entire project) has not yet reached a practical threshold; this is a limitation shared by current 12B-class models.

Training

LoRA supervised fine-tuning, using a minimal-perturbation strategy of "preserving the base model's coding ability and layering agentic behavior on top"; all training trajectories were execution-verified with pytest (kept only if the tests passed).

License

Apache-2.0 (the license of the base gemma-4-12B-it). The distillation trajectories used for training are a one-time input and do not change the license status of the resulting weights.

About xCloudinfo

xCloudinfo Corp. Limited (云碩科技) builds on-premises, private AI solutions. xVITA is xCloudinfo's in-house model brand.

Offices: Taipei, Taichung, Hsinchu.

More models: https://hf.co/xCloudinfo