Exécuter un modèle d’intelligence artificielle sur son propre ordinateur est devenu beaucoup plus accessible, mais la VRAM reste un facteur limitant essentiel. La quantification, FlashAttention, la réduction du contexte, le cache KV optimisé et le déchargement CPU permettent d’utiliser au mieux une GPU, même si chaque situation nécessite une adaptation spécifique : un modèle de 13 milliards de paramètres n’a pas toujours besoin de la même mémoire, et réduire le nombre de couches ne garantit pas de conserver la qualité.

Les astuces pour réduire la VRAM d’un LLM en 30 secondes

• La quantification en INT8 ou INT4 peut considérablement réduire la taille des poids mémoire.
• La VRAM requise dépend aussi du contexte, du cache KV, du lot (batch) et du moteur d’inférence.
• FlashAttention diminue la consommation mémoire lors du calcul de l’attention, mais l’économie n’est pas une réduction fixe en pourcentage.
• Le déchargement CPU permet de dépasser la VRAM physique en utilisant la RAM, avec une pénalité de performance variable.
• Des outils comme llama.cpp et vLLM intègrent directement plusieurs de ces optimisations.

L’utilisation croissante de modèles ouverts et d’outils tels que llama.cpp, Ollama, vLLM ou Transformers a rendu possible l’exécution de modèles de langage en évitant d’envoyer chaque requête à une API externe. Le problème surgit lorsque le modèle est téléchargé, et que la GPU se retrouve à court de mémoire avant même de générer le premier token.

La solution ne consiste pas forcément à acheter une nouvelle carte graphique. Il existe une marge d’adaptation pour optimiser l’exécution du modèle selon le matériel disponible.

La VRAM d’un LLM ne dépend pas uniquement de ses paramètres

Une approximation simple permet de comprendre rapidement le phénomène. Si un modèle compte 7 000 milliards de paramètres et que chacun occupe 16 bits, la taille des poids est d’environ 14 Go.

Le calcul de base est :

mémoire = nombre de paramètres × bits par paramètre / 8

En appliquant cette formule à différentes précisions :

Modèle	FP16	INT8 théorique	4 bits théorique
7B	14 GB	7 GB	3,5 GB
13B	26 GB	13 GB	6,5 GB
32B	64 GB	32 GB	16 GB
70B	140 GB	70 GB	35 GB

Ces chiffres donnent une idée approximative de la mémoire nécessaire pour stocker les poids, mais ils ne représentent pas la mémoire totale requise.

Une quantification à quatre bits augmente généralement la taille totale par rapport à la simple multiplication, en raison du format utilisé, des échelles, des métadonnées et d’autres éléments. Pendant l’inférence, il faut aussi ajouter des buffers d’exécution, et surtout, le cache KV.

C’est pourquoi deux utilisateurs peuvent exécuter le même modèle avec des consommations de VRAM très différentes.

INT4 et INT8 : quantifier avant d’acheter plus de mémoire

La quantification reste l’une des techniques les plus efficaces pour faire fonctionner de grands modèles avec des ressources limitées.

En représentant les poids avec moins de bits (au lieu de FP16 ou BF16), on approche une moitié de la consommation mémoire. Utiliser quatre bits permet d’en réduire encore davantage l’utilisation.

De nombreuses solutions existent actuellement dans l’écosystème.

llama.cpp utilise généralement des modèles au format GGUF et propose différents niveaux de quantification. GPTQ et AWQ sont deux techniques populaires, tandis que Hugging Face intègre aussi la quantification via bitsandbytes. vLLM supporte aussi plusieurs formats et techniques pour diminuer la mémoire lors de l’inférence.

Mais quantifier n’est pas sans coûts.

Réduire la précision peut entraîner une perte de qualité, qui est variable selon le modèle et la tâche. Un modèle destiné à la conversation générale peut tolérer une quantification agressive mieux qu’un modèle conçu pour du code, du raisonnement ou une application spécifique.

L’enjeu pratique consiste à trouver le bon compromis entre économie de mémoire et dégradation de performance.

Le contexte peut occuper plus de mémoire que prévu

Il est souvent oublié que la longueur du contexte influence aussi la consommation de mémoire VRAM.

Les modèles transformer maintiennent l’information des tokens précédents via la KV cache (Key-Value cache). Grâce à elle, ils n’ont pas besoin de recalculer toute la séquence à chaque génération de nouveau token.

