#3716·omlx

Bonsai/t5 load patch is installed for every 2-bit checkpoint, and no test covers that path

Author: LXD-8Created Sep 17, 2026Updated Sep 17, 2026

What

omlx/utils/model_loading.py installs the Bonsai/t5 load patch whenever a checkpoint declares quantization.bits of 1 or 2, without consulting the model type:

python
quant_cfg = config.get("quantization") or {}
...
if quant_bits in (1, 2):
    apply_bonsai_t5_load_patch()

apply_bonsai_t5_load_patch() rewrites nn.Module.load_weights and mx.quantized_matmul process-wide for the lifetime of the process.

Why it matters

Any 2-bit checkpoint — not just the Bonsai/t5 family the patch targets — picks it up. A community 2-bit mlx_lm conversion of a DeepSeek V4.1 checkpoint is such a case, and I hit it while loading one: the patch was installed, and the model loaded and generated correctly, so it does not appear to be harmful there. But it is a global monkeypatch installed on a family it was not written for.

The unit tests do not cover it either: they call the V4.1 loader directly and never reach utils/model_loading.py, so nothing exercises the patched load_weights / quantized_matmul together with a non-Bonsai 2-bit model.

Suggestion

Gate the patch on the family it was written for (the model types that actually need it), or state in a comment why the bit width alone is the correct signal. Happy to send the patch if you would like it gated — I can reproduce the path with a 2-bit checkpoint on this machine.