Fine-Tuning von GPT-OSS-20B für mehrsprachiges Reasoning auf Amazon SageMaker HyperPod

GPT-OSS-20B ist ein Open-Weight-Reasoning-Modell, das auf Englisch denkt. Bittet man es, auf Französisch, Deutsch, Spanisch oder Italienisch zu reasonen, bestätigt es die Anweisung und erzeugt seine Chain-of-Thought dennoch auf Englisch. In einem mehrsprachigen Reasoning-Test mit 50 Beispielen reasonte das Basismodell nur in 22 Prozent der Fälle in der richtigen Zielsprache. Diese 22 Prozent waren fast ausschließlich die englischen Beispiele (Englisch 100 Prozent, Französisch 0 Prozent, Deutsch 10 Prozent, Spanisch 0 Prozent, Italienisch 0 Prozent).

Für Teams, die Reasoning-Modelle für nicht-englischsprachige Nutzer bereitstellen, ist diese Lücke von Bedeutung. Ein Nutzer, der eine Frage auf Französisch stellt, erwartet, dass das Modell auf Französisch reasoned und antwortet, und nicht mitten im Gedankengang zu Englisch wechselt. Das Schließen dieser Lücke ist ein Fine-Tuning-Problem. Es wirft eine Frage auf, der sich jedes Team stellt, sobald es beginnt, Open-Weight-Modelle anzupassen: überwachtes Fine-Tuning (SFT), Reinforcement Learning mit Group Relative Policy Optimization (GRPO) oder beides?

In diesem Beitrag zeigen wir, wie wir GPT-OSS-20B für mehrsprachiges Reasoning auf Amazon SageMaker HyperPodfine-getunt haben. Wir zeigen, wann SFT allein ausreichte und wann GRPO zusätzlichen messbaren Wert brachte. Um allgemein zu verstehen, wann GRPO hilft, führten wir außerdem ein kontrolliertes Qwen2.5-7B-Experiment mit zwei Aufgaben mit unterschiedlichen Fähigkeitslücken durch. Die kurze Antwort: SFT leistet den Großteil der Arbeit, GRPO verfeinert, wenn Spielraum zum Verfeinern vorhanden ist, und die Passung der Technik zur Fähigkeitslücke entscheidet über das Ergebnis.

Überblick über die Lösung

Dieser Abschnitt behandelt die mehrsprachige Reasoning-Aufgabe und den Datensatz, wie SFT und GRPO einander ergänzen, und den Trainings-Stack, den wir auf Amazon SageMaker HyperPod betrieben haben.

Die Aufgabe und der Datensatz

Der Datensatz ist HuggingFaceH4/Multilingual-Thinking – ein Chain-of-Thought-Reasoning-Datensatz, der neben Englisch ins Französische, Spanische, Deutsche und Italienische übersetzt wurde, mit etwa 949 Trainings- und 50 Validierungsbeispielen. Das Modell erhält eine reasoning language: System-Prompt-Anweisung und muss sowohl reasonen als auch in dieser Zielsprache antworten, wodurch seine starke Englisch-Präferenz außer Kraft gesetzt wird. Die Evaluierung umfasst 50 Testfälle: 10 Mathe-/Logikprobleme in 5 Sprachen (EN/FR/DE/ES/IT).

Zwei Metriken sind wichtig:

• Reasoning-Sprache korrekt – ist die Chain-of-Thought in der angeforderten Sprache?
• Antwortsprache korrekt – ist die endgültige Antwort in der angeforderten Sprache?

Wie SFT und GRPO zusammenpassen

Die klarste Art, über die beiden Techniken nachzudenken: SFT lehrt ein Verhalten, das das Modell nicht besitzt. GRPO optimiert ein Verhalten, das das Modell bereits manchmal erzeugen kann. GRPO funktioniert, indem es eine Gruppe von Antworten pro Prompt sampelt und die Policy in Richtung der überdurchschnittlichen Antworten drängt. Wenn das gewünschte Verhalten in der Basisverteilung eine Wahrscheinlichkeit von null hat, gibt es für GRPO sehr wenig zu verstärken. Diese eine Idee erklärt fast jedes Ergebnis in diesem Beitrag.

