💎Affinez les modèles MoE 12x plus rapidement avec Unsloth

Entraînez des MoE LLM localement en utilisant le guide Unsloth.

Nous introduisons un entraînement Mixture of Experts (MoE) LLM environ 12x plus rapide avec >35% de VRAM en moins et ~6x de contexte plus long avec nos nouveaux noyaux 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 incluant gpt-oss, Qwen3 (30B, 235B, VL, Coder), DeepSeek R1, V3 et GLM (4.6, 4.7, Flash).

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

• Nos noyaux fonctionnent à la fois sur les centres de données (B200, H100), grand public et les GPU plus anciens (par ex., RTX 3090), ainsi que FFT, LoRA et QLoRA.

En collaboration avec 🤗Hugging Face, nous avons normalisé toutes les exécutions d'entraînement MoE avec le nouveau torch._grouped_mm de PyTorch. Transformers v5 a récemment été optimisé avec un MoE environ 6x plus rapide que la v4 et Unsloth pousse cela encore plus loin avec des noyaux regroupés‑GEMM Triton + LoRA personnalisés pour un supplémentaire gain de vitesse d'environ 2x, >35% de réduction de VRAM et >6x de contexte plus long (12-30x d'accélération globale vs v4).

Essayez nos notebooks Unsloth pour un 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)

🦥 Noyaux Triton MoE Unsloth

Aux côtés de torch._grouped_mm (voir Faster MoE Training), nous avons créé des noyaux 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 l'A100, et des versions plus anciennes de PyTorch.

Sur A100, nos noyaux Triton sont ~2,5× plus rapides que torch._grouped_mm. Les noyaux comportent également une étape d'autotune une seule fois pour choisir la meilleure configuration du noyau.

L'auto‑optimisation 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 vs _grouped_mm, ce qui en vaut la peine pour les exécutions longues.

Plus le modèle est grand et plus le contexte est long, plus les économies de mémoire de nos noyaux Unsloth seront prononcées (l'efficacité augmentera de façon exponentielle).

🧭 Sélection automatique du backend

Notre principale innovation est notre approche Split LoRA pour un MoE efficace, qui utilise ~35% moins de mémoire et est 2x plus rapide à l'entraînement comparé à Transformers v5 + torch._grouped_mm. Personnalisé torch._grouped_mm + nos noyaux 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 l'affinage complet.

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

Backend	Optimisations
grouped_mm	torch._grouped_mm - disponible des T4 jusqu'aux B200, mais optimisé pour les H100 et plus.
unsloth_triton	Noyaux Triton Unsloth - qui s'activeront automatiquement pour les A100, et les versions plus anciennes de PyTorch.
native_torch	PyTorch natif. C'est 12x plus lent, mais nos réductions de VRAM restent présentes !

Vous pouvez aussi 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 comme une ModuleList de couches linéaires par expert. La seule façon pratique d'exécuter un passage avant était 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épondre exactement à ce goulet d'étranglement. En parallèle, nous fournissons nos propres noyaux Triton optimisés pour MoE. Cela s'aligne également sur un changement clé de Transformers : à partir de Transformers v5, les poids des experts sont stockés comme un unique nn.Parameter, faisant de 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 style : transformers 5.0.0

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 le support est largement disponible.

Nous avons également précédemment introduit Unsloth et notre fonctionnalité Standby dans pour gpt-oss, et ces optimisations devraient le rendre encore plus efficace.

📊 Résultats des noyaux + Benchmarks

Ci‑dessous se trouve une comparaison des longueurs de séquence pour la vitesse d'entraînement et l'utilisation mémoire par rapport à Transformers v5 (qui utilise déjà torch._grouped_mm pour MoE). Pour l'entraînement gpt-oss BF16 MoE, 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 affiné 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 tandis qu'Unsloth non. De plus, l'accélération augmente avec la longueur de séquence dans ce cas grâce à notre Long Context gpt-oss, et nos noyaux MoE.

Comparaison avec transformers v4

Longueur de contexte	Unsloth (ms)	TF v5 (ms)	Mémoire Unsloth (GB)	Mémoire TF v5 (GB)	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% d'efficacité mémoire en plus avec Qwen3-30B-A3B LoRA, les économies de mémoire s'améliorant encore à des longueurs de séquence plus longues.

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

Sur GPU H100, nous performons significativement mieux que la référence atteignant jusqu'à 1,77x d'accélération à l'entraînement tout en économisant ~5,3 Go lors de l'affinage à une longueur de contexte de 4K. Alors que nous nous étendons sans problème jusqu'à 8192 longueurs de contexte, Transformers v5 + TRL provoque un OOM à 8K. Notez que nous utilisons moins de mémoire à 8K que la référence à 4K, donc nous pouvons continuer à augmenter la longueur du contexte.

Longueur de contexte	Unsloth (ms)	TF v5 (ms)	Mémoire Unsloth (GB)	Mémoire TF v5 (GB)	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 lot pour GLM 4.7 Flash. GLM 4.7 Flash est un MoE 30B (3B de paramètres actifs) modèle agentif & de codage et emploie une configuration similaire au style MoE DeepSeek, avec 64 experts routés et 1 expert partagé. Nous avons comparé l'entraînement MoE d'Unsloth à celui du nouveau Transformers v5 optimisé.

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

Google Colabcolab.research.google.com

Notebook GLM 4.7 Flash MoE A100 80GB

Longueur de contexte	Unsloth (ms)	TF v5 (ms)	Mémoire Unsloth (GB)	Mémoire TF v5 (GB)	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 est de fusionner l'adaptateur LoRA dans le poids de base puis d'exécuter le calcul MoE (surtout puisque MoE utilise souvent nn.Parameter au lieu de nn.Linear). Le problème est que cette fusion matérialise effectivement 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 d'importants gains de vitesse 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 l'affinage complet.

Ces optimisations sont activées par défaut lors de l'entraînement des 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 UNSLOTH_MOE_BACKEND variable d'environnement : soit torch._grouped_mm Noyaux Triton ou une boucle for PyTorch basique, selon la compatibilité et la préférence. Nous utilisons par défaut grouped_mm pour la meilleure performance et un large support.

import os
# si vous voulez choisir un backend différent (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, # Le 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 la mémoire
    random_state = 3407,
)

