> 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/advanced-rl-documentation.md).

# Erweiterte Dokumentation zu Reinforcement Learning

Erweiterte Dokumentationseinstellungen bei der Verwendung von Unsloth mit GRPO.

Detaillierte Anleitungen zur Durchführung von GRPO mit Unsloth für Batching, Generierung und Trainingsparameter:

## Trainingsparameter

* **`beta`** *(float, Standardwert 0.0)*: KL-Koeffizient.
  * `0.0` ⇒ kein Referenzmodell geladen (weniger Speicher, schneller).
  * Höher `beta` beschränkt die Policy darauf, näher an der Referenz-Policy zu bleiben.
* **`num_iterations`** *(int, Standardwert 1)*: PPO-Epochen pro Batch (μ im Algorithmus).\
  Spielt Daten innerhalb jedes Gradient-Akkumulationsschritts erneut durch; z. B., `2` = zwei Forward-Pässe pro Akkumulationsschritt.
* **`epsilon`** *(float, Standardwert 0.2)*: Clipping-Wert für Verhältnisse der Log-Wahrscheinlichkeiten auf Token-Ebene (typischer Verhältnisbetrag ≈ \[-1.2, 1.2] mit Standard-ε).
* **`delta`** *(float, optional)*: Ermöglicht **obere** Clipping-Grenze für **zweiseitiges GRPO** wenn gesetzt. Wenn `Keine`, wird das standardmäßige GRPO-Clipping verwendet. Empfohlen `> 1 + ε` wenn aktiviert (laut INTELLECT-2-Bericht).
* **`epsilon_high`** *(float, optional)*: Obergrenzen-ε; Standardwert ist `epsilon` wenn nicht gesetzt. DAPO empfiehlt **0.28**.
* **`importance_sampling_level`** *("token" | "sequence", Standardwert "token")*:
  * `"token"`: rohe Verhältnisse pro Token (ein Gewicht pro Token).
  * `"sequence"`: mittelt die Token-Verhältnisse zu einem einzelnen Verhältnis auf Sequenzebene.\
    GSPO zeigt, dass Sampling auf Sequenzebene oft ein stabileres Training für Belohnungen auf Sequenzebene ergibt.
* **`reward_weights`** *(list\[float], optional)*: Ein Gewicht pro Belohnung. Wenn `Keine`, sind alle Gewichte = 1.0.
* **`scale_rewards`** *(str|bool, Standardwert "group")*:
  * `Wahr` oder `"group"`: skaliert anhand der **Standardabweichung innerhalb jeder Gruppe** (Einheitsvarianz in der Gruppe).
  * `"batch"`: skaliert anhand der **Standardabweichung über den gesamten Batch** (gemäß PPO-Lite).
  * `Falsch` oder `"none"`: **keine Skalierung**. Dr. GRPO empfiehlt, nicht zu skalieren, um einen Schwierigkeits-Bias durch Std-Skalierung zu vermeiden.
* **`loss_type`** *(str, Standardwert "dapo")*:
  * `"grpo"`: normalisiert über die Sequenzlänge (Längen-Bias; nicht empfohlen).
  * `"dr_grpo"`: normalisiert durch eine **globale Konstante** (eingeführt in Dr. GRPO; entfernt Längen-Bias). Konstante ≈ `max_completion_length`.
  * `"dapo"` **(Standard)**: normalisiert durch **aktive Tokens im global akkumulierten Batch** (eingeführt in DAPO; entfernt Längen-Bias).
  * `"bnpo"`: normalisiert durch **aktive Tokens nur im lokalen Batch** allein (Ergebnisse können mit der lokalen Batchgröße variieren; entspricht GRPO, wenn `per_device_train_batch_size == 1`).
