vLLM : PagedAttention & Batching Continu, Clés de l'Inférence LLM

L'ère des Modèles de Langage à Grande Échelle (LLM) a transformé le paysage technologique, ouvrant des horizons inédits pour l'innovation. Cependant, avec cette puissance vient un défi de taille : l'inférence. Exécuter ces modèles gigantesques de manière efficace, rapide et économique est devenu un goulot d'étranglement majeur pour de nombreuses entreprises cherchant à intégrer l'IA avancée dans leurs produits et services. Chez Voronkin Web Development, nous sommes constamment à l'affût des technologies qui repoussent les limites de ce qui est possible, et c'est pourquoi nous nous penchons aujourd'hui sur vLLM, une solution qui promet de révolutionner l'inférence des LLM grâce à ses innovations clés : PagedAttention et le batching continu.

Dans cet article, nous allons explorer en profondeur comment vLLM aborde les problèmes fondamentaux de l'inférence LLM, en boostant l'utilisation du GPU et en améliorant considérablement les performances pour des applications d'IA hautement évolutives. Préparez-vous à une plongée technique qui démystifie ces concepts et révèle leur impact potentiel sur le développement web et les solutions d'IA.

Les Défis Inhérents à l'Inférence des LLM

Avant d'apprécier la portée de vLLM, il est essentiel de comprendre les obstacles auxquels est confrontée l'inférence des LLM. Les modèles modernes, tels que GPT-3.5, Llama ou Mixtral, sont caractérisés par des milliards de paramètres, ce qui les rend incroyablement lourds à charger en mémoire et à exécuter. Lorsque nous parlons d'inférence, nous faisons référence au processus par lequel le modèle génère une réponse à une invite donnée. Ce processus est séquentiel : le modèle génère un jeton (mot ou sous-mot) à la fois, en se basant sur tous les jetons précédents.

Un élément crucial de ce processus est le cache KV (Key-Value cache). Pour chaque nouveau jeton généré, le modèle doit "se souvenir" des représentations internes (les "clés" et les "valeurs") de tous les jetons précédents de la séquence. Ce cache KV est stocké dans la mémoire GPU et sa taille augmente linéairement avec la longueur de la séquence générée. Cela pose plusieurs problèmes majeurs :

• Consommation mémoire élevée : Le cache KV peut rapidement devenir le principal consommateur de mémoire GPU, dépassant parfois la taille des poids du modèle lui-même pour de longues séquences.
• Fragmentation mémoire : La taille du cache KV varie dynamiquement d'une requête à l'autre, et même au sein d'une seule requête à mesure que la séquence s'allonge. Les systèmes d'allocation mémoire traditionnels peinent à gérer cette variabilité, entraînant une fragmentation de la mémoire GPU et un gaspillage d'espace précieux.
• Sous-utilisation du GPU : En raison de la génération séquentielle des jetons et de la gestion inefficace du cache KV, les GPU ne sont souvent pas pleinement utilisés. Ils passent une partie significative de leur temps à attendre les données ou à gérer des opérations de mémoire inefficaces, plutôt qu'à effectuer des calculs matriciels intensifs.

Les approches traditionnelles de batching (regroupement de requêtes pour traitement simultané) tentent d'atténuer la sous-utilisation du GPU, mais elles introduisent leurs propres défis, comme nous le verrons plus loin. C'est dans ce contexte que vLLM émerge comme une solution disruptive, s'attaquant de front à ces problèmes fondamentaux.

vLLM : Une Architecture Pensée pour la Performance

vLLM est une bibliothèque open-source conçue spécifiquement pour l'inférence haute performance des LLM. Elle se distingue par son approche radicalement différente de la gestion de la mémoire et de l'ordonnancement des requêtes. L'objectif de vLLM est clair : maximiser le débit (nombre de requêtes traitées par unité de temps) et minimiser la latence (temps de réponse par requête), tout en optimisant l'utilisation des ressources GPU.

Au cœur de cette performance se trouvent deux innovations majeures :

• PagedAttention : Une technique novatrice de gestion du cache KV qui s'inspire de la mémoire virtuelle des systèmes d'exploitation. Elle permet une allocation mémoire plus efficace et élimine la fragmentation.
• Batching Continu (Continuous Batching) : Une stratégie d'ordonnancement des requêtes qui maintient le GPU occupé en permanence, en traitant les requêtes dès leur arrivée et en les regroupant dynamiquement.

