Formats de quantification et matériel nécessaire

La quantification sacrifie la précision contre la taille et la vitesse, et repose sur deux axes indépendants : le nom de la quantification (Q4_K_M, INT4, FP8 — nombre de bits et mode d’empaquetage, décrits dans Explication de la quantification) ainsi que le format de quantification (GGUF, AWQ, NVFP4 — format de fichier et noyau d’exécution, qui déterminent le matériel capable de le charger). Cette page traite du second axe : sélectionnez une ligne ci-dessous pour connaître le matériel nécessaire.

​

La matrice

† Le tableau de compatibilité matérielle de vLLM mentionne qu’AWQ est pris en charge sur les processeurs x86/Arm via un chemin de code distinct, mais pas GPTQ ; en pratique, il convient de considérer ces deux formats comme prioritairement destinés aux GPU. ‡ Le tableau de compatibilité de vLLM indique que ni AWQ ni GPTQ ne sont pris en charge sur les GPU AMD ; il s’agit là d’une limitation propre au moteur d’exécution vLLM, et non d’une caractéristique universelle de tous les noyaux AWQ/GPTQ. § Les GPU NVIDIA antérieurs à la génération Blackwell ne disposent pas de la prise en charge des Tensor Core requise par NVFP4 ; il ne s’agit pas d’une simple limitation liée aux pilotes. ** Le paquet PyPI principal de MLX cible la puce Apple Silicon et macOS ; le projet propose également un backend CUDA expérimental pour Linux, mais les fichiers de modèles quantifiés MLX disponibles sur Hugging Face sont conçus pour le moteur graphique Apple Metal. Les sources justifiant chacune des affirmations ci-dessus figurent dans les notes ci-dessous.

​

Notes spécifiques à chaque format

​

GGUF — le format portable par défaut

GGUF est le format de modèle de llama.cpp, et c’est celui qu’Ollama et LM Studio utilisent en coulisses. Il fonctionne sur CPU, Apple Metal, NVIDIA CUDA, AMD ROCm (via HIP) et Vulkan — la documentation de compilation de llama.cpp répertorie des cibles de compilation dédiées pour chacun de ces backends, ce qui fait de GGUF le format le plus portable sur le matériel grand public. Si vous ne savez pas ce que votre matériel prend en charge, GGUF est le choix par défaut le plus sûr. Consultez llama.cpp et la spécification GGUF.

​

bf16 / FP16 — la référence de base

bf16 et FP16 stockent chaque paramètre sur 2 octets, sans compression. C’est la précision de départ à partir de laquelle la quantification compresse — chaque fichier Q4, AWQ ou NVFP4 est une version plus petite et plus destructrice d’un original bf16/FP16. Considérez la prise en charge comme dépendante du framework : les piles d’inférence CUDA et ROCm prennent généralement en charge ces précisions lorsque la mémoire est suffisante, tandis que les chemins CPU, Metal et Vulkan dépendent du runtime et sont souvent peu pratiques pour les grands modèles. Avec une empreinte environ 4x supérieure à celle d’une quantification 4 bits, bf16/FP16 est rarement ce que vous exécutez en local sur du matériel grand public. Consultez identifier un modèle adapté à votre matériel pour les calculs de mémoire.

​

AWQ et GPTQ — formats destinés aux GPU, utilisés par vLLM

AWQ et GPTQ sont des formats de quantification en 4 bits conçus spécifiquement pour l’inférence sur GPU ; vLLM est le runtime qui documente et assure la prise en charge de ces deux formats. Selon le tableau de compatibilité matérielle de vLLM, ils fonctionnent sur les GPU NVIDIA, de la génération Volta jusqu’à Hopper, le format GPTQ étant également compatible avec Volta. Aucun de ces formats n’est toutefois répertorié comme supporté sur les GPU AMD. Il convient donc de les considérer comme des formats prioritairement destinés à NVIDIA/CUDA, sauf si vous avez vérifié le contraire pour votre runtime. Consultez la documentation sur la quantification de vLLM.

​

MXFP4 — format natif de gpt-oss

