Quatre projets open source dominent aujourd’hui le fine-tuning des grands modèles de langage : Unsloth, Axolotl, TRL et LLaMA-Factory. Tous les quatre encapsulent la même pile sous-jacente PyTorch et Hugging Face, mais ils divergent dans la manière dont ils concentrent leurs efforts d’ingénierie. Unsloth réécrit des kernels pour maximiser la vitesse brute. Axolotl se concentre sur des stratégies de parallélisme composables. TRL définit les API d’entraînement sur lesquelles les autres s’appuient. LLaMA-Factory privilégie l’étendue de la couverture des modèles et l’utilisation sans code.

Alors que les modèles à poids ouverts de Meta, Alibaba, Google et d’autres réduisent l’écart de qualité avec les API propriétaires, les entreprises recourent de plus en plus au fine-tuning local plutôt que de payer des primes par token — faisant de la couche framework un levier direct de coûts, les heures GPU restant la dépense dominante dans toute chaîne de personnalisation.

Cette comparaison évalue trois axes auxquels les praticiens sont régulièrement confrontés : le débit d’entraînement, l’utilisation maximale de la VRAM et le passage à l’échelle multi-GPU.

Vue d’ensemble des frameworks

TRL sert de couche d’implémentation de référence. Il fournit SFTTrainer, DPOTrainer, GRPOTrainer, KTOTrainer, RewardTrainer et RLOOTrainer. Axolotl et LLaMA-Factory l’appellent tous deux en interne. La ligne de version stable actuelle est v1.8.0.

Unsloth remplace certaines parties du code de modélisation par des kernels Triton écrits à la main. Les étapes de rétropropagation sont dérivées manuellement plutôt que générées par autograd. Le propre article de Hugging Face indique que la dégradation de précision est de 0 % par rapport à QLoRA standard, car aucune approximation n’est introduite.

Axolotl est une surcouche pilotée par YAML au-dessus de Transformers, PEFT, TRL, Accelerate et DeepSpeed. Son principal facteur de différenciation est la composabilité des stratégies de parallélisme, et non l’optimisation au niveau des kernels.

LLaMA-Factory est documenté dans un article de démonstration système ACL 2024 et inclut une interface web Gradio appelée LlamaBoard. Le dépôt couvre plus de 100 LLM et VLM.

Vitesse

Unsloth : gains au niveau des kernels sur un seul GPU

Les benchmarks publiés par Unsloth indiquent une vitesse d’entraînement 2x pour Llama 3.1 8B et Llama 3.3 70B. La configuration de test utilisait le jeu de données Alpaca, une taille de batch de 2 et une accumulation de gradients de 4. QLoRA était exécuté au rang 32 sur toutes les couches linéaires.

Les résultats pour les modèles Mixture-of-Experts (MoE) sont plus marqués. Unsloth a fine-tuné unsloth/gpt-oss-20b-BF16 sur une NVIDIA B200, avec 712.33 ms par étape à un contexte 8K contre 5,226.86 ms pour Transformers v5 — soit un écart de 7.3x. À un contexte 4K, l’écart se réduit à 4.82x, et à 1K il n’est plus que de 1.37x.

La direction de la tendance dépend du modèle. La documentation MoE d’Unsloth limite cette affirmation particulière à gpt-oss, où l’accélération augmente avec la longueur de séquence, grâce à Flex Attention et aux kernels MoE.

Qwen3-30B-A3B sur B200 présente le schéma inverse. L’accélération rapportée passe de 1.7x à un contexte 1K à 1.1x à 16K. Les économies de mémoire évoluent dans le sens opposé, passant d’environ 2 % à 15 %.

Qwen3-30B-A3B sur H100 atteint jusqu’à 1.77x. GLM-4.7-Flash sur RTX PRO 6000 atteint 2.1x. Une collaboration avec AMD a mesuré Llama-3.1-8B LoRA SFT à 2.07 s/step, tandis que TRL avec FlashAttention-2 atteignait 2.87 s/step — un écart de 1.39x avec des courbes de perte correspondantes.

