Calculateur de VRAM

La vitesse est une estimation basée sur la bande passante pour un décodage en flux unique, pas un benchmark. Le traitement du prompt est limité par le calcul et se comporte différemment.

Comment lire la répartition en trois parties

Presque tous les débats sur Internet concernant la capacité mémoire reposent en réalité sur l'oubli de l'un des trois chiffres clés. La taille de téléchargement indiquée sur la fiche du modèle en est un. Les deux autres n'existent qu'une fois le modèle chargé et en cours de réponse, moment précis où le manque de mémoire devient critique.

Prenons Llama 3.1 8B en Q4_K_M avec un contexte de 8K, une requête à la fois, cache F16. C'est la configuration locale la plus courante qui soit, et voici chaque octet la composant :

weights  = 8.03e9 params x 4.85 bits / 8      = 4.87e9 bytes = 4.53 GB
kv       = 2 x 32 layers x 8 kv-heads x 128 dim
           x 8192 tokens x 2 bytes             = 1.07e9 bytes = 1.00 GB
overhead = 0.65 + 0.08 x (4.53 + 1.00)                        = 1.09 GB
                                                                -------
total                                                            6.63 GB

Les poids sont la seule partie que vous pouvez consulter. Il s'agit d'arithmétique pure : nombre de paramètres multiplié par les bits par poids, divisé par huit. Rien dans votre charge de travail ne les modifie. Si vous ne touchiez jamais aux deux autres nombres, vous concluriez qu'un modèle 8B à 4 bits nécessite 4,5 Go et tient confortablement sur une carte de 6 Go. Ce n'est pas le cas.

Le KV cache est la partie dynamique. Chaque token dans le contexte possède un vecteur clé et valeur stocké pour chaque couche, afin que le modèle puisse se référer au passé sans le recalculer. C'est ce qui rend la génération rapide, et c'est pourquoi le cache n'est pas optionnel. Il évolue linéairement avec le contexte, linéairement avec les requêtes simultanées, et il est déterminé par la structure de l'attention plutôt que par le nombre de paramètres. Ici, il coûte exactement 0,125 Go par 1024 tokens, ce qui est faible car Llama 3.1 utilise huit têtes clé-valeur pour trente-deux têtes de requête.

La surcharge d'exécution (runtime overhead) est la partie que personne ne budgétise et à laquelle tout le monde se heurte. Noyaux compilés, contexte CUDA ou Metal, tampons d'activation et de logit, l'allocateur qui ne peut pas compacter les blocs parfaitement, et le jeu de travail de l'échantillonneur. Ce calculateur le modélise comme une valeur fixe de 0,65 Go plus 8 pour cent du reste. C'est une approximation délibérée, mais la tendance est correcte : la surcharge ne disparaît pas sur les petits modèles et ne reste pas constante sur les grands.

Une note sur les unités, car cela cause une réelle confusion. Chaque Go sur cette page est calculé en divisant par 1024 à la puissance trois, il s'agit donc techniquement d'un gibioctet (GiB). C'est la même unité que celle rapportée par votre pilote GPU, c'est pourquoi une carte vendue pour 24 Go affiche environ 24564 MiB. Les fichiers de modèles sur Hugging Face sont généralement listés en gigaoctets décimaux, donc un téléchargement de 5,0 Go apparaît ici comme environ 4,65 Go. L'écart est d'environ 7 pour cent et joue en votre faveur, pas contre vous.

Choisir un niveau de quantification

La quantification stocke chaque poids avec moins de bits. Un modèle publié en BF16 utilise deux octets par paramètre ; une quantification 4 bits en utilise un peu plus d'un demi-octet. Rien d'autre ne change dans le modèle, c'est pourquoi la quantification est le levier le plus important dont vous disposez pour savoir si un modèle tiendra en mémoire.

Voici un modèle, Llama 3.3 70B, à chaque niveau proposé par ce calculateur. Les poids correspondent au fichier sur le disque ; les deux autres colonnes représentent l'empreinte mémoire totale chargée, incluant le cache et la surcharge, pour un flux unique avec un cache F16.

