- GGUF est un format conteneur mono-fichier pour modèles quantifiés, créé pour llama.cpp. Un
.ggufseul fichier contient les poids, le tokenizer, le modèle de discussion (chat template) et les métadonnées — pas de dossier de configuration, pas de fichiers séparés pour le tokenizer. - Les modèles GGUF sont ceux que chargent effectivement Ollama, LM Studio, KoboldCpp, Jan et llama.cpp. Si vous exécutez un modèle localement sur du matériel grand public, il est quasi certain que vous utilisez GGUF.
- Choix par défaut :
Q4_K_M. Environ 0,6 Go de taille par milliard de paramètres — un modèle de 8 milliards de paramètres pèse environ 5 Go, ce qui correspond à la valeur de ~5 Go en 4 bits indiquée par base de données des modèles Convly pour Llama 3.1 8B. - GGUF est conçu pour l’inférence locale destinée à un seul utilisateur. Pour une utilisation simultanée (serving concurrent), privilégiez safetensors avec vLLM ou une API à la place.
GGUF (GPT-Generated Unified Format) est le format de fichier utilisé par l’écosystème llama.cpp/ggml pour stocker un modèle prêt à être utilisé en inférence. Un seul .gguf fichier contient les tenseurs quantifiés ainsi que tout ce qui est nécessaire pour les exploiter : vocabulaire, paramètres du tokenizer, modèle de discussion (chat template) et métadonnées relatives à l’architecture. Il a remplacé l’ancien format GGML en août 2023 et constitue désormais la norme de facto pour exécuter des modèles sur des ordinateurs portables, des postes de travail et des processeurs (CPU).
- Que contient réellement un fichier .gguf
- Comment interpréter un nom de fichier GGUF
- Taille : quels modèles GGUF conviennent à votre GPU
- Où télécharger des modèles GGUF
- Exécuter des modèles GGUF sous Linux
- Exécuter des modèles GGUF sous macOS
- Exécuter des modèles GGUF sous Windows
- Charger un fichier GGUF arbitraire dans Ollama
- Quand GGUF n’est pas la bonne solution
- Questions fréquemment posées
Que contient réellement un fichier .gguf
Un fichier GGUF se compose d’un en-tête, d’un bloc de métadonnées clé-valeur, puis des données tensorielles. Ce sont les métadonnées qui revêtent une importance pratique — c’est pourquoi un modèle GGUF ne nécessite aucun fichier annexe. La documentation GGUF d’Hugging Face GGUF documentation décrit la structure du format ainsi que le visualiseur intégré de métadonnées GGUF sur le Hub, qui vous permet d’inspecter au préalable le type de quantification, la longueur de contexte et le modèle de discussion (chat template) d’un fichier avant de télécharger plusieurs gigaoctets.
Les clés de métadonnées courantes incluent l’architecture (llama, qwen3, gemma3, phi3), la longueur de contexte utilisée lors de l’entraînement, les paramètres RoPE, le vocabulaire complet et le modèle de discussion Jinja. Un chargeur lit ce bloc et s’configure automatiquement ; vous n’avez pas besoin de fournir manuellement un tokenizer ou un format de prompt.
GGUF contre safetensors
| GGUF | safetensors | |
|---|---|---|
| Runtime principal | llama.cpp, Ollama, LM Studio | PyTorch, vLLM, Transformers, TGI |
| Fichiers par modèle | Un seul (ou fragments numérotés) | Poids plus dossier config/tokenizer |
| Quantification | Intégrée (Q4_K_M, Q8_0, IQ…) | Généralement FP16/BF16, ou variantes GPTQ/AWQ |
| CPU + déchargement partiel sur GPU | Oui, objectif fondamental de conception | Limitée et lente |
| Serving groupé simultané | Faible | Fort |
| Affinage | Non (conversion préalable requise) | Oui |
Comment interpréter un nom de fichier GGUF
Les fichiers portent généralement des noms tels que Model-Name-8B-Instruct-Q4_K_M.gguf. Le suffixe indique le type de quantification mixte. Le chiffre correspond à la largeur de bit nominale ; _K signifie k-quants, qui conservent les tenseurs d’attention et d’embedding à une précision supérieure à celle des poids principaux de la couche feed-forward ; S/M/L désignent respectivement les variantes petite, moyenne et grande de ce type de quantification.
| Quant | Bits/poids approximatifs | Taille approximative, modèle de 8 milliards de paramètres | Quand l'utiliser |
|---|---|---|---|
| Q8_0 | ~8.5 | ~8,5 Go | Référence quasi sans perte ; modèles petits uniquement |
| Q6_K | ~6.6 | ~6,6 Go | Vous disposez de VRAM en surplus |
| Q5_K_M | ~5.7 | ~5,7 Go | Paramètre par défaut privilégiant la qualité |
| Q4_K_M | ~4.9 | ~4,9 Go | Valeur par défaut habituelle |
| Q4_0 | ~4.5 | ~4,5 Go | Héritage ; certains accélérateurs le préfèrent |
| Q3_K_M | ~3.9 | ~4,0 Go | Faire tenir un modèle plus volumineux dans une faible quantité de VRAM |
| Q2_K / IQ2 | ~2,5–3,4 | ~2,5–3,4 Go | Dernier recours ; dégradation notable |
Considérez la colonne « bits par poids » comme approximative. Les tailles réelles varient selon l’architecture du modèle (un grand vocabulaire gonfle les tenseurs d’embeddings) et selon la version de llama.cpp, car les combinaisons de quantification sont progressivement optimisées. La famille IQ (IQ2_XXS à IQ4_NL) utilise une calibration basée sur une matrice d’importance pour mieux résister à des largeurs de bits très faibles, et des quantificateurs tels que Bartowski ou Unsloth publient des variantes IQ aux côtés des K-quants standards.
Le consensus communautaire — et non une mesure effectuée par Convly — est que Q4_K_M représente le meilleur compromis, et que la qualité chute fortement en dessous d’environ 3 bits par poids : les modèles petits se dégradent plus rapidement que les grands au même niveau de quantification.
Taille : quels modèles GGUF conviennent à votre GPU
La taille du fichier constitue un plancher, pas le total. Ajoutez la mémoire cache KV correspondant à votre longueur de contexte, ainsi qu’environ 500 Mo à 1 Go de surcharge. Ces chiffres à 4 bits proviennent de la base de données des modèles Convly:
| Modèle | VRAM en 4 bits | Contexte | GPU réaliste |
|---|---|---|---|
| Gemma 3 4B | ~3 Go | 128 K | Toute carte graphique de 6 Go, GPU intégré |
| Mistral 7B | ~4,5 Go | 32 K | Carte graphique de 8 Go |
| Llama 3.1 8B | ~5 Go | 128 K | Carte graphique de 8 Go |
| Qwen3 14B | ~9 Go | 128 K | Carte graphique de 12 Go |
| Phi-4 | ~9 Go | 16 K | Carte graphique de 12 Go |
| Gemma 3 27B | ~16 Go | 128 K | Carte graphique de 24 Go |
| Qwen3 32B | ~20 Go | 128 K | Carte graphique de 24 Go |
| Llama 3.3 70B | ~40 Go | 128 K | 2 × 24 Go ou mémoire unifiée de 48 Go |
| DeepSeek R1 (intégral) | ~400 Go | 128 K | Serveur multi-GPU uniquement |
Les modèles à mélange d’experts constituent ici le piège. Qwen3 30B-A3B n’active que ~3 milliards de paramètres par jeton, mais nécessite tout de même le chargement complet des ~18 Go en mémoire. À l’extrême, la base de données indique une taille de Kimi K3 d’environ 1,4 To en 4 bits — un format GGUF existe théoriquement, mais aucune machine individuelle que vous possédez ne peut l’accueillir. Pour obtenir une estimation précise à votre longueur de contexte, utilisez le Calculateur de VRAM ou la ventilation par modèle fournie dans Exigences en VRAM pour chaque grand modèle de langage (LLM). Si vous êtes encore en train de choisir votre matériel, meilleures GPU pour les LLM locaux traite le compromis VRAM/prix.
Où télécharger des modèles GGUF
- Hugging Face — filtrez la liste des modèles avec library=gguf. La plupart des dépôts fournissent toutes les quantifications dans un seul dépôt ; téléchargez uniquement le fichier dont vous avez besoin, pas l’intégralité du dépôt.
- bibliothèque Ollama — ollama.com/library propose des fichiers GGUF pré-packagés avec le modèle de discussion déjà configuré. Consultez le Liste des modèles Ollama.
- LM Studio — l’onglet Découvrir intégré à l’application recherche les dépôts GGUF sur Hugging Face et signale quelles quantifications conviennent à la RAM/VRAM détectée sur votre système. Tutoriel pas à pas : Guide complet de LM Studio.
Les modèles volumineux arrivent fragmentés sous forme de model-00001-of-00003.gguf et ainsi de suite. Téléchargez tous les fragments dans le même dossier, puis pointez le chargeur vers le fragment 00001 — il détectera automatiquement les autres.
Exécuter des modèles GGUF sous Linux
Construisez llama.cpp avec le support CUDA :
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j
Les binaires sont placés dans build/bin/. Lancez un serveur compatible OpenAI :
./build/bin/llama-server -m ~/models/model-Q4_K_M.gguf -c 8192 -ngl 99 --port 8080
-ngl (--n-gpu-layers) est le réglage de déchargement : 99 signifie « toutes les couches sur GPU » 0 signifie « CPU uniquement », et les valeurs intermédiaires répartissent le modèle entre GPU et CPU lorsque celui-ci ne tient pas entièrement sur GPU. -c définit la longueur de contexte ; la laisser à la valeur maximale entraînée pour le modèle peut consommer davantage de VRAM que les poids eux-mêmes. Le point de terminaison devient alors http://localhost:8080/v1/chat/completions.
Deux précisions concernant les versions : le drapeau CMake s’appelait LLAMA_CUBLAS dans les anciennes versions, et les binaires ont été renommés (main → llama-cli, server → llama-server) en 2024. Consultez le fichier README du dépôt que vous avez cloné pour connaître les instructions exactes. Pour les GPU AMD ou Intel, remplacez le drapeau CUDA par celui correspondant au backend ROCm/Vulkan/SYCL documenté dans le dépôt, plutôt que d’essayer de deviner.
Si vous utilisez Ollama à la place, les modèles sont stockés dans /usr/share/ollama/.ollama/models lorsqu’il fonctionne en tant que service système, ou ~/.ollama/models pour une installation utilisateur. Voir comment installer Ollama.
Exécuter des modèles GGUF sous macOS
Apple Silicon est remarquablement performant avec GGUF, car sa mémoire unifiée permet au GPU d’accéder à la majeure partie de la RAM système : un Mac de 64 Go peut charger un modèle 70B quantifié en 4 bits d’environ 40 Go, qui nécessiterait deux cartes PC de 24 Go.
brew install llama.cpp
llama-server -m ~/models/model-Q4_K_M.gguf -c 8192 --port 8080
Le déchargement vers Metal est activé dans la version Homebrew, donc vous n’avez généralement pas besoin de -ngl. macOS limite la quantité de mémoire RAM que le GPU peut réserver (réglable via un iogpu sysctl, dont la valeur varie selon la version de macOS), aussi laissez une marge pour le système d’exploitation. Ollama stocke les modèles dans ~/.ollama/models; LM Studio utilise ~/.lmstudio/models sur les versions récentes et ~/.cache/lm-studio/models sur les versions plus anciennes — l’onglet « Mes modèles » affiche et permet de modifier le chemin réel.
Exécuter des modèles GGUF sous Windows
Trois approches, du plus simple au plus technique :
- LM Studio — Installateur graphique, recherche intégrée de modèles, bascule vers un serveur local. Le meilleur choix par défaut pour les non-développeurs.
- Ollama — Installateur natif Windows ; les modèles sont placés dans
C:\Users<vous>\.ollama\models. Définissez la variable d’environnementOLLAMA_MODELSpour les déplacer hors du disque système. Contexte : qu’est-ce qu’Ollama. - Binaires précompilés de llama.cpp — La page des versions GitHub publie des archives Windows zippées pour chaque backend (CUDA, Vulkan, CPU). Décompressez-les puis exécutez
llama-server.exe -m model.gguf -ngl 99à partir de PowerShell. Choisissez la version CUDA pour les cartes NVIDIA ; Vulkan constitue une solution fiable multi-fournisseurs pour AMD et Intel Arc.
Pièges spécifiques à Windows : l’analyse en temps réel de Windows Defender ralentit le premier chargement d’un fichier de plusieurs gigaoctets, et l’exécution de llama.cpp sous WSL2 consomme une part de la mémoire RAM allouée à la machine virtuelle. Les versions natives Windows constituent généralement la voie la plus simple.
Charger un fichier GGUF arbitraire dans Ollama
Les versions récentes d’Ollama peuvent télécharger directement depuis Hugging Face :
ollama run hf.co//:Q4_K_M
Pour un fichier local, créez un fichier Modelfile dans le même répertoire :
FROM ./model-Q4_K_M.gguf
puis ollama create my-model -f Modelfile et ollama run my-model. Si le GGUF ne contient pas de modèle de discussion utilisable, ajoutez une ligne TEMPLATE et PARAMETER stop — les directives exactes disponibles dans les fichiers Modelfile ont évolué au fil des versions, vérifiez donc ollama help create pour votre version. Sélections recommandées : les meilleurs LLM locaux pour Ollama.
Quand GGUF n’est pas la bonne solution
GGUF est optimisé pour un seul utilisateur à la fois. Pour servir de nombreuses requêtes simultanées ou nécessiter un parallélisme tensoriel entre plusieurs GPU, privilégiez les fichiers safetensors avec vLLM ou SGLang. De plus, l’exécution locale n’est pas automatiquement moins coûteuse : les services hébergés Llama 3.3 70B coûtent 0,10 $ en entrée / 0,32 $ en sortie par million de jetons, tandis que les modèles hébergés haut de gamme comme Claude Sonnet 5 atteignent 2,00 $ en entrée / 10,00 $ en sortie par million de jetons pour un contexte de 1 million de jetons. Évaluez votre volume d’utilisation via le Calculateur de coûts d’API et le Calculateur de seuil de rentabilité entre hébergement local et utilisation d’une API avant d’acheter un GPU.
Questions fréquemment posées
Que signifie GGUF, et en quoi diffère-t-il de GGML ?
GGUF signifie « GPT-Generated Unified Format ». GGML était le format antérieur issu du même projet ; il rompait la compatibilité à chaque ajout de nouveaux métadonnées. GGUF a introduit un bloc de métadonnées extensible sous forme de paires clé-valeur, permettant d’ajouter de nouvelles architectures et options sans invalider les anciens fichiers. Les fichiers .bin GGML antérieurs à GGUF ne sont plus chargés par la version actuelle de llama.cpp.
Quelle quantification dois-je télécharger ?
Commencez par Q4_K_M. Si le modèle laisse encore plusieurs gigaoctets de VRAM libres, passez à Q5_K_M ou Q6_K. S’il ne tient pas, préférez un modèle plus petit en Q4_K_M plutôt qu’un modèle identique en Q2_K — un modèle de 14 milliards de paramètres en 4 bits surpasse généralement un modèle de 32 milliards de paramètres dégradé en 2 bits. Vérifiez l’adéquation avec le Calculateur de VRAM à la longueur de contexte souhaitée.
Puis-je exécuter des modèles GGUF sans GPU ?
Oui — l’inférence CPU seule est précisément ce pour quoi GGUF a été conçu. La vitesse dépend de la bande passante mémoire : attendez-vous à quelques jetons par seconde (un chiffre à un seul chiffre) pour un modèle de 7 à 8 milliards de paramètres en Q4_K_M sur une mémoire RAM bureautique typique à double canal, et à des performances encore plus faibles pour des modèles plus volumineux. Les modèles légers comme Gemma 3 4B (environ 3 Go en 4 bits) constituent le choix pratique pour une inférence CPU seule.
Puis-je convertir moi-même un modèle Hugging Face au format GGUF ?
Oui. llama.cpp fournit un script de conversion (convert_hf_to_gguf.py dans les versions récentes ; le nom du fichier utilisait des traits d’union dans les versions antérieures) qui génère un GGUF en F16, puis le binaire llama-quantize le compresse vers une quantification cible. Consultez l’aide du script via --help dans la copie que vous avez clonée, et assurez-vous que votre architecture est prise en charge avant de commencer — les architectures non prises en charge échouent lors de la conversion.
Les modèles GGUF prennent-ils en charge la vision ou l’appel d’outils ?
L’appel d’outils fonctionne là où le modèle définit un modèle de discussion compatible et où votre chargeur respecte ce modèle. Les modèles multimodaux nécessitent un second fichier — un GGUF mmproj contenant le projecteur visuel, chargé en parallèle des poids textuels. Les outils multimodaux de llama.cpp ont été renommés et réorganisés à plusieurs reprises, suivez donc la documentation actuelle du dépôt plutôt qu’un tutoriel obsolète.
La quantification modifie-t-elle la fenêtre de contexte ?
Non. Le contexte est une propriété du modèle, pas de la quantification : Llama 3.3 70B dispose de 128 K et Llama 4 Scout de 10 M, que vous l’exécutiez en F16 ou en Q4_K_M. Ce qui change, c’est votre capacité à loger le cache KV correspondant à ce contexte en mémoire. Comparez contexte et tarifs entre modèles sur le Classement des grands modèles linguistiques (LLM).
