🧩Erweiterte Dokumentation zu Reinforcement Learning

Erweiterte Dokumentationseinstellungen bei der Verwendung von Unsloth mit GRPO.

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

Trainingsparameter

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

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

  • Höher beta schränkt die Policy stärker ein, sich näher an der Referenzpolicy zu halten.

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

• 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 oberes Clipping-Grenze für zweiseitiges GRPO wenn gesetzt. Wenn None, wird das standardmäßige GRPO-Clipping verwendet. Empfohlen > 1 + ε wenn aktiviert (laut INTELLECT-2 Bericht).

• epsilon_high (float, optional): Oberer Epsilon-Grenzwert; standardmäßig epsilon wenn nicht gesetzt. DAPO empfiehlt 0.28.

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

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

  • "sequence": mittelt Token‑Verhältnisse zu einem einzelnen sequence‑level Verhältnis. GSPO zeigt, dass sequence‑level Sampling oft stabileres Training für sequence‑level Belohnungen ergibt.

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

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

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

  • "batch": skalieren nach Std über den gesamten Batch (laut PPO‑Lite).

  • False oder "none": keine Skalierung. Dr. GRPO empfiehlt, nicht zu skalieren, um Verzerrungen durch Std‑Skalierung zu vermeiden.

• loss_type (str, Standard "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" (Standard): normalisiert nach aktiven Tokens im global akkumulierten Batch (eingeführt in DAPO; entfernt Längenbias).

  • "bnpo": normalisiert nach aktive Tokens nur im lokalen Batch (Ergebnisse können mit lokaler Batchgröße variieren; entspricht GRPO, wenn per_device_train_batch_size == 1).

• mask_truncated_completions (bool, Standard False): Wenn True, werden abgeschnittene Completionen von der 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 Completionen 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 nullen, wenn viele Completionen abgeschnitten sind, wodurch n_mask_per_reward = 0 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 ist dies automatisch auf True gesetzt wenn Sie vLLM/fast_inference verwenden; andernfalls False.

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

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

RL bei 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 die Completionen. Stellen Sie sicher, dass Sie eine relativ hohe (1.0) Temperatur 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 obersten Tokens steuert, die berücksichtigt werden. Muss in (0, 1] liegen. Auf 1.0 setzen, um alle Tokens zu berücksichtigen.

• top_k (int, optional): Anzahl der Vokabeltokens mit höchster Wahrscheinlichkeit, die für das 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 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, das neue Tokens basierend darauf bestraft, ob sie im Prompt und im bisher generierten Text erscheinen. Werte > 1.0 fördern die Nutzung neuer Tokens, während Werte < 1.0 das Wiederholen von Tokens fördern.

• steps_per_generation: (int, optional): Anzahl der Schritte pro Generierung. Wenn None, ist der Standardwert gradient_accumulation_steps. Steht in gegenseitigem Ausschluss mit generation_batch_size.

Es ist etwas verwirrend, mit diesem Parameter zu hantieren; empfohlen wird, per_device_train_batch_size und die Gradientenakkumulation für die Batchgrößen zu bearbeiten

Batch‑ & Durchsatzparameter

Parameter, die Batches steuern

• train_batch_size: Anzahl der Samples pro Prozess pro Schritt. Wenn diese Ganzzahl kleiner als num_generations, 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; das Timing 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 sollenbevor Rückpropagation und Optimizer‑Update angewendet werden. Effektive Batchgröße

• effective_batch_size = steps_per_generation * num_processes * train_batch_size:

  Gesamtsamples, die vor einem Update zu den Gradienten beitragen (über alle Prozesse und Schritte hinweg).

  Optimizer‑Schritte pro Generation

• optimizer_steps_per_generation = steps_per_generation / gradient_accumulation_steps:

  Beispiel:

  : Anzahl der erzeugten Generierungen 4 / 2 = 2.

• num_generationspro Prompt (angewendet nach Berechnung der effective_batch_size ). Die Anzahl dereinzigartigen 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	Anmerkungen	→ Optimizer‑Update (accum = 2 erreicht)
0	[0,0,0]
1	[1,1,1]	Optimizer‑Update
2	[2,2,2]
3	[3,3,3]	Generierungszyklus B

Beispiel 2

Batch	Anmerkungen	→ Optimizer‑Update (accum = 2 erreicht)
0	[4,4,4]
1	[5,5,5]	Optimizer‑Update
2	[6,6,6]
3	[7,7,7]	Generierungszyklus B

steps_per_generation = gradient_accumulation_steps = 4

per_device_train_batch_size = 3
gradient_accumulation_steps = 2
Optimizer‑Update (accum = 4 erreicht)

num_generations = 3
Generierungszyklus A

Schritt

Batch	Anmerkungen	→ Optimizer‑Update (accum = 2 erreicht)
0	[0,0,0]
1	[1,1,1]
2	[2,2,2]
3	[3,3,3]	Beispiel 3

Beispiel 2

Batch	Anmerkungen	→ Optimizer‑Update (accum = 2 erreicht)
0	[4,4,4]
1	[5,5,5]
2	[6,6,6]
3	[7,7,7]	Beispiel 3

num_generations = 4

per_device_train_batch_size = 3
gradient_accumulation_steps = 2
Optimizer‑Update (accum = 4 erreicht)

num_generations = 3
unique_prompts = effective_batch_size / num_generations = 3
Beispiel 4

Schritt

Batch	Anmerkungen	→ Optimizer‑Update (accum = 2 erreicht)
0	[0,0,0]
1	[0,1,1]
2	[1,1,3]
3	[3,3,3]	Beispiel 3

Beispiel 2

Batch	Anmerkungen	→ Optimizer‑Update (accum = 2 erreicht)
0	[4,4,4]
1	[4,5,5]
2	[5,5,6]
3	[6,6,6]	Beispiel 3

per_device_train_batch_size = 6

per_device_train_batch_size = 3
steps_per_generation = gradient_accumulation_steps = 2
effective_batch_size = 2 * 6 * 1 = 12

unique_prompts = 4
Generierungszyklus A
Optimizer‑Update (accum = 2 erreicht)

Schritt

Batch	Anmerkungen	→ Optimizer‑Update (accum = 2 erreicht)
0	[0,0,0, 1,1,1]
1	[2,2,2, 3,3,3]	Schnelle Formelreferenz

Beispiel 2

Batch	Anmerkungen	→ Optimizer‑Update (accum = 2 erreicht)
0	[4,4,4, 5,5,5]
1	[6,6,6, 7,7,7]	Schnelle Formelreferenz

unique_prompts = effective_batch_size / num_generations # muss > 2 sein

Gesamtsamples, die vor einem Update zu den Gradienten beitragen (über alle Prozesse und Schritte hinweg).
Beispiel:
unique_prompts = effective_batch_size / num_generations   # muss > 2 sein