mlx-tune: Unsloth-API auf Apple Silicon, mit MLX statt Triton
Fine-tune LLMs on your Mac with Apple Silicon. SFT, DPO, GRPO, Vision, TTS, STT, Embedding, and OCR fine-tuning — natively on MLX. Unsloth-compatible API.
Auf einen Blick
- Was ist das?
- mlx-tune bildet die Unsloth-Schnittstelle auf Apples MLX-Framework nach, damit dasselbe Trainingsskript lokal auf dem Mac laeuft und spaeter auf einer CUDA-Maschine. Der Nutzen liegt in der Portabilitaet, nicht in der Geschwindigkeit.
- Für wen ist es gedacht?
- Sinnvoll ist mlx-tune fuer Einzelpersonen und kleine Teams, die auf einem Mac mit Apple Silicon Prototypen bauen und denselben Code spaeter auf einer NVIDIA-Maschine mit Unsloth weiterverwenden wollen. Wer produktiv auf CUDA trainiert, grossen Datensaetzen verarbeitet oder Werkzeuge wie Triton, Flash-Attention oder bitsandbytes voraussetzt, sollte beim Original bleiben.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 85 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Workflow-Problem, kein Hardware-Problem
Der Autor beschreibt den Ausloeser selbst: Er arbeitet taeglich mit Unsloth auf Cloud-GPUs, bekam dann ein MacBook M4 und wollte lokal prototypen, ohne das Trainingsskript fuer die Cloud neu zu schreiben. Unsloth setzt auf Triton, das auf dem Mac nicht verfuegbar ist. Damit zerfaellt der Arbeitsablauf in zwei nicht kompatible Teile. mlx-tune schliesst diese Luecke, indem es Apples MLX-Framework hinter eine API legt, die wie Unsloth aussieht. Der Nutzen ist ausdruecklich nicht Leistung. Im README steht, das Ziel sei nicht, Unsloth zu ersetzen oder bessere Werte zu behaupten, sondern Code-Portabilitaet. Wer ein Modell auf dem Mac vortrainiert und danach dieselbe Datei auf einen CUDA-Cluster schiebt, muss nichts umbauen. Das ist ein enges, aber praezise beschriebenes Ziel. Wer mlx-tune als schnelleren Ersatz fuer Unsloth sucht, sucht am Zweck des Projekts vorbei.
Die API-Nachbildung ist die eigentliche Architektur
Das Projekt implementiert keine neue Trainingsbibliothek von Grund auf, sondern eine Uebersetzungsschicht. Aus `from unsloth import FastLanguageModel` wird `from mlx_tune import FastLanguageModel`, aus `from trl import SFTTrainer` wird `from mlx_tune import SFTTrainer`. Der Rest des Skripts bleibt laut README unveraendert. Darunter liegt MLX, Apples Framework fuer Apple Silicon, das die Unified Memory des Systems direkt nutzt. Auf einem Mac Studio sind das laut README bis zu 512 GB, die als ein Speicherraum fuer Modell und Aktivierungen zur Verfuegung stehen. Das ist der Grund, warum ein Mac ueberhaupt als Trainingsmaschine in Frage kommt: kein Kopieren zwischen Host und VRAM. Die Nachbildung umfasst nicht nur Trainer, sondern auch Hilfsfunktionen wie `train_on_responses_only()`, `to_sharegpt()` mit `conversation_extension`, `apply_column_mapping()` und `HFDatasetConfig`. Diese Liste ist aufschlussreich. Sie zeigt, dass der Autor den Unsloth-Workflow inklusive Datenaufbereitung nachbaut, nicht nur die Trainingsschleife. Genau dort liegt das Risiko: Je mehr Oberflaeche nachgebildet wird, desto mehr Stellen koennen bei einem Versionssprung des Originals auseinanderlaufen.
Trainingsverfahren und Modalgattungen
Die Statusliste im README nennt SFT, DPO, ORPO, GRPO, KTO und SimPO jeweils als stabil. Bei DPO und ORPO steht ausdruecklich "Full DPO loss" beziehungsweise "Full ORPO loss", bei GRPO "Multi-generation + reward". Das sind Abgrenzungen gegen vereinfachte Nachbauten, die nur einen Teil der Verlustfunktion umsetzen. Fuer KTO und SimPO gibt es eigene Konfigurationsklassen, `KTOConfig` und `SimPOConfig`. Bei SimPO wird zusaetzlich vermerkt, dass kein Referenzmodell noetig ist, was den Speicherbedarf waehrend des Trainings senkt. Neben Textmodellen deckt das Projekt Vision-Modelle ueber mlx-vlm ab, ausserdem Text-zu-Sprache, Spracherkennung und Embeddings. Die Audio-Liste umfasst laut README fuenf TTS-Modelle (Orpheus, OuteTTS, Spark, Sesame, Qwen3-TTS) und sieben STT-Modelle (Whisper, Moonshine, Qwen3-ASR, NVIDIA Canary, Voxtral, Voxtral Realtime, NVIDIA Parakeet TDT). Mit Version 0.6.0 kommen JEPA-Verfahren hinzu: LeJEPA zum Vortraining eines Vision Transformers, I-JEPA mit Metas vortrainiertem Bildencoder, V-JEPA 2 fuer Video samt `predict_latents` und `latent_energy`, sowie LLM-JEPA, das die JEPA-Zielfunktion auf die LLM-Feinabstimmung uebertraegt. Die neuen Einstiegspunkte heissen `FastJEPAModel`, `FastVideoJEPAModel` und `LLMJEPATrainer`. Das ist ein ungewoehnlich breiter Umfang fuer ein Projekt dieser Groesse, und Breite ist hier ein Warnsignal: Jede Modalgattung bringt eigene Datenformate, eigene Fehlerquellen und eigene Tests mit.
Installation und die Namen, die sich geaendert haben
Das Projekt hiess frueher `unsloth-mlx`. Weil es kein offizielles Unsloth-Projekt ist, wurde es umbenannt. Wer die alte Version im Einsatz hatte, muss laut README zwei Dinge tun: auf `pip install mlx-tune` wechseln und die Imports von `unsloth_mlx` auf `mlx_tune` aendern. Die Umbenennung ist mehr als Kosmetik, denn der alte Name legte eine Zugehoerigkeit nahe, die nicht besteht. Voraussetzungen sind Apple Silicon, Python ab 3.9 und MLX ab 0.20. Der Quick Start im README zeigt das Muster: `FastLanguageModel` laden, `SFTTrainer` instanziieren, trainieren, und das Ergebnis anschliessend im HuggingFace-Format oder als GGUF fuer Ollama und llama.cpp exportieren. Der GGUF-Export ist der Punkt, an dem die meisten Nutzer scheitern duerften, denn das README verweist dafuer auf einen eigenen Abschnitt mit Einschraenkungen, statt ihn als voraussetzungsfrei darzustellen. Wer ein quantisiertes Basismodell verwendet, sollte zusaetzlich die Release Notes zu v0.5.1 lesen: Dort wird ein Fehler in `save_pretrained_merged` bei quantisierter Basis behoben, der genau diesen Exportpfad betrifft. Ein quantisiertes Basismodell ist auf einem Mac mit begrenztem Unified Memory der Normalfall, nicht die Ausnahme.
Wo mlx-tune das falsche Werkzeug ist
Der wichtigste Vorbehalt steht im Projekt selbst: mlx-tune ist kein Ersatz fuer Unsloth und erhebt keinen Anspruch auf vergleichbare Leistung. Das README beschreibt den vorgesehenen Ablauf als Kette. Lokal auf dem Mac wird prototypisiert, mit kleinen Datensaetzen und schnellen Iterationen. Fuer das eigentliche Training groesserer Datensaetze geht es auf Cloud-GPUs mit dem Original. Wer diese Kette umdreht und auf dem Mac produktiv trainieren will, arbeitet gegen die dokumentierte Absicht. Dazu kommen harte Grenzen: Die Bibliothek laeuft nur auf Apple Silicon, sie ist an MLX ab 0.20 gebunden, und der GGUF-Export ist laut README mit Einschraenkungen versehen. Ein weiterer Punkt ist die Abhaengigkeit von der API eines anderen Projekts. Aendert Unsloth seine Signaturen, muss mlx-tune nachziehen, sonst bricht die Portabilitaet genau an der Stelle, an der sie versprochen wird. Das ist kein Fehler des Autors, sondern eine Eigenschaft des Ansatzes. Wer eine stabile, langfristig garantiert kompatible Schnittstelle braucht, findet sie hier nicht.
Was Unsloth anders macht
Der Unterschied liegt nicht in den Trainingsverfahren. DPO, GRPO und die uebrigen Verlustfunktionen sind in beiden Projekten vorhanden. Der Unterschied liegt im Unterbau. Unsloth laeuft auf CUDA und nutzt Triton-Kernel, die auf NVIDIA-Hardware zugeschnitten sind. mlx-tune laeuft auf MLX und nutzt die Unified Memory von Apple Silicon. Diese beiden Entscheidungen schliessen sich gegenseitig aus, und deshalb ist die Wahl keine Frage der Qualitaet, sondern der vorhandenen Hardware. Praktisch heisst das: Auf einem Mac ist Unsloth nicht installierbar, auf einer NVIDIA-Maschine ist mlx-tune nicht sinnvoll. Der eigentliche Wert von mlx-tune liegt darin, dass die Schnittstelle gleich bleibt, waehrend die Hardware wechselt. Ein Skript, das auf dem Mac gegen `FastLanguageModel` und `SFTTrainer` entwickelt wurde, soll auf der CUDA-Maschine mit den gleichnamigen Klassen aus Unsloth laufen. Ob das im Einzelfall gelingt, haengt davon ab, wie tief das Skript in Unsloth-Interna greift. Je mehr direkt importierte Hilfsfunktionen und je mehr Annahmen ueber Zwischenergebnisse, desto unwahrscheinlicher ist die reibungslose Uebertragung.
Wartung, Versionen und Lizenz
Die Release-Historie zeigt einen kurzen Takt: v0.5.0 mit Leistungsverbesserungen in allen Trainern am 19. Mai 2026, v0.5.1 mit einem gezielten Fehlerfix am 31. Mai, v0.6.0 mit der JEPA-Familie am 23. Juni. Zwischen v0.5.0 und v0.6.0 liegen rund fuenf Wochen, und in dieser Zeit kamen mehrere neue Einstiegspunkte hinzu. Fuer Anwender bedeutet das: Die Oberflaeche waechst schneller als die Dokumentation nachziehen kann, und ein Upgrade kann neue Abhaengigkeiten mitbringen. Wer mlx-tune in einer laufenden Pipeline einsetzt, sollte die Version festnageln und vor jedem Sprung die Release Notes lesen, besonders wenn quantisierte Basismodelle im Spiel sind. Zur Lizenz: Das Projekt steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Aenderungen an Dateien kenntlich gemacht werden. Was das fuer ein konkretes Produkt bedeutet, haengt vom Einzelfall ab und gehoert zu einer Rechtsberatung, nicht in eine Projektbesprechung. Unabhaengig davon bleibt eine zweite Ebene: Die heruntergeladenen Basismodelle und Datensaetze tragen eigene Lizenzen, die von Apache-2.0 abweichen koennen. Wer ein mit mlx-tune feinabgestimmtes Modell weitergibt, muss diese Ebene separat pruefen.
Redaktionelles Fazit
Sinnvoll ist mlx-tune fuer Einzelpersonen und kleine Teams, die auf einem Mac mit Apple Silicon Prototypen bauen und denselben Code spaeter auf einer NVIDIA-Maschine mit Unsloth weiterverwenden wollen. Wer produktiv auf CUDA trainiert, grossen Datensaetzen verarbeitet oder Werkzeuge wie Triton, Flash-Attention oder bitsandbytes voraussetzt, sollte beim Original bleiben. Vor dem ersten Ernstfall ist zu pruefen, ob das eigene Basismodell im MLX-Format vorliegt, ob der geplante Exportweg nach GGUF mit dem gewaehlten Quantisierungsgrad zusammenpasst und ob das eigene Skript ausserhalb der nachgebildeten Namen auf Unsloth-Interna zugreift.
Community-Notizen