Tech • IA • Robotique
Les infrastructures de l’IA expliquées (GPU, vLLM et LLM-D)
8/10INTRO
L’infrastructure IA est devenue une priorité majeure d’ingénierie, alors que les hyperscalers injectent plus de 700 milliards de dollars dans des systèmes de service de modèles, ce qui fait fortement croître la demande d’expertise en GPU, serveurs de modèles et orchestration basée sur Kubernetes.
POINTS CLÉS
La flambée des dépenses reconfigure la demande en infrastructure
Amazon, Google, Microsoft et Meta devraient dépenser plus de 700 milliards de dollars en infrastructure IA cette année, soit environ quatre fois leur niveau d’il y a quatre ans et près de 80 % de plus que l’an dernier. McKinsey prévoit qu’environ 7 000 milliards de dollars seront investis dans les centres de données d’ici 2030, faisant du déploiement du calcul, de la mémoire, du réseau et des opérations une priorité centrale du secteur.
Les modèles sont des structures logicielles plus des poids appris
Un modèle de langage est fondamentalement une structure de calcul fixe à laquelle s’ajoute un énorme ensemble de poids numériques appris. Dans les systèmes modernes, cette structure est généralement le transformer, tandis que les capacités du modèle proviennent des poids produits pendant l’entraînement. Ces poids sont stockés sous forme de fichiers allant d’environ 2 Go pour les petits modèles à 140 Go pour un modèle de 70 milliards de paramètres, les plus grands systèmes atteignant plusieurs centaines de gigaoctets.
Pourquoi les ordinateurs portables peinent et les GPU dominent
Exécuter un modèle exige des milliards de petites multiplications pouvant être effectuées en parallèle, ce qui rend les GPU bien mieux adaptés que les CPU. Un CPU peut fournir environ 10 000 milliards d’opérations par seconde, tandis qu’un GPU peut atteindre 1 000 000 milliards, soit environ 100 fois plus de débit de calcul. Le défi ne tient pas seulement au calcul, mais aussi à l’alimentation suffisamment rapide du processeur en poids du modèle.
La VRAM et la bande passante sont des contraintes décisives
Les GPU résolvent le problème d’alimentation des données grâce à la VRAM embarquée, proche des cœurs de calcul et offrant une bande passante en téraoctets par seconde, bien supérieure au chemin beaucoup plus lent de la mémoire système. Mais cette vitesse s’accompagne d’une capacité limitée. Une carte comme la Nvidia T4 dispose d’environ 16 Go de VRAM, tandis que des composants de centre de données comme les A100, H100, H200 et B200 offrent bien plus de calcul et de mémoire, jusqu’à 192 Go de VRAM et environ 8 To/s de bande passante sur la B200.
Le model serving transforme un script en service permanent
Des frameworks comme PyTorch chargent les poids du modèle sur les GPU, tandis que des couches de service comme vLLM les exposent via une API web compatible avec le format OpenAI API. Cela permet de remplacer un endpoint de modèle hébergé par un serveur exploité soi-même sans modifier le code client. L’inconvénient est le coût: chaque serveur conserve une copie complète du modèle en mémoire GPU, ce qui ralentit le démarrage et rend la réplication coûteuse.
La génération de tokens explique la latence
Les modèles de langage fonctionnent en tokens, et non en mots complets, et génèrent leur sortie un token à la fois. Cela crée deux phases de performance: le prefill, lorsque l’intégralité du prompt est traitée en une seule passe, puis le decode, lorsque la réponse est produite token par token. Les principales métriques de latence sont le TTFT ou time to first token, et le TPOT ou time per output token.
Le cache est essentiel pour la performance et le coût
Pendant le prefill, le modèle stocke dans le KV cache un travail intermédiaire réutilisable, évitant un recalcul complet pour chaque token généré. Une optimisation supplémentaire, le prefix caching, conserve le travail lié à des préfixes de prompt répétés, ce qui réduit à la fois la latence et le coût dans les systèmes de type chat et les charges d’assistants partagés. Certaines API commerciales facturent déjà les tokens d’entrée mis en cache à environ un dixième du prix des tokens non mis en cache.
Le batching augmente le débit, mais la mémoire fixe la limite
Servir efficacement plusieurs utilisateurs repose sur le batching, qui permet à une seule lecture du modèle de produire des tokens pour de nombreuses requêtes à la fois. Cela augmente fortement le débit total, mais chaque utilisateur a aussi besoin de KV cache en VRAM. En pratique, la mémoire GPU devient souvent le véritable goulet d’étranglement avant même le calcul brut, obligeant les opérateurs à mettre les utilisateurs en file d’attente ou à ajouter du matériel.
Les grands modèles doivent être répartis sur plusieurs GPU
Lorsqu’un modèle est trop volumineux pour une seule carte, les opérateurs utilisent le sharding sur plusieurs GPU. À l’intérieur d’une même machine, des liaisons rapides comme NVLink permettent des communications fréquentes et des découpages plus fins; entre machines, des réseaux plus lents favorisent un partitionnement plus grossier, couche par couche. Le résultat est un serveur logique unique réparti sur plusieurs GPU ou plusieurs machines.
L’équilibrage de charge traditionnel échoue pour les LLM
L’équilibrage standard en round-robin gaspille les performances, car il ignore où réside le cache de chaque utilisateur et suppose que les requêtes ont une taille similaire. En réalité, une requête peut être une question courte et une autre un travail de synthèse de 50 pages. Envoyer les messages de suivi vers le mauvais serveur force un recalcul coûteux et peut ralentir des dizaines d’utilisateurs actifs partageant ce GPU.
LLM-D vise à router les requêtes intelligemment
LLM-D, soutenu par Red Hat, Google, IBM et Nvidia, est conçu comme une couche de routage plus intelligente pour les flottes de serving de modèles. Il prend en compte l’état du cache, la mémoire libre et la profondeur des files d’attente avant de placer les requêtes. Un routage sensible au cache peut offrir environ 3 fois plus de débit et réduire la latence de première réponse d’environ moitié, tandis que la séparation du prefill et du decode sur différents pools de GPU peut augmenter la production jusqu’à 70 % de tokens par seconde en plus sur le même matériel.
Kubernetes devient le plan de contrôle
La couche d’orchestration de cette infrastructure est de plus en plus Kubernetes, déjà utilisé par environ 66 % des organisations hébergeant des charges d’inférence d’IA générative. Dans ce modèle, les serveurs d’inférence s’exécutent comme des pods, le routage se place derrière une passerelle et un ordonnanceur, et les grands modèles fragmentés peuvent être regroupés avec des constructions plus récentes comme LeaderWorkerSet. Le résultat est un modèle opérationnel familier pour les équipes plateforme, avec des comportements standards de redémarrage, placement et mise à l’échelle appliqués aux charges IA.
CONCLUSION
Le défi central de l’IA générative n’est plus seulement la qualité des modèles, mais aussi l’infrastructure nécessaire pour les exécuter rapidement, à moindre coût et à grande échelle. À mesure que les dépenses s’accélèrent, l’expertise en systèmes GPU, logiciels de serving et orchestration native Kubernetes devient une composante critique de la pile IA.
Explique-moi