Comment estimer la mémoire GPU nécessaire à l’inférence LLM auto-hébergée

Pourquoi la taille du modèle ne suffit pas à déterminer les besoins en mémoire GPU

Le nombre de paramètres d’un modèle constitue un premier repère utile, mais ne permet pas d’établir un budget mémoire GPU complet. L’inférence nécessite aussi de la mémoire pour le cache clé-valeur (KV) et les activations, tandis que l’environnement d’exécution, l’architecture du modèle et la configuration du service peuvent influer sur l’utilisation réelle.

Un modèle qui tient en mémoire au chargement peut néanmoins dépasser la capacité disponible lorsque les requêtes arrivent. Les séquences plus longues et l’augmentation du nombre de requêtes actives accroissent les besoins du cache KV. Les autres charges exécutées sur le GPU et la surcharge d’exécution consomment elles aussi de la mémoire.

Considérez tout calcul comme une estimation destinée à la planification, et non comme une garantie matérielle. Le résultat dépend du modèle concerné, de l’environnement d’inférence et de la configuration du service.

• Estimez séparément les poids du modèle et le cache KV.
• Décrivez la charge de travail, notamment la longueur des séquences et la concurrence, avant de comparer les estimations à la mémoire GPU disponible.
• Validez la configuration prévue sur le déploiement visé au lieu de vous fier uniquement au nom ou au nombre de paramètres du modèle.

Estimer la mémoire des poids du modèle, quantification comprise

Pour obtenir une première estimation, multipliez le nombre de paramètres du modèle par le nombre d’octets utilisés par paramètre. À titre indicatif, on associe souvent FP32 à 4 octets, FP16 à 2 octets, INT8 à 1 octet et INT4 à 0,5 octet par paramètre.

Par exemple, pour un modèle hypothétique de 8 milliards de paramètres, l’estimation idéale des poids serait de 16 Go à 2 octets par paramètre, de 8 Go à 1 octet ou de 4 Go à 0,5 octet. Il s’agit de calculs décimaux illustratifs concernant uniquement les poids ; ils n’incluent ni le cache KV, ni les activations, ni les besoins de l’environnement d’exécution.

La quantification peut réduire la mémoire consacrée aux poids en utilisant moins de bits par paramètre, mais cette estimation ne décrit pas à elle seule le modèle déployé. Vérifiez le format réel du modèle et l’environnement d’exécution, et prenez en compte les compromis de précision pour déterminer si une configuration quantifiée convient.

• Notez le nombre de paramètres ainsi que le format de précision ou de quantification que vous prévoyez d’utiliser en service.
• Calculez la mémoire des poids ainsi : nombre de paramètres × octets par paramètre.
• Gardez des unités cohérentes : les Go décimaux et les Gio binaires sont deux unités différentes, et les outils GPU peuvent afficher la mémoire de différentes façons.
• Ne considérez pas ce résultat comme la mémoire totale nécessaire au traitement des requêtes.

Tenir compte de la longueur du contexte et du cache KV

Pendant l’inférence, le cache KV stocke les données de clés et de valeurs pour les jetons des séquences actives. Sa consommation mémoire dépend de la taille du lot, de la longueur de la séquence, du nombre de couches, du nombre de têtes KV, de la dimension des têtes et du nombre d’octets par élément du cache.

Une estimation utile est la suivante : octets du cache KV = 2 × taille du lot × longueur de la séquence × nombre de couches × nombre de têtes KV × dimension des têtes × octets par élément du cache. Le facteur 2 correspond aux clés et aux valeurs.

À titre d’exemple explicitement hypothétique, supposons une configuration comprenant 32 couches, 8 têtes KV, une dimension de tête de 128, des éléments de cache de 2 octets, une séquence de 4 096 jetons et une taille de lot de 1. La formule donne 536 870 912 octets, soit environ 0,5 Gio. Avec une taille de lot de 4 et toutes les autres hypothèses inchangées, l’estimation est d’environ 2 Gio. Ces valeurs servent uniquement à illustrer le calcul ; elles ne décrivent pas un modèle particulier.

