💎Finetune MoE-Modelle 12x schneller mit Unsloth

Trainiere MoE-LLMs lokal mit Unsloth - Anleitung.

Wir führen etwa 12× schnellere Mixture-of-Experts-(MoE)-LLM-Trainings ein mit >35% weniger VRAM und ~6× längerer Kontext mit unseren neuen MoE-Triton-Kernels und neuen mathematischen Optimierungen, alles ohne Genauigkeitsverlust.

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

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

• Unsere Kernel funktionieren sowohl in Rechenzentren (B200, H100), für Consumer als auch auf älteren GPUs (z. B. RTX 3090) sowie mit FFT, LoRA und QLoRA.

In Zusammenarbeit mit 🤗Hugging Face haben wir alle MoE-Trainingsläufe mit PyTorchs neuem Standard vereinheitlicht, torch._grouped_mm Funktion. Transformers v5 wurde kürzlich mit etwa 6× schnellerem MoE im Vergleich zu v4 optimiert, und Unsloth treibt das noch weiter voran mit maßgeschneiderten Triton grouped‑GEMM + LoRA-Kernels für einen zusätzlichen ~2× Geschwindigkeitszuwachs, >35% VRAM-Reduktion und >6× längeren Kontext (insgesamt 12–30× schneller vs. v4).

Probieren Sie 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

Neben torch._grouped_mm (siehe Faster MoE Training), haben wir benutzerdefinierte Triton-MoE-Kernel erstellt, die in einigen Fällen noch schneller sein können. Sie sind außerdem rückwärtskompatibel mit älterer Hardware wie A100 und älteren PyTorch-Versionen.

Auf A100 sind unsere Triton-Kernel etwa 2,5× schneller als torch._grouped_mm. Die Kernel haben außerdem einen einmaligen Autotune-Schritt, um die beste Kernel-Konfiguration zu wählen.

Auto-Tuning dauert einmalig etwa 2 Minuten zu Beginn des Trainings, kann aber den gesamten Lauf auf A100 im Vergleich zu _grouped_mmum 35% beschleunigen, was sich bei längeren Läufen definitiv lohnt.

Je größer das Modell und je mehr Kontext Sie verwenden, desto ausgeprägter sind die Speicherersparnisse durch unsere Unsloth-Kernel (die Effizienz skaliert exponentiell).

🧭 Automatische Backend-Auswahl

Unsere Hauptinnovation ist unser Split-LoRA-Ansatz für effizientes MoE, der etwa 35% weniger Speicher verwendet und beim Training 2× schneller ist im Vergleich zu Transformers v5 + torch._grouped_mm. Maßgeschneiderte torch._grouped_mm + unsere Triton-Kernel sind etwa 12–30× schneller als Transformers v4.

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

Unsloth wählt abhängig von Ihrer Hardware automatisch eines 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-Kernel - die sich automatisch für A100s und ältere PyTorch-Versionen aktivieren.
native_torch	Native PyTorch. Es ist 12× langsamer, aber unsere VRAM-Reduktionen bleiben bestehen!

Sie können 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, aktualisieren Sie Unsloth über pip install --upgrade unsloth unsloth_zoo

❓Was ist torch._grouped_mm?

Früher wurden Mixture-of-Experts-(MoE)-Gewichte als ModuleList von pro‑Experten linearen Schichten gespeichert. Der einzige praktikable Weg, einen Forward-Pass auszuführen, 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 dieses Nadelöhr zu adressieren. Parallel dazu stellen wir unsere eigenen MoE‑optimierten Triton-Kernel bereit. Das stimmt auch mit einer wichtigen Veränderung in Transformers überein: Ab Transformers v5 werden Expertengewichte als einzelner nn.Parametergespeichert, was grouped_mm eine natürliche Passform für schnelleres MoE-Training und -Inference darstellt.

Also transformers 4.57.6 änderte:

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 verifiziert, sodass die Unterstützung breit verfügbar ist.

Wir haben zuvor auch Unsloth Flex Attention für gpt-oss eingeführt, und diese Optimierungen sollten es noch effizienter machen.

📊 Kernel-Ergebnisse + Benchmarks

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

gpt-oss Benchmarks

Wir haben feinabgestimmt unsloth/gpt-oss-20b-BF16 zum Benchmarking. Unsloth ist 7× schneller und verwendet 36% weniger VRAM bei 16K Kontextlängen. Transformers v5 + TRL läuft out-of-memory, während Unsloth das nicht tut. Außerdem steigt die Beschleunigung in diesem Fall mit der Sequenzlänge dank unseres Long Context gpt-oss, und unserer MoE-Kernel.

