qwen3-4b-es-reasoning-gguf
GGUF quantizations for
llama.cpp, Ollama and LM Studio. Quantized from a local merge of
axiom-of-choice/qwen3-4b-es-reasoning-peft onto
Qwen/Qwen3-4B.
Files
Q4_K_M is the default most tools pull -- smallest with negligible quality
loss for most use. Q8_0 is near-lossless if you have the RAM/VRAM for it.
Usage
1ollama run hf.co/axiom-of-choice/qwen3-4b-es-reasoning-gguf:Q4_K_M
2# or
3llama-cli -hf axiom-of-choice/qwen3-4b-es-reasoning-gguf:Q4_K_M -p "¿Cuánto es 17 por 24?"
What the numbers below do NOT cover
The merge-verification table is measured on the bf16 merge, before this
GGUF's own quantization step. Q4/Q8 quantization is a further lossy step on
top of that and is not separately measured here -- treat it as an additional,
unquantified source of drift on top of the number below, not as covered by it.
Did merging (pre-quantization) change the model?
This is checked against the unmerged PEFT adapter's own generations
(results/peft_parity/qwen3-4b-s6.0.json), not the original MLX numbers -- the question here is only
"did merging change the model", and MLX-vs-PyTorch divergence is a separate,
already-documented story on the adapter repo's card.
| accuracy | agreement |
|---|
| this repo (merged) | 95.0% | 95.0% |
| unmerged adapter | 90.0% | |
Paired counts: 1 correct only here, 0 correct only
unmerged, out of 20. The merge tracks the unmerged PEFT adapter closely, as it should -- this is the same engine and precision on both sides, so unlike the MLX-vs-PyTorch phase-2 numbers, there is no expected source of divergence here. Treat any drift beyond this as a merge bug, not backend noise.
Training
Same recipe, dataset and evaluation as the adapter --
see
axiom-of-choice/qwen3-4b-es-reasoning-peft.