Trois points dans ce tableau méritent attention. Premièrement, le nombre de bits nominal est un mensonge en votre faveur et contre vous. Q4_K_M n'est pas à 4 bits par poids, mais à 4,85, car les formats K-quant conservent les tenseurs d'attention et d'embedding à une précision plus élevée là où les dommages sont les plus critiques. Q2_K atteint une moyenne de 3,35 bits pour la même raison. Si vous dimensionnez un modèle en multipliant les paramètres par quatre et en divisant par huit, vous sous-estimerez d'environ un cinquième.

Deuxièmement, les rendements diminuent fortement à mesure que l'on descend. Passer de BF16 à Q8_0 réduit le modèle de moitié sans coût mesurable. Passer de Q8_0 à Q4_K_M le réduit presque à nouveau pour une perte de qualité que la plupart des gens ne détectent pas en usage courant. Passer de Q4_K_M à Q3_K_M économise 7,8 Go et commence à se traduire par un moins bon suivi des instructions, un code plus faible et davantage d'erreurs arithmétiques. En dessous, vous sacrifiez la capacité au profit de l'espace de manière perceptible.

Troisièmement, les dommages causés par une quantification agressive ne sont pas répartis uniformément selon la taille des modèles. Un 70B en Q2_K reste utilisable, car il y a une énorme redondance à détruire. Un 3B en Q2_K produit fréquemment des sorties corrompues. La règle empirique qui survit à la pratique : préférez un modèle plus grand avec une quantification plus faible jusqu'à environ 4 bits, et préférez un modèle plus petit à 4 bits ou mieux en dessous. Un 70B en Q4_K_M surpasse un 32B en Q8_0 pour la plupart des tâches ; un 70B en IQ2_XXS ne le fait généralement pas.

Un cas particulier à connaître. Certains modèles sont publiés nativement dans un format à faible nombre de bits plutôt que quantifiés après coup. gpt-oss est distribué en MXFP4 à 4,25 bits par poids, et comme l'entraînement en a tenu compte, la qualité n'est pas comparable à une compression 4 bits d'une version BF16. C'est pourquoi le calculateur ne propose MXFP4 que pour les modèles qui sont réellement distribués ainsi, et pourquoi gpt-oss 120B occupe 63,4 Go au lieu des 250 Go qu'un modèle 117B nécessiterait en pleine précision.

Pourquoi la longueur du contexte est une décision matérielle

Les gens traitent la longueur du contexte comme un paramètre de fonctionnalité : la fiche du modèle indique 128K, donc on règle sur 128K. Ce n'est pas un paramètre, c'est une allocation mémoire, et sur certaines architectures, c'est la ligne la plus importante du budget. Voici quatre modèles en Q4_K_M, flux unique, cache F16, avec l'empreinte totale chargée pour quatre longueurs de contexte.

Llama 3.1 8B quadruple de taille entre 2K et 128K, passant de 5,8 Go à 22,8 Go, ce qui fait la différence entre tourner sur presque n'importe quoi et ne pas tenir sur une carte de 24 Go. Command R 35B est le cas extrême : il commence plus petit que Qwen3 32B à 2K et finit près de quatre fois plus grand à 128K, car il utilise une attention multi-têtes complète avec 64 têtes clé-valeur et consomme 1,25 Go de cache par 1024 tokens. Gemma 3 27B bouge à peine, car cinq de ses six couches ne portent leur attention que sur une fenêtre de 1024 tokens et cessent donc de croître presque immédiatement.

La conséquence pratique est que la longueur de contexte que vous configurez doit être celle que vous utilisez réellement, et non le maximum supporté par le modèle. Si vos prompts font 3000 tokens et vos réponses 800, régler sur 32K gaspille de la mémoire que vous auriez pu utiliser pour une meilleure quantification. Llama 3.1 8B en Q4_K_M sur une carte de 24 Go peut gérer un contexte de 64K, mais pas 128K, car 128K nécessite 22,8 Go et la carte ne laisse qu'environ 22,3 Go après la consommation de l'affichage et du pilote. Réduire le cache à Q8 vous permet d'y arriver. Rien d'autre ne doit changer.