Ce mécanisme accélère énormément la génération, mais consomme aussi de la mémoire.

Plus le contexte est long, plus la mémoire requise peut augmenter.

Ce qui explique qu’il ne soit pas toujours judicieux de configurer automatiquement une fenêtre de contexte de 64K, 128K ou plus, simplement parce que le modèle le supporte. La longueur du contexte utile dépend de l’application ; supporter une grande fenêtre ne signifie pas qu’elle doit être utilisée en permanence.

Diminuer la longueur maximale du contexte sur une GPU limitée peut libérer une quantité significative de mémoire sans toucher aux poids.

Des moteurs comme vLLM permettent d’ailleurs de gérer la KV cache quantifiée et de contrôler la mémoire qui lui est réservée, ce qui est crucial quand plusieurs requêtes sont traitées simultanément.

FlashAttention réduit la mémoire, mais pas la magie

FlashAttention est une autre optimisation qui a changé la manière d’exécuter les transformers.

Le mécanisme d’attention classique peut requérir beaucoup de mémoire temporaire, surtout pour de longues séquences. FlashAttention réorganise les calculs pour réduire les accès mémoire et éviter de générer certaines matrices complètes.

Léger gain en consommation et en vitesse, mais il ne faut pas croire qu’il réduit la VRAM d’un pourcentage fixe, par exemple 30% : cela dépend de nombreux facteurs, comme la longueur de la séquence, l’architecture, le batch, la GPU, et l’implémentation.

Dans la pratique, si un modèle occupe 20 Go pour ses poids sur une GPU de 24 Go, FlashAttention ne va pas transformer ces 20 Go en 14 Go. Son efficacité se fait surtout sur la mémoire utilisée pour le calcul d’attention.

PyTorch propose aujourd’hui des implémentations optimisées de scaled dot product attention, et des moteurs spécialisés en inférence exploitent aussi des techniques attention mémoire-efficace.

Petits batch pour bureau, batching efficace pour serveurs

Réduire la taille du batch est une solution simple.

Si une seule requête est en cours, il ne sert pas à grand-chose d’allouer de la mémoire pour plusieurs séquences en parallèle. Un batch size réduit peut diminuer activations et buffers nécessaires.

C’est une bonne stratégie pour un PC personnel, utilisé par une seule personne.

Mais la donne change en environnement de production.

Un serveur traitant des dizaines voire des centaines d’utilisateurs doit exploiter toute la puissance parallèle de la GPU. Réduire trop le batch pourrait diminuer la consommation mémoire, mais aussi sous-utiliser une GPU qui coûte des milliers d’euros.

vLLM utilise justement la batching continu pour combiner plusieurs requêtes et tirer le meilleur parti du matériel.

L’optimisation dépend donc de l’objectif : faire tenir un modèle sur une GPU domestique ou maximiser les tokens par seconde en environnement serveur.

CPU offload : utiliser la RAM quand la VRAM est pleine

Quand un modèle est trop gros pour tenir en VRAM, une solution pratique consiste à décharger une partie de ses poids vers la mémoire RAM.

llama.cpp permet de répartir le traitement entre CPU et GPU. vLLM offre aussi des mécanismes de CPU offload.

Cela ouvre la voie à des scénarios où, avec 24 Go de VRAM et beaucoup de RAM, on peut exécuter des modèles dont les poids dépassent la mémoire physique de la GPU.

Mais la RAM ne se transforme pas magiquement en VRAM.

Lorsque la GPU doit accéder à des données en mémoire principale, celles-ci doivent transiter entre la RAM et la GPU. Sur une machine avec GPU dédié, cela implique le bus PCI Express, impactant le rendu en inférence.

Plus on confie de travail à la CPU, plus l’impact peut être important.

Il n’y a pas de règle universelle précisant que le déchargement CPU entraîne toujours une baisse de performance de 20 ou 30 %. Cela peut être moindre ou beaucoup plus élevé.

Pour un usage personnel, cela peut être suffisant. En production à haute charge, cela peut poser problème.

Pruner des couches n’est pas une solution miracle pour la mémoire

Supprimer des couches d’un modèle demande un traitement différent.

Il est techniquement possible de réduire un transformer en retirant certaines couches, via des techniques comme le layer pruning ou d’autres méthodes de compression structurée.

