💎Fine-tunez les modèles MoE 12x plus vite avec Unsloth

Entraînez localement des LLM MoE à l'aide du guide Unsloth.

Nous introduisons un entraînement LLM Mixture of Experts (MoE) ~12x plus rapide avec >35 % de VRAM en moins et un contexte ~6x plus long grâce à nos nouveaux kernels MoE Triton et à de nouvelles optimisations mathématiques, le tout sans perte de précision.

• Unsloth prend désormais en charge l’entraînement rapide pour les architectures MoE, notamment gpt-oss, Qwen3 (30B, 235B, VL, Coder), DeepSeek R1, V3 et GLM (4.6, 4.7, Flash).

• les fine-tunes gpt-oss-20b en 12,8 Go de VRAM. Qwen3-30B-A3B (LoRA 16 bits) utilise 63 Go.

• Nos kernels fonctionnent aussi bien sur les GPU de centre de données (B200, H100), grand public et plus anciens (par ex. RTX 3090), ainsi qu’avec FFT, LoRA et QLoRA.

En collaboration avec 🤗Hugging Face, nous avons standardisé toutes les exécutions d’entraînement MoE avec la nouvelle fonction torch._grouped_mm de PyTorch. Transformers v5 a récemment été optimisé avec un MoE ~6x plus rapide que v4, et Unsloth pousse cela encore plus loin avec des kernels Triton groupés GEMM + LoRA personnalisés pour une amélioration supplémentaire d’environ ~2x, une réduction de >35 % de la VRAM et un contexte >6x plus long (accélération globale de 12-30x par rapport à v4).

Essayez nos notebooks Unsloth pour l’entraînement MoE rapide :

gpt-oss (20b) (gratuit)	Qwen3-30B-A3B (A100)	GLM-4.7-Flash (A100)
gpt-oss-120b (A100)	gpt-oss (contexte 500K)	TinyQwen3 MoE (test uniquement)

🦥 Kernels MoE Triton d’Unsloth

En plus de torch._grouped_mm (voir Faster MoE Training), nous avons créé des kernels Triton MoE personnalisés qui peuvent être encore plus rapides dans certains cas. Ils sont également rétrocompatibles avec du matériel plus ancien comme A100, ainsi qu’avec des versions plus anciennes de PyTorch.

Sur A100, nos kernels Triton sont ~2,5× plus rapides que torch._grouped_mm. Les kernels ont également une étape d’auto-ajustement unique pour choisir la meilleure configuration de kernel.

L’auto-ajustement prend ~2 minutes une fois au début de l’entraînement, mais peut accélérer l’exécution complète de 35 % sur A100 par rapport à _grouped_mm, ce qui en vaut largement la peine pour les exécutions longues.

Plus le modèle est grand et plus vous utilisez de contexte, plus les économies de mémoire apportées par nos kernels Unsloth seront importantes (l’efficacité évoluera de manière exponentielle).

🧭 Sélection automatique du backend

Notre principale innovation est notre approche Split LoRA pour un MoE efficace, qui utilise ~35 % de mémoire en moins et permet un entraînement 2x plus rapide par rapport à Transformers v5 + torch._grouped_mm. Custom torch._grouped_mm + nos kernels Triton sont ~12-30x plus rapides que Transformers v4.

Entraîner des modèles MoE en 4 bits QLoRA n’est pas recommandé pour le moment car BitsandBytes ne le prend pas en charge. Ce n’est pas spécifique à Unsloth. Pour l’instant, utilisez bf16 pour LoRA ou le fine-tuning complet.

Unsloth sélectionnera automatiquement l’un des backends suivants en fonction de votre matériel :

Backend	Optimisations
grouped_mm	torch._grouped_mm - disponible sur les T4 jusqu’aux B200, mais optimisé pour les H100+.
unsloth_triton	Kernels Triton d’Unsloth - qui s’activeront automatiquement pour les A100, ainsi que pour les versions plus anciennes de PyTorch.
native_torch	PyTorch natif. C’est 12x plus lent, mais nos réductions de VRAM sont toujours là !

Vous pouvez également les basculer vous-même :

os.environ["UNSLOTH_MOE_BACKEND"] = "grouped_mm"
os.environ["UNSLOTH_MOE_BACKEND"] = "unsloth_triton"
os.environ["UNSLOTH_MOE_BACKEND"] = "native_torch"

Pour activer un entraînement MoE plus rapide, mettez à jour Unsloth via pip install --upgrade unsloth unsloth_zoo

❓Qu’est-ce que torch._grouped_mm ?

