> 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/loslegen/reinforcement-learning-rl-guide/grpo-long-context.md). # Reinforcement Learning GRPO mit 7x längerem Kontext Erfahre, wie Unsloth ultra-langes Kontext-RL-Fine-Tuning ermöglicht. Die größte Herausforderung beim Reinforcement Learning (RL) ist die Unterstützung langer Denkspuren. Wir führen neue Batching-Algorithmen ein, um \~**7x längerer Kontext** (kann mehr als 12x sein) RL-Training ohne Einbußen bei Genauigkeit oder Geschwindigkeit im Vergleich zu anderen optimierten Setups, die FA3, Kernel und chunked losses verwenden. * Unsloth trainiert gpt-oss QLoRA jetzt mit **380K Kontext** auf einer einzelnen NVIDIA-B200-GPU mit 192 GB * [Qwen3](/docs/de/modelle/tutorials/qwen3-how-to-run-and-fine-tune.md#fine-tuning-qwen3-with-unsloth)-8B GRPO erreicht **110K Kontext** auf einer H100 mit 80 GB VRAM über [vLLM](#vllm-for-rl) und QLoRA, und **65K** für [gpt-oss](/docs/de/modelle/gpt-oss-how-to-run-and-fine-tune/gpt-oss-reinforcement-learning.md) mit BF16 LoRA. * Mit 24 GB VRAM erreicht gpt-oss 20K Kontext und 32K für [Qwen3-VL](/docs/de/modelle/tutorials/qwen3-how-to-run-and-fine-tune/qwen3-vl-how-to-run-and-fine-tune.md)-8B QLoRA * Unsloth-GRPO-RL-Läufe mit Llama, Gemma und allen Modellen unterstützen automatisch längere Kontexte Unsere neuen Datenbewegungs- und Batching-Kernel und -Algorithmen ermöglichen mehr Kontext durch: * Dynamisch [flaches Sequenz-Chunking](#flattened-sequence-length-chunking) um das Materialisieren riesiger Logit-Tensoren zu vermeiden und * [Auslagern von Log-Softmax](#offloading-activations-for-log-softmax) Aktivierungen, wodurch ein stilles Speicherwachstum im Laufe der Zeit verhindert wird. {% hint style="info" %} **Sie können alle Funktionen in Unsloth miteinander kombinieren:** 1. Unslooths [Gewichtsteilungs](/docs/de/loslegen/reinforcement-learning-rl-guide/memory-efficient-rl.md) Funktion mit [vLLM](https://github.com/vllm-project/vllm) und unserer Standby-Funktion in [Speichereffizientes RL](/docs/de/loslegen/reinforcement-learning-rl-guide/memory-efficient-rl.md) 2. Unslooths [Flex Attention](/docs/de/modelle/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md) für gpt-oss mit langem Kontext und unserer [500K Context Training](/docs/de/blog/500k-context-length-fine-tuning.md) 3. Float8-Training in [FP8 RL](/docs/de/loslegen/reinforcement-learning-rl-guide/fp8-reinforcement-learning.md) und Unslooths [asynchronem Gradient Checkpointing](https://unsloth.ai/blog/long-context) und vieles mehr {% endhint %} ### :tada:Erste Schritte Um loszulegen, können Sie jede vorhandene [GRPO-Notebooks](/docs/de/loslegen/unsloth-notebooks.md#grpo-reasoning-rl-notebooks) (oder Unsloth lokal aktualisieren): {% columns %} {% column width="33.33333333333333%" %} [**gpt-oss-20b**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt-oss-\(20B\)-GRPO.ipynb) GSPO {% embed url="" %} {% endcolumn %} {% column width="33.33333333333333%" %} [**Qwen3-VL-8B**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_VL_\(8B\)-Vision-GRPO.ipynb) Vision-RL {% embed url="" %} {% endcolumn %} {% column width="33.33333333333333%" %} [Qwen3-8B - **FP8**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_8B_FP8_GRPO.ipynb) L4-GPU {% embed url="" %} {% endcolumn %} {% endcolumns %} Die Einführung von Unsloth für Ihre RL-Aufgaben bietet ein robustes Framework für die effiziente Verwaltung großskaliger Modelle. Um die Verbesserungen von Unsloth effektiv zu nutzen: * **Hardware-Empfehlungen**: Verwendung einer NVIDIA H100 oder gleichwertig für eine optimale VRAM-Nutzung. * **Konfigurationshinweise**: Stellen Sie sicher, `batch_size` und `gradient_accumulation_steps` dass die Einstellungen zu Ihren Rechenressourcen passen, um die beste Leistung zu erzielen. {% hint style="success" %} Aktualisieren Sie Unsloth auf die neueste PyPI-Version, um die neuesten Updates zu erhalten: ``` pip install --upgrade --no-cache-dir unsloth unsloth_zoo ``` {% endhint %} Unsere Benchmarks zeigen die eingesparten Speichermengen im Vergleich zu früheren Versionen für GPT OSS und Qwen3-8B. Beide untenstehenden Diagramme (ohne [Standby](/docs/de/loslegen/reinforcement-learning-rl-guide/memory-efficient-rl.md)) wurden ausgeführt mit `batch_size = 4` und `gradient_accumulation_steps=2` , da Standby designbedingt den gesamten VRAM nutzt. Für unsere Benchmarks vergleichen wir BF16 GRPO mit Hugging Face, bei dem alle Optimierungen aktiviert sind (alle Kernel in der kernels-Bibliothek, Flash Attention 3, chunked-loss-Kernel usw.): ### :1234:Chunking der abgeflachten Sequenzlänge Früher reduzierte Unsloth den Speicherverbrauch von RL, indem das vollständige Materialisieren des Logits-Tensors durch Chunking über die Batch-Dimension vermieden wurde. Eine grobe Abschätzung des für das Materialisieren von Logits während des Forward-Passes benötigten VRAM ist in Gleichung (1) dargestellt. $$ \text{Equation 1: } \text{Logit Memory (GB)} = \frac{\text{batch size} \times\text{context length} \times \text{vocab dim}}{1024^3} $$ Mit dieser Formulierung würde eine Konfiguration mit `batch_size = 4`, `context_length = 8192`, und `vocab_dim = 128,000` würde ungefähr erfordern **3,3 GB VRAM** zum Speichern des Logit-Tensors. Über [Long Context gpt-oss](/docs/de/modelle/gpt-oss-how-to-run-and-fine-tune/long-context-gpt-oss-training.md) im letzten Jahr führten wir dann einen gefussten Loss-Ansatz für GRPO ein. Dieser Ansatz stellt sicher, dass jeweils nur ein einzelnes Batch-Sample verarbeitet wird, wodurch die maximale Speichernutzung deutlich reduziert wird. Bei derselben Konfiguration sinkt die VRAM-Nutzung auf ungefähr **0,83 GB**, wie in Gleichung (2) dargestellt. $$ \text{Equation 2: }\text{Logit Memory (GB)} = \frac{\text{context length} \times \text{vocab dim}}{1024^3} $$

