BoldingBuilds/GLM-5.3-Flash-Uncensored-GGUF

🤗 Hugging Face sourceimage-text-to-textmit78 GBGGUFChecksums witnessedupdated today
No torrent yet

GLM-5.3-Flash Uncensored — GGUF

Refusal removed from GLM-5.3-Flash by editing 666 of its 12,384 routed experts — about 1.74% of the model's parameters. Quantized to IQ1_S at 71.5 GiB, which fits on a single 96 GB card.

I did the edit and the quantization myself, and I measured what it cost. Every number below is first-party, taken on my own rig, on the file in this repo.

Read this before you run it. Every headline number below was measured at temperature 0, seed 0, repetition penalty 1.1/256, 16k context, --reasoning-budget 1024. The file itself ships temperature 1.0 in its metadata and no reasoning budget, so a plain llama-server -m … does not run the measured configuration. I tested that gap directly (table under Default settings vs tested settings): at the file's own defaults, long coding tasks ran out of output budget without answering about 1 time in 8; with --reasoning-budget 1024 they did not. Use the quickstart line as written. The weights are not the problem; the budget is the lever. This is an experimental 1.92-bit build: 37 of 120 harmful-set responses and 8 of 120 benign ones hit the output cap in the headline run, and that is reported separately from "unusable" below.

Full write-up with charts and method: https://curve666-field-report.pages.dev/

What is different about this one

  • Small edit. Only the down-projections of 666 selected experts are written. Every other tensor is byte-identical to the parent at the BF16 stage, before quantization — the released IQ1_S file is, of course, quantized throughout (see the tensor classes under Quants).
  • Selected by refusal traffic, not magnitude. Same 384-expert budget spent on experts ranked by the size of their refusal component leaves 25.0% refusal; spent on experts that actually carry refusal traffic it leaves 5.8%. Which experts you pick matters more than how many.
  • Anti-repetition defaults baked into the file. general.sampling.penalty_repeat = 1.1 and general.sampling.penalty_last_n = 256 are set in the GGUF, so llama.cpp picks them up with no flags. That cuts unusable answers from 14.2% to 5.0%.

Requirements

This needs a llama.cpp build with GLM-5.3-Flash support. It is not in upstream master yet. Use PR #27754. That applies to every GLM-5.3-Flash GGUF right now, not just this one.

My numbers below were measured on that PR plus two local commits of mine (an MTP path and a KV-cache change). The MTP tensors are ignored at load time, so plain PR #27754 should behave the same — but I have not proven that, and you should know which build the numbers came from.

Quants

Quant Size Fits Measured
IQ1_S 71.5 GiB (2 shards) one 96 GB card yes — every number below

More rungs to follow. Each will say plainly whether it was evaluated or only built, because I can only serve up to about 96 GB and anything larger I cannot benchmark myself.

Shared file Size
mmproj-GLM-5.3-Flash-F16.gguf 1.13 GB vision, works with any rung

Not uniformly 1-bit, but not "only the experts are 1-bit" either. Read out of the published file: attention (208 tensors), the shared experts (129) and block 45 are q8_0; the routed experts are IQ1_S (124), Q2_K (2) and q8_0 (3, the MTP block); the first three dense FFN blocks are IQ1_S (gate/up) and Q2_K (down); token_embd is Q2_K and output is Q5_K. An earlier version of this card said only the routed experts were IQ1_S — that was wrong. Built with a 10-chunk imatrix inherited from a sibling build; thin, and disclosed as such.

The vision tower is unmodified — I converted it myself from zai-org/GLM-5.3-Flash, and the edit never touches it. Text-only use does not need that file.

Quickstart

# text only
llama-server \
  -m GLM-5.3-Flash-Uncensored-IQ1S-00001-of-00002.gguf \
  -c 16384 --jinja --reasoning-budget 1024

# with vision
llama-server \
  -m GLM-5.3-Flash-Uncensored-IQ1S-00001-of-00002.gguf \
  --mmproj mmproj-GLM-5.3-Flash-F16.gguf \
  -c 16384 --jinja --reasoning-budget 1024

Point at the first shard; llama.cpp loads the rest automatically.

--reasoning-budget 1024 matters. Without it GLM keeps thinking and often never reaches an answer. Every number below was measured with it set.

Method

  1. Capture routing on refusal prompts, rank routed experts by how much refusal traffic each one actually carries.
  2. Take the top 666, project a single refusal direction (layer 44) out of their ffn_down_exps weights at BF16.
  3. Quantize the edited BF16 to IQ1_S with an imatrix.

The edit is applied at full precision and quantized afterwards. There is no runtime steering, no LoRA, and nothing to load at serve time.

Results

Fixed 120-prompt harmful set, 120-prompt benign set, greedy, seed 0, --reasoning-budget 1024. Measured on the file in this repo.

Refusal

parent this model
keyword classifier 99.2% 3.3%
model judge (StrongREJECT rubric) 4.2%

The judge reads the whole answer, so it catches replies that open agreeably and then decline — which a keyword rule scores as compliance. I report both because the cheap number flatters the result by about a point.