Le runtime utilisé a également son importance. llama.cpp alloue le cache pour la taille de contexte que vous passez et rien de plus, donc un petit contexte libère réellement la mémoire. vLLM, au contraire, réserve une fraction de la carte dès le départ et gère un pool paginé en interne, donc nvidia-smi affichera la carte presque pleine, quel que soit votre réglage. Le chiffre donné par ce calculateur est le jeu de travail dont vous avez besoin, ce qui correspond directement au comportement de llama.cpp et au pool que vLLM doit être capable d'allouer.

Le cache est déterminé par l'architecture, pas par la taille

Le fait le plus utile concernant le KV cache est que le nombre de paramètres ne permet guère de le prédire. Ce qui le prédit, c'est le nombre de têtes clé-valeur conservées par le modèle, leur largeur, le nombre de couches, et s'il utilise des mécanismes avancés. Voici le coût du cache par 1024 tokens pour des modèles couvrant trois ordres de grandeur en nombre de paramètres.

Lisez les lignes du haut et du bas ensemble. Un modèle 671B a un cache plus petit qu'un 35B, et un modèle 3,8B a un cache quatre fois et demie plus grand qu'un 27B. Phi-3.5 mini avec un contexte complet de 128K nécessite 54,8 Go au total, dont seulement 2,2 Go pour les poids. C'est un modèle que les gens décrivent comme minuscule, nécessitant pourtant plus de mémoire qu'un 32B.

Quatre mécanismes expliquent tout le tableau. L'attention à requêtes groupées (GQA) partage une tête clé-valeur entre plusieurs têtes de requête, ce qui est devenu la norme industrielle et réduit généralement le cache de quatre à huit fois. L'attention à fenêtre glissante donne à la plupart des couches une fenêtre fixe, de sorte que leur cache cesse de croître au-delà, ce qui explique pourquoi Gemma 3 et gpt-oss se stabilisent. L'attention latente multi-têtes, utilisée par DeepSeek, compresse les clés et les valeurs en un seul vecteur de 576 éléments par token et par couche au lieu de les stocker intégralement. Et l'attention multi-têtes classique, encore utilisée par d'anciennes versions comme Command R et Phi-3.5, n'utilise aucun de ces mécanismes et paie pour chaque tête.

Si vous voulez la version longue de cet argument avec les dérivations, elle est rédigée séparément dans pourquoi le nombre de paramètres est un mauvais prédicteur de la VRAM.

Quand la quantification du KV cache en vaut la peine

Le cache peut être quantifié tout comme les poids. F16 utilise 2 octets par élément stocké ; l'option Q8 ici atteint une moyenne de 1,06 octets et Q4 une moyenne de 0,56, la surcharge provenant des échelles par bloc. Tous les runtimes sérieux le supportent : llama.cpp l'expose via cache-type-k et cache-type-v, vLLM via un flag kv-cache-dtype.

La question n'est jamais de savoir si cela économise de la mémoire. C'est de savoir si l'économie est suffisamment importante pour compter, et cela dépend entièrement de la part que représente le cache dans votre empreinte mémoire totale. Avec un contexte de 32K et des poids Q4_K_M :

Command R gagne 20,3 Go avec un seul flag, ce qui fait la différence entre avoir besoin de deux cartes de 48 Go ou d'une seule. Llama 3.3 70B gagne 5,1 Go avec le même flag, car le grouped-query attention rendait déjà son cache réduit. Le schéma est général : la quantification KV est transformative sur les modèles multi-head en contexte long, mais marginale sur les modèles grouped-query en contexte court. Vérifiez le segment cache KV dans la répartition ci-dessus avant de l'utiliser. Si cette barre est très fine, le flag ne vous sauvera pas.