Abbildung 1: gpt-oss BF16 GRPO LoRA (Unsloth vs. HF mit allen aktivierten Optimierungen)

Abbildung 2: Qwen3-8B QLoRA GRPO LoRA (Unsloth vs. HF mit allen aktivierten Optimierungen)

In diesem Update erweitern wir dieselbe Idee weiter, indem wir auch Chunking über die **Sequenzdimension** einführen. Statt Logits für die gesamte `(batch_size × context_length)` Fläche auf einmal zu materialisieren, flachen wir diese Dimensionen ab und verarbeiten sie in kleineren Chunks mithilfe eines konfigurierbaren Multiplikators. Dadurch kann Unsloth erheblich längere Kontexte unterstützen, ohne die maximale Speichernutzung zu erhöhen. In der untenstehenden Abbildung 5 verwenden wir einen Multiplikator von `max(4, context_length // 4096)`, wobei je nach gewünschtem Speicher-Leistungs-Kompromiss jeder beliebige Multiplikator angegeben werden kann. Mit dieser Einstellung benötigt dieselbe Beispielkonfiguration (`batch_size = 4`, `context_length = 8192`, `vocab_dim = 128,000`) benötigt jetzt nur noch **0,207 GB VRAM** für das Materialisieren der Logits. $$ \text{Equation 3: }\text{Logit Memory (GB)} = \frac{\frac{\text{context length}}{\text{multiplier}} \times \text{vocab dim}}{1024^3} $$

Abbildung 3: gpt-oss-20b (H100) Unsloth neu vs. alt

Abbildung 4: Qwen3-8B (H100) Unsloth neu vs. alt

Abbildung 5: gpt-oss-20b (H100)

Abbildung 6: Qwen3-8B (B200)

