Format SafeTensors : guide de sérialisation sécurisée des modèles ML

Le format s'intègre naturellement aux pipelines ML modernes car il se concentre sur ce que la plupart des checkpoints contiennent déjà :

• Tenseurs
• Shapes
• Types de données
• Valeurs de poids

Au lieu d'agir comme un système de sérialisation Python généraliste, SafeTensors fonctionne comme une couche de stockage dédiée aux paramètres de modèle.

Bien que Hugging Face ait initialement développé SafeTensors pour son écosystème, le format en lui-même est agnostique au framework. Il a rejoint la PyTorch Foundation récemment (en avril 2026) et prend en charge PyTorch, TensorFlow, JAX, Flax, NumPy et d'autres frameworks ML.

Le problème de Pickle : pourquoi il fallait un nouveau format

Le format Pickle de Python a été conçu pour des applications Python générales, où les développeurs doivent souvent sauvegarder et restaurer des objets Python entiers avec leur état interne, leurs méthodes et leur logique de reconstruction.

Les checkpoints de machine learning n'ont généralement pas besoin d'un tel niveau de stockage. La plupart des fichiers de modèles contiennent principalement des tenseurs : matrices de poids, embeddings, biais et autres paramètres numériques. En pratique, le checkpoint n'est donc que des données numériques structurées.

Mais un fichier .pkl fait plus que stocker des données. Il peut aussi contenir des instructions pour Python sur la façon de reconstruire des objets au chargement. Autrement dit, la désérialisation n'est pas une simple lecture : elle peut exécuter du code. Et si ce code est malveillant, le risque de sécurité est majeur. 

Comment pickle permet l'exécution de code arbitraire

Python reconstruit les objets lors de la désérialisation pickle en utilisant des méthodes spéciales comme __reduce__(). Les classes peuvent définir cette méthode pour indiquer à pickle comment rebâtir l'objet au retour en mémoire.

Par exemple, __reduce__() peut renvoyer une fonction appelable ainsi que ses arguments. Lors de la désérialisation, Python exécute cette fonction pour reconstruire l'objet. Exemple de code :

import pickle
import os

class Demo:
    def __reduce__(self):
        return (os.system, ("echo 'Code executed during deserialization'",))

payload = pickle.dumps(Demo())

pickle.loads(payload)

Quand pickle.loads() s'exécute, Python lance la fonction renvoyée par __reduce__(). Dans cet exemple, la désérialisation déclenche une commande shell via os.system().

Le problème ne vient pas de la commande shell en soi. __reduce__() peut retourner n'importe quelle fonction appelable avec des arguments arbitraires selon la logique. Un fichier Pickle peut donc appeler d'autres fonctions, télécharger des fichiers, modifier l'environnement ou exécuter du code malveillant au chargement. C'est pourquoi la documentation Python met explicitement en garde contre le chargement de données pickle depuis des sources non fiables.

Le risque à l'ère du partage de modèles

Des plateformes comme Hugging Face Hub hébergent désormais plus d'un million de modèles partagés par des chercheurs, des startups, des passionnés et des contributeurs anonymes. L'écosystème avance vite car les développeurs peuvent télécharger et tester des modèles instantanément. Mais la plupart des checkpoints téléversés ne sont pas audités individuellement avant diffusion.

Beaucoup de checkpoints PyTorch reposent encore sur la sérialisation basée sur pickle via des formats comme .pt ou .bin. Lorsqu'on charge l'un de ces fichiers, Python peut exécuter de la logique de désérialisation intégrée au checkpoint. Si le checkpoint est malveillant, cette logique peut voler des identifiants, lire des variables d'environnement, télécharger des charges utiles ou exécuter du code à distance pendant le chargement.

C'est précisément le problème que SafeTensors résout. Au lieu de sérialiser des objets Python arbitraires, il stocke uniquement les données des tenseurs et les métadonnées nécessaires pour les charger correctement. Le chargement d'un fichier .safetensors ne requiert pas d'exécuter de logique de reconstruction Python, ce qui réduit fortement la surface d'attaque.

Comment fonctionne le format SafeTensors

Maintenant que vous savez ce qu'est SafeTensors et pourquoi il existe, regardons sa structure et son fonctionnement.

La structure en en-tête et données

Un fichier SafeTensors comporte deux parties : un en-tête JSON suivi des données brutes des tenseurs.

L'en-tête stocke les métadonnées pour chaque tenseur, notamment 

• Noms des tenseurs
• Shapes
• Types de données
• Offsets en octets

Après l'en-tête, le fichier stocke contiguëment les octets bruts des tenseurs.