Auparavant, les poids Mixture-of-Experts (MoE) étaient stockés sous forme de ModuleList de couches linéaires par expert. La seule manière pratique d’exécuter un passage avant consistait à faire une boucle for sur les experts, ce qui est coûteux et sous-optimal.

for expert_idx in expert_hit:
    expert_idx = expert_idx[0]
    if expert_idx == num_experts: continue
    _, token_idx = torch.where(expert_mask[expert_idx])
    current_state = hidden_states[token_idx]
    gate, up = nn.functional.linear(current_state, self.gate_up_proj[expert_idx]).chunk(2, dim=-1)

PyTorch a récemment introduit grouped_mm pour résoudre précisément ce goulot d’étranglement. En parallèle, nous fournissons nos propres kernels Triton optimisés pour MoE. Cela s’aligne aussi avec un changement clé de Transformers : à partir de Transformers v5, les poids d’experts sont stockés comme un seul nn.Parameter, ce qui en fait grouped_mm un choix naturel pour un entraînement et une inférence MoE plus rapides.

Donc transformers 4.57.6 a changé :

self.experts = nn.ModuleList(
    [Qwen3MoeMLP(config, intermediate_size) for _ in range(self.num_experts)]
)

en transformers 5.0.0 style :

self.gate_up_proj = nn.Parameter(torch.empty(num_experts, 2 * intermediate_dim, hidden_dim))

torch._grouped_mm fonctionne sur les GPU à partir du NVIDIA T4, et nous l’avons vérifié sur H100, A100, B200 et RTX 6000 Pro, donc la prise en charge est largement disponible.

Nous avions également précédemment introduit Unsloth Flex Attention pour gpt-oss, et ces optimisations devraient le rendre encore plus efficace.

📊 Résultats des kernels + benchmarks

Ci-dessous figure une comparaison selon la longueur de séquence pour la vitesse d’entraînement et l’utilisation de mémoire par rapport à Transformers v5 (qui utilise déjà torch._grouped_mm pour MoE). Pour l’entraînement MoE BF16 de gpt-oss, nous observons un entraînement 7x plus rapide et une réduction de 36 % de la VRAM sur NVIDIA B200. Pour Qwen3-30B-A3B, c’est 1,8x plus rapide, et GLM 4.7 Flash est 2,1x plus rapide sur RTX PRO 6000. Tous les benchmarks sont réalisés avec un rang LoRA = 64 et tous les modules LoRA sur les couches MoE (gate, up, down).

Benchmarks gpt-oss

Nous avons fine-tuné unsloth/gpt-oss-20b-BF16 pour les benchmarks. Unsloth est 7x plus rapide et utilise 36 % de VRAM en moins à des longueurs de contexte de 16K. Transformers v5 + TRL manque de mémoire alors qu’Unsloth non. De plus, ici, l’accélération augmente avec la longueur de séquence grâce à notre Long Context gpt-oss, et à nos kernels MoE.

Comparaison avec transformers v4

Longueur de contexte	Unsloth (ms)	TF v5 (ms)	Mémoire Unsloth (Go)	Mémoire TF v5 (Go)	Accélération	Économie de VRAM
1024	275.35	376.99	40.91	43.88	1,4x	6.76%
2048	292.88	696.57	41.83	44.93	2,4x	6.89%
4096	370.30	1785.89	43.68	49.86	4,8x	12.39%
8192	712.33	5226.86	47.43	73.80	7,3x	35.73%
16384	1775.80	OOM	55.13	OOM	N/A	N/A

Benchmarks Qwen3

Sur un NVIDIA B200, nous observons ~1,7x d’accélération et ~35 % de meilleure efficacité mémoire avec Qwen3-30B-A3B LoRA, avec des économies de mémoire qui s’améliorent encore aux longues séquences.

Qwen3-Next et Coder tiennent étonnamment sur un seul GPU B200 en bf16 LoRA.

Sur un GPU H100, nous faisons nettement mieux que la base, avec jusqu’à 1,77x d’accélération à l’entraînement tout en économisant ~5,3 Go lors du fine-tuning à une longueur de contexte de 4K. Alors que nous montons sans problème jusqu’à 8192 longueurs de contexte, Transformers v5 + TRL atteint un OOM à 8K. Notez que nous utilisons moins de mémoire à 8K que la base à 4K, ce qui nous permet de continuer à pousser la longueur de contexte plus loin.