En combinant ces deux approches, vLLM parvient à des gains de performance spectaculaires par rapport aux solutions d'inférence LLM traditionnelles. Explorons chacune de ces innovations en détail.

PagedAttention : La Gestion Intelligente du Cache KV

Pour comprendre PagedAttention, imaginons la mémoire GPU comme un vaste espace de stockage. Dans les approches conventionnelles, lorsqu'une requête LLM est traitée, son cache KV est alloué comme un bloc contigu de mémoire. Si la séquence s'allonge, il faut potentiellement réallouer un bloc plus grand, copier les données, puis libérer l'ancien bloc. C'est inefficace et cela conduit à la fragmentation, où de petits morceaux de mémoire inutilisés sont dispersés, rendant difficile l'allocation de grands blocs contigus pour de nouvelles requêtes.

PagedAttention résout ce problème en s'inspirant de la gestion de la mémoire paginée des systèmes d'exploitation. Au lieu d'allouer le cache KV en un seul bloc contigu, PagedAttention le divise en "blocs" logiques de taille fixe. Ces blocs logiques peuvent ensuite être mappés à des blocs physiques de mémoire GPU qui ne sont pas nécessairement contigus. Un tableau de blocs (similaire à une table de pages) maintient la correspondance entre les blocs logiques d'une séquence et leurs emplacements physiques dans la mémoire GPU.

Les avantages de PagedAttention sont multiples et profonds :

• Élimination de la fragmentation : Puisque les blocs physiques n'ont pas besoin d'être contigus pour une même séquence, la mémoire GPU est utilisée de manière beaucoup plus dense. Les petits espaces libres peuvent être utilisés, réduisant le gaspillage.
• Allocation dynamique et flexible : Lorsque la séquence d'une requête s'allonge, de nouveaux blocs peuvent être alloués et ajoutés à la table de blocs, sans nécessiter de coûteuses réallocations ou copies de données massives.
• Partage de cache KV : PagedAttention permet de partager des blocs de cache KV entre différentes requêtes ou différentes branches d'une même requête (par exemple, dans le cas de la recherche par faisceau ou "beam search"). Si deux requêtes partagent un préfixe commun, elles peuvent réutiliser les mêmes blocs de cache KV pour ce préfixe, réduisant ainsi la consommation mémoire et les calculs redondants. C'est particulièrement bénéfique dans les scénarios multi-utilisateurs où de nombreuses requêtes peuvent commencer par des invites similaires.
• Gestion efficace des requêtes de longue durée : Les applications nécessitant des conversations étendues avec un LLM, où le contexte doit être maintenu sur de nombreux tours, bénéficient énormément de cette gestion optimisée du cache KV.

En somme, PagedAttention transforme la gestion du cache KV d'une contrainte majeure en un atout flexible et efficace, libérant ainsi des ressources GPU cruciales pour les calculs réels.

Le Batching Continu : Un Flux de Travail Ininterrompu

Le second pilier de vLLM est le batching continu, une technique qui s'attaque à l'inefficacité des méthodes de batching traditionnelles. Historiquement, pour améliorer l'utilisation du GPU, les requêtes étaient regroupées en "batches" (lots) statiques. Le GPU attendait qu'un nombre prédéfini de requêtes soit accumulé avant de commencer le traitement. Une fois le lot terminé, le GPU attendait le lot suivant. Cette approche, bien que meilleure que le traitement requête par requête, présentait plusieurs inconvénients :

• Latence élevée : Les requêtes devaient attendre que le lot soit complet, même si elles étaient prêtes à être traitées.
• Sous-utilisation du GPU : Le GPU restait inactif entre les lots, ainsi que lorsque les requêtes au sein d'un lot avaient des longueurs de séquence différentes (nécessitant du "padding" pour égaliser les longueurs, gaspillant des calculs).
• Rigidité : La taille du lot devait être choisie à l'avance, ce qui était un compromis entre latence et débit, difficile à optimiser pour des charges de travail variables.

Le batching continu de vLLM adopte une approche radicalement différente. Au lieu d'attendre des lots statiques, vLLM traite les requêtes dès qu'elles arrivent. Il maintient une file d'attente de requêtes et, à chaque étape de génération de jetons, il tente d'ajouter autant de nouvelles requêtes que possible au lot en cours de traitement, tout en gérant les requêtes existantes.

Voici comment cela fonctionne et pourquoi c'est si efficace :

• Traitement dynamique : Le GPU ne reste jamais inactif. Dès qu'une requête est prête, elle est ajoutée au lot. Si d'autres requêtes sont