--- license: apache-2.0 license_link: https://huggingface.co/tencent/Hy3/blob/main/LICENSE base_model: tencent/Hy3 base_model_relation: quantized library_name: mlx pipeline_tag: text-generation tags: - mlx - oq - oqe - imatrix - quantized - moe - hunyuan --- # Hy3 (MLX, oQ2e) Calibrated 2-bit MLX quantization of [tencent/Hy3](https://huggingface.co/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](https://huggingface.co/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](https://github.com/ml-explore/mlx-lm/pull/1211). Until it lands, install mlx-lm from the PR branch, otherwise the model won't load: ```bash 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](https://huggingface.co/mlx-community/Hy3-oQ2) · [oQ2e](https://huggingface.co/mlx-community/Hy3-oQ2e) · [oQ2e-2.37bpw](https://huggingface.co/mlx-community/Hy3-oQ2e-2.37bpw) · [oQ2e-2.33bpw](https://huggingface.co/mlx-community/Hy3-oQ2e-2.33bpw) · [oQ2e-2.31bpw](https://huggingface.co/mlx-community/Hy3-oQ2e-2.31bpw) ## Usage ```bash python -m mlx_lm generate --model mlx-community/Hy3-oQ2e --prompt "Explain Bayes' theorem in two sentences." --max-tokens 300 ``` ```python from mlx_lm import load, generate model, tokenizer = load("mlx-community/Hy3-oQ2e") ``` ## License [Apache-2.0](https://huggingface.co/tencent/Hy3/blob/main/LICENSE), inherited from the base model. Refer to the original model card for architecture, benchmarks, and intended use.