Flight Simulator — Coded by This Model

A real-world coding benchmark: each model was prompted to write a complete flight simulator from scratch. The resulting code was rendered and recorded.

About XL Quantization

BaseQuant_XL is a fully data-agnostic, static quantization. No calibration dataset, no sensitivity analysis, no importance matrix. Precision is allocated purely by architectural role — routing-critical layers get higher precision, bulk expert parameters get lower precision. The result is a transparent, faithful capture of the source model.

Data-dependent calibration quantizations (iMatrix, AWQ, GPTQ, oQ, oQ4e, etc.) use a calibration set to guide bit allocation. This can produce a skewed representation of the model: domains well-represented in the calibration data (English, popular topics, public or leaked benchmarks) are preserved better, while underrepresented domains (non-English languages, niche use cases, your own data) are preserved worse. XL avoids this trade-off entirely — it generalizes honestly because it is never fit to any particular data distribution.

Local SOTA for 48GB Macs — Intelligence Benchmark Comparison

This model is part of a benchmark comparison of the best local MLX-quantized LLMs that fit in 48GB unified memory on Apple Silicon. All benchmarks run in instruct mode (no thinking) with n=50 samples per benchmark.

Collection: Local SOTA for 48GB Macs

⚠️ n=50 sampling means wide confidence intervals (±~13% at 95% CI). Differences under ~6 points may not be statistically significant. Models using data-aware quantization (oQ/oQe) may be calibrated on benchmark-like data — their scores carry a benchmaxxing caveat. The BaseQuant_XL variants (data-agnostic) provide the most honest generalization estimates.

leonsarmiento/Qwen3.6-35B-A3B-oQ4e-mtp-XL-mlx

⚡ oMLX REQUIRED: These quants are designed to be used with oMLX and they will not work on LM studio. The bundled MTP (Lightning MTP) speculative-decoding heads only execute on oMLX — LM Studio loads the base model but ignores the MTP heads, so the acceleration is lost. For MTP speed, serve this model with oMLX.

A hybrid MLX quantization that surgically combines layers from two quantization variants of Qwen3.6-35B-A3B:

• Attention, embeddings, shared expert gate, lm_head from leonsarmiento/Qwen3.6-35B-A3B-5bit-XL-mlx — BaseQuant_XL 8-bit / bf16 (data-agnostic)
• Routed experts (switch_mlp), MTP layer, vision tower from Jundot/Qwen3.6-35B-A3B-oQ4e-mtp — oQ4e 4-bit (data-aware)

The result is a quantization-level layer swap — not a weight-space merge (DARE-TIES, Task Arithmetic). The model architecture is identical; only the quantization precision and method per layer differs.

Why This Combination?

The two donor quantizations use fundamentally different approaches:

The hypothesis: XL's high-precision 8-bit attention and bf16 shared expert/lm_head provide the best token routing and output projection, while oQ4e's data-aware 4-bit experts preserve the weight regions that matter most for the oQ calibration data. The MTP (Multi-Token Prediction) layer from oQ4e-mtp is preserved for speculative decoding support.

Important consideration: oQ/oQe quantization is data-aware — its quality depends on how well the oQ calibration dataset represents your use case. If your workload aligns with the calibration data, data-aware experts can outperform data-agnostic quantization at the same or lower bit depth. If it doesn't, the data-agnostic XL quantization may be more reliable. This hybrid gives you data-aware experts with data-agnostic attention — a middle ground.

Intelligence Benchmarks (Instruct mode, n=50)

Analysis: Data-Aware vs Data-Agnostic Quantization

This comparison spans three quantization philosophies:

• oQ / oQe (data-aware): Uses calibration data to guide bit allocation — oQ uses sensitivity analysis, oQe uses a process similar to iMatrix. Both are potentially benchmaxxed — if the calibration set overlaps with these benchmarks, the scores reflect calibration quality as much as model quality.
• XL (data-agnostic): No calibration data. Layers are quantized to fixed bit depths based on their architectural role (routing-critical → bf16, every-token → 8-bit, bulk experts → 6-bit). Results reflect genuine generalization.
• Frankenstein oQ4e-XL (this model): Hybrid — data-agnostic attention/routing from XL + data-aware 4-bit experts from oQ4e. Inherits calibration risk on the expert layers only.

Key observations:

1. This model scores highest on average (78.8%), edging out oQ4e-mtp (78.0%) by +0.8pp. The XL attention layers boost MMLU by +6 (72 vs 66) and MMLU_PRO by +4 over oQ4e-mtp — knowledge recall benefits from higher-precision routing. However, the data-aware experts from oQ4e likely contribute to the coding benchmark strength.

2. The benchmaxxing caveat is critical. oQ/oQe quantizations use calibration data that may include these exact benchmarks (or similar distributions). If so, their scores are partly a measure of calibration fit, not general intelligence. The XL quantization carries no such risk — its results are honest.

3. If we discount data-aware results as potentially benchmaxxed, the 6bit-XL is the honest king. Its average of 74.8% reflects pure architectural quality without calibration assistance. Notably, it matches or beats oQ6-mtp (71.2%) across all five benchmarks — the 6-bit data-aware variant is actually weaker than data-agnostic XL, suggesting oQ calibration at 6-bit may be counterproductive for this model.

4. HUMANEVAL tells the most interesting story. oQ4e-mtp leads at 92.0%, this model follows at 90.0%, but oQ6-mtp drops to 66.0% — a 26-point collapse. This suggests data-aware 4-bit calibration is highly effective for code generation, but data-aware 6-bit calibration may actively harm it. The data-agnostic 6bit-XL lands in between at 78.0% — a safe, honest result.

