Aller au contenu
TortueTech
RubriquesIA publique & IA locale

Dimensionner GPU et RAM pour un LLM local

Dimensionner GPU et RAM pour un LLM local

Section intitulée « Dimensionner GPU et RAM pour un LLM local »

Le dimensionnement d’un grand modèle de langage local ne commence pas par comparer des cartes graphiques sur une boutique en ligne. Il commence par chiffrer les poids, le contexte, la concurrence et le débit réellement attendu, puis par tester la pile complète. La carte la plus chère ne corrige pas une architecture qui confond mémoire disponible et capacité de service.

→ Lire l’explication complète de la marmotte

La page IA locale présente les bases des modèles locaux et d’Ollama. Ici, le sujet est le dimensionnement : décider avant achat, distinguer un poste de travail d’un serveur partagé, puis mesurer ce que la machine tient réellement. Le compromis central est brutal : plus de mémoire permet un modèle, un contexte et une concurrence plus grands, mais le coût, la consommation et la complexité d’exploitation augmentent tous ensemble. Pour un usage professionnel partagé, privilégier la mémoire et la bande passante mémoire avant la puissance de calcul affichée sur la boîte.

Calculer la mémoire des poids, du contexte et des requêtes

Section intitulée « Calculer la mémoire des poids, du contexte et des requêtes »

Un LLM (Large Language Model) est défini, entre autres, par son nombre de paramètres. Les paramètres sont les valeurs numériques du modèle, chargées en mémoire pour produire chaque jeton, c’est-à-dire chaque unité de texte générée ou lue. Leur taille dépend de la quantification : une représentation à moins de bits réduit la mémoire, au prix d’une perte de précision variable selon le modèle et la tâche.

Le calcul théorique minimal des poids est :

mémoire des poids (octets) = nombre de paramètres × bits par paramètre / 8

Un modèle de 8 milliards de paramètres en quantification 4 bits nécessite donc environ 4 milliards d’octets, soit 3,73 Gio (gibioctets). Ce chiffre est une borne basse, pas un besoin matériel. Les formats réels stockent aussi des échelles de quantification, des métadonnées et parfois des tenseurs non quantifiés. La taille exacte du fichier modèle est la valeur de référence opérationnelle. Acheter une carte de 8 Gio pour un fichier de 7,8 Gio est une façon coûteuse de découvrir qu’un système d’exploitation et un moteur d’inférence ont aussi des besoins. La physique conserve ce droit de veto, malgré les slides de vendeurs.

Ajouter ensuite quatre postes :

  1. Cache de clés et valeurs : le cache KV (Key-Value) conserve des états intermédiaires pour chaque jeton du contexte. Sa taille croît linéairement avec la longueur de contexte et avec le nombre de requêtes simultanées.
  2. Espace de travail : les bibliothèques d’inférence réservent des tampons pour les calculs, les opérations de préremplissage et la planification des lots.
  3. Mémoire des requêtes : les entrées, sorties et structures de planification ne sont pas gratuites, particulièrement avec des lots dynamiques.
  4. Marge d’exploitation : réserver au moins 15 à 25 % de mémoire graphique évite les échecs intermittents liés à la fragmentation ou à une hausse de concurrence.

Pour un modèle utilisant une attention à requêtes groupées, le cache KV peut être estimé ainsi :

cache KV = 2 × couches × jetons de contexte × têtes KV × dimension de tête × octets par valeur

Le facteur 2 représente les clés et les valeurs. Avec 32 couches, 8 têtes KV, une dimension de 128, 8 192 jetons et des valeurs sur 16 bits, le cache consomme environ 1 Gio par requête. Huit requêtes simultanées consomment alors près de 8 Gio avant même les poids et les espaces de travail. Un contexte maximal déclaré par le modèle n’est donc pas une capacité gratuite ; c’est une facture mémoire dont le montant est multiplié par la concurrence.

