Comment vLLM résout l'inefficacité des GPU grâce au batching continu et à PagedAttention

Les grands modèles de langage sont des moteurs de prédiction, non des serveurs, ce qui crée une inadéquation fondamentale lors du traitement de volumes élevés de requêtes. L'exécution de ces modèles une requête à la fois laisse la majeure partie de la puissance de calcul du GPU inactive, augmentant les coûts et limitant la scalabilité pour les développeurs construisant des produits IA.

Ce qui s'est passé

Le défi consistant à servir des modèles à poids ouverts à grande échelle a conduit les ingénieurs à adopter vLLM, un serveur d'inférence et un framework conçu spécifiquement pour les environnements à haut débit. Issu du Sky Computing Lab de l'UC Berkeley en 2023, vLLM répond aux inefficacités fondamentales du déploiement standard des LLM en repensant la manière dont les requêtes sont regroupées (batching) et dont la mémoire est gérée sur les GPU.

Les méthodes d'inférence traditionnelles peinent car elles traitent les requêtes séquentiellement ou utilisent un batching statique, où des groupes de requêtes commencent et se terminent ensemble. Cette approche ne tient pas compte de la longueur variable des réponses des LLM, entraînant un gaspillage significatif de cycles de calcul lorsque les requêtes rapides attendent la fin des requêtes plus lentes. vLLM introduit le batching continu et une technique novatrice de gestion de la mémoire appelée PagedAttention pour maintenir les GPU pleinement utilisés.

Ce framework est devenu la solution de référence pour les environnements de production où l'efficacité des coûts et le débit sont critiques. En découplant l'achèvement des requêtes de l'exécution des batches, vLLM garantit que chaque passe avant effectue un travail utile, augmentant considérablement le nombre de tokens générés par seconde sans nécessiter de matériel supplémentaire.

Comment cela fonctionne

L'inférence des LLM comprend deux phases : le prefill, où le modèle traite le prompt d'entrée, et le decode, où il génère les tokens de sortie un par un. Dans les configurations standards, la phase de decode est inefficace car le GPU doit charger l'intégralité des poids du modèle pour chaque génération de token unique. Le batching statique améliore légèrement cette situation en traitant plusieurs requêtes simultanément, mais il souffre de l'effet traînard (straggler effect), où les réponses courtes bloquent le démarrage de nouveaux batches pour les réponses plus longues.

vLLM remplace le batching statique par le batching continu. Au lieu d'attendre que toutes les requêtes d'un batch soient terminées, le planificateur insère immédiatement de nouvelles requêtes dans la prochaine passe avant dès qu'une requête existante se termine. Cela maintient le GPU occupé en permanence, maximisant ainsi le débit. Cependant, le batching continu nécessite une gestion efficace de la mémoire, car chaque requête active maintient un cache Key-Value (KV) qui croît avec chaque token généré.

Pour résoudre le problème de fragmentation de la mémoire, vLLM utilise PagedAttention. Les frameworks traditionnels réservent une mémoire correspondant au pire cas pour le cache KV de chaque requête, entraînant un gaspillage massif. PagedAttention traite le cache KV comme la mémoire virtuelle d'un système d'exploitation, le stockant dans des blocs non contigus. Cela permet au système d'allouer la mémoire dynamiquement et de partager des blocs entre les requêtes lorsque c'est possible, garantissant que la mémoire du GPU n'est utilisée que pour les données actives plutôt que pour des réserves potentielles.

Détails clés

• vLLM a été présenté dans un article de recherche publié en 2023 par des chercheurs du Sky Computing Lab de l'UC Berkeley.
• Le framework utilise le batching continu pour ajouter de nouvelles requêtes aux passes avant dès que les précédentes se terminent.
• PagedAttention gère la mémoire du cache KV dans des blocs non contigus, de manière similaire au paginage de la mémoire virtuelle d'un OS.
• Le batching statique standard gaspille des ressources de calcul en forçant les requêtes rapides à attendre les requêtes lentes au sein du même batch.
• Le cache KV stocke les paires clé-valeur pour chaque token, augmentant à chaque étape de la génération.
• vLLM expose un point de terminaison API compatible OpenAI pour faciliter l'intégration dans les applications existantes.

Pourquoi c'est important

Pour les ingénieurs logiciels et les fondateurs techniques, l'utilisation du GPU est directement liée aux coûts d'infrastructure. Lorsqu'un modèle traite une requête à la fois, le matériel coûteux reste largement inactif pendant la phase de decode. En adoptant vLLM, les équipes peuvent servir un nombre significativement plus élevé d'utilisateurs avec le même budget matériel, rendant les modèles à poids ouverts viables pour des applications de production nécessitant une faible latence et une forte concurrence.

La transition du batching statique au batching continu améliore également l'expérience utilisateur en réduisant les temps d'attente. Dans les systèmes statiques, un utilisateur soumettant une requête courte peut être retardé par un batch précédent contenant une requête longue et complexe. Le batching continu garantit qu'aucune requête ne reste inactive pendant que d'autres se terminent, offrant une performance API plus prévisible et réactive. Cette fiabilité est essentielle pour les fonctionnalités IA destinées aux consommateurs, où la vitesse perçue impacte l'engagement.

De plus, l'efficacité mémoire offerte par PagedAttention supprime un obstacle majeur à la montée en charge. Sans elle, les ingénieurs doivent surdimensionner la mémoire pour gérer les scénarios de longueur maximale, ce qui limite le nombre de requêtes concurrentes qu'un seul GPU peut traiter. L'allocation dynamique de vLLM permet des déploiements à plus haute densité, simplifiant la planification de capacité et réduisant le besoin d'optimisations manuelles complexes des tailles de batch.

Ce que vous pouvez faire

• Remplacez les pipelines Hugging Face standards par vLLM pour tout déploiement de modèle à poids ouvert nécessitant un haut débit.
• Configurez votre serveur d'inférence pour utiliser le batching continu plutôt que le batching statique afin de réduire le temps d'inactivité du GPU.
• Surveillez l'utilisation du cache KV pour comprendre la pression mémoire et ajustez les paramètres de longueur maximale du modèle en conséquence.
• Utilisez le point de terminaison API compatible OpenAI fourni par vLLM pour minimiser les modifications dans votre code côté client.
• Effectuez des benchmarks de votre configuration actuelle de batching statique contre vLLM pour quantifier les améliorations en tokens par seconde.
• Assurez-vous que votre application gère gracieusement les temps de réponse variables, car le batching continu peut modifier les profils de latence.