💎MoE-Modelle mit Unsloth 12x schneller feinabstimmen

Trainiere MoE-LLMs lokal mit der Unsloth-Anleitung.

Wir führen ein ~12x schnelleres Training von Mixture of Experts (MoE) LLMs mit >35% weniger VRAM und ~6x längerem Kontext mit unseren neuen MoE-Triton-Kernels und neuen mathematischen Optimierungen ein, alles ohne Genauigkeitsverlust.

• Unsloth unterstützt jetzt schnelles Training für MoE-Architekturen, darunter gpt-oss, Qwen3 (30B, 235B, VL, Coder), DeepSeek R1, V3 und GLM (4.6, 4.7, Flash).

• gpt-oss-20b Fine-Tunes in 12,8 GB VRAM. Qwen3-30B-A3B (16-Bit LoRA) verwendet 63 GB.

• Unsere Kernels funktionieren sowohl auf Rechenzentrums-GPUs (B200, H100), Consumer- als auch auf älteren GPUs (z. B. RTX 3090) und FFT, LoRA und QLoRA.

In Zusammenarbeit mit 🤗Hugging Face haben wir alle MoE-Trainingsläufe mit Pythons neuer torch._grouped_mm Funktion standardisiert. Transformers v5 wurde kürzlich mit ~6x schnellerem MoE als v4 optimiert, und Unsloth geht mit benutzerdefinierten Triton grouped-GEMM + LoRA-Kernels noch weiter für einen zusätzlichen ~2x Speed-up, >35% VRAM-Reduktion und >6x längeren Kontext (12-30x Gesamtspeed-up gegenüber v4).

Probiert unsere Unsloth-Notebooks für schnelles MoE-Training aus:

gpt-oss (20b) (kostenlos)	Qwen3-30B-A3B (A100)	GLM-4.7-Flash (A100)
gpt-oss-120b (A100)	gpt-oss (500K Kontext)	TinyQwen3 MoE (nur Test)

🦥 Unsloth MoE Triton Kernels

Zusammen mit torch._grouped_mm (siehe Faster MoE Training), haben wir benutzerdefinierte Triton-MoE-Kernels erstellt, die in manchen Fällen sogar schneller sein können. Sie sind außerdem abwärtskompatibel mit älterer Hardware wie A100 und älteren PyTorch-Versionen.

Auf A100 sind unsere Triton-Kernels ~2,5× schneller als torch._grouped_mm. Die Kernels haben außerdem einen einmaligen Auto-Tuning-Schritt, um die beste Kernel-Konfiguration auszuwählen.

Das Auto-Tuning dauert zu Beginn des Trainings einmalig ~2 Minuten, kann aber den gesamten Lauf auf A100 gegenüber _grouped_mmum 35% beschleunigen, was sich für längere Läufe durchaus lohnt.

Je größer das Modell und je mehr Kontext ihr verwendet, desto stärker werden die Speichereinsparungen durch unsere Unsloth-Kernels ausfallen (die Effizienz skaliert exponentiell).

🧭 Automatische Backend-Auswahl

Unsere wichtigste Innovation ist unser Split-LoRA-Ansatz für effizientes MoE, der ~35% weniger Speicher benötigt und 2x schneller trainiert als Transformers v5 + torch._grouped_mm. Custom torch._grouped_mm + unsere Triton-Kernels sind ~12-30x schneller als Transformers v4.

MoE-Modelle in 4-Bit QLoRA wird derzeit nicht empfohlen, da BitsandBytes es nicht unterstützt. Das ist nicht spezifisch für Unsloth. Verwendet vorerst bf16 für LoRA oder vollständiges Fine-Tuning.

Unsloth wählt je nach eurer Hardware automatisch einen der folgenden Backends aus:

Backend	Optimierungen
grouped_mm	torch._grouped_mm - verfügbar von T4s bis hin zu B200s, aber für H100s+ optimiert.
unsloth_triton	Unsloth Triton-Kernels - sie werden automatisch für A100s und ältere PyTorch-Versionen aktiviert.
native_torch	Natives PyTorch. Es ist 12x langsamer, aber unsere VRAM-Reduktionen bleiben erhalten!

Ihr könnt sie auch selbst umschalten:

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

Um schnelleres MoE-Training zu aktivieren, aktualisiert Unsloth über pip install --upgrade unsloth unsloth_zoo

❓Was ist torch._grouped_mm?

