MLX LM provides a native Apple Silicon path for adapting open language models with LoRA or QLoRA. The command is the easy part. The quality of the result depends on the dataset contract, the frozen baseline, and the evaluation you run after the adapter trains.

Prepare the environment and data

Install the training extras for MLX LM and choose a compatible model. The official loader accepts a local data directory with train.jsonl, optional valid.jsonl, and test.jsonl, or supported Hugging Face datasets. Chat, tool, completion, and text formats are supported. Keep each JSONL example on one line and validate the chat template for the chosen base model.

Run a bounded adapter experiment

Use mlx_lm.lora with the base model, data path, iteration budget, and an explicit adapter output path. A quantized base selects QLoRA; a non-quantized base uses LoRA by default. Record the exact base revision, MLX LM version, configuration, seed, data manifest, and machine. If you use prompt masking, verify that the loss is applied to the intended completion tokens.

Evaluate before fusing

Test the unchanged base and the adapter on the same frozen examples. Perplexity can detect some training problems but does not replace task metrics. For a tool specialist, measure exact tool selection and arguments. For a formatter, measure protected spans and unnecessary edits. Add out-of-domain slices so a narrow gain cannot hide general regression.

Generate and package

Use the adapter with mlx_lm.generate for qualitative inspection only after the quantitative gate. Fuse only when the evaluation decision supports it. The official MLX LM workflow can fuse adapter weights and export GGUF, but the resulting artifact still needs a model card, base identity, license checks, runtime requirements, and a record of missing measurements.

Common failure modes

Training and evaluating on overlapping examples.
Choosing a ship threshold after seeing the candidate.
Treating lower loss as task success.
Publishing only the improved slice.
Fusing before preserving the adapter, recipe, and evidence.
Assuming a narrow specialist should replace the general model.

PostTrainLLM wraps these concerns in a factory-run, evaluation, package, and report-card workflow so the result is a decision artifact rather than an orphan adapter folder.

CTA: Read the local evaluation guide or inspect a public specialist report card.