Dieses Update spiegelt sich im kompilierten `chunked_hidden_states_selective_log_softmax` unten wider, das nun Chunking sowohl über die Batch- als auch über die Sequenzdimension unterstützt. Um den Logit-Tensor (`[batch_size, context_length, vocab_dim]`), wird er immer über die Batch-Dimension gechunked. Zusätzliches Chunking der Sequenz wird gesteuert über `unsloth_logit_chunk_multiplier` in der GRPO-Konfiguration; falls nicht gesetzt, ist der Standardwert `max(4, context_length // 4096)`. Im folgenden Beispiel, `input_ids_chunk[0]` entspricht der Größe der Mini-Batches der Hidden States in Optimierung 2. ```python logprobs_chunk = chunked_hidden_states_selective_log_softmax( new_hidden_states_chunk, lm_head, completion_ids, chunks=input_ids_chunk.shape[0]*multiplier, logit_scale_multiply=logit_scale_multiply, logit_scale_divide=logit_scale_divide, logit_softcapping=logit_softcapping, temperature=temperature, ) ``` 1. Wir verwenden torch.compile mit benutzerdefinierten Compile-Optionen, um den VRAM zu reduzieren und die Geschwindigkeit zu erhöhen. 2. Alle gechunkten Logits werden zur Erhaltung der Genauigkeit in float32 hochgestuft. 3. Wir unterstützen Logit-Softcapping, Temperaturskalierung und alle anderen Funktionen. ### :ghost:Chunking der Hidden States Wir haben außerdem beobachtet, dass bei längeren Kontextlängen Hidden States einen erheblichen Anteil am Speicherverbrauch haben können. Zur Demonstration nehmen wir an, `hidden_states_dim=4096`. Der entsprechende Speicherverbrauch folgt einer ähnlichen Formulierung wie im Logits-Fall, wie unten gezeigt. $$ \text{Hidden States Memory (GB)} = \frac{\text{batch size} \times\text{context length} \times \text{hidden states dim}}{1024^3} $$ Mit einem `batch_size = 8` und `context_length = 64000`, dies würde zu einer VRAM-Nutzung von ungefähr **2 GB**. In diesem Release führen wir optionales Chunking über die Batch-Dimension für den Hidden-States-Tensor während der Log-Wahrscheinlichkeitsberechnung ein. Dadurch würde sich die VRAM-Nutzung durch die Batchgröße teilen oder in diesem Fall **0,244 GB**.Dies reduziert den maximal benötigten VRAM zum Materialisieren der Hidden States, wie in der aktualisierten Gleichung unten dargestellt: $$ \text{Hidden States Memory (GB)} = \frac{\text{context length} \times \text{hidden states dim}}{1024^3} $$ Ähnlich wie unser Cross-Entropy-Loss in unserem [500K Context Training](/docs/de/blog/500k-context-length-fine-tuning.md) Release, die neue Implementierung **stimmt das Batching der Hidden States automatisch ab**. Nutzer können dieses Verhalten auch über `unsloth_grpo_mini_batch`. Eine Erhöhung von `unsloth_grpo_mini_batch` über den optimalen Wert hinaus kann im Vergleich zur vorherigen Loss-Funktion zu einer leichten Leistungssteigerung oder Verlangsamung führen (meistens schneller). Während eines GPT-OSS-Laufs (`context_length = 8192, batch_size = 4, gradient_accumulation_steps = 2`), führt das Setzen von `unsloth_grpo_mini_batch = 1` und `unsloth_logit_chunk_multiplier = 4` führt zu **kaum bis keine Geschwindigkeitsverschlechterung, während die VRAM-Nutzung um ungefähr 5 GB reduziert wird** im Vergleich zu älteren Versionen von Unsloth.
{% hint style="success" %} **Hinweis:** In den Abbildungen 3 und 4 verwenden wir die maximale effektive Batchgröße, die in diesem Setup 8 beträgt. Die effektive Batchgröße berechnet sich als `batch_size × gradient_accumulation_steps`, also `4 × 2 = 8`. Für eine ausführlichere Erklärung, wie effektive Batchgrößen in RL funktionieren, siehe unsere [erweiterte RL-Dokumentation](/docs/de/loslegen/reinforcement-learning-rl-guide/advanced-rl-documentation.md). {% endhint %} ### :cactus:Auslagern von Aktivierungen für Log-Softmax Während der Entwicklung dieses Releases stellten wir fest, dass beim Kacheln über die Batch-Dimension für Hidden States die Aktivierungen nach der gefussten Berechnung von Logits und Log-Wahrscheinlichkeiten nicht ausgelagert wurden. Da die Logits jeweils eine Batch nach der anderen mithilfe von `hidden_states[i] @ lm_head`, galt die bestehende Logik für das Auslagern von Aktivierungen und Gradient Checkpointing, die innerhalb des Forward-Passes des Modells arbeitet, in diesem Fall nicht. Um dies zu beheben, haben wir explizite Logik hinzugefügt, um diese Aktivierungen außerhalb des Forward-Passes des Modells auszulagern, wie im folgenden Python-Pseudocode gezeigt: ```python class Unsloth_Offloaded_Log_Softmax(torch.autograd.Function): def forward(...): with torch.no_grad(): output = chunked_hidden_states_selective_log_softmax(hidden_states, lm_head, ...) return output def backward(ctx, grad_output): hidden_states = ctx.saved_hidden_states hidden_states.requires_grad_(True) with torch.enable_grad(): output = chunked_hidden_states_selective_log_softmax(hidden_states, lm_head, ...) torch.autograd.backward(output, grad_output) return ... ``` {% hint style="success" %} **Hinweis:** Diese Funktion ist nur wirksam, wenn über die Batch-Dimension gechunked wird oder wenn `unsloth_grpo_mini_batch > 1`. Wenn alle Hidden States während des Forward-Passes auf einmal materialisiert werden (d. h., `unsloth_grpo_mini_batch = 1`), benötigt der Backward-Pass unabhängig davon, ob Aktivierungen ausgelagert werden, dieselbe Speichermenge auf der GPU. Da das Auslagern von Aktivierungen in diesem Fall eine leichte Verlangsamung ohne Reduzierung des Speicherverbrauchs mit sich bringt, bietet es keinen Vorteil. {% endhint %} ### :sparkles:Parameter konfigurieren: Wenn Sie `unsloth_grpo_mini_batch` und `unsloth_logit_chunk_multiplier`, werden wir **diese beiden Parameter automatisch anpassen lassen** möchten, basierend auf Ihrem verfügbaren VRAM und abhängig von der Größe Ihrer Kontextlänge. Unten sehen Sie jedoch, wie Sie diese Variablen in Ihrem GRPO-Lauf ändern können: ```python training_args = GRPOConfig( ... unsloth_grpo_mini_batch = 3 unsloth_logit_chunk_multiplier = 2 ... ) ``` Eine Visualisierung der Optimierungen und `unsloth_grpo_mini_batch` und `unsloth_logit_chunk_multiplier` ist im Diagramm unten zu sehen.
Die 3 Matrizen repräsentieren den insgesamt größeren Batch oder `unsloth_grpo_mini_batch` (dargestellt durch die Anzahl der schwarzen Klammern), und die Zeilen jeder der Matrizen stellen die Kontextlänge dar, die die `unsloth_logit_chunk_multiplier` Sequenzlänge in Chunks unterteilt (dargestellt durch die Anzahl der roten Klammern). ### :vhs:vLLM für RL **Bei RL-Workflows ist die Inferenz-/Generierungsphase der Hauptengpass**. Um dies zu adressieren, nutzen wir [vLLM](https://github.com/vllm-project/vllm), welches die Generierung im Vergleich zur normalen Generierung um bis zu 11x beschleunigt hat. Seit GRPO im letzten Jahr populär wurde, ist vLLM ein Kernbestandteil der meisten RL-Frameworks, einschließlich Unsloth. Wir möchten dem vLLM-Team und allen Mitwirkenden für ihre Arbeit unseren großen Dank aussprechen, da sie eine entscheidende Rolle dabei spielen, Unsloths RL zu verbessern! Um RL mit längerem Kontext auszuprobieren, können Sie jede vorhandene [GRPO-Notebooks](/docs/de/loslegen/unsloth-notebooks.md#grpo-reasoning-rl-notebooks) (oder Unsloth lokal aktualisieren): {% columns %} {% column width="33.33333333333333%" %} [**gpt-oss-20b**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/gpt-oss-\(20B\)-GRPO.ipynb) - GSPO {% embed url="" %} {% endcolumn %} {% column width="33.33333333333333%" %} [**Qwen3-VL-8B**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_VL_\(8B\)-Vision-GRPO.ipynb) Vision-RL {% embed url="" %} {% endcolumn %} {% column width="33.33333333333333%" %} [Qwen3-8B - **FP8**](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_8B_FP8_GRPO.ipynb) L4-GPU {% embed url="" %} {% endcolumn %} {% endcolumns %} Danksagung: Ein riesiges Dankeschön an das Hugging-Face-Team und die Bibliotheken dafür, dass sie Unsloth antreiben und dies möglich machen. --- # 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/loslegen/reinforcement-learning-rl-guide/grpo-long-context.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.