Zuvor wurden Mixture-of-Experts-(MoE)-Gewichte als ModuleList aus linearen Schichten pro Experte gespeichert. Die einzige praktikable Möglichkeit für einen Forward Pass war eine for-Schleife über die Experten, was teuer und suboptimal ist.

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 hat kürzlich grouped_mm eingeführt, um genau diesen Engpass zu beheben. Parallel dazu bieten wir unsere eigenen MoE-optimierten Triton-Kernels an. Das passt auch zu einer wichtigen Transformers-Änderung: Seit Transformers v5 werden Expertengewichte als ein einzelner nn.Parametergespeichert, was grouped_mm zu einer natürlichen Wahl für schnelleres MoE-Training und Inferenz macht.

Also transformers 4.57.6 änderte sich:

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

zu transformers 5.0.0 Stil:

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

torch._grouped_mm funktioniert auf GPUs ab der NVIDIA T4, und wir haben es auf H100, A100, B200 und RTX 6000 Pro überprüft, sodass die Unterstützung breit verfügbar ist.

Wir haben außerdem bereits Unsloth Flex Attention für gpt-oss eingeführt, und diese Optimierungen sollten es noch effizienter machen.

📊 Kernel-Ergebnisse + Benchmarks

Unten ist ein Vergleich über Sequenzlängen hinweg für Trainingsgeschwindigkeit und Speichernutzung gegenüber Transformers v5 (das bereits torch._grouped_mm für MoE verwendet). Für gpt-oss BF16 MoE-Training sehen wir auf NVIDIA B200 ein 7x schnelleres Training und 36% weniger VRAM auf NVIDIA B200. Für Qwen3-30B-A3B ist es 1,8x schneller, und GLM 4.7 Flash ist auf RTX PRO 6000 2,1x schneller. Alle Benchmarks wurden mit LoRA-Rang = 64 und allen LoRA-Modulen auf MoE-Schichten (gate, up, down) durchgeführt.

gpt-oss Benchmarks

Wir haben unsloth/gpt-oss-20b-BF16 für das Benchmarking feinabgestimmt. Unsloth ist 7x schneller und verwendet bei 16K Kontextlängen 36% weniger VRAM. Transformers v5 + TRL läuft in den Speicherüberlauf, während das bei Unsloth nicht der Fall ist. Außerdem steigt die Beschleunigung in diesem Fall mit der Sequenzlänge dank unserer Long Context gpt-ossund unserer MoE-Kernels.

Vergleich mit transformers v4

Kontextlänge	Unsloth (ms)	TF v5 (ms)	Unsloth-Speicher (GB)	TF v5-Speicher (GB)	Beschleunigung	VRAM-Ersparnis
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

Qwen3 Benchmarks

Auf einem NVIDIA B200sehen wir ~1,7x Speed-up und ~35% bessere Speichereffizienz mit Qwen3-30B-A3B LoRA, wobei sich die Speichereinsparungen bei längeren Sequenzlängen weiter verbessern.

Qwen3-Next und Coder passen überraschenderweise als bf16 LoRA auf eine einzelne B200-GPU.

Auf einer H100-GPU schneiden wir deutlich besser als die Baseline ab und erreichen bis zu 1,77x Speed-up beim Training und sparen außerdem ~5,3 GB beim Fine-Tuning mit 4K Kontextlänge. Während wir nahtlos auf 8192 Kontextlängen skalieren, läuft Transformers v5 + TRL bei 8K in OOM. Beachtet, dass wir bei 8K weniger Speicher verwenden als die Baseline bei 4K, sodass wir die Kontextlänge weiter erhöhen können.

Kontextlänge	Unsloth (ms)	TF v5 (ms)	Unsloth-Speicher (GB)	TF v5-Speicher (GB)	Beschleunigung	VRAM-Ersparnis
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%

GLM 4.7 Benchmarks

Unsloth erreicht 2,6x höheren Durchsatz bei >15% weniger VRAM über alle Batchgrößen hinweg für GLM 4.7 Flash. GLM 4.7 Flash ist ein 30B-MoE-Modell (3B aktive Parameter) für Agenten- und Coding-Aufgaben und verwendet eine Konfiguration ähnlich dem DeepSeek-MoE-Stil mit 64 gerouteten Experten und 1 gemeinsamem Experten. Wir haben Unsloth MoE-Training gegen das neue optimierte Transformers v5 benchmarkiert.

Verwendet unten unser neues Colab-Notebook für GLM 4.7 Flash:

Google Colabcolab.research.google.com

GLM 4.7 Flash MoE Notebook A100 80GB

Kontextlänge	Unsloth (ms)	TF v5 (ms)	Unsloth-Speicher (GB)	TF v5-Speicher (GB)	Beschleunigung	VRAM-Ersparnis
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%

⚡Schnelleres LoRA-MoE-Training