Le coût est réel mais limité. Le cache Q8 est quasiment gratuit en termes de qualité et mérite d'être activé par défaut pour toute charge de travail à contexte long. Le cache Q4 dégrade précisément ce pour quoi le contexte long est conçu : le rappel précis de faits spécifiques enfouis dans l'entrée. Le résumé et le chat libre le tolèrent bien ; la recherche dans un long document, les recherches « aiguille dans une botte de foin » et le raisonnement sur plusieurs fichiers de code ne le supportent pas. Il existe aussi une asymétrie à connaître : les clés sont plus sensibles à la quantification que les valeurs. Si votre runtime permet de les configurer séparément, un cache de clés Q8 avec un cache de valeurs Q4 est généralement préférable à un Q4 pour les deux.

Une règle qui ne vous trompera pas : quantifiez d'abord les poids, ensuite le cache. Des poids Q4_K_M avec un cache F16 surpassent des poids Q6_K avec un cache Q4 à taille totale égale, dans presque tous les cas, car la quantification des poids a été étudiée et optimisée bien plus en profondeur que celle du cache.

Deux cartes de 24 Go ne valent pas une carte de 48 Go

Répartir un modèle sur plusieurs GPU fonctionne, et pour les grands modèles, c'est la seule option abordable. Mais l'arithmétique n'est pas une simple addition, et la différence apparaît à deux niveaux : la capacité utilisable et la vitesse de décodage.

En termes de capacité, une carte unique perd une partie de son espace à cause du pilote, de la sortie d'affichage et de la fragmentation de l'allocateur. Ce calculateur suppose qu'environ 93 % est utilisable sur une carte grand public et 95 % sur une carte station de travail ou datacenter sans affichage. Une configuration multi-cartes perd davantage, environ 90 %, car chaque carte gère son propre contexte d'exécution et sa propre copie des tampons d'activation, et parce que la répartition des couches ne se divise presque jamais équitablement. Deux RTX 4090 offrent donc environ 43,2 Go d'espace de travail, là où une seule RTX 6000 Ada avec les mêmes 48 Go nominaux en offre 45,6 Go.

Cet écart de 2,4 Go est déterminant dans des cas réels. Llama 3.3 70B en Q4_K_M avec un contexte de 8K nécessite 46,4 Go, donc il ne tient sur aucune des deux. Passer le cache en Q8 le ramène à 45,1 Go, ce qui tient sur la carte unique de 48 Go mais toujours pas sur la paire. Pour le faire tenir sur deux 4090, vous devez aussi passer à des poids Q4_0, à 42,5 Go. Même mémoire nominale, deux compromis supplémentaires.

Sur la vitesse, on s'attend généralement à ce que deux cartes soient deux fois plus rapides. Pour le décodage en flux unique, ce n'est pas le cas, et elles sont souvent plus lentes qu'une seule carte si le modèle y tient. La répartition par défaut dans llama.cpp et la plupart des configurations mono-nœud est le pipeline parallelism : les couches 0 à 39 sont sur la première carte, 40 à 79 sur la seconde. La génération d'un token parcourt les quatre-vingts couches dans l'ordre, donc un seul GPU travaille à un instant T tandis que l'autre attend, avec en plus un transfert d'état caché via PCIe à la frontière. Vous avez acheté de la capacité, pas du débit. Ce calculateur modélise cela par une baisse de l'efficacité de la bande passante, passant de 0,75 sur une carte unique à 0,6 sur une configuration divisée, ce qui place deux RTX 4090 à environ 13 tokens par seconde sur un modèle 70B, contre environ 16 pour une seule RTX 6000 Ada, malgré une bande passante brute plus élevée par carte pour la paire.

Le tensor parallelism, utilisé par vLLM et TensorRT-LLM, est l'alternative : chaque couche est découpée sur toutes les cartes qui travaillent simultanément. Cela améliore réellement la vitesse de décodage, mais nécessite un all-reduce entre les cartes à chaque couche, donc il faut du NVLink ou au moins des lignes PCIe x16 complètes vers chaque carte. Sur une carte mère grand public faisant tourner la seconde carte en x4, le tensor parallelism peut être plus lent que le pipeline parallelism. Il exige aussi que le nombre de têtes d'attention soit divisible par le nombre de cartes, ce qui rend les configurations à trois cartes peu pratiques.

