Long-Context gpt-oss Training
Wir freuen uns, die Unterstützung von Unsloth Flex Attention für das OpenAI gpt-oss Training vorzustellen, die ermöglicht >8× längere Kontextlängen, >50% weniger VRAM-Verbrauch und >1,5× schnellere Ausbildung (ohne Genauigkeitsverlust) im Vergleich zu allen Implementierungen, einschließlich jener mit Flash Attention 3 (FA3). Unsloth Flex Attention macht es möglich, mit einer 60K Kontextlänge auf einer 80GB VRAM H100 GPU für BF16 LoRA zu trainieren. Außerdem:
Du kannst jetzt exportieren/speichern Ihr QLoRA feinabgestimmtes gpt-oss Modell für llama.cpp, vLLM, Ollama oder HF
Wir haben das gpt-oss Training wobei Verluste gegen unendlich gingen auf float16 GPUs (wie T4 Colab)
Wir haben die gpt-oss Implementierung Fehler behoben, die für Unsloth irrelevant sind, am wichtigsten ist dabei die Gewährleistung, dass
swiglu_limit = 7.0während der MXFP4-Inferenz in transformers korrekt angewendet wird
🦥Einführung der Unsloth Flex Attention-Unterstützung
Mit Unsloths Flex Attention-Unterstützung kann eine einzelne 80GB VRAM H100 mit QLoRA bis zu 81K Kontextlänge und mit BF16 LoRA bis zu 60K Kontextlänge verarbeiten! Diese Verbesserungen gelten für BEIDE gpt-oss-20b und gpt-oss-120b! Je größer die verwendete Kontextlänge, desto mehr Vorteile erhalten Sie durch Unsloth Flex Attention:

Im Vergleich dazu erreichen alle anderen nicht-Unsloth-Implementierungen auf einer 80GB GPU maximal 9K Kontextlänge und können nur mit FA3 15K Kontext erreichen. Aber ist FA3 für gpt-oss Training ungeeignet, da es keinen Backward-Pass für Attention Sinks unterstützt. Wenn Sie also zuvor FA3 für gpt-oss Training verwendet haben, empfehlen wir Ihnen es momentan nicht zu benutzen Daher ist die maximale Kontextlänge, die Sie ohne Unsloth auf 80GB VRAM erreichen können, ~9K.
Training mit Unsloth Flex Attention liefert mindestens eine 1,3× Beschleunigung, mit wachsenden Vorteilen bei steigender Kontextlänge und erreicht bis zu 2× schnellere Ausführung. Da Flex Attention mit dem Kontext skaliert, ergeben längere Sequenzen größere Einsparungen sowohl beim VRAM als auch bei der Trainingszeit, wie hier beschrieben.
Ein großes Dankeschön an Rohan Pandey für seine Flex Attention-Implementierung, die direkt die Entwicklung von Unsloths Flex Attention-Implementierung inspiriert hat.
🕶️ Attention Sinks
Das GPT OSS Modell von OpenAI verwendet ein alternierendes Muster aus Sliding Window Attention, Full Attention, Sliding Window Attention und so weiter (SWA, FA, SWA, FA, etc.). Jedes Sliding Window beachtet nur 128 Token (inklusive des aktuellen Tokens), wodurch die Berechnung stark reduziert wird. Das bedeutet jedoch auch, dass lange Kontextwiedergewinnung und -schlussfolgerung aufgrund des kleinen Sliding Windows nutzlos werden. Die meisten Einrichtungen beheben dies, indem sie das Sliding Window auf 2048 oder 4096 Tokens erweitern.
OpenAI nutzte Attention Sinks aus den Efficient Streaming Language Models with Attention Sinks Papier , die zeigen, dass man ein kleines Sliding Window verwenden kann, allerdings muss man eine globale Attention auf das erste Token hinzufügen! Das Paper liefert dazu die folgende gute Illustration:

Das Paper stellt fest, dass der Aufmerksamkeitsmechanismus scheinbar viel Gewicht auf die ersten wenigen Tokens (1 bis 4) legt, und wenn diese während der Sliding Window-Operation entfernt werden, verschwinden diese „wichtigen“ ersten Tokens und verursachen schlechte Langzeit-Kontextwiedergewinnung.
Wenn wir die logarithmische Perplexität auftragen (höher ist schlechter) und nach der voreingestellten Kontextlänge des vortrainierten Modells Langzeit-Inferenz durchführen, sehen wir, dass die Perplexität stark ansteigt (nicht gut). Die rote Linie (verwendet Attention Sinks) bleibt jedoch niedrig, was sehr gut ist!