Pour planifier, utilisez la longueur de séquence que l’environnement d’exécution peut conserver simultanément, en comptant les jetons du prompt et ceux générés. Une limite de contexte élevée ne signifie pas que chaque requête utilisera cette limite dans son intégralité, mais les requêtes les plus longues peuvent déterminer les besoins de pointe du cache.

• Recherchez dans la documentation ou la configuration fiable du modèle le nombre de couches, le nombre de têtes KV et la dimension des têtes.
• Utilisez le type de données du cache et le comportement du service correspondant à l’environnement d’exécution prévu.
• Estimez les longueurs de séquence habituelles ainsi que les plus longues séquences que vous prévoyez de traiter.
• Si le modèle utilise l’attention à requêtes groupées (grouped-query attention), utilisez le nombre de têtes KV au lieu de supposer qu’il est égal au nombre de têtes de requête.

Prendre en compte les requêtes simultanées, les lots et les charges partagées sur le GPU

La formule du cache KV évolue à la fois avec la taille du lot et la longueur de la séquence. Plusieurs requêtes actives peuvent donc nécessiter beaucoup plus de mémoire cache qu’une seule, en particulier si elles ont un contexte long.

La concurrence et la taille du lot sont liées, mais ne doivent pas être considérées comme interchangeables sans vérifier la configuration du service. Un serveur peut regrouper les requêtes en lots ou gérer les séquences actives d’une autre manière. Fondez votre estimation sur le comportement attendu de l’environnement d’exécution réel.

Tenez également compte de tout autre élément qui utilise le GPU. Un autre processus ou modèle peut consommer de la mémoire qui serait autrement disponible pour l’inférence. La fragmentation de la mémoire et les choix d’exécution peuvent aussi influer sur la possibilité de faire fonctionner en pratique une configuration qui semble tenir sur le papier.

• Notez le nombre moyen et maximal de requêtes actives prévu, et pas seulement le volume quotidien de requêtes.
• Indiquez les longueurs de séquence associées à ces requêtes actives.
• Vérifiez si le traitement par lots est activé et comment l’environnement d’exécution gère les requêtes de longueurs différentes.
• Répertoriez les autres processus et charges GPU susceptibles de fonctionner en même temps que l’inférence.

Inclure la surcharge de l’environnement d’exécution et du matériel sans supposer de marge fixe

Il n’existe pas de marge fixe universelle et fiable à ajouter à chaque estimation. L’utilisation réelle de la mémoire peut varier selon le moteur d’inférence, les optimisations de l’environnement d’exécution, la stratégie de traitement par lots, l’architecture du modèle et la fragmentation de la mémoire. Des facteurs propres au framework et au modèle comptent également.

Au lieu d’ajouter un pourcentage arbitraire et de considérer le résultat comme définitif, traitez la surcharge comme une inconnue à mesurer. Commencez par calculer les poids et le cache, puis comparez les résultats à l’utilisation observée avec l’environnement d’exécution et la charge prévus.

Vérifiez la mémoire utilisable du GPU telle qu’elle est indiquée dans l’environnement où le service fonctionnera. La capacité nominale ne permet pas de déterminer la quantité qui restera disponible après les allocations des autres charges et de l’environnement d’exécution.

• Documentez le moteur d’inférence, la configuration du modèle et les paramètres de service utilisés pour l’estimation.
• Identifiez les charges GPU qui partageront le dispositif et déterminez si elles fonctionneront simultanément.
• Ne présentez pas une marge de sécurité non testée comme une exigence universelle.
• Utilisez les résultats des tests pour définir une marge opérationnelle adaptée à votre propre charge de travail.

Définir le profil de charge avant de choisir l’infrastructure

Une estimation utile commence par la description de la charge de travail, et non par le seul nom du modèle. Relevez les détails architecturaux nécessaires au calcul du cache, la précision des poids ainsi que les longueurs et la concurrence que votre service doit prendre en charge.

