Ce modèle tient-il dans votre GPU ? Estimer la VRAM avant de choisir son matériel

La question ne se résume pas au nombre de paramètres du modèle

Connaître le nombre de paramètres d’un modèle peut donner un premier repère, mais ne répond pas à la question concrète : fonctionnera-t-il sur ce GPU avec la configuration dont j’ai besoin ? Pour le savoir, il faut tenir compte du modèle exact, du format de ses poids, du runtime, du contexte à traiter, du nombre de requêtes simultanées et de la mémoire déjà utilisée par le système.

« Tenir » n’est donc pas une propriété intrinsèque du modèle. Celui-ci peut se charger, puis manquer de mémoire lorsque le contexte s’allonge ; il peut fonctionner pour une requête, mais pas pour plusieurs ; ou il peut démarrer parce qu’une partie du travail est exécutée en RAM, alors que le modèle ne réside pas entièrement dans le GPU. Le résultat peut également changer selon le runtime et ses options.

L’objectif de ce guide est de construire une première estimation, puis de la confronter à un essai contrôlé. L’estimation aide à écarter les configurations manifestement irréalisables et à déterminer ce qu’il faut mesurer. Elle ne remplace pas un essai avec le matériel, le runtime et la charge réels. Elle ne permet pas non plus de déduire la vitesse, la qualité des réponses ou la stabilité sur une longue durée.

Ce qui occupe de la mémoire pendant l’exécution

Pour être utile, une estimation doit distinguer au moins quatre éléments : les poids du modèle, le cache KV, les buffers temporaires de calcul et la mémoire nécessaire au runtime, au système et aux autres processus. Cette séparation est conceptuelle : selon le runtime, les options et le matériel, les allocations peuvent être comptabilisées différemment et ne pas apparaître comme des catégories distinctes dans un outil de surveillance.

Les poids sont les données du modèle chargées par le runtime pour effectuer l’inférence. La taille du fichier peut donner une indication, mais elle ne correspond pas automatiquement à la mémoire totale nécessaire. Le format et la quantification influent sur la taille des poids, tandis que le chargement mobilise également de la mémoire de travail et des structures propres au runtime. Ne convertissez pas directement la taille du fichier en quantité de VRAM disponible sans mesurer la configuration choisie.

Le cache KV conserve des informations liées aux tokens déjà traités afin de poursuivre la génération. Son occupation dépend de la charge active et de caractéristiques du modèle, pas seulement de son nom ou du nombre de paramètres. Le contexte prévu et les requêtes parallèles sont des variables à fixer avant l’estimation ; l’architecture et le type de cache configuré peuvent également modifier le résultat.

Les buffers de calcul sont des espaces mémoire temporaires utilisés par les opérations du runtime. Leur taille peut dépendre de l’implémentation et des options activées. Le runtime et le système ont, eux aussi, besoin d’une marge ; en outre, un GPU peut partager sa mémoire avec l’affichage ou d’autres processus. La capacité nominale de la carte ne doit donc pas être considérée comme entièrement disponible pour le modèle.

Rassemblez les données avant de faire des calculs

Commencez par identifier l’artefact exact du modèle : pas seulement son nom commercial, mais aussi le fichier ou le format que vous allez charger et la configuration associée. Une fiche de configuration peut révéler des dimensions que le nom ne précise pas, comme le nombre de couches ou certaines dimensions et têtes d’attention. Ces données aident à décrire l’architecture, mais ne suffisent pas à calculer la consommation finale : la manière dont le runtime représente et alloue le cache et les buffers compte également.

Définissez ensuite le runtime et ses options. Consignez la version ou la configuration testée, la taille du contexte demandé, la concurrence prévue et tout choix concernant le type ou l’emplacement du cache. Si le runtime permet de placer certaines couches sur le GPU, d’en décharger une partie sur le CPU ou de répartir le travail entre plusieurs cartes, notez également ces choix. Une estimation qui omet ces conditions mélange des scénarios différents.

Enfin, relevez l’état initial de la machine : mémoire totale et disponible du GPU, processus qui l’utilisent déjà et rôle de la carte — réservée à l’inférence ou utilisée aussi pour d’autres tâches. Les outils d’administration du GPU peuvent afficher la mémoire totale, réservée, utilisée et libre. Ces mesures décrivent l’état du périphérique, mais n’expliquent pas à elles seules quel composant du modèle occupe chaque portion de mémoire.

