El GPT-OSS-20B es un modelo de razonamiento de peso abierto que piensa en inglés. Pídele que razone en francés, alemán, español o italiano y, de todos modos, reconocerá la instrucción y, de todos modos, expresará su cadena de pensamiento en inglés. En una prueba de razonamiento multilingüe de 50 ejemplos, el modelo base razonó en el idioma de destino correcto solo el 22 por ciento de las veces. Ese 22 por ciento correspondió casi en su totalidad a ejemplos en inglés (100 por ciento en inglés, 0 por ciento en francés, 10 por ciento en alemán, 0 por ciento en español, 0 por ciento en italiano

).

Para los equipos que implementan modelos de razonamiento para usuarios que no hablan inglés, esa brecha es importante. Un usuario que hace una pregunta en francés espera que el modelo razone y responda en francés, no que cambie al inglés a mitad de camino. Cerrar esa brecha es un problema de ajuste. Esto plantea una pregunta a la que se enfrentan todos los equipos una vez que comienzan a personalizar los modelos de peso libre: ¿ajustes supervisados (SFT), aprendizaje reforzado con la optimización de políticas relativas grupales (GRPO

) o ambos?

En este artículo, explicamos cómo ajustamos el GPT-OSS-20B para que permitiera el razonamiento multilingüe en Amazon SageMaker HyperPod. Mostramos cuándo el SFT por sí solo fue suficiente y cuándo el GRPO añadió un valor cuantificable. Para comprender de manera más amplia cuándo ayuda el GRPO, también realizamos un experimento controlado con el Qwen2.5-7B en dos tareas con diferentes brechas de capacidad. La respuesta resumida: el SFT hace la mayor parte del trabajo, el GRPO lo perfecciona cuando hay margen para perfeccionarlo, y lo que decide el resultado es adaptar la técnica a la brecha

de capacidad.

Descripción general de la solución

En esta sección se describen la tarea y el conjunto de datos de razonamiento multilingües, cómo se complementan SFT y GRPO y el conjunto de programas de formación que utilizamos en Amazon SageMaker HyperPod.

La tarea y el conjunto de datos

El conjunto de datos es HuggingFaceH4/Multilingual-Thinking, un conjunto de datos sobre el razonamiento en cadena traducido al francés, español, alemán e italiano junto con el inglés, con aproximadamente 949 ejemplos de capacitación y 50 de validación. El modelo se basa en un lenguaje de razonamiento, es decir, la instrucción basada en el sistema, y debe razonar y responder en ese idioma de destino, por encima de su fuerte dominio del inglés. La evaluación consiste en 50 casos de prueba: 10 problemas matemáticos/lógicos en 5 idiomas (EN/FR/DE/ES/IT)

.

Hay dos métricas que importan:

  • El lenguaje de razonamiento es correcto: ¿la cadena de pensamiento está en el idioma solicitado?
  • El lenguaje de respuesta es correcto: ¿la respuesta final está en el idioma solicitado?

Cómo encajan SFT y GRPO

La forma más clara de pensar en las dos técnicas: la SFT enseña un comportamiento que el modelo no tiene. El GRPO optimiza un comportamiento que el modelo ya puede producir a veces. El GRPO toma muestras de un grupo de respuestas por mensaje e impulsa la política hacia las respuestas superiores a la media. Si el comportamiento deseado tiene una probabilidad cero en la distribución base, el GRPO tiene muy poco que reforzar. Esa sola idea explica casi todos los resultados de esta publicación

.

La pila de entrenamiento

Utilizamos Amazon SageMaker HyperPod con la orquestación de Amazon Elastic Kubernetes Service (Amazon EKS). Para las ejecuciones iniciales de SFT y GRPO en GPT-OSS-20B, utilizamos la biblioteca TRL de PyTorch. Para el experimento de control de Qwen, cambiamos a VerL como entrenador, a Ray y KubeRay para la orquestación distribuida y a vLLM para una rápida generación de despliegues. Los puntos de control y los conjuntos de datos se basaban en Amazon FSx for Lustre, y la estructura entre nodos utilizaba Elastic Fabric Adapter (EFA). Todos los ajustes utilizaron la adaptación de rango bajo (LoRa), que es eficiente en cuanto a los parámetros y se adapta bien tanto a SFT como a GRPO

.