Longueur de contexte	Unsloth (ms)	TF v5 (ms)	Mémoire Unsloth (Go)	Mémoire TF v5 (Go)	Accélération	Économie de VRAM
1024	366.3	628.3	80.88	104.80	1,7x	2.06%
2048	467.0	745.3	80.88	104.81	1,6x	2.57%
4096	711.6	975.5	80.89	104.80	1,4x	5.08%
8192	1376.6	1633.5	80.90	104.81	1,2x	9.17%
16384	3182.2	3407.9	85.53	116.61	1,1x	15.26%

Benchmarks GLM 4.7

Unsloth atteint un débit 2,6x plus rapide avec >15 % de VRAM en moins sur toutes les tailles de batch pour GLM 4.7 Flash. GLM 4.7 Flash est un modèle agentique et de codage MoE de 30B (3B de paramètres actifs) et emploie une configuration similaire au style MoE DeepSeek, avec 64 experts routés et 1 expert partagé. Nous avons benchmarké l’entraînement MoE d’Unsloth par rapport au nouveau Transformers v5 optimisé.

Utilisez ci-dessous notre nouveau notebook Colab pour GLM 4.7 Flash :

Google Colabcolab.research.google.com

Notebook MoE GLM 4.7 Flash A100 80 Go

Longueur de contexte	Unsloth (ms)	TF v5 (ms)	Mémoire Unsloth (Go)	Mémoire TF v5 (Go)	Accélération	Économie de VRAM
512	1145.0	2992.1	57.81	60.89	2,6x	6.51%
1024	1298.9	3323.3	58.76	62.55	2,6x	6.22%
2048	1831.9	4119.3	60.09	67.32	2,3x	9.46%
4096	2883.9	5646.1	63.34	76.78	2x	14.83%

⚡Entraînement LoRA MoE plus rapide

Dans Transformers/PEFT, l’approche habituelle consiste à fusionner l’adaptateur LoRA dans le poids de base puis à exécuter le calcul MoE (surtout parce que MoE utilise souvent nn.Parameter au lieu de nn.Linear). Le problème est que cette fusion matérialise le delta LoRA (pour tous les experts) lora_B @ lora_A.t, ce qui est très gourmand en mémoire.

Unsloth évite cela. Nous avons auparavant utilisé la même idée pour optimiser l’entraînement et l’inférence LoRA génériques, et nous l’avons maintenant appliquée à MoE + LoRA également. Les mathématiques sont identiques, donc la perte, les gradients et les sorties restent les mêmes. Le seul changement est l’ordre des opérations, rendu possible par l’associativité de la multiplication matricielle. Avec ce réordonnancement, nous obtenons des accélérations majeures et des réductions de mémoire.

Entraîner des modèles MoE en 4 bits QLoRA n’est pas recommandé pour le moment car BitsandBytes ne le prend pas en charge. Ce n’est pas spécifique à Unsloth. Pour l’instant, utilisez bf16 pour LoRA ou le fine-tuning complet.

Ces optimisations sont activées par défaut lors de l’entraînement de modèles MoE avec Unsloth (notamment Qwen-3 MoE, gpt-oss, et les modèles mentionnés ci-dessus). Vous pouvez changer d’implémentation via la variable d’environnement UNSLOTH_MOE_BACKEND : soit torch._grouped_mm les kernels Triton soit une simple boucle for PyTorch, selon la compatibilité et vos préférences. Nous utilisons par défaut grouped_mm pour les meilleures performances et une large compatibilité.

import os
# si vous voulez choisir un autre backend (grouped_mm par défaut), définissez la variable ci-dessous :
# os.environ['UNSLOTH_MOE_BACKEND'] = 'unsloth_triton' # ou grouped_mm ou native_torch
lora_rank = 16
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "Qwen/Qwen3-30B-A3B-Instruct-2507", # modèle MoE
    max_seq_length = max_seq_length,
    load_in_4bit = False, # nn.Parameter MoE ne prend pas encore en charge bnb 4bit
)
model = FastLanguageModel.get_peft_model(
    model,
    r = lora_rank,
    target_modules = [
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_up_proj", "down_proj", # LoRA sur les couches MoE !
    ],
    lora_alpha = lora_rank*2, # *2 accélère l’entraînement
    use_gradient_checkpointing = "unsloth", # réduit l’utilisation de mémoire
    random_state = 3407,
)

📚 Détails de l’implémentation

LoRA est une méthode de fine-tuning efficace en paramètres : au lieu de mettre à jour la matrice de poids complète, on entraîne un « adaptateur » de faible rang avec bien moins de paramètres, ce qui réduit drastiquement la mémoire de l’optimiseur.

Si le poids original a pour forme (m, n), LoRA ajoute deux matrices entraînables de formes (m, r) et (r, n). Leur produit est (m, n), mais vous ne suivez les états de l’optimiseur et les gradients que pour :