Construire une première estimation

Pour une première approximation, considérez que la VRAM requise correspond à la somme des poids résidant sur le GPU, du cache KV hébergé sur le GPU, des buffers et du coût du runtime, à laquelle s’ajoute une marge pour les variations de charge et les autres usages de la carte. Il ne s’agit ni d’une formule exacte ni d’un résultat que l’on peut obtenir à partir de données génériques : les catégories et leur taille dépendent de l’implémentation et de la configuration.

Séparez les valeurs connues des approximations. La taille du fichier est observable, mais ne prouve ni quelle part de cette taille résidera dans le GPU ni quel sera le pic de mémoire. Le contexte et la concurrence souhaités sont des décisions qui vous appartiennent. Pour connaître l’architecture et la stratégie de cache, il faut consulter les informations du modèle et du runtime. Les buffers et la marge doivent souvent être mesurés sur la machine qui exécutera le modèle.

Si une variable importante est inconnue, ne la dissimulez pas derrière un chiffre unique. Il est plus prudent de préparer plusieurs scénarios : par exemple, une configuration avec un contexte modéré et une autre plus exigeante, chacune avec la concurrence requise par le service. Ces descriptions ne garantissent pas une consommation précise ; elles servent à couvrir les conditions d’utilisation pendant l’essai, au lieu de valider uniquement le cas le plus simple.

La documentation d’un runtime peut aider à comprendre les options disponibles et les limites annoncées. Cependant, une capacité déclarée ou une valeur de configuration ne démontre pas que la machine supportera la charge en fonctionnement. Appuyez-vous sur la documentation pour concevoir l’essai, puis sur les mesures pour vérifier la configuration.

Le cache KV varie avec le contexte et la charge

Le cache KV mérite une attention particulière, car son occupation est liée au travail actif. Un contexte plus long peut nécessiter de conserver davantage d’informations pour poursuivre la génération ; plusieurs requêtes simultanées peuvent maintenir plusieurs séquences actives. Il est impossible d’en déduire une valeur précise à partir du nom du modèle ou de son nombre de paramètres.

L’architecture compte. Pour obtenir une estimation plus étayée, il faut connaître les attributs de configuration du modèle et la façon dont le runtime gère l’attention et le cache. Même avec ces informations, la valeur observée peut dépendre du type de cache choisi, de l’allocation mémoire et des options du runtime. Une règle générale dépourvue de ces données peut fournir un repère qualitatif, mais ne garantit pas qu’une configuration tiendra.

Les runtimes peuvent proposer différentes stratégies, par exemple des caches dynamiques, statiques, quantifiés ou déchargés vers le CPU. Le changement de stratégie peut modifier la répartition de la mémoire et les conditions d’exécution. Ne comparez pas deux estimations comme si elles étaient équivalentes lorsque la stratégie de cache, le runtime ou ses options diffèrent.

GPU entièrement utilisé, déchargement vers la RAM ou plusieurs cartes

Une exécution peut utiliser le GPU pour toutes les couches du modèle, n’y placer qu’une partie des couches, décharger une partie du cache vers le CPU ou répartir le modèle entre plusieurs GPU. Certaines de ces options permettent d’essayer des configurations qui ne tiendraient pas sur une seule carte si toutes leurs composantes y résidaient. Elles ne prouvent toutefois pas que le modèle est entièrement présent dans la VRAM et ne permettent pas, à elles seules, de déduire les performances obtenues.

Vérifiez le mode d’exécution dans les options et les journaux du runtime. Si l’outil permet de préciser le nombre de couches sur GPU ou de répartir le travail entre plusieurs cartes, notez les valeurs appliquées. Lorsqu’un déchargement vers le CPU ou une stratégie de cache sur CPU est activé, la mémoire du GPU ne représente plus à elle seule toute la mémoire utilisée par l’exécution. Distinguez « l’application a démarré » de « la configuration respecte les exigences de résidence et de charge définies ».

Avec plusieurs GPU, connaître la somme de leurs capacités nominales ne suffit pas non plus à déterminer comment le modèle sera réparti. La répartition dépend des capacités du runtime et de la configuration choisie. Évaluez chaque périphérique ainsi que l’allocation effective, sans supposer que toute la mémoire cumulée est disponible pour n’importe quelle répartition.