El siguiente diagrama muestra la ruta de los datos de entrenamiento de principio a fin. Un envío del usuario llega al plano de control de Amazon EKS del clúster HyperPod de Amazon SageMaker. Amazon EKS programa un módulo de Ray Head y módulos de trabajo que ejecutan los equipos de entrenamiento de vURL y de implementación de vLLM. Ambos conjuntos de módulos incorporan Amazon FSx for Lustre para el modelo base, los datos de entrenamiento y los puntos de control. Los colectivos entre nodos utilizan EFA. Los despliegues se transmiten desde vLLM al entrenador de VerL, y este último devuelve los puntos de control a Amazon FSx for Lustre

.
End-to-end fine-tuning architecture on Amazon SageMaker HyperPod

Figura 1: Ruta de datos de entrenamiento de extremo a extremo para el ajuste fino de SFT y GRPO en Amazon SageMaker HyperPod con vErL, Ray, KuberRay, vLLM y Amazon FSx for Lustre para experimentos de control de Qwen

A continuación se describe cada salto con más detalle. El remitente inicia la ejecución desde Amazon SageMaker Studio o la interfaz de línea de comandos de AWS (AWS CLI). El plano de control de Amazon EKS de Amazon SageMaker HyperPod coloca los pods en los nodos de la GPU y pone en marcha un Ray Head con módulos de trabajo para los trabajadores de entrenamiento de vURL y de implementación de vLLM. Amazon FSx for Lustre proporciona almacenamiento compartido de alto rendimiento para el modelo base, los datos de entrenamiento y los puntos de control. Cuando finaliza el entrenamiento, el instructor envía el adaptador LoRa a Amazon FSx for Lustre para su posterior

evaluación o distribución.

Prerrequisitos

Para seguir adelante, necesitas:

  • Un clúster HyperPod de Amazon SageMaker con orquestación de Amazon EKS. El GPT-OSS SFT utilizó 4 × ml.g6 y 12 veces más grande (16 × L40S de 48 GB). El control Qwen utilizaba 2 x G6 de 0,48 x de tamaño (16 x L40S).
  • Un sistema de archivos Amazon FSx for Lustre montado en el clúster con un PersistentVolumeClaim denominado fsx-claim at /fsx.
  • Instancias compatibles con EFA y una biblioteca de comunicaciones colectivas (NCCL) de NVIDIA en funcionamiento y una pila aws-ofi-nccl para SFT multinodo.
  • Un registro de contenedores, como Amazon Elastic Container Registry (Amazon ECR), para almacenar la imagen de formación creada a partir del repositorio de referencia.
  • Un token de acceso de HuggingFace para openai/gpt-oss-20b y el conjunto de datos HuggingFaceH4/Multilingual-Thinking.
  • La interfaz de línea de comandos de AWS (CLI de AWS), kubectl, docker y envsubst están disponibles en su estación de trabajo.

Configurar el entorno de formación

Todos los comandos, manifiestos y scripts a los que se hace referencia a continuación se encuentran en el repositorio de GitHub de awsome-distributed-ai, en la dirección 3.test_cases/pytorch/trl/gpt-oss-lora-grpo/. Clona el repositorio y

cámbialo al directorio de casos de prueba:
clon de git https://github.com/awslabs/awsome-distributed-ai
cd awsome-distributed-ai/3.test_cases/pytorch/trl/gpt-oss-lora-grpo

Copia la plantilla de entorno y, a continuación, edita env_vars para configurar tu registro ECR, el nombre de la imagen, la etiqueta y el token de HuggingFace:

cp env_vars.ejemplo env_vars
fuente env_vars

Crea la imagen de entrenamiento y envíala a tu registro. La imagen incluye PyTorch, TRL, HuggingFace Transformers, PEFT y los scripts de entrenamiento e inferencia

:
artefactos d &. /build_push.sh y cd.

Dirija kubectl a su clúster y aplique el pod del administrador de almacenamiento FSx. El administrador de almacenamiento le proporciona un shell en el sistema de archivos compartido para la conversión en puntos de control

y la inspección del registro de evaluación:
aws eks update-kubeconfig --name --region us-east-2
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN'\
 < kubernetes/fsx-storage-manager.yaml | kubectl apply -f -

Ajuste el GPT-OSS-20B con SFT y LoRa

Empezamos midiendo el modelo base, luego configuramos la ejecución del SFT y examinamos los resultados.

La brecha entre el modelo base

El GPT-OSS-20B basado en la evaluación de 50 casos obtuvo un 22 por ciento de aciertos en el lenguaje de razonamiento (11/50).

Por idioma: inglés 100 por ciento, francés 0 por ciento, alemán 10 por ciento, español 0 por ciento, italiano 0 por ciento. El modelo utiliza de forma predeterminada el razonamiento en inglés independientemente de la instrucción