Der Trainings-Stack

Wir liefen auf Amazon SageMaker HyperPod mit Amazon Elastic Kubernetes Service (Amazon EKS)-Orchestrierung. Für die ersten SFT- und GRPO-Läufe auf GPT-OSS-20B verwendeten wir die PyTorch-TRL-Bibliothek. Für das Qwen-Kontrollexperiment wechselten wir zu veRL als Trainer, mit Ray und KubeRay für verteilte Orchestrierung und vLLM für schnelle Rollout-Generierung. Checkpoints und Datensätze lagen auf Amazon FSx for Lustre, und das Inter-Node-Fabric nutzte Elastic Fabric Adapter (EFA). Das gesamte Fine-Tuning verwendete Low-Rank Adaptation (LoRA), das parametereffizient ist und sich sowohl für SFT als auch für GRPO eignet.

Das folgende Diagramm zeigt den Trainingsdatenpfad End-to-End. Eine Einreichung des Nutzers landet auf der Amazon-EKS-Kontrollebene des Amazon SageMaker HyperPod-Clusters. Amazon EKS plant einen Ray-Head-Pod plus Worker-Pods, die den veRL-Trainer und die vLLM-Rollout-Worker ausführen. Beide Pod-Sets mounten Amazon FSx for Lustre für das Basismodell, die Trainingsdaten und die Checkpoints. Inter-Node-Kollektive nutzen EFA. Rollouts strömen von vLLM zurück zum veRL-Trainer, und der Trainer schreibt Checkpoints zurück auf Amazon FSx for Lustre.

Abbildung 1: End-to-End-Trainingsdatenpfad für SFT- und GRPO-Fine-Tuning auf Amazon SageMaker HyperPod mit veRL, Ray, KubeRay, vLLM und Amazon FSx for Lustre für Qwen-Kontrollexperimente

Das Folgende beschreibt jeden Hop genauer. Der Einreicher startet den Lauf über Amazon SageMaker Studio oder die AWS Command Line Interface (AWS CLI). Die Amazon-EKS-Kontrollebene auf Amazon SageMaker HyperPod platziert Pods auf GPU-Knoten und startet einen Ray-Head mit Worker-Pods für den veRL-Trainer und die vLLM-Rollout-Worker. Amazon FSx for Lustre bietet gemeinsamen, hochdurchsatzfähigen Speicher für das Basismodell, die Trainingsdaten und die Checkpoints. Nach Abschluss des Trainings schreibt der Trainer den LoRA-Adapter zurück auf Amazon FSx for Lustre, um ihn nachgelagert zu evaluieren oder bereitzustellen.

Voraussetzungen

Zum Nachvollziehen benötigen Sie:

• Einen Amazon SageMaker HyperPod-Cluster mit Amazon-EKS-Orchestrierung. GPT-OSS SFT verwendete 4× ml.g6e.12xlarge (16× L40S 48GB). Das Qwen-Kontrollverfahren verwendete 2× g6e.48xlarge (16× L40S).
• Ein auf dem Cluster gemountetes Amazon FSx for Lustre-Dateisystem mit einem PersistentVolumeClaim benannten fsx-claim at /fsx.
• EFA-fähige Instanzen sowie eine funktionierende NVIDIA Collective Communications Library (NCCL) und aws-ofi-nccl einen Stack für Multi-Node-SFT.
• Eine Container-Registry wie Amazon Elastic Container Registry (Amazon ECR), um das aus dem Referenz-Repository erstellte Trainings-Image zu speichern.
• Ein HuggingFace-Zugriffstoken für openai/gpt-oss-20b und den HuggingFaceH4/Multilingual-Thinking Datensatz.
• Die AWS Command Line Interface (AWS CLI), kubectl, docker, und envsubst auf Ihrer Workstation verfügbar sind.

Richten Sie die Trainingsumgebung ein