Vergleich mit transformers v4

Kontextlänge	Unsloth (ms)	TF v5 (ms)	Unsloth Mem (GB)	TF v5 Mem (GB)	Beschleunigung	VRAM-Ersparnis
1024	275.35	376.99	40.91	43.88	1,4×	6.76%
2048	292.88	696.57	41.83	44.93	2,4×	6.89%
4096	370.30	1785.89	43.68	49.86	4,8×	12.39%
8192	712.33	5226.86	47.43	73.80	7,3×	35.73%
16384	1775.80	OOM	55.13	OOM	N/V	N/V

Qwen3 Benchmarks

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

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

Auf H100-GPUs schneiden wir deutlich besser als die Basislinie ab und erreichen bis zu 1,77× Beschleunigung beim Training und sparen gleichzeitig etwa 5,3GB bei Feinabstimmung mit 4K Kontextlänge. Während wir nahtlos auf 8192 Kontextlängen skalieren, OOMt Transformers v5 + TRL bei 8K. Beachten Sie, dass wir bei 8K weniger Speicher verwenden als die Basislinie bei 4K, sodass wir die Kontextlänge weiter erhöhen können.

Kontextlänge	Unsloth (ms)	TF v5 (ms)	Unsloth Mem (GB)	TF v5 Mem (GB)	Beschleunigung	VRAM-Ersparnis
1024	366.3	628.3	80.88	104.80	1,7×	2.06%
2048	467.0	745.3	80.88	104.81	1,6×	2.57%
4096	711.6	975.5	80.89	104.80	1,4×	5.08%
8192	1376.6	1633.5	80.90	104.81	1,2×	9.17%
16384	3182.2	3407.9	85.53	116.61	1,1×	15.26%

GLM 4.7 Benchmarks

Unsloth erreicht 2,6× höheren Durchsatz mit >15% weniger VRAM über alle Batch-Größen für GLM 4.7 Flash. GLM 4.7 Flash ist ein 30B MoE (3B aktive Parameter) agentisches & Coding-Modell 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 gebenchmarkt.

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

Google Colabcolab.research.google.com

GLM 4.7 Flash MoE-Notebook A100 80GB

Kontextlänge	Unsloth (ms)	TF v5 (ms)	Unsloth Mem (GB)	TF v5 Mem (GB)	Beschleunigung	VRAM-Ersparnis
512	1145.0	2992.1	57.81	60.89	2,6×	6.51%
1024	1298.9	3323.3	58.76	62.55	2,6×	6.22%
2048	1831.9	4119.3	60.09	67.32	2,3×	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 Basismodellgewicht zu integrieren und dann die MoE-Berechnung auszuführen (insbesondere da MoE oft ALLE anderen Trainingsmethoden werden mindestens 65GB VRAM benötigen, um das 20B-Modell zu trainieren, während Unsloth nur 14GB VRAM benötigt (-80%). anstatt nn.Parameterverwendet). Das Problem ist, dass dieses Zusammenführen effektiv das LoRA-Delta materialisiert (für alle Experten) lora_B @ lora_A.t, was sehr speicherhungrig.

ist. Unsloth vermeidet das. Wir haben zuvor dieselbe Idee genutzt, um generisches LoRA-Training und -Inference zu optimieren, und haben sie nun auch auf MoE + LoRA angewendet. Die Mathematik ist identisch, daher bleiben Verlust, Gradienten und Ausgaben gleich. Die einzige Änderung ist die Reihenfolge der Operationen, ermöglicht durch die Assoziativität der Matrixmultiplikation. Durch diese Umordnung erzielen wir große Beschleunigungen und Speicherreduktionen.

MoE-Modelle trainieren in 4-Bit QLoRA wird derzeit nicht empfohlen, da BitsandBytes es nicht unterstützt. Das ist nicht spezifisch für Unsloth. Verwenden Sie vorläufig 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). Sie können Implementierungen über die UNSLOTH_MOE_BACKEND Umgebungsvariable umschalten: entweder torch._grouped_mm Triton-Kernel 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 Sie ein anderes Backend wählen möchten (standardmäßig grouped_mm), setzen Sie 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 derzeit 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,
)

📚 Implementierungsdetails

LoRA ist eine parameter-effiziente Fine-Tuning-Methode: Statt die vollständige Gewichtsmatrix zu aktualisieren, trainieren Sie einen niedrig-rangigen „Adapter“ mit deutlich weniger Parametern, was den Optimizer-Speicher drastisch reduziert.

