# MoE-Modelle 12x schneller mit Unsloth feinabstimmen 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](https://unsloth.ai/docs/de/modelle/gpt-oss-how-to-run-and-fine-tune), [Qwen3](https://unsloth.ai/docs/de/modelle/tutorials/qwen3-how-to-run-and-fine-tune) (30B, 235B, VL, Coder), DeepSeek [R1](https://unsloth.ai/docs/de/modelle/tutorials/deepseek-r1-0528-how-to-run-locally), [V3](https://unsloth.ai/docs/de/modelle/tutorials/deepseek-v3.1-how-to-run-locally) und GLM ([4.6](https://unsloth.ai/docs/de/modelle/tutorials/glm-4.6-how-to-run-locally#glm-4.6v-flash), [4.7](https://unsloth.ai/docs/de/modelle/tutorials/glm-4.7), [Flash](https://unsloth.ai/docs/de/modelle/glm-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)**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt-oss-$20B$-Fine-tuning.ipynb) **(kostenlos)** | [Qwen3-30B-A3B](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_MoE.ipynb) (A100) | [GLM-4.7-Flash](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/GLM_Flash_A100$80GB$.ipynb) (A100) | | ------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | [gpt-oss-120b](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt-oss-$120B$_A100-Fine-tuning.ipynb) (A100) | [gpt-oss (500K Kontext)](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt_oss_$20B$_500K_Context_Fine_tuning.ipynb) | [TinyQwen3 MoE](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/TinyQwen3_MoE.ipynb) (nur Test) |

### 🦥 Unsloth MoE Triton Kernels Zusammen mit `torch._grouped_mm` (siehe [#what-is-torch.\_grouped\_mm](#what-is-torch._grouped_mm "mention")), 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. {% columns %} {% column width="50%" %} 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_mm`um 35% beschleunigen, was sich für längere Läufe durchaus lohnt. {% endcolumn %} {% column width="50%" %}

{% endcolumn %} {% endcolumns %} {% hint style="success" %} 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). {% endhint %} ### :compass: 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.

{% hint style="warning" %} 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. {% endhint %} 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: ```python os.environ["UNSLOTH_MOE_BACKEND"] = "grouped_mm" os.environ["UNSLOTH_MOE_BACKEND"] = "unsloth_triton" os.environ["UNSLOTH_MOE_BACKEND"] = "native_torch" ``` {% hint style="success" %} Um schnelleres MoE-Training zu aktivieren, aktualisiert Unsloth über `pip install --upgrade unsloth unsloth_zoo` {% endhint %} ### ❓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. ```python 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`](https://docs.pytorch.org/docs/main/generated/torch.nn.functional.grouped_mm.html) 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.Parameter`](https://github.com/huggingface/transformers/blob/v5.0.0/src/transformers/models/qwen3_moe/modeling_qwen3_moe.py#L226)gespeichert, was `grouped_mm` zu einer natürlichen Wahl für schnelleres MoE-Training und Inferenz macht. Also [transformers 4.57.6](https://github.com/huggingface/transformers/blob/v4.57.6/src/transformers/models/qwen3_moe/modeling_qwen3_moe.py#L222) änderte sich: {% code overflow="wrap" %} ```python self.experts = nn.ModuleList( [Qwen3MoeMLP(config, intermediate_size) for _ in range(self.num_experts)] ) ``` {% endcode %} zu [transformers 5.0.0](https://github.com/huggingface/transformers/blob/v5.0.0/src/transformers/models/qwen3_moe/modeling_qwen3_moe.py#L226) Stil: {% code overflow="wrap" %} ```python self.gate_up_proj = nn.Parameter(torch.empty(num_experts, 2 * intermediate_dim, hidden_dim)) ``` {% endcode %} `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](https://unsloth.ai/docs/de/modelle/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training) 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](https://huggingface.co/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 [#unsloths-flex-attention-implementation](https://unsloth.ai/docs/de/modelle/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training#unsloths-flex-attention-implementation "mention")und unserer MoE-Kernels.

Kontextlänge	Unsloth (ms)	TF v5 (ms)	Unsloth-Speicher (GB)	TF v5-Speicher (GB)	Beschleunigung	VRAM-Ersparnis	Rang	Unsloth-Warmup (ms)	TRL-Warmup (ms)
1024	275.35	376.99	40.91	43.88	1,4x	6.76%	8	2601.17	615.62
2048	292.88	696.57	41.83	44.93	2,4x	6.89%	8	4996.62	928.42
4096	370.30	1785.89	43.68	49.86	4,8x	12.39%	8	6648.94	2130.33
8192	712.33	5226.86	47.43	73.80	7,3x	35.73%	8	9632.44	5472.66
16384	1775.80	OOM	55.13	OOM	N/A	N/A	8	12696.26	N/A

### Qwen3 Benchmarks Auf einem **NVIDIA B200**sehen 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	Rang
1024	366.3	628.3	80.88	104.80	1,7x	2.06%	8
2048	467.0	745.3	80.88	104.81	1,6x	2.57%	8
4096	711.6	975.5	80.89	104.80	1,4x	5.08%	8
8192	1376.6	1633.5	80.90	104.81	1,2x	9.17%	8
16384	3182.2	3407.9	85.53	116.61	1,1x	15.26%	8

### 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: {% embed url="" %} GLM 4.7 Flash MoE Notebook A100 80GB {% endembed %}

Kontextlänge	Unsloth (ms)	TF v5 (ms)	Unsloth-Speicher (GB)	TF v5-Speicher (GB)	Beschleunigung	VRAM-Ersparnis	Rang	Unsloth-Warmup (ms)	TRL-Warmup (ms)
512	1145.0	2992.1	57.81	60.89	2,6x	6.51%	8	13317.46	893.04
1024	1298.9	3323.3	58.76	62.55	2,6x	6.22%	8	12895.28	937.37
2048	1831.9	4119.3	60.09	67.32	2,3x	9.46%	8	12531.37	1039.45
4096	2883.9	5646.1	63.34	76.78	2x	14.83%	8	7671.60	1643.26

### ⚡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.Linear`verwendet). 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. {% hint style="warning" %} 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. {% endhint %} 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. ```python 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) {% hint style="info" %} Beim Fine-Tuning von MoEs ist es keine gute Idee, die Router-Schicht mitzufinetunen, daher haben wir sie standardmäßig deaktiviert. {% endhint %} 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 parallel**habt, 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=64**fü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](https://huggingface.co/Qwen/Qwen3-32B/blob/main/config.json#L13) ä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_proj`zusammengefü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, 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 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

## :tada: 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 | -- | 2. Vision-Fine-Tuning akzeptiert jetzt gemischte Daten nur aus Bildern und Textdaten! 3. [Windows wird jetzt offiziell unterstützt, ohne dass WSL erforderlich ist](https://unsloth.ai/docs/de/loslegen/install/windows-installation). 4. `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. 5. Viele Fehlerbehebungen und andere Updates - siehe {% hint style="success" %} Um schnelleres MoE-Training zu aktivieren, aktualisiert Unsloth über `pip install --upgrade unsloth unsloth_zoo` {% endhint %} ### 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.