Alle unten genannten Befehle, Manifeste und Skripte befinden sich im awsome-distributed-ai GitHub-Repository unter 3.test_cases/pytorch/trl/gpt-oss-lora-grpo/. Klonen Sie das Repository und wechseln Sie in das Testfall-Verzeichnis:

git clone https://github.com/awslabs/awsome-distributed-ai
cd awsome-distributed-ai/3.test_cases/pytorch/trl/gpt-oss-lora-grpo

Kopieren Sie die Umgebungs-Vorlage und bearbeiten Sie dann env_vars , um Ihre ECR-Registry, den Image-Namen, das Tag und das HuggingFace-Token festzulegen:

cp env_vars.example env_vars
source env_vars

Bauen Sie das Trainings-Image und pushen Sie es in Ihre Registry. Das Image bündelt PyTorch, TRL, HuggingFace Transformers, PEFT sowie die Trainings- und Inferenz-Skripte:

cd artifacts && ./build_push.sh && cd ..

Richten Sie kubectl auf Ihren Cluster und wenden Sie den FSx-Speicher-Manager-Pod an. Der Speicher-Manager gibt Ihnen eine Shell in das gemeinsame Dateisystem für die Checkpoint-Konvertierung und die Prüfung der Eval-Logs:

aws eks update-kubeconfig --name <YOUR_CLUSTER_NAME> --region us-east-2
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/fsx-storage-manager.yaml | kubectl apply -f -

Feintunen Sie GPT-OSS-20B mit SFT und LoRA

Wir beginnen mit der Messung des Basismodells, konfigurieren dann den SFT-Lauf und betrachten die Ergebnisse.

Die Lücke beim Basismodell

Das Basismodell GPT-OSS-20B erreichte bei der 50-Fälle-Evaluation 22 Prozent korrekt bei Reasoning-Sprache (11/50). Pro Sprache: Englisch 100 Prozent, Französisch 0 Prozent, Deutsch 10 Prozent, Spanisch 0 Prozent, Italienisch 0 Prozent. Das Modell nutzt standardmäßig englisches Reasoning, unabhängig von der Anweisung.

SFT-Konfiguration

Das SFT-Setup verwendete LoRA r=8, α=16, trainiert für 1,000 Schritte auf 4× ml.g6e.12xlarge (16× L40S 48GB) mit Fully Sharded Data Parallel (FSDP) full-shard, bf16-Präzision und Gradient Checkpointing. Der Job läuft als elastischer HyperPodPyTorchJob managed von Kueue, gestartet mit hyperpodrun.

Wenden Sie das SFT-Manifest an:

envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < hyperpod-eks/train-lora-hyperpod-elastic-g6e.yaml | kubectl apply -f -

Beobachten Sie den Trainingsfortschritt:

kubectl get pods -l app=gpt-oss-lora-elastic
kubectl logs -f -l app=gpt-oss-lora-elastic

Loss und Gradientennorm werden bei jedem Schritt ausgegeben. Ein gesunder Lauf sieht so aus:

{'loss': 1.035, 'grad_norm': 0.163, 'learning_rate': 0.0002, 'mean_token_accuracy': 0.716, 'epoch': 3.25}
{'loss': 1.003, 'grad_norm': 0.171, 'lr': 0.0002, 'acc': 0.722, 'epoch': 3.32}
{'loss': 0.976, 'grad_norm': 0.159, 'lr': 0.0002, 'acc': 0.726, 'epoch': 3.57}

Wenn das Training abgeschlossen ist, konvertieren Sie den FSDP-Checkpoint in das Parameter-Efficient Fine-Tuning (PEFT)-Format, das der GRPO-Trainer von TRL und die Inferenz-Skripte erwarten:

kubectl exec -it fsx-storage-manager -- python /app/convert_fsdp_checkpoint.py \
  --checkpoint /fsx/checkpoints/checkpoint-1000 \
  --output    /fsx/checkpoints/converted-peft/lora-checkpoint-1000-peft

SFT-Ergebnisse und die gestaffelte Lernkurve

