mlx-community/Hy3-oQ2e

Hy3 (MLX, oQ2e)

Calibrated 2-bit MLX quantization of tencent/Hy3 (Hunyuan 3.0, 295B-A21B MoE), produced with omlx oQe at level 2 — 2.44 bits/weight effective, 90 GB on disk. For Apple Silicon.

Same family as mlx-community/Hy3-oQ2, but 9 GB smaller (90 GB vs 99 GB). Two changes get there:

• group_size=128 on the routed experts instead of 64. Affine quantization stores an fp16 scale and bias per group, so the metadata costs 32 / group_size bits per weight. Doubling the group halves that overhead: 0.50 → 0.25 bpw. The experts are 97.6% of the model (288B of 295B params), so this alone is the entire saving.
• imatrix-weighted quantization (oQe) to pay for it. A larger group means four quantization levels now have to cover 128 weights instead of 64 — one outlier stretches the scale for twice as many neighbours. oQe weights the error by a measured importance matrix, so within each group the bits land on the weights that actually matter.

Attention, embeddings and lm_head stay at 8-bit, group_size 64 — untouched from oQ2. The size reduction comes entirely from the expert FFN.

Regular oQ2 goes cuckoo at group_size=128

Without the imatrix, group_size=128 at the same 90 GB is worse. Asked for an iterative Fibonacci function — same prompt, same greedy decoding — plain gs=128 wrote a dead statement into the n == 1 branch and an off-by-one loop that returns F(n-1); this model and oQ2 both get it right.

The imatrix is what makes the larger group survivable.

Requirements

mlx-lm doesn't support the hy_v3 architecture yet — there's an open PR: mlx-lm#1211. Until it lands, install mlx-lm from the PR branch, otherwise the model won't load:

uv pip install "mlx-lm @ git+https://github.com/kernelpool/mlx-lm.git@add-hy3-preview"

If you’re using oMLX, Hy3 is supported already.

How it was quantized

Hy3 is ~590 GB in BF16 — larger than RAM on a 128 GB machine — so neither of oQe's two calibration passes can load the source model. Both have to be routed around, and they fail differently.

1. Sensitivity — pass an existing quant as sensitivity_model_path (I used oQ2). omlx's automatic fallback builds a uniform 4-bit proxy of a 295B model, which does not survive on this hardware.

2. imatrix — the collection pass has the same problem, but sensitivity_model_path does not cover it: it is a separate code path with its own proxy builder. The way out is a cache hit, since a cached imatrix skips collection entirely. The cache key is the source checkpoint, the calibration set and the sample/sequence counts — not the bits or the group size, because per-column importance is orthogonal to how the weights are later grouped. So an imatrix collected once for oQ2e at group_size=64 is valid, unchanged, for group_size=128.

   One catch: Hy3 declares num_nextn_predict_layers: 1, and omlx force-recollects when a model declares MTP heads but the cache has no mtp.* entries — even on a signature match. With preserve_mtp=False the MTP tensors are stripped from the output anyway, so calibrating that head is work thrown away; skipping the recollect is the correct behaviour here, not a workaround.

With both passes served from cache, the quantization itself streams tensor-by-tensor and never holds the full model.

Memory and speed

Measured with the oMLX benchmark (Engine: Auto) on a MacBook Pro M5 Max, 128 GB, 40-core GPU. Generating 128 tokens, single request:

context	TTFT	prompt	generation	peak memory
1024	1.7 s	619 tok/s	29.4 tok/s	84.7 GB
4096	7.8 s	523 tok/s	25.2 tok/s	86.2 GB
8192	16.2 s	504 tok/s	23.0 tok/s	87.9 GB
16384	31.6 s	519 tok/s	19.8 tok/s	89.6 GB

Continuous batching at 1024-token prompts scales to 68 tok/s aggregate at 8 concurrent requests:

batch	generation	speedup
1×	29.4 tok/s	1.00×
2×	42.2 tok/s	1.44×
4×	54.6 tok/s	1.83×
8×	67.6 tok/s	2.28×

The headroom is what the 9 GB bought. oQ2 peaks at 99 GB against the default Metal working-set cap of 107.5 GB on a 128 GB machine, so the KV cache runs out of room at long context; this one is still at 89.6 GB with a 16k prompt.

TurboQuant KV did not pay off here — it slowed down batched prompt processing, so these numbers are all without it. I don't have an explanation yet. With this much headroom you likely don't need it anyway.

Conversion check

Smoke-tested with mlx_lm.generate, greedy: an iterative Fibonacci function (correct, no corrupted tokens) and a backend-agnostic Keras 3 autoencoder (real bottleneck, keras.ops throughout, parses clean). oQ2 passes both as well; plain 2-bit group_size=128 without the imatrix fails the first.

This is a smoke test, not a benchmark — it does not establish parity with oQ2. If you run an executable code benchmark on both, please post the numbers in a discussion.

Benchmarks (all Hy3 MLX variants)

oMLX intelligence suite, 300 seeded samples per benchmark, identical questions across models. I ran seeded samples — this is not a complete benchmark run, so read the differences as noise and test the versions against your own workload before picking one.

Benchmark (300)	oQ2 · 2.68	oQ2e · 2.43 (this model)	oQ2e-2.37bpw	oQ2e-2.33bpw	oQ2e-2.31bpw
mathqa	0.63	0.65	0.64	0.62	0.60
mmlu_pro	0.65	0.61	0.60	0.59	0.55
winogrande	0.74	0.68	0.68	0.65	0.65

Variants: oQ2 · oQ2e · oQ2e-2.37bpw · oQ2e-2.33bpw · oQ2e-2.31bpw

Usage

python -m mlx_lm generate --model mlx-community/Hy3-oQ2e --prompt "Explain Bayes' theorem in two sentences." --max-tokens 300

from mlx_lm import load, generate
model, tokenizer = load("mlx-community/Hy3-oQ2e")

License

Apache-2.0, inherited from the base model. Refer to the original model card for architecture, benchmarks, and intended use.