> GGUF vs safetensors — c'est le runtime qui décide, pas le format▋

DuckDuckGo autocomplète gguf vs safetensors comme si c'était un combat de cage entre deux extensions de fichier. C'est un contrôle d'accès. Choisis GGUF et une étagère de runtimes s'ouvre — llama.cpp, Ollama, LM Studio, Jan. Choisis safetensors et une autre étagère s'ouvre — transformers, vLLM, ComfyUI. Le format, c'est la liste des portes qui s'ouvriront ; tout le reste suit. Le mensonge que cet article refuse : que le combat se décide sur des chiffres de vitesse que personne n'a jamais égalés sur la même machine. Ce que le dossier te donne gratuitement — et ce que la plupart des arguments sautent — c'est ce que chaque conteneur pèse, et où chacun peut seulement s'ouvrir.

Entre quoi choisis-tu, au juste ?

GGUF est un conteneur fichier unique construit par les auteurs de llama.cpp, et la quantification y est cuite par tenseur — l'échelle de quantification dont tout le monde dispute n'existe que dans ce format. Un seul fichier porte les poids, le tokenizer et le modèle de chat : le fichier est la distribution. Safetensors est un conteneur de sérialisation — un en-tête JSON plus les octets bruts des tenseurs — et il porte la précision telle que le dépôt d'entraînement l'a expédiée, généralement BF16 ou FP16. Il ne quantifie pas ; il stocke.

Safetensors tient son nom de son unique travail : garantir que personne ne se fait pickler au chargement du modèle. Le pickle de Python exécute du code au déballage ; safetensors n'exécute rien — c'est tout l'argument sécurité, et c'est pourquoi l'écosystème Hugging Face l'a standardisé.

Pèse le même modèle dans chaque conteneur et les philosophies se voient dans les octets. Le 14 octobre 2026, le même Qwen3-0.6B s'expédiait comme : GGUF Q4_K_M, 396,705,472 octets (397 MB) · GGUF BF16, 1,198,182,848 octets (1.20 GB) · safetensors BF16, 1,503,300,328 octets (1.50 GB). Le conteneur quantifié tient un quart du pleine précision parce qu'il tient un quart de la précision — et chacun de ces chiffres est à un curl -I de ton terminal, aucun banc de test requis. Savoir si la précision manquante te coûte en qualité est une question de fidélité que les octets ne tranchent pas ; l'article sur les niveaux de quant détaille ce que chaque cran abandonne.

Le format n'est pas une préférence. C'est la liste des runtimes qui ouvriront ton fichier.

Que disent les octets ?

La règle honnête pour une lecture de dossier : seulement les chiffres que le dossier énonce, attribués, pas de cosplay de bench. La table, c'est un modèle, trois conteneurs, les octets exacts tels qu'expédiés — vérifie-les toi-même avant de faire confiance à quoi que ce soit.

Conteneur	Précision	Octets tels qu'expédiés	Part de la pleine précision
GGUF Q4_K_M	quantifié 4 bits	396,705,472 (397 MB)	26%
GGUF BF16	pleine, empaquetage llama.cpp	1,198,182,848 (1.20 GB)	80%
safetensors BF16	pleine, tenseurs bruts	1,503,300,328 (1.50 GB)	100%

vérifier : curl -sIL https://huggingface.co/unsloth/Qwen3-0.6B-GGUF/resolve/main/Qwen3-0.6B-Q4_K_M.gguf | grep -i content-length → le compte d'octets, le jour même ou n'importe quel jour · le même one-liner contre les fichiers BF16 et safetensors

Lis la table honnêtement. Les 26 %, c'est toute la promesse de l'échelle de quantification : quatre bits là où il y en avait seize, sur disque et en RAM. L'écart entre les deux lignes pleine précision — 1.20 contre 1.50 GB — c'est du coût d'empaquetage, pas de la physique : l'empaquetage BF16 de llama.cpp range les mêmes tenseurs plus maigrement que le dump brut. Ce que les octets ne peuvent pas dire, c'est la vitesse ou la qualité ; une colonne de tokens par seconde sans machine équivalente derrière, c'est du bruit de forum, et cet article refuse d'en imprimer une. La lecture llama.cpp contre Ollama a heurté le même mur côté moteur : même fichier, mêmes maths, wrapper différent.