Axolotl : kernels empruntés, parallélisme natif

Axolotl a ajouté en février 2025 des kernels Triton personnalisés et des fonctions autograd pour LoRA, en citant explicitement Unsloth comme source d’inspiration. Ils sont activables en option via lora_mlp_kernel, lora_qkv_kernel et lora_o_kernel.

Des notes de version récentes ajoutent la prise en charge de SonicMoE LoRA, avec jusqu’à 1.45x d’accélération et 30 % de réduction de mémoire par rapport à une baseline grouped_mm pour Qwen3.5-35B-A3B 8-bit LoRA sur un seul H100 SXM.

Axolotl inclut également FlashAttention 2/3/4, xFormers, Flex Attention, SageAttention, Liger Kernel, Cut Cross Entropy et ScatterMoE.

TRL : la référence à laquelle tout le monde se compare

TRL sert généralement de point de référence plutôt que de vainqueur en débit brut sur un seul GPU. Il compense par un large éventail de leviers mémoire et vitesse documentés dans Reducing Memory Usage et Speeding Up Training. Ces leviers incluent le packing, les batches sans padding, la troncature, Liger Kernel et le mode veille vLLM pour GRPO. TRL dispose aussi d’une intégration Unsloth de première partie, les deux ne sont donc pas mutuellement exclusifs.

LLaMA-Factory : la vitesse par délégation

LLaMA-Factory n’écrit pas ses propres kernels. Il expose plutôt les optimisations d’autres frameworks au moyen d’options de configuration. Définir use_unsloth: true active le patch Unsloth, le journal des changements du projet faisant état d’une vitesse relative de 170 % par cette voie. L’entraînement de longues séquences avec Unsloth est indiqué à 117 % de vitesse et 50 % de mémoire. LLaMA-Factory prend également en charge enable_liger_kernel: true et FlashAttention-2 via flash_attn: fa2.

VRAM

Seuils de mémoire rapportés

Unsloth publie un tableau des exigences en VRAM trié par nombre de paramètres. Il indique 6 GB pour un modèle 8B en QLoRA 4-bit et 41 GB pour 70B. LoRA en 16-bit coûte respectivement 22 GB et 164 GB pour les mêmes modèles.

Le tableau matériel du README de LLaMA-Factory couvre le même régime QLoRA 4-bit, avec 6 GB à 7B, 24 GB à 30B et 48 GB à 70B. Le fine-tuning complet bf16 de 70B est indiqué à 600 GB.

Les deux tableaux décrivent des minimums. La taille de batch, la longueur de séquence et le choix de l’optimiseur affectent tous la consommation réelle.

La longueur de contexte comme différenciateur plus net

La VRAM maximale à longueur de contexte fixe importe moins que le contexte maximal qu’un budget VRAM donné permet. Les benchmarks de longueur de contexte d’Unsloth pour Llama 3.1 8B QLoRA au rang 32 et avec une taille de batch de 1 sont frappants. Unsloth l’attribue à son algorithme de gradient checkpointing combiné à Cut Cross Entropy d’Apple. Pour Llama 3.3 70B sur un A100 de 80 GB, il indique 89,389 tokens — contre 6,916 pour la baseline FA2.

Le cas mémoire des MoE

L’entraînement MoE est le domaine où le comportement mémoire a le plus évolué en 2026. Unsloth indique un fine-tuning de gpt-oss-20b dans 12.8 GB, tandis que Qwen3-30B-A3B en LoRA 16-bit exige 63 GB.

Lors de son exécution gpt-oss sur B200, Unsloth utilisait 47.43 GB à un contexte 8K, contre 73.80 GB pour Transformers v5. À 16K, Transformers v5 a manqué de mémoire tandis qu’Unsloth utilisait 55.13 GB.

Le mécanisme est une formulation split-LoRA. PEFT matérialise le delta LoRA sur tous les experts avant la multiplication matricielle MoE. Unsloth réordonne plutôt les opérations, ce qui est mathématiquement identique mais évite l’étape de matérialisation.

