AWS montre comment exécuter une LLM sur deux nœuds GPU EKS avec Ray LLM DLC

AWS a publié un guide pas à pas pour exécuter une grande LLM sur deux nœuds GPU Amazon EKS. Un nœud assure le prefill, l'autre le decode, et de l'extérieur, tout ressemble à un unique endpoint compatible OpenAI. Le dispositif repose sur les Deep Learning Containers Ray LLM multi-nœuds : des images prêtes à l'emploi qui regroupent déjà toute la pile d'inférence. L'assemblage des composants disparaît des tâches de l'équipe, il ne reste que la configuration du déploiement.

Ce que l'on déploie exactement

Le schéma est simple. Il y a un seul modèle, deux nœuds GPU dans un cluster Amazon EKS, et deux étapes distinctes du traitement d'une requête, réparties sur des machines différentes. L'application cliente ignore tout de la topologie. Elle s'adresse à une seule adresse via le protocole OpenAI habituel, et les SDK et outils existants continuent de fonctionner sans modification.

L'essentiel de cette annonce n'est pas l'idée elle-même, mais son packaging. Jusqu'ici, monter une inférence multi-nœuds supposait de choisir soi-même des versions compatibles du moteur, de l'orchestrateur, des pilotes et des bibliothèques réseau. AWS livre désormais le tout sous forme de conteneur préconstruit, issu de la gamme Deep Learning Containers. La prise en charge de Ray dans cette image se comprend : Ray sert depuis longtemps de couche d'orchestration pour les charges distribuées, et sa surcouche LLM est conçue pour servir des modèles via une API unique.

Pourquoi séparer prefill et decode

La génération de texte comporte deux phases au profil de charge différent. Le prefill traite l'intégralité du prompt d'entrée. Ce sont des calculs denses, limités par la puissance du GPU. Le decode produit les tokens un par un et se heurte plus souvent à la bande passante mémoire et à la taille du KV-cache.

Si les deux phases tournent sur les mêmes accélérateurs, elles se gênent mutuellement. Le long prompt d'un utilisateur retarde la production de tokens pour les autres. Séparer les phases par nœud permet de régler chaque côté indépendamment : parallélisme, taille de batch et volume de mémoire s'ajustent à la tâche. Le prix de cette approche est connu. Il faut transférer le KV-cache entre les nœuds, ce qui rend le réseau et la configuration correcte du connecteur essentiels. C'est précisément cette partie que prend en charge le conteneur.

Principaux paramètres du schéma

• Modèle : une seule grande LLM, répartie entre les nœuds.
• Topologie : deux nœuds GPU, l'un dédié au prefill, l'autre au decode.
• Plateforme : Amazon EKS, c'est-à-dire un Kubernetes standard en version managée.
• Interface : un endpoint unique compatible OpenAI pour tous les clients.
• Livraison : un Deep Learning Container Ray LLM multi-nœuds préconstruit, avec la pile d'inférence complète.
• Approche de configuration : configuration du déploiement, sans assemblage manuel des composants.

En pratique : les points à vérifier avant d'adopter

Cette architecture ne se justifie pas partout. Pour un petit modèle qui tient sur un seul nœud, la désagrégation n'ajoutera que des sauts réseau et des points de défaillance. Elle a du sens lorsque le modèle ne tient pas dans la mémoire d'un seul nœud, ou lorsque le profil de trafic est très hétérogène. Par exemple : des contextes longs en entrée pour des réponses courtes en sortie, ou l'inverse.

Avant un pilote, plusieurs points méritent d'être vérifiés :

• Connectivité entre les nœuds. Le transfert du KV-cache est sensible à la latence et à la bande passante : placez donc les nœuds dans la même zone de disponibilité et consultez la documentation AWS sur les types d'instances et les adaptateurs réseau pris en charge.
• Métriques par phase. Suivez le temps jusqu'au premier token, qui dépend du prefill, et la vitesse de production des tokens, qui dépend du decode. Une latence moyenne globale masquera un déséquilibre.
• Équilibre des nœuds. Un nœud par phase constitue un point de départ. Si une file d'attente s'accumule d'un côté, il faudra faire évoluer ce côté indépendamment.
• Compatibilité des clients. Une API compatible OpenAI simplifie la migration, mais le comportement des paramètres de requête rares doit être testé sur vos propres scénarios.

Pour les équipes qui sont déjà sur EKS et cherchent un moyen de servir de grands modèles sans plateforme d'inférence maison, c'est une voie rapide vers un prototype fonctionnel. Chacun doit mesurer le coût et les performances réelles sur son propre trafic : le guide décrit le déploiement, il ne garantit pas de gain précis.