La mémoire vidéo, ou VRAM (Video Random Access Memory), doit contenir idéalement tous les poids et le cache KV. Déporter une partie des couches vers la mémoire vive, ou RAM (Random Access Memory), permet de démarrer un modèle trop gros, mais la liaison entre processeur et carte graphique devient un frein. La liaison PCI Express n’a pas la bande passante de la mémoire vidéo. Ce montage sert au dépannage ou au prototypage, pas à promettre un temps de réponse régulier.

Règle de décision : partir de la taille mesurée du fichier quantifié, ajouter le cache KV au contexte cible multiplié par la concurrence cible, puis ajouter 25 % de marge. Si ce total dépasse la VRAM, changer de quantification, réduire le contexte ou choisir davantage de VRAM. Ne pas acheter en espérant que le moteur « optimisera ». Il optimisera surtout l’heure à laquelle l’erreur de mémoire apparaîtra.

Choisir entre poste GPU, serveur multi-GPU et CPU

Section intitulée « Choisir entre poste GPU, serveur multi-GPU et CPU »

Le poste individuel équipé d’un GPU (Graphics Processing Unit), ou processeur graphique, est le meilleur choix pour un ingénieur, un analyste ou une équipe réduite qui utilise un modèle interactif. Une carte disposant de 24 Gio de VRAM accueille confortablement un modèle de 7 à 14 milliards de paramètres en quantification 4 bits, avec un contexte raisonnable et une marge pour les outils locaux. La latence de génération est bonne, l’administration reste légère et les données ne quittent pas le poste.

Cette option ne fournit pas un service mutualisé. Une carte grand public supporte mal une file d’attente permanente, une ventilation confinée, les mises à jour sans interruption et la concurrence imprévisible. Elle ne possède généralement pas de mémoire à correction d’erreur, ou ECC (Error-Correcting Code). Pour un poste, le compromis est acceptable. Pour un service métier, une erreur mémoire silencieuse et une absence de supervision ne deviennent pas respectables parce que la carte a un éclairage RGB.

Un serveur dédié à plusieurs GPU cible un service partagé, des modèles plus grands ou une exigence de débit élevée. Prévoir des GPU de même génération et de même capacité mémoire. Répartir un modèle sur plusieurs cartes ajoute un coût de communication ; la somme des VRAM n’équivaut pas mécaniquement à une carte unique de capacité égale. L’interconnexion, la topologie PCI Express, les numéros NUMA (Non-Uniform Memory Access) et la bande passante entre cartes déterminent le résultat. Sur un serveur à quatre GPU, vérifier que chaque carte dispose des lignes PCI Express prévues et qu’aucun emplacement ne partage silencieusement sa bande passante avec un contrôleur de stockage. Le serveur qui vend quatre accélérateurs mais n’alimente pas leurs voies est une créature fréquente dans les catalogues, avec des oreilles de lapin et une fiche technique.

Pour un modèle de 70 milliards de paramètres quantifié à 4 bits, compter typiquement 38 à 45 Gio pour les poids réels selon le format, puis le cache KV et la marge. Une seule carte de 48 Gio est souvent trop juste pour un service concurrent. Deux cartes de 48 Gio ou quatre cartes de 24 Gio peuvent charger le modèle, mais le débit dépendra fortement du partitionnement et de l’interconnexion. En production, préférer deux GPU à forte capacité plutôt que quatre petites cartes si le budget le permet : moins de synchronisation, moins de pilotes, moins de chemins de panne.

L’inférence sur CPU (Central Processing Unit), ou processeur central, reste valable pour un budget contraint, un traitement différé ou un faible volume. Elle exige surtout de la RAM rapide et abondante. Prévoir la taille du modèle, le cache KV, 20 % de marge, puis la mémoire du système et des services adjacents. Pour un modèle quantifié occupant 8 Gio, 32 Gio de RAM constituent un plancher pragmatique ; 64 Gio évitent de négocier chaque contexte avec le système. La génération sera sensiblement plus lente qu’avec un GPU, car l’inférence dépend fortement de la bande passante mémoire.

