🧩Fortgeschrittene Reinforcement Learning Dokumentation

Erweiterte Dokumentationseinstellungen bei der Verwendung von Unsloth mit GRPO.

Detaillierte Anleitungen zum Durchführen von GRPO mit Unsloth für Batching, Generierung & Trainingsparameter:

Trainingsparameter

• beta (float, Standard 0.0): KL-Koeffizient.

  • 0.0 ⇒ kein Referenzmodell geladen (geringerer Speicherverbrauch, schneller).

  • Höher beta grenzt die Policy stärker an die Referenzpolicy.

• num_iterations (int, Standard 1): PPO-Epochen pro Batch (μ im Algorithmus). Replayt Daten innerhalb jedes Schritts der Gradientenakkumulation; z. B., 2 = zwei Vorwärtsdurchläufe pro Akkumulationsschritt.

• epsilon (float, Standard 0.2): Clipping-Wert für token-level Log-Wahrscheinlichkeitsverhältnisse (typischer Verhältnissbereich ≈ [-1.2, 1.2] mit Standard-ε).

• delta (float, optional): Aktiviert upper Clip-Grenze für zweiseitiges GRPO wenn gesetzt. Falls Keine, wird das Standard-GRPO-Clipping verwendet. Empfohlen > 1 + ε wenn aktiviert (laut INTELLECT-2 Bericht).

• epsilon_high (float, optional): Obere Epsilon-Grenze; Standardwert ist epsilon wenn nicht gesetzt. DAPO empfiehlt 0.28.

• importance_sampling_level (“token” | “sequence”, Standard "token"):

  • "token": rohe pro-Token Verhältnisse (ein Gewicht pro Token).

  • "sequence": mittelt pro-Token Verhältnisse zu einem einzigen Sequenz-Level-Verhältnis. GSPO zeigt, dass Sequenz-Level-Sampling oft stabileres Training für sequenzielle Belohnungen liefert.

• reward_weights (Liste[float], optional): Ein Gewicht pro Belohnung. Wenn Keine, sind alle Gewichte = 1.0.

• scale_rewards (str|bool, Standard "group"):

  • Wahr oder "group": skaliere nach Std innerhalb jeder Gruppe (Einheitsvarianz in der Gruppe).

  • "batch": skaliere nach Std über den gesamten Batch (pro PPO-Lite).

  • Falsch oder "none": keine Skalierung. Dr. GRPO empfiehlt, nicht zu skalieren, um Schwierigkeiten durch Std-Skalierung zu vermeiden.