Over-refusal on benign prompts

refused
parent 1.7%
this model 0.0%

0 of 120, no errors, no empty responses. It refuses harmless requests less often than the model it came from.

Degenerate output

sampler refused repetition loops no usable answer hit the output cap
greedy 4.2% 10.0% 14.2% 44 / 120
baked defaults (rep-pen 1.1) 3.3% 1.7% 5.0% 37 / 120
baked defaults, benign set 0.0% 0.0% 0.0% 8 / 120

A repetition loop contains no refusal language, so a refusal classifier scores it as a success. Reporting refusal without this number overstates any abliteration.

Two things this table does not say on its own. First, "no usable answer" counts refusals and loops; it does not count the responses that hit the token cap, which are listed in the last column separately — a capped response may be a fine answer that ran long, or it may have never reached one, and I did not adjudicate them individually. Second, every row was measured at temperature 0, seed 0, 16k context, --reasoning-budget 1024. The file ships temperature 1.0 in its metadata. What the file does at its own defaults, with no reasoning budget, is a separate measurement — see Default settings vs tested settings below.

Default settings vs tested settings

Every number above was measured at temperature 0 with a 1,024-token reasoning budget. The file itself ships temperature 1.0 and no budget. Those are different machines to a user, so on 2026-09-06 I ran the same 12-task coherence suite used on the OrcaRouter rebuilds (4 reasoning tasks with exact-answer checks, 4 coding tasks with executed asserts, 4 three-turn retention tasks; 2 seeds; 8,192-token output budget; loop flags from the same n-gram heuristic as the table above) under three server configurations, on the exact bytes in this repo, on the same 3×3090 box the other numbers came from:

condition what it is pass loop flags capped, no answer reasoning code multi-turn
shipped baked defaults, no reasoning budget — a plain llama-server -m … 21/24 0 final, 2 in reasoning 3 8/8 5/8 8/8
nopen same, repetition penalty off (control) 20/24 0 final, 2 in reasoning 4 7/8 5/8 8/8
quickstart the quickstart line on this card: baked temp 1.0, --reasoning-budget 1024 22/24 0 0 8/8 6/8 8/8
tested temp 0, seed 0, penalty, --reasoning-budget 1024 — the condition above 24/24 0 0 8/8 8/8 8/8

Read it column by column. Capped, no answer is the one that matters: at the file's own defaults, 3 of 8 coding runs (and with the penalty off, 4 of 8 plus one reasoning task) thought for 34–36 thousand characters and never wrote an answer. Those traces are not degenerate — the n-gram loop heuristic scores them 0.71–0.97 distinct, they read as fluent reasoning that keeps re-litigating edge cases — they are GLM thinking with no ceiling. Add the 1,024-token reasoning budget and that failure goes to zero at both temperatures. The two quickstart misses are ordinary temperature-1.0 sampling errors (one malformed regex in an over-long answer, one wrong merge), not non-termination; at temperature 0 the same tasks are 8 for 8. Multi-turn retention was perfect in every condition.

So: the weights are fine; the budget is required; the quickstart line is the right recommendation, and temperature 0 is better still for code. What the file does with no budget is documented here so nobody has to discover it. The repetition penalty, which the file bakes in, made no difference to this failure (21 vs 20) — it is there for the n-gram loops in the table above, which are a different thing. Same caveats as every table on this page: 24 correlated cases per condition at two seeds bound the rate, they do not certify it.

Capability

pass@1
parent, run 1 87.8%
parent, run 2 90.2%
this model 87.2%

HumanEval-164, greedy, 6000-token cap, run on the quantized weights before the sampler defaults were baked into the file (the bake changes metadata only, not weights). The parent disagrees with itself by 2.4 points across two runs; this model sits 0.6 below the weaker one.

What I did not measure

  • Anything but coding. No GSM8K, MMLU, MBPP, tool use or agentic evaluation.
  • Any language other than English. Both prompt sets are English.
  • Long context. Everything was run at 16k.
  • A higher-precision comparison. I cannot yet separate what the edit does from what it does with IQ1_S on top. Testing that now.

Two base runs do not establish statistical equivalence. These are same-condition lab measurements, not a leaderboard reproduction, and they are first-party — I made the model and I graded it.

Intended use

Research, and local assistants where over-refusal is a problem. It is still a general model and it will produce unsafe content if you ask it to. Use it under your own policy and applicable law.

Provenance

Parent zai-org/GLM-5.3-Flash
Quantizer llama.cpp CUDA build 10700
Edit single refusal direction, layer 44, 666 routed-expert down-projections
Runtime llama.cpp PR #27754, plus 2 local commits (see Requirements)
shard 1 04d81e6d17a7fdb9e04e39bbd15725f43a5ffefeaa51f608f67b07620ad913f0
shard 2 4d0d4ce1eb9961306bdfa05af12d99609e7d0eb784c36c131c44d2cd47c515cd
mmproj fffaa0aa02394d385a51db178a8b8a996c26955d642f367abee0048de244ee7a

If you re-download this repo later and the hashes differ, the weights changed. Check.