Comment estimer la mémoire GPU dont a besoin un modèle de langage privé : les poids, la mémoire qu'ajoute chaque requête, le nombre de GPU que cela représente et ce que coûte leur location à l'heure.
Pour faire tourner un modèle d'IA générative (GenAI) sur vos propres serveurs, additionnez deux choses : les poids du modèle et la mémoire occupée par les requêtes auxquelles il répond au même moment. À la précision habituelle de 16 bits, les poids demandent environ 2 Go de mémoire GPU par milliard de paramètres, donc un modèle de 32,8 milliards de paramètres a besoin d'environ 66 Go avant de répondre à qui que ce soit. Chaque requête ajoute ensuite de la mémoire en proportion de sa longueur, et c'est cette partie qui décide du nombre de requêtes que le serveur peut traiter à la fois.
La réponse courte : un modèle d'environ 30 milliards de paramètres tient sur un GPU de centre de données doté de 80 à 94 Go de mémoire, avec de la place pour moins de dix longues requêtes à la fois. Des poids stockés sur 8 bits prennent deux fois moins de place et laissent de la place pour plus de deux fois plus de requêtes, mais testez d'abord leurs réponses sur vos propres questions. Avant d'acheter du matériel, louez des GPU pendant quelques jours et faites un test de charge à votre heure de pointe.
Un modèle de langage tourne généralement sur des GPU, des processeurs conçus pour le type de calcul que font les modèles, et le modèle doit se trouver dans la mémoire propre des GPU pendant qu'il travaille. Cette mémoire contient :
Les poids sont fixés dès que vous choisissez un modèle et une précision. Le cache KV grandit avec le nombre de requêtes traitées au même moment et avec leur longueur. Les deux peuvent se calculer avant tout achat.
La taille d'un modèle se compte en paramètres, et la précision est le nombre de bits utilisés pour stocker chacun d'eux. Le guide de Hugging Face pour faire tourner des modèles efficacement, consulté le 27 octobre 2026, note que « presque tous les modèles sont aujourd'hui entraînés en bfloat16 », un format sur 16 bits où chaque paramètre occupe 2 octets. Sa règle empirique : « charger les poids d'un modèle de X milliards de paramètres demande environ 2 * X Go de VRAM en précision bfloat16/float16 », la VRAM étant la mémoire du GPU.
L'exemple que donne le guide lui-même est Llama 2 70B, avec environ 140 Go pour les seuls poids. Qwen3-32B, un modèle à poids ouverts publié sous licence Apache 2.0, compte 32,8 milliards de paramètres selon sa fiche de modèle, ses poids occupent donc environ 66 Go. « Poids ouverts » signifie que le créateur publie les fichiers du modèle pour que chacun puisse le faire tourner.
La quantification stocke les poids sur moins de bits. Sur 8 bits, un paramètre occupe 1 octet, et sur 4 bits un demi-octet, donc le même modèle a besoin d'environ 33 Go ou d'un peu plus de 16 Go. L'équipe Qwen publie une version sur 8 bits, Qwen3-32B-FP8.
Le guide de Hugging Face indique que les poids « peuvent être quantifiés sur 8 ou 4 bits sans perte significative de performance ». Il avertit aussi que la quantification sur 4 bits « peut en pratique souvent donner des résultats différents » de ceux sur 8 ou 16 bits, et ajoute : « C'est à l'utilisateur de l'essayer. » Faites passer vos propres questions de test par toute version compressée avant de vous y fier.
Pendant que le modèle écrit une réponse, il garde des valeurs pour chaque token qu'il a déjà lu et écrit, afin de ne pas avoir à les recalculer à chaque nouveau mot. Un token est un morceau de mot. Ces valeurs gardées forment le cache KV, abréviation de key-value cache. Un billet de 2023 des créateurs de vLLM, un programme open source pour servir des modèles, note que ce cache « occupe jusqu'à 1,7 Go pour une seule séquence dans LLaMA-13B ».
Vous pouvez calculer la taille pour votre propre modèle à partir de ses paramètres publiés. Pour chaque token, le cache garde deux ensembles de nombres, les clés et les valeurs, pour chaque couche. Qwen3-32B a 64 couches et garde dans son cache 8 têtes d'attention de 128 nombres chacune, selon sa fiche de modèle et son fichier de configuration. À 2 octets par nombre, cela fait 2 × 64 × 8 × 128 × 2 octets, soit environ 262 Ko par token.
Une requête de 8 000 tokens, comme une longue question accompagnée de passages trouvés dans vos documents plus la réponse, occupe donc environ 2,1 Go jusqu'à ce que la réponse soit terminée. Le contexte natif complet du modèle, de 32 768 tokens, occupe environ 8,6 Go.
Comptez les requêtes traitées au même moment, pas les personnes qui ont un accès. Les collaborateurs qui utilisent un assistant passent l'essentiel de leur temps à lire des réponses et à taper des questions, alors qu'un système qui traite un stock de documents en retard peut occuper chaque GPU toute la nuit.
Les GPU de centre de données ont une quantité de mémoire fixe. Les pages de spécifications de Nvidia, consultées le même jour, indiquent 80 Go pour le H100 dans sa version SXM et 94 Go dans sa version NVL, 141 Go pour le H200 et 48 Go pour le L40S.
Le logiciel de service laisse libre une partie de chaque GPU. La documentation de vLLM décrit le réglage correspondant comme « la fraction de la mémoire GPU utilisée par l'exécuteur du modèle » et donne 0,92 comme valeur par défaut dans sa version actuelle. Sur un H100 NVL de 94 Go, cela fait environ 86 Go. Les poids de Qwen3-32B sur 16 bits en occupent environ 66 Go. Il reste à peu près 21 Go pour le cache KV et le reste de la mémoire de travail du logiciel, de quoi traiter moins de dix requêtes de 8 000 tokens au même moment.
Avec les poids sur 8 bits, il reste environ 54 Go, de quoi traiter environ 25 requêtes de ce type. Sur un H100 de 80 Go, les poids sur 16 bits laissent environ 8 Go, de la place pour moins de quatre.
Quand les poids ne tiennent pas sur un GPU, le modèle est réparti sur plusieurs GPU du même serveur. La documentation de vLLM indique que « si le modèle est trop grand pour un seul GPU mais tient sur un seul nœud doté de plusieurs GPU, il faut utiliser le parallélisme de tenseurs », son nom pour ce découpage. Un modèle de 70 milliards de paramètres en précision 16 bits ne tient pas sur un GPU de 94 Go, et sur deux d'entre eux il reste environ 33 Go pour les requêtes.
Ces chiffres vous disent si un modèle tient. La vitesse à laquelle il répond dépend des GPU, de la longueur des réponses et de la charge, et seul un test sur vos propres requêtes peut le montrer.
Louer d'abord est un moyen moins coûteux de savoir ce dont vous avez besoin. La liste de prix publique de Microsoft pour Azure, consultée le même jour, donne ces prix à l'usage pour des machines virtuelles Linux dans sa région East US :
Ce sont des prix catalogue pour un paiement à l'heure, et la capacité réservée se vend à d'autres conditions. Les prix changent : demandez des devis à plus d'un fournisseur pour la configuration vers laquelle pointent vos tests.
Des serveurs à vous ont du sens quand la charge est stable et que vous savez quel modèle vous ferez tourner, ou quand vos règles exigent que le matériel reste dans vos propres locaux. Le coût inclut alors les personnes qui maintiennent ces serveurs en marche, ce que traite l'article sur l'exploitation d'un système LLM sans équipe ML.
vLLM inclut une commande pour ce type de test, vllm bench serve. Elle peut indiquer des percentiles de « ttft » et de « tpot », le temps jusqu'au premier token et le temps par token de sortie. Décidez avant le test combien de temps vos équipes attendront les premiers mots d'une réponse, et jugez les résultats sur l'heure de pointe.
Votre équipe d'infrastructure peut exploiter les serveurs GPU si elle s'occupe déjà de ses propres serveurs, et le fournisseur de matériel ou de cloud peut aider pour les machines. Relier le modèle à vos documents, à l'authentification et aux droits d'accès, et tester ses réponses, revient à qui construit le système autour du modèle.
La société ou l'équipe que vous engagez doit vous montrer le calcul : quel modèle et quelle précision, combien de mémoire va aux poids et combien au cache KV, avec quelle charge le test a été fait et ce qu'il a mesuré. Demandez ces chiffres avant d'approuver un budget matériel.
Le seul projet de modèle de langage qu'amBrain décrit publiquement est le suivant : « Nous avons mené une intégration de LLM jusqu'en production dans le périmètre FinTech d'un client : extraction et normalisation d'avis non structurés de courtiers et de places de marché — opérations sur titres, changements d'instruments et de marges — en enregistrements structurés consommés par le système de trading. »
Cet article n'est pas une étude de cas et ne décrit aucun travail pour un client. La phrase citée ne dit pas quel modèle ce système utilise, sur quel matériel ni où il tourne. Les chiffres ci-dessus sont des calculs tirés de spécifications et de listes de prix publiées, et non des mesures de ce projet ni d'aucun autre travail d'amBrain.
Les entreprises, modèles et produits cités ici le sont d'après leurs pages publiées, et l'article n'affirme aucune relation entre amBrain et l'un d'eux. Il ne donne ni prix, ni délais, ni conditions d'amBrain.
amBrain développe des logiciels depuis 2019. Elle travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Sur la propriété, sa formule est : « Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables. » Si amBrain figure sur votre liste restreinte, demandez-lui le même calcul qu'à n'importe quelle autre société.
Apportez votre architecture actuelle et le mode de défaillance qui vous inquiète : nous les passerons en revue ensemble en une demi-heure.
Réserver un appel