GPU pour l’inférence LLM : mémoire, débit, coût

La plupart des erreurs de dimensionnement GPU pour l’inférence de grands modèles de langage surviennent avant même la commande du matériel. Une équipe choisit un modèle, trouve un GPU doté d’assez de mémoire pour le charger et considère que le travail est terminé.

Charger le modèle n’est que la première contrainte. La capacité d’inférence dépend de trois éléments combinés : la mémoire nécessaire aux poids, la mémoire du cache d’attention de chaque requête active, et le rythme auquel le GPU peut produire des tokens tout en respectant l’objectif de latence que vous avez promis.

Partir de la charge de travail, pas du GPU

Avant de comparer les accélérateurs, notez ce que le service doit faire.

• Modèle et précision. Nombre de paramètres, architecture (couches, têtes d’attention, têtes clé/valeur, dimension des têtes) et précision à laquelle vous acceptez de servir le modèle.
• Longueurs de contexte. Le nombre typique et le 95e centile de tokens d’entrée par requête, ainsi que la longueur de sortie typique et maximale.
• Forme du trafic. Les requêtes par seconde à l’heure la plus chargée, et non la moyenne quotidienne, ainsi que la raideur des pics.
• Objectifs de latence. Le temps jusqu’au premier token (combien de temps avant que l’utilisateur ne voie quelque chose) et le temps par token de sortie (la vitesse à laquelle le texte s’affiche ensuite).
• Isolation et localisation. La question de savoir si les prompts et les réponses peuvent quitter un environnement ou un pays donné, ce qui peut exclure la capacité partagée quel que soit le prix.

Le chat interactif, la recherche augmentée par récupération, la synthèse de documents et le scoring par lots hors ligne peuvent exécuter le même modèle avec des empreintes matérielles totalement différentes. Une tâche de synthèse avec 8 000 tokens d’entrée et une réponse de 200 tokens sollicite d’autres parties du système qu’un assistant conversationnel avec 1 000 tokens d’entrée et 600 tokens de sortie.

Mémoire, première partie : les poids du modèle

Multipliez le nombre de paramètres par le nombre d’octets par paramètre correspondant à la précision utilisée en production. Les règles empiriques courantes sont de 2 octets par paramètre en FP16 ou BF16, 1 octet en INT8 ou FP8 et environ 0,5 octet dans les formats 4 bits, plus une petite quantité pour les facteurs d’échelle de quantification.

• 8B paramètres. Environ 16 GB en FP16, 8 GB en INT8, 4 à 5 GB en INT4.
• 70B paramètres. Environ 140 GB en FP16, 70 GB en INT8, 35 à 40 GB en INT4.
• Classe 400B paramètres. Environ 800 GB en FP16, 400 GB en INT8, 200 à 230 GB en INT4, ce qui impose un nœud multi-GPU même après quantification.

Le contexte CUDA, les buffers d’activation, les buffers de communication du parallélisme tensoriel et la fragmentation occupent généralement plusieurs gigaoctets par GPU. Les moteurs de service comme vLLM permettent de définir la fraction de la mémoire GPU qu’ils peuvent réserver ; une valeur de planification de 85 à 90 % de la mémoire physique utilisable est un point de départ raisonnable.

Les poids en 8 bits sont largement servis en production avec une perte mesurable faible sur la plupart des tâches. Les poids en 4 bits divisent encore la mémoire par deux, mais peuvent dégrader plus nettement le raisonnement, le code et les réponses multilingues : évaluez-les donc sur vos propres prompts avant d’en faire la base de votre planification de capacité.

Mémoire, deuxième partie : le KV cache détermine la concurrence

Pendant la génération, chaque requête conserve les clés et les valeurs d’attention de chaque token qu’elle a vu. Ce KV cache croît avec la longueur du contexte et le nombre de requêtes simultanées, et sur un serveur chargé il occupe souvent plus de mémoire que les poids.

La taille par token se calcule ainsi : 2 (une clé et une valeur) multiplié par le nombre de couches, par le nombre de têtes clé/valeur, par la dimension des têtes et par le nombre d’octets par élément. Pour un modèle type de la classe 70B avec grouped-query attention (80 couches, 8 têtes clé/valeur, dimension de tête 128) en FP16, on obtient 2 x 80 x 8 x 128 x 2 octets, soit environ 320 KB par token.

À 320 KB par token, une requête qui conserve 4 000 tokens de contexte utilise environ 1,3 GB. Cinquante requêtes de ce type nécessitent environ 65 GB, soit presque la taille des poids INT8 eux-mêmes.

• Allocation par pages. Les moteurs qui allouent le cache par petits blocs (paged attention) ne réservent de la mémoire que pour les tokens existants : vous pouvez donc planifier sur le contexte moyen et non sur le contexte maximal, avec une marge pour les requêtes longues.
• Quantification du cache. Stocker le KV cache en FP8 réduit son empreinte d’environ moitié et double le nombre de séquences qui tiennent en mémoire, généralement au prix d’une perte de qualité modeste qu’il faut tester.
• Cache de préfixes. Lorsque de nombreuses requêtes partagent un long prompt système ou un même document, la réutilisation de ses clés et valeurs en cache économise à la fois de la mémoire et du calcul de prefill.
• Limites de contexte. Plafonner le contexte maximal par requête est souvent le levier de capacité le moins coûteux, car une poignée de requêtes très longues peut affamer toutes les autres.

