mlx-tune: Fine-Tuning on Apple Silicon With an Unsloth-Shaped API

The Problem: A Training Script That Cannot Leave the Cloud

The README opens with a personal note that frames the project precisely. The author says he relies on Unsloth for daily fine-tuning on cloud GPUs, then started working on a MacBook M4 and hit a friction point: he wanted to prototype locally, then scale to the cloud without rewriting the training script. Unsloth depends on Triton, which the README states Macs do not have yet, so it cannot run locally. The gap is therefore not a missing training algorithm. It is a missing runtime that accepts the same import statements. mlx-tune exists to close that gap by wrapping Apple's MLX framework in an Unsloth-compatible API. The intended user is narrow and clearly stated: someone who already writes code against FastLanguageModel and SFTTrainer, owns an Apple Silicon machine, and wants the same file to run in both places. If you have no intention of ever moving to a CUDA cluster, the compatibility layer buys you less than it appears to.

How the Compatibility Layer Actually Works

The mechanism is import substitution, not a transpiler. The README gives a side-by-side example: on CUDA you write from unsloth import FastLanguageModel and from trl import SFTTrainer; on Apple Silicon you write from mlx_tune import FastLanguageModel and from mlx_tune import SFTTrainer. The comment in the example says the rest of the code stays exactly the same. So the project reimplements the entry points that training scripts touch, and the underlying execution goes through MLX rather than Triton and CUDA kernels. That distinction matters when reading the feature table. The status list marks SFT, DPO, ORPO, GRPO, KTO and SimPO as stable, with notes such as full DPO loss, full ORPO loss, multi-generation plus reward for GRPO, binary feedback plus KTOConfig, and no reference model plus SimPOConfig. Those are algorithmic surfaces, and they are the part of Unsloth's API that a script actually calls. What is not claimed anywhere in the supplied material is that the kernel-level optimizations Unsloth is known for are reproduced on MLX. The README says the goal is not to replace Unsloth or claim superior performance, and that the goal is code portability. Read the feature table with that sentence in mind.

Getting It Running: Install, Rename, Import

The installation path is a single package from PyPI. The README's name-change note states that if you were using the earlier package name, you switch to pip install mlx-tune and update your imports from unsloth_mlx to mlx_tune. The badges indicate Python 3.9 or later and MLX 0.20 or later, and the platform is Apple Silicon only. The training loop itself is the Unsloth shape: import FastLanguageModel and SFTTrainer from mlx_tune, load a model, then train. The README also names several helper entry points that a script may call: train_on_responses_only(), to_sharegpt() with conversation_extension for multi-turn merging, apply_column_mapping() for automatic column renaming, and HFDatasetConfig for structured dataset loading. Version 0.6.0 adds three more: FastJEPAModel, FastVideoJEPAModel and LLMJEPATrainer, documented separately at the JEPA docs page. On the export side, the README states you can save in HuggingFace format or export to GGUF for Ollama and llama.cpp, and it points to a known limitations section for GGUF. That pointer is worth following before you plan a deployment around the export path.

What the Feature Table Does Not Promise

The status table is unusually candid, and the gaps are where adoption decisions get made. Chat templates are listed at 16 models across llama, gemma, qwen, phi and mistral. That is a finite list. If your base model is outside it, the compatibility story degrades, because a chat template mismatch changes what the model actually learns from. Model loading is described as stable for any HuggingFace model, quantized and non-quantized, which is broader than the template list, so the two statements have different scopes and should not be read as covering the same ground. Save and export is stable for HF format, with GGUF flagged by a limitations link rather than a caveat in the table itself. The audio surface is wide: five TTS models (Orpheus, OuteTTS, Spark, Sesame, Qwen3-TTS) and seven STT models (Whisper, Moonshine, Qwen3-ASR, NVIDIA Canary, Voxtral, Voxtral Realtime, NVIDIA Parakeet TDT). Vision support is described as full VLM fine-tuning via mlx-vlm, and the README text trails off mid-sentence at Gemma 4 in the supplied excerpt, so treat the vision model list as incomplete in this material rather than as a definitive inventory.

The Real Constraint: Memory Bandwidth, Not Just Memory Size