Ce que le dossier ne peut pas te dire

Trois murs, énoncés platement. Un : la qualité — Q4 contre BF16 est un compromis de fidélité, et aucun compte d'octets ne le mesure. Deux : la vitesse — temps de chargement et tokens par seconde appartiennent à un bench équivalent sur une machine nommée, que cet article n'a pas, donc il n'en imprime pas. Trois : l'échelle — les ratios d'octets d'un modèle 0.6B gardent leur forme à 70B, mais les attentes absolues que tu sentiras à 70B sont un autre article sur un autre matériel.

Où chaque format tourne-t-il vraiment ?

C'est la partie qui décide vraiment. GGUF s'ouvre dans llama.cpp, Ollama, LM Studio, Jan — l'écosystème local fichier unique. vLLM lit GGUF aussi, via son plugin, sur GPU, avec des réserves. Safetensors s'ouvre dans transformers, vLLM nativement, ComfyUI, et l'outillage MLX d'Apple. Le chevauchement aux bords est instructif : Ollama — l'électroménager construit sur un moteur GGUF — expédie quand même un runner MLX pour que les utilisateurs d'Apple Silicon chargent des poids dérivés de safetensors. Même l'électroménager se couvre.

Tu fais déjà tourner	Ton format se choisit tout seul	Pourquoi
Ollama, LM Studio ou llama-server	GGUF	Leurs moteurs mangent GGUF nativement ; les fichiers quantifiés tiennent sur les petits disques
Un pipeline Python/transformers	safetensors	from_pretrained est le chemin natif ; aucune étape de conversion à maintenir
vLLM sur un serveur GPU	safetensors	Natif, pas de plugin, pas de réserves GGUF — les réserves GGUF elles-mêmes
ComfyUI ou un pipeline d'images	safetensors	L'écosystème diffusion fait commerce de checkpoints safetensors
Un petit disque et une petite machine	GGUF Q4_K_M	397 MB contre 1.50 GB pour les mêmes poids

GGUF fait de la quantification le défaut ; safetensors fait de la pleine précision le défaut. Ce défaut-là est l'essentiel de la décision.

Lequel servir, au final ?

Regarde ce qui est déjà installé avant de consulter une table. Si la machine répond à ollama run, tu vis en pays GGUF — prends le fichier Q4_K_M et arrête de lire des forums. Si ta journée est Python, ou si ta couche de service est vLLM, safetensors n'a jamais vraiment été un choix ; c'est la langue natale de l'écosystème. Convertir entre les deux est possible et ne vaut presque jamais le coup : chaque conversion est un nouvel endroit où les poids peuvent différer en silence.

La ligne d'honnêteté obligatoire, maison : J'ai lu le dossier, je ne l'ai pas exécuté. Chaque chiffre de cette page vient des fichiers tels qu'expédiés, relevés le matin de la publication — pas de banc de test, pas de cosplay de tokens par seconde. Ce que le dossier établit, c'est la forme du compromis — un quart des octets pour le conteneur quantifié, deux runtimes qui se chevauchent à peine, et une précision par défaut de chaque côté qui décide en silence pour la plupart des gens. Tout le cluster — runners, formats, niveaux de quant, le lot — est indexé sur le hub local-LLM.

Personne n'a jamais changé de format pour la vitesse. Les gens ont changé de runtime pour une fonctionnalité, et le format est venu avec, comme le ticket.

Alors, deux questions renvoyées par-dessus le mur : quel format ta machine du quotidien ouvre-t-elle vraiment — et à quoi ressemblerait un bench équitable de ces trois conteneurs sur ton matériel ? Nomme la machine et le modèle en commentaires ; le mieux spécifié fixe la fiche technique du prochain article.