Das Paper zeigt auch, dass die Attention Is Off By One Methode teilweise funktioniert, allerdings muss man ein paar zusätzliche Sink-Tokens hinzufügen, um niedrigere Perplexitäten zu erzielen. Das Paper zeigt, dass das Hinzufügen eines einzigen lernbaren Sink-Tokens bemerkenswert gut funktioniert! Und genau das hat OpenAI für GPT-OSS getan!

📐Unsloths Flex Attention-Implementierung
Flex Attention https://pytorch.org/blog/flexattention/ ist äußerst mächtig, da sie dem Anwender 2 Anpassungswege für den Aufmerksamkeitsmechanismus bietet - ein Score-Modifikator (f) und ein Maskierungsfunktion (M).
Der Score-Modifikator (f) ermöglicht es uns, die Attention-Logits vor der Softmax-Operation zu bearbeiten, und das Maskierungsfunktion (M) ermöglicht uns, Operationen zu überspringen, wenn wir sie nicht benötigen (z. B. sieht Sliding Window Attention nur die letzten 128 Tokens).
Der Trick ist, dass Flex Attention schnelle automatisch generierte Triton-Kernel mit beliebigen Score-Modifikatoren und Maskierungsfunktionen bereitstellt!
σ(s×f(QKT+M))
Das bedeutet, dass wir Flex Attention verwenden können, um Attention Sinks zu implementieren! Die Implementierung eines einzelnen Attention Sinks ist sowohl in OpenAIs ursprünglichem GPT-OSS-Repo als auch in der Implementierung von HuggingFace transformers verfügbar.
Das Obige zeigt, dass wir das Sink ganz am Ende der Q @ K.T konkateniieren, die Softmax durchführen und die letzte Spalte entfernen, welche das Sink-Token war.
Durch die Verwendung einiger Visualisierungswerkzeuge aus Flex Attentions Github-Repo, können wir dies visualisieren. Angenommen, die Sequenzlänge war 16 und ein Sliding Window von 5. Links ist die letzte Sink-Spalte (Standardimplementierung) und rechts ist, wenn wir die Sink-Position auf Index 0 verschieben (unsere Implementierung).
Sink-Position am Ende (Standard)

Sink-Position auf Index 0 verschieben

Interessante Erkenntnis: Die offizielle Flex Attention Sliding Window-Implementierung betrachtet die Fenstergröße als die Anzahl der letzten Tokens PLUS EINS da sie das aktuelle Token einschließt. Die HuggingFace- und GPT OSS-Implementierungen sehen strikt nur die letzten N Tokens. D. h. das Folgende stammt von https://pytorch.org/blog/flexattention/ und https://github.com/meta-pytorch/attention-gym:
Standard Flex Attention (3+1 Tokens)

HuggingFace, GPT-OSS (3+0 Tokens)

Wir bestätigten dies auch anhand der offiziellen GPT-OSS-Implementierung von OpenAI, ob wir auf die letzten N oder N+1 Tokens achten, hier: https://github.com/openai/gpt-oss/blob/main/gpt_oss/torch/model.py

Und wir sehen, dass nur die letzten 3 Tokens (nicht 3+1) beachtet werden! Das bedeutet, anstelle von <= SLIDING_WINDOW, verwenden Sie < SLIDING_WINDOW (d. h. Verwenden von weniger als, nicht gleich).
Da wir den Sink-Token-Index an den ersten Platz verschoben haben, müssen wir 1 zu q_idx addieren, um korrekt zu indexieren:
Um unsere Index-0-Implementierung zu bestätigen, verifizierten wir, dass der Trainingsverlust mit den Standard-Hugging-Face-Läufen (ohne Unsloth Flex Attention) konsistent bleibt, wie in unserem Diagramm gezeigt:

📜 Mathematische Herleitung für Attention Sinks
Es gibt eine andere Möglichkeit, die Attention Sinks ohne Padding von K und V zu berechnen. Zuerst stellen wir fest, dass die Softmax-Operation das tut, und wir wollen vorerst die zweite Version mit Sinks als Skalar:\
Wir können das logsumexp von Flex Attention über return_lse = True erhalten, und so tun wir:
Und wir können nun leicht die Sink-Version der Attention ableiten. Wir stellen jedoch fest, dass dieser Prozess etwas höhere Fehler als der Null-Padding-Ansatz aufweist, daher verwenden wir standardmäßig weiterhin unsere ursprüngliche Version.
💾NEU: Speicherung als GGUF, vLLM nach gpt-oss-Training
Sie können jetzt gpt-oss mit QLoRA feinabstimmen und das Modell direkt speichern, exportieren oder zusammenführen zu llama.cpp, vLLM, oder HF - nicht nur Unsloth. Wir werden hoffentlich bald ein kostenloses Notebook veröffentlichen.
Früher war jedes QLoRA feinabgestimmte gpt-oss Modell darauf beschränkt, in Unsloth zu laufen. Wir haben diese Einschränkung aufgehoben, indem wir die Möglichkeit eingeführt haben, in MXFP4 nativen Format mit save_method="mxfp4" und On-Demand-Dequantisierung von MXFP4 Basismodelle (wie gpt-oss) zusammenzuführen, wodurch es möglich ist, Ihr feinabgestimmtes Modell im bf16-Format zu exportieren mithilfe von save_method="merged_16bit" .
Der MXFP4 Das native Merge-Format bietet im Vergleich zum bf16-Formaterhebliche Leistungsverbesserungen: Es benötigt bis zu 75% weniger Festplattenspeicher, reduziert den VRAM-Verbrauch um 50%, beschleunigt das Mergen um das 5–10-fache und ermöglicht eine viel schnellere Konvertierung in das GGUF Format.
Nach der Feinabstimmung Ihres gpt-oss-Modells können Sie es in MXFP4 Format zusammenführen mit:
Wenn Sie das Modell lieber mergen und ins Hugging-Face-Repo pushen möchten, verwenden Sie:
Um Inferenz auf dem zusammengeführten Modell auszuführen, können Sie unter anderem vLLM und Llama.cpp verwenden. OpenAI empfiehlt diese Inference-Einstellungen für beide Modelle: temperature=1.0, top_p=1.0, top_k=0
✨ Speichern für Llama.cpp
Holen Sie sich die neueste
llama.cppauf GitHub hier. Sie können auch den unten stehenden Build-Anweisungen folgen. Ändern Sie-DGGML_CUDA=ONzu-DGGML_CUDA=OFFwenn Sie keine GPU haben oder nur CPU-Inferenz wünschen.Konvertieren Sie das MXFP4 zusammengeführte Modell:
Führen Sie Inferenz auf dem quantisierten Modell aus:
♦️Direktes Fine-Tuning von gpt-oss
Wir haben auch Unterstützung für direktes Fine-Tuning von gpt-oss Modellen hinzugefügt, indem wir Patches implementiert haben, die das Laden des nativen MXFP4-quantisierten Formats ermöglichen. Das macht es möglich, das Modell 'openai/gpt-oss' mit weniger als 24GB VRAM zu laden und mit QLoRA feinabzustimmen. Laden Sie das Modell einfach mit:
fügen Sie eine Peft-Schicht hinzu mit FastLanguageModel.get_peft_model und führen Sie dann SFT-Fine-Tuning über das Peft-Modell aus.
🐛Bugfixes für gpt-oss
Wir wir haben kürzlich mit Hugging Face zusammengearbeitet um Inferenzprobleme zu lösen, indem wir OpenAIs Kernel verwendeten und sicherstellten, dass swiglu_limit = 7.0 während der MXFP4-Inferenz korrekt angewendet wird.
Basierend auf Nutzerfeedback entdeckten wir, dass verlängerte QLoRA-Trainingsläufe (über 60 Schritte hinaus) dazu führen konnten, dass der Verlust divergiert und schließlich zu einem Fehler führt. Dieses Problem trat nur auf Geräten auf, die BF16 nicht unterstützen und stattdessen auf F16 zurückfallen (z. B. T4 GPUs). Wichtig ist, dass es das QLoRA-Training auf A100- oder H100-GPUs sowie LoRA-Training auf f16-GPUs nicht beeinflusste.
Nach umfangreichen Untersuchungen haben wir das Verhalten des Trainingsverlusts nun über alle GPU-Setups hinweg angeglichen, einschließlich GPUs, die auf F16 beschränkt sind. Wenn Sie zuvor Probleme deswegen hatten, empfehlen wir die Verwendung unseres neuen aktualisierten gpt-oss Notebooks!

Wir mussten viele Experimente durchführen, um die Trainingsverlustkurve von float16 so zu verschieben, dass sie der von bfloat16-Maschinen (blaue Linie) entspricht. Wir fanden Folgendes:
Reines float16 geht bei Schritt 50 gegen unendlich
Wir fanden, dass die Down-Projektionen im MoE große Ausreißer aufweisen
Aktivierungen müssen in bfloat16 oder float32 gespeichert werden
Nachfolgend wird die absolute Größenordnung der Aktivierungen für GPT OSS 20B gezeigt, und einige spikes — dies würde auf float16-Maschinen überlaufen, da der maximale Bereich von float16 65504 beträgt.
Wir haben das in Unsloth behoben, sodass alle float16-Trainings sofort funktionieren!

🔢 Implementierungen für Sink Attention
OpenAIs Sink-Token-Implementierung ist hier verfügbar. Wir stellen sie unten zur Verfügung:
Die HuggingFace transformers-Implementierung ist hier verfügbar. Wir stellen sie ebenfalls unten zur Verfügung:
Zuletzt aktualisiert
War das hilfreich?