Débit, latence et batching

L’inférence comporte deux phases dont les goulets d’étranglement diffèrent. Le prefill traite l’intégralité du prompt en une seule passe et est limité par la puissance de calcul ; une approximation utile est de 2 opérations en virgule flottante par paramètre et par token, si bien qu’un modèle de 70B nécessite environ 140 GFLOP pour chaque token d’entrée. Le décodage produit ensuite un token à la fois par requête et est limité par la bande passante mémoire, car chaque étape lit les poids et le KV cache de la requête dans la mémoire du GPU.

On obtient ainsi un plafond simple pour la vitesse d’un flux unique : la bande passante mémoire divisée par le nombre d’octets lus par token. Un modèle de 70 GB de poids INT8 répartis sur deux GPU disposant chacun d’environ 2 TB/s peut lire l’intégralité des poids au maximum environ 57 fois par seconde : une requête ne peut donc pas produire plus d’environ 57 tokens par seconde sur cette configuration, et en pratique ce sera moins.

C’est le batching qui rend l’inférence rentable. Le batching continu, désormais standard dans des moteurs comme vLLM et les piles basées sur Triton, intègre de nouvelles requêtes dans le lot en cours à chaque étape au lieu d’attendre la fin d’un lot. Le débit agrégé augmente fortement avec la taille du lot, jusqu’à ce que le KV cache soit plein ou que le calcul devienne la limite.

Le prix du batching est la latence. La planification de capacité est donc un arbitrage : choisissez le plus grand lot qui respecte encore vos objectifs de délai avant le premier token et de temps par token de sortie au 95e percentile, puis dimensionnez le parc à partir du débit mesuré à ce point, et non du débit maximal affiché dans un graphique de benchmark.

Estimer la concurrence à partir du trafic

La concurrence, c’est-à-dire le nombre de requêtes traitées simultanément, est ce qui consomme le KV cache et les places dans les lots. Vous pouvez l’estimer avec la loi de Little : la concurrence moyenne est égale au taux d’arrivée multiplié par le temps moyen que chaque requête passe dans le système.

Si le trafic de pointe est de 5 requêtes par seconde et que chaque requête dure 14 secondes entre son arrivée et le dernier token (environ 1 seconde de file d’attente et de prefill, plus 400 tokens de sortie à 30 tokens par seconde), le système traite environ 70 requêtes simultanément. Multipliez ce chiffre par le nombre moyen de tokens conservés par requête et par la taille du KV cache par token : vous obtenez la mémoire de cache nécessaire en pointe.

• Raisonner sur la pointe, pas sur la moyenne. Le trafic interactif atteint couramment deux à quatre fois sa moyenne quotidienne pendant l’heure la plus chargée.
• Surveiller la longueur des sorties. La concurrence croît avec la durée pendant laquelle les requêtes restent ouvertes, et les tokens de sortie sont la partie lente : doubler la longueur moyenne des sorties double donc à peu près la concurrence.
• Tenir compte des nouvelles tentatives et des agents. Les agents qui appellent des outils et les nouvelles tentatives automatiques peuvent déclencher plusieurs appels au modèle pour une seule action utilisateur, ce qui multiplie le taux d’arrivée effectif.

Un exemple chiffré

Prenons un assistant interne construit sur un modèle de la classe 70B avec grouped-query attention, servi avec des poids en INT8 et un KV cache en FP16. La charge de pointe est de 5 requêtes par seconde. Les requêtes comptent en moyenne 2 000 tokens d’entrée et 400 tokens de sortie. Les objectifs sont de moins de 1,5 seconde jusqu’au premier token et d’au moins 25 tokens par seconde de streaming au 95e centile. Le matériel envisagé se compose de GPU de 80 GB offrant chacun environ 2 TB/s de bande passante mémoire.

• Poids. 70B paramètres à 1 octet chacun représentent environ 70 GB. Un GPU de 80 GB ne peut pas contenir cela plus un cache utile : l’unité minimale est donc de deux GPU avec parallélisme de tenseurs, soit 160 GB physiques, environ 144 GB utilisables à 90 pour cent.
• Budget de cache. 144 GB moins 70 GB de poids laissent environ 74 GB pour le KV cache.
• Besoin en cache. D’après la loi de Little, environ 70 requêtes simultanées. Chacune occupe environ 2 400 tokens à son terme, soit à peu près 0,8 GB à 320 KB par token, ce qui donne un besoin de pointe d’environ 55 GB. Cela tient, avec une marge d’environ 25 pour cent.
• Vitesse de décodage. Chaque étape lit environ 35 GB de poids par GPU, plus la part du cache de ce GPU, soit environ 27 GB en pointe. À 2 TB/s, cela représente à peu près 31 ms par étape avant surcoût, soit environ 30 tokens par seconde par flux et environ 2 000 tokens de sortie par seconde au total. C’est exactement les 2 000 tokens par seconde qu’exige la pointe, sans aucune marge.
• Charge de prefill. 5 requêtes x 2 000 tokens représentent 10 000 tokens d’entrée par seconde, soit environ 1,4 PFLOP/s de calcul. Cette charge entre en concurrence avec le décodage sur les mêmes GPU et fera passer le streaming sous l’objectif lors des pics.