.

Configuración SFT

La configuración SFT utilizó LoRa r=8, α=16, entrenado para dar 1000 pasos en 4 × ml.g6e.12 x large (16 × L40S 48 GB) con datos completamente fragmentados en paralelo (FSDP), precisión bf16 y puntos de control de gradiente.

El trabajo se ejecuta como un HyperpodPyTorchJob elástico administrado por Kueue y lanzado con hyperpodrun.

Aplica el manifiesto de SFT:

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

Observa el progreso del entrenamiento:

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

norma de pérdida y gradiente imprime cada paso. Una carrera saludable tiene este aspecto:

{'loss': 1.035, 'grad_norm': 0.163, 'learning_rate': 0.0002, 'mean_token_accuracy': 0.716, 'epoch': 3.25}
{'pérdida': 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
}

Cuando termine el entrenamiento, convierta el punto de control del FSDP al formato PEFT (ajuste preciso según los parámetros) que esperan el entrenador de GRPO de TRL y los guiones de inferencia:

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

Los resultados de SFT y la curva de aprendizaje por etapas

Después de la SFT, el modelo razona en el idioma correcto el 100 por ciento de las veces (50/50) en los cinco idiomas. SFT aprendió esto en

dos etapas:
  • Alrededor de la etapa 200, el modelo aprendió a razonar en el idioma de destino (la métrica del lenguaje de razonamiento alcanza el 100 por ciento).
  • Alrededor del paso 1000, el modelo también aprendió a dar la respuesta en el idioma de destino.

Evaluación final de SFT (paso 1000):

  • Lenguaje de razonamiento correcto: 100 por ciento (50/50).
  • Lenguaje de respuesta correcto: 62 por ciento (31/50).
  • Ambos aciertos: 62 por ciento (31/50).
  • Precisión de respuesta por idioma: FR 60 por ciento, DE 60 por ciento, ES 30 por ciento, IT 60 por ciento, EN 100 por ciento.

Conclusión: el SFT no es opcional en este caso. El modelo base no puede seguir en absoluto la enseñanza del lenguaje del razonamiento, y SFT lleva el lenguaje del razonamiento del 22 por ciento al 100 por ciento. La brecha restante es el lenguaje de las respuestas, con un 62 por ciento. Esa es la parte más difícil, porque la respuesta final es corta y el inglés previo es más fuerte allí

.

Refina el lenguaje de las respuestas con GRPO

El

lenguaje de las respuestas era el objetivo obvio del GRPO. El SFT ya producía un razonamiento correcto el 100 por ciento de las veces, y el modelo a veces producía la respuesta en el idioma correcto, por lo que había una

señal para reforzarlo.

Ejecute GRPO en la parte superior del punto de control de SFT

Ejecutamos GRPO con el GRPOTrainer de TRL, empezando por el puesto de control de SFT. La configuración: cargar el SFT LoRa, ejecutar merge_and_unload y añadir un nuevo LoRa (r=8, α=16, aproximadamente un 0,068 por ciento de parámetros entrenables, 13,6 M de 20 B). En el entrenamiento se utilizaron K = 8 generaciones por mensaje, device_map=auto, una tasa de aprendizaje de 1 a 6 y 10 épocas. La función de recompensa puntuó el lenguaje de respuesta (±5,0), el lenguaje de razonamiento (±1,5) y la brevedad (+0,5 o −1,0), lo que arroja un rango combinado de −7,5 a +7,0

.

Lanza GRPO desde el punto de control SFT convertido:

envsubst '$REGISTRY $IMAGEN $ETIQUETA $HF_TOKEN'\
 < kubernetes/train-grupo-singlenode.yaml | kubectl apply -f -
kubectl registra -f grpo-single

GRPO escribe los puntos de control en /fsx/checkpoints/grpo-singlenode/. Elija el mejor punto de control para compararlo con la evaluación que no ha realizado (la métrica basada en el lenguaje de respuestas alcanzó su punto máximo al principio de esta ejecución) y conviértala al formato PEFT para fines de inferencia

y evaluación.

Resultado (del punto de control de la SFT):

  • El lenguaje de razonamiento es correcto: 100 por ciento (mantenido: el GRPO no rompió lo que enseñaba SFT).
  • Lenguaje de respuesta correcto: del 62 al 70 por ciento (+8 puntos, 35/50).
  • Ambas aciertan: 70 por ciento.
  • Respuesta por idioma: FR 70 por ciento, DE 80 por ciento, ES 60 por ciento, IT 40 por ciento, EN 100 por ciento.

