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:
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.
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.
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.