L'en-tête joue le rôle de table des matières. Il indique au chargeur quels tenseurs existent et où ils se trouvent dans le fichier, à l'image d'un index de base de données qui pointe vers les enregistrements. SafeTensors limite la taille de cet en-tête à 100 Mo pour éviter les charges de métadonnées surdimensionnées.

Zero-copy et chargement mémoire mappé

SafeTensors accélère le chargement grâce au mappage mémoire. Plutôt que de reconstruire des objets Python à la désérialisation, les frameworks peuvent mapper directement les données des tenseurs du disque vers la mémoire. Cela réduit les copies inutiles et baisse la charge CPU au chargement.

D'après les benchmarks Hugging Face, SafeTensors charge les poids environ 76× plus vite que PyTorch sur CPU et environ 2× plus vite sur GPU. Bien sûr, l'accélération exacte dépend du matériel et de la taille du checkpoint, mais éviter la désérialisation Python améliore systématiquement les performances de chargement.

Chargement paresseux et désérialisation partielle

SafeTensors charge des tenseurs précis par leur nom au lieu de lire l'intégralité du checkpoint en mémoire d'un coup.

C'est utile pour les grands modèles distribués sur plusieurs GPU. Prenons le modèle BLOOM de 176 milliards de paramètres. Avec des checkpoints PyTorch standard, le système devait d'abord désérialiser tous les poids avant de les répartir entre les périphériques, ce qui prenait environ 10 minutes. 

Avec SafeTensors, chaque GPU a chargé uniquement les fragments de tenseurs dont il avait besoin. Cela a ramené le temps de démarrage du modèle à environ 45 secondes sur 8 GPU.

SafeTensors vs autres formats de sérialisation

SafeTensors excelle pour stocker et charger des poids de modèles de façon sûre et efficace, mais ce n'est pas pour autant un remplaçant universel. Le bon choix dépend de ce que vous stockez et de l'étape de la chaîne où se situe le modèle.

Nous avons déjà beaucoup parlé de pickle, concentrons-nous sur d'autres formats.

SafeTensors vs GGUF

SafeTensors et GGUF résolvent des problèmes différents. 

GGUF, pour GGML Unified Format, a été conçu pour l'inférence quantifiée dans des runtimes comme llama.cpp. Le format cible le déploiement efficace de modèles compressés, en particulier pour l'inférence CPU et en périphérie. 

SafeTensors intervient plus tôt dans la chaîne. La plupart des checkpoints SafeTensors stockent des tenseurs en pleine précision ou prêts pour l'entraînement, utilisés pour l'entraînement, le fine-tuning, la fusion ou l'inférence distribuée. Le format privilégie un chargement sûr, la compatibilité avec des frameworks comme PyTorch et un accès efficace aux tenseurs pendant l'entraînement et la mise en production.

Ils peuvent donc se compléter plutôt que d'être en concurrence directe. Exemple de flux :

• Entraîner ou affiner le modèle avec PyTorch et des checkpoints SafeTensors
• Quantifier le modèle final
• L'exporter en GGUF pour le déploiement dans llama.cpp ou des runtimes d'inférence en périphérie

SafeTensors vs ONNX

SafeTensors se concentre sur le stockage sûr des poids et leur chargement efficace au sein de frameworks comme PyTorch. Il ne stocke que des tenseurs et des métadonnées, ce qui le rend léger et rapide pour le partage de checkpoints, le fine-tuning et les workflows d'entraînement.

ONNX adopte une approche plus large. Il stocke le graphe de calcul complet avec les paramètres du modèle. ONNX est donc utile lorsque vous souhaitez exporter un modèle d'un framework et l'exécuter ailleurs.

Par exemple, des équipes qui entraînent et affinent des LLM avec PyTorch préféreront généralement des checkpoints SafeTensors pour leur chargement rapide et leur intégration directe dans les workflows existants. Mais si la même équipe doit déployer le modèle dans TensorRT, ONNX Runtime ou un moteur d'inférence en périphérie, l'export en ONNX s'impose.

Utiliser SafeTensors en pratique

L'une des raisons de la diffusion rapide de SafeTensors dans l'écosystème PyTorch est son API familière. Vous continuez de manipuler des dictionnaires d'état et des tenseurs comme d'habitude.

Sauvegarde et chargement de tenseurs

Le flux de base ressemble à s'y méprendre à la gestion classique des checkpoints PyTorch. Exemple :

import torch
from safetensors.torch import save_file, load_file

tensors = {
    "weights": torch.randn(2, 2),
    "bias": torch.zeros(2)
}

save_file(tensors, "model.safetensors")

loaded_tensors = load_file("model.safetensors")

print(loaded_tensors["weights"])

save_file() écrit les tenseurs au format .safetensors, tandis que load_file() les recharge en mémoire.

SafeTensors prend aussi en charge le chargement sélectif via safe_open(), utile avec de gros checkpoints lorsque vous n'avez besoin que de quelques tenseurs.

