Ajuster finement des modèles GPT-OSS OpenAI avec les recettes SageMaker HyperPod

TL;DR

Ajustez finement les modèles GPT-OSS OpenAI en utilisant les recettes SageMaker HyperPod ou les jobs d’entraînement SageMaker.
Les recettes HyperPod fournissent des configurations préconstruites et validées pour des modèles de fondation tels que Llama, Mistral et DeepSeek, permettant des expériences rapides et à grande échelle.
Le processus prend en charge le raisonnement multilingue avec le jeu de données Multilingual-Thinking de HuggingFace et une longueur de séquence de 4 000 tokens pour le GPT-OSS 120B.
Les données sont stockées sur FSx for Lustre pour HyperPod ou sur S3 pour les jobs d’entraînement ; les artefacts finaux sont sur S3 et déployés sur des endpoints SageMaker via des conteneurs vLLM.
Les prérequis couvrent l’accessibilité du cluster et la configuration de l’environnement ; le lanceur HyperPod automatise l’orchestration sur des architectures telles que EKS ou Slurm, tandis que les jobs d’entraînement gèrent le provisionnement des ressources.

Contexte et antécédents

Cet article est la deuxième partie de la série GPT-OSS axée sur la personnalisation des modèles avec SageMaker AI d’Amazon. Dans la Partie 1, nous avons démontré l’ajustement fin de modèles GPT-OSS en utilisant des bibliothèques open source Hugging Face avec des jobs d’entraînement SageMaker, qui prennent en charge des configurations distribuées multi-GPU et multi-nœud. Dans ce post, nous montrons comment affiner des modèles GPT-OSS via des recettes sur SageMaker HyperPod et Training Jobs. Les recettes HyperPod facilitent le démarrage de l’entraînement et du réglage fin de modèles publics de référence tels que Llama de Meta, Mistral et DeepSeek en quelques minutes, en utilisant soit HyperPod soit des jobs d’entraînement. Les recettes fournissent des configurations préconstruites et validées qui réduisent la complexité de la mise en place d’environnements d’entraînement distribués tout en garantissant des performances et une évolutivité de niveau entreprise. Nous décrivons les étapes pour affiner le modèle GPT-OSS sur un jeu de données de raisonnement multilingue HuggingFaceH4/Multilingual-Thinking, afin que GPT-OSS gère un raisonnement structuré en plusieurs langues. Cette solution utilise les recettes SageMaker HyperPod pour lancer un ajustement fin sur HyperPod via l’orchestration EKS ou Training Jobs. Les recettes passent par le lanceur de recettes SageMaker HyperPod, qui agit comme couche d’orchestration responsable du lancement du travail sur l’architecture correspondante, telle que SageMaker HyperPod (Slurm ou Amazon EKS) ou Training Jobs. Pour les détails sur les recettes HyperPod, consultez SageMaker HyperPod recipes. Pour les détails sur l’ajustement fin du modèle GPT-OSS, consultez Fine-tune OpenAI GPT-OSS models on Amazon SageMaker AI using Hugging Face libraries. Dans les sections suivantes, nous décrivons les prérequis pour les deux options et passons ensuite à la préparation des données. Les données préparées sont sauvegardées sur Amazon FSx for Lustre, utilisé comme système de fichiers persistant pour SageMaker HyperPod, ou sur Amazon S3 pour Training Jobs. Nous utilisons ensuite les recettes pour soumettre le travail d’ajustement fin et enfin déployons le modèle entraîné sur un endpoint SageMaker pour des tests et évaluations.

Ce qui est nouveau

Les recettes HyperPod étendent le flux d’ajustement fin du GPT-OSS à un cluster persistant préconfiguré et validé pour l’échelle d’entreprise. Vous pouvez exécuter l’ajustement fin sur SageMaker HyperPod avec une orchestration EKS ou utiliser des jobs d’entraînement SageMaker pour une puissance de calcul à la demande. Le jeu de données multilingue Multilingual-Thinking offre des exemples CoT traduits dans des langues telles que le français, l’espagnol et l’allemand, permettant au GPT-OSS d’effectuer un raisonnement multilingue. La recette prend en charge une longueur de séquence de 4 000 tokens pour le modèle GPT-OSS 120B. Le lanceur de recettes HyperPod gère l’orchestration selon l’architecture choisie. Pour des conseils détaillés, consultez le post AWS référencé.

Contexte et arrière-plan (suite)

La préparation des données suit une approche directe : tokeniser le jeu Multilingual-Thinking au format Hugging Face (arrow) et enregistrer le jeu traité sur disque avant l’ajustement. L’approche s’aligne sur les deux chemins d’exécution — HyperPod et Training Jobs — en mettant l’accent sur la performance, la résilience et l’évolutivité de niveau entreprise. Le guide précise que le stockage varie selon le chemin : FSx for Lustre pour HyperPod et S3 pour Training Jobs. Le modèle cible est le GPT-OSS 120B, avec une longueur de séquence de 4 000 tokens.

Pourquoi c’est important (impact pour les développeurs/entreprises)

