Axolotl

Axolotl est un framework de fine-tuning de LLM gratuit et open source, créé par Wing Lian et maintenu par les organisations Axolotl AI et OpenAccess AI Collective sur GitHub. Il enveloppe Hugging Face Transformers, PEFT et d'autres bibliothèques connexes derrière un système de configuration basé sur YAML, de sorte que les exécutions d'entraînement deviennent des artefacts reproductibles que vous pouvez commiter sur git, partager avec vos coéquipiers ou transmettre à des pipelines CI/CD. Publié sous licence Apache 2.0, le framework ne comporte aucune restriction de licence pour un usage commercial et a attiré les contributions de plus de 170 développeurs depuis son lancement en 2023.

Axolotl prend en charge plus de 100 architectures de modèles, dont Llama 4, Mistral Small 4, Qwen 3, Gemma 4, Granite 4, ainsi qu'un ensemble croissant de modèles de vision-langage tels que Qwen-VL, Pixtral et InternVL 3.5. Les méthodes d'entraînement couvrent le fine-tuning complet, LoRA, QLoRA, le preference tuning (DPO, IPO, KTO, ORPO), l'apprentissage par renforcement (GRPO, GDPO), la modélisation de récompense et l'entraînement sensible à la quantification (QAT). L'entraînement distribué multi-GPU via FSDP1, FSDP2 et DeepSpeed est une fonctionnalité de premier plan, tout comme la prise en charge multi-nœuds via Torchrun et Ray. Les jeux de données peuvent être extraits d'un disque local, du Hub Hugging Face ou d'un stockage cloud sur S3, Azure, GCP et OCI.

Ce que fait réellement Axolotl en avril 2026

La version v0.16.0 du 2 avril 2026 a été la mise à jour la plus importante du framework à ce jour. Wing Lian a annoncé deux capacités phares : ScatterMoE avec des noyaux Triton LoRA fusionnés offrant des passes avant MoE jusqu'à 15 fois plus rapides et nécessitant 40 fois moins de mémoire que les implémentations précédentes, ainsi que l'entraînement GRPO asynchrone avec intégration vLLM qui permet d'obtenir des temps d'étape 58 % plus rapides en superposant la génération de tokens avec la passe d'entraînement.

"Axolotl v0.16.0 est là. Deux grands piliers dans cette version : 1. MoE et LoRA, rendant le fine-tuning MoE rapide (15x plus rapide, 40x moins de mémoire) et l'entraînement LoRA fluide, sur toutes les architectures, clé en main. 2. GRPO, entraînement asynchrone (58 % plus rapide), noyaux Triton personnalisés, environnement." -- Wing Lian (@winglian), X, 2 avril 2026

Cette même version a ajouté Flash Attention 4 avec solution de repli automatique, l'intégration de NeMo Gym pour les environnements d'entraînement RL, l'Energy-Based Fine-Tuning (EBFT) comme nouvelle approche RL, le déchargement des couches CPU pour LoRA, le MX Quantization-Aware Training, et la prise en charge de nouveaux modèles pour Mistral Small 4, Qwen 3.5 et NeMo Super. Wing Lian a également annoncé une refonte complète de la documentation : "Nous avons également remanié la documentation, avec de nouveaux guides pour l'entraînement GRPO, le service vLLM, la stabilité de l'entraînement, le débogage et les workflows spécifiques aux agents."

La version v0.13.0 de décembre 2024 a introduit le SFT en streaming pour des tailles de jeux de données illimitées, l'entraînement par diffusion de texte sous forme de plugin, et l'entraînement sensible à la quantification NVFP4. La version v0.15.0 de mars 2026 a ajouté Torch 2.10.0, les noyaux SonicMoE pour les GPU Hopper et Blackwell, la quantification experte MoE qui a réduit le pic de mémoire réservée de 127 GiB à 23 GiB pour les grands modèles mixture-of-experts, et l'intégration de SageAttention.

Le framework couvre désormais l'ensemble du cycle de vie post-entraînement via un seul fichier YAML : prétraitement des jeux de données, entraînement, évaluation, quantification et préparation à l'inférence. Les paramètres de performance par défaut clés incluent les variantes de Flash Attention, le multipacking (regroupement de séquences pour éliminer le gaspillage lié au padding) et le parallélisme de séquences pour les modèles à contexte long. Wing Lian a expliqué la logique de cette approche basée sur la configuration lors du podcast Latent Space : "Je voulais vraiment que ce soit dans un fichier YAML parce que c'était plus portable et reproductible."

Où se situe Axolotl par rapport à Unsloth et LLaMA-Factory