from safetensors import safe_open

with safe_open("model.safetensors", framework="pt") as f:
    weights = f.get_tensor("weights")

print(weights)

Au lieu de charger tout le checkpoint, get_tensor() lit uniquement le tenseur demandé.

Convertir des modèles existants en safetensors

Le schéma standard est :

1. Charger le modèle existant
2. Extraire le dictionnaire d'état
3. Le sauvegarder avec save_file()

from transformers import AutoModel
from safetensors.torch import save_file

model = AutoModel.from_pretrained("bert-base-uncased")

save_file(model.state_dict(), "model.safetensors")

state_dict() renvoie les poids du modèle sous forme de tenseurs, que SafeTensors peut stocker directement. 

Si le modèle est déjà sur Hugging Face Hub, vous n'avez même pas toujours besoin d'une conversion locale. Hugging Face propose une conversion de checkpoints intégrée pour de nombreux modèles hébergés via l'interface du Hub.

Formats de sérialisation : tableau comparatif

SafeTensors en 2026 : la PyTorch Foundation et la suite

En avril 2026, Hugging Face a contribué SafeTensors à la PyTorch Foundation au sein de la Linux Foundation. Le projet se trouve désormais aux côtés de PyTorch, vLLM, DeepSpeed et Ray, sous la gouvernance de la fondation.

Ce mouvement signale que SafeTensors n'est plus seulement un projet Hugging Face. Il devient une infrastructure partagée pour l'écosystème ML. 

L'annonce précise également la direction que le format s'apprête à prendre.

Chargement adapté au périphérique

Une priorité majeure est le chargement conscient du périphérique. Aujourd'hui, de nombreux workflows chargent encore les tenseurs en mémoire CPU avant de les transférer vers des périphériques CUDA ou ROCm. Cette étape intermédiaire accroît la latence de démarrage, surtout pour les systèmes distribués de grande taille. 

Les mainteneurs de SafeTensors travaillent sur des chemins de chargement directs vers les périphériques pour réduire les copies CPU inutiles et déplacer les tenseurs directement sur les accélérateurs. 

Chargement distribué

Le support du chargement distribué évolue également. Les systèmes d'inférence modernes n'exécutent quasiment plus de modèles sur un seul GPU. Le parallélisme tensoriel et le parallélisme de pipeline sont devenus des schémas de déploiement standard pour les grands modèles, mais les API de chargement de checkpoints restent fragmentées selon les frameworks. 

SafeTensors étend la prise en charge du chargement conscient des fragments et des dispositions de tenseurs distribués, afin que les frameworks coordonnent plus efficacement le chargement des checkpoints à travers les périphériques. 

Workflows de quantification modernes

Le format s'adapte aussi aux workflows de quantification récents. Les systèmes d'inférence s'appuient de plus en plus sur les formats FP8, GPTQ et AWQ pour réduire l'empreinte mémoire et les coûts de service. 

Plutôt que de forcer les frameworks à gérer cela via une logique de sérialisation ad hoc, SafeTensors ajoute une prise en charge formelle des formats de tenseurs en plus basse précision et à quantification par blocs, directement dans le format. 

Aujourd'hui, les développeurs doivent encore opter manuellement pour SafeTensors en adaptant les flux de sauvegarde et de chargement. Mais des travaux sont en cours pour une intégration plus profonde avec le système de sérialisation natif de PyTorch. Si cela aboutit, SafeTensors pourrait cesser d'être un format alternatif et devenir la façon par défaut de stocker les modèles dans PyTorch.

En conclusion

Pendant des années, les développeurs ont partagé des checkpoints avec des systèmes de sérialisation susceptibles d'exécuter du code Python arbitraire au chargement. Avec des hubs publics hébergeant des millions de checkpoints, les risques de sécurité sont devenus difficiles à ignorer.

SafeTensors a changé la donne en réduisant le périmètre du format. Au lieu d'essayer de sérialiser des objets Python entiers, il se concentre sur le stockage des tenseurs et des métadonnées nécessaires pour les charger. Cette conception plus simple supprime les risques de désérialisation liés aux checkpoints pickle tout en améliorant la vitesse de chargement et l'efficacité mémoire.

Lorsque vous n'avez besoin que des poids du modèle, il n'y a aucune raison d'exécuter du code arbitraire à la désérialisation : dans ces cas, mieux vaut utiliser SafeTensors.

Si vous souhaitez aller plus loin avec les outils ML modernes, les formats de modèles et les workflows Hugging Face, nos cours Deep Learning in Python et Working with Hugging Face sont une excellente étape suivante. Ils couvrent des workflows pratiques pour entraîner, affiner et déployer des modèles avec les outils de l'écosystème IA actuel.