• m*r + r*n paramètres (LoRA) au lieu de

• m*n paramètres (fine-tuning complet)

Lors du fine-tuning des MoE, il n’est pas judicieux de fine-tuner la couche router, donc nous l’avons désactivée par défaut.

Pour des couches MLP typiques, m ≈ 4096, n ≈ 12k, et r ≈ 64, cela fait environ ~1M paramètres LoRA contre ~48M paramètres complets - environ ~2%, souvent avec une perte de précision minime, voire nulle.

Le LoRA MoE change la donne

Les couches MoE sont différentes car vous avez E MLP experts en parallèle, donc toute modification par expert (comme l’ajout de LoRA) se répercute sur tous les experts.

Prenons Qwen3‑30B‑A3B: taille cachée m=2048, taille intermédiaire n=768, E=128 experts avec k=8 activés par jeton. Par expert :

• gate_proj et up_proj: (m, n) = (2048, 768)

• down_proj: (n, m) = (768, 2048)

Avec un rang LoRA r=64, chaque projection ajoute r*(m+n)=64*(2048+768)=180,224 paramètres par expert (≈ 11% d’un matrice 2048×768 ). Le problème principal est que r/n = 64/768 est élevé par rapport aux configurations MLP typiques, par exemple r/n = 64/25600 dans Qwen3-32B de taille similaire.

Si vous matérialisez cela sur tous les experts, la mémoire s’accumule rapidement. Et comme gate_proj et up_proj sont souvent fusionnés comme gate_up_proj, vous matérialisez généralement les deux ensemble, ce qui double approximativement la surcharge/le pic de mémoire.

En termes de mémoire, pour une longueur de séquence s, E experts et k choisis, nous avons ce qui suit de commun aux deux approches

# Toutes ces valeurs sont par expert
Sortie finale : (s, n)
Activations d’entrée : (s, m)
Sortie finale : (s, n)

C’est ici que les choses commencent à diverger. Pour l’approche de peft, nous avons

delta = loraA@loraB  = (m,n) par expert = Emn paramètres

Pour l’approche Split LoRA d’Unsloth, nous effectuons les opérations suivantes

Y = X @ loraA : (s,m) @ (m, r)       # mais sparse pour k experts = ksr paramètres
Y @ loraB: (s, r) @ (r, n)           # mais à nouveau sparse pour k experts = ksn paramètres

Prenons maintenant le cas de Qwen3-30B-A3B.

E = 128, k = 8, m = 2048, n = 768. En remplaçant toutes ces valeurs, on obtient s < 32K.

$$\begin{aligned} \text{PEFT params} &:\quad Emn \\ \text{Unsloth Split LoRA params} &:\quad ks(r+n) \\ \text{In typical LoRA we have} &:\quad r \ll n \\ \text{Split LoRA is better when} &:\quad Emn > ksn \;=\; Em > ks \\ \\ \text{For Qwen3-30B-A3B, we have} \\ E &= 128, \quad k = 8, \quad m = 2048, \quad n = 768 \\ \\ \text{So, Split LoRA is mathematically better when} \\ s &< \frac{Emn}{kn} = 32K \end{aligned}$$

En termes de calcul, pour une longueur de séquence s, E experts et top k choisis, nous effectuons :

$$\begin{aligned} \Delta = AB, A \in \mathbb{R}^{m \times r}, \; B \in \mathbb{R}^{r \times n} &\quad \Rightarrow \quad 2mnr \text{ flops per expert lora} \\ \\ W' = W + \Delta \quad &\Rightarrow \quad mn \text{ flops} \\ \\ XW' \quad | \quad X \in \mathbb{R}^{s \times m}, \; W' \in \mathbb{R}^{m \times n} \quad &\Rightarrow \quad 2smn \text{ flops} \\ \\ \text{MoE peft lora flops} &= E\big(2mnr + mn\big) + 2k\,smn \end{aligned}$$

Dans le cas du Split LoRA d’Unsloth que nous avons mentionné, nous avons

$$\begin{aligned} XW &= 2smn \text{ flops} \\ Y = XA, &= 2smr \quad \text{(applied only to routed token--expert pairs)} \\ \ Z = YB &= 2srn \\ \text{MoE split lora flops} &= 2k\big(smn + smr + srn\big) \\ \text{Crossover condition} &:\quad 2ksr(m+n) > 2Emn(r+1/2) \Rightarrow s > \frac{Emn}{k(m+n)} \times (1+ \frac{1}{2r}) \\ \\ \text{For Qwen3-30B-A3B with} &: E = 128,\; m = 2048,\; n = 768,\; k = 8 \\ \\ \Rightarrow \quad s & \;\approx\; 16\text{K tokens} \end{aligned}$$

