Instructions to use mlx-community/Hy3-oQ2e with libraries, inference providers, notebooks, and local apps. Follow these links to get started.

Libraries

How to use mlx-community/Hy3-oQ2e with MLX:

# Make sure mlx-lm is installed
# pip install --upgrade mlx-lm

# Generate text with mlx-lm
from mlx_lm import load, generate

model, tokenizer = load("mlx-community/Hy3-oQ2e")

prompt = "Write a story about Einstein"
messages = [{"role": "user", "content": prompt}]
prompt = tokenizer.apply_chat_template(
    messages, add_generation_prompt=True
)

text = generate(model, tokenizer, prompt=prompt, verbose=True)

Notebooks
Google Colab
Kaggle
Local Apps Settings
LM Studio

How to use mlx-community/Hy3-oQ2e with Pi:

Start the MLX server

# Install MLX LM:
uv tool install mlx-lm
# Start a local OpenAI-compatible server:
mlx_lm.server --model "mlx-community/Hy3-oQ2e"

Configure the model in Pi

# Install Pi:
npm install -g @mariozechner/pi-coding-agent
# Add to ~/.pi/agent/models.json:
{
  "providers": {
    "mlx-lm": {
      "baseUrl": "http://localhost:8080/v1",
      "api": "openai-completions",
      "apiKey": "none",
      "models": [
        {
          "id": "mlx-community/Hy3-oQ2e"
        }
      ]
    }
  }
}

Run Pi

# Start Pi in your project directory:
pi

Hermes Agent new

How to use mlx-community/Hy3-oQ2e with Hermes Agent:

Start the MLX server

# Install MLX LM:
uv tool install mlx-lm
# Start a local OpenAI-compatible server:
mlx_lm.server --model "mlx-community/Hy3-oQ2e"

Configure Hermes

# Install Hermes:
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes setup
# Point Hermes at the local server:
hermes config set model.provider custom
hermes config set model.base_url http://127.0.0.1:8080/v1
hermes config set model.default mlx-community/Hy3-oQ2e

Run Hermes

hermes

OpenClaw new

How to use mlx-community/Hy3-oQ2e with OpenClaw:

Start the MLX server

# Install MLX LM:
uv tool install mlx-lm
# Start a local OpenAI-compatible server:
mlx_lm.server --model "mlx-community/Hy3-oQ2e"

Configure OpenClaw

# Install OpenClaw:
npm install -g openclaw@latest
# Register the local server and set it as the default model:
openclaw onboard --non-interactive --mode local \
  --auth-choice custom-api-key \
  --custom-base-url http://127.0.0.1:8080/v1 \
  --custom-model-id "mlx-community/Hy3-oQ2e" \
  --custom-provider-id mlx-lm \
  --custom-compatibility openai \
  --custom-text-input \
  --accept-risk \
  --skip-health

Run OpenClaw

openclaw agent --local --agent main --message "Hello from Hugging Face"

MLX LM

How to use mlx-community/Hy3-oQ2e with MLX LM:

Generate or start a chat session

# Install MLX LM
uv tool install mlx-lm
# Interactive chat REPL
mlx_lm.chat --model "mlx-community/Hy3-oQ2e"

Run an OpenAI-compatible server

# Install MLX LM
uv tool install mlx-lm
# Start the server
mlx_lm.server --model "mlx-community/Hy3-oQ2e"
# Calling the OpenAI-compatible server with curl
curl -X POST "http://localhost:8000/v1/chat/completions" \
   -H "Content-Type: application/json" \
   --data '{
     "model": "mlx-community/Hy3-oQ2e",
     "messages": [
       {"role": "user", "content": "Hello"}
     ]
   }'

Hy3-oQ2e / README.md

gabfssilva

Upload README.md with huggingface_hub

1979c30 verified 2 days ago

preview code

Raw

History Blame Contribute Delete

6.77 kB

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