⚠️ n=50 sampling means wide confidence intervals (±~13% at 95% CI). Differences under ~6 points may not be statistically significant. The HUMANEVAL gap between oQ6-mtp (66%) and the 4-bit variants (90%+) is too large to dismiss as noise, but most other differences are within sampling error.

Custom MATHQA (thinking mode, n=30, corrected test set)

A failure-enriched MATHQA test set (n=30) run with thinking enabled and a relaxed 8192-token budget to isolate reasoning quality from throughput artifacts. The test set was manually audited and 9 of 19 "hard" questions corrected for dataset errors (dropped digits, wrong expected answers, impossible constraints) before this run — see methodology in leonsarmiento/gemma-4-26B-A4B-it-6bit-XL-mlx.

Raw vs verified accuracy: The "raw" column reflects the initial benchmark run. The "verified" column reflects a re-test of all 5 questions that failed on either model — both models solved all 5 correctly on re-run. The original failures were:

1. Degenerate reasoning loops (2 questions, non-XL only) — the model spiraled into 20–22K char self-verification loops producing zero extractable output. On re-test, both were solved cleanly in 36–42s with ~6–7K reasoning chars. These are transient failures caused by sampling variance (temperature=1.0), not capability gaps.
2. Answer extraction artifacts (3 questions) — correct answers masked by markdown bold formatting (**E**) or non-standard answer formatting that the extraction regex missed. On re-test with an improved regex, all 3 were recovered as correct.

Key findings:

• Both models can solve all 30 questions. The corrected test set is well within both models' reasoning capability. The raw 90% vs verified 100% gap is entirely attributable to (a) sampling-induced degenerate loops and (b) extraction bugs.
• XL is more stable and token-efficient. The XL eliminated both degenerate loop failures in the initial run (Q636, Q1556) and uses 15% less reasoning chars per correct answer (5,847 vs 6,881). The XL's bf16 routing produces more decisive reasoning chains — the same finding observed on Gemma 4 26B A4B XL.
• MTP degrades thinking-mode stability. Enabling MTP on this XL variant dropped raw accuracy from 90.0% → 83.3% and introduced 3 degenerate loops on previously reliable questions, while increasing wall time +20%. See the MTP evaluation section below.

⚠️ Thinking mode uses temperature=1.0, which introduces sampling variance. Individual questions can occasionally spiral into degenerate loops on any model. The n=30 raw scores carry ±10% noise; the re-test confirms both models are capable of perfect scores on this test set.

About MTP (Multi-Token Prediction)

⚠️ Note on MTP and TurboQuant when using oMLX: Tests on oMLX 0.5.5 show no MTP (Lightning MTP) advantage when TurboQuant KV Cache is turned On. For MTP decoding speed advantages, TurboQuant should be disabled.

This model preserves the MTP (Multi-Token Prediction) layer from the oQ4e-mtp donor for speculative decoding support in compatible runtimes (LM Studio, oMLX). MTP can significantly boost raw token generation throughput — on this model, from ~48 tok/s (MTP-OFF) to ~58 tok/s (MTP-ON), a +21% throughput increase.

However, our evaluation reveals an important caveat for thinking/reasoning mode:

The problem: In thinking mode, the model is an autonomous reasoner — it decides how long to think. MTP's faster token generation doesn't produce the same answer sooner; instead, the model thinks more with the extra speed. This creates three possible outcomes:

• ✅ Speed dividend (same or less reasoning, faster wall clock) — sometimes happens on genuinely hard questions where more thinking helps
• ❌ Speed waste (more reasoning, same or worse wall clock) — most common outcome, e.g., a trivial 2-second question ballooning to 109s with 16K reasoning chars
• ❌ Degenerate loop (model spirals until token limit, zero extractable output) — MTP introduced 3 of these on previously reliable questions

Recommendation:

• Thinking mode: Keep MTP OFF. The throughput boost is wasted on unnecessary reasoning loops, accuracy regresses, and wall time increases. The faster token generation is a liability, not an asset, when the model controls its own output length.
• Instruct mode (no thinking): MTP may be beneficial — output length is deterministic, so faster tokens directly translate to faster wall time. Not formally tested here.
• The right MTP evaluation metric is correct answers per minute (wall-clock efficiency) and correct answers per million tokens (context/energy efficiency), not tokens per second.

Quantization Strategy

About the Base Model

Qwen3.6-35B-A3B is a 35B-parameter multimodal MoE (Mixture of Experts) model with 256 experts (8 active per token + 1 shared expert), hybrid full + linear (Gated DeltaNet) attention, and a vision encoder. Despite 35B total parameters, only ~3B are activated per token for efficient inference.

Use with mlx

pip install -U mlx-vlm

python -m mlx_vlm.generate --model leonsarmiento/Qwen3.6-35B-A3B-oQ4e-mtp-XL-mlx --max-tokens 256 --temperature 0.6 --top-p 0.95 --prompt "Hello"

Recommended Inference Parameters - Add to Jinja template on LM studio or Chat Template Kwargs on oMLX

Thinking Preserve ({%- set preserve_thinking = true %}):

• General tasks: temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0
• Coding tasks: temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0

Instruct Mode ({%- set enable_thinking = false -%}):

• General tasks: temperature=0.7, top_p=0.8, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0
• Reasoning tasks: temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0

**Note:**If your runtime supports MTP, keep it disabled for thinking-mode workloads — see the MTP evaluation section above.

Acknowledgments

• Jundot for the oQ4e-mtp data-aware quantization with MTP layer and the oQ framework
• Qwen Team for the base Qwen3.6-35B-A3B model