El GRPO obtuvo una ganancia real de +8 puntos en la métrica del lenguaje de respuesta, mientras que mantuvo el razonamiento en un 100 por ciento. La ganancia se produjo cuando había margen para ganar. El lenguaje de las respuestas era el comportamiento, a veces correcto, en el que SFT no había convergido del todo, y el GRPO lo reforzó

.

Compare las inferencias de base, SFT y GRPO una al lado de la otra

Para ver la diferencia cualitativa, implemente tres módulos de inferencia que compartan el mismo modelo base pero carguen adaptadores diferentes:

envsubst '$REGISTRY $IMAGEN $ETIQUETA $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-grupo.yaml | kubectl apply -f -

Ejecuta el mismo mensaje de razonamiento francés en cada variante:

kubectl exec -it base de inferencias -- python /app/inference_g6e.py\
 --reasoning_language (francés)

kubectl exec -it entrenado por inferencia -- python /app/inference_g6e.py\
 --checkpoint /fsx/checkpoints/converted-peft/lora-checkpoint-1000-peft\
 --reasoning_language (francés)

kubectl exec -it inference-grupo -- python /app/inference_grpo_new.py\
 --use_grpo\
 --grpo_checkpoint /fsx/checkpoints/converted-left/checkpoint-1470-peft\
 --reasoning_language (francés)

El módulo base razona en inglés a pesar de las instrucciones. El módulo SFT razona en francés, pero a menudo responde en inglés. El módulo GRPO razona y responde en francés. Para reproducir la evaluación completa de 50 casos que generó los números anteriormente, ejecute el manifiesto de evaluación y lea el archivo de resultados desde el administrador de almacenamiento de FSx:

envsubst '$REGISTRY $IMAGEN $ETIQUETA $HF_TOKEN'\
 < kubernetes/eval-grupo.yaml | kubectl apply -f -
kubectl registra -f | eval-grupo
kubectl exec fsx-storage-manager --\
 cat /fsx/experiments/grupo_eval_checkpoint1470_ *.txt

Para comprender de manera más amplia cuándo el GRPO agrega valor, realizamos un experimento controlado en Qwen2.5-7B en dos tareas con diferentes brechas de capacidad.

Pruebe el patrón con un control Qwen2.5-7B

Para probar la tesis de «combinar la técnica con la brecha de capacidad» en un modelo diferente y diferentes tareas, realizamos experimentos controlados con el Qwen2.5-7B-Instruct. La primera tarea es la misma tarea de razonamiento multilingüe (cuando hay margen de maniobra). La segunda tarea es el GSM8K, donde el modelo ya tiene la máxima precisión. Este es un experimento interno y el repositorio público aún no se ha publicado

.

Infraestructura: 2 g6e.48 x large (16 × L40S), EFA 100 Gbps, FSx Lustre, Ray 2.44 + KubeRay 1.4.2, VerL v0.6.1, vLLM 0.8.4.

Brazos: A = base, B = solo SFT, C = SFT+GRPO.

Razonamiento multilingüe (50 casos)

Métrico Una base SÉ SUAVE C SFT+GRUPO GRUPO Δ
Formato estructurado 0% 92% 98% +6
Lenguaje de razonamiento 0% 96% 98%
+2
Idioma de respuesta 0% 38% 44% +6
Ambos correctos 0% 38% 44% +6

GSM8K, una tarea sin margen

En el GSM8K, el Qwen2.5-7B básico ya obtiene una puntuación del 90,5 por ciento (181/200). El GRPO en el paso 30 también obtiene una puntuación del 90,5 por ciento. Cuando la mayoría de los grupos muestreados son totalmente correctos, la ventaja relativa del grupo se reduce a cero, por lo que no hay ninguna señal de aprendizaje. Esta es la otra mitad de la tesis: el GRPO necesita margen (pass @k >> pass @1) para tener algo que optimizar. Sin margen de maniobra no hay ganancia

.

