Comment la désagrégation optimise l’infrastructure des LLM

Les architectures désagrégées optimisent les différents besoins de calcul de l’inférence LLM.

Nous avons atteint un point où grands modèles de langage (LLM) alimentent des produits réels, l’assistance à la clientèle, les systèmes de recherche, les moteurs de contenu. Mais voici le problème : la plupart des infrastructures actuelles, en particulier les infrastructures monolithiques traditionnelles, ne savent pas comment servir ces modèles de manière efficace. Elle est dépassée.

Les LLM fonctionnent en deux étapes principales. Tout d’abord, le modèle prend en compte vos données et les traite en une seule fois. C’est la phase de « pré-remplissage ». Elle exige une puissance de calcul brute et fonctionne bien sur les GPU dotés d’une forte performance tensorielle, comme le NVIDIA H100. Vient ensuite la phase de « décodage », au cours de laquelle le modèle génère un jeton à la fois. Cette étape n’est pas un goulot d’étranglement pour le calcul, elle est liée à la mémoire. Des tas de clés et de valeurs flottent dans le cache, et leur accès est étonnamment inefficace. Le décodage n’a pas besoin de force brute ; il a besoin d’une bande passante mémoire intelligente.

Or, essayer de réaliser ces deux phases avec le même matériel revient à monter des pneus inadaptés sur une voiture à grande vitesse. Les performances sont insuffisantes sur les deux fronts. Le pré-remplissage consomme du calcul. Le décodage consomme de la bande passante mémoire. En associant les deux sur le mauvais GPU ? Vous gaspillez de l’énergie, vous dégradez les performances et vous augmentez les coûts.

Le matériel d’accélération actuel reflète ce compromis. Le H100 dispose d’une bande passante mémoire de 3,35 To/s et multiplie par trois la vitesse de calcul de l’A100, ce qui lui permet d’exceller dans le pré-remplissage. Mais lorsqu’il s’agit de décoder, l’A100 est plus efficace. Cela est dû à des hiérarchies de mémoire différentes.

C’est la raison pour laquelle la désagrégation fonctionne. Lorsque vous séparez le travail lié au calcul de celui lié à la mémoire, vous pouvez associer le bon GPU au bon travail. Vous ne forcez plus un seul système à faire ce qu’il ne sait pas faire. Au lieu de cela, vous optimisez chaque ressource de manière ciblée.

Dans le monde réel, les phases de décodage sont généralement exécutées à 20-40% d’utilisation du GPU, tandis que le pré-remplissage atteint 90-95%. L’efficacité par opération dans le décodage est également 3 à 4 fois moins bonne. Ainsi, que vous déployiez à grande échelle ou que vous optimisiez le coût par utilisateur, les architectures LLM désagrégées sont la voie à suivre, plus rapide, moins chère et plus efficace.

Des outils conçus à cet effet, tels que vLLM, SGLang et DistServe, démontrent l’efficacité de l’inférence désagrégée.

On ne remédie pas à l’inefficacité d’une infrastructure en se contentant de souhaiter qu’elle disparaisse. Vous avez besoin d’outils spécialement conçus à cet effet. C’est là que des cadres tels que vLLM, SGLang et DistServe entrent en jeu. Ils n’imposent pas de solutions génériques à des problèmes très spécifiques. Ils sont conçus pour la précision.

vLLM a ouvert la voie lors de son lancement à la mi-2023. Il a introduit des fonctionnalités telles que PagedAttention, qui gère des caches de valeurs clés massifs avec un minimum de surcharge, et Continuous Batching, qui maintient vos GPU alimentés en travail. Dans les tests de référence effectués avec Llama 8B, le débit a été multiplié par 2,7 et la latence de sortie a été réduite de 5 fois. Il ne s’agit pas d’un simple réglage. Il s’agit d’une refonte du système.

SGLang est allé plus loin. Il a ajouté RadixAttention et la génération structurée, ce qui lui a permis de battre les outils de base de 6,4 fois et de surpasser ses concurrents de 3,1 fois sur le Llama-70B, un modèle plus lourd qui pose de plus grands défis en termes de débit. Il s’agit là d’une efficacité de niveau industriel.

DistServe s’est appuyé sur des bases académiques solides. Il ne s’est pas contenté de séparer les phases de calcul et de mémoire, il a optimisé le placement des GPU, le déplacement du cache et la gestion de la latence. Le résultat ? Un système capable de répondre à 7,4 fois plus de demandes tout en réduisant la variance de la latence jusqu’à 20 fois. Et, ce qui est essentiel, il a atteint les objectifs de latence pour plus de 90 % des demandes. Un impact réel sur la production, et non une simple théorie sur tableau blanc.