Wenn das ursprüngliche Gewicht die Form (m, n)hat, fügt LoRA zwei trainierbare Matrizen mit Formen hinzu (m, r) und (r, n). Ihr Produkt ist (m, n), aber Sie verfolgen 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 — es ist keine gute Idee, die Router-Schicht zu feinabstimmen, daher haben wir sie standardmäßig deaktiviert.

Für typische MLP-Schichten gilt: m ≈ 4096, n ≈ 12k und r ≈ 64, das sind ungefähr ~1M LoRA-Parameter vs. ~48M volle Parameter - etwa ~2%, oft mit minimalem bis keinem Genauigkeitsverlust.

MoE LoRA ändert die Lage

MoE-Schichten sind anders, weil Sie E Experten-MLPs parallel haben, sodass jede pro‑Experten-Änderung (wie das Hinzufügen von LoRA) über alle Experten skaliert.

Nehmen Sie Qwen3‑30B‑A3B: versteckte Größe m=2048, Zwischen- bzw. Intermediate-Größ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=64, fügt jede Projektion r*(m+n)=64*(2048+768)=180.224 Parameter pro Experte hinzu (≈ 11% einer 2048×768 Matrix). Das Kernproblem ist, dass r/n = 64/768 im Vergleich zu typischen MLP-Konfigurationen groß ist, z. B. r/n = 64/25600 in Qwen3-32B bei ähnlicher Größe.

Wenn Sie dies über alle Experten materialisieren, summiert sich der Speicher schnell. Und da gate_proj und up_proj oft als gate_up_projfusioniert werden, materialisiert man typischerweise beide zusammen, was den Overhead/Spitzenverbrauch ungefähr verdoppelt.

In Bezug auf Speicher, für eine Sequenzlänge s, E Experten und k ausgewählt, haben wir Folgendes, das für beide Ansätze üblich ist

# Alle diese Werte sind pro Experte
Endausgabe: (s, n)
Eingangsaktivierungen: (s, m)
Endausgabe: (s, n)

Hier beginnen die Unterschiede. Für den peft-Ansatz 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)           # wieder spärlich für k Experten = ksn Parameter

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

E = 128, k = 8, m = 2048, n = 768. Wenn man all dies einsetzt, erhält man 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}$$

In Bezug auf Rechenaufwand, für eine Sequenzlänge s, E Experten und Top k ausgewählt, führen wir aus:

$$\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 Unsloth 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, ist wenn s > Emn/k(m+n) was in der Größenordnung von 16K Token für ein Qwen3-30B-A3B-ähnliches Modell liegt.

Schließlich stammen einige Beschleunigungen aus reduziertem Speicherverkehr: moderne GPUs sind oft bandbreiten‑gebunden, daher kann das Übertragen weniger Daten wichtiger sein als FLOPs. Eine grobe Geschwindigkeitsabschätzung ist Emn / [k·s·(m+n)], also hängt es stark von s, E, k, und 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 Vergleich zu Transformers v4

Kontextlänge	Unsloth (ms)	TF v5 (ms)	TF v4 (ms)	Beschleunigung
1024	275.35	376.99	2111.18	1,37×
2048	292.88	696.57	2626.80	2,38×
4096	370.30	1785.89	4027.93	4,82×
8192	712.33	5226.86	8513.52	7,34×
16384	1775.80	OOM	OOM	N/V

Speicher VRAM-Nutzung

Kontextlänge	Unsloth Mem (GB)	TF v5 Mem (GB)	TF v4 Mem (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/V

🎉 Wichtige Unsloth-Updates

1. Im Rahmen unserer MoE-Veröffentlichung haben wir außerdem Gemma-3 verwendet jetzt standardmäßig Flex-Attention , und das funktioniert auch in float16-Umgebungen (es gab zuvor Infinities, die wir vor einiger Zeit gelöst haben). Gemma-3 verwendet nun O(N)-Speicher und nicht O(N^2)-Speicher und trainiert >3× schneller (skaliert mit Kontextlänge sogar noch besser). Frühere Unsloth-Versionen hätten OOMs verursacht.

Kontext	Alter 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, die nur aus Bildern und Text bestehen!

2. Windows wird jetzt offiziell unterstützt, ohne dass WSL benötigt wird.

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

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

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

Danksagungen

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

Wir danken auch dem torchao-Team, insbesondere Vasily Kuznetsov (vkuzo), dafür, dass er uns geholfen hat, grouped_mm-Unterstützung für float16 zu ermöglichen, damit es auf T4 funktioniert und Rückwärtskompatibilität mit A100 gewährleistet ist.