The README highlights unified memory, up to 512GB on a Mac Studio, as a reason to fine-tune locally. That is a capacity argument, and it is true as far as it goes: a large machine can hold a model that would not fit on a consumer GPU. But capacity is not throughput. Apple Silicon shares one memory pool between CPU and GPU, and the training step is bound by how fast that pool can be read, not only by how much of it is free. Nothing in the supplied material gives a tokens-per-second figure, a step time, or a comparison against a specific CUDA card, and I am not going to invent one. The honest reading is that mlx-tune removes the need for a cloud GPU during prototyping and iteration, which is the workflow claim the author actually makes. It does not make the Mac a substitute for the cluster. The README says so directly: local for prototyping and small datasets, cloud for full-scale training and large datasets. If your iteration loop is already fast enough on rented hardware, the local path adds a second environment to keep in sync for no throughput gain.

When This Is the Wrong Tool

Three cases stand out. First, production training runs on large datasets. The project's own diagram routes those to cloud GPUs and original Unsloth, so using mlx-tune for the final run means ignoring the author's stated design. Second, models outside the 16 supported chat templates. You can still load the weights, per the model-loading row, but you lose the guarantee that the template matches what the model expects, and that is a silent failure mode rather than a loud one. Third, workflows that depend on GGUF export as the delivery mechanism. The README links GGUF to known limitations instead of describing it as fully solved, and the v0.5.1 release note records a fix to save_pretrained_merged on a quantized base, tracked as issue #15. A bug in the merge path for quantized bases is exactly the kind of thing that surfaces after you have already trained, so test the export on a small run before committing to a full one.

Unsloth on a Rented GPU: The Actual Alternative

The obvious alternative is the thing mlx-tune is imitating: Unsloth itself, running on rented NVIDIA hardware. The difference is not a feature checklist, it is where the compute lives and what that does to your loop. Unsloth runs on CUDA through Triton and carries the kernel-level optimizations the README calls the gold standard for efficient fine-tuning on CUDA. mlx-tune runs on MLX and, by the author's own framing, does not attempt to match that. So the trade is: rent a GPU, get the optimized trainer and the full Unsloth surface, and pay per hour while your data leaves the laptop. Or stay local, get a compatible API and no hourly bill, and accept that the training step is not the optimized one. There is a third path worth naming: write against MLX directly and skip the compatibility layer entirely. That gives you access to MLX features the Unsloth-shaped API has no reason to expose, at the cost of a script you cannot move to CUDA. mlx-tune is specifically for people who have decided the portability is worth more than either of those.

Version Churn, Licence, and What to Check First

The release cadence is visible in the supplied dates: v0.5.0 on 2026-05-19 described as performance improvements across every trainer, v0.5.1 on 2026-05-31 as a targeted fix, and v0.6.0 on 2026-06-23 adding the JEPA family (LeJEPA, I-JEPA, V-JEPA 2 and LLM-JEPA, the last citing arXiv 2509.14252 and described as first-on-MLX). That is roughly monthly movement with a widening surface, which means upgrade cost is real: each release can touch trainers, and the v0.5.1 note shows that save and merge paths are still being corrected. Pin a version for anything you depend on. The licence is Apache-2.0, which is permissive and includes an explicit patent grant, but the model weights you fine-tune carry their own licences from their original publishers, and mlx-tune does not change those terms. That is a fact about the stack, not legal advice; check the licence of each base model you load. Before adopting, the concrete items to verify are: whether your model is in the 16 chat templates, whether your export target survives a small GGUF round trip, and whether the trainer you need (SFT, DPO, GRPO, KTO, SimPO, or one of the JEPA entry points) is in the stable column of the table for the version you pinned.

Editorial conclusion

mlx-tune is for Mac-based engineers who want to prototype a fine-tuning pipeline locally and then move the same FastLanguageModel script to a CUDA cluster running Unsloth. It is not for anyone who needs maximum training throughput on NVIDIA hardware, or who expects the full Unsloth feature set, since attention and kernel-level optimizations are not part of this project. Before adopting it, verify that your target model appears in the 16 chat templates the README lists, and read the known limitations section on GGUF export.

Official sources

1. ARahim3/mlx-tune on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases