Quel format de quantification utiliser, en pratique.

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.

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é, à 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.

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.

Demander chacun d’eux se résume à un flag. Ce sont les mêmes options que celles que le guide vLLM détaille longuement ; le propos ici est seulement de montrer à quel point la différence entre elles est mince.

# 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 — poids contre cache.

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.

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.

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.

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.

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 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, 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.

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.

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.

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 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 en jeu, et c’est un autre guide.

À 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.

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 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é est calculé séparément, et la quantification le déplace largement en faveur du matériel.