Unsloth est l'outil de fine-tuning mono-GPU le plus rapide disponible en 2026, avec 53,9k étoiles GitHub contre 11,8k pour Axolotl. Unsloth utilise des noyaux Triton personnalisés qui remplacent FlashAttention 2 standard au niveau du noyau, permettant un entraînement 2 à 5 fois plus rapide et nécessitant 70 à 80 % de VRAM en moins que les méthodes de base. Sur un benchmark direct, un QLoRA Llama-3.1 8B entraîné sur un A100 40GB pendant deux époques sur 512 tokens a pris 3,2 heures avec Unsloth contre 5,8 heures avec Axolotl. Unsloth offre également un entraînement MoE 12 fois plus rapide et peut faire tenir l'entraînement d'un modèle de raisonnement GRPO dans 5 Go de VRAM. La limitation structurelle : la version open source d'Unsloth est uniquement mono-GPU. L'entraînement multi-GPU nécessite un abonnement Unsloth Pro. Les équipes qui passent à l'échelle sur 4, 8 GPU ou plus et qui ont besoin d'une licence ouverte choisissent Axolotl.

LLaMA-Factory compte 68,4k étoiles GitHub et constitue le point d'entrée pour les équipes qui ont besoin d'une interface web plutôt que d'un terminal. Son interface LlamaBoard gère la configuration des jeux de données, la sélection de la méthode d'entraînement et l'évaluation sans aucune interaction en ligne de commande, et elle utilise en interne le backend d'accélération d'Unsloth pour que les nouveaux utilisateurs bénéficient automatiquement d'une vitesse compétitive. La faiblesse de LLaMA-Factory est que la personnalisation de bas niveau est restreinte par l'interface graphique, et le débogage en production via une interface web est plus difficile que la lecture d'un fichier YAML ayant causé l'échec d'un entraînement. Les configurations YAML d'Axolotl peuvent être contrôlées en version, comparées (diff) et intégrées dans des pipelines, ce qui n'est pas le cas des exécutions configurées via une interface graphique.

TRL (Transformer Reinforcement Learning, 17,6k étoiles) est l'implémentation de référence de Hugging Face pour RLHF et GRPO, la technique utilisée par DeepSeek pour entraîner ses modèles de raisonnement. TRL est l'endroit où les articles de recherche sur l'alignement sont implémentés en premier, mais il n'est pas optimisé pour le débit sur le fine-tuning supervisé. L'implémentation GRPO de la v0.16.0 d'Axolotl avec chevauchement asynchrone vLLM le rend désormais directement compétitif avec TRL pour l'entraînement d'alignement en production à l'échelle multi-GPU.

À quoi ressemble réellement le workflow quotidien

Une exécution d'entraînement Axolotl commence par un fichier YAML. Une configuration minimale spécifie le modèle de base (un chemin Hugging Face Hub ou un répertoire local), le jeu de données (ID du Hub, JSONL local ou URI de stockage cloud), la méthode d'entraînement (LoRA, QLoRA, fine-tuning complet) et les éventuels indicateurs d'optimisation. Le YAML pilote ensuite la tokenisation et le prétraitement du jeu de données (exécutés une fois, mis en cache), l'entraînement avec la méthode configurée et l'évaluation facultative. Les commandes CLI sont courtes : axolotl preprocess config.yml suivi de axolotl train config.yml.

Pour les exécutions multi-GPU, le même YAML ajoute une section DeepSpeed ou FSDP2. Un exemple de production réel tiré du benchmark 2026 de Spheron : l'entraînement de Llama-3.1 70B sur 8 GPU H100 avec 50 000 exemples a pris 18 heures avec Axolotl FSDP2 et a produit une amélioration de 8 à 12 % par rapport aux variantes QLoRA sur les tâches en aval. Le fichier de configuration a été commité avec les résultats de l'expérience, rendant l'exécution reproductible par n'importe quel membre de l'équipe.

Le blog des développeurs de Red Hat a documenté un pipeline de fine-tuning clairsemé en trois étapes construit sur Axolotl en juin 2025. Le workflow combinait LLM Compressor pour la sparsification, Axolotl pour le fine-tuning sensible à la sparsité à l'aide d'une recette ConstantPruningModifier, et la quantification post-entraînement avant le déploiement vLLM. Le résultat : des modèles 3 fois plus petits et 2 fois plus rapides avec FP8 clairsemé, ou 5 fois plus petits et 3 fois plus rapides avec INT4 clairsemé, tout en conservant une précision de plus de 99 % sur la tâche.

Axolotl est le framework derrière plusieurs familles de modèles open source de premier plan. Nous Research l'a utilisé pour entraîner Puffin, Capybara et NousHermes. Les modèles OpenHermes et Trismigestus de Teknium ont été construits sur des configurations Axolotl. La reproductibilité basée sur YAML du framework signifie que les configurations de la communauté pour des combinaisons spécifiques de modèles/jeux de données circulent sur GitHub et Hugging Face aux côtés des poids fine-tunés, permettant aux équipes de forker et d'adapter des expériences réussies plutôt que de partir de zéro. Pour les équipes s'intégrant avec Predibase ou OpenPipe pour le fine-tuning hébergé, le format de checkpoint d'Axolotl (Hugging Face Transformers standard) est compatible : les adaptateurs entraînés dans Axolotl se chargent directement dans n'importe quelle pile d'inférence basée sur Transformers.

À qui s'adresse Axolotl