Pour les développeurs et les entreprises, ce flux permet d’expérimenter rapidement avec des grands modèles ouverts tout en conservant le contrôle sur les ressources de formation distribuée. Les recettes HyperPod réduisent la complexité de la configuration d’environnements distribués et offrent des clusters persistants adaptés au développement continu et à l’expérimentation. Les jobs d’entraînement offrent une option totalement gérée pour des charges d’entraînement ponctuelles ou récurrentes. L’alliance HyperPod et Training Jobs donne une flexibilité sur le moment et la manière de s’entraîner, tandis que le jeu de données multilingue étend les capacités multi-langues. L’artéfact final fusionne le modèle de base avec des adaptateurs PEFT personnalisés et est stocké sur S3, prêt à être déployé en endpoints SageMaker. Le déploiement nécessite des conteneurs vLLM compatibles et une approche d’hébergement conforme aux pratiques SageMaker.

Détails techniques ou mise en œuvre

Cette section décrit les étapes pratiques et les composants impliqués dans le processus.

Prérequis

S’assurer que les quotas et limites de service sont approuvés (peuvent prendre jusqu’à 24 heures).
Il est possible de réserver des plans de formation pour des créneaux spécifiques, comme décrit dans les directives AWS.
Préparer un environnement de développement avec Python 3.9 ou supérieur. Avoir accès à SageMaker HyperPod, au launcher de recettes HyperPod et aux fichiers de configuration associés.

Préparation des données

Utiliser le jeu HuggingFaceH4/Multilingual-Thinking, un jeu de données multilingue avec des exemples CoT traduits en langues comme le français, l’espagnol et l’allemand.
Tokeniser le jeu pour le modèle GPT-OSS 120B ; la recette accepte les données au format Hugging Face (arrow) et peut sauvegarder le jeu traité sur disque pour l’ajustement.

Ajustement fin avec SageMaker HyperPod

Configurer l’environnement virtuel et les dépendances pour exécuter l’entraînement sur le cluster EKS. Confirmer que le cluster est InService et que Python 3.9+ est actif.
Télécharger et configurer le dépôt de recettes SageMaker HyperPod. Utiliser le launcher de recettes pour soumettre le travail d’entraînement.
Dans recipes_collection/cluster/k8s.yaml, mettre à jour la section persistent_volume_claims pour monter FSx dans /fsx sur chaque pod.
Le launcher fournit un script de lancement pour chaque recette sous launcher_scripts. Pour ajuster le GPT-OSS-120B, modifier le script launcher_scripts/gpt_oss/run_hf_gpt_oss_120b_seq4k_gpu_lora.sh et définir cluster_type sur k8s.
Après préparation, soumettre l’ajustement fin. Utiliser kubectl pour vérifier que les pods fonctionnent et examiner les journaux (par exemple kubectl logs -f hf-gpt-oss-120b-lora-h2cwd-worker-0).
Les checkpoints sont écrits dans /fsx/experiment/checkpoints. Le modèle final fusionné se trouve dans /fsx/experiment/checkpoints/peft_full/steps_50/final-model dans le répertoire de l’expérience.

Ajustement fin avec les jobs d’entraînement SageMaker

En alternative, utilisez les jobs d’entraînement SageMaker avec l’estimateur PyTorch et le paramètre training_recipe pour spécifier la recette d’ajustement.
Définissez input, output et results dans /opt/ml selon les exigences des jobs d’entraînement SageMaker.
Après soumission, suivez l’état dans la console SageMaker sous Training et consultez les journaux pour confirmer l’achèvement. Les sorties sont sauvegardées dans un emplacement S3 et l’emplacement de l’artéfact est affiché dans les détails du travail.

Déploiement et hosting

Après l’ajustement, l’artéfact est un modèle personnalisé fusionnant le modèle de base et les adaptateurs PEFT. L’artéfact est stocké sur S3 et peut être déployé directement depuis S3 vers des endpoints SageMaker.
Pour servir les modèles GPT-OSS, assurez-vous d’utiliser les conteneurs vLLM les plus récents compatibles OpenAI (version 0.10.1 ou ultérieure). Une liste complète des images Docker vllm-openai est disponible sur Docker Hub.
Le déploiement consiste à construire un conteneur d’hébergement SageMaker qui étend l’image vLLM de base avec un script d’entrée compatible SageMaker. L’image est poussée vers ECR et l’endpoint se met en service en tirant l’image à l’exécution.
Un exemple de déploiement comprend un script build équivalent à build.sh, qui produit un conteneur vllm-openai optimisé pour SageMaker et l’envoie vers ECR, puis crée l’endpoint d’inférence. L’endpoint peut être invoqué via le SDK Python SageMaker en utilisant le format d’entrée OpenAI pour les échanges de type chat.
Le conteneur vLLM modifié est pleinement compatible avec le format de messages OpenAI, ce qui facilite les requêtes de chat.

Points importants

Cette intégration conserve les pratiques de hosting SageMaker tout en intégrant le runtime vLLM pour une inférence à faible latence.
L’architecture supporte à la fois des clusters HyperPod persistants et des jobs d’entraînement SageMaker à la demande, offrant une flexibilité pour les environnements de développement et de production.
Les données multilingues et la longueur de séquence de 4K étendent les capacités de GPT-OSS pour le raisonnement multilingue dans des scénarios pratiques.