# Dokumentation für fortgeschrittenes Reinforcement Learning

Detaillierte Anleitungen zum Durchführen von GRPO mit Unsloth für Batch-, Generierungs- und Trainingsparameter:

## Trainingsparameter

* **`beta`** *(float, Standardwert 0.0)*: KL-Koeffizient.
  * `0.0` ⇒ kein Referenzmodell geladen (geringerer Speicherverbrauch, schneller).
  * Höhere `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).\
  Wiederholt Daten innerhalb jedes Gradientenakkumulationsschritts; z. B. `2` = zwei Forward-Pässe pro Akkumulationsschritt.
* **`epsilon`** *(float, Standardwert 0.2)*: Clipping-Wert für Log-Prob-Ratios auf Token-Ebene (typischer Bereich des Verhältnisses ≈ \[-1.2, 1.2] mit standardmäßigem ε).
* **`delta`** *(float, optional)*: Aktiviert **obere** Clipping-Grenze für **beidseitiges GRPO** wenn gesetzt. Wenn `None`, wird das standardmäßige GRPO-Clipping verwendet. Empfohlen `> 1 + ε` wenn aktiviert (laut INTELLECT-2-Bericht).
* **`epsilon_high`** *(float, optional)*: Obergrenzen-ε; standardmäßig `epsilon` falls nicht gesetzt. DAPO empfiehlt **0.28**.
* **`importance_sampling_level`** *(„token“ | „sequence“, Standardwert "token")*:
  * `"token"`: rohe Verhältnisse pro Token (ein Gewicht pro Token).
  * `"sequence"`: Mittelwert der Verhältnisse pro Token zu einem einzelnen Verhältnis auf Sequenzebene.\
    GSPO zeigt, dass Sampling auf Sequenzebene oft stabileres Training für Belohnungen auf Sequenzebene liefert.
* **`reward_weights`** *(list\[float], optional)*: Ein Gewicht pro Belohnung. Wenn `None`, dann sind alle Gewichte = 1.0.
* **`scale_rewards`** *(str|bool, Standardwert "group")*:
  * `True` oder `"group"`: skalieren durch **Std innerhalb jeder Gruppe** (Einheitsvarianz in der Gruppe).
  * `"batch"`: skalieren durch **Std über den gesamten Batch** (laut PPO-Lite).
  * `False` oder `"none"`: **keine Skalierung**. Dr. GRPO empfiehlt, nicht zu skalieren, um eine Schwierigkeitsschrägheit durch Std-Skalierung zu vermeiden.
* **`loss_type`** *(str, Standardwert "dapo")*:
  * `"grpo"`: normalisiert über die Sequenzlänge (Längenbias; nicht empfohlen).
  * `"dr_grpo"`: normalisiert durch eine **globale Konstante** (eingeführt in Dr. GRPO; entfernt Längenbias). Konstante ≈ `max_completion_length`.
  * `"dapo"` **(Standardwert)**: normalisiert durch **aktive Tokens im global akkumulierten Batch** (eingeführt in DAPO; entfernt Längenbias).
  * `"bnpo"`: normalisiert durch **aktive Tokens nur im lokalen Batch** (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 `True`, werden abgeschnittene Komplettierungen 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, abgeschnittene Komplettierungen in completion_mask auf null setzen
  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 null setzen, wenn viele Komplettierungen abgeschnitten sind, 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) sich vom Trainings-Backend unterscheidet.\
  In Unsloth wird dies **automatisch auf True gesetzt** wenn Sie vLLM/fast\_inference verwenden; andernfalls **False**.
* **`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 Auswahl 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 sind die Ausgaben. 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. Setzen Sie ihn auf 1.0, um alle Token zu berücksichtigen.
* `top_k (int, optional):`\
  Anzahl der Wörterbuch-Token mit der höchsten Wahrscheinlichkeit, die für das Top-k-Filtering beibehalten werden sollen. Wenn None, ist das Top-k-Filtering deaktiviert und alle Token werden berücksichtigt.
* `min_p (float, optional):`\
  Mindest-Token-Wahrscheinlichkeit, die mit der Wahrscheinlichkeit des wahrscheinlichsten Tokens skaliert wird. Sie muss einen Wert zwischen 0.0 und 1.0 haben. Typische Werte liegen im Bereich 0.01-0.2.
* `repetition_penalty (float, optional, Standardwert 1.0):`\
  Float, der neue Tokens bestraft, je nachdem, 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, an diesem Parameter herumzuexperimentieren; es wird empfohlen, `per_device_train_batch_size` und Gradient Accumulation für die Batchgrößen zu bearbeiten
{% endhint %}

## Batch- und Durchsatzparameter

### Parameter, die Batches steuern

* **`train_batch_size`**: Anzahl der Samples **pro Prozess** pro Schritt.\
  Wenn diese ganze Zahl **kleiner als `num_generations`**&#x69;st, wird standardmäßig `num_generations`.
* **`steps_per_generation`**: Anzahl der **Mikrobatches** die zu **einer Generierung** zur Berechnung des Loss beitragen (nur Forward-Pässe).\
  Alle `steps_per_generation` Schritte wird ein neuer Datenbatch 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 Mikrobatches, die vor **dem** Anwenden von Backpropagation und Optimizer-Update akkumuliert 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** dem Berechnen 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 folgenden Tabellen 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) |

### Schnelle Formelbezugnahme

```
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: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://unsloth.ai/docs/de/loslegen/reinforcement-learning-rl-guide/advanced-rl-documentation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.