En résumé : ajoutez des cartes pour faire tenir un modèle que vous ne pourriez pas exécuter autrement, pas pour accélérer un modèle qui tourne déjà. Si vous hésitez entre une grosse carte et deux petites au même prix, la carte unique l'emporte sur la simplicité, la consommation électrique, la capacité utilisable et la latence en flux unique. Les cartes multiples sont avantageuses lorsque vous servez des requêtes concurrentes, où le batching occupe chaque carte.

Que se passe-t-il lors d'un déchargement vers la RAM système

Si un modèle ne tient pas, llama.cpp et Ollama garderont volontiers certaines couches dans la RAM système pour les exécuter sur le CPU. Ça fonctionne. C'est aussi le moment où les utilisateurs pensent que leur matériel est en panne, car la vitesse ne se dégrade pas progressivement.

La raison est que le décodage est limité par la bande passante mémoire, pas par le calcul. Pour produire un token, le runtime lit chaque poids actif et tout le cache une fois. Pour Llama 3.3 70B en Q4_K_M avec un contexte de 8K, cela représente environ 45,5 Go de lecture par token. Divisez cela par la bande passante de la mémoire utilisée et vous obtenez votre plafond avant même que le calcul ne commence.

Une RTX 4090 lit à 1008 Go/s. La DDR5 dual-channel d'un PC de bureau classique lit à environ 90 Go/s. C'est une différence de onze fois, et tout est là. Si le modèle 70B tenait entièrement dans la 4090, il décoderait à environ 17 tokens par seconde. Il ne tient pas : 22,3 Go sur 46,4 Go sont résidents, donc 52 % de chaque lecture de token provient de la RAM système à un neuvième de la vitesse. Le résultat est d'environ 2,6 tokens par seconde. Vous avez gardé 48 % du modèle sur le périphérique rapide et perdu 84 % de la vitesse.

Le même schéma s'applique à toutes les échelles. Llama 3.1 8B lit 5,9 Go par token ; sur une 4090, cela donne environ 127 tokens par seconde, et entièrement sur CPU avec 90 Go/s de RAM, environ 11. Qwen3 32B en Q4_K_M nécessite 22,8 Go, donc sur une RTX 5080 de 16 Go, environ 65 {}este résident et l'estimation chute d'environ 33 tokens par seconde à environ 8.

Deux détails rendent l'expérience réelle pire que ce que ces chiffres suggèrent. Le traitement du prompt sur les couches CPU est limité par le calcul plutôt que par la bande passante, donc un long prompt peut prendre des minutes avant que le premier token n'apparaisse, même si le taux de streaming semble ensuite tolérable. Et le déchargement n'est pas gratuit côté GPU, car le runtime a toujours besoin de tampons de travail pour les couches qu'il héberge.

Quand le déchargement est une bonne option : tâches par lots pour lesquelles vous n'êtes pas pressé, modèles où quelques tokens par seconde suffisent, et cas où seules quelques couches débordent. Décharger 10 % coûte beaucoup moins cher que 50 %. Quand c'est une mauvaise option : tout ce qui est interactif. Un modèle plus petit avec une bonne quantification sera presque toujours préférable à un modèle plus grand qui rampe à travers vos DIMMs. Si vous avez besoin des capacités du modèle plus grand, l'appeler via une API est plus rapide et moins cher que de faire semblant avec votre PC de bureau.

Apple Silicon et mémoire unifiée

Apple Silicon n'a pas de VRAM séparée. Le CPU et le GPU partagent un pool de LPDDR sur le même package, ce qui signifie qu'un Mac avec 128 Go de mémoire peut charger un modèle qu'aucun GPU grand public sur le marché ne peut contenir. C'est un avantage réel, et c'est pourquoi les Mac sont courants dans les cercles d'inférence locale. Cela s'accompagne de deux nuances que les gens découvrent tardivement.

