KBBridge-v3-GGUF

KBBridge-v3

A fine-tune of Qwen/Qwen3.8-27B specialised in GeneXus programming, in the native .gxSource export format.

Frontier models do not know this format. Without the GeneXus documentation injected into the prompt they produce syntactically invalid output almost every time (parse rate 0.5–3.1%). KBBridge writes it natively, runs on your own hardware, and never sends your Knowledge Base code to an external API.

---

⚠️ Read this before your first prompt

Three settings. All three are measured on this model, not stylistic.

1. Reasoning: it depends on the task, and the difference is large

These GGUFs no longer pin a value, so reasoning follows the upstream Qwen default (on) unless you turn it off. Which one you want depends on what you are asking for. All three rows are measured on this model, not inherited from Qwen.

If you generate GeneXus objects, turn reasoning off. The collapse is real, not a budget artifact: with reasoning on, only 5.2% of items hit the token ceiling (fewer than the 8.4% without it) and 3.7% came back empty. The model simply writes worse .gxSource when it reasons first.

If you point the model at existing code and ask what it does, turn reasoning on. It nearly halves the rate at which the model asserts things the source does not support. Cost: ~5× the output tokens.

Correction (2026-09-02). An earlier version of this card reported MCQ dropping 78.1 → 69.6 with reasoning on, and shipped GGUFs with enable_thinking pinned to false. That MCQ number was wrong: our benchmark capped multiple-choice answers at 512 tokens, not enough for a reasoning block to close, so the run measured the cap rather than the model. Re-measured with an adequate budget the difference is zero. The .gxSource degradation is real and is reproduced above. The pin was removed so that the choice is yours.

Turning it off — and a trap per runtime

llama.cpp. --chat-template-kwargs '{"enable_thinking":false}' is deprecated, and --reasoning defaults to auto, which reads support from the template and turns reasoning on. Set it explicitly:

llama-server -m KBBridge-v3-Q4_K_M.gguf --jinja --reasoning none

LM Studio. It ignores chat_template_kwargs sent through the API. Use the "thinking"/"reasoning" toggle in the model settings instead — the API parameter will not reach the template. We once watched a benchmark score 24.1 instead of 90.0 for exactly this reason.

Any runtime, guaranteed. Edit the template and add this as its first line:

{%- set enable_thinking = false %}

A set at the top overrides anything the caller passes. It is blunt, but it is the only approach that behaves identically across llama.cpp, LM Studio and Ollama — which is why these files shipped that way until 2026-09-02.

2. Ask for the format explicitly

Write "in .gxSource format" in your prompt.

Measured on v3: the bare request "a Procedure that adds two numbers" returns generic SQL. Naming the format returns the GeneXus object, consistently. If you use a harness with its own system prompt, put the instruction there once.

3. Give it enough room

max_tokens ≥ 4096. A .gxSource object consumes roughly 340 tokens per KB of source, and most tools default to 512–1024, which truncates the object mid-body.

---

Results

580 held-out items (191 codegen + 329 MCQ + 60 data-model) that no model saw during training. Syntax validated with the official GeneXus ANTLR parser. Same protocol for every model: temperature 0.1, reasoning off, concurrency 8.

v3 vs v2 — an honest comparison

v3 is not a clean win over v2. It gains domain knowledge and loses syntax accuracy:

What these numbers do NOT establish. v3 changed three things at once — the base model (Qwen3.6 → 3.8), the corpus (4× larger, per-KB cap removed) and the teacher (v1 → v2). The parseRate drop cannot be attributed to any one of them without a control arm that was never run. Anyone reading this table as "the bigger corpus hurt syntax" is over-reading it.

Choose v3 if domain knowledge matters more to you; v2 still leads on raw syntax validity.

Generalisation to unseen Knowledge Bases

Three entire KBs were held out — different domains, never in the pipeline:

v3's relative gap to unseen KBs is larger than v2's (+2.6 vs +0.9), i.e. it generalises better in relative terms, even though two KBs make up 54.7% of its corpus.

Fairness note on the frontier comparison

In our benchmark the frontier models were run with ~21,600 tokens of GeneXus documentation injected into every request; KBBridge was run without any. That is not a handicap we imposed — injecting the same documentation into KBBridge makes it worse (76.4 → 73.3 parseRate), because the fine-tune already internalised that knowledge and the extra context gets in the way. Still, the setups differ, and you should know that when reading any head-to-head number.

Quantisation — what the Q4 build actually costs you

Same 580-item benchmark, run against KBBridge-v3-Q4_K_M.gguf in llama.cpp with all layers on GPU:

The Q4 scoring higher than the full-precision model is not a quantisation benefit, and we are not going to pretend otherwise. Here is what is actually going on.

On items both runs completed normally, the two are identical. Excluding every item where either run hit the 20,000-token ceiling (20 items), the remaining 171 give:

A 0.6-point gap on parseRate is one item out of 171. 4-bit quantisation costs essentially nothing in output quality. The MCQ drop (−0.9) is the only measurable degradation.

The whole headline difference is the runaway rate. Degenerate repetition until the token budget is exhausted hit 19 of 191 items (9.9%) under vLLM and 7 of 191 (3.7%) in llama.cpp. Of the 19 the bf16 run ruined, the Q4 run closed 13 cleanly; one item went the other way.

And we cannot attribute that to the quantisation. The two runs differ in the inference engine and in the default sampler stack — llama.cpp applies top_k=20, top_p=0.95, min_p=0.05; vLLM applies none of them, and the benchmark only sets temperature. Truncating the low-probability tail is a plausible mechanism for suppressing repetition loops, and it is confounded with the quantisation in this measurement. Isolating it would need a controlled run we have not done.