Le point jusqu’où le Split LoRA est meilleur d’un point de vue analytique est lorsque s > Emn/k(m+n) ce qui est de l’ordre de 16K tokens pour un modèle de type Qwen3-30B-A3B.

Enfin, certaines accélérations viennent de la réduction du trafic mémoire: les GPU modernes sont souvent limités par la bande passante, donc transférer moins de données peut compter davantage que les FLOPs. Une estimation approximative de l’accélération est Emn / [k·s·(m+n)], donc cela dépend fortement de s, E, ket des formes des matrices.

🔮 Prise en charge des modèles

Unsloth prend en charge un entraînement MoE plus rapide pour les modèles Qwen, gpt-oss, DeepSeek et GLM :

• Qwen3 (Thinking et Instruct) : VL • 2507 • Coder

• gpt-oss: 20B • 120B • safeguard

• GLM: 4.5 • 4.6 • 4.6-Air • 4.7 • 4.7-Flash

• DeepSeek: V3 • R1 • V3.1 • V3.2

Il se peut que nous n’ayons pas téléversé certains modèles MoE, mais Unsloth devrait tout de même les prendre en charge.

📈 Davantage de benchmarks

Benchmarks gpt-oss BF16

Vitesse d’entraînement, y compris par rapport à Transformers v4

Longueur de contexte	Unsloth (ms)	TF v5 (ms)	TF v4 (ms)	Accélération
1024	275.35	376.99	2111.18	1,37x
2048	292.88	696.57	2626.80	2,38x
4096	370.30	1785.89	4027.93	4,82x
8192	712.33	5226.86	8513.52	7,34x
16384	1775.80	OOM	OOM	N/A

Utilisation mémoire VRAM

Longueur de contexte	Mémoire Unsloth (Go)	Mémoire TF v5 (Go)	Mémoire TF v4 (Go)	Économie de VRAM
1024	40.91	43.88	89.75	6.76%
2048	41.83	44.93	90.47	6.89%
4096	43.68	49.86	92.72	12.39%
8192	47.43	73.80	100.3	35.73%
16384	55.13	OOM	OOM	N/A

🎉 Mises à jour importantes d’Unsloth

1. Dans le cadre de notre sortie MoE, nous avons également fait en sorte que Gemma-3 utilise désormais Flex-Attention par défaut, et cela fonctionne aussi en float16 (il y avait des infinis que nous avons résolus il y a quelque temps). Gemma-3 utilise désormais une mémoire O(N) et non plus O(N^2), et s’entraîne >3x plus vite (et se met à l’échelle encore mieux avec la longueur de contexte). Les versions précédentes d’Unsloth auraient manqué de mémoire.

Contexte	Pic VRAM ancien	Nouveau pic VRAM	Économie de VRAM
1K	20,1 Go	20,1 Go	0 Go (0 %)
2K	21,5 Go	21,1 Go	0,3 Go (2 %)
4K	27,7 Go	23,3 Go	4,5 Go (16 %)
8K	52,3 Go	27,5 Go	24,8 Go (47 %)
16K	OOM	36,0 Go	--
24K	OOM	44,6 Go	--
32K	OOM	53,1 Go	--
48K	OOM	38,4 Go	--
64K	OOM	44,7 Go	--

1. Le fine-tuning vision accepte désormais des données mixtes composées uniquement d’images et de texte !

2. Windows est désormais officiellement pris en charge sans besoin de WSL.

3. trl==0.27.1 et transformers==5.1.0 sont bien pris en charge - la couverture précédente était de 30 % de tous nos 120 notebooks, mais maintenant nous avons une couverture >80 % - nous prévoyons d’atteindre 100 % dans les prochains jours.

4. De nombreux correctifs de bugs et autres mises à jour - voir https://github.com/unslothai/unsloth/releases/tag/February-2026

Pour activer un entraînement MoE plus rapide, mettez à jour Unsloth via pip install --upgrade unsloth unsloth_zoo

Remerciements

Nous remercions l’équipe Hugging Face pour avoir collaboré avec nous afin d’améliorer l’entraînement MoE pour la communauté.

Nous remercions également sincèrement l’équipe torchao, en particulier Vasily Kuznetsov (vkuzo), pour nous avoir aidés à activer la prise en charge de grouped_mm pour float16 afin de le faire fonctionner sur T4 et assurer la rétrocompatibilité avec A100.