Exécuter Nemotron sur AWS : prérequis et premières étapes

Pour démarrer le déploiement de Nemotron sur AWS, l’exemple officiel demande l’accès à certaines instances GPU, Git et Docker en local, ainsi que des autorisations AWS pour EC2, EKS et FSx for Lustre. Son parcours EKS standard décrit les premières étapes, de la configuration de la région à la vérification des nœuds du cluster.

Les prérequis de l’exemple AWS

Le parcours AWS pour Nemotron prévoit un compte ayant accès à des instances P5en.48xlarge ou P6-b200.48xlarge. Une hausse de quota ou une réservation de capacité peut être nécessaire. Il faut aussi disposer de Git et Docker sur un terminal, et d’identifiants AWS autorisés à gérer EC2, EKS et FSx for Lustre.

Ces conditions concernent le parcours de l’exemple. Une fois le cluster créé, le dépôt enchaîne avec l’installation de pilotes, de modules complémentaires et d’opérateurs Kubernetes, puis la validation, le téléchargement des poids du modèle, le déploiement, les tests et le nettoyage des ressources.

Les premières étapes avec EKS standard

L’exemple commence par le cluster EKS standard. Suivez les actions dans cet ordre :

1. Clonez le dépôt aws-do-eks. Il contient le script auxiliaire et les fichiers de configuration utilisés dans les étapes suivantes.
2. Configurez la région avec ./config.sh. Le script prépare la configuration régionale du parcours.
3. Construisez l’image auxiliaire avec ./build.sh. Le guide utilise cet environnement pour les opérations de configuration.
4. Démarrez le conteneur avec ./run.sh. Cette étape lance l’environnement auxiliaire.
5. Vérifiez son état avec ./status.sh. Vous pouvez ainsi contrôler que le conteneur a démarré.
6. Ouvrez son terminal avec ./exec.sh. Les étapes suivantes se déroulent dans cet environnement.
7. Configurez les identifiants AWS avec aws configure. Le parcours a besoin de ces identifiants pour agir sur les services autorisés.
8. Choisissez le manifeste du cluster avec ./env-config.sh. Le manifeste détermine la configuration sélectionnée pour le cluster.
9. Modifiez les paramètres avec ./eks-config.sh. Le script permet d’ajuster les réglages du cluster avant sa création.
10. Créez le cluster avec ./eks-create.sh. AWS indique que cette opération peut prendre jusqu’à 30 minutes.
11. Vérifiez les nœuds avec kubectl get nodes. Cette commande affiche les nœuds créés.

Choisir une orchestration et dimensionner les GPU

AWS décrit trois options d’orchestration pour ce déploiement : Amazon EKS standard, Amazon EKS Auto Mode et Amazon SageMaker HyperPod EKS. Selon AWS, les mêmes manifestes Kubernetes peuvent être utilisés avec ces trois options. En mode Auto Mode, AWS gère la mise à l’échelle ainsi que la prise en charge des GPU et d’EFA, l’Elastic Fabric Adapter.

L’architecture présentée par AWS associe des nœuds CPU et GPU. Amazon ECR héberge les images de conteneurs, Amazon FSx for Lustre fournit le stockage partagé des poids du modèle et EFA relie les nœuds GPU. L’exemple propose aussi plusieurs choix de stockage, de précision et de topologie, avec NVIDIA Dynamo et vLLM pour le service du modèle. Il s’agit d’un parcours sur cluster GPU autogéré, pas d’une procédure de service sans serveur sur Bedrock.

Pour vLLM, AWS donne les minima de GPU suivants selon l’accélérateur et la précision du point de contrôle :

Ces nombres sont des minima pour faire tourner le modèle avec vLLM. Ils ne dimensionnent pas à eux seuls l’ensemble du cluster.

Lire le résultat de latence dans son contexte

AWS rapporte un TTFT plus faible, c’est-à-dire un délai plus court avant le premier jeton, pour son déploiement désagrégé à deux nœuds que pour son déploiement agrégé. L’ITL, la latence entre les jetons produits, était à peu près similaire. Le graphique d’AWS compare toutefois 8 GPU en agrégé à 16 GPU en désagrégé : les deux configurations ne mobilisent donc pas le même nombre de GPU.

Le graphique porte sur Nemotron 3.5 Super VL en BF16 sur H200, avec 1 024 jetons en entrée et 512 en sortie. Il balaie des niveaux de concurrence de 1 à 128 et indique un lancement par cellule. AWS rapporte ces résultats pour ces conditions précises.

Vérifier le cluster et mesurer sa charge

AWS recommande un microbenchmark all-reduce de NCCL, la bibliothèque de communication collective de NVIDIA, pour vérifier le fonctionnement du cluster et du réseau. L’activité observée sur les GPU et les adaptateurs EFA pendant le test constitue, selon AWS, un signe que le cluster fonctionne comme prévu.

Pour mesurer le service du modèle, AWS utilise NVIDIA aiperf. L’outil permet de relever le TTFT, l’ITL et le débit de sortie à différents niveaux de concurrence. AWS conseille d’observer quelle ressource devient le facteur limitant : une hausse de l’ITL oriente vers davantage de capacité de décodage, tandis qu’une hausse du TTFT oriente vers davantage de capacité de préremplissage. (https://aws.amazon.com/blogs/machine-learning/accelerate-agentic-ai-with-nvidia-nemotron-models-on-amazon-eks-and-sagemaker-hyperpod-eks)