MXFP4 est le format de flottants en 4 bits à micro-mise à l’échelle (Microscaling) de l’Open Compute Project, et c’est le format dans lequel OpenAI a publié gpt-oss nativement — gpt-oss-120b et gpt-oss-20b sont tous deux distribués pré-quantifiés en MXFP4 sur Hugging Face, ce qui permet à 120b de fonctionner dans environ 80GB et à 20b dans environ 16GB. llama.cpp a ajouté la prise en charge native de MXFP4 pour gpt-oss, et vLLM le prend également en charge. Consultez OpenAI — Introducing gpt-oss et les notes de prise en charge de gpt-oss dans llama.cpp.

​

NVFP4 — réservé à l’architecture Blackwell

NVFP4 est le format de flottants en 4 bits développé par NVIDIA, conçu spécifiquement pour les cœurs Tensor de cinquième génération de l’architecture Blackwell (cartes grand public de la série RTX 50 et GPU de datacenter de génération Blackwell). Le blog technique de NVIDIA décrit NVFP4 comme un format destiné aux cœurs Tensor de Blackwell utilisant un schéma de mise à l’échelle en deux niveaux ; il est également présenté aux côtés de MXFP4 et FP4 comme l’un des trois formats en 4 bits supportés nativement par ces cœurs. Si votre GPU ne fait pas partie de la gamme Blackwell, le format NVFP4 ne vous convient pas ; privilégiez plutôt une version GGUF, AWQ ou GPTQ du même modèle. Consultez l’annonce de NVIDIA concernant NVFP4.

​

MLX — destiné aux puces Apple Silicon

MLX est le framework de traitement matriciel d’Apple, fondé sur un modèle de mémoire unifiée où les tableaux sont partagés entre le processeur et le GPU. Les modèles quantifiés en MLX — proposés par LM Studio et d’autres outils destinés aux Mac aux côtés du format GGUF — sont conçus pour les puces Apple Silicon sous macOS 14 ou ultérieur. La documentation d’installation du projet indique que la combinaison Apple Silicon et macOS constitue la configuration principale supportée ; un backend expérimental Linux/CUDA est également disponible pour le framework lui-même, indépendamment des fichiers modèles distribués au format MLX. Si vous ne disposez pas d’un Mac, le format MLX ne vous est pas accessible ; privilégiez plutôt GGUF. Consultez le dépôt MLX sur GitHub ainsi que sa documentation d’installation.

​

Lequel choisir ?

Adaptez le format au matériel que vous possédez déjà, et non l’inverse :

• NVIDIA, cartes grand public (séries RTX 40/30 ou cartes antérieures sans Blackwell) — choisissez GGUF pour une intégration simplifiée (Ollama, LM Studio) ; sinon optez pour AWQ/GPTQ si vous utilisez vLLM et souhaitez tirer parti de la puissance d’un noyau natif pour GPU.
• NVIDIA Blackwell (séries RTX 50 ou GPU de datacenter Blackwell) — toutes les options précédentes restent valables, mais privilégiez un NVFP4 compilé si le modèle en propose un ; il s’agit du format conçu spécifiquement pour vos Tensor Cores.
• Apple Silicon — GGUF (via Metal) constitue la solution la plus aisée et la plus répandue ; MLX est une alternative native Mac que certains outils (tels que LM Studio) proposent en parallèle de GGUF.
• GPU AMD — utilisez GGUF via ROCm ou Vulkan. La prise en charge d’AWQ/GPTQ varie selon les environnements d’exécution, il ne faut donc pas compter dessus pour vos besoins.
• CPU uniquement — GGUF. C’est le seul format de ce tableau permettant une inférence réelle sur CPU ; c’est également celui sur lequel reposent llama.cpp, Ollama et LM Studio.

Pour savoir quel nom de quantification choisir selon le format retenu (Q4_K_M ou Q8_0, par exemple), consultez Explication sur la quantification. Pour déterminer la taille d’un modèle adaptée à votre VRAM, rendez-vous sur Adéquation GPU-modèle.