Mais ici, on modifie l’architecture du modèle.

Ce n’est pas équivalent à exécuter les mêmes poids en 4 bits.

Supprimer les deux ou quatre dernières couches d’un modèle de 13B ne garantit pas qu’il conservera toute sa capacité. Le résultat dépend énormément du modèle et doit être validé par des évaluations selon les tâches envisagées.

Pour quelqu’un cherchant simplement à faire tourner un LLM sur une petite GPU, la quantification, le contexte, le cache KV et le déchargement sont généralement des options plus sûres que le pruning.

Une GPU de 8 Go a encore de belles années devant elle

Les avancées en quantification ont permis de redonner vie à des GPU qui semblaient trop petites pour l’IA générative.

Avec 8 Go de VRAM, il est possible d’exécuter de nombreux modèles quantifiés de petite ou moyenne taille, notamment ceux d’environ 7 à 8 milliards de paramètres.

A 12 ou 16 Go, les marges s’élargissent pour des modèles plus grands, des contextes plus vastes ou des quantifications moins agressives.

Les GPU de 24 Go permettent une autre catégorie, avec la capacité de charger des modèles considérablement plus grands ou d’allouer la mémoire entre poids et contextes longs plus confortablement.

Ensuite, on atteint des configurations multi-GPU ou des accélérateurs professionnels avec beaucoup plus de mémoire.

Mais plus de VRAM ne signifie pas forcément un meilleur déploiement.

L’optimisation change radicalement à l’arrivée du modèle en production

La préoccupation que « le modèle doit tenir » a du sens pour une utilisation personnelle. En entreprise, le cahier des charges est beaucoup plus large.

Une infrastructure d’inférence doit considérer simultanément la VRAM, la bande passante mémoire, la puissance de calcul, la RAM, le CPU, le stockage, le réseau et la consommation électrique.

Il existe aussi des métriques qui ne ressortent pas d’un simple nvidia-smi : le temps jusqu’au premier token, les tokens par seconde, la concurrence, le débit total et le coût par million de tokens.

Un modèle de 70 milliards, utilisant beaucoup de CPU en déchargement, peut fonctionner techniquement, mais ne sera pas optimal pour une plateforme à haute charge utilisateur.

Inversement, un modèle de 8 milliards, bien choisi, quantifié et adapté, peut répondre à certaines missions avec beaucoup moins d’équipement.

Une des décisions clés dans tout projet d’IA d’entreprise consiste à ne pas commencer par choisir le modèle avant d’étudier les besoins d’exécution.

Il faut commencer par analyser la mission :

• Les données d’entrée
• La réponse attendue
• La précision requise
• Le nombre de requêtes
• Les contraintes de latence
• Les données disponibles en interne

Ce n’est qu’après cette Analyse que l’on peut déterminer la capacité mémoire nécessaire, par exemple 8, 24, ou même 80 Go de VRAM.

L’ingénierie de l’inférence locale s’oriente vers cette logique : tirer plus de performance de ressources limitées. Quantifier les poids en fait partie, mais la vraie optimisation se construit lorsque modèle, contexte, runtime et matériel sont conçus comme un système intégré.

Questions fréquentes

Quelle VRAM faut-il vraiment pour un modèle de 13 milliards ?

Ses poids nécessitent environ 26 Go en FP16 et environ 6,5 Go en quantification à quatre bits. La consommation réelle sera supérieure, car il faut ajouter le format de quantification, le cache KV, les buffers et la mémoire du runtime.

INT8 ou INT4 : quel est le meilleur choix pour exécuter un LLM ?

INT4 permet d’économiser plus de mémoire, mais INT8 offre une meilleure précision numérique. Le choix dépend du modèle, du matériel et de la qualité souhaitée ; il faut donc évaluer le compromis en pratique selon la tâche.

Que faire si un modèle ne tient pas en GPU ?

Les options incluent une quantification plus faible, la réduction du contexte, l’optimisation du cache KV, le déchargement CPU, ou la répartition sur plusieurs GPU si l’outil d’inférence le permet.

FlashAttention réduit-il toujours la VRAM ?

Il diminue surtout la mémoire utilisée pour le calcul de l’attention, mais l’économie en pourcentage n’est pas fixe et dépend de nombreux paramètres, dont la longueur de la séquence, l’architecture, le batch, la GPU et l’implémentation.