In Transformers/PEFT ist der übliche Ansatz, den LoRA-Adapter in das Basisgewicht zu integrieren und dann die MoE-Berechnung auszuführen (insbesondere, da MoE oft nn.Parameter anstelle von nn.Linearverwendet). Das Problem ist, dass dieses Zusammenführen effektiv das LoRA-Delta für alle Experten materialisiert lora_B @ lora_A.t, was sehr speicherintensiv ist.

Unsloth vermeidet das. Wir haben zuvor dieselbe Idee verwendet, um generisches LoRA-Training und -Inference zu optimieren, und wir haben sie nun auch auf MoE + LoRA angewendet. Die Mathematik ist identisch, also bleiben Verlust, Gradienten und Ausgaben gleich. Die einzige Änderung ist die Reihenfolge der Operationen, ermöglicht durch die Assoziativität der Matrixmultiplikation. Mit dieser Umordnung erhalten wir deutliche Geschwindigkeitssteigerungen und Speicherreduktionen.

MoE-Modelle in 4-Bit QLoRA wird derzeit nicht empfohlen, da BitsandBytes es nicht unterstützt. Das ist nicht spezifisch für Unsloth. Verwendet vorerst bf16 für LoRA oder vollständiges Fine-Tuning.

Diese Optimierungen sind standardmäßig aktiviert wenn MoE-Modelle mit Unsloth trainiert werden (insbesondere Qwen-3 MoE, gpt-oss und die oben genannten Modelle). Ihr könnt Implementierungen über die UNSLOTH_MOE_BACKEND Umgebungsvariable umschalten: entweder torch._grouped_mm Triton-Kernels oder eine einfache PyTorch-for-Schleife, je nach Kompatibilität und Präferenz. Standardmäßig verwenden wir grouped_mm für die beste Leistung und breite Unterstützung.

import os
# wenn ihr ein anderes Backend wählen wollt (grouped_mm ist standardmäßig), setzt die folgende Variable:
# os.environ['UNSLOTH_MOE_BACKEND'] = 'unsloth_triton' # oder grouped_mm oder native_torch
lora_rank = 16
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "Qwen/Qwen3-30B-A3B-Instruct-2507", #MoE-Modell
    max_seq_length = max_seq_length,
    load_in_4bit = False, # MoE nn.Parameter unterstützt bnb 4bit noch nicht
)
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 auf MoE-Schichten!
    ],
    lora_alpha = lora_rank*2, # *2 beschleunigt das Training
    use_gradient_checkpointing = "unsloth", # reduziert den Speicherverbrauch
    random_state = 3407,
)

📚 Details zur Implementierung

LoRA ist eine parameter-effiziente Fine-Tuning-Methode: Anstatt die vollständige Gewichtsmatrix zu aktualisieren, trainiert ihr einen niedrig-rangigen „Adapter“ mit viel weniger Parametern, wodurch der Optimierungsspeicher drastisch reduziert wird.

Wenn das ursprüngliche Gewicht die Form hat (m, n), fügt LoRA zwei trainierbare Matrizen mit den Formen (m, r) und (r, n)hinzu. Ihr Produkt ist (m, n)aber ihr verfolgt nur Optimizer-Zustände und Gradienten für:

• m*r + r*n Parameter (LoRA) statt

• m*n Parameter (vollständiges Fine-Tuning)

Beim Fine-Tuning von MoEs ist es keine gute Idee, die Router-Schicht mitzufinetunen, daher haben wir sie standardmäßig deaktiviert.

Für typische MLP-Schichten, m ≈ 4096, n ≈ 12k und r ≈ 64, das sind ungefähr ~1 Mio. LoRA-Parameter gegenüber ~48 Mio. Gesamtparametern - also ~2%, oft mit minimalem bis keinem Genauigkeitsverlust.

MoE LoRA verändert die Dinge

MoE-Schichten sind anders, weil ihr E Expert-MPLs parallelhabt, sodass jede Änderung pro Experte (z. B. das Hinzufügen von LoRA) über alle Experten skaliert.

Nehmen wir Qwen3‑30B‑A3B: verborgene Größe m=2048, Zwischengröße n=768, E=128 Experten mit k=8 pro Token aktiviert. Pro Experte:

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

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

Mit LoRA-Rang r=64fügt jede Projektion hinzu r*(m+n)=64*(2048+768)=180,224 Parameter pro Experte (≈ 11% einer 2048×768 Matrix). Das Kernproblem ist, dass r/n = 64/768 im Vergleich zu typischen MLP-Setups groß ist, zum Beispiel r/n = 64/25600 in Qwen3-32B ähnlicher Größe.

Wenn ihr dies über alle Experten materialisiert, summiert sich der Speicher schnell. Und da gate_proj und up_proj oft als gate_up_projzusammengeführt werden, materialisiert man typischerweise beide gemeinsam, was den Overhead bzw. den Spitzen-Speicher ungefähr verdoppelt.