Distinguez l’utilisation habituelle de l’utilisation de pointe. Si votre système traite des requêtes variées, une longueur de séquence moyenne unique peut masquer les besoins en mémoire des prompts longs ou des requêtes longues simultanées. Testez un profil représentatif ainsi que le cas maximal crédible que vous devez prendre en charge.

• Modèle : nombre de paramètres, détails de l’architecture nécessaires à la formule du cache KV, et précision ou quantification des poids.
• Prompt : longueur habituelle et longueur maximale du prompt, en jetons.
• Sortie : longueur prévue et longueur maximale des jetons générés.
• Séquence : longueur du prompt et de la sortie réunis, que l’environnement d’exécution peut devoir conserver.
• Service : nombre habituel et maximal de requêtes actives, comportement du traitement par lots et paramètres pertinents de l’environnement d’exécution.
• Environnement : mémoire GPU disponible pour le processus et autres charges partageant le GPU.

Valider l’estimation avec un test représentatif

Exécutez le modèle réel avec l’environnement d’inférence et la configuration de service prévus avant de vous fier à l’estimation. Commencez par une charge normale, puis testez les séquences plus longues et le niveau de concurrence supérieur correspondant aux pointes attendues.

Surveillez la mémoire GPU pendant le chargement du modèle et lorsque des requêtes sont actives. Consignez la configuration avec les mesures afin de pouvoir les exploiter si vous modifiez le modèle, les limites de contexte, la quantification, l’environnement d’exécution ou le traitement par lots.

La réussite d’une seule requête ne prouve pas que le système peut gérer la charge de pointe. Répétez le test avec des requêtes simultanées représentatives et examinez toute hausse inattendue de la consommation mémoire ou tout échec avant de considérer la configuration comme prête.

• Testez le même format de modèle, la même précision, le même environnement d’exécution et les mêmes paramètres que ceux prévus pour le déploiement.
• Incluez des longueurs de prompt et de sortie réalistes, puis testez le niveau de concurrence maximal prévu.
• Surveillez l’utilisation réelle de la mémoire pendant tout le chargement et le service, pas uniquement au démarrage.
• Répétez les mesures après toute modification importante du modèle ou de la configuration du service.

Que faire si la charge de travail dépasse la mémoire GPU disponible

Commencez par déterminer quelle partie de la charge entraîne le dépassement. Si les longues séquences en sont la cause, réduire la longueur du contexte ou limiter les requêtes exceptionnellement longues peut diminuer les besoins du cache KV. Si les poids du modèle occupent l’essentiel de la mémoire, la quantification peut réduire leur empreinte, mais implique un compromis de précision à évaluer pour le modèle et la tâche concernés.

Parmi les autres options figurent la réduction de la concurrence maximale ou la modification de la configuration du service. Chaque choix change le comportement du service : vérifiez donc que les limites de contexte, le traitement des requêtes et la qualité des sorties restent conformes aux exigences de l’application.

Si ces modifications ne suffisent pas à répondre aux besoins de la charge de travail, réévaluez la capacité GPU ou la conception du déploiement. Ne supposez pas qu’un transfert vers une autre mémoire, un paramètre particulier de l’environnement d’exécution ou un GPU spécifique résoudra le problème sans test : les estimations présentées ne constituent pas une recommandation matérielle universelle.

Après chaque modification, relancez un test de charge représentatif. Une configuration qui tient après réduction de la concurrence ou de la longueur du contexte doit tout de même répondre aux exigences réelles de l’application.

• Réduisez la longueur du contexte si la charge de travail peut tolérer des prompts ou des sorties plus courts.
• Évaluez la quantification des poids en tenant compte de son compromis de précision pour votre cas d’usage.
• Réduisez le nombre maximal de requêtes simultanées ou ajustez le traitement par lots, puis testez l’effet sur le service.
• Si la charge requise ne tient toujours pas en mémoire, comparez les options de déploiement à partir de résultats mesurés plutôt que d’un calcul portant uniquement sur les poids.