🧩Erweiterte Dokumentation für Reinforcement Learning

Erweiterte Dokumentationseinstellungen bei der Verwendung von Unsloth mit GRPO.

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.

  # 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

• 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

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. Setzen Sie einfach fast_inference=False beim Laden des Modells.

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.

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

Batch- und Durchsatzparameter

Parameter, die Batches steuern

• train_batch_size: Anzahl der Samples pro Prozess pro Schritt. Wenn diese ganze Zahl kleiner als num_generationsist, 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