Nach dem SFT reasoned das Modell in der korrekten Sprache 100 Prozent der Zeit (50/50) über alle fünf Sprachen. Das SFT lernte dies in zwei Stufen:

• Ab Schritt 200 lernte das Modell, zu begründen in der Zielsprache (Reasoning-Sprache-Metrik erreicht 100 Prozent).
• Ab Schritt 1000 lernte das Modell zusätzlich, die Antwort in der Zielsprache zu geben.

Abschließende SFT-Evaluation (Schritt 1000):

• Reasoning-Sprache korrekt: 100 Prozent (50/50).
• Antwort-Sprache korrekt: 62 Prozent (31/50).
• Beides korrekt: 62 Prozent (31/50).
• Antwortgenauigkeit pro Sprache: FR 60 Prozent, DE 60 Prozent, ES 30 Prozent, IT 60 Prozent, EN 100 Prozent.

Fazit: SFT ist hier nicht optional. Das Basismodell kann der Reasoning-Sprache-Anweisung überhaupt nicht folgen, und SFT hebt die Reasoning-Sprache von 22 Prozent auf 100 Prozent. Die verbleibende Lücke liegt bei der Antwort-Sprache mit 62 Prozent. Das ist die schwierigere Hälfte, weil die finale Antwort kurz ist und dort der englische Prior am stärksten ist.

Antwort-Sprache mit GRPO verfeinern

Die Antwort-Sprache war das offensichtliche Ziel für GRPO. SFT hatte bereits zu 100 Prozent korrektes Reasoning erzeugt, und das Modell manchmal die Antwort in der richtigen Sprache ausgab, also gab es ein Signal zum Verstärken.

GRPO auf dem SFT-Checkpoint ausführen

Wir führten GRPO mit TRLs GRPOTraineraus, beginnend vom SFT-Checkpoint. Das Setup: SFT-LoRA laden, merge_and_unloadaufrufen und eine neue LoRA hinzufügen (r=8, α=16, etwa 0.068 percent trainierbare Parameter, 13.6M von 20B). Das Training verwendete K=8 Generierungen pro Prompt, device_map=auto, Lernrate 1e-6 und 10 Epochen. Die Belohnungsfunktion bewertete Antwort-Sprache (±5.0), Reasoning-Sprache (±1.5) und Kürze (+0.5 oder −1.0), mit einem kombinierten Bereich von −7.5 bis +7.0.

GRPO vom konvertierten SFT-Checkpoint starten:

envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/train-grpo-singlenode.yaml | kubectl apply -f -
kubectl logs -f grpo-single

GRPO schreibt Checkpoints nach /fsx/checkpoints/grpo-singlenode/. Wählen Sie den besten Checkpoint anhand Ihres zurückgehaltenen Evals aus (die Antwort-Sprachmetrik erreichte in diesem Run früh ihren Höhepunkt) und konvertieren Sie ihn in das PEFT-Format für Inferenz und Auswertung.

Ergebnis (vom SFT-Checkpoint):

• Reasoning-Sprache korrekt: 100 Prozent (zurückgehalten: GRPO hat nichts zerstört, was SFT beigebracht hat).
• Antwort-Sprache korrekt: 62 bis 70 Prozent (+8 Punkte, 35/50).
• Beides korrekt: 70 Prozent.
• Antwort pro Sprache: FR 70 Prozent, DE 80 Prozent, ES 60 Prozent, IT 40 Prozent, EN 100 Prozent.

GRPO brachte einen echten Gewinn von +8 Punkten bei der Antwort-Sprachmetrik, während das Reasoning bei 100 Prozent gehalten wurde. Der Gewinn kam dort, wo Spielraum nach oben vorhanden war. Die Antwort-Sprache war das manchmal-korrekte Verhalten, auf dem SFT nicht vollständig konvergiert war, und GRPO verstärkte es.

Vergleichen Sie die Inferenz von Base, SFT und GRPO direkt nebeneinander

