Prism: Cost-Efficient Multi-LLM Serving via GPU Memory Ballooning

Prism est un cadre de co-service de LLM centré sur la mémoire qui utilise une nouvelle technique de gonflement de mémoire appelée kvcached pour réclamer et réallouer dynamiquement la mémoire GPU entre plusieurs modèles, unifiant ainsi le partage spatial et temporel afin d'améliorer l'efficience des coûts et le respect des SLO dans les environnements de production.

L'essentiel

Imaginez que vous dirigez un hôtel immense avec des milliers de chambres (des GPU) et des milliers de clients différents (des modèles d'IA). Parmi eux, il y a des célébrités qui veulent une chambre 24h/24 et des touristes qui ne passent que pour un séjour de 10 minutes une fois par jour.

Le problème est que votre hôtel coûte cher à faire fonctionner. Si vous donnez à chaque touriste sa propre chambre privée au cas où il se présenterait, vous vous retrouvez avec 90 % de votre hôtel vide et gaspillé. Mais si vous essayez de serrer tout le monde dans une seule chambre, c'est le chaos, et les célébrités s'énervent parce qu'elles doivent attendre.

Prism est un nouveau gestionnaire d'hôtel intelligent qui résout ce problème en utilisant une astuce appelée « Memory Ballooning » (le gonflement de la mémoire).

Voici comment cela fonctionne, décomposé en concepts simples :

1. Le Problème : Le piège de la « Chambre Statique »

Dans l'ancienne façon de gérer l'IA, si un modèle (un client) se voyait assigner une chambre, cette chambre était la sienne pour toujours, même s'il dormait (inactif).

• Le Partage d'Espace (L'ancienne méthode) : Vous essayez de mettre plusieurs clients dans une même chambre. Cela fonctionne très bien si tous sont réveillés et discutent. Mais si un client part pour une semaine, sa moitié de chambre reste vide, et l'autre client ne peut pas l'utiliser.
• Le Partage de Temps (L'autre ancienne méthode) : Vous mettez un client dehors pour en laisser entrer un autre. Cela fonctionne si les clients n'arrivent qu'à des moments différents. Mais si deux clients arrivent exactement à la même seconde, vous devez constamment les mettre dehors et les faire rentrer. Ce processus de « mise à la porte » est lent et fait attendre tout le monde (latence), ce qui leur fait manquer leurs échéances.

Le trafic réel de l'IA est désordonné. Parfois, un groupe de modèles devient très actif en même temps, et parfois, ils deviennent tous silencieux. Aucune des anciennes stratégies ne pouvait gérer ces changements.

2. La Solution : L'astuce du « Gonflement »

Prism introduit un nouveau gestionnaire appelé kvcached (le pilote de ballon). Imaginez la mémoire du GPU non pas comme un ensemble de chambres fixes, mais comme des ballons gonflables.

• Le Ballon Élastique : Lorsqu'un modèle est occupé et a besoin de plus d'espace pour réfléchir, le gestionnaire gonfle son ballon, en volant l'air vide des autres modèles qui dorment actuellement.
• Dégonfler pour les autres : Lorsqu qu'un modèle s'endort, son ballon rétrécit, libérant cet espace pour qu'un nouveau modèle, qui vient de se réveiller, puisse instantanément gonfler son propre ballon.
• Pas de changement de mobilier : Le meilleur dans tout ça ? Les modèles ne savent même pas ce qui se passe. Ils voient simplement une chambre qui s'agrandit et se contracte magiquement. Le gestionnaire s'occupe de tout le travail difficile en coulisses.

3. La Stratégie en Deux Étapes

Prism utilise deux règles intelligentes pour décider qui reçoit l'air :

• Règle 1 : Le Planificateur Global (Le Directeur de l'Hôtel) : Il regarde l'ensemble de l'hôtel. Il demande : « Quel groupe de clients est actuellement actif ? ». Il place ensuite ces clients actifs sur le même étage (GPU) afin qu'ils puissent partager l'espace facilement. Si un client dort, il le déplace dans un placard de rangement (CPU) pour libérer de l'espace. Il réorganise constamment l'hôtel pour s'assurer qu'aucun étage ne soit surchargé pendant qu'un autre est vide.
• Règle 2 : Le Planificateur Local (Le Concierge) : Il regarde les demandes spécifiques qui arrivent en ce moment même. Si deux clients se battent pour la dernière parcelle d'espace, le concierge vérifie qui a l'échéance la plus urgente. Il laisse passer l'invité urgent en premier et dit au moins urgent d'attendre un moment. Cela garantit que les tâches les plus importantes sont accomplies à temps.

4. Les Résultats

L'article a testé Prism sur des données réelles provenant de grands fournisseurs d'IA et a constaté que :

• Un service plus rapide : Il respecte ses promesses de vitesse (SLO) jusqu'à 3,3 fois mieux que les méthodes précédentes.
• Des coûts moins élevés : Pour obtenir le même niveau de performance, Prism a eu besoin de la moitié du nombre de GPU (ou peut gérer deux fois plus de requêtes avec le même matériel).
• Preuve en conditions réelles : Il est déjà déployé dans des environnements de production avec plus de 10 000 GPU, aidant les entreprises à générer des revenus nettement plus élevés par GPU en transformant le temps « inactif » gaspillé en travail facturable.

Résumé

Prism est comme un gestionnaire d'hôtel intelligent et élastique. Au lieu de bloquer les clients dans des chambres fixes ou de les mettre dehors constamment, il utilise des ballons gonflables pour partager l'espace de manière dynamique. Il agrandit l'espace pour les modèles occupés et réduit l'espace pour ceux qui dorment, garantissant que l'hôtel est toujours plein, efficace et rapide, sans que personne n'attende dans la file.

Résumé technique

Résumé Technique : Prism

Énoncé du Problème

Les fournisseurs d'inférence hébergeant des milliers de grands modèles de langage (LLM) font face à un défi d'efficacité critique : maintenir la disponibilité de modèles essentiels à faible volume tout en minimisant les coûts à mesure que les prix des tokens diminuent. L'analyse des traces de production révèle que les charges de travail réelles présentent un modèle de rafale par groupes dynamiques (bursty-group pattern), où des sous-ensembles spécifiques de modèles deviennent actifs ensemble et évoluent au fil du temps, sous l'impulsion de systèmes d'IA composés et de pipelines d'agents.

Les stratégies de service existantes ne parviennent pas à s'adapter à cette variabilité :

• Partage d'Espace (Colocalisation) : La colocalisation de plusieurs modèles sur un GPU pour utiliser la mémoire inutilisée fonctionne pour les modèles à faible trafic continu, mais crée une fragmentation sévère de la mémoire lors de longues périodes d'inactivité. Cela empêche les modèles actifs de monter en charge pour répondre aux exigences des objectifs de niveau de service (SLO), car la mémoire est statiquement verrouillée par les modèles inactifs.
• Partage de Temps (Échange/Swapping) : L'échange de modèles dans et hors de la mémoire GPU gère bien le trafic sporadique, mais souffre d'une latence élevée (plusieurs secondes) lors de fluctuations rapides de la charge de travail. Cela provoque un « battement » (thrashing) lorsque plusieurs modèles subissent des requêtes entrelacées, entraînant des violations de SLO.

Le défi central est l'absence d'un mécanisme fondé sur des principes pour unifier le partage spatial et temporel. Les systèmes actuels imposent un compromis entre l'adhérence aux SLO et l'efficacité des ressources, incapables de passer de manière fluide entre les stratégies à mesure que les modèles de charge passent de rafales volatiles à une activité entrelacée.

Méthodologie

Prism est un framework de partage de GPU centré sur la mémoire, conçu pour unifier le partage spatial et temporel grâce à une allocation de mémoire élastique. Son architecture se compose de trois composants principaux :

1. Gonflement de la Mémoire GPU (Le pilote kvcached)

Prism introduit un pilote de gonflement, kvcached, qui se situe entre les moteurs d'inférence (ex: SGLang) et la mémoire physique du GPU. Ce pilote implémente le gonflement de la mémoire (memory ballooning) pour récupérer et réallouer la mémoire entre les modèles sans interrompre l'exécution.

• Découplage Virtuel/Physique : Les moteurs réservent un large espace d'adressage virtuel, mais la mémoire physique est allouée et mappée à la demande. Cela permet au système de réduire ou d'étendre l'empreinte physique d'un modèle (poids et KV cache) au moment de l'exécution.
• Gestion Unifiée : kvcached traite les poids du modèle et le KV cache comme un pool unifié de pages physiques. Il supporte diverses architectures de modèles en mappant les blocs de tokens à des pages virtuelles et en les séparant physiquement pour éviter les conflits de forme.
• Optimisations : Pour minimiser les surcharges, il utilise des pages de mémoire de 2 Mo, priorise les pages partiellement remplies et emploie un thread de pré-allocation pour la préparation asynchrone des pages. Il expose une abstraction de tenseur élastique (eTensor) compatible avec les kernels d'attention existants et les graphes CUDA, ne nécessitant aucun changement de code dans les moteurs de service.
• Chargement Rapide : Pour atténuer la latence de démarrage à froid (cold-start), Prism découple les cycles de vie des moteurs de ceux des modèles en utilisant un pool de moteurs réutilisables et emploie un chargement de poids parallèle entre les GPU via NVLink pour saturer la bande passante de l'interconnexion.

2. Plan de Contrôle Centré sur la Mémoire

Prism emploie un ordonnanceur hiérarchique pour gérer l'élasticité fournie par kvcached :

• Placement de Modèles Sensible à la Charge (Global) : Un ordonnanceur global place les modèles sur les GPU pour maximiser la réserve de mémoire pour le gonflement. Il utilise une heuristique de Ratio de Pression KV (KVPR), qui quantifie la contention de la mémoire basée sur les taux de tokens pondérés par les SLO. L'algorithme place de manière gloutonne les modèles à forte demande sur les GPU ayant la pression existante la plus faible, garantissant que les modèles actifs ont de la place pour étendre leurs KV caches lors des rafales.
• Arbitrage de Requêtes Sensible à l'Éventail (Local) : Un ordonnanceur local au GPU gère les requêtes concurrentes des modèles colocalisés. Au lieu d'une isolation statique, il utilise une file d'attente de requêtes partagée et applique l'algorithme de Moore-Hodgson pour minimiser les manquements aux échéances. Il priorise les requêtes en fonction de leur éventail de temps (time slack) (la différence entre l'échéance et le temps d'exécution requis), garantissant que les requêtes urgentes à faible latence sont servies avant les requêtes plus longues, maximisant ainsi l'atteinte du SLO de TTFT (Temps de Premier Token).

3. Intégration Système

Prism est implémenté comme une bibliothèque étendant SGLang, utilisant les API de gestion de la mémoire virtuelle CUDA (VMM). Il fonctionne comme un processus de contrôle distinct qui coordonne les évictions, les activations et les migrations de modèles basées sur les métriques d'exécution.

Contributions Clés

1. Mécanisme de Partage Unifié : Prism est le premier système à unifier le partage spatial et temporel sous un seul schéma en traitant la mémoire GPU comme une ressource élastique. Il permet au système d'agir simultanément comme un système de partage de temps (éviction des modèles inactifs) et un système de partage d'espace (co-service des rafales actives).
2. Pilote de Gonflement kvcached : Un pilote open-source qui permet une redistribution de mémoire flexible et à grain fin (2 Mo) entre des LLM hétérogènes avec une surcharge de l'ordre de la milliseconde et sans modification du kernel.
3. Déploiement à l'Échelle de la Production : Le système a été déployé dans des environnements de production sur plus de 10 000 GPU et est activement maintenu.
4. Évaluation Complète : L'article fournit une analyse rigoureuse de traces de production provenant de fournisseurs majeurs (Hyperbolic, Novita AI) et de plateformes d'évaluation (Chatbot Arena), couvrant 58 modèles hétérogènes sur des périodes allant de 11 jours à 16 mois.

Résultats

Évalué sur un cluster comprenant jusqu'à 32 GPU NVIDIA H100 en utilisant des traces réelles :

• Atteinte des SLO : Prism atteint jusqu'à 3,3× une meilleure atteinte du SLO de TTFT et 2× une meilleure atteinte du SLO de TPOT par rapport aux bases de référence de pointe (incluant MuxServe++, QLM et ServerlessLLM) pour un nombre identique de GPU.
• Efficacité des Coûts : Pour atteindre le même niveau d'atteinte des SLO, Prism réduit le nombre de GPU requis par 2× (ex: atteindre 99 % de SLO TTFT avec 16 GPU contre 32+ pour les bases de référence) ou gère 3,5× plus de requêtes avec le même matériel.
• Impact de Production : Dans des déploiements en mode ombre (shadow deployments) chez deux entreprises, Prism a augmenté le débit par GPU de 3,89× (Entreprise A) et le revenu par GPU de 2,86× (Entreprise B) en convertissant la capacité inactive en tokens facturables sans violer les SLO.
• Latence : La latence d'activation des modèles est réduite à moins de 1,5 seconde, même pour des modèles de 70B, et la surcharge de migration est négligeable (dizaines de millisecondes) lorsqu'on utilise NVLink.

Signification

L'article soutient que le goulot d'étranglement fondamental dans le service multi-LLM est la contention de la mémoire GPU, et non le calcul. En déplaçant la perspective d'un partitionnement statique ou d'un découpage temporel rigide vers une gestion de la mémoire élastique, Prism résout le conflit entre le besoin de réactivité immédiate (nécessitant la colocalisation) et le besoin d'efficacité des ressources (nécessitant l'éviction). Ce travail démontre qu'une vision centrée sur la mémoire peut s'adapter de manière fluide à la nature par « rafales de groupes » des charges de travail d'IA modernes, permettant aux fournisseurs d'héberger des milliers de modèles de manière rentable tout en respectant strictement les SLO de latence. L'ouverture du code de kvcached et son adoption dans des environnements de production à grande échelle valident la viabilité pratique de cette approche.