* **`mask_truncated_completions`** *(bool, Standardwert False)*:\
  Wenn `Wahr`, werden abgeschnittene Vervollständigungen vom Loss ausgeschlossen (von DAPO für Stabilität empfohlen).\
  **Hinweis**: Es gibt einige KL-Probleme mit diesem Flag, daher empfehlen wir, es zu deaktivieren.

  ```python
  # Wenn mask_truncated_completions aktiviert ist, setze abgeschnittene Vervollständigungen in completion_mask auf 0
  if self.mask_truncated_completions:
      truncated_completions = ~is_eos.any(dim=1)
      completion_mask = completion_mask * (~truncated_completions).unsqueeze(1).int()
  ```

  Dies kann alle `completion_mask` Einträge auf 0 setzen, wenn viele Vervollständigungen abgeschnitten werden, wodurch `n_mask_per_reward = 0` und KL zu NaN wird. [Siehe](https://github.com/unslothai/unsloth-zoo/blob/e705f7cb50aa3470a0b6e36052c61b7486a39133/unsloth_zoo/rl_replacements.py#L184)
* **`vllm_importance_sampling_correction`** *(bool, Standardwert True)*:\
  Wendet **Truncated Importance Sampling (TIS)** an, um Off-Policy-Effekte zu korrigieren, wenn die Generierung (z. B. vLLM / fast\_inference) vom Trainings-Backend abweicht.\
  In Unsloth wird dies **automatisch auf True gesetzt** wenn Sie vLLM/fast\_inference verwenden; andernfalls **Falsch**.
* **`vllm_importance_sampling_cap`** *(float, Standardwert 2.0)*:\
  Trunkierungsparameter **C** für TIS; setzt eine obere Grenze für das Importance-Sampling-Verhältnis, um die Stabilität zu verbessern.
* **`dtype`** bei der Wahl von float16 oder bfloat16, siehe [FP16 vs. BF16 für RL](/docs/de/loslegen/reinforcement-learning-rl-guide/advanced-rl-documentation/fp16-vs-bf16-for-rl.md)

### RL auf nicht unterstützten Modellen:

Sie können RL mit Unsloth auch auf Modellen ausführen, die von vLLM nicht unterstützt werden, wie z. B. [Qwen3.5](/docs/de/modelle/qwen3.5/fine-tune.md). Setzen Sie einfach `fast_inference=False` beim Laden des Modells.

```python
from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Qwen3.5-4B",
    fast_inference=False,
)
```

## Generierungsparameter

* `temperature (float, Standardwert 1.0):`\
  Temperatur für das Sampling. Je höher die Temperatur, desto zufälliger die Vervollständigungen. Achten Sie darauf, eine relativ hohe Temperatur (1.0) zu verwenden, um Vielfalt in den Generierungen zu haben, was das Lernen unterstützt.
* `top_p (float, optional, Standardwert 1.0):`\
  Float, der die kumulative Wahrscheinlichkeit der Top-Token steuert, die berücksichtigt werden sollen. Muss in (0, 1] liegen. Auf 1.0 setzen, um alle Tokens zu berücksichtigen.
* `top_k (int, optional):`\
  Anzahl der Vokabular-Tokens mit der höchsten Wahrscheinlichkeit, die für das Top-k-Filtering beibehalten werden sollen. Wenn None, wird das Top-k-Filtering deaktiviert und alle Tokens werden berücksichtigt.
* `min_p (float, optional):`\
  Minimale Token-Wahrscheinlichkeit, die durch die Wahrscheinlichkeit des wahrscheinlichsten Tokens skaliert wird. Sie muss ein Wert zwischen 0.0 und 1.0 sein. Typische Werte liegen im Bereich 0.01-0.2.
* `repetition_penalty (float, optional, Standardwert 1.0):`\
  Float, der neue Tokens bestraft, basierend darauf, ob sie im Prompt und im bisher generierten Text vorkommen. Werte > 1.0 ermutigen das Modell, neue Tokens zu verwenden, während Werte < 1.0 das Modell dazu ermutigen, Tokens zu wiederholen.
* `steps_per_generation: (int, optional):`\
  Anzahl der Schritte pro Generierung. Wenn None, ist der Standardwert `gradient_accumulation_steps`. Gegenseitig ausschließend mit `generation_batch_size`.

{% hint style="info" %}
Es ist etwas verwirrend, mit diesem Parameter herumzuspielen; es wird empfohlen, `per_device_train_batch_size` und das Gradient Accumulation für die Batchgrößen zu bearbeiten
{% endhint %}

## Batch- und Throughput-Parameter

### Parameter, die Batches steuern

* **`train_batch_size`**: Anzahl der Samples **pro Prozess** pro Schritt.\
  Wenn diese Ganzzahl **kleiner als `num_generations`**, wird standardmäßig auf `num_generations`.
* **`steps_per_generation`**: Anzahl von **Mikro-Batches** die zu **einer Generierung** Loss-Berechnung beitragen (nur Forward-Pässe).\
  Alle `steps_per_generation` Schritte wird ein neuer Batch an Daten generiert; das Timing der Backpropagation hängt ab von `gradient_accumulation_steps`.
* **`num_processes`**: Anzahl verteilter Trainingsprozesse (z. B. GPUs / Worker).
* **`gradient_accumulation_steps`** (auch bekannt als `gradient_accumulation`): Anzahl der Mikro-Batches, die akkumuliert werden, bevor **vor** Backpropagation und Optimizer-Update angewendet werden.
* **Effektive Batchgröße**:

  ```
  effective_batch_size = steps_per_generation * num_processes * train_batch_size
  ```

  Gesamtzahl der Samples, die vor einem Update zu den Gradienten beitragen (über alle Prozesse und Schritte hinweg).
* **Optimizer-Schritte pro Generierung**:

  ```
  optimizer_steps_per_generation = steps_per_generation / gradient_accumulation_steps
  ```

  Beispiel: `4 / 2 = 2`.
* **`num_generations`**: Anzahl der generierten **pro Prompt** (angewendet **nach** bei der Berechnung von `effective_batch_size`).\
  Die Anzahl der **eindeutigen Prompts** in einem Generierungszyklus ist:

  ```
  unique_prompts = effective_batch_size / num_generations
  ```

  **Muss > 2 sein** damit GRPO funktioniert.

### GRPO-Batch-Beispiele

Die Tabellen unten veranschaulichen, wie Batches durch die Schritte fließen, wann Optimizer-Updates stattfinden und wie neue Batches generiert werden.

#### Beispiel 1

```
num_gpus = 1
per_device_train_batch_size = 3
gradient_accumulation_steps = 2
steps_per_generation = 4

effective_batch_size = 4 * 3 * 1 = 12
num_generations = 3
```

**Generierungszyklus A**

| Schritt | Batch    | Hinweise                                |
| ------: | -------- | --------------------------------------- |
|       0 | \[0,0,0] |                                         |
|       1 | \[1,1,1] | → Optimizer-Update (Akkum = 2 erreicht) |
|       2 | \[2,2,2] |                                         |
|       3 | \[3,3,3] | Optimizer-Update                        |

**Generierungszyklus B**

| Schritt | Batch    | Hinweise                                |
| ------: | -------- | --------------------------------------- |
|       0 | \[4,4,4] |                                         |
|       1 | \[5,5,5] | → Optimizer-Update (Akkum = 2 erreicht) |
|       2 | \[6,6,6] |                                         |
|       3 | \[7,7,7] | Optimizer-Update                        |

#### Beispiel 2

```
num_gpus = 1
per_device_train_batch_size = 3
steps_per_generation = gradient_accumulation_steps = 4

effective_batch_size = 4 * 3 * 1 = 12
num_generations = 3
```

**Generierungszyklus A**

| Schritt | Batch    | Hinweise                              |
| ------: | -------- | ------------------------------------- |
|       0 | \[0,0,0] |                                       |
|       1 | \[1,1,1] |                                       |
|       2 | \[2,2,2] |                                       |
|       3 | \[3,3,3] | Optimizer-Update (Akkum = 4 erreicht) |

**Generierungszyklus B**

| Schritt | Batch    | Hinweise                              |
| ------: | -------- | ------------------------------------- |
|       0 | \[4,4,4] |                                       |
|       1 | \[5,5,5] |                                       |
|       2 | \[6,6,6] |                                       |
|       3 | \[7,7,7] | Optimizer-Update (Akkum = 4 erreicht) |

#### Beispiel 3

```
num_gpus = 1
per_device_train_batch_size = 3
steps_per_generation = gradient_accumulation_steps = 4

effective_batch_size = 4 * 3 * 1 = 12
num_generations = 4
unique_prompts = effective_batch_size / num_generations = 3
```

**Generierungszyklus A**

| Schritt | Batch    | Hinweise                              |
| ------: | -------- | ------------------------------------- |
|       0 | \[0,0,0] |                                       |
|       1 | \[0,1,1] |                                       |
|       2 | \[1,1,3] |                                       |
|       3 | \[3,3,3] | Optimizer-Update (Akkum = 4 erreicht) |

**Generierungszyklus B**

| Schritt | Batch    | Hinweise                              |
| ------: | -------- | ------------------------------------- |
|       0 | \[4,4,4] |                                       |
|       1 | \[4,5,5] |                                       |
|       2 | \[5,5,6] |                                       |
|       3 | \[6,6,6] | Optimizer-Update (Akkum = 4 erreicht) |

#### Beispiel 4

```
num_gpus = 1
per_device_train_batch_size = 6
steps_per_generation = gradient_accumulation_steps = 2

effective_batch_size = 2 * 6 * 1 = 12
num_generations = 3
unique_prompts = 4
```

**Generierungszyklus A**

| Schritt | Batch           | Hinweise                              |
| ------: | --------------- | ------------------------------------- |
|       0 | \[0,0,0, 1,1,1] |                                       |
|       1 | \[2,2,2, 3,3,3] | Optimizer-Update (Akkum = 2 erreicht) |

**Generierungszyklus B**

| Schritt | Batch           | Hinweise                              |
| ------: | --------------- | ------------------------------------- |
|       0 | \[4,4,4, 5,5,5] |                                       |
|       1 | \[6,6,6, 7,7,7] | Optimizer-Update (Akkum = 2 erreicht) |

### Kurzübersicht der Formeln

```
effective_batch_size = steps_per_generation * num_processes * train_batch_size
optimizer_steps_per_generation = steps_per_generation / gradient_accumulation_steps
unique_prompts = effective_batch_size / num_generations   # muss > 2 sein
```


---

# 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/advanced-rl-documentation.md?ask=<question>&goal=<user_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.