Dimensionnement guide · 10 min de lecture # Quel format de quantification utiliser, en pratique. Une stack de serving demande un format de nombres avant toute autre chose, et la réponse fait varier votre facture mensuelle d’un facteur huit. Le format aux poids les plus légers n’est pas toujours celui qui donne le modèle le plus petit. En bref - **La règle empirique:** Les poids rétrécissent exactement selon le ratio indiqué dans le nom — BF16 / FP16 **2 B/param** · FP8 **1 B/param** · 4-bit (AWQ, GPTQ) **0.5 B/param**. Rien d’autre ne rétrécit. - **Ce que cela vaut:** Qwen 3 32B demande [NVIDIA A100 PCIe](https://gpuserver.io/fr/gpu/a100-80gb) à **$1,091** par mois à pleine précision, et [NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) à **$125** en 4-bit. Même modèle, même contexte. - **Le piège:** Le cache clef/valeur ne suit pas la baisse des poids. À 128k de contexte, un Llama 3.3 70B en 4 bits représente **53 %** de cache et seulement 47 % de poids. - **Où le 4 bits perd nettement:** Llama 3.1 8B à 128k demande **23.0 GB** en 4-bit contre **18.4 GB** en FP8 — plus de mémoire, pour une moins bonne qualité ## Commencez ici La majeure partie de cette page est du calcul, voici donc la conclusion en premier. Quatre questions déterminent le format, posées dans cet ordre parce que chacune peut à elle seule clore la discussion. **Le modèle tient-il déjà en pleine précision, avec de la place pour votre contexte ?** Faites-le tourner en BF16 et arrêtez de lire. La quantification est une façon d’acheter une machine plus petite, et vous en avez déjà acheté une qui fonctionne. Il n’y a aucune récompense à compresser un modèle qui tient déjà. **Votre contexte est court et votre modèle grand ?** C’est là que le 4 bits mérite sa réputation. Les poids dominent la mémoire, et les réduire au quart revient presque à réduire la machine au quart. **Votre contexte est long et votre modèle petit ?** Utilisez FP8, sur une carte qui le prend en charge. FP8 divise par deux le cache aussi bien que les poids, et au-delà d’une certaine longueur, c’est cette seconde division par deux qui compte — le tableau ci-dessous indique le point exact où il dépasse le 4 bits. **Servez-vous une seule personne sur une seule machine ?** GGUF via Ollama demande de loin le moins de travail, et le débit auquel vous renoncez est un débit qu’un lecteur unique n’allait de toute façon jamais utiliser. Tout ce qui suit explique pourquoi ces quatre réponses sont ce qu’elles sont, et vous donne les chiffres pour les vérifier sur votre propre modèle plutôt que sur le nôtre. Si vous n’avez pas encore déterminé de combien de mémoire votre modèle a besoin, ce calcul fait l’objet d’[un guide séparé](https://gpuserver.io/fr/guides/vram-sizing), à consulter en premier. ## Trois formats, quatre noms Il n’existe que trois formats numériques d’usage courant pour le service, et ils ne diffèrent que par une chose : le nombre d’octets que coûte chaque paramètre. Tout le reste — AWQ, GPTQ, GGUF, bitsandbytes — est une méthode pour produire l’un de ces trois formats, pas un quatrième. **Les trois formats numériques, et ce à quoi s’applique chaque chiffre en octets** | Format | Octets par poids | Octets par élément de cache | À quoi ça sert | |---|---|---|---| | BF16 / FP16 Les poids tels que publiés | 2 | 2 | Qualité de référence | | FP8 Produit par la stack de serving elle-même | 1 | 1 | Proche de la référence, Hopper et Blackwell | | 4-bit (AWQ, GPTQ) Un checkpoint préparé à l’avance | 0.5 | 2 | Poids minimaux, cache toujours en FP16 | Lisez les deux colonnes numériques comme une paire. Elles sont égales sur les deux premières lignes et elles ne sont *pas* égales sur la troisième, et cette seule asymétrie explique la plupart des surprises plus loin sur cette page. Les quatre noms que vous rencontrerez réellement dans un dépôt de modèle correspondent à ce tableau comme suit. ### AWQ et GPTQ Deux voies vers la même destination en 4 bits. AWQ détermine quels poids comptent en observant les activations et les protège ; GPTQ compresse couche par couche et corrige l’erreur au fur et à mesure. Les deux produisent un checkpoint que vLLM et SGLang chargent directement, et sur un modèle donné, l’écart entre eux est plus petit que l’écart entre l’un ou l’autre et le 16 bits. ### GGUF La famille llama.cpp, ce qu’Ollama utilise en interne. C’est un conteneur plutôt qu’une méthode unique : un seul fichier contient les poids à l’une ou l’autre d’une douzaine de précisions, et il déborde les couches vers la RAM système quand la carte est trop petite. Imbattable pour un utilisateur sur une machine, et le plus faible des trois en concurrence réelle. ### FP8 Moins un format de checkpoint qu’un mode. Donnez à une stack de serving des poids en 16 bits, et elle les convertira en FP8 au chargement, sans téléchargement séparé ni passe de calibration. C’est le seul des quatre qui puisse aussi compresser le cache, ce qui explique pourquoi il apparaît plus loin là où on ne l’attend pas. ### BF16 et FP16 Les poids tels que les auteurs les ont publiés, et la référence à laquelle chaque autre ligne est comparée. Deux octets par paramètre, aucun jeu de calibration, aucun support de kernel à vérifier, aucun débat de qualité à avoir. Quand cela tient, c’est la bonne réponse et le reste de cette page est une distraction. Demander chacun d’eux se résume à un flag. Ce sont les mêmes options que celles que le [guide vLLM](https://gpuserver.io/fr/guides/serve-llama-70b) détaille longuement ; le propos ici est seulement de montrer à quel point la différence entre elles est mince. Le même serveur, de quatre façons ``` # 1. Reference. The weights as published, nothing to prepare. $ vllm serve meta-llama/Llama-3.3-70B-Instruct --dtype bfloat16 # 2. FP8, quantised while it loads. No second download, no calibration. # --kv-cache-dtype is the half everyone forgets: it is what # halves the CACHE as well as the weights. $ vllm serve meta-llama/Llama-3.3-70B-Instruct \ --quantization fp8 --kv-cache-dtype fp8 # 3. Four-bit AWQ. A DIFFERENT checkpoint, prepared by someone else. $ vllm serve casperhansen/llama-3.3-70b-instruct-awq \ --quantization awq_marlin # 4. Four-bit GPTQ. Same idea, different repository and flag. $ vllm serve TechxGenus/Llama-3.3-70B-Instruct-GPTQ \ --quantization gptq_marlin ``` ## La moitié qui ne rétrécit pas Quantifier les poids en 4 bits ne quantifie pas le cache clef/valeur. AWQ et GPTQ compressent les poids, et seulement les poids ; le cache reste en 16 bits sauf si vous demandez séparément un cache FP8, ce que la plupart des gens ne font jamais sur un checkpoint 4 bits. C’est la troisième colonne du tableau ci-dessus, et c’est la raison pour laquelle le calcul ci-dessous ne se déroule pas comme on pourrait s’y attendre. La conséquence se voit le plus facilement sur un seul modèle. Voici Llama 3.3 70B, en 4 bits, à chaque longueur de contexte que propose le [configurateur](https://gpuserver.io/fr/configure) — poids contre cache. **Poids et cache d’un modèle 70B en 4 bits, par longueur de contexte** | Contexte | Poids | Cache clef/valeur | Part de cache | |---|---|---|---| | 4k tokens | 35.0 GB | 1.3 GB | 3 % | | 8k tokens | 35.0 GB | 2.5 GB | 7 % | | 32k tokens | 35.0 GB | 10.0 GB | 22 % | | 128k tokens | 35.0 GB | 40.0 GB | 53 % | La colonne des poids ne bouge jamais — c’est tout l’intérêt de les quantifier. La colonne du cache croît linéairement avec le contexte jusqu’à ce que, sur la dernière ligne, elle dépasse le modèle auquel elle appartient. **À 128k, un Llama 3.3 70B en 4 bits représente 53 % de cache.** Vous avez quantifié les poids à un quart de leur taille et la machine dont vous avez besoin a à peine changé, parce que vous avez compressé la partie qui n’était plus le problème. Quiconque dimensionne un déploiement à long contexte à partir du seul chiffre des poids sous-commandera de plus de moitié. Poussez suffisamment loin, et le 4 bits cesse purement et simplement de gagner. FP8 divise par deux les deux moitiés ; le 4 bits divise par quatre une moitié et laisse l’autre intacte. Il existe donc, pour chaque modèle, une longueur de contexte où les deux se croisent, et elle survient d’autant plus tôt que le modèle est petit — car un petit modèle a peu de poids à économiser, pour la même croissance de cache par token. **Mémoire totale en FP8 face au 4 bits, par modèle et longueur de contexte** | Modèle | 4k | 8k | 32k | 128k | |---|---|---|---|---| | Llama 3.1 8B 8 Md de paramètres · 32 couches · 8 têtes KV | 5.24 bits, de 4.3 GB | 5.84 bits, de 4.0 GB | 9.24 bits, de 2.3 GB | 23.0FP8 l’emporte — 18.4 GB | | Qwen 3 32B 32 Md de paramètres · 64 couches · 8 têtes KV | 19.54 bits, de 17.8 GB | 20.74 bits, de 17.2 GB | 27.64 bits, de 13.8 GB | 55.2égalité parfaite | | Llama 3.3 70B 70 Md de paramètres · 80 couches · 8 têtes KV | 41.74 bits, de 39.5 GB | 43.14 bits, de 38.8 GB | 51.74 bits, de 34.5 GB | 86.34 bits, de 17.2 GB | Chiffres en gigaoctets, pour le plus léger des deux formats, avec le perdant indiqué en dessous. Lisez de gauche à droite et observez l’avantage de la colonne 4 bits s’amenuiser à mesure que le contexte grandit. La dernière ligne garde son avance partout, car 70 milliards de paramètres représentent un poids considérable à économiser. La ligne du milieu se termine à égalité parfaite : à 128k, Qwen 3 32B coûte exactement le même prix dans les deux formats, et vous choisiriez le FP8 pour la qualité. Et la première ligne s’inverse complètement at 128k, où le 4 bits demande *plus* de mémoire que le FP8 tout en étant le moins fidèle des deux. Cette combinaison — plus de mémoire et une sortie moins bonne — est l’erreur de quantification la plus courante que nous observons, et elle est invisible si vous ne regardez jamais que la taille du fichier de poids. ## Ce que votre carte peut réellement faire FP8 est d’abord une fonctionnalité matérielle avant d’être logicielle. Une carte dont les tensor cores ne le prennent pas en charge chargera quand même un checkpoint FP8 — la stack déballe les poids en 16 bits avant la multiplication — mais vous ne conservez que le gain sur le téléchargement, sans aucun gain de vitesse, et un cache FP8 ne vous est pas du tout accessible. Le 4 bits, c’est l’inverse : il fonctionne partout, car les poids sont de toute façon déballés en 16 bits avant le calcul. **Cartes du catalogue par génération, et leur prise en charge de FP8** | Génération | Cartes que nous louons | FP8 | |---|---|---| | Ampere | NVIDIA RTX A6000 48GB, NVIDIA A100 PCIe 40GB, NVIDIA A100 PCIe 80GB, NVIDIA A100 SXM4 80GB | Aucune en matériel — déballé en 16 bits | | Ada Lovelace | NVIDIA L4 24GB, NVIDIA RTX 4090 24GB, NVIDIA L40S 48GB | Dans les tensor cores — poids et cache | | Hopper | NVIDIA H100 PCIe 80GB, NVIDIA H100 SXM5 80GB, NVIDIA H200 SXM5 141GB | Dans les tensor cores — poids et cache | | Blackwell | NVIDIA RTX 5090 32GB, NVIDIA B200 SXM6 180GB | Dans les tensor cores — poids et cache | Cette colonne décrit le silicium, ce qui n’est pas tout à fait la même question que celle de savoir où le FP8 est une bonne idée. La note du catalogue elle-même, en regard du format, nomme Hopper and Blackwell, et c’est une remarque qui porte sur les piles de service plutôt que sur les cœurs tensoriels : ce sont les générations sur lesquelles les kernels FP8 et les caches FP8 ont eu le plus d’usage et le moins de surprises. Ada Lovelace le fera tourner. Hopper et Blackwell sont là où nous placerions un déploiement qui en dépend. **Sur une carte Ampere, FP8 n’est qu’une économie de téléchargement, rien de plus.** Les NVIDIA RTX A6000, NVIDIA A100 PCIe et NVIDIA A100 SXM4 n’ont pas de voie FP8 dans leurs cœurs tensoriels. Si votre plan était de réduire le cache de moitié sur l’une d’elles, cela n’arrivera pas — et les chiffres de mémoire de la colonne FP8 ci-dessus ne sont pas des chiffres que vous pouvez atteindre sur ce matériel. Choisissez la carte et le format ensemble, dans cet ordre. Encore une chose à savoir avant de choisir une carte. Llama 3.3 70B en FP8 à 8k nécessite 81.9 GB, et une carte de 80 GB — entre autres la NVIDIA A100 PCIe — en manque de 1.9 GB. Pas assez pour sauter aux yeux sur un tableur, mais largement assez pour échouer sur la machine. La carte qui s’en sort seule est celle du niveau au-dessus, et le [configurateur](https://gpuserver.io/fr/configure) vous dira laquelle avant de payer plutôt qu’après. ## Ce que cela apporte en vitesse Générer un token signifie lire une fois les poids actifs en mémoire. Moins d’octets par poids signifie moins d’octets à lire, ce qui signifie plus de tokens par seconde — et sur un flux unique sans traitement par lots, cette relation est quasiment linéaire, car la carte n’a rien d’autre à attendre. C’est le même plafond de bande passante mémoire que divise le [guide du coût par token](https://gpuserver.io/fr/guides/api-vs-self-hosting), et il est délibérément prudent. Ci-dessous, il est appliqué à un modèle assez petit pour tourner sur chaque machine à une seule carte que nous louons, afin que le format et la carte puissent être lus sur le même tableau. **Débit de génération en flux unique pour un modèle 8B, par carte et par format** | Carte | Bande passante | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) | |---|---|---|---|---| | NVIDIA L4 24 GB · $125 par mois | 300 GB/s | ~ 8 tok/s | ~ 17 tok/s | ~ 34 tok/s | | NVIDIA RTX A6000 48 GB · $286 par mois | 768 GB/s | ~ 22 tok/s | ~ 43 tok/s | ~ 86 tok/s | | NVIDIA L40S 48 GB · $714 par mois | 864 GB/s | ~ 24 tok/s | ~ 49 tok/s | ~ 97 tok/s | | NVIDIA RTX 4090 24 GB · $193 par mois | 1008 GB/s | ~ 28 tok/s | ~ 57 tok/s | ~ 113 tok/s | | NVIDIA A100 PCIe 40 GB · $392 par mois | 1555 GB/s | ~ 44 tok/s | ~ 87 tok/s | ~ 175 tok/s | | NVIDIA RTX 5090 32 GB · $335 par mois | 1792 GB/s | ~ 50 tok/s | ~ 101 tok/s | ~ 202 tok/s | | NVIDIA A100 PCIe 80 GB · $1,091 par mois | 1935 GB/s | ~ 54 tok/s | ~ 109 tok/s | ~ 218 tok/s | | NVIDIA H100 PCIe 80 GB · $1,469 par mois | 2000 GB/s | ~ 56 tok/s | ~ 113 tok/s | ~ 225 tok/s | Llama 3.1 8B sur une carte, un flux à la fois. Chaque machine listée le contient dans les trois formats, si bien que les lignes sont comparables aussi bien horizontalement que verticalement — et le ratio entre les trois colonnes est le même sur chaque ligne, car il est fixé par les octets par poids et rien d’autre. Deux précautions pour lire ce tableau. La première est qu’il décrit une seule requête à la fois, et presque personne ne sert une seule requête à la fois : avec le traitement par lots continu, les poids sont lus une seule fois pour tout le lot, si bien que c’est l’arithmétique plutôt que la mémoire qui devient la limite, et l’écart entre les colonnes se resserre. La seconde est que la déquantification a un coût. Les poids en 4 bits doivent être décompressés avant d’être multipliés, et sur un petit modèle à faible taille de lot, cette décompression peut absorber une part visible de ce que la lecture réduite vous a fait gagner. La direction du tableau est fiable ; les multiples exacts ne sont pas une promesse. ## Ce que cela vous coûte C’est la partie du sujet où il faut se méfier des chiffres assurés, y compris les nôtres. L’erreur de quantification dépend bien davantage du modèle que de la méthode, et les comparaisons publiées se contredisent entre elles parce qu’elles mesurent des modèles différents sur des tâches différentes. Ce que l’on peut dire honnêtement, c’est la tendance générale. **FP8 est assez proche pour ne pas prêter à controverse.** C’est toujours un format à virgule flottante — un exposant et une mantisse, avec moins de bits pour chacun — et non la grille d’entiers sur laquelle un checkpoint 4 bits doit être mappé avec des échelles par groupe. C’est pourquoi il se dégrade si progressivement, et pourquoi il ne nécessite aucune passe de calibration. La plupart des équipes l’adoptent sans faire d’évaluation, et la plupart s’en sortent bien. **Le 4 bits est un compromis réel, et il ne joue pas de façon uniforme.** Le score moyen aux benchmarks bouge généralement très peu. Ce qui bouge, c’est la traîne : les longues chaînes de raisonnement, le calcul exact, les langues rares, les formats de sortie stricts. Un modèle qui obtient toujours un bon score sur une suite à choix multiples peut se mettre à fermer incorrectement du JSON. **Les modèles plus gros l’absorbent mieux.** Le 4 bits sur un 70B est un déploiement courant. Le 4 bits sur un 8B, dont chaque paramètre porte davantage d’information, est là où la dégradation se remarque — et, d’après le tableau ci-dessus, là où il rapporte le moins. **Les données de calibration comptent plus que le nom de la méthode.** AWQ et GPTQ compressent tous deux par rapport à un corpus d’échantillon. Un checkpoint calibré sur de la prose anglaise et utilisé pour du code sera moins bon que ce que la méthode mérite, et aucun tableau de benchmark ne vous le dira. Ce qui mène à la seule recommandation de cette page qui ne relève pas de l’arithmétique : faites tourner les deux. Vous louez une machine avec accès root et rien n’y est facturé au compteur, donc servir deux fois le même modèle sur deux ports et y envoyer vous-même une centaine de prompts coûte une soirée et tranche la question pour votre usage plutôt que pour celui de quelqu’un d’autre. C’est une réponse nettement meilleure que n’importe quel tableau, celui-ci compris — et c’est pourquoi nous préférons vous montrer la formule plutôt qu’un score. **Testez dans l’ordre le moins coûteux.** Commencez par le BF16 s’il tient, car c’est la référence dont vos autres essais ont besoin. Passez ensuite au FP8 — même checkpoint, une seule option, rien à télécharger. Ne recourez à un checkpoint en 4 bits que lorsque les deux précédents ont été écartés faute de mémoire, et dans ce cas, comparez-le à l’essai FP8 plutôt qu’à vos attentes. ## Quelle machine cela implique La raison pour laquelle tout cela compte, c’est la facture. Voici la machine la moins chère de [notre catalogue](https://gpuserver.io/fr/#catalog) qui contient chaque modèle *entier* à 8k de contexte, dans chacun des trois formats — entier signifiant sur une seule carte, sans le répartir, car un modèle réparti sur plusieurs cartes fait entrer [l’interconnexion](https://gpuserver.io/fr/guides/nvlink-vs-pcie) en jeu, et c’est un autre guide. **Machine la moins chère contenant chaque modèle en entier, par format** | Modèle | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) | |---|---|---|---| | Llama 3.1 8B | [NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) $125 par mois · exige 19.5 GB | [NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) $125 par mois · exige 9.8 GB | [NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) $125 par mois · exige 5.8 GB | | Qwen 3 32B | [NVIDIA A100 PCIe](https://gpuserver.io/fr/gpu/a100-80gb) $1,091 par mois · exige 75.9 GB | [NVIDIA RTX A6000](https://gpuserver.io/fr/gpu/rtx-a6000) $286 par mois · exige 37.9 GB | [NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) $125 par mois · exige 20.7 GB | | Llama 3.3 70B | [4 × NVIDIA B200 SXM6](https://gpuserver.io/fr/gpu/b200) $11,790 par mois · exige 163.9 GB | [4 × NVIDIA H200 SXM5](https://gpuserver.io/fr/gpu/h200) $8,405 par mois · exige 81.9 GB | [NVIDIA RTX A6000](https://gpuserver.io/fr/gpu/rtx-a6000) $286 par mois · exige 43.1 GB | À 8k de contexte, sur les machines que nous louons réellement. Quand une cellule nomme plusieurs cartes, il s’agit du plus petit nœud dans lequel la carte est livrée, et non d’un modèle réparti : les cartes les plus grosses sont vendues par quatre et par huit, donc le moyen le moins cher d’éviter de répartir un 70B en pleine précision est d’en acheter quatre et de n’en utiliser qu’une seule. C’est exactement la facture que la quantification existe pour éviter. **Lisez la ligne du milieu horizontalement : $1,091 face à $125, soit environ 9×.** Le même Qwen 3 32B, le même contexte de 8k, la même carte unique et le même accès root — et un seul format numérique qui les distingue. C’est tout l’argument commercial de la quantification, et c’est aussi pourquoi cela vaut une soirée de mesures plutôt qu’un après-midi de lecture. Deux réflexes font la différence entre bien utiliser ce tableau et se faire piéger par lui. Dimensionnez au contexte que vous ferez réellement tourner, pas au maximum du modèle — le second tableau de cette page montre ce qui arrive à ceux qui confondent les deux. Et vérifiez le format par rapport à la carte avant de commander, pas après : NVIDIA RTX A6000, NVIDIA A100 PCIe et NVIDIA A100 SXM4 ne peut pas vous donner les chiffres du FP8, quelle que soit l’option que vous passiez. Le [configurateur](https://gpuserver.io/fr/configure) indique la mémoire requise et si elle tient sur une seule carte, pour chaque nœud et chaque format, avant tout paiement. Si ce que vous évaluez, c’est la location par rapport au paiement d’une API au jeton, [ce seuil de rentabilité](https://gpuserver.io/fr/guides/api-vs-self-hosting) est calculé séparément, et la quantification le déplace largement en faveur du matériel. ## Vérifiez le format et la machine ensemble. Le configurateur indique ce dont votre modèle a besoin à chaque précision, et quels nœuds le contiennent sur une seule carte, avant que vous ne payiez quoi que ce soit. [Ouvrir le configurateur](https://gpuserver.io/fr/configure) [Lire les guides](https://gpuserver.io/fr/guides) ## Autres guides - [Dimensionnement · 10 min Faire tourner un modèle à mélange d’experts Le nombre total de paramètres décide de la machine, les actifs de la vitesse. Ce qu’il faut en VRAM pour DeepSeek V3 et Qwen 3 235B, et quel nœud louer. Lire le guide](https://gpuserver.io/fr/guides/mixture-of-experts) - [Coût · 6 min Quand la location mensuelle l’emporte sur l’horaire Le seuil de rentabilité sur des chiffres réels, les trois coûts qu’un prix horaire cache jusqu’à la facture, et le piège du temps mort qui triple une estimation. Lire le guide](https://gpuserver.io/fr/guides/monthly-vs-hourly) - [Coût · 9 min L’auto-hébergement contre une API facturée au token Le seuil de rentabilité entre payer une API au token et louer un GPU, calculé sur nos propres prix et débit — et les quatre points que l’arithmétique laisse de côté. Lire le guide](https://gpuserver.io/fr/guides/api-vs-self-hosting) --- Source : https://gpuserver.io/fr/guides/awq-vs-gptq-vs-fp8/. Ce fichier est généré à partir des mêmes données que le site ; si un chiffre ici diffère d’une page, la page fait foi et ce fichier est obsolète — la source canonique est https://gpuserver.io/.