Axolotl traite le même problème via la quantification des experts MoE, en quantifiant les poids des experts au chargement du modèle et en libérant immédiatement le tenseur bf16 original. Cela est devenu nécessaire après un changement dans Transformers v5 qui a déplacé les couches expertes de nn.Linear vers des tenseurs 3D nn.Parameter fusionnés, empêchant bitsandbytes de les quantifier au chargement. La documentation d’Axolotl indique que GLM-4.7-Flash QLoRA passe d’environ 127 GiB à environ 23 GiB de mémoire réservée avec quantize_moe_experts: true.

Multi-GPU

Le multi-GPU est le domaine où le classement sur un seul GPU s’inverse. L’avance d’Unsloth sur un seul GPU ne se transpose pas.

Axolotl : la matrice de parallélisme la plus profonde

Le guide multi-GPU d’Axolotl propose trois stratégies de sharding mutuellement exclusives : DeepSpeed ZeRO stages 1 à 3, FSDP et DDP. FSDP2 est la voie recommandée, FSDP1 étant déprécié.

En plus de celles-ci, son guide de parallélisme N-D compose le parallélisme de données, de tenseurs, de contexte et d’experts via DeviceMesh de PyTorch. La matrice de prise en charge documentée confirme FSDP+TP, HSDP+TP, FSDP+CP, FSDP+TP+CP et FSDP+EP. Deux combinaisons sont explicitement non prises en charge : le parallélisme d’experts ne peut pas se composer avec TP ou CP en v1, et le DDP pur ne peut pas non plus se composer avec eux.

Le parallélisme de séquence d’Axolotl utilise la bibliothèque ring-flash-attention. Son benchmark H100 publié pour Llama 3.1 8B QLoRA illustre le compromis : le contexte augmente presque linéairement, mais l’efficacité du débit s’effondre. Sur des 4090 avec un degré SP de 8, le même benchmark enregistre une accélération de 0.88x — l’entraînement est en fait devenu plus lent alors que le contexte atteignait 32,768 tokens.

Axolotl prend également en charge l’entraînement multi-nœud via torchrun et Ray.

TRL : deux backends de découpage de séquence

Le guide d’entraînement distribué de TRL distingue clairement deux approches. Le parallélisme de contexte utilise Ring Attention sur FSDP2, nécessite Accelerate 1.11.0+, utilise cp_size avec cp_backend="torch" et ne prend actuellement en charge que SDPA — FlashAttention n’est pas pris en charge sur cette voie. Les séquences doivent être divisibles exactement par cp_size * 2.

Le parallélisme de séquence utilise ALST/Ulysses sur DeepSpeed, nécessite DeepSpeed 0.18.1+ et Accelerate 1.12.0+. Il utilise sp_size avec sp_backend="deepspeed" et fonctionne avec FlashAttention-2, mais il est limité par le nombre de têtes d’attention, exigeant num_heads >= sp_size.

Les recommandations de TRL sont précises : Ring Attention convient aux séquences de 1M+ tokens et aux topologies réseau limitées, tandis qu’Ulysses convient aux interconnexions NVLink ou InfiniBand et aux séquences allant jusqu’à environ 500k tokens. Le propre benchmark Ring Attention de TRL a fine-tuné Qwen3-8B sur 1, 2, 4 et 8 GPU H100, avec des longueurs de contexte supérieures à 300k tokens devenant entraînables à 8 GPU.

LLaMA-Factory : moteurs standards avec Megatron

La documentation d’entraînement distribué de LLaMA-Factory couvre DDP, DeepSpeed et FSDP, y compris FSDP2 et Ray pour les exécutions mono-nœud et multi-nœuds. La documentation décrit également DeepSpeed AutoTP, qui combine le parallélisme de tenseurs avec ZeRO.

