Qwen3.6-35B-A3B-MAYA-oQ4e-mtp

The MAYA series

Monitoring, Analysis and Yield Agent.

The MAYA name marks models calibrated to run as a local AI assistant and is not just a benchmark-chasing quantization. The custom imatrix corpus was built to preserve the weight channels that matter : multi-step agentic reasoning, tool use, network monitoring, expressive professional prose, the ability to express a personality, and the kind of organizational intelligence that lets an AI feel like a real collaborator rather than merely a command executor. The weights provide the capability; the system prompt is what instantiates the specific character on top. If you're building a personal assistant with a defined persona and want the model to have the headroom to inhabit it, and still do real work, then this series was built with that in mind.

So this is simply Qwen3.6-35B-A3B quantized using a custom imatrix calibration corpus that would ensure activation of the specific weights which benefit this use case.

---

Qwen3.6-35B-A3B · oQe Q4 bf16 · Vision + MTP Verified

Qwen3.6-35B-A3B (35B MoE, ~3.6B active parameters) quantized with oMLX's oQe (imatrix-weighted) pipeline at Q4 bit depth, bf16 weights, with a custom calibration corpus. Vision tower and Multi-Token Prediction (Lightning MTP) tensors are verified present -- not inferred from the source or claimed from conversion flags.

This is the bf16 variant, recommended for M3/M4.

Companion models:

• For M1/M2 / fp16 at this bit depth: Robot-Haus/Qwen3.6-35B-A3B-MAYA-oQ4e-fp16-mtp — same quantization, fp16 dtype; ~44% faster prefill at long context on M1/M2.
• For better speed + smallest footprint (my production pick): Robot-Haus/Qwen3.6-35B-A3B-MAYA-oQ3.5e-fp16-mtp — Q3.5e fp16; faster decode throughput and the highest MMLU-Pro and HumanEval scores of any variant tested. Handles code and agent tasks well at a smaller footprint.

Why this exists

HuggingFace has been flooded with Qwen3.x uploads claiming to have MTP retained and the vision tower intact. In my experience, that was rarely the case as conversion pipelines silently strip those components, and there's no standard way to verify from the outside without opening the checkpoint yourself. I started quantizing from the official original weights myself to be certain.

This model was quantized directly from Qwen/Qwen3.6-35B-A3B : the official full-precision source. MTP and vision tensors were verified after quantization by inspecting the safetensors index directly.

Verification

Tensor counts in this checkpoint:

If you want to verify yourself:

import json
idx = json.load(open("model.safetensors.index.json"))
tensors = list(idx["weight_map"].keys())
print("MTP:", len([t for t in tensors if "mtp" in t]))
print("Vision:", len([t for t in tensors if "vision" in t or "visual" in t]))

Benchmarks

Full Intelligence Bench results (Thinking Mode off, greedy/temp=0 where applicable):

Q4 shows a clear advantage on LiveCodeBench (+9pp vs Q3.5 fp16, +10pp vs the prior DWQ production baseline) -- the harder the coding task, the more the extra bit depth matters.

What oQe is

oQe is oMLX's imatrix-calibrated quantization. Rather than quantizing all weights uniformly, it first collects activation statistics over a calibration corpus, then uses those to guide per-tensor quantization -- protecting the weights that matter most for accuracy from the worst precision loss.

Calibration Corpus

This build used a custom corpus that supplements oMLX's stock calibration data rather than replacing it. The goal was to bias imatrix weighting toward the specific channels a local homelab agent uses most: agentic tool orchestration, coding, shell/sysadmin, and professional writing. The stock corpus already provides strong Hermes-style chat/code/reasoning diversity; the additions target what's under-represented for this use case.

100% MoE expert coverage confirmed: all 256 experts across 123 layers received imatrix weighting (weakest expert: 37 samples vs. 16 required minimum).

fp16 vs bf16 -- which to use

M3 / M4: Apple improved bf16 throughput in these generations -- bf16 is the natural choice and this checkpoint is built for it.

M1 / M2: fp16 runs meaningfully faster on these chips. Use the fp16 companion oQ3.5e-fp16-mtp instead.

CUDA: bf16 is typically the native type on NVIDIA hardware, so this checkpoint may work there, but it was not tested on CUDA.

Quantization details

Usage

Designed for oMLX. Load as a standard MLX model. Enable "Lightning MTP" in oMLX settings to activate the MTP drafting heads for faster decode throughput.

What this is not

Straight quantization of the original weights. No fine-tuning, no abliteration, no merges.