What this means for you, practically: the numbers in the Q4 column are what you should expect from this file in llama.cpp or LM Studio with stock settings — that is the configuration we measured. If you disable min_p/top_k to match a vLLM-style setup, expect more runaway on large objects.

---

Files

# llama.cpp, downloads on demand
llama-server -hf KBBridge/KBBridge-v3-GGUF:Q4_K_M --jinja

# or fetch the file directly
hf download KBBridge/KBBridge-v3-GGUF KBBridge-v3-Q4_K_M.gguf --local-dir .

In LM Studio, search for KBBridge/KBBridge-v3-GGUF.

Verify your download against SHA256SUMS.

Vision

The base model is multimodal and KBBridge inherits its vision tower unchanged (verified: identical tensors). These GGUFs are text-only; if you want image input, pair them with the official projector from Qwen/Qwen3.8-27B via --mmproj. For writing GeneXus you do not need it.

Speculative decoding — free speed

The multi-token-prediction head is included in these files. Enable it:

llama-server -m KBBridge-v3-Q4_K_M.gguf --spec-type draft-mtp --jinja

Measured on one RTX PRO 6000 (Q4_K_M, all layers on GPU, 301-token generations, first run discarded):

+71%, and the output is unchanged — in speculative decoding the main model verifies every drafted token, so a draft head can only affect speed, never correctness.

Across the 583 requests of the full benchmark run — real GeneXus generation, not a microbenchmark — the draft head's tokens were accepted at a median rate of 0.86, averaging 3.28 accepted tokens per speculative step. It predicts the fine-tuned model's output well despite coming from the base model untouched by the fine-tune.

---

Intended use

Assisting GeneXus developers: generating objects (Procedures, Transactions, Data Providers, SDTs, WebPanels), explaining existing code, completion, and documentation questions.

Out of scope: not a general-purpose model, not a replacement for validating in the GeneXus IDE, and it does not know any particular Knowledge Base (see Limitations).

---

Limitations

• It does not know your KB. It learned the style and syntax of the format, not the contents of any specific base. Ask it about a transaction you did not paste in, and it will invent plausible attribute names and present them as fact. Always give it the context and validate the output in the IDE.
• Runaway generation on very large objects. For objects over ~10 KB the model can fall into degenerate repetition — the same line hundreds of times without closing the object. Measured on v2 at ~1.6% of benchmark items; not re-measured on v3. Raising max_tokens does not fix it. Generate large objects section by section.
• Spanish bias in explanations, reflecting the corpus.
• Specialised: worse than the base model at general tasks.
• The limitations above other than the first were measured on v2 and are carried over as working assumptions, not verified properties of v3.

If you also use a hosted KBBridge endpoint

The raw GGUF and a gateway-fronted deployment do not behave the same by default. Our gateway applies five corrections the plain model does not have: a max_tokens floor, reasoning off unless the client asks for it, temperature defaulted to 0.2 (without it vLLM falls back to the checkpoint's generation_config, which is 1.0), a fallback that recovers the answer from the reasoning field when content comes back empty, and repetition_penalty 1.05 to suppress runaway. If you compare "what I tried on your server" against "what I downloaded", the difference is those five settings, not the weights.

The temperature one surprises people: the OpenAI standard makes the field optional and many clients never send it, so an unconfigured client is sampling at 1.0 without being told.

---

Training

train_loss 0.2618 (v2: 0.3344) · eval_loss 0.3723 (v2: 0.4675), minimum at the last step — no overfitting across 71 evaluations, which suggests there was room for more epochs.

Note that these losses are much better than v2's and yet parseRate went down: eval_loss measures fit to the corpus, not GeneXus quality.

Data

80,344 examples derived from GeneXus objects across 25 real Knowledge Bases (GX16/17/17U8/18/ Evo1, multi-domain) — 129% more than v2, with the per-KB cap removed. Sanitised, deduplicated and split by deterministic hash. The datasets are not published: they contain customer proprietary code.

---

Training-data privacy

The model was trained on real customer Knowledge Bases, so we audited whether it can leak them. This is the strongest result of the project.

Canaries: no memorisation threshold found

12 synthetic objects containing unguessable 16-character secrets were inserted at four frequencies, and verified to have reached train.jsonl at exactly those counts:

Not even at a thousand identical repetitions. A control rules out a broken probe: asked for the canary, the model returns a structurally valid but empty object — no token, no secret. And it does generate real bodies when the request has content, so the empty skeleton is not an inability to generate.

Membership inference: marginal signal

0.554 against 0.50 for indistinguishable. There is a statistical trace of having seen the data, but the distributions overlap almost entirely.

Conclusion: customer code is not recoverable from the weights.

Caveat, stated plainly: absence of evidence is not proof of absence. These audits cover the attacks we ran, not every attack that exists.

---

Reproducibility

Full external reproduction is not possible, and it is worth saying so directly:

1. The 25 Knowledge Bases are customer code and are not distributed.
2. The parseRate scorer uses the KBEditor's ANTLR parser — proprietary, not distributable.
3. The teacher that generated v3's data is KBBridge-v2, which is not published.

What a third party can verify: the raw benchmark outputs (one model response per item) and the scoring over them.

---

Citation

@misc{kbbridge-v3,
  title  = {KBBridge-v3: a GeneXus code assistant fine-tuned from Qwen3.8-27B},
  author = {{KBBridge}},
  year   = {2026},
  url    = {https://huggingface.co/KBBridge/KBBridge-v3-GGUF}
}

License

Apache 2.0, inherited from the base model Qwen/Qwen3.8-27B. This is a modified derivative work; see NOTICE.