Um den qualitativen Unterschied zu sehen, deployen Sie drei Inferenz-Pods, die dasselbe Basismodell nutzen, aber unterschiedliche Adapter laden:

envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/inference-g6e-base.yaml    | kubectl apply -f -
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/inference-g6e-trained.yaml | kubectl apply -f -
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/inference-g6e-grpo.yaml    | kubectl apply -f -

Führen Sie denselben französischen Reasoning-Prompt durch jede Variante:

kubectl exec -it inference-base    -- python /app/inference_g6e.py \
  --reasoning_language French

kubectl exec -it inference-trained -- python /app/inference_g6e.py \
  --checkpoint /fsx/checkpoints/converted-peft/lora-checkpoint-1000-peft \
  --reasoning_language French

kubectl exec -it inference-grpo    -- python /app/inference_grpo_new.py \
  --use_grpo \
  --grpo_checkpoint /fsx/checkpoints/converted-peft/checkpoint-1470-peft \
  --reasoning_language French

Der Base-Pod argumentiert auf Englisch trotz der Anweisung. Der SFT-Pod argumentiert auf Französisch, antwortet aber oft auf Englisch. Der GRPO-Pod argumentiert und antwortet auf Französisch. Um das vollständige 50-Fälle-Eval zu reproduzieren, das die oben genannten Zahlen erzeugt hat, führen Sie das Evaluationsmanifest aus und lesen Sie die Ergebnisdatei vom FSx-Speichermanager:

envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/eval-grpo.yaml | kubectl apply -f -
kubectl logs -f eval-grpo
kubectl exec fsx-storage-manager -- \
  cat /fsx/experiments/grpo_eval_checkpoint1470_*.txt

Um breiter zu verstehen, wann GRPO Mehrwert schafft, führten wir ein kontrolliertes Experiment mit Qwen2.5-7B über zwei Aufgaben mit unterschiedlichen Fähigkeitslücken durch.

Testen Sie das Muster mit einer Qwen2.5-7B-Kontrolle

Um die These „Technik an Fähigkeitslücke anpassen“ an einem anderen Modell und anderen Aufgaben zu testen, führten wir kontrollierte Experimente mit Qwen2.5-7B-Instruct durch. Die erste Aufgabe ist dieselbe mehrsprachige Reasoning-Aufgabe (wo Spielraum existiert). Die zweite Aufgabe ist GSM8K, bei der das Modell bereits auf höchster Genauigkeit ist. Dies ist ein internes Experiment; das öffentliche Repo wurde noch nicht veröffentlicht.

Infrastruktur: 2× g6e.48xlarge (16× L40S), EFA 100Gbps, FSx Lustre, Ray 2.44 + KubeRay 1.4.2, veRL v0.6.1, vLLM 0.8.4.

Gruppen: A = base, B = nur SFT, C = SFT+GRPO.

Mehrsprachiges Reasoning (50 Fälle)

GSM8K, eine Aufgabe ohne Spielraum

Bei GSM8K erreicht das Basismodell Qwen2.5-7B bereits 90,5 Prozent (181/200). GRPO bei Schritt 30 erreicht ebenfalls 90,5 Prozent. Wenn die meisten sampelnden Gruppen vollständig korrekt sind, kollabiert der gruppenrelative Vorteil auf null, sodass es kein Lernsignal gibt. Dies ist die andere Hälfte der These: GRPO braucht Spielraum (pass@k >> pass@1), um überhaupt etwas zu optimieren. Kein Spielraum bedeutet keinen Gewinn.

Best Practices