📚 Détails de l'implémentation

LoRA est une méthode d'affinage efficace en paramètres : au lieu de mettre à jour la matrice de poids complète, vous entraînez un « adaptateur » de faible rang avec beaucoup moins de paramètres, ce qui réduit drastiquement la mémoire de l'optimiseur.

Si le poids original a la 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 que les états de l'optimiseur et les gradients pour :

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

• m*n paramètres (affinage complet)

Pour l'affinage des MoE - ce n'est pas une bonne idée d'affiner la couche de routage, donc nous l'avons désactivée par défaut.

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

MoE LoRA change la donne

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

Prenez 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 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 central est que r/n = 64/768 est élevé comparé aux configurations MLP typiques, par exemple, r/n = 64/25600 dans Qwen3-32B d'une taille similaire.

Si vous matérialisez cela sur tous experts, la mémoire s'accumule rapidement. Et puisque gate_proj et up_proj sont souvent fusionnés en tant que gate_up_proj, vous matérialisez typiquement les deux ensemble, doublant grossièrement la surcharge/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 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 creux pour k experts = ksr paramètres
Y @ loraB: (s, r) @ (r, n)           # mais à nouveau creux pour k experts = ksn paramètres

Maintenant prenons le cas de Qwen3-30B-A3B.

E = 128, k = 8, m = 2048, n = 768. En remplaçant tout cela, nous obtenons 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 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'auquel le Split LoRA d'un point de vue analytique est meilleur est lorsque s > Emn/k(m+n) qui est de l'ordre de 16K jetons pour un modèle de style Qwen3-30B-A3B.

Enfin, certaines accélérations proviennent de 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 plus que les FLOPs. Une estimation grossière de l'accélération est Emn / [k·s·(m+n)], donc cela dépend fortement de s, E, k, et des formes des matrices.

🔮 Support de modèles

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

• Qwen3 (Thinking and 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échargé certains modèles MoE, mais Unsloth devrait toujours les prendre en charge.

📈 Plus de benchmarks

Benchmarks gpt-oss BF16

Vitesse d'entraînement incluant vs 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 VRAM mémoire

Longueur de contexte	Mémoire Unsloth (GB)	Mémoire TF v5 (GB)	TF v4 Mem (GB)	É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 Gemma-3 utilise maintenant Flex-Attention par défaut, et cela fonctionne également en float16 (il y avait des infinis que nous avons résolus il y a un certain temps). Gemma-3 utilise maintenant une mémoire O(N) et non O(N^2), et s'entraîne >3x plus vite (s'optimise encore mieux avec la longueur du contexte). Les versions précédentes d'Unsloth faisaient OOM.

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

1. L'adaptation fine pour la vision accepte désormais des données mixtes composées uniquement d'images et de textes !

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 nos 120 notebooks, mais maintenant nous avons >80% de couverture - nous prévoyons d'atteindre 100% dans les prochains jours.

4. De nombreuses corrections 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 à l'amélioration de l'entraînement MoE pour la communauté.

Nous remercions également sincèrement l'équipe torchao, en particulier Vasily Kuznetsov (vkuzo) pour son aide à activer le support grouped_mm pour float16 afin de le faire fonctionner sur T4 et assurer la compatibilité rétroactive avec A100.