Ces cadres ne sont pas des mises à niveau optionnelles. Ce sont les outils que les entreprises utilisent aujourd’hui pour réduire les coûts, augmenter le débit et obtenir des performances prévisibles des systèmes d’IA.

C’est là l’avantage réel. Vous n’avez pas besoin de plus de GPU, mais d’une logique de service plus intelligente. Avec le bon cadre, vous ne vous contentez pas de suivre, vous prenez de l’avance.

La désagrégation des services permet d’obtenir des avantages substantiels en termes de coûts et d’efficacité énergétique.

Si vous investissez dans une infrastructure d’IA, les coûts et la consommation d’énergie ne sont pas négociables. À grande échelle, les inefficacités se multiplient. L’approche monolithique traditionnelle de l’inférence LLM est pleine de ces inefficacités. Elle surprovisionne le calcul, sous-utilise la puissance GPU disponible et peine à adapter le bon matériel à la tâche spécifique. Résultat ? Vous dépensez plus pour un résultat moindre.

Le service désagrégé résout ce problème. Au lieu d’utiliser des GPU haut de gamme à chaque phase de l’inférence, quelle que soit la charge de travail, il aligne les ressources sur la précision. Les tâches à forte intensité de calcul sont dirigées vers du matériel à haut débit, tel que le H100 de NVIDIA, tandis que les tâches centrées sur la mémoire sont confiées à du matériel tel que l’A100, conçu pour la bande passante et l’efficacité énergétique.

Dans les systèmes traditionnels, il est courant de voir des GPU coûteux sous-utilisés pendant les charges de travail à forte intensité de décodage. Les tâches de pré-remplissage peuvent nécessiter un débit de calcul énorme, mais l’utilisation du même GPU pour les deux signifie que des parties de votre pile sont inutilisées la plupart du temps. La désagrégation corrige ce décalage et améliore l’utilisation des GPU de 40 à 60 % d’une phase à l’autre. Cette utilisation alignée permet également de réduire les coûts d’infrastructure de 15 à 40 %.

L’efficacité énergétique est un facteur multiplicateur. La compression des modèles et leur allocation intelligente au sein de clusters désagrégés ont permis de réduire jusqu’à 50 % la consommation d’énergie. Dans les environnements de production réels, certains déploiements font état d’une réduction des coûts allant jusqu’à 4 fois grâce à l’amélioration du dimensionnement des serveurs. Il ne s’agit pas de théorie, ces économies se matérialisent dès que les charges de travail sont réparties correctement, que les ressources sont profilées et que l’utilisation des clusters est optimisée en conséquence.

Pour les entreprises qui développent des charges de travail LLM, que ce soit en interne pour des produits ou en externe pour des clients, ces gains d’efficacité se traduisent par des marges plus claires, des frais généraux réduits et une diminution significative du gaspillage dans les budgets de matériel et d’énergie. Lorsqu’elle est bien faite, la désagrégation n’est pas seulement plus rapide, elle est aussi plus légère, plus écologique et plus prévisible.

La mise en œuvre de la désagrégation nécessite une compréhension détaillée de l’infrastructure et des stratégies de déploiement progressif.

On ne change pas d’infrastructure du jour au lendemain. Les charges de travail LLM sont dynamiques et imprévisibles. C’est pourquoi l’adoption d’un service désagrégé nécessite une bonne compréhension de votre architecture, de vos goulets d’étranglement et de vos schémas de ressources.

Le processus commence par le profilage de la charge de travail. Vous décomposez votre utilisation actuelle et classez les applications : celles qui sont fortement axées sur le préremplissage et celles qui sollicitent la mémoire lors de la phase de décodage. Le résumé et le traitement de documents ont tendance à s’appuyer sur le préremplissage, car ils consomment beaucoup de calculs en amont. Les agents interactifs et les chatbots exigent souvent une génération de jetons rapide et optimale en termes de mémoire, de sorte que le décodage devient le goulot d’étranglement.

Une fois ce schéma établi, vous alignez les nœuds sur les tâches. Les tâches axées sur le calcul vont sur des clusters offrant un maximum de FLOP et des performances de mise en lots efficaces. Les charges de travail de décodage gourmandes en bande passante vont sur des clusters optimisés pour la charge mémoire, l’accès au cache et la latence. Il ne s’agit pas d’ajouter du matériel au problème, mais d’en utiliser moins, de manière plus intelligente.

