Formats de stockage
des modèles IA en 2026

Pourquoi tant de formats

Le paysage des formats de stockage de modèles IA est riche — presque chaotique. Chaque format est né d'un compromis local : sécurité contre vitesse, portabilité contre performance, simplicité contre fonctionnalité. Aucun ne domine universellement parce qu'aucun ne peut.

Cet article fait l'inventaire pratique des formats que vous rencontrerez en mission, avec une règle claire pour chacun : quand l'utiliser, quand ne pas.

Les formats de poids — vue d'ensemble

safetensors (Hugging Face) — le défaut moderne

Successeur de PyTorch .pt/.bin, défaut sur Hugging Face depuis 2023. Format binaire simple, lecture mmap (memory-mapped, instantanée sans charger en RAM), sans exécution de code à la désérialisation — fini les exploits via pickle.

Standard de fait pour publier et consommer un modèle en 2026. Si vous fine-tunez avec TRL, Unsloth ou Axolotl, vous sortez du safetensors sans y penser.

GGUF (llama.cpp) — pour l'edge et le local

Successeur de GGML, format unifié de llama.cpp. Auto-contenu (poids + tokenizer + métadonnées dans un seul fichier), portable sur CPU, ARM, Apple Silicon, GPU via Vulkan/CUDA. Supporte nativement la quantization mixed-precision (Q4_K_M, Q5_K_M, Q8_0).

Notre choix pour : démos sur laptop, dev local, déploiement edge sur Raspberry/Jetson, Mac Studio. Ollama, LM Studio, llamafile utilisent tous GGUF en interne.

ONNX — pour la portabilité cross-runtime

Open Neural Network Exchange. Format standard pour faire tourner un modèle hors de son framework d'origine. Compatible avec ONNX Runtime (Microsoft), Triton, OpenVINO (Intel), Apple Core ML via conversion.

Utile en 2026 pour : vision computer (où PyTorch reste lourd), modèles d'embedding sur CPU à grande échelle (text-embedding-3-small en ONNX tourne très bien sur Xeon), déploiement edge industriel. Moins pertinent pour les gros LLM décodeurs.

TensorRT-LLM (NVIDIA) — la perf max H100/B100

Format propriétaire NVIDIA optimisé pour leurs GPU. Le modèle est compilé pour un GPU spécifique (H100, H200, B100), avec kernels CUDA optimisés, fusion d'opérations, paged attention, speculative decoding intégré. Perf imbattable mais portabilité nulle.

Utilisé quand : chaque milliseconde compte en production sur fleet NVIDIA standardisée. Sinon, vLLM avec safetensors quantifiés (AWQ/FP8) atteint 80-90 % des perfs avec une portabilité bien meilleure.

MLX (Apple) — Apple Silicon natif

