Bonsai/t5 load patch is installed for every 2-bit checkpoint, and no test covers that path
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:
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.
Source: jundot/omlx