Le choix du cadre de travail est également important. Si vous construisez des plates-formes à usage général, vLLM vous offre une grande flexibilité. Pour les sorties structurées ou les cas d’utilisation multimodaux, SGLang offre un retour sur investissement. À l’échelle de l’entreprise, TensorRT-LLM possède des crochets d’intégration plus profonds, ce qui le rend précieux si vous avez besoin d’outils soutenus par le fournisseur et d’un réglage précis.

Le déploiement doit être progressif. Laissez les systèmes existants fonctionner en parallèle tout en acheminant le trafic contrôlé vers la nouvelle architecture. Effectuez des analyses comparatives sur tous les aspects : latence, débit, utilisation du GPU. Commencez par les fonctions non critiques, validez de manière cohérente et n’augmentez l’échelle que lorsque la fiabilité est évidente. Il ne s’agit pas seulement de déployer une meilleure architecture, il s’agit de le faire sans impact sur les utilisateurs et avec un minimum de friction pour les équipes opérationnelles.

Dans des environnements réels, comme une configuration à 12 nœuds avec 8× H100 GPU par nœud exécutant SGLang, les organisations ont atteint des niveaux de débit de 52,3k tokens d’entrée/sec et 22,3k tokens de sortie/sec. De tels résultats ne sont pas accidentels, ils sont le fruit de la précision de l’infrastructure, d’un profilage réel et d’une stratégie de déploiement intentionnelle.

Les parties prenantes de la suite devraient considérer l’inférence désagrégée non pas comme un remplacement d’infrastructure, mais comme une optimisation, ciblée, mesurée et hautement efficace, conçue pour rendre l’infrastructure d’IA plus intelligente.

Les architectures désagrégées renforcent la fiabilité et la sécurité grâce aux microservices

Lors du déploiement de systèmes d’intelligence artificielle à grande échelle, la fiabilité et la sécurité sont fondamentales. Le fait de tout centraliser sur une infrastructure monolithique concentre les risques. Si une partie tombe en panne, c’est tout le système qui peut s’écrouler. Si une partie est vulnérable, tout le reste est exposé.

Les architectures désagrégées changent cela en séparant le flux de travail d’inférence en microservices isolés. Le pré-remplissage et le décodage ne partagent plus les mêmes ressources physiques ou logiques. Chaque tâche est gérée par son propre cluster spécialisé. Cette séparation à elle seule supprime de nombreuses dépendances qui fragilisent les systèmes. Si le décodage échoue, le préremplissage continue. Si un nœud tombe, les autres restent en bonne santé. Cela réduit considérablement le risque de défaillance en cascade.

L’avantage s’étend à la sécurité. Les systèmes désagrégés s’appuient sur des communications entre clusters, qui doivent être sécurisées. Les implémentations modernes utilisent des cadres de maillage de services et le cryptage entre les services pour garantir l’isolation et la protection des données. Cela signifie une surface d’attaque réduite et un meilleur contrôle de la manière dont les entrées et sorties sensibles se déplacent dans le système.

La gestion des états est essentielle dans cette configuration. Les plateformes de mise en cache distribuées, telles que Redis ou Memcached, sont utilisées pour coordonner les états des jetons et des contextes dans les grappes de calcul. Les microservices sans état facilitent la reprise et la tolérance aux pannes. Si un service tombe en panne au milieu d’une tâche, il n’a pas besoin de tout rejouer, un autre cluster peut intervenir rapidement avec un minimum d’interruption.

Pour les dirigeants qui gèrent des systèmes en contact avec la clientèle ou des outils internes qui ne peuvent pas se permettre de temps d’arrêt, ce modèle de fiabilité réduit l’exposition. Il permet une reprise plus rapide, des performances régulières et la certitude que des problèmes isolés ne se transformeront pas en pannes de système à part entière. Ces modèles sont également plus faciles à adapter et à faire évoluer, car les composants sont faiblement couplés et peuvent être déployés indépendamment.

Dans les environnements où les services d’IA sont liés à des accords de niveau de service et à des expériences utilisateur en temps réel, cette architecture n’est pas seulement robuste, elle est conçue pour répondre aux exigences opérationnelles de l’IA de niveau production à l’échelle.

Les architectures désagrégées s’alignent sur les tendances futures de l’évolution matérielle et logicielle de l’IA