La première est que vous n'en disposez pas en totalité. macOS réserve de la mémoire pour tout le reste et limite ce que le GPU peut verrouiller ; ce calculateur suppose qu'environ 75 % est disponible pour un modèle, donc 128 Go de mémoire unifiée deviennent environ 96 Go de budget, et un Mac mini de 16 Go devient environ 12 Go. La limite peut être augmentée avec le réglage iogpu wired limit, mais s'approcher du total physique risque de provoquer du swapping système, et swapper un modèle est pire que de ne pas le charger.

La seconde est la bande passante. La mémoire unifiée est large, mais pas autant que la GDDR. Un M4 Max lit à environ 546 Go/s contre 1008 Go/s sur une RTX 4090 et 1792 Go/s sur une RTX 5090. Le M4 de base dans un Mac mini lit à environ 120 Go/s, soit un tiers de ce qu'une RTX 3060 vieille de cinq ans gère. Sur Llama 3.1 8B en Q4_K_M, cela donne environ 60 tokens par seconde sur un M4 Max, environ 13 sur un Mac mini M4 de base, et environ 45 sur la RTX 3060. Capacité et vitesse sont des achats séparés, et Apple vend beaucoup de la première par dollar et relativement peu de la seconde.

Le traitement du prompt est le point le plus critique. Le décodage est limité par la bande passante, où Apple est simplement en retard ; le prefill est limité par le calcul, où l'écart avec une carte NVIDIA moderne dotée de cœurs tensor dédiés est beaucoup plus large. Un document de 30 000 tokens collé dans un chat sur un Mac peut rester figé un moment avant que le streaming ne commence, même si le streaming lui-même semble ensuite correct. Si votre charge de travail consiste en de longs prompts et des réponses courtes, c'est le chiffre à tester avant d'acheter.

Là où le Mac gagne haut la main, c'est dans la gamme intermédiaire que les cartes discrètes ne peuvent atteindre à un prix raisonnable. Llama 3.3 70B en Q4_K_M tient confortablement dans un M4 Max de 128 Go à environ 8 tokens par seconde, et un M2 Ultra de 192 Go le fait tourner à environ 11 tout en pouvant contenir des modèles nécessitant bien plus de 100 Go. Y arriver avec du matériel NVIDIA signifie plusieurs cartes, une carte mère avec les lignes PCIe pour les alimenter, et une alimentation adaptée. Utilisez MLX plutôt qu'un backend générique quand vous le pouvez, car il est écrit pour ce modèle de mémoire et surpasse systématiquement les alternatives sur la même machine.

Servir plus d'une personne à la fois

Tout ce qui précède suppose une seule requête à la fois. Dès que vous placez le modèle derrière un endpoint utilisé par d'autres personnes, les poids restent partagés mais chaque requête concurrente transporte son propre cache KV. Cela transforme le cache d'un élément secondaire en coût dominant. Llama 3.1 8B en Q4_K_M avec un contexte de 8K, avec une concurrence croissante :

À seize utilisateurs concurrents, le cache est plus grand que le modèle. À trente-deux, un modèle 8B nécessite plus de mémoire qu'un 70B pour un seul utilisateur. C'est le chiffre qui surprend les équipes ayant prototypé sur un ordinateur portable et qui se demandaient pourquoi le serveur plantait avec huit personnes dessus.

L'avantage est que la concurrence permet de ne plus gaspiller les GPU. Le décodage en flux unique laisse la majeure partie de la puissance de calcul inactive car elle attend la mémoire ; le batching amortit une lecture de poids sur plusieurs séquences, donc le débit total augmente beaucoup plus vite que l'utilisation de la mémoire. C'est aussi là qu'un paged cache est utile, car vLLM alloue le cache par blocs au fur et à mesure que les séquences grandissent, plutôt que de réserver le pire des cas pour chaque slot. Si vous dimensionnez un serveur, dimensionnez pour le cache selon votre concurrence réelle et votre longueur de prompt médiane réelle, pas pour le contexte maximum multiplié par le nombre maximum d'utilisateurs.

