The mlx-community Repository on Hugging Face

mlx-community is where almost every MLX model you will load comes from, and it is a community organisation rather than an Apple product. Understanding that is most of what you need to use it well: the naming is a convention, not a schema, and nothing in it is guaranteed to be current.

What the organisation is

It is a Hugging Face organisation that anyone can join, holding conversions produced with the same mlx_lm.convert command described in converting a model to MLX format. Read through the Hugging Face organisation API on 11 August 2026, it reported 5,440 models and 5,504 members. Those figures move continuously — the first is what makes the org useful and the second is what makes it unaudited.

Because conversion is close to mechanical, the weights in a well-formed repository are a faithful re-encoding of the upstream checkpoint and not a fork. The value the org adds is that somebody already spent the download bandwidth and the disk space, which for a 70B is the difference between forty gigabytes and a hundred and eighty.

Reading a repository name

The convention is the upstream model name, unchanged, plus a suffix describing the numeric format. Real examples from the org, in the same reading:

mlx-community/Qwen3-14B-4bit           affine 4-bit, group size 64
mlx-community/Qwen3-0.6B-8bit          affine 8-bit
mlx-community/Muse-Glimmer-30B-6bit    affine 6-bit
mlx-community/Muse-Glimmer-30B-bf16    not quantized, bfloat16
mlx-community/...-A3B-mxfp4            microscaling fp4
mlx-community/...-A3B-mxfp8            microscaling fp8
mlx-community/Muse-Glimmer-30B-nvfp4   nvfp4

So the vocabulary in active use is -4bit, -5bit, -6bit, -8bit, -bf16, -fp16, -mxfp4, -mxfp8 and -nvfp4, which maps directly onto the --q-bits and --q-mode options of the converter. A name with no suffix at all is usually an unquantized conversion, and a name with a suffix you do not recognise is usually a bespoke recipe from one uploader.

The convention is not enforced. Casing varies — -8Bit exists alongside -8bit — and some uploaders append their own scheme names for mixed-precision recipes. Do not parse repository names in code; read config.json, which carries the authoritative quantization block with bits, group_size and mode.

What the name does not tell you is the size. A 4-bit repository is roughly 0.5625 bytes per parameter, so a 14B is about 8.3 GB and a 70B about 39.7 GB — the arithmetic is worked out in quantizing a model for MLX. Check the file sizes on the repository’s Files tab before you start a download you cannot hold.

There is no version number

This is the real trap. When an upstream model is re-released — a tokenizer fix, a corrected chat template, a new instruct revision — the conversion in mlx-community does not automatically follow, and nothing in the repository name changes to tell you which upstream commit it came from. Two repositories with the same name and different uploaders can be conversions of different source revisions.

Three checks, in the order they are worth doing:

• The commit history. The Files tab shows when each file last changed. A conversion whose weights predate a known upstream fix does not contain that fix.
• The config.json. The quantization block tells you exactly what was done, which is the only claim about the repository that is machine-checkable.
• The chat template. It lives in the tokenizer files and is copied through at conversion time, so a stale conversion carries a stale template. If a model behaves oddly with role markers, compare its template against the upstream repository’s before blaming the quantization.

If reproducibility matters — anything you would deploy — convert from a pinned upstream revision yourself with --revision. That is one command and it removes the entire class of problem.

Licences travel with the weights

Converting a checkpoint does not change its licence. A conversion of a gated model is still governed by the upstream terms, and an mlx-community copy of a model whose original repository requires you to accept a licence does not constitute permission you did not have.

In practice the well-maintained repositories say so on their card and link the original. Where one does not, the upstream repository is the authority, not the conversion — and if you are shipping something, that is the page to read and record, not the mirror. The general treatment is in quantized model transparency.

When to convert it yourself

Pulling a pre-converted model is the right default for trying something out. Converting yourself is worth the download when any of these is true: you need a quantization level or mode nobody has uploaded; you need the conversion pinned to a specific upstream commit; you are deploying it and want the provenance to be a command in your repository rather than a stranger’s upload; or you want a mixed-bit recipe, which is a converter flag and is rarely uploaded.

The cost is bandwidth and disk — the full-precision source has to land on your machine first — and about the length of time it takes to read the checkpoint twice. For an 8B that is minutes. For a 70B it is an evening and roughly 180 GB of transient disk.

One habit that removes most of the ambiguity either way: record the exact repository and commit you loaded, not just the name. The Hugging Face cache stores blobs by revision, so hf download <repo> --revision <sha> and a note of that sha in your project turns “the 4-bit one from mlx-community” into something reproducible. It costs nothing and it is the difference between a model that behaves differently next month being a mystery and being a diff.

There is also a category of repository worth being wary of, and it is not the abandoned ones. Fine-tunes and merges are uploaded here alongside conversions of official releases, under names that look like the original with a word appended. Those are different models with different behaviour and, frequently, different licence positions than the base weights they were derived from. Read the model card before assuming a repository named after a family is that family.