Calibrated 2-bit MLX quantization of poolside/Laguna-S-2.1 (118B total, 8B activated per token), produced with oMLX oQ at level 2 enhanced — 2.70 bits/weight effective, 36 GB on disk. Data-driven mixed precision: bits are allocated per tensor from an imatrix-calibrated sensitivity map, not a fixed rule. For Apple Silicon.

mlx-lm doesn't support the laguna architecture yet — there's an open PR: mlx-lm#1223. Until it lands, use mlx-vlm (0.6.3+), which implements laguna as a text-only model:

oMLX serves it directly from 0.5.3 on — it vendors that PR and patches it into mlx-lm at import, so no model setting is needed. On earlier builds, discovery decides between the mlx-lm and mlx-vlm loaders by looking for a vision sub-config, and laguna has none — so it lands on mlx-lm and fails with Model type laguna not supported. Set model_type_override: "vlm" in the model's settings, then refresh discovery (omlx restart): the load failure is cached per entry until the next discovery pass, so setting the override alone won't clear it.

oQ2e allocates bits per tensor from an importance-matrix calibration pass over calibration data. Here the split came out extreme: every non-expert tensor — attention, embeddings, lm_head, routers, 386 in total — was boosted to 8 bits, leaving the 2-bit base to the experts alone. With only 8B parameters active per token there's little margin in the dense spine, and the calibration spent its entire budget protecting it. Output is standard MLX affine quantization — no custom kernels or runtime required.

The measured sensitivity ranks L46, L24, L20 and L44 highest, and L0 lowest of the 48 by a wide margin (0.0021), which tracks with L0 being the model's only mlp_only layer.

oQ at level 2 enhanced — imatrix-calibrated, group size 128. I had to patch omlx to route laguna through the mlx-vlm loader. At 235 GB the model doesn't fit in 128 GB of RAM, so calibration ran against a uniform 4-bit proxy on disk rather than the FP weights, which shifts the bit allocation slightly.

Unlike the upstream config, generation_config.json here ships repetition_penalty: 1.05: at this bit-width the model can fall into verbatim repetition loops in long-form generation, and this is the mildest setting that reliably broke them in my tests.

Smoke-tested after conversion with mlx_vlm.generate: coherent — solved 17 * 24 = 408, broke it down by the distributive property and verified the result a second way, no repetition loop.

Measured with oMLX's benchmark harness on a Macbook Pro M5 Max 128GB 40 GPU, single request, 128 generated tokens:

Continuous batching at 1k prompt / 128 generated:

mmlu_pro, mathqa and winogrande, n=300 seeded samples each, thinking off, identical questions across every variant. The bf16 row is the hosted API, measured the same way. Standard error at this n is around 2.5 points, so oQ4e through oQ6e aren't separated by this run.

Treat this as a rough sighting, not a verdict. Three benchmarks at n=300 cover a narrow slice of what the model does — no long-context work, no agentic loops, no real code — and at this sample size most of the ladder above 3.6 bpw sits inside the error bars. I ran them to size the drop between levels, not to rank the variants against each other. Test the one you're considering on your own workload before trusting any of it.

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