Erreurs courantes lors du dimensionnement d'un GPU

Questions fréquemment posées

De combien de VRAM ai-je besoin pour exécuter un modèle 7B ou 8B ?

Environ 6.6 Go en Q4_K_M avec un contexte de 8K, ce qui tient sur une carte de 8 Go avec un peu de marge. En BF16, le même modèle nécessite 17.9 Go et requiert une carte de 24 Go. Si vous souhaitez utiliser le contexte complet de 128K, cela monte à 22.8 Go ; le contexte est donc tout aussi important que la précision ici.

Pourquoi mon modèle de 8 Go refuse-t-il de se charger sur une carte de 8 Go ?

Trois raisons se cumulent. Le pilote et le bureau occupent déjà environ 7 pour cent de la carte, le KV cache est alloué en plus des poids, et le runtime nécessite environ 0.65 Go d'espace de contexte et de noyau avant de commencer toute opération. La taille du fichier est la seule valeur qui n'inclut rien de tout cela.

Une carte de 24 Go peut-elle exécuter un modèle 70B ?

Pas uniquement dans la VRAM. Llama 3.3 70B nécessite 46.4 Go en Q4_K_M et 8K, et même en IQ2_XXS avec un contexte de 2K, il a encore besoin de 22.5 Go contre environ 22.3 Go disponibles. Vous pouvez décharger vers la RAM système et obtenir quelques tokens par seconde, ou exécuter un 32B à la place pour en obtenir trente.

Le Q4_K_M est-il vraiment suffisant ?

Pour presque tout, oui, et c'est le réglage par défaut pour une bonne raison. Il stocke 4.85 bits par poids au lieu de 4, conservant les tenseurs d'attention et d'embedding à une précision plus élevée. L'écart mesurable avec le Q8_0 est faible et l'économie de mémoire est proche de la moitié. Ne descendez en dessous que si l'alternative est de ne pas pouvoir exécuter le modèle du tout.

Un modèle plus grand à faible précision est-il meilleur qu'un plus petit à haute précision ?

Jusqu'à environ 4 bits, oui. Un 70B en Q4_K_M surpasse un 32B en Q8_0 sur la plupart des tâches pour une empreinte similaire. En dessous de 3 bits, l'ordre s'inverse pour les modèles de petite et moyenne taille, car il y a moins de redondance à sacrifier. Les très grands modèles tolèrent bien mieux les formats 2 bits que les petits.

Pourquoi le KV cache d'un modèle 3.8B est-il plus grand que celui d'un 27B ?

Parce que Phi-3.5 mini utilise une attention multi-têtes complète avec 32 têtes clé-valeur, à 0.375 Go par 1024 tokens, tandis que Gemma 3 27B applique une fenêtre glissante de 1024 tokens à cinq couches sur six. À 128K, cela représente 48 Go contre 10.4 Go. La taille du cache suit la structure de l'attention, pas le nombre de paramètres.

Dois-je quantifier le KV cache ?

Activez le Q8 dès que votre contexte est long ; c'est quasiment gratuit. N'utilisez le Q4 que lorsque le cache représente une part importante de votre empreinte mémoire et que votre charge de travail n'est pas intensive en rappel. Sur Command R 35B à 32K, le Q8 économise 20.3 Go. Sur Llama 3.3 70B au même contexte, il économise 5.1 Go, car le grouped-query attention a déjà effectué le travail.

Deux cartes de 24 Go équivalent-elles à une carte de 48 Go ?

Non. Vous obtenez environ 43.2 Go utilisables au lieu de 45.6, car chaque carte gère son propre contexte d'exécution et la répartition des couches est inégale. La vitesse en flux unique ne s'améliore pas non plus, car le parallélisme de pipeline signifie qu'une carte calcule pendant que l'autre attend. Deux cartes offrent de la capacité et, en cas de concurrence, du débit.

À quelle vitesse cela va-t-il réellement fonctionner ?