Axolotl cible les ingénieurs ML et les équipes de recherche qui ont besoin d'un fine-tuning de niveau production avec un contrôle total sur le processus d'entraînement. Le profil type : une équipe qui fine-tune des modèles de 7B à 70B de paramètres sur des données spécifiques à un domaine, s'exécutant sur 2 GPU ou plus ou sur un nœud GPU cloud, et qui a besoin que l'exécution de l'entraînement soit commitée dans le contrôle de version afin de pouvoir être auditée, répétée ou transmise à un autre ingénieur six mois plus tard.

Le framework est particulièrement performant pour : les équipes effectuant du fine-tuning multimodal (modèles vision-langage ou audio) où la couverture d'Unsloth est incomplète ; les équipes utilisant le GRPO de style DeepSeek pour entraîner des modèles de raisonnement ou des modèles RL spécifiques à un domaine ; les équipes intégrant le fine-tuning dans des pipelines MLOps où la reproductibilité compte plus que la minimisation du temps d'exécution sur un seul essai ; et les équipes effectuant un entraînement clairsemé ou sensible à la quantification où la prise en charge QAT d'Axolotl et l'intégration avec des outils de compression comme LLM Compressor fournissent un pipeline complet.

"Pour la plupart des utilisateurs, en particulier si vous êtes débutant, nous recommandons d'utiliser Axolotl en raison de son équilibre entre accessibilité et puissance." -- Guide de fine-tuning Modal.com, 2025

Axolotl s'intègre également naturellement à l'écosystème plus large. Les jeux de données se chargent depuis le Hub Hugging Face avec un simple ID de jeu de données Hub dans le YAML. Les métriques d'entraînement sont diffusées vers Weights and Biases ou d'autres outils de journalisation pris en charge. Les checkpoints sont enregistrés au format standard Transformers pour un déploiement direct en inférence. La compatibilité des checkpoints est un avantage pratique significatif : étant donné que les quatre principaux frameworks de fine-tuning open source (Axolotl, Unsloth, LLaMA-Factory et TRL) partagent le format de checkpoint Hugging Face Transformers en arrière-plan, les adaptateurs LoRA entraînés dans Axolotl se chargent directement dans Unsloth pour l'inférence, ou dans n'importe quelle pile de service basée sur Transformers, y compris vLLM et llama.cpp. Les équipes ne sont pas enfermées dans un écosystème. Passer de l'entraînement basé sur YAML d'Axolotl à un autre runtime d'inférence ne coûte rien, si ce n'est la réécriture de la configuration.

La philosophie du YAML comme configuration façonne également la manière dont les utilisateurs d'Axolotl partagent leur travail. Lorsque les chercheurs publient des modèles fine-tunés sur le Hub Hugging Face, le fichier de configuration YAML accompagne les poids, rendant la configuration d'entraînement transparente et reproductible. C'est une culture différente des workflows basés sur des notebooks : au lieu d'un notebook Colab avec des paramètres intégrés, vous obtenez une spécification déclarative que n'importe quel ingénieur de l'équipe peut exécuter, auditer et modifier sans toucher à Python. Pour les organisations où les exécutions d'entraînement de modèles doivent passer une revue interne ou être reproduites des mois plus tard pour des raisons de conformité ou de débogage, cette piste d'audit est un avantage matériel par rapport aux outils basés sur une interface graphique.

Ce que n'est pas Axolotl

Axolotl n'est pas la bonne première étape pour quelqu'un sans expérience en machine learning. L'installation nécessite Python 3.11+, PyTorch 2.9.1+ et un GPU NVIDIA Ampere compatible CUDA ou plus récent. Les nouveaux utilisateurs rencontrent régulièrement des incompatibilités de versions de dépendances ou des erreurs de mémoire insuffisante lors des premières exécutions, et les messages d'erreur ne pointent pas toujours clairement vers le paramètre YAML responsable. Une plainte récurrente dans les avis : "Axolotl est un excellent outil, mais sa documentation n'est pas facile à suivre." Si vous avez besoin d'une interface web, d'une configuration en cinq minutes et d'aucun travail en ligne de commande, LLaMA-Factory est le bon choix.

Axolotl n'est pas non plus le framework mono-GPU le plus rapide. Si votre contrainte est de maximiser la vitesse d'entraînement sur un seul GPU grand public (RTX 4090, 3090 ou instance Colab gratuite), Unsloth battra le débit d'Axolotl d'environ 2x pour une utilisation de VRAM comparable. Les couches d'abstraction autour de Hugging Face Transformers ajoutent une surcharge qui apparaît clairement dans les benchmarks mono-GPU. L'avantage multi-GPU d'Axolotl ne se matérialise que lorsque vous avez 2 GPU ou plus et que vous avez besoin de la coordination FSDP ou DeepSpeed.

Enfin, Axolotl n'est pas un service géré ou une API. Il n'y a pas de point de terminaison Axolotl que vous pouvez appeler pour fine-tuner un modèle. Vous l'exécutez vous-même sur votre propre matériel ou chez un fournisseur de GPU cloud. Les équipes qui souhaitent un fine-tuning sous forme d'API gérée devraient plutôt se tourner vers Predibase ou OpenPipe.