Conclusion : une réplique à deux GPU accueille le modèle et le cache, mais n’offre aucune marge de débit en pointe et aucune redondance. Deux répliques, soit quatre GPU au total derrière un équilibreur de charge, divisent à peu près par deux la charge de chaque réplique, maintiennent la latence dans l’objectif pendant les rafales et permettent de drainer une réplique pour maintenance aux heures creuses.

Taux d’utilisation, montée en charge horizontale et coût par million de tokens

Les pourcentages d’utilisation GPU affichés par les outils de supervision peuvent être trompeurs, car un GPU occupé à lire la mémoire pour un lot d’une seule requête paraît pleinement utilisé alors qu’il accomplit peu de travail utile. Suivez plutôt les métriques qui reflètent la capacité : tokens générés par seconde, occupation du KV cache, requêtes en attente dans la file, et centiles de latence pour le temps jusqu’au premier token et le temps par token de sortie.

• Ajouter des réplicas quand des files se forment. Une file d’attente persistante en pointe, ou une occupation du KV cache supérieure à environ 90 pour cent avec des requêtes préemptées, signifie que le réplica est plein.
• Ajouter des réplicas quand la latence dérive. Si le 95e centile du temps par token de sortie se rapproche de l’objectif alors que le débit stagne, le lot est trop grand pour le réplica.
• Monter en gamme quand le modèle ne tient pas. Davantage de mémoire par GPU ou davantage de GPU par réplica aident lorsque les poids et le cache minimal ne tiennent pas en mémoire, ou lorsque les contextes longs dominent.
• Conserver N+1. Un service important doit survivre à la perte d’un réplica en pointe, ce qui détermine généralement le nombre de réplicas davantage que le débit brut.

Le coût par million de tokens découle directement de ces chiffres : divisez le coût horaire du parc par les millions de tokens qu’il produit par heure. Avec un tarif purement hypothétique de 2,50 $ par heure-GPU, l’exemple à quatre GPU coûte 10 $ de l’heure. À pleine production de pointe, soit 2 000 tokens par seconde, il produit 7,2 millions de tokens de sortie par heure, environ 1,40 $ par million. Si la charge moyenne sur la journée représente 30 pour cent de la pointe, le même parc produit environ 2,2 millions de tokens par heure et le coût effectif monte à environ 4,60 $ par million.

Le taux d’utilisation pèse davantage sur le coût unitaire que le tarif horaire. Les charges de travail différables, comme la synthèse par lots, le recalcul d’embeddings ou les campagnes d’évaluation, peuvent occuper les heures creuses de la capacité interactive et faire baisser le coût moyen.

Checklist de planification de capacité

• Consignez paramètres, couches, têtes clé/valeur et dimension des têtes.
• Fixez la précision des poids et du KV cache. Testez la qualité sur vos propres prompts.
• Calculez la mémoire des poids et le minimum de GPU par réplica. Réservez 10 à 15 pour cent au surcoût.
• Calculez les octets de KV cache par token et le budget après les poids.
• Mesurez ou estimez le RPS en pointe et le nombre moyen de tokens d’entrée et de sortie.
• Utilisez la loi de Little pour la concurrence en pointe et le cache requis.
• Fixez des objectifs p95 pour le délai avant le premier token et le temps par token de sortie.
• Mesurez le moteur à la concurrence cible. Consignez le débit soutenu en tokens/s par réplica.
• Dimensionnez les répliques sur le débit de pointe avec marge, plus une pour N+1.
• Plafonnez contexte et sortie par requête. Activez le cache de préfixes pour les prompts répétés.
• Déclenchez la montée en charge sur la profondeur de file, le cache et la latence, pas seulement les GPU.
• Calculez le coût par million de tokens en pointe et en charge moyenne. Batch aux heures creuses.
• Confirmez où prompts, réponses et poids peuvent résider, puis choisissez l’emplacement.

Comment Vonahost peut vous aider

Vonahost établit un devis de capacité GPU par projet, avec le modèle de GPU, la quantité et le délai de livraison confirmés par écrit, et prend en charge les déploiements privés dans lesquels les données et les modèles restent dans l’environnement du client. Les déploiements utilisent des outils standard tels que PyTorch, vLLM, Triton et Kubernetes, de sorte que la méthode de dimensionnement ci-dessus se transpose directement en un benchmark sur le matériel proposé.

Chaque proposition Vonahost indique la configuration, l’emplacement, les responsabilités et le prix mensuel en dollars américains, et les clients choisissent le pays où fonctionne chaque serveur.