1. Beginnen Sie mit SFT. GRPO kann ein Verhalten mit null Basiswahrscheinlichkeit nicht lehren. Es kann nur Antworten verstärken, die das Modell bereits manchmal erzeugt. SFT hob die Reasoning-Sprache von 22 Prozent auf 100 Prozent, und jeder GRPO-Erfolg in dieser Arbeit basierte auf diesem SFT-Checkpoint.
2. Verwenden Sie LoRA sowohl für SFT als auch für GRPO. LoRA r=8/α=16 war parameter-effizient (0,068 Prozent trainierbar) und blieb bei der Qwen-Kontrolle durch GRPO numerisch stabil (Gradientennorm 0,23, etwa 11,7 GB pro GPU). Es ist ein starker Standard, wenn Sie möchten, dass SFT und GRPO dieselbe Adapterform verwenden.
3. Passen Sie die Technik an die Lücke an. Verwenden Sie SFT für fehlendes Verhalten. Verwenden Sie GRPO zur Verfeinerung eines vorhandenen, manchmal korrekten Verhaltens. Die realistische Obergrenze von GRPO lag hier bei +6 bis +8 Punkten.
4. Prüfen Sie den Reward Headroom, bevor Sie GPU-Stunden ausgeben. Wenn die meisten Gruppen vollständig korrekt sind (GSM8K 90.5 Prozent Basis), kollabiert der gruppenrelative Vorteil auf null und GRPO erhält keinen Gradienten. Stellen Sie vor dem Start eines GRPO-Runs sicher, dass Headroom besteht (pass@k >> pass@1).

Ressourcen bereinigen

Um laufende Kosten zu vermeiden, löschen Sie die Workload-Ressourcen und anschließend die zugrunde liegende Infrastruktur:

1. Löschen Sie die Trainings- und Inferenz-Pods und -Jobs:

   kubectl delete hyperpodpytorchjob lora-hyperpod-elastic --ignore-not-found
   kubectl delete pod grpo-single inference-base inference-trained inference-grpo \
     eval-grpo fsx-storage-manager --ignore-not-found

2. Skalieren Sie den Amazon SageMaker HyperPod-Cluster oder seine Node Groups herunter oder löschen Sie ihn bzw. sie.
3. Löschen Sie das Amazon FSx for Lustre-Dateisystem, sobald Sie alle Checkpoints exportiert haben, die Sie behalten möchten.
4. Löschen Sie alle Amazon Simple Storage Service (Amazon S3)-Buckets oder -Objekte, die für Trainingsdaten oder Checkpoint-Archive verwendet wurden.

Fazit

Wir haben gezeigt, wie man GPT-OSS-20B für mehrsprachiges Reasoning auf Amazon SageMaker HyperPod feinjustiert und wie man zwischen SFT und GRPO entscheidet. SFT leistete den Großteil der Arbeit: Die Reasoning-Sprache stieg von 22 Prozent auf 100 Prozent. GRPO fügte dort, wo Headroom vorhanden war, eine echte, bescheidene Verfeinerung hinzu (Antwort von 62 Prozent auf 70 Prozent). Eine parallele Qwen2.5-7B-Kontrollgruppe bestätigte das Muster. GRPO brachte +6 Prozent beim mehrsprachigen Reasoning, wo Verbesserungsspielraum bestand. Bei GSM8K, wo das Modell bereits bei maximaler Genauigkeit war (90.5 Prozent), brachte es keinen Gewinn.

Entscheidungsrahmen:

• Verhalten, das das Modell überhaupt nicht kann: verwenden Sie SFT.
• Verhalten, das es manchmal zeigt, mit Headroom: verwenden Sie SFT gefolgt von GRPO für ein paar Prozentpunkte mehr.
• Modell bereits bei maximaler Genauigkeit oder Ziel hat Basiswahrscheinlichkeit null: GRPO hilft nicht.

Um dies selbst auszuprobieren, gehen Sie die Testfälle im awsome-distributed-ai -Repository durch. Weitere Informationen zu Amazon SageMaker HyperPod finden Sie auf der Servicedetailseite und in der Amazon SageMaker HyperPod-Dokumentation. Eine Anleitung zu Ray auf Amazon SageMaker HyperPod finden Sie im verwandten Beitrag Verteiltes Training auf Amazon SageMaker HyperPod mit Ray und Amazon SageMaker Studio ausführen. Der Link wird hinzugefügt, sobald dieser Beitrag veröffentlicht ist. Teilen Sie Ihre Ergebnisse in den Kommentaren.

Über die Autoren