Le CPU convient aux tâches asynchrones : extraction, classification, résumés nocturnes ou enrichissement documentaire. Il ne convient pas à une interface conversationnelle partagée qui doit répondre vite. Réduire le modèle et le contexte est plus honnête que vendre une attente de trente secondes comme une réflexion profonde de la machine.

Valider le débit avec des requêtes concurrentes

Section intitulée « Valider le débit avec des requêtes concurrentes »

Le débit se mesure en jetons par seconde, mais séparer deux phases est indispensable. Le préremplissage lit l’invite entière et produit le cache KV ; la génération produit les jetons de sortie un par un. Une machine peut absorber rapidement une courte question puis s’effondrer sur des documents longs ou plusieurs conversations simultanées.

Fixer avant test les paramètres mesurés : modèle et quantification, longueur d’invite, longueur maximale de sortie, contexte maximal, nombre de requêtes parallèles, température et version du moteur. Sans ces valeurs, comparer deux benchmarks revient à comparer deux thermomètres posés dans des pièces différentes.

Exemple de charge Ollama reproductible

Section intitulée « Exemple de charge Ollama reproductible »

L’exemple suivant lance huit requêtes simultanées vers une instance Ollama locale, puis affiche l’utilisation GPU. Le modèle doit être téléchargé avant l’essai et le nom doit correspondre à un modèle disponible localement.

Fenêtre de terminal
# Télécharger le modèle quantifié choisi avant le test.
ollama pull llama3.1:8b


# Créer une invite de taille stable pour comparer les essais.
printf '%s\n' \
  'Résumer les risques d une rotation de secret absente en cinq points.' \
  > prompt.txt


# Lancer 8 requêtes en parallèle et enregistrer leur durée totale.
seq 1 8 | xargs -n1 -P8 -I{} sh -c '
  /usr/bin/time -f "requete={} duree=%e s" \
  curl --silent --show-error http://127.0.0.1:11434/api/generate \
    -H "Content-Type: application/json" \
    -d "{\"model\":\"llama3.1:8b\",\"prompt\":\"$(cat prompt.txt)\",\"stream\":false}" \
    > "resultat-{}.json"
'


# Observer mémoire, puissance et taux d utilisation du GPU pendant le test.
nvidia-smi --query-gpu=timestamp,memory.used,memory.total,utilization.gpu,power.draw \
  --format=csv -l 1

Mesurer aussi le nombre de jetons générés, exposé dans la réponse du moteur selon sa version, pour calculer le débit global. Augmenter la concurrence progressivement : 1, 2, 4, 8, puis 16 requêtes. Le seuil où la latence augmente brutalement révèle la capacité utile, pas la valeur flatteuse obtenue avec une seule requête courte.

Un GPU à 95 % d’utilisation avec une VRAM stable indique un plafond de calcul. Une VRAM saturée, des erreurs d’allocation ou une latence erratique indiquent un plafond mémoire. Une faible utilisation GPU combinée à une activité CPU élevée et à des transferts importants suggère un déport RAM ou une préparation d’invites coûteuse. En multi-GPU, une utilisation déséquilibrée peut révéler une topologie PCI Express défavorable ou une répartition de couches inefficace.

Exploitation, sécurité et limites de l’inférence locale

Section intitulée « Exploitation, sécurité et limites de l’inférence locale »

Le matériel local ne garantit ni confidentialité complète ni contrôle d’accès. Un modèle peut mémoriser une invite dans des journaux, une mémoire de processus, des fichiers temporaires ou l’historique applicatif. Le chiffrement du disque ne protège pas un processus déjà exécuté sous un compte compromis. Isoler le service, limiter les accès au point d’API (Application Programming Interface), authentifier les appelants et désactiver les journaux de requêtes contenant des données sensibles restent nécessaires.