Mejores prácticas

  1. Comience con SFT. El GRPO no puede enseñar un comportamiento con una probabilidad de base cero. Solo puede reforzar las respuestas que el modelo ya produce a veces. La SFT hizo que el lenguaje de razonamiento pasara del 22 por ciento al 100 por ciento, y cada GRPO que ganó en este trabajo se basó en ese punto
  2. de control de la SFT.
  3. Usa LoRa tanto para SFT como para GRPO. LoRa r=8/α=16 era eficiente en cuanto a parámetros (se podía entrenar un 0,068 por ciento) y, en el control Qwen, se mantuvo numéricamente estable gracias al GRPO (la norma de clasificación es de 0,23, unos 11,7 GB por GPU). Es un valor predeterminado seguro cuando quieres que SFT y GRPO compartan la misma forma de adaptador.
  4. Haga coincidir la técnica con la brecha. Use SFT para detectar el comportamiento faltante. Use GRPO para refinar un comportamiento existente, que a veces es correcto. El límite realista de GRPO en este caso era de +6
  5. a +8 puntos.
  6. Comprueba el margen de recompensa antes de dedicarle horas a la GPU. Si la mayoría de los grupos tienen toda la razón (GSM8K con una base del 90,5 por ciento), la ventaja relativa del grupo se reduce a cero y el GRPO no obtiene ningún gradiente. Verifique que haya margen de maniobra (pase @k >> pase
  7. @1) antes de iniciar una ejecución de GRPO.

Limpiar los recursos

Para evitar cargos continuos, elimine los recursos de la carga de trabajo y, a continuación, la infraestructura subyacente:

  1. Elimine los módulos y trabajos de entrenamiento e inferencia:
    kubectl eliminar hyperpodpytorchjob lora-hyperpod-elastic --ignore-not-found
    kubectl borra pod grupo-inferencia-base única inferencia-grupo entrenado\
     eval-grpo fsx-storage-manager
  2. --ignore-non-found
  3. Reduzca o elimine el clúster HyperPod de Amazon SageMaker o sus grupos de nodos.
  4. Elimine el sistema de archivos Amazon FSx for Lustre una vez que haya exportado los puntos de control que quiera conservar.
  5. Elimine cualquier depósito u objeto de Amazon Simple Storage Service (Amazon S3) que se utilice para archivar datos de entrenamiento o puntos de control.

Conclusión

Mostramos cómo ajustar el GPT-OSS-20B para el razonamiento multilingüe en Amazon SageMaker HyperPod y cómo decidir entre SFT y GRPO. La SFT hizo la mayor parte del trabajo: el lenguaje de razonamiento pasó del 22 por ciento al 100 por ciento. El GRPO añadió un refinamiento real y modesto a los lugares donde había margen de maniobra (respuesta del 62 al 70 por ciento). Un control paralelo de Qwen2.5-7B confirmó el patrón. El GRPO añadió un 6 por ciento más en el razonamiento multilingüe, aspecto en el que había margen de mejora. No supuso ninguna ventaja respecto al GSM8K, donde el modelo ya tenía una precisión máxima (90,5 por

ciento).

Marco de decisión:

  • Comportamiento que el modelo no puede realizar en absoluto: utilice SFT.
  • Comportamiento que tiene a veces, con margen de maniobra: usa SFT y luego GRPO por unos cuantos puntos más.
  • El modelo ya tiene la máxima precisión o el objetivo tiene una probabilidad base cero: el GRPO no ayudará.

Para probarlo tú mismo, recorre los casos de prueba del repositorio awsome-distributed-ai. Para obtener más información sobre Amazon SageMaker HyperPod, consulte la página de detalles del servicio y la documentación de Amazon SageMaker HyperPod. Para ver un tutorial sobre Ray en Amazon SageMaker HyperPod, consulte la publicación relacionada Cómo ejecutar cursos distribuidos en Amazon SageMaker HyperPod con Ray y Amazon SageMaker Studio. El enlace se añadirá una vez que se publique la entrada. Comparte tus resultados en los comentarios.


Acerca de los autores

Mijanur Palash

Mijanur Palash

Mijanur es arquitecto de soluciones especializado en el equipo de infraestructura de inteligencia artificial y aprendizaje automático de AWS. Se centra en las cargas de trabajo distribuidas de formación y aprendizaje por refuerzo en Amazon SageMaker HyperPod para clientes de la industria automotriz, farmacéutica y de inteligencia artificial generativa. Fuera del trabajo, a Palash le gusta el senderismo y

la fotografía.
Mark Vinciguerra

Mark Vinciguerra

Mark fue arquitecto de soluciones especializado en IA generativa a nivel mundial en AWS y se especializó en el entrenamiento distribuido y la inferencia en Amazon SageMaker HyperPod. Trabaja con clientes estratégicos en cargas de trabajo a gran escala basadas en modelos básicos basados en la orquestación de EKS y Slurm, y contribuye con arquitecturas de referencia y talleres para HyperPod, Ray y SageMaker Unified Studio

.

¿Tiene un proyecto de software o plataforma SaaS en mente?

Hable directamente con nuestros arquitectos de software en SoftAndino. Le brindamos asesoría técnica y cotización inmediata sin compromiso.