GGUF est un format de fichier binaire utilisé pour stocker des modèles destinés à l’inférence avec GGML et des runtimes compatibles comme llama.cpp ou des outils qui s’appuient dessus. Un fichier GGUF n’est pas seulement “un modèle quantifié” : il peut contenir des tensors, des métadonnées, des informations de tokenizer et parfois être en F16. La quantification est fréquente, pas obligatoire.
Repère documentaire : documentation officielle du fonctionnement présenté.
Ce que contient un GGUF
Un GGUF regroupe les poids du modèle sous forme de tensors et une structure clé-valeur de métadonnées. Ces métadonnées peuvent décrire l’architecture, le tokenizer, la taille de contexte, les types de quantification ou d’autres informations nécessaires au runtime. Le tokenizer compte beaucoup : si le runtime interprète mal les tokens spéciaux ou le template de chat, les réponses peuvent devenir mauvaises même si les poids sont corrects.
Fichier unique ou shards
Beaucoup de distributions GGUF se présentent comme un fichier unique : model.Q4_K_M.gguf. Certains modèles très gros peuvent être découpés en plusieurs fichiers ou venir d’une conversion depuis des shards Safetensors. Le runtime choisi doit supporter la forme fournie. Avant de télécharger, vérifiez la documentation du dépôt et l’outil d’exécution visé.
F16, Q8, Q4 : ne pas confondre
Un GGUF F16 garde des poids en 16 bits et peut être volumineux. Un GGUF Q4 compresse davantage, mais peut dégrader certaines tâches. Les suffixes de fichiers donnent une indication, pas une garantie universelle de qualité. Comparez sur vos prompts réels : français, JSON, code, résumé long, raisonnement, selon votre usage.
Provenance, checksum et licence
Avant d’utiliser un GGUF, notez le modèle source, l’auteur de la conversion, la licence, la date, le hash du fichier et le runtime testé. Deux fichiers portant un nom proche peuvent venir de conversions différentes. Pour une production, conservez un checksum et évitez de remplacer silencieusement le fichier : sinon vous ne saurez plus quelle version a produit les sorties.
Décision pratique
Choisissez d’abord le runtime, puis le modèle, puis le niveau de quantification. Si vous partez de la mémoire disponible uniquement, vous risquez de prendre un fichier qui démarre mais échoue sur la tâche. Un bon test GGUF doit inclure chargement, prompt court, prompt long, format attendu, mesure de mémoire et vérification de licence.
Compatibilité runtime
Avant de conclure qu’un GGUF est mauvais, testez la compatibilité. Un runtime ancien peut ne pas gérer une architecture récente, un tokenizer particulier ou un type de quantification. Mettez à jour l’outil, puis relancez un prompt minimal. Si le fichier charge mais répond n’importe quoi, vérifiez le template de chat et les tokens spéciaux.
Procédure de réception
Pour un modèle local sérieux, créez une fiche : URL du dépôt, fichier exact, taille, checksum, licence, commande de lancement, runtime, prompt de test et résultat attendu. Cette fiche évite de remplacer un fichier par “presque le même” et de perdre la reproductibilité d’un benchmark interne.
Erreur courante
Un fichier GGUF téléchargé depuis un dépôt communautaire peut être techniquement valide mais mal adapté à votre runtime ou à votre usage. Ne mélangez pas provenance du modèle, conversion et quantification : ce sont trois décisions séparées à documenter.
Pour les bases : définition d’un modèle de langage.