Les modèles téléchargés sont des dépendances logicielles. Épingler les versions, vérifier l’origine et l’empreinte des artefacts, scanner les images de conteneurs et interdire le téléchargement automatique depuis un service de production. Un fichier de modèle n’est pas un exécutable au sens classique, mais la chaîne qui le charge, les extensions et les scripts associés méritent la même méfiance. La gouvernance des données s’applique aux invites comme aux documents indexés.

Prévoir la rotation des jetons d’accès au registre de modèles, des clés d’API et des certificats du frontal. Stocker ces secrets hors des variables visibles dans les interfaces d’administration et limiter leur lecture au compte de service. Sauvegarder les manifestes de modèles, les fichiers de configuration, les mesures de référence et les politiques de rétention, pas seulement les poids massifs. Les poids peuvent être retéléchargés ; une configuration de débit, de contexte et de filtrage perdue recrée des incidents avec une régularité presque artistique.

Surveiller la température, la consommation, les erreurs ECC lorsqu’elles existent, la VRAM, la RAM, la saturation disque, la latence par phase et la longueur des files d’attente. Définir une dégradation : refuser les requêtes longues, réduire la concurrence ou basculer vers un modèle plus petit. L’inférence locale ne garantit pas la qualité des réponses, l’absence d’hallucination, la protection contre les injections d’invite ni l’autorisation d’accéder aux données. Pour une base documentaire, séparer strictement les droits de recherche et consulter les contraintes propres aux embeddings et à la recherche sémantique.

🐝 Ce qui arrive si on s’en passe

Section intitulée « 🐝 Ce qui arrive si on s’en passe »

Sans dimensionnement chiffré ni mesure de référence, aucune valeur normale n’existe pour comparer un ralentissement : une saturation devient indiscernable d’une panne, et l’origine (contexte trop long, concurrence, déport vers la RAM) reste invisible faute de seuil connu. Le coût mémoire par requête n’étant pas borné, la longueur d’invite acceptée devient un levier d’épuisement de VRAM utilisable par tout appelant du point d’API, sans exploitation d’une faille logicielle. Les échecs d’allocation surviennent alors de façon intermittente, donc difficiles à reproduire et à tracer. L’absence de mesures archivées empêche aussi de détecter une régression de débit après un changement de quantification, de moteur ou de pilote, et prive la reprise de tout objectif de capacité vérifiable.

🦫 Explication de la marmotte 🍫

Section intitulée « 🦫 Explication de la marmotte 🍫 »

Un modèle de langage contient un très grand nombre de valeurs numériques. Avant d’acheter une machine, il faut mesurer l’espace occupé par ces valeurs dans le format choisi. Réduire leur précision fait baisser cet espace, mais peut diminuer la qualité des réponses. Cette mémoire doit tenir sur la carte graphique ou, en l’absence de carte graphique, dans la mémoire principale de la machine.

Le modèle conserve aussi des informations sur le texte déjà lu pendant une conversation. Plus le texte est long, plus cette mémoire augmente. Si plusieurs personnes posent des questions en même temps, chaque conversation consomme sa propre part. Il faut donc additionner la taille du modèle, la mémoire des conversations, celle nécessaire aux calculs et une réserve pour éviter les pannes.

Une carte graphique convient à une personne ou à un petit groupe, car elle calcule vite. Plusieurs cartes dans un serveur permettent de servir davantage de demandes, mais leur coordination peut ralentir le résultat. Le processeur central coûte moins cher si la machine existe déjà, mais répond plus lentement.

Après installation, il faut envoyer plusieurs demandes en même temps et mesurer le temps de réponse. Si la mémoire est pleine, le service échoue ou ralentit fortement. Si la carte graphique travaille au maximum, il faut réduire la charge ou ajouter de la capacité. Il faut aussi protéger les demandes, les accès et les journaux, car exécuter le modèle localement ne rend pas automatiquement les données secrètes.

À lire aussi

Pages voisines

La citent

Dimensionner GPU et RAM pour un LLM local

Elle cite