Son ajout le plus important en 2025 a été un backend d’entraînement Megatron-core via mcore_adapter, ouvrant une véritable voie de préentraînement à grande échelle. Le chemin FSDP+QLoRA permet de fine-tuner un modèle 70B sur deux GPU de 24 GB — la voie documentée la moins coûteuse vers 70B dans cette comparaison.

Le point de friction est l’interface elle-même. La configuration distribuée réside dans YAML et la CLI, pas dans LlamaBoard. Les équipes qui ont adopté LLaMA-Factory pour son interface sans code perdent cette propriété lorsqu’elles dépassent un GPU.

Unsloth : l’écart encore ouvert

La documentation multi-GPU d’Unsloth indique que le multi-GPU fonctionne via Accelerate et DeepSpeed, donnant accès à FSDP et DDP. Toutefois, elle précise aussi que le processus est complexe et nécessite une configuration manuelle, le support officiel étant encore en cours d’annonce. La voie pratique est accelerate launch train.py ou torchrun --nproc_per_node N_GPUS train.py. Pour les modèles trop grands pour un seul GPU, device_map = "balanced" répartit le modèle entre les appareils.

La fiche PyPI d’Unsloth indique que le multi-GPU est disponible, avec des améliorations majeures en attente. Le journal des changements de Studio décrit une allocation multi-GPU automatique préliminaire pour l’inférence et l’entraînement depuis mars 2026.

Pris ensemble, le constat est clair : Unsloth prend en charge le multi-GPU, mais ne propose pas encore la matrice de parallélisme composable documentée par Axolotl et TRL.

Limites de chaque framework

Unsloth atteint ses limites lorsque le parallélisme de tenseurs, de contexte ou d’experts doit être une configuration de premier ordre. Il atteint aussi ses limites lorsqu’un modèle n’est pas dans sa liste prise en charge, car les gains proviennent de kernels spécifiques à l’architecture.

Axolotl est limité par sa courbe d’apprentissage. Les utilisateurs doivent configurer FSDP2 par rapport à DeepSpeed, le degré SP et des contraintes de divisibilité couvrant le nombre de GPU, la longueur de séquence et les têtes d’attention.

TRL est limité par ses paramètres par défaut. Il fournit des primitives correctes plutôt que des configurations optimisées — les utilisateurs doivent fournir la configuration Accelerate, les optimisations mémoire et le plan de parallélisme.

LLaMA-Factory atteint ses limites à la frontière de l’interface utilisateur. Son abstraction est efficace jusqu’à un nœud, mais devient plus légère au-delà.

Recommandations pratiques

Pour un seul GPU grand public avec une architecture prise en charge exécutant LoRA ou QLoRA, Unsloth est le choix le plus solide — la marge sur la longueur de contexte suffit à elle seule à le justifier.

Pour deux à huit GPU avec un long contexte et des pipelines de fine-tuning complet ou de RLHF, Axolotl est recommandé. FSDP2 plus le parallélisme de séquence constitue la voie la mieux documentée.

Pour des boucles d’entraînement personnalisées, de nouveaux algorithmes de post-entraînement ou une intégration étroite avec Hugging Face, TRL est la base sur laquelle construire, car c’est la couche que les autres encapsulent.

Pour la couverture de modèles la plus large, des opérateurs non ingénieurs et les exécutions initiales les plus rapides, LLaMA-Factory est optimal — avec un passage à la CLI lors de la montée en charge.

Ces choix ne sont pas mutuellement exclusifs. LLaMA-Factory peut exécuter Unsloth comme backend. TRL fournit une intégration Unsloth. Axolotl appelle les entraîneurs TRL en interne. Les frameworks convergent visiblement vers les forces des autres — Unsloth ajoutant le multi-GPU, LLaMA-Factory ajoutant Megatron, Axolotl adoptant des optimisations au niveau des kernels — ce qui suggère qu’au prochain cycle, la différenciation pourrait se déplacer de la performance brute vers l’ergonomie développeur et l’étendue des intégrations.

Source : MarkTechPost