Speicherseitig haben wir für eine Sequenzlänge s, E Experten und k ausgewählt, für beide Ansätze Folgendes gemeinsam

# Alle diese Werte gelten pro Experte
Endausgabe: (s, n)
Eingabeaktivierungen: (s, m)
Endausgabe: (s, n)

Hier beginnen sich die Dinge zu unterscheiden. Für den Ansatz von peft haben wir

delta = loraA@loraB  = (m,n) pro Experte = Emn Parameter

Für Unsloths Split-LoRA-Ansatz führen wir die folgenden Operationen aus

Y = X @ loraA : (s,m) @ (m, r)       # aber spärlich für k Experten = ksr Parameter
Y @ loraB: (s, r) @ (r, n)           # aber wieder spärlich für k Experten = ksn Parameter

Betrachten wir nun den Fall von Qwen3-30B-A3B.

E = 128, k = 8, m = 2048, n = 768. Wenn wir all das einsetzen, erhalten wir 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}$$

Rechenmäßig, für eine Sequenzlänge s, E Experten und top k ausgewählt, berechnen wir:

$$\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}$$

Im Fall von Unsloths Split-LoRA, den wir erwähnt haben, haben wir

$$\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}$$

Der Punkt, bis zu dem Split LoRA aus analytischer Sicht besser ist, liegt bei s > Emn/k(m+n) was in der Größenordnung von 16K Token für ein Modell im Stil von Qwen3-30B-A3B ist.

Schließlich kommen einige Geschwindigkeitsgewinne von reduziertem Speicherverkehr: Moderne GPUs sind oft bandbreitenlimitiert, daher kann das Übertragen weniger Daten wichtiger sein als FLOPs. Eine grobe Schätzung für den Speed-up ist Emn / [k·s·(m+n)], also hängt er stark von s, E, kund den Matrixformen ab.

🔮 Modellunterstützung

Unsloth unterstützt schnelleres MoE-Training für Qwen-, gpt-oss-, DeepSeek- und GLM-Modelle:

• Qwen3 (Thinking und 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

Möglicherweise haben wir einige MoE-Modelle nicht hochgeladen, aber Unsloth sollte sie trotzdem unterstützen.

📈 Weitere Benchmarks

gpt-oss BF16 Benchmarks

Trainingsgeschwindigkeit einschließlich gegenüber Transformers v4

Kontextlänge	Unsloth (ms)	TF v5 (ms)	TF v4 (ms)	Beschleunigung
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

Speicher-VRAM-Nutzung

Kontextlänge	Unsloth-Speicher (GB)	TF v5-Speicher (GB)	TF v4 Speicher (GB)	VRAM-Ersparnis
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

🎉 Wichtige Unsloth-Updates

1. Im Rahmen unseres MoE-Release haben wir außerdem Gemma-3 verwendet jetzt standardmäßig Flex-Attention standardmäßig aktiviert, und das funktioniert auch in float16-Einstellungen (es gab Unendlichkeiten, die wir vor einiger Zeit behoben haben). Gemma-3 verwendet jetzt O(N)-Speicher statt O(N^2)-Speicher und trainiert >3x schneller (skaliert mit der Kontextlänge sogar noch besser). Frühere Unsloth-Versionen würden in OOM laufen.

Kontext	Alte Spitzen-VRAM	Neuer Spitzen-VRAM	VRAM-Ersparnis
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. Vision-Fine-Tuning akzeptiert jetzt gemischte Daten nur aus Bildern und Textdaten!

2. Windows wird jetzt offiziell unterstützt, ohne dass WSL erforderlich ist.

3. trl==0.27.1 und transformers==5.1.0 werden gut unterstützt - die vorherige Abdeckung lag bei 30% aller unserer 120 Notebooks, jetzt haben wir >80% Abdeckung - wir planen, in den nächsten Tagen 100% zu erreichen.

4. Viele Fehlerbehebungen und andere Updates - siehe https://github.com/unslothai/unsloth/releases/tag/February-2026

Um schnelleres MoE-Training zu aktivieren, aktualisiert Unsloth über pip install --upgrade unsloth unsloth_zoo

Danksagungen

Wir danken dem Hugging-Face-Team für die Zusammenarbeit mit uns bei der Verbesserung des MoE-Trainings für die Community.

Wir danken auch dem torchao-Team von Herzen, insbesondere Vasily Kuznetsov (vkuzo), dafür, dass er uns geholfen hat, die grouped_mm-Unterstützung für float16 zu aktivieren, damit es auf T4 und mit Abwärtskompatibilität zu A100 funktioniert.