⚡3x schnelleres LLM-Training mit Unsloth-Kerneln + Packing

Lerne, wie Unsloth den Trainingsdurchsatz erhöht und Padding-Verschwendung beim Finetuning 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 reduziert außerdem den VRAM-Verbrauch (30% - 90%) ohne Genauigkeitsverlust. Unsloth GitHub Das bedeutet, dass Sie jetzt LLMs wie Qwen3-4B nicht nur auf nur 3GB VRAM, sondern auch 3x schneller trainieren können.

Unser Auto ohne Padding kontaminationsfreies Packing wird für alle Trainingsläufe automatisch und intelligent aktiviert, ohne Änderungen, und für alle schnellen Attention-Backends (FlashAttention 3, xFormers, SDPA). Benchmarks zeigen, dass Trainingsverluste genau mit Nicht-Packing-Läufen übereinstimmen genau.

• 2.3x schnellere QK Rotary Embedding fusionierter Triton-Kernel mit Packing-Unterstützung

• Aktualisierte SwiGLU-, GeGLU-Kernel mit int64-Indexierung für langen Kontext

• 2.5x bis 5x schnelleres kontaminationsfreies Packing mit xformers-, SDPA-, FA3-Backends

• 2.1x schnelleres padding-freies, 50% weniger VRAM, 0% Änderung der Genauigkeit

• Unsloth hat jetzt außerdem eine verbesserte SFT-Loss-Stabilität und vorhersehbarere GPU-Auslastung.

• Dieses neue Upgrade funktioniert für alle Trainingsmethoden z. B. vollständiges Feintuning, Vortraining usw.

🥁Fusionierter QK RoPE Triton-Kernel mit Packing

Im Dezember 2023 stellten wir im Rahmen unseres Unsloth-Starts einen in Triton geschriebenen RoPE-Kernel vor. Im März 2024 machte ein Community-Mitglied das End-to-End-Training 1–2% schneller, indem es den RoPE-Kernel optimierte, um das Starten eines Blocks für eine Gruppe von Heads zu ermöglichen. Siehe PR 238.

Ein Problem war, dass es für jedes Q und K zwei Triton-Kernel gab. Wir haben sie jetzt in einen Triton-Kernel zusammengeführt und variable Länge RoPE aktiviert, was für padding-freies Training und Packing-Unterstützung unerlässlich war. Dadurch ist der RoPE-Kernel in Mikrobenchmarks 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 Transpose-Operationen eliminiert, und so ist RoPE jetzt vollständig inplace, was den GPU-Speicher weiter reduziert. Hinweis für den Backward-Pass: Wir sehen, dass sin1 = -sin1 da:

Q * cos + rotate_half(Q) * sin
äquivalent ist zu
Q * cos + Q @ R * sin
wobei R eine Rotationsmatrix ist [ 0,  I]
                             [-I,  0]
dC/dY = dY * cos + dY @ R.T * sin
wobei R.T wieder dieselbe [ 0, -I] ist
aber das Minus ist transponiert. [ I,  0]

🚃Int64-Indexierung für Triton-Kernel

Während des Trainings mit 500K langer Kontextlänge, das wir in 500K Context Trainingeingeführt haben, bekamen wir CUDA-Out-of-Bounds-Fehler. Das lag daran, dass MLP-Kernel für SwiGLU, GeGLU int32-Indexierung hatten, welche in Triton und CUDA standardmäßig ist.

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 Variablen, damit der Triton-Compiler dies spezialisieren kann. Dadurch laufen kurze und lange Kontextläufe beide sehr gut!

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)

🧮Warum Padding nötig ist & mathematische Beschleunigung

Computer und GPUs können Datensätze unterschiedlicher Länge nicht direkt verarbeiten, daher müssen wir sie mit Nullen auffüllen. Das verursacht Verschwendung. Angenommen, wir haben einen Datensatz mit 50% kurzen Sequenzen S und 50% langen Sequenzen L, dann führt Padding im schlimmsten Fall zu einem Token-Einsatz von $\text{batchsize} \times L$ da die längste Sequenzlänge dominiert.