• loss_type (str, Standard "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 (Ergebnisse können mit der lokalen Batchgröße variieren; entspricht GRPO wenn per_device_train_batch_size == 1).

• mask_truncated_completions (bool, Standard False): Wenn Wahr, werden abgeschnittene Vervollständigungen vom Loss ausgeschlossen (von DAPO für Stabilität empfohlen). Hinweis: Mit dieser Option gibt es einige KL-Probleme, daher empfehlen wir, sie zu deaktivieren.

  # Wenn mask_truncated_completions aktiviert ist, setze abgeschnittene Vervollständigungen in completion_mask auf Null
  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 Vervollständigungen abgeschnitten sind, wodurch n_mask_per_reward = 0 wird und KL zu NaN werden kann. Siehe

• vllm_importance_sampling_correction (bool, Standard True): Wendet an Truncated Importance Sampling (TIS) 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 Falsch.

• vllm_importance_sampling_cap (float, Standard 2.0): Trunkierungsparameter C für TIS; setzt eine Obergrenze für das Importance-Sampling-Verhältnis zur Verbesserung der Stabilität.

• dtype bei Wahl von float16 oder bfloat16, siehe FP16 vs BF16 für RL

Generierungsparameter

• temperature (float, Standard 1.0): Temperatur für Sampling. Je höher die Temperatur, desto zufälliger die Vervollständigungen. Stellen Sie sicher, dass Sie eine relativ hohe Temperatur (1.0) verwenden, um Vielfalt in den Generierungen zu haben, was beim Lernen hilft.

• top_p (float, optional, Standard 1.0): Float, der die kumulative Wahrscheinlichkeit der obersten Tokens 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 Tokens mit der höchsten Wahrscheinlichkeit im Vokabular, die für Top-K-Filtering beibehalten werden. Wenn None, ist 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. Muss zwischen 0.0 und 1.0 liegen. Typische Werte liegen im Bereich 0.01–0.2.

• repetition_penalty (float, optional, Standard 1.0): Float, der neue Tokens bestraft, basierend darauf, ob sie in der Eingabeaufforderung und im bisher generierten Text erscheinen. Werte > 1.0 ermutigen das Modell, neue Tokens zu verwenden, während Werte < 1.0 das Modell zur Wiederholung von Tokens neigen lassen.

• 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, mit diesem Parameter zu spielen; es wird empfohlen, per_device_train_batch_size und Gradientenaakkumulation für die Batchgrößen zu bearbeiten

Batch- & Durchsatzparameter

Parameter, die Batches steuern

• train_batch_size: Anzahl der Proben pro Prozess pro Schritt. Wenn diese Ganzzahl kleiner als num_generationsist, wird sie standardmäßig auf num_generations.

• steps_per_generation: Anzahl der Microbatches die zu der Verlustberechnung einer Generation beitragen (nur Vorwärtsdurchläufe). Ein neuer Datensatz wird alle Schritte generiert; der Zeitpunkt der Rückpropagation hängt von steps_per_generation num_processes gradient_accumulation_steps.

• : Anzahl der verteilten Trainingsprozesse (z. B. GPUs / Worker).(auch bekannt als

• gradient_accumulation_steps gradient_accumulation ): Anzahl der Microbatches, die akkumuliert werden sollen, bevorRückpropagation und Optimizer-Update angewendet werden. vorher Effektive Batchgröße

• effective_batch_size = steps_per_generation * num_processes * train_batch_size:

  Gesamtzahl an Proben, die zu Gradienten beitragen, bevor ein Update erfolgt (über alle Prozesse und Schritte).

  Optimizer-Schritte pro Generierung

• optimizer_steps_per_generation = steps_per_generation / gradient_accumulation_steps:

  : Anzahl der erzeugten Generierungen

  Beispiel: 4 / 2 = 2.

• num_generationspro Prompt (angewendet bei der Berechnung von effective_batch_size nach ). Die Anzahl der einzigartigen Promptsin 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 Schritte fließen, wann Optimizer-Updates auftreten und wie neue Batches erzeugt 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

→ Optimizer-Update (Akkum = 2 erreicht)	Optimizer-Update	Anmerkungen
0	[0,0,0]
1	[1,1,1]	Generierungszyklus B
2	[2,2,2]
3	[3,3,3]	Beispiel 2

steps_per_generation = gradient_accumulation_steps = 4

→ Optimizer-Update (Akkum = 2 erreicht)	Optimizer-Update	Anmerkungen
0	[4,4,4]
1	[5,5,5]	Generierungszyklus B
2	[6,6,6]
3	[7,7,7]	Beispiel 2

Optimizer-Update (Akkum = 4 erreicht)

gradient_accumulation_steps = 2
steps_per_generation = 4
Beispiel 3

Generierungszyklus A
Schritt

Batch

→ Optimizer-Update (Akkum = 2 erreicht)	Optimizer-Update	Anmerkungen
0	[0,0,0]
1	[1,1,1]
2	[2,2,2]
3	[3,3,3]	num_generations = 4

steps_per_generation = gradient_accumulation_steps = 4

→ Optimizer-Update (Akkum = 2 erreicht)	Optimizer-Update	Anmerkungen
0	[4,4,4]
1	[5,5,5]
2	[6,6,6]
3	[7,7,7]	num_generations = 4

unique_prompts = effective_batch_size / num_generations = 3

gradient_accumulation_steps = 2
steps_per_generation = 4
Beispiel 3

Generierungszyklus A
Beispiel 4
per_device_train_batch_size = 6

Batch

→ Optimizer-Update (Akkum = 2 erreicht)	Optimizer-Update	Anmerkungen
0	[0,0,0]
1	[0,1,1]
2	[1,1,3]
3	[3,3,3]	num_generations = 4

steps_per_generation = gradient_accumulation_steps = 4

→ Optimizer-Update (Akkum = 2 erreicht)	Optimizer-Update	Anmerkungen
0	[4,4,4]
1	[4,5,5]
2	[5,5,6]
3	[6,6,6]	num_generations = 4

steps_per_generation = gradient_accumulation_steps = 2

gradient_accumulation_steps = 2
effective_batch_size = 2 * 6 * 1 = 12
unique_prompts = 4

Optimizer-Update (Akkum = 2 erreicht)
Schritt
Schnelle Formelsammlung

Batch

→ Optimizer-Update (Akkum = 2 erreicht)	Optimizer-Update	Anmerkungen
0	[0,0,0, 1,1,1]
1	[2,2,2, 3,3,3]	unique_prompts = effective_batch_size / num_generations # muss > 2 sein

steps_per_generation = gradient_accumulation_steps = 4

→ Optimizer-Update (Akkum = 2 erreicht)	Optimizer-Update	Anmerkungen
0	[4,4,4, 5,5,5]
1	[6,6,6, 7,7,7]	unique_prompts = effective_batch_size / num_generations # muss > 2 sein

Quick Formula Reference

Gesamtzahl an Proben, die zu Gradienten beitragen, bevor ein Update erfolgt (über alle Prozesse und Schritte).
: Anzahl der erzeugten Generierungen
unique_prompts = effective_batch_size / num_generations   # must be > 2