Guide de quantification LLM : 7 méthodes comparées (avec les chiffres des benchmarks)

Guide de quantification LLM : 7 méthodes comparées (avec les chiffres des benchmarks)

Llama 3.3 70B en FP16 réclame 140 Go rien que pour les poids. Deux H100. En Q4_K_M, le même modèle tient dans environ 42 Go, soit une RTX A6000 d'occasion dénichée sur eBay. Cet écart est la raison d'être même de la quantification LLM, et se tromper de méthode vous coûte soit une qualité qui se voit, soit une VRAM que vous n'avez pas.

Ce guide de quantification LLM compare les 7 méthodes qui comptent en 2026, chaque chiffre étant rattaché à une source publiée.

À retenir

• La quantification échange de la mémoire et de la bande passante contre une perte de qualité mesurable, généralement faible.
• GPTQ et AWQ sont pensés pour le GPU ; GGUF est le format qui tourne aussi sur CPU.
• Q4_K_M atteint environ 4,8 bits par poids, pas 4. Le nommage masque la surcharge.
• La quantification 6 bits reste à environ 0,1 % de la perplexité FP16, d'après la PR k-quants de llama.cpp.

Que fait concrètement la quantification LLM à votre modèle ?

La quantification LLM stocke les poids du modèle avec une précision numérique réduite, ce qui diminue la mémoire et la bande passante au prix d'une erreur d'arrondi. Un modèle de 70B paramètres passe de 140 Go en FP16 à environ 42 Go en 4 bits. L'intelligence reste ; les décimales sautent. Toutes les méthodes de ce guide sont des variantes de ce compromis.

L'échelle de précision descend de FP32 (32 bits) vers FP16 et BF16 (16 bits chacun), puis INT8, puis INT4. Chaque palier divise par deux les octets par paramètre. La norme IEEE 754 définit les formats de flottants ; l'article de Mark Horowitz en 2014, « Computing's Energy Problem », a montré que le déplacement de ces octets, et non les calculs effectués dessus, domine le coût énergétique. C'est la raison physique pour laquelle la quantification accélère l'inférence.

Deux paramètres font fonctionner la quantification : un facteur d'échelle (le multiplicateur qui ramène la plage d'entiers vers des valeurs réelles) et un point zéro (l'entier qui représente 0,0). La quantification symétrique centre la plage sur zéro et se passe du point zéro ; la quantification asymétrique la décale pour couvrir toute la plage d'entiers quand les poids se concentrent loin de zéro.

Les poids se quantifient proprement parce qu'ils sont statiques et distribués normalement. Les activations, non. Les activations aberrantes, parfois 100 fois la médiane, font exploser l'erreur d'arrondi si vous les quantifiez naïvement. Cette asymétrie explique pourquoi la plupart des méthodes présentées ici ne quantifient que les poids (W4A16) et laissent les activations en FP16.

La quantification post-entraînement (PTQ) convertit un modèle terminé, après l'entraînement. Le quantization-aware training (QAT) simule les arrondis pendant l'entraînement pour que le modèle s'y adapte. Tout ce qui suit dans cet article concerne la PTQ. Le QAT coûte plus de calcul et un run d'entraînement ; c'est une autre décision.

Les lignes INT4 et NF4 correspondent au 4 bits pur théorique : 4 bits par poids et rien d'autre. Les formats 4 bits réels ajoutent des échelles et des minimums de bloc, ce qui les place plus haut. Un modèle 70B en Q4_K_M pèse environ 42 Go, pas 35. La table VRAM plus bas utilise les taux effectifs.

La quantification ne réduit pas l'intelligence du modèle. Elle réduit le nombre de décimales dans lesquelles cette intelligence est stockée. Et si vous payez l'inférence API au token, réduire votre facture API LLM commence souvent par faire tourner vous-même un modèle quantifié.

Les 7 méthodes de quantification, côte à côte

Les sept méthodes ci-dessous couvrent tous les chemins de production pour quantifier un LLM en 2026. Deux sont réservées au GPU (GPTQ, AWQ), une tourne partout (GGUF), une quantifie au chargement (BitsandBytes), deux visent le serving à haut débit (SmoothQuant, FP8) et une est native PyTorch (TorchAO). Le bon choix dépend de votre matériel, pas de la méthode qui score le plus haut sur un leaderboard.

GPTQ quantifie couche par couche en utilisant la hessienne inverse pour redistribuer l'erreur d'arrondi sur les poids restants. Il lui faut un jeu d'étalonnage et un GPU. L'article GPTQ rapporte la quantification d'un modèle 175B en 3-4 bits en environ 4 heures-GPU.

AWQ identifie les ~1 % de poids les plus importants (les poids saillants, repérés par l'amplitude des activations) et les met à l'échelle pour les protéger des arrondis. L'article AWQ (meilleur article MLSys 2024) rapporte une accélération de plus de 3x par rapport à l'implémentation FP16 de HuggingFace, sur GPU de bureau comme sur GPU mobile.

GGUF est un format de fichier, pas un algorithme. L'algorithme à l'intérieur est le schéma de blocs k-quant de la PR llama.cpp #1684. C'est la seule méthode de ce guide qui tourne sur CPU, ce qui en fait le choix par défaut pour l'inférence locale. Voyez les modèles open-weight qui valent d'être quantifiés pour savoir quoi lui donner.

BitsandBytes quantifie au chargement plutôt qu'en amont. NF4 (NormalFloat 4 bits) est son format signature, et c'est la colonne vertébrale du fine-tuning QLoRA. Aucun jeu d'étalonnage requis.

SmoothQuant migre les valeurs aberrantes des activations vers les poids pour que les deux puissent tourner en INT8. L'article rapporte jusqu'à 1,56x d'accélération et une réduction de mémoire de 2x, et vise le débit du serving à gros batch, là où les méthodes W4A16 laissent de la performance sur la table.

FP8 (W8A8) est la voie native sur les GPU H100 et B200. Quasi sans perte en 8 bits, pas de casse-tête d'étalonnage, et vLLM le prend directement en charge.

TorchAO est la bibliothèque de quantification de PyTorch lui-même, conçue pour fonctionner avec torch.compile. Si votre pipeline est déjà en PyTorch, c'est le chemin de moindre résistance.

Il n'y a que deux vraies questions : votre matériel peut-il la faire tourner, et pouvez-vous vivre avec la qualité qu'elle coûte ?

Que montrent vraiment les benchmarks publiés ?

Les benchmarks publiés disent que la quantification 4 bits coûte 1 à 2 % de perplexité sur un modèle 7B, et que le 6 bits coûte moins de 0,1 %. Ces chiffres viennent de la PR llama.cpp #1684 (2023), mesurés par les mainteneurs de llama.cpp sur un seul modèle 7B et une RTX 4080. Ce sont les chiffres les plus cités dans le domaine de la quantification, et ils sont réels. Ils reposent aussi sur n = 1.

Source : PR llama.cpp #1684 (2023). Modèle 7B, RTX 4080, mesuré par les mainteneurs de llama.cpp. n = 1 modèle.

Une note sur cette colonne bits/poids : ce sont les taux nominaux du type k-quant de base, et les mixtes _K relèvent le taux effectif. Q2_K en est l'illustration. Appliquez la formule même de l'article au taux nominal de 2,5625 et à un modèle de 6,74B paramètres, et vous obtenez ~2,0 Go, mais la ligne indique un fichier de 2,67 Go, ce qui correspond, en remontant le calcul, à ~3,4 bits par poids. Le reste de cet article utilise les taux effectifs, dérivés de ces tailles de fichier.

Les chiffres des méthodes GPU viennent directement des articles. GPTQ rapporte des accélérations d'inférence de bout en bout par rapport au FP16 d'environ 3,25x sur A100 et ~4,5x sur A6000, avec un modèle 175B quantifié en 3-4 bits en environ 4 heures-GPU. AWQ rapporte « plus de 3x d'accélération par rapport à l'implémentation FP16 de HuggingFace, sur GPU de bureau comme sur GPU mobile », ainsi que le premier déploiement de Llama-2 70B sur un GPU mobile via TinyChat. Nous citons la formulation de l'article plutôt que de paraphraser un chiffre en fausse précision.

La contribution originale ici est arithmétique. La mémoire pour les poids suit : poids (Go) ≈ paramètres (B) × bits par poids ÷ 8. Le piège est le chiffre de bits par poids que vous y injectez. La PR #1684 publie le taux du type k-quant de base (Q4_K = 4,5), et les mixtes _S/_M/_L se situent au-dessus de ce taux de base parce qu'ils attribuent des bits supplémentaires aux tenseurs d'attention et feed-forward. Nous avons donc dérivé les taux effectifs à partir des tailles de fichier que la PR elle-même publie, sur un modèle 7B qui fait en réalité 6,74B paramètres : Q2_K à 2,67 Go correspond, en remontant le calcul, à ~3,4 bpw, Q4_K_S à 3,56 Go à ~4,5, Q6_K à 5,15 Go à ~6,6. Q4_K_M atteint environ 4,8.

Cela change le chiffre phare. Un modèle 70B en Q4_K_M : 70 × 4,8 ÷ 8 = 42 Go. La plupart des articles disent 35 Go. Ils utilisent 4,0 bpw et ignorent purement et simplement la surcharge des échelles de bloc. La vérification croisée tient en un clic : Llama-3.3-70B-Instruct-Q4_K_M.gguf pèse 42,5 Go sur HuggingFace, dans les dépôts bartowski, lmstudio-community et second-state. Nous avons recalculé chaque cellule de la table VRAM ci-dessous sur cette base.

Notre lecture de ces chiffres : l'écart de perplexité entre Q6_K (5,9110) et F16 (5,9066) est de 0,0044, soit moins que l'écart entre deux fine-tunes différents du même modèle de base. C'est pourquoi « prenez simplement Q4_K_M ou Q5_K_M » est le conseil qui survit au contact du matériel réel. La colonne ms/token montre aussi que Q2_K n'achète aucune vitesse par rapport à Q4_K_S (les deux à 15,5 ms/token) tout en coûtant 0,75 de perplexité. Q2_K est le pire échange de la table.

Ce que les chiffres ne vous disent pas : la perplexité sur wikitext n'est pas la même chose que la qualité sur vos prompts. Un modèle sur un GPU, c'est n = 1. Les chiffres de vitesse dépendent de la taille du batch. Prenez-les comme des indications, pas comme des vérités universelles.

La quantification 6 bits reste à environ 0,1 % de la perplexité du modèle en pleine précision. À ce niveau, la compression est quasi gratuite.

GPTQ vs AWQ : choisir entre les deux méthodes GPU

GPTQ et AWQ produisent tous deux des checkpoints GPU 4 bits à partir d'un jeu d'étalonnage, et tous deux sont bien pris en charge dans vLLM. La différence tient à leur gestion de l'erreur d'arrondi. GPTQ la redistribue sur les poids restants via la hessienne inverse. AWQ protège les 1 % de poids que les activations signalent comme importants. Les deux fonctionnent. Le choix dépend de votre mode de serving.

GPTQ travaille couche par couche. Pour chaque couche, il quantifie un poids à la fois, puis ajuste les poids restants de cette couche pour compenser l'arrondi qu'il vient de faire. L'ajustement utilise l'information du second ordre de la matrice hessienne, raison pour laquelle il a besoin d'un jeu d'étalonnage. Le résultat est solide pour l'inférence batch, où le débit compte plus que la latence par token.

AWQ prend un angle différent. Il identifie les poids saillants en observant l'amplitude des activations sur le jeu d'étalonnage, grossièrement le top 1 % des canaux. Ces poids reçoivent un facteur d'échelle par canal qui les maintient dans une plage de plus haute précision pendant les arrondis. Le jeu d'étalonnage peut être plus petit que celui de GPTQ, et AWQ y surapprend moins parce qu'il protège des caractéristiques structurelles plutôt qu'il ne s'ajuste à des entrées spécifiques. L'article rapporte de solides résultats sur le serving sensible à la latence.

Choisissez GPTQ si : vous faites de l'inférence batch sur GPU, vous disposez d'un bon jeu d'étalonnage représentatif de votre domaine, et le débit est la métrique.

Choisissez AWQ si : vous servez des requêtes mono-utilisateur à faible latence, vous voulez un jeu d'étalonnage plus petit, ou vous déployez sur des GPU edge/mobile.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Si vous hésitez aussi entre moteurs de serving, vLLM face à SGLang traite cette décision séparément.

GGUF et K-Quants : ce que Q4_K_M veut vraiment dire

GGUF est un format de fichier, pas un algorithme de quantification. La spécification GGUF définit un conteneur pour les poids du modèle, les métadonnées et les données de tokenizer. L'algorithme de quantification à l'intérieur d'un fichier GGUF est le schéma de blocs k-quant (ou i-quant) de la PR llama.cpp #1684. Confondre le conteneur et l'algorithme est l'erreur la plus courante dans ce domaine, et elle mène à des questions comme « lequel est le meilleur, GGUF ou GPTQ ? » qui ne veulent pas tout à fait dire quelque chose.

Le schéma de nommage se décode ainsi. Q désigne le schéma de blocs k-quant ; IQ désigne l'i-quant à matrice d'importance (une variante plus récente qui utilise une matrice d'importance pour une meilleure qualité à même profondeur de bits). Le chiffre est la profondeur de bits nominale. _K marque la famille k-quant par opposition aux formats hérités comme Q4_0. _S, _M, _L contrôlent les groupes de tenseurs qui reçoivent des bits supplémentaires : small, medium, large. Un suffixe plus élevé signifie plus de bits attribués aux tenseurs d'attention et feed-forward, ceux qui comptent le plus.

Taux effectifs, obtenus en remontant le calcul depuis les tailles de fichier du 7B (6,74B paramètres) publiées dans la PR #1684, et non les chiffres du type de base. Les lignes héritées sont exactes par construction : un bloc Q4_0 contient 32 poids à 4 bits plus une échelle FP16, soit 4,5 bits par poids, et Q8_0 contient 32 poids à 8 bits plus une échelle FP16, soit 8,5. La PR le corrobore, listant les fichiers 7B Q4_0 et Q4_K_S à la même taille de 3,56 Go.

Q4_K_M, ce n'est pas 4 bits par poids. C'est environ 4,8. Les échelles et minimums de bloc doivent bien loger quelque part, et le mixte _M dépense ensuite des bits supplémentaires sur les tenseurs d'attention et feed-forward, ce qui explique précisément pourquoi Q4_K_M se situe au-dessus de Q4_K_S et Q3_K_M au-dessus de Q3_K_S plutôt qu'à égalité.

Pourquoi GGUF tourne-t-il là où GPTQ ne peut pas : il prend en charge l'inférence CPU et le déport de couches entre la VRAM du GPU et la RAM système. Un modèle 32B qui ne tient pas entièrement sur votre GPU peut tourner avec la moitié de ses couches déportées, lentement mais fonctionnellement. GPTQ n'a pas de voie CPU.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Nouveau dans les modèles locaux ? Commencez par faire tourner votre premier modèle local avant de quantifier quoi que ce soit. Et si vous voulez une interface dans le navigateur, Open WebUI par-dessus Ollama prend une dizaine de minutes. La documentation GGUF de HuggingFace explique comment le Hub expose le nommage des types de quantification.

BitsandBytes, Marlin, SmoothQuant et TorchAO

Ces quatre-là couvrent les chemins de production restants. Aucun n'est un « meilleur GPTQ ». Ils résolvent des problèmes différents.

BitsandBytes quantifie au chargement, pas en amont. Vous le pointez vers un checkpoint FP16 et il convertit à la volée en NF4 ou FP4. Pas de jeu d'étalonnage, pas d'étape hors ligne. Son principal titre de gloire est QLoRA : un modèle de base figé en 4 bits avec des adaptateurs LoRA entraînés par-dessus, ce qui rend possible le fine-tuning d'un modèle 65B sur un seul GPU avec 48 Go de VRAM. QLoRA est une technique d'entraînement, pas d'inférence, mais c'est la raison pour laquelle la plupart des gens rencontrent BitsandBytes en premier.

Marlin n'est pas une méthode de quantification. C'est un noyau GEMM à précision mixte INT4xFP16 qui accélère les checkpoints 4 bits existants à des tailles de batch modérées. L'article Marlin rapporte des accélérations sur A100 et H100. Si votre stack de serving le prend en charge, vous l'activez sur un modèle déjà quantifié. On ne « quantifie pas avec Marlin ».

SmoothQuant déplace les valeurs aberrantes des activations vers les poids via un facteur de mise à l'échelle par canal, ce qui rend le W8A8 (poids et activations tous deux en INT8) viable. L'article vise le serving à gros batch, là où les méthodes W4A16 laissent du débit sur la table. Si vous servez des centaines de requêtes simultanées, c'est la bonne carte à jouer.

TorchAO est la quantification native de PyTorch, qui fonctionne avec torch.compile. Aucune dépendance externe, aucune conversion de format. Si votre pipeline d'inférence est déjà en PyTorch, c'est l'option la moins frictionnelle. Pour faire tourner des modèles d'embedding en local, la voie Ollama est généralement plus simple, mais TorchAO convient aux stacks PyTorch sur mesure.

De combien de VRAM un modèle quantifié a-t-il besoin ?

La formule est poids (Go) ≈ paramètres (B) × bits par poids ÷ 8. Un modèle 70B en Q4_K_M : 70 × 4,8 ÷ 8 = 42,0 Go. Les taux ci-dessous sont effectifs, obtenus en remontant le calcul depuis les tailles de fichier que publie la PR llama.cpp #1684 plutôt que depuis les chiffres du type de base, parce que les mixtes _M tournent toujours au-dessus de leur taux k-quant de base. Nous avons recalculé plutôt que de copier le raccourci habituel à 4,0 bpw.

Calculé à partir des bits par poids effectifs : Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Dérivé des tailles de fichier du 7B (6,74B paramètres) de la PR #1684, puis vérifié par rapport à un build 70B publié : Llama-3.3-70B-Instruct-Q4_K_M.gguf pèse 42,5 Go sur HuggingFace, contre 42,0 Go prédits ici.

L'avertissement honnête : ceci ne couvre que les poids uniquement. Le cache KV, la longueur de contexte et la surcharge du framework s'ajoutent par-dessus. Le cache KV grandit avec la longueur de contexte et la taille du batch. Une session à 32k de contexte sur un modèle 70B peut ajouter plusieurs Go. La table des poids est le plancher, pas le budget. Votre fenêtre de contexte loue elle aussi de la VRAM. Pour le tableau complet, voyez les exigences VRAM par modèle en détail.

Quelle méthode de quantification devez-vous utiliser ?

Votre matériel décide avant vos préférences. Une méthode qui ne tourne pas sur votre GPU n'est pas un choix, c'est un souhait. La table ci-dessous associe les configurations courantes à la méthode qui fonctionne réellement pour elles, d'après les contraintes matérielles et les compromis qualité couverts plus haut.

Pour la plupart des lecteurs sur du matériel grand public, un GGUF Q4_K_M ou Q5_K_M pré-quantifié est la bonne réponse. Récupérez-le sur HuggingFace, lancez-le dans Ollama ou llama.cpp, et arrêtez d'optimiser. L'écart de qualité entre Q4_K_M et Q5_K_M est assez faible pour que vous choisissiez selon que le fichier tient ou non, pas selon une table de perplexité. Tout ce qui va au-delà est de l'optimisation pour l'optimisation, et cela ne vaut le coup qu'une fois confirmé que le modèle résout bien votre problème en Q4.

Le guide des outils qui font réellement tourner ces modèles en local couvre le versant serving une fois votre niveau de quantification choisi.

Cinq façons dont la quantification tourne mal

Les échecs de quantification sont presque toujours des problèmes de configuration, pas des problèmes de méthode. Ces cinq-là reviennent sans cesse.

1. Le jeu d'étalonnage ne correspond pas à votre domaine. GPTQ et AWQ s'ajustent tous deux aux données d'étalonnage. Si vous étalonnez sur Wikipédia et déployez sur des transcriptions médicales, le modèle quantifié sous-performe sur les tokens qu'il n'a jamais vus. Correction : utilisez un jeu d'étalonnage tiré de votre distribution d'entrées réelle, même 128 exemples aident.

2. Taille de groupe réglée trop grande. La taille de groupe de GPTQ contrôle combien de poids partagent un facteur d'échelle. 128 est le standard. 256 ou 512 économise du calcul pendant la quantification mais heurte une falaise de qualité sur les modèles plus petits. Correction : restez à 128 sauf si vous avez confirmé que la qualité tient sur vos prompts.

3. Croire que Q2_K est utilisable. D'après les données de la PR #1684, Q2_K coûte ~0,87 de perplexité par rapport à F16 et n'achète aucune vitesse face à Q4_K_S (les deux à 15,5 ms/token sur le benchmark 7B). Vous obtenez un fichier plus petit et une sortie dégradée sans gain de latence. Correction : Q4_K_S est le plancher, sauf si la taille du fichier est une contrainte dure.

4. Benchmarker sur la perplexité wikitext au lieu de vos propres prompts. La perplexité est une métrique de modélisation du langage. Elle ne mesure pas si le modèle suit votre prompt système, formate correctement du JSON ou gère le vocabulaire de votre domaine. Correction : passez 20 à 30 de vos vrais prompts dans le modèle quantifié et non quantifié, et comparez les sorties.

5. Confondre le conteneur GGUF avec l'algorithme de quantification qu'il contient. Cela mène à comparer « GGUF vs GPTQ » comme s'ils étaient de la même catégorie. Ils ne le sont pas. GGUF est un format de fichier. Le schéma k-quant à l'intérieur est l'algorithme. Correction : comparez les niveaux k-quant (Q4_K_M vs Q5_K_M), pas les formats de fichier.

Questions fréquemment posées

Qu'est-ce que la quantification LLM ?

La quantification LLM réduit la précision numérique des poids d'un modèle, typiquement de flottants 16 bits vers des entiers 4 bits ou 8 bits. Cela diminue l'usage mémoire et accélère l'inférence en réduisant la bande passante. Un modèle 70B passe de 140 Go à environ 42 Go en 4 bits. Le coût qualité est généralement de 1 à 2 % de perplexité en 4 bits, moins en 6 bits.

La quantification réduit-elle la précision d'un modèle ?

Oui, mais moins que ce que la plupart des gens attendent. D'après les benchmarks de la PR llama.cpp #1684, Q4_K_S sur un modèle 7B coûte environ 2 % de perplexité par rapport à F16, et Q6_K coûte moins de 0,1 %. L'impact pratique sur de vrais prompts est souvent plus faible que le chiffre de perplexité ne le suggère, surtout à partir de Q4_K_M.

GPTQ ou AWQ, lequel est le meilleur ?

Aucun n'est universellement meilleur. GPTQ utilise la redistribution d'erreur par hessienne inverse et convient à l'inférence batch sur GPU. AWQ protège les poids saillants via une mise à l'échelle sensible aux activations et convient au serving sensible à la latence. AWQ demande un jeu d'étalonnage plus petit et y surapprend moins. Si vous servez des requêtes mono-utilisateur à faible latence, commencez par AWQ.

Que signifie Q4_K_M ?

Q4_K_M est un niveau de quantification GGUF k-quant. « Q4 » désigne la profondeur nominale de 4 bits, « K » marque le schéma de blocs k-quant (par opposition au Q4_0 hérité) et « M » signifie medium : les tenseurs d'attention et feed-forward reçoivent des bits supplémentaires. Les bits par poids effectifs sont d'environ 4,8, pas 4,0, parce que les échelles et minimums de bloc ajoutent de la surcharge et que le mixte medium dépense davantage par-dessus.

Peut-on faire tourner un modèle quantifié sur un CPU ?

Oui, mais uniquement via GGUF. GPTQ et AWQ sont des formats réservés au GPU. Les modèles k-quant de GGUF tournent sur CPU via llama.cpp ou Ollama, et prennent en charge le déport de couches entre la VRAM du GPU et la RAM système. Q4_K_M est la quantification CPU standard. Attendez-vous à une génération de tokens plus lente que sur GPU, mais à une inférence fonctionnelle.

Quelle est la différence entre GGUF et GGML ?

GGML est l'ancienne bibliothèque de tenseurs et l'ancien format de fichier que llama.cpp utilisait à l'origine. GGUF l'a remplacé en août 2023 comme format conteneur plus flexible avec une meilleure prise en charge des métadonnées. Les fichiers GGUF sont ce que vous téléchargez aujourd'hui depuis HuggingFace. Les fichiers GGML sont hérités et ne sont quasiment plus distribués.

Faut-il quantifier un modèle soi-même ou télécharger une version pré-quantifiée ?

Téléchargez d'abord une version pré-quantifiée. Les communautés llama.cpp et HuggingFace ont déjà quantifié la plupart des modèles populaires à tous les niveaux. Quantifier vous-même n'a de sens que si vous avez besoin d'un jeu d'étalonnage spécifique à votre domaine, ou s'il n'existe aucune version pré-quantifiée de votre modèle.

Quand utiliser la quantification plutôt qu'un modèle plus petit ?

Utilisez la quantification quand vous avez besoin des capacités du modèle plus gros mais qu'il ne tient pas en mémoire. Un modèle 70B quantifié surpasse généralement un modèle 13B non quantifié sur les tâches de raisonnement complexes. Utilisez plutôt un modèle plus petit quand la latence est la contrainte, car les modèles plus petits génèrent des tokens plus vite, indépendamment de la quantification.

Quelle est la différence entre quantification et distillation ?

La quantification réduit la précision numérique des poids d'un modèle existant. La distillation entraîne un modèle plus petit à imiter un modèle plus gros, ce qui produit une architecture réellement différente (plus petite). La quantification préserve l'architecture du modèle d'origine et est réversible en principe. La distillation crée un nouveau modèle et exige un run d'entraînement.

La version courte : la quantification est la façon de faire tenir le modèle que vous voulez dans le matériel que vous avez. Pour la plupart des gens sur des GPU grand public ou sur Apple Silicon, un GGUF Q4_K_M pré-quantifié récupéré sur HuggingFace est la solution complète. GPTQ et AWQ sont les réponses pour le serving GPU. FP8 et SmoothQuant sont les réponses pour le débit en production. Tout le reste est de l'optimisation une fois confirmé que le modèle fonctionne.

Si vous décidez ce que vous auto-hébergez et voulez un second avis sur l'association matériel-méthode, nous serons ravis d'en parler.