mlx-tune : fine-tuner des LLM sur Mac en gardant le script Unsloth
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.
En bref
- De quoi s’agit-il ?
- mlx-tune enveloppe MLX d'Apple Silicon derrière une API compatible Unsloth, pour prototyper en local puis pousser le même script sur un cluster CUDA. Le projet vise la portabilité du code, pas la performance brute.
- À qui s’adresse-t-il ?
- mlx-tune convient à celui qui possède déjà un Mac Apple Silicon et veut prototyper un pipeline de fine-tuning avant de payer du GPU cloud, en réutilisant tel quel un script écrit pour Unsloth. Il ne convient pas à qui cherche à entraîner en production sur Mac, ni à qui attend la parité de performance avec Unsloth sur CUDA.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 84 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : le changement de contexte entre Mac et CUDA
L'auteur du projet raconte dans le README avoir rencontré un point de friction précis : il utilise Unsloth pour ses fine-tunings quotidiens sur GPU cloud, mais travaille aussi sur un MacBook M4. Il voulait prototyper en local puis monter en charge sur le cloud sans réécrire son script d'entraînement. Unsloth s'appuie sur Triton, que les Mac ne fournissent pas selon le README, donc la bibliothèque n'est pas utilisable localement. mlx-tune est né de cette contrainte, et l'auteur formule explicitement l'objectif : la portabilité du code, pas la supériorité de performance. Le projet a d'ailleurs été renommé, il s'appelait auparavant unsloth-mlx, et le README précise qu'il ne s'agit pas d'un projet officiel Unsloth. Le public visé est donc étroit et identifiable : un développeur équipé d'un Mac Apple Silicon, déjà familier d'Unsloth, qui veut itérer vite sur de petits jeux de données avant de lancer l'entraînement complet ailleurs.
Ce que le remplacement d'imports implique réellement
La promesse tient en deux lignes de code. Là où un script Unsloth écrit from unsloth import FastLanguageModel et from trl import SFTTrainer, mlx-tune propose from mlx_tune import FastLanguageModel et from mlx_tune import SFTTrainer. Le README affirme que le reste du code ne change pas. C'est le mécanisme central du projet : reproduire les noms de classes et de fonctions d'Unsloth pour que le script reste identique de part et d'autre. La conséquence pratique est double. D'un côté, la migration d'un script existant se limite à l'import. De l'autre, le script devient dépendant de la fidélité de cette imitation : tout ce qu'Unsloth expose et que mlx-tune n'implémente pas se traduira par une erreur à l'exécution, pas par une dégradation silencieuse. Le README ne fournit pas de tableau de correspondance exhaustif entre les deux API, seulement la liste des méthodes d'entraînement marquées Stable. C'est une limite documentaire à garder en tête : la compatibilité annoncée porte sur le cœur de l'API, pas sur l'intégralité de la surface d'Unsloth.
MLX comme couche d'exécution, et ce que cela change pour la mémoire
mlx-tune n'implémente pas son propre moteur d'entraînement. Il enveloppe MLX, le framework d'Apple, et s'appuie sur la mémoire unifiée des puces M1 à M5. Le README mentionne des configurations jusqu'à 512 Go sur Mac Studio, ce qui déplace la contrainte habituelle : au lieu de raisonner en VRAM de carte graphique, on raisonne en mémoire partagée entre le système et le GPU. Le chargement de modèles est annoncé comme fonctionnant avec n'importe quel modèle HuggingFace, quantifié ou non. Les méthodes d'entraînement listées comme stables couvrent SFT, DPO, ORPO, GRPO, KTO et SimPO, avec des implémentations présentées comme complètes pour DPO, ORPO et SimPO. Le projet ajoute des utilitaires de préparation de données : to_sharegpt() avec conversation_extension pour fusionner des tours de conversation, apply_column_mapping() pour renommer automatiquement des colonnes, HFDatasetConfig pour un chargement structuré, et train_on_responses_only() pour n'entraîner que sur les réponses. Les templates de chat sont fournis pour 16 modèles, dont llama, gemma, qwen, phi et mistral.
Des modalités au-delà du texte, et l'arrivée de JEPA en v0.6.0
Le projet ne se limite pas aux LLM. Le README liste le fine-tuning de modèles vision via mlx-vlm, cinq modèles TTS (Orpheus, OuteTTS, Spark, Sesame, Qwen3-TTS) et sept modèles STT (Whisper, Moonshine, Qwen3-ASR, NVIDIA Canary, Voxtral, Voxtral Realtime, NVIDIA Parakeet TDT), plus l'embedding et l'OCR. La version 0.6.0 introduit la famille JEPA de Yann LeCun : LeJEPA pour préentraîner un Vision Transformer avec l'objectif SIGReg, I-JEPA pour charger les encodeurs facebook/ijepa_*, V-JEPA 2 pour les modèles vidéo facebook/vjepa2_* avec classification de clips et prédiction de latents masqués, et LLM-JEPA qui ajoute un terme JEPA à la prédiction du token suivant en alignant deux vues d'un même élément. Les points d'entrée correspondants sont FastJEPAModel, FastVideoJEPAModel et LLMJEPATrainer. Cette accumulation de domaines dans un seul paquet est un choix discutable : elle élargit la surface à maintenir, et le README ne donne pas d'indication sur la maturité relative de chaque modalité au-delà du tableau de statut. Un utilisateur venu pour le STT n'a aucune raison de porter le code JEPA, mais il en subit la dépendance.
Installation et export : ce que la documentation montre
L'installation se fait par pip install mlx-tune, comme l'indique la note de renommage du README, qui précise aussi de remplacer les imports unsloth_mlx par mlx_tune pour les utilisateurs de l'ancien nom. Les prérequis annoncés sont Python 3.9 ou plus et MLX 0.20 ou plus, sur plateforme Apple Silicon. L'export est présenté comme prenant en charge le format HuggingFace et le format GGUF pour Ollama et llama.cpp. C'est ici qu'il faut lire attentivement : le tableau de statut renvoie la ligne Save/Export vers une section intitulée Known limitations pour ce qui concerne le GGUF, ce qui signifie que le README lui-même signale des restrictions sur ce chemin. Le projet a par ailleurs corrigé en v0.5.1 un bug de save_pretrained_merged sur un modèle de base quantifié, ce qui donne une idée du type de problème rencontré dans cette zone. La version 0.5.0 annonce des améliorations de performance sur l'ensemble des entraîneurs, sans chiffres dans le matériel fourni. Je ne peux donc pas quantifier ce gain.
La portabilité a un coût, et il n'est pas mesuré ici
Le README est explicite sur un point : le but n'est pas de remplacer Unsloth ni de revendiquer de meilleures performances. La comparaison honnête n'est donc pas mlx-tune contre Unsloth, mais mlx-tune contre l'absence de prototypage local. Si votre jeu de données est petit et que vous voulez valider un pipeline avant de louer un GPU, l'outil a un sens. Si vous comptez entraîner en production sur Mac, le README décrit lui-même mlx-tune comme une étape de prototypage, avec le cloud NVIDIA et Unsloth pour les entraînements à grande échelle. La limite structurelle est ailleurs : le code reste identique, mais le comportement numérique ne l'est pas forcément. Une loss qui converge sur MLX ne garantit pas la même trajectoire sur CUDA, et rien dans le matériel fourni ne documente cet écart. C'est le point aveugle du projet. Pour un prototype destiné à valider un format de données ou un template de chat, l'écart importe peu. Pour calibrer un learning rate ou un nombre d'étapes, il faut s'attendre à réajuster sur le cluster cible.
Alternatives et entretien
L'alternative directe est Unsloth lui-même, sur GPU cloud : même API, mais exécution CUDA et Triton, avec l'écosystème complet. La différence n'est pas une question de qualité mais d'étape dans le cycle de développement : Unsloth suppose une machine NVIDIA, mlx-tune suppose un Mac. Une autre option consiste à écrire directement contre MLX ou mlx-lm, sans la couche de compatibilité Unsloth. On perd la portabilité du script, on gagne un contrôle total sur l'API et on évite de dépendre de la fidélité d'une imitation. Le choix dépend de ce que vous valorisez : réutiliser un script existant, ou ne pas avoir à en maintenir deux versions. Sur l'entretien, le rythme de publication est soutenu, avec trois versions entre mai et juin 2026, dont une correction ciblée sur un cas d'export. Cela suggère un projet actif, mais aussi une API encore mouvante : la version 0.6.0 ajoute des points d'entrée entiers, ce qui peut casser du code écrit contre 0.5.x. Le projet est sous licence Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de licence et d'état des modifications. Cette licence couvre le code de mlx-tune, pas les poids des modèles que vous chargez depuis HuggingFace : leurs conditions propres s'appliquent séparément, et le README ne les traite pas.
Conclusion éditoriale
mlx-tune convient à celui qui possède déjà un Mac Apple Silicon et veut prototyper un pipeline de fine-tuning avant de payer du GPU cloud, en réutilisant tel quel un script écrit pour Unsloth. Il ne convient pas à qui cherche à entraîner en production sur Mac, ni à qui attend la parité de performance avec Unsloth sur CUDA. Avant d'adopter, vérifier dans le README que la méthode d'entraînement visée figure bien dans le tableau de statut avec la mention Stable, et tester l'export GGUF sur votre modèle de base, car c'est le point que la documentation signale elle-même comme limité.
Notes de la communauté