> For the complete documentation index, see [llms.txt](https://unsloth.ai/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://unsloth.ai/docs/de/blog/3x-faster-training-packing.md). # 3x schnelleres LLM-Training mit Unsloth-Kernels + Packing Erfahren Sie, wie Unsloth den Trainingsdurchsatz erhöht und Padding-Verschwendung beim Feinabstimmen eliminiert. Unsloth unterstützt jetzt bis zu **5× schneller** (typischerweise 3x) Training mit unseren neuen benutzerdefinierten **RoPE- und MLP-Triton-Kernels**, plus unser neues intelligentes automatisches Packing. Unsloths neue Kernel + Funktionen erhöhen nicht nur die Trainingsgeschwindigkeit, sondern **reduzieren auch den VRAM-Verbrauch (30 % - 90 %)** ohne Genauigkeitsverlust. [Unsloth GitHub](https://github.com/unslothai/unsloth)\ \ Das bedeutet, dass Sie LLMs jetzt wie [Qwen3](/docs/de/modelle/tutorials/qwen3-how-to-run-and-fine-tune.md)-4B nicht nur auf gerade einmal **3GB VRAM**, sondern auch 3x schneller trainieren können. Unser automatisches [**padding-freies**](#padding-free-by-default) unkontaminiertes Packing wird für alle Trainingsläufe ohne Änderungen intelligent aktiviert, ebenso wie alle schnellen Attention-Backends (FlashAttention 3, xFormers, SDPA). [Benchmarks](#analysis-and-benchmarks) zeigen, dass die Trainingsverluste den Läufen ohne Packing entsprechen **genau**. * **2,3x schnelleres QK Rotary Embedding** fusionierter Triton-Kernel mit Packing-Unterstützung * Aktualisierte SwiGLU-, GeGLU-Kernels mit **int64-Indexierung für langen Kontext** * **2,5x bis 5x schnelleres unkontaminiertes Packing** mit xformers-, SDPA-, FA3-Backends * **2,1x schneller ohne Padding, 50 % weniger VRAM**, 0 % Genauigkeitsänderung * Unsloth hat jetzt außerdem eine verbesserte Stabilität des SFT-Verlusts und eine vorhersehbarere GPU-Auslastung. * Dieses neue Upgrade funktioniert **für alle Trainingsmethoden** z. B. vollständiges Fine-Tuning, Pretraining usw. ### :drum:Fusionierter QK-RoPE-Triton-Kernel mit Packing Im Dezember 2023 führten wir im Rahmen unseres Unsloth-Launches einen in Triton geschriebenen RoPE-Kernel ein. Im März 2024 konnte ein Community-Mitglied das End-to-End-Training um 1–2 % beschleunigen, indem der RoPE-Kernel optimiert wurde, um das Starten eines Blocks für eine Gruppe von Heads zu ermöglichen. Siehe [PR 238](https://github.com/unslothai/unsloth/pull/238).
Ein Problem ist, dass es für jedes Q und K zwei Triton-Kernel gibt. Wir haben sie jetzt zu einem Triton-Kernel zusammengeführt, und variable Längen für RoPE aktiviert, was für Padding-freies Training und Packing-Unterstützung unerlässlich war. Dadurch ist der RoPE-Kernel in Micro-Benchmarks **2,3x schneller bei längeren Kontextlängen**, und 1,9x schneller bei kürzeren Kontextlängen. Wir haben außerdem alle Klone und zusammenhängenden Transponierungsoperationen entfernt, und daher ist **RoPE jetzt vollständig inplace**, wodurch der GPU-Speicher weiter reduziert wird. Beachten Sie für den Backward-Pass, dass `sin1 = -sin1` da: ``` Q * cos + rotate_half(Q) * sin äquivalent ist zu Q * cos + Q @ R * sin wobei R eine Rotationsmatrix [ 0, I] ist [-I, 0] dC/dY = dY * cos + dY @ R.T * sin wobei R.T wiederum dieselbe [ 0, -I] ist aber das Minus transponiert ist. [ I, 0] ``` ### :railway\_car:Int64-Indexierung für Triton-Kernels Während des 500K langen Kontexttrainings, das wir in [500K Context Training](/docs/de/blog/500k-context-length-fine-tuning.md)eingeführt haben, bekamen wir CUDA-Fehler wegen Out-of-Bounds. Das lag daran, dass die MLP-Kernels für SwiGLU, GeGLU eine int32-Indexierung hatten, die standardmäßig in Triton und CUDA verwendet wird. Wir können nicht einfach `tl.program_id(0).to(tl.int64)` machen, da das Training aufgrund der int64-Indexierung etwas langsamer wäre. Stattdessen machen wir dies zu einer `LONG_INDEXING: tl.constexpr` Variable, damit der Triton-Compiler dies spezialisieren kann. Dadurch können sowohl kürzere als auch längere Kontexte großartig laufen! {% code overflow="wrap" %} ```python block_idx = tl.program_id(0) if LONG_INDEXING: offsets = block_idx.to(tl.int64) * BLOCK_SIZE + tl.arange(0, BLOCK_SIZE).to(tl.int64) n_elements = tl.cast(n_elements, tl.int64) else: offsets = block_idx * BLOCK_SIZE + tl.arange(0, BLOCK_SIZE) ``` {% endcode %} ### :abacus:Warum Padding benötigt wird & mathematischer Geschwindigkeitsgewinn Computer und GPUs können Datensätze unterschiedlicher Länge nicht verarbeiten, daher müssen wir sie mit 0en auffüllen. Das führt $$\text{batchsize} \times L$$ zu Verschwendung, da die längste Sequenzlänge dominiert. Indem wir mehrere Beispiele in einen einzelnen, langen eindimensionalen Tensor packen, können wir einen erheblichen Teil des Paddings eliminieren. Tatsächlich erhalten wir die folgende Token-Nutzung: $$ \text{Token Usage} = \frac{\text{batchsize}}{2}L+\frac{\text{batchsize}}{2}S $$ Mit etwas Mathematik und Algebra können wir den Geschwindigkeitsgewinn über Folgendes berechnen: $$ \text{Speedup} = \frac{\text{batchsize} \times L}{\frac{\text{batchsize}}{2}L+\frac{\text{batchsize}}{2}S} = 2 \frac{L}{L + S} $$ Indem wir annehmen $$S\rightarrow0$$ erhalten wir dann einen theoretischen 2x-Geschwindigkeitsgewinn, da $$2 \frac{L}{L + 0} = 2$$ Wenn wir das Verhältnis von 50 % kurzen Sequenzen ändern und annehmen, dass wir MEHR kurze Sequenzen haben, z. B. 20 % lange Sequenzen und 80 % kurze Sequenzen, erhalten wir $$\frac{L}{0.2L + 0.8S}\rightarrow\frac{L}{0.2L}=5$$ also 5x schnelleres Training! Das bedeutet, dass der Geschwindigkeitsgewinn von Packing davon abhängt, wie viele kurze Zeilen Ihr Datensatz hat (je mehr kurze, desto schneller). ### :clapper:Standardmäßig ohne Padding Zusätzlich zu den großen Durchsatzgewinnen, die beim Setzen von `packing = True` in Ihrem `SFTConfig` , werden wir **automatisch padding-freies Batching verwenden** um Padding-Verschwendung zu reduzieren, den Durchsatz zu verbessern und den tokens/s-Durchsatz zu erhöhen, während gleichzeitig ***genau derselbe Loss*** wie in der vorherigen Version von Unsloth resultiert. Zum Beispiel sehen wir bei Qwen3-8B und Qwen3-32B eine Verringerung des Speicherverbrauchs um 60 %, eine 2x höhere Geschwindigkeit und genau dieselben Loss- und Grad-Norm-Kurven!
### :spades:Unkontaminiertes Packing: 2-5x schnelleres Training Echte Datensätze können unterschiedliche Sequenzlängen enthalten, daher führt eine Erhöhung der Batchgröße auf beispielsweise 32 zu Padding, wodurch das Training langsamer wird und mehr VRAM verbraucht. {% hint style="success" %} Früher führte das Erhöhen von `batch_size` auf große Zahlen (>32) dazu, dass das Training LANGSAMER statt schneller wurde. Das lag am Padding – wir können dieses Problem jetzt durch `packing = True`lösen, und so ist das Training SCHNELLER! {% endhint %} Wenn wir mehrere Samples in einen einzelnen eindimensionalen Tensor packen, behalten wir Metadaten zur Sequenzlänge bei, um Samples korrekt zu maskieren, ohne Attention zwischen Samples zu leaken. Wir benötigen außerdem den in [#fused-qk-rope-triton-kernel-with-packing](#fused-qk-rope-triton-kernel-with-packing "mention") beschriebenen RoPE-Kernel, um Positions-IDs zurückzusetzen. {% columns %} {% column width="41.66666666666667%" %}

4 Beispiele ohne Packing verschwenden Platz

{% endcolumn %} {% column width="58.33333333333333%" %}

Unkontaminiertes Packing erzeugt das richtige Attention-Muster

{% endcolumn %} {% endcolumns %} Wenn wir das Verhältnis von 50 % kurzen Sequenzen ändern und annehmen, dass wir MEHR kurze Sequenzen haben, z. B. 20 % lange Sequenzen und 80 % lange Sequenzen, erhalten wir $$\frac{L}{0.2L + 0.8S}\rightarrow\frac{L}{0.2L}=5$$ also 5x schnelleres Training! Das bedeutet, dass der Geschwindigkeitsgewinn von Packing davon abhängt, wie viele kurze Zeilen Ihr Datensatz hat (je mehr kurze, desto schneller). ### :beach:Analyse und Benchmarks Um die verschiedenen Verbesserungen beim Training mit unseren neuen Kernels und gepackten Daten zu demonstrieren, haben wir Fine-Tuning-Läufe mit [Qwen3-32B](/docs/de/modelle/tutorials/qwen3-how-to-run-and-fine-tune.md), Qwen3-8B, Llama 3 8B auf dem `yahma/alpaca-cleaned` Datensatz durchgeführt und verschiedene [Trainingsverlust-](#padding-free-by-default) Durchsatz- und Effizienzmetriken gemessen. Wir verglichen unsere neuen Läufe mit einem standardmäßigen optimierten Trainingslauf, bei dem unsere eigenen Kernel/Optimierungen aktiviert waren und Kernel wie Flash Attention 3 (FA3) aktiviert waren. Wir setzten `max_length = 1024` fest und variierten die Batchgröße in {1, 2, 4, 8, 16, 32}. Dadurch kann die maximale Token-Anzahl pro Batch in {1024, 2048, 4096, 8192, 16K, 32K} variieren.
Das oben Gezeigte zeigt, wie sich der Trainingsdurchsatz in Tokens pro Sekunde (tokens/s) für das neue Unsloth bei variierender Batchgröße verändert. Das bedeutet, dass Sie Ihr Modell in einer Epoche Ihres Datensatzes **1,7- bis 3-mal schneller trainieren (manchmal sogar 5x oder mehr)**! Diese Gewinne werden ausgeprägter sein, wenn es viele kurze Sequenzen in Ihren Daten gibt und wenn Sie längere Trainingsläufe haben, wie in [#why-is-padding-needed-and-mathematical-speedup](#why-is-padding-needed-and-mathematical-speedup "mention")
Das oben Gezeigte zeigt den durchschnittlichen Prozentsatz der Tokens pro Batch, die gültig sind (d. h. kein Padding). Mit wachsender Batchgrößenlänge werden im ungepackten Fall wesentlich mehr Padding-Tokens gesehen, während wir im gepackten Fall unabhängig von der maximalen Sequenzlänge eine hohe Packing-Effizienz erreichen. Beachten Sie, dass die Batching-Logik Batches auf die maximale im Batch gesehene Sequenzlänge kürzt. Wenn die Batchgröße also 1 ist, bestehen die ungepackten Daten nur aus gültigen Tokens (d. h. ohne Padding). Wenn jedoch mehr Beispiele in den Batch aufgenommen werden, nimmt das Padding im Durchschnitt zu und erreicht bei einer Batchgröße von 8 fast 50 % Padding! Unsere Sample-Packing-Implementierung eliminiert diese Verschwendung.
Das erste Diagramm (oben) zeigt den Fortschritt auf `yahma/alpaca-cleaned` mit `max_length = 2048`, das neue Unsloth mit Packing + Kernels (kastanienbraun) vs. altes Unsloth (grau). Beide werden trainiert mit `max_steps = 500`, aber wir tragen die x-Achse als Echtzeit auf. Beachten Sie, dass wir im gepackten Fall in nahezu 40 % einer Epoche mit derselben Anzahl an Schritten (und nur etwas mehr Echtzeit), die es im ungepackten Fall braucht, um weniger als 5 % einer Epoche zu trainieren, Ebenso zeigt das 2. Diagramm (oben) den Loss ### :sparkles:Wie aktiviert man Packing? **Aktualisieren Sie zuerst Unsloth und ohne Padding wird standardmäßig erledigt**! Also ist das gesamte Training sofort 1,1 bis 2x schneller, benötigt mindestens 30 % weniger Speicher und die Loss-Kurvenmetrik ändert sich um 0! {% code overflow="wrap" %} ```bash pip install --upgrade --force-reinstall --no-cache-dir --no-deps unsloth pip install --upgrade --force-reinstall --no-cache-dir --no-deps unsloth_zoo ``` {% endcode %} Wir unterstützen außerdem Flash Attention 3 über Xformers, SDPA-Unterstützung, Flash Attention 2, und das funktioniert auf alten GPUs (Tesla T4, RTX 2080) sowie neuen GPUs wie H100s, B200s usw.! Sample Packing funktioniert *unabhängig von der Wahl des Attention-Backends oder der Modellfamilie*, also genießen Sie dieselben Geschwindigkeitsgewinne wie zuvor mit diesen schnellen Attention-Implementierungen! Wenn Sie explizites Packing aktivieren möchten, fügen Sie `packing = True` hinzu, um bis zu 5x schnelleres Training zu ermöglichen! {% hint style="warning" %} Hinweis `packing=True` ändert den Trainingsverlust und führt dazu, dass die Anzahl der Zeilen im Datensatz gekürzt wird, da mehrere kurze Sequenzen zu 1 Sequenz gepackt werden. Sie könnten sehen, dass die Anzahl der Beispiele im Datensatz schrumpft. Um keine unterschiedlichen Trainingsverlustwerte zu erhalten, setzen Sie einfach `packing=False` und wir aktivieren automatisch ohne Padding, was das Training bereits schneller macht! {% endhint %} ```python from unsloth import FastLanguageModel from trl import SFTTrainer, SFTConfig model, tokenizer = FastLanguageModel.from_pretrained( "unsloth/Qwen3-14B", ) trainer = SFTTrainer( model = model, processing_class = tokenizer, train_dataset = dataset, args = SFTConfig( per_device_train_batch_size = 1, max_length = 4096, …, packing = True, # erforderlich, um Sample Packing zu aktivieren! ), ) trainer.train() ``` Alle unsere Notebooks sind automatisch schneller (Sie müssen nichts tun). Siehe [Unsloth-Notebooks](/docs/de/loslegen/unsloth-notebooks.md) {% columns %} {% column %} Qwen3 14B schneller: {% embed url="" %} {% endcolumn %} {% column %} Llama 3.1 Conversational schneller: {% embed url="" %} {% endcolumn %} {% endcolumns %} Vielen Dank! Wenn Sie interessiert sind, sehen Sie unsere [500K Context Training](/docs/de/blog/500k-context-length-fine-tuning.md) Blog, [Speichereffizientes RL](/docs/de/loslegen/reinforcement-learning-rl-guide/memory-efficient-rl.md) Blog und [Long Context gpt-oss](/docs/de/modelle/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md) Blog für weitere Themen zu Kernels und Leistungsgewinnen! --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://unsloth.ai/docs/de/blog/3x-faster-training-packing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.