Vérifier l’estimation à l’aide d’un essai contrôlé

L’essai doit reproduire le scénario que vous envisagez de déployer. Fixez le modèle, son format, le runtime, le contexte, la concurrence ainsi que les options de cache et de déchargement. Consignez l’état initial de la mémoire et tout processus extérieur qui partage le GPU. Si vous modifiez plusieurs options à la fois, il sera difficile de savoir laquelle explique le résultat.

Chargez le modèle et relevez la mémoire utilisée et disponible. Lancez ensuite une requête avec la configuration prévue. Augmentez progressivement le contexte ou la concurrence, une seule variable à la fois, puis notez à quel moment une erreur apparaît, un déchargement est activé ou la consommation approche la limite observée. N’interprétez pas une mesure isolée comme un maximum stable : surveillez la charge pendant l’exécution, car l’utilisation peut différer entre le chargement initial et l’inférence.

Consultez les journaux du runtime pour vérifier la répartition entre GPU et CPU et les options réellement appliquées. Comparez ces observations à celles d’un outil GPU affichant la mémoire totale, utilisée, réservée et libre. Cette mesure décrit l’état du périphérique, mais ne sépare pas toujours les poids, le cache et les buffers. Répétez l’exécution pour repérer les variations sur une même machine et consignez précisément les conditions.

Définissez à l’avance les critères de réussite : le contexte prévu doit être traité, la concurrence requise doit être supportée et l’exécution ne doit pas dépendre d’un déchargement qui n’était pas prévu. Si le système doit conserver une marge pour d’autres processus, faites-en également une exigence. Un essai qui se termine sans erreur, mais ne laisse plus cette marge, peut ne pas convenir à l’usage prévu.

Erreurs fréquentes et limites de l’estimation

L’erreur la plus courante consiste à traiter la taille du fichier comme la consommation totale. Cette donnée ne comprend pas nécessairement le cache, les buffers, le runtime ni la mémoire déjà utilisée par le système. Une autre erreur consiste à comparer la charge à la capacité nominale du GPU sans mesurer la mémoire réellement disponible lorsque la machine est dans son état d’utilisation habituel.

Il est également facile de vérifier uniquement le démarrage et d’en déduire qu’un contexte étendu ou plusieurs requêtes fonctionneront. Le chargement initial et l’exécution sous charge sont deux étapes différentes de l’essai. Si vous changez le contexte, la concurrence, le type de cache, le runtime ou la répartition entre GPU et CPU, vous testez une autre configuration.

Enfin, ne transposez pas sans précaution un chiffre obtenu avec un runtime vers un autre. Les outils peuvent gérer la mémoire différemment et ne pas exposer les mêmes métriques. Les valeurs observées décrivent la machine et les options testées ; elles ne garantissent pas le même résultat sur un autre système ni une exécution stable indéfiniment. L’essai ne permet pas non plus d’établir la qualité des réponses ou une vitesse suffisante pour un cas d’usage donné.

Derniers critères pour choisir ou réutiliser du matériel

Avant d’acheter un GPU, définissez une charge représentative et vérifiez si la mémoire disponible peut accueillir les composants que vous souhaitez y garder, ainsi que la marge nécessaire au système. Si l’estimation dépasse manifestement la capacité utilisable, inutile de prétendre à une précision illusoire : cette combinaison exige de revoir les contraintes, la répartition ou le matériel. Si la configuration se situe près de la limite, un essai sur la machine exacte devient particulièrement important.

Pour réutiliser un GPU, mesurez son état réel et vérifiez quels autres usages partagent sa mémoire. Ne considérez pas sa capacité totale comme entièrement libre. Si vous acceptez une exécution partielle en RAM ou une répartition entre plusieurs cartes, consignez ce choix comme une partie de la configuration, et non comme un détail invisible. Pour comparer des options, utilisez la même charge et les mêmes critères.

Pour approfondir l’exécution de modèles locaux, vous pouvez consulter le guide consacré aux modèles locaux, le comparateur et la section de découverte. Appliquez la même méthode à chaque option : identifiez précisément la configuration et vérifiez les conditions pertinentes pour votre cas. La conclusion utile n’est pas une valeur universelle de VRAM, mais un résultat reproductible pour un modèle, un runtime, un matériel et une charge définis.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.