Indem wir mehrere Beispiele in einen einzelnen, langen eindimensionalen Tensor packen, können wir einen erheblichen Teil der Padding-Overhead eliminieren. Tatsächlich erhalten wir die untenstehende Token-Nutzung:

$$\text{Token Usage} = \frac{\text{batchsize}}{2}L+\frac{\text{batchsize}}{2}S$$

Durch etwas Mathematik und Algebra können wir die Beschleunigung wie folgt 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$ dann erhalten wir eine theoretische 2x-Beschleunigung, da $2 \frac{L}{L + 0} = 2$

Wenn man das Verhältnis von 50% kurzen Sequenzen ändert und annimmt, 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 die Beschleunigung durch Packing davon abhängt, wie viele kurze Reihen Ihr Datensatz hat (je mehr kurze, desto schneller).

🎬Padding-frei per Voreinstellung

Zusätzlich zu den großen Durchsatzgewinnen, die verfügbar sind, wenn man packing = True in Ihrem SFTConfig , werden wir verwenden, nutzen Sie automatisch padding-freies Batching um Padding-Verschwendung zu reduzieren, den Durchsatz zu verbessern und die Token/s-Durchsatzrate zu erhöhen, während das genau gleiche 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 schnellere Ausführung und exakt dieselben Loss- und Grad-Norm-Kurven!

♠️Kontaminationsfreies Packing: 2-5x schnelleres Training

Reale Datensätze können unterschiedliche Sequenzlängen enthalten. Wenn man z. B. die Batch-Größe auf 32 erhöht, verursacht das Padding, macht das Training langsamer und verbraucht mehr VRAM.

Früher machte eine Erhöhung von batch_size auf große Zahlen (>32) das Training LANGSAMER, nicht schneller. Das lag am Padding – wir können dieses Problem jetzt durch packing = Trueeliminieren, und so ist das Training SCHNELLER!

Wenn wir mehrere Proben in einen einzigen eindimensionalen Tensor packen, behalten wir Metadaten zur Sequenzlänge bei, um Proben korrekt zu maskieren, ohne Attention zwischen Proben zu leaken. Wir benötigen außerdem den in New 3x Faster Training beschriebenen RoPE-Kernel, um Positions-IDs zurücksetzen zu können.

4 Beispiele ohne Packing verschwenden Platz

Kontaminationsfreies Packing erzeugt korrektes Attention-Muster

Wenn man das Verhältnis von 50% kurzen Sequenzen ändert und annimmt, 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 die Beschleunigung durch Packing davon abhängt, wie viele kurze Reihen Ihr Datensatz hat (je mehr kurze, desto schneller).

🏖️Analyse und Benchmarks

Um die verschiedenen Verbesserungen beim Training mit unseren neuen Kernels und gepackten Daten zu demonstrieren, führten wir Feintuning-Läufe mit Qwen3-32B, Qwen3-8B, Llama 3 8B auf dem yahma/alpaca-cleaned Datensatz durch und maßen verschiedene Trainingsverluste Durchsatz- und Effizienzmetriken. Wir verglichen unsere neuen Läufe mit einem standardmäßigen optimierten Trainingslauf mit unseren eigenen Kernel-/Optimierungen aktiviert und Kerneln wie Flash Attention 3 (FA3) aktiviert. Wir setzten max_length = 1024 und variierten die Batch-Größe in {1, 2, 4, 8, 16, 32}. Dies erlaubt, dass die maximale Token-Anzahl pro Batch in {1024, 2048, 4096, 8192, 16K, 32K} variiert.

Oben wird gezeigt, wie sich die Tokens pro Sekunde (Tokens/s) Trainingsdurchsatz für das neue Unsloth mit variierender Batch-Größe verändert. Das übersetzt sich in das Training Ihres Modells auf einer Epoche Ihres Datensatzes 1.7-3x schneller (manchmal sogar 5x oder mehr)! Diese Gewinne sind ausgeprägter, wenn viele kurze Sequenzen in Ihren Daten vorhanden sind und wenn Sie längere Trainingsläufe haben, wie in New 3x Faster Training

oben beschrieben.