Les écosystèmes matériels et logiciels qui soutiennent l’IA ne sont pas immobiles. L’infrastructure spécialisée est désormais la direction à suivre, et les architectures désagrégées correspondent à la direction que prend l’industrie, et non à celle qu’elle a prise.

En ce qui concerne le matériel, nous constatons une évolution vers l’optimisation au niveau des composants. Les processeurs à base de chiplets facilitent la séparation des fonctions de calcul et de mémoire avec une plus grande flexibilité. L’informatique proche de la mémoire réduit la latence en diminuant la distance à parcourir par les données. Ces deux tendances permettent un contrôle plus fin de ce qui s’exécute et de l’endroit où cela s’exécute. Cela rend l’inférence désagrégée encore plus efficace, car les futurs accélérateurs sont conçus spécifiquement pour gérer l’orchestration des charges de travail distribuées.

Les interconnexions à large bande passante telles que NVLink et PCIe 5.0 continuent de réduire les goulets d’étranglement en matière de communication entre les GPU. Ces améliorations sont cruciales pour des transferts rapides de cache clé/valeur pendant les étapes de décodage, en particulier lorsque le pré-remplissage et le décodage se font sur des appareils différents. Plus la latence de communication est faible, plus votre système de service est performant pour l’inférence de bout en bout.

Du côté des logiciels, les cadres évoluent dans le même sens. La prise en charge des modèles multimodaux est désormais intégrée dans les cadres d’inférence à haute performance. Ils ajoutent le routage dynamique de la charge de travail, la normalisation des API et une planification plus avancée des ressources qui réagit en temps réel aux performances des clusters. Des écosystèmes tels que vLLM et SGLang sont à la pointe de cette vague.

L’alignement industriel est également en cours. Nous observons des mesures normalisées, des API communes et des outils conçus pour prendre en charge la désagrégation portable et prête pour la production. Ces éléments réduisent le temps d’intégration et les obstacles à l’adoption, même entre différents fournisseurs de cloud et déploiements sur site.

Les chefs d’entreprise qui se projettent dans trois à cinq ans devraient en tenir compte dans la planification de l’infrastructure. Les systèmes qui évolueront efficacement, maintiendront les coûts à un bas niveau et fonctionneront de manière fiable seront conçus autour de la désagrégation. Ils fonctionneront mieux avec les microprocesseurs de nouvelle génération, s’intégreront plus rapidement aux logiciels modernes et permettront aux équipes d’expérimenter et d’innover plus vite.

Principaux enseignements pour les décideurs

• Les architectures désagrégées améliorent les performances et l’efficacité du LLM : Les dirigeants devraient passer d’une infrastructure monolithique à des configurations désagrégées afin d’aligner les charges de travail de calcul et de mémoire avec le matériel adéquat, en augmentant l’utilisation du GPU et en réduisant le gaspillage d’énergie.
• Des cadres spécialisés prouvent que le modèle fonctionne : Des outils tels que vLLM, SGLang et DistServe ont déjà permis de multiplier par 7 les gains de performance et de réduire la latence, ce qui indique que l’approche est opérationnelle et prête à être déployée à l’échelle de l’entreprise.
• La réduction des coûts et de la consommation d’énergie est mesurable : Le passage à des systèmes désagrégés peut réduire les coûts d’infrastructure de 15 à 40 % et la consommation d’énergie jusqu’à 50 %, ce qui en fait une mesure à fort retour sur investissement pour les directeurs financiers et les responsables de l’infrastructure.
• La stratégie de mise en œuvre doit être intentionnelle : Les dirigeants doivent déployer la désagrégation par phases, commencer par établir le profil de la charge de travail, segmenter le matériel en fonction des besoins des tâches et migrer progressivement le trafic de production pour maintenir la continuité du service.
• L’architecture microservices améliore la résilience et la sécurité : Les systèmes désagrégés isolent les risques, simplifient la reprise et sécurisent la communication entre les clusters. Les dirigeants devraient considérer cette architecture comme un élément essentiel de la protection future de l’infrastructure de l’IA.
• L’infrastructure s’aligne sur la conception désagrégée par défaut : l ‘innovation matérielle et logicielle se dirige vers des systèmes modulaires et adaptés à la charge de travail. En adoptant la désagrégation dès maintenant, les équipes sont en mesure d’effectuer des transitions en douceur vers de nouvelles architectures d’intelligence artificielle et d’accélérer le délai d’obtention de la valeur.