Format natif Apple pour Apple Silicon (M1/M2/M3/M4). Tire parti du Unified Memory : pas de copies CPU→GPU, mémoire totale du Mac Studio (jusqu'à 512 GB) directement accessible au modèle.

Utilisé pour : dev local sur Mac, démos client en présentation, tests rapides. Un Mac Studio M4 Ultra peut faire tourner Mistral Large 3 en MLX à 30+ tokens/s, ce qu'aucun autre laptop ne fait.

Les formats de quantization — vue d'ensemble

La quantization réduit la précision des poids (16 bits → 8, 4, voire 2 bits) pour gagner mémoire et vitesse. Mais chaque format a son tradeoff qualité/perf/portabilité.

FP8 — le sweet spot 2026 sur H100/H200

Précision float 8 bits, supportée nativement par les Tensor Cores des H100 et au-delà. Réduction mémoire 50 %, perte qualité négligeable (typiquement < 0.3 pt sur MMLU). Notre default en production quand on a des H100.

Deux variantes : E4M3 (4 bits exposant, 3 bits mantisse) pour les poids et activations classiques, E5M2 (5 bits exposant) pour les gradients en training. vLLM et TensorRT-LLM supportent E4M3 nativement.

AWQ vs GPTQ — la guerre du 4 bits

Deux algorithmes de quantization 4 bits, créés en 2023, toujours actifs en 2026. AWQ (Activation-aware Weight Quantization) préserve les outliers d'activation : meilleure qualité moyenne. GPTQ est plus simple à calibrer, écosystème plus large.

Notre choix par défaut : AWQ. Quand AWQ n'est pas disponible (modèle exotique), GPTQ. La différence se mesure en moins d'un point sur la plupart des benchmarks.

GGUF — les Q-variants

GGUF est plus qu'un format : c'est une famille. Les Q-variants désignent des stratégies de quantization mixed-precision. Les plus utilisées en 2026 :

• Q4_K_M : 4 bits pour la majorité des poids, 5-6 bits pour les couches sensibles. Le default moderne. ~27 % de la taille FP16.
• Q5_K_M : 5 bits, qualité supérieure à Q4 pour 30 % d'inflation. Recommandé si la mémoire le permet.
• Q8_0 : 8 bits, qualité quasi-FP16. Sur Mac Studio avec 64+ GB de mémoire unifiée, c'est jouable.
• Q2_K : 2 bits. Perte qualité significative, mais permet de faire tourner un 70B sur un MacBook 16GB. Démos uniquement.

MXFP4 — le format Blackwell natif

Microscaling FP4 : format float 4 bits supporté nativement par les Tensor Cores Blackwell (B100/B200/B300, déployés depuis 2025). Qualité quasi-identique à FP8 pour 50 % de la mémoire. Perf inférence record.

Devient le default en 2026-2027 sur les nouveaux clusters NVIDIA. Pour l'instant, requiert TensorRT-LLM. vLLM gère depuis 0.7.

Notre matrice de décision

Le choix de format n'est jamais isolé. Il dépend du GPU cible, de la contrainte de mémoire, du tradeoff qualité/coût acceptable.

Cas 1 — Production sur H100/H200, charge forte

Default : safetensors FP8. Si la mémoire le permet, BF16. Si le modèle est trop gros : AWQ 4-bit. Serving via vLLM.

Cas 2 — Production sur B100/B200 (Blackwell)

Default : MXFP4 via TensorRT-LLM. Perf maximale, qualité préservée.

Cas 3 — Edge, embarqué, IoT

Default : GGUF Q4_K_M. CPU-friendly, llama.cpp ou Ollama.

Cas 4 — Mac dev / démo

Default : MLX 4-bit ou GGUF Q4_K_M. Apple Silicon brille en mémoire unifiée.

Cas 5 — Embedder à grande échelle sur CPU

Default : ONNX. ONNX Runtime + Intel MKL ou OpenVINO. Excellent débit sur Xeon.

Cas 6 — Distribution interne entreprise

Default : safetensors BF16 dans MLflow Registry. Quantization à la demande au déploiement selon le GPU cible.

Pièges fréquents

Piège 1 — Quantifier sans benchmark

La perte qualité de quantization varie selon le modèle et selon la tâche. Toujours benchmarker sur votre jeu d'évaluation avant d'envoyer en production. La perte mesurée sur MMLU n'est pas la perte sur votre tâche métier.

Piège 2 — Mélanger les tokenizers

Un modèle quantifié garde son tokenizer original. Si vous avez fine-tuné avec un tokenizer étendu (nouveaux tokens spéciaux), il faut distribuer le tokenizer modifié avec les poids. GGUF embarque tout dans un fichier : avantage. Safetensors : il faut packager le bundle complet.

Piège 3 — Compter sur la portabilité de TensorRT-LLM

Un engine TensorRT-LLM est compilé pour une combinaison précise de GPU + version CUDA + version TRT-LLM. Migrer entre H100 et H200 ou monter de version requiert recompilation. À gérer dans la chaîne CI/CD.

Piège 4 — Croire que GGUF est aussi rapide que vLLM sur GPU serveur

GGUF excelle sur CPU et edge. Sur GPU serveur, llama.cpp est ~3-5× plus lent que vLLM sur le même H100. Ne pas se tromper de format selon la cible.

Notre recommandation

Pour 80 % de nos missions : safetensors BF16 en source de vérité, quantification vers FP8 ou AWQ 4-bit au déploiement selon le GPU, le tout servi par vLLM. C'est l'arbitrage qui maximise la portabilité, la qualité, la perf sans s'enfermer dans un écosystème propriétaire.

Les 20 % restants sont des cas spécifiques : edge (GGUF), Mac (MLX), perf max NVIDIA (TensorRT-LLM + MXFP4), embeddings CPU à grande échelle (ONNX). Choisir lucidement, sans dogme.