Formats de modèles : GGUF, SafeTensors, MLX

Les modèles d’IA peuvent être stockés dans différents formats, chacun optimisé pour des cas d’usage spécifiques. Comprendre ces formats est essentiel pour choisir la meilleure solution selon votre matériel.

GGUF — le format universel

GGUF (GPT-Generated Unified Format) est un format binaire développé par Georgi Gerganov, créateur de llama.cpp. Il succède à l’ancien format GGML et est devenu le standard de facto pour exécuter des LLM en local, particulièrement sur CPU ou en configuration CPU/GPU hybride.

Avantage clé. GGUF encapsule tout dans un seul fichier : les poids du modèle, le tokenizer (le composant qui découpe le texte en tokens — voir Comprendre les LLM open source), la configuration et les métadonnées. Vous téléchargez un fichier et c’est prêt à l’emploi.

Structure interne d’un fichier GGUF

Un fichier GGUF est composé de quatre sections majeures écrites séquentiellement :

Header  →  Métadonnées  →  Tensor Info  →  Tensor Data
(Magic +   (Key-Value     (Noms, shapes,  (Poids
 Version)   pairs)         types)          quantifiés)

1. Header

Contient le « magic number » (GGUF) et la version du format. Supporte little-endian (par défaut) et big-endian.

2. Métadonnées (key-value pairs)

Stocke la configuration du modèle sous forme de paires clé-valeur :

general.architecture: 'qwen3moe'
general.name: 'Qwen3.6-35B-A3B'
qwen3moe.context_length: 262144
general.file_type: 10
tokenizer.ggml.model: 'gpt2'
tokenizer.ggml.tokens: [...]   # Vocabulaire complet

3. Tensor Information Array

Décrit chaque tenseur : nom, nombre de dimensions, shape, type de quantification et offset dans la section data. Note importante : les dimensions sont stockées en ordre inverse (ex : [4096, 32, 128] devient [128, 32, 4096]).

4. Tensor Data Section

Contient les poids réels, alignés sur 32 bytes (GGUF_DEFAULT_ALIGNMENT). Cette section est généralement memory-mapped pour un chargement ultra-rapide sans copie mémoire.

Caractéristiques de GGUF

• Auto-suffisant : contient modèle + tokenizer + configuration.
• Polyvalent : fonctionne sur CPU, GPU ou les deux (hybride).
• Quantification intégrée : supporte 1.5-bit à 8-bit nativement.
• Memory-mapping : chargement rapide sans copie des tenseurs.
• Splitting : support des fichiers fragmentés pour les très grands modèles.
• Compatible : utilisable avec Ollama, LM Studio, llama.cpp, GPT4All, etc.

C’est le format que SoberCloud privilégie : lors de nos tests sur un Strix Halo (Ryzen AI MAX+ 395, 128 Gio de mémoire unifiée), nous avons mesuré Qwen3.6-35B-A3B en GGUF Q5_K_XL (~26 Go) via llama.cpp Vulkan, à environ 73 tokens/s. Sur ce matériel limité par la bande passante mémoire, un modèle MoE comme celui-ci surpasse un modèle dense à taille de fichier équivalente, car seuls 3B de paramètres sont actifs par token.

SafeTensors — le format sécurisé

SafeTensors est un format développé par Hugging Face pour remplacer les fichiers pickle de PyTorch, qui présentaient des vulnérabilités de sécurité (exécution de code arbitraire au chargement).

Avantages de SafeTensors

• Sécurité : pas de code exécutable, uniquement des données.
• Chargement rapide : memory-mapping natif, temps de chargement réduits.
• Zero-copy : accès direct aux tenseurs sans désérialisation.
• Standard HuggingFace : format par défaut de l’écosystème Transformers.
• Multi-framework : compatible PyTorch, TensorFlow, JAX, etc.

À noter. Contrairement à GGUF qui est un format « tout-en-un », SafeTensors ne contient que les poids. Le tokenizer et la configuration sont stockés séparément (tokenizer.json, config.json).

C’est sur ce format que reposent les poids servis par vLLM lors de nos tests sur une RTX 3090 (24 Go), où nous exécutons Qwen3.6-27B quantifié int4 AutoRound, avec un contexte de 81k tokens grâce à un cache KV en fp8_e5m2.

MLX — le format Apple Silicon

MLX est un format développé par Apple Research, optimisé pour les puces Apple Silicon (M1/M2/M3/M4). Il exploite la mémoire unifiée des Mac où CPU et GPU partagent la même RAM, éliminant les coûteux transferts de données.

Structure des modèles MLX

Un modèle MLX est généralement un dossier contenant :

model/
├── config.json          # Configuration du modèle
├── model.safetensors    # Poids (format SafeTensors)
├── tokenizer.json       # Tokenizer
├── tokenizer_config.json
└── special_tokens_map.json

Caractéristiques de MLX

• Mémoire unifiée : zéro copie entre CPU et GPU, accès direct aux tenseurs.
• Évaluation paresseuse : les calculs sont différés et optimisés automatiquement.
• Quantification native : support 4-bit et 8-bit intégré via mlx_lm.convert.
• Performance : comparable ou supérieure à llama.cpp sur Apple Silicon, avec un avantage sur les modèles FP16.
• API NumPy-like : syntaxe familière pour les développeurs Python.

Conversion vers MLX. Vous pouvez convertir n’importe quel modèle HuggingFace vers MLX avec quantification :

mlx_lm.convert --hf-path Qwen/Qwen3.6-27B-Instruct --mlx-path ./qwen-mlx -q

Comparaison des formats de stockage

Format	Type	Contenu	Plateforme	Cas d’usage principal
GGUF	Format fichier	Modèle + Tokenizer + Config	Universel	Inférence locale CPU/GPU
SafeTensors	Format fichier	Poids uniquement	Universel	Entraînement, HuggingFace
MLX	Dossier structuré	Poids + Tokenizer + Config	Apple Silicon	Inférence Mac M1/M2/M3/M4
PyTorch (.pt/.bin)	Format fichier	Poids + Code (pickle)	PyTorch	Legacy, déconseillé

Formats vs méthodes de quantification. Il est crucial de distinguer les formats de fichiers (GGUF, SafeTensors) des méthodes de quantification (GPTQ, AWQ, EXL2, AutoRound). GPTQ, AWQ et EXL2 sont des algorithmes : leurs poids quantifiés sont généralement stockés en SafeTensors dans la structure Hugging Face standard. Seul GGUF est à la fois un format et intègre ses propres méthodes de quantification (K-quants).

Pour aller plus loin

• Comprendre les LLM open source — architecture, tokens et lexique.
• Quantification GGUF et front de Pareto — choisir le bon niveau de quantification.
• Stack d’inférence llama.cpp et vLLM — l’infra SoberCloud en pratique.