Divisez la bande passante mémoire par les octets lus par token. Llama 3.1 8B en Q4_K_M lit 5.9 Go par token, donc une RTX 4090 à 1008 Go/s atteint environ 127 tokens par seconde après les pertes d'efficacité. Cette estimation ne vaut que pour le décodage. Le traitement des prompts est limité par le calcul et suit une courbe différente.

Que se passe-t-il réellement si je décharge vers la RAM système ?

La vitesse chute brutalement plutôt que de diminuer progressivement. Llama 3.3 70B avec 48 pour cent de ses couches sur une RTX 4090 et le reste en DDR5 décode à environ 2.6 tokens par seconde au lieu des 17 qu'il atteindrait s'il était entièrement en VRAM. Un léger débordement est gérable ; la moitié du modèle ne l'est pas.

Un Mac est-il une bonne machine pour l'inférence locale ?

Pour la capacité par dollar, oui : un M4 Max avec 128 Go offre environ 96 Go de budget utilisable et exécute un 70B à environ 8 tokens par seconde. Pour la vitesse brute, non : 546 Go/s de bande passante contre 1792 sur une RTX 5090, et le traitement des prompts est encore plus lent. Achetez-en un pour les grands modèles et le fonctionnement silencieux, pas pour la latence.

Les modèles mixture-of-experts économisent-ils de la mémoire ?

Ils économisent du temps, pas de l'espace. Qwen3 30B-A3B nécessite toujours 20.1 Go car chaque expert doit être résident, mais il ne lit qu'environ 3.3B de paramètres par token, il décode donc plusieurs fois plus vite qu'un modèle dense 32B occupant la même empreinte. Jugez un modèle MoE par son total pour le chargement et par ses paramètres actifs pour la vitesse.

Le flash attention réduit-il la VRAM ?

Il supprime la grande matrice d'attention intermédiaire, ce qui constitue une réelle économie lors du prefill sur les prompts longs, et accélère le traitement des prompts. Il ne réduit pas le KV cache, qui est la partie qui croît avec votre contexte. Activez-le dans tous les cas ; ne vous attendez simplement pas à ce que les totaux sur cette page changent.

Pourquoi nvidia-smi indique-t-il que la carte est pleine alors que j'ai défini un petit contexte ?

Vous exécutez probablement vLLM, qui réserve une fraction fixe de la carte au démarrage et gère un pool de cache paginé en interne. llama.cpp n'alloue que ce dont le contexte demandé a besoin. Les chiffres ici décrivent le jeu de travail, ce que vLLM doit être capable d'allouer et ce que llama.cpp rapporte directement.

De combien de VRAM ai-je besoin pour fine-tuner plutôt que d'exécuter un modèle ?

Bien plus, et ce calculateur ne le modélise pas. Un fine-tuning complet conserve les poids, les gradients et l'état de l'optimiseur à environ 16 octets par paramètre, donc un modèle 8B atteint près de 130 Go avant les activations. QLoRA sur une base 4 bits est beaucoup plus proche de l'empreinte de l'inférence plus la mémoire d'activation, c'est pourquoi c'est la seule option réaliste sur une carte grand public unique.

Les modèles de vision changent-ils le calcul ?

L'encodeur de vision est inclus dans le nombre de paramètres des modèles multimodaux listés ici, le chiffre des poids est donc correct. Ce que les totaux ne prennent pas en compte, c'est que les images sont développées en un grand nombre de tokens avant d'atteindre le modèle de langage ; ainsi, quelques images haute résolution peuvent consommer plus de contexte, et donc plus de cache, qu'une page de texte.

Que faire si rien ne tient ?

Réduisez d'abord le contexte, car c'est généralement la concession la moins coûteuse, puis quantifiez le cache en Q8, et enfin réduisez les poids d'un niveau. Si vous manquez toujours d'espace, un modèle plus petit avec une quantification raisonnable est préférable à un modèle plus grand qui sature la RAM système. Ou appelez les mêmes modèles open-weight via l'API gratuite et laissez quelqu'un d'autre gérer le matériel.