Qwen 3.6 precision sweep: full-precision BF16 vs 8-bit vs 6-bit vs 4-bit

How far can the self-hosted Qwen 3.6 models be quantized before vulnerability detection — or the tokens spent reaching it — degrades? The same open-prompt probe across four precision tiers (full-precision BF16 / UD-Q8_K_XL / UD-Q6_K_XL / UD-Q4_K_XL): three non-leaking arms (open / plan-first / CWE-checklist) × two models, 2 trials/arm at temperature 0.5, over six single-file cases spanning an 18→0 baseline and five languages. Detection = a finding localized within 10 lines of the planted ground-truth hunk.

Detection matrix — BF16, Q8, Q6, Q4 side by side

Cell = localized hits / completed trials, one column per quant. green = both trials hit, amber = split, red = neither, — = no data. A Δ marks an arm where the quants disagree on whether the bug was found. Hard-miss cases (baseline ≤1) bold.

Qwen 3.6 27B (dense)

Qwen 3.6 35B-A3B (MoE)

Token usage — cost to answer per quant

Mean per completed run. Gen tokens = what the model actually generates (the real compute-to-answer); context tokens = input re-read across the ReAct loop (proxy for tool-call turns); wall-clock = latency (also moved by host load). Percentages are vs BF16; + means the smaller quant works harder. A smaller quant that needs materially more gen tokens for the same detection is a false economy where both quants are runnable.

Arm summary (union over 2 trials)

How many solved/medium cases and hard-miss cases each (model, quant, arm) detected in at least one trial. Denominators count only cases with a completed run.

Off-target findings: real secondary bugs vs false positives

These are real in-the-wild OSS files, not synthetic single-bug fixtures, so a finding that isn't the planted CVE is not automatically a false positive — it may be a genuine, never-fixed secondary bug. We judged every off-target finding with the code-grounded Opus FP-judge (it reads the pre-patch source, never the advisory) and classified each as a real bug, a false positive, or undetermined. Distinct sites are deduped globally across all four tiers (the verdict is a property of the code, not the precision), so this counts how many real secondary bugs actually live in each file.

green = judge-confirmed real bug, red = false positive, grey = undetermined. Hard-miss cases bold. The on-target CVE hits (95 findings) are not shown here — those are the planted bug, already known real.

Does a smaller quant hallucinate more? Off-target rows by tier

Per-tier off-target finding volume split by verdict (row-level, so repeated reports of the same bug count each time). If the smaller quants don't post a materially lower % real, precision is precision-invariant too — the smaller build is no noisier, consistent with the detection result.

Method & caveats

• Models: qwen3.6-27b (dense, 10.20.30.1) and qwen3.6-35b-A3b (MoE, 10.20.30.2), self-hosted llama-server, free. Identical endpoints — only the loaded precision differs (BF16 / UD-Q8/Q6/Q4_K_XL).
• Per tier: 6 cases × 3 arms × 2 trials × 2 models = 72 cells. Completed runs found: BF16 36, Q8 36, Q6 36, Q4 36.
• Temperature 0.5 so repeats explore; llama-server's default seed=-1 randomizes per request. Detection is localization-only (free); on the hard cases zero findings landed near the planted bug, so there is nothing for a truth-judge to confirm.
• Token counts are llama-server's reported usage. Context tokens are large because the ReAct loop re-sends the transcript each turn (cache-blind accounting); the cross-quant comparison is still apples-to-apples since the harness is identical.
• Separate DBs per quant (nelson-promptlab-bf16.db, nelson-promptlab.db, nelson-promptlab-6bit.db, nelson-promptlab-4bit.db); the baseline benchmark DB is untouched.

Generated from nelson-promptlab-bf16.db, nelson-promptlab.db, nelson-promptlab-6bit.db, nelson-promptlab-4bit.db · 4 quants × 2 models × 6 cases × 3 arms × 2 trials.