Oben wird der durchschnittliche Prozentsatz der Tokens pro Batch gezeigt, die gültig sind (d. h. kein Padding). Wenn die Batch-Länge wächst, treten in der ungepackten Variante viel mehr Padding-Tokens auf, während wir unabhängig von der maximalen Sequenzlänge eine hohe Packing-Effizienz im gepackten Fall erreichen.

Beachten Sie, dass die Batching-Logik die Batches auf die maximale Sequenzlänge im Batch zuschneidet. Wenn die Batch-Größe 1 ist, sind die ungepackten Daten also alle gültige Tokens (d. h. kein Padding). Sobald jedoch mehr Beispiele in das Batch aufgenommen werden, nimmt das Padding im Durchschnitt zu und erreicht bei Batch-Größe 8 fast 50% Padding! Unsere Beispiel-Packing-Implementierung eliminiert diese Verschwendung. yahma/alpaca-cleaned mit Das erste Diagramm (oben) zeigt den Fortschritt beimax_length = 2048 , Unsloth neu mit Packing + Kernels (weinrot) vs. Unsloth alt (grau). Beide wurden mitmax_steps = 500

trainiert, aber wir tragen die x-Achse in Echtzeit auf. Beachten Sie, dass wir im gepackten Fall in derselben Anzahl von Schritten (und nur etwas mehr Echtzeit) fast 40% einer Epoche trainieren, wofür im ungepackten Fall weniger als 5% einer Epoche trainiert werden.

✨Ähnlich zeigt das 2. Diagramm (oben) den Loss der gleichen Läufe, diesmal mit Trainingsschritten auf der x-Achse. Beachten Sie, dass die Verluste in Skalierung und Trend übereinstimmen, aber der Loss im gepackten Fall weniger variabel ist, da das Modell mehr Tokens pro Trainingsschritt sieht.

Wie aktiviert man Packing?Aktualisieren Sie zuerst Unsloth und padding-frei ist standardmäßig aktiviert

pip install --upgrade --force-reinstall --no-cache-dir --no-deps unsloth
pip install --upgrade --force-reinstall --no-cache-dir --no-deps unsloth_zoo

! Somit ist alles Training sofort 1.1 bis 2x schneller mit mindestens 30% weniger Speicherverbrauch und 0 Änderung in der Loss-Kurve! 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) und neuen GPUs wie H100s, B200s etc.! Sample-Packing funktioniertunabhängig von der Wahl des Attention-Backends oder der Modelfamilie

, also genießen Sie dieselben Geschwindigkeitssteigerungen wie zuvor bei diesen schnellen Attention-Implementierungen! packing = True Wenn Sie explizites Packing aktivieren möchten, fügen Sie einfach

Hinweis hinzu, um bis zu 5x schnelleres Training zu ermöglichen! packing=True

wird den Trainingsverlust ändern und die Anzahl der Zeilen im Datensatz verkürzen, da mehrere kurze Sequenzen in eine Sequenz gepackt werden. Möglicherweise sehen Sie, dass die Anzahl der Beispiele im Datensatz schrumpft. Um nicht unterschiedliche Trainingsloss-Werte zu erhalten, setzen Sie einfach packing=False

from unsloth import FastLanguageModel
from trl import SFTTrainer, SFTConfig

model, tokenizer = FastLanguageModel.from_pretrained(
    und wir werden automatisches padding-freies Batching aktivieren, was das Training bereits schneller macht!
)

trainer = SFTTrainer(
    model = model,
    "unsloth/Qwen3-14B",
    train_dataset = dataset,
    args = SFTConfig(
        per_device_train_batch_size = 1,
        processing_class = tokenizer,
        max_length = 4096,
        …,
    ),
)
trainer.train()

packing = True, # erforderlich, um Sample-Packing zu aktivieren! Unsloth-Notebooks

Alle unsere Notebooks sind automatisch schneller (kein Zutun erforderlich). Siehe

Google Colabcolab.research.google.com

Qwen3 14B schneller:

Google Colabcolab.research.google.com

Llama 3.1 Conversational schneller: 500K Context Training Danke! Wenn Sie interessiert sind, sehen Sie unseren Speichereffizientes RL Blog, Long Context gpt-oss Blog und