Préremplissage et décodage dissociés pour l'inférence LLM sur SageMaker HyperPod
Amazon Web Services a détaillé une nouvelle architecture d'inférence pour les grands modèles de langage sur SageMaker HyperPod, baptisée Disaggregated Prefill and Decode (DPD), conçue pour éliminer les ralentissements causés par les longs prompts. L'inférence LLM comporte deux phases très différentes : le prefill, qui traite l'intégralité du prompt en parallèle pour générer le cache clé-valeur initial, est limité par la puissance de calcul, tandis que le decode, qui génère les tokens un par un, dépend surtout de la bande passante mémoire. Lorsque ces deux phases partagent le même GPU, un prompt long bloque la génération de tokens pour toutes les autres requêtes en cours. La solution d'AWS sépare physiquement ces deux étapes sur des pools de GPU distincts, reliés par la technologie Elastic Fabric Adapter (EFA) avec accès direct à la mémoire à distance (RDMA), en s'appuyant sur vLLM et le HyperPod Inference Operator.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
Cette séparation permet d'ajuster indépendamment le temps jusqu'au premier token (TTFT) et la latence entre les tokens (ITL), tout en offrant un contrôle plus fiable sur la latence de queue que les méthodes classiques de découpage du prefill. Elle est particulièrement utile pour les charges de travail à fort trafic et à contexte long : assistants conversationnels, pipelines d'agents autonomes, analyse de documents ou génération augmentée par récupération (RAG) avec de larges contextes récupérés. AWS recommande cette architecture dès que les prompts dépassent régulièrement 4 096 tokens, en cas de requêtes concurrentes multiples, de réponses en streaming, ou de trafic mixte mêlant prompts courts et longs. Pour des charges simples, en batch ou à faible concurrence, un déploiement classique reste suffisant, le coût de transfert du cache via EFA RDMA ne se justifiant pas en dessous d'un certain seuil.
L'architecture repose sur trois composants principaux articulés autour du routeur de la pile de production vLLM, avec LMCache assurant le transfert du cache clé-valeur via NIXL et EFA. Le routeur intelligent joue le rôle de plan de contrôle : il analyse chaque prompt et, selon un seuil configurable de tokens, décide s'il doit emprunter le chemin désagrégé ou être traité entièrement par un seul décodeur. Les requêtes longues passent d'abord par un nœud de prefill, qui calcule le cache et le transmet à un nœud de décodage via LMCache, avant que ce dernier ne génère la réponse. Le routeur prend également en charge plusieurs stratégies de routage, comme la priorité aux préfixes communs, la connaissance du cache ou le round-robin, afin de maximiser la réutilisation du cache entre les répliques. Ce déploiement nécessite au minimum un nœud de prefill et un nœud de decode équipés d'un réseau EFA compatible RDMA.
Les entreprises européennes utilisant AWS SageMaker pourraient réduire leurs couts et leur latence d'inférence LLM en adoptant cette architecture, sans impact réglementaire ou économique direct sur la France ou l'UE.
Mélanger prefill et décodé sur le même GPU, c'est le genre de détail d'architecture qui plombe silencieusement la latence dès qu'un prompt dépasse 4000 tokens, tout le monde qui fait tourner vLLM en prod le savait déjà. Séparer les deux pools change la donne surtout pour les agents autonomes et le RAG à gros contexte, où le prompt long devient la norme plutôt que l'exception. Sur le papier ça complexifie le déploiement (deux types de nœuds, du RDMA à câbler), mais si t'as du trafic mixte à tenir, c'est clairement la direction que prend toute l'inférence LLM.