SafeTensors-Format: Der Leitfaden für sichere ML-Modellserialisierung

Das Format passt auch nahtlos in moderne ML-Pipelines, weil es sich auf das konzentriert, was die meisten Checkpoints ohnehin enthalten: 

• Tensoren
• Shapes
• Datentypen
• Gewichtswerte

Statt wie ein universelles Python-Serialisierungssystem zu agieren, fungiert SafeTensors als dedizierte Speicherschicht für Modellparameter.

Auch wenn Hugging Face SafeTensors ursprünglich für sein eigenes Ökosystem entwickelt hat, ist das Format selbst framework-agnostisch. Es ist kürzlich (im April 2026) der PyTorch Foundation beigetreten und unterstützt PyTorch, TensorFlow, JAX, Flax, NumPy und weitere ML-Frameworks.

Das Pickle-Problem: Warum ein neues Format nötig war

Pythons Pickle-Format wurde für allgemeine Python-Anwendungen entwickelt, in denen komplette Python-Objekte mitsamt internem Zustand, Methoden und Rekonstruktionslogik gespeichert und wiederhergestellt werden müssen.

ML-Checkpoints benötigen diesen Umfang in der Regel nicht. Die meisten Modelldateien speichern vor allem Tensoren: Gewichtsmatrizen, Embeddings, Biases und andere numerische Parameter. In der Praxis besteht der Checkpoint also im Wesentlichen aus strukturierten numerischen Daten.

Eine .pkl-Datei macht jedoch mehr als nur Daten zu speichern. Sie kann auch Anweisungen enthalten, wie Python beim Laden Objekte wieder aufbaut. Das heißt: Deserialisierung ist keine passive Leseoperation, sondern kann Code ausführen. Und wenn dieser Code bösartig ist, wird daraus ein ernstes Sicherheitsproblem. 

Wie Pickle willkürliche Codeausführung ermöglicht

Python rekonstruiert Objekte während der Pickle-Deserialisierung mithilfe spezieller Methoden wie __reduce__(). Klassen können diese Methode definieren, um Pickle genau mitzuteilen, wie das Objekt beim Laden wieder aufgebaut werden soll.

Zum Beispiel kann __reduce__() eine aufrufbare Funktion samt Argumenten zurückgeben. Während der Deserialisierung führt Python diese Funktion aus, um das Objekt zu rekonstruieren. Beispielcode:

import pickle
import os

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

payload = pickle.dumps(Demo())

pickle.loads(payload)

Wenn pickle.loads() läuft, führt Python die von __reduce__() zurückgegebene Funktion aus. In diesem Beispiel löst die Deserialisierung über os.system() einen Shell-Befehl aus.

Das Problem ist nicht der Shell-Befehl an sich. __reduce__() kann jede aufrufbare Funktion und beliebige Argumente zurückgeben. Eine Pickle-Datei kann also andere Funktionen aufrufen, Dateien herunterladen, die Umgebung verändern oder beim Laden schädlichen Code ausführen. Deshalb warnt die Python-Dokumentation ausdrücklich davor, Pickle-Daten aus nicht vertrauenswürdigen Quellen zu laden.

Das Risiko in der Ära des Modell-Sharings

Plattformen wie der Hugging Face Hub hosten inzwischen über eine Million Modelle von Forschenden, Startups, Hobbyist:innen und anonymen Beitragenden. Das Ökosystem ist so dynamisch, weil Entwickler:innen Modelle sofort herunterladen und testen können. Die meisten hochgeladenen Checkpoints werden jedoch vor der Verteilung nicht einzeln geprüft.

Viele PyTorch-Checkpoints setzen weiterhin auf Pickle-basierte Formate wie .pt oder .bin. Beim Laden solcher Dateien kann Python Deserialisierungslogik ausführen, die im Checkpoint steckt. Ist der Checkpoint bösartig, kann diese Logik Zugangsdaten stehlen, Umgebungsvariablen auslesen, Payloads nachladen oder beim Laden Remote-Code ausführen.

Genau dieses Problem löst SafeTensors. Statt beliebige Python-Objekte zu serialisieren, speichert es nur Tensordaten und die Metadaten, die zum korrekten Laden nötig sind. Das Laden einer .safetensors-Datei benötigt keine Python-Rekonstruktionslogik – die Angriffsfläche schrumpft deutlich.

So funktioniert das SafeTensors-Format

Jetzt, da wir wissen, was SafeTensors ist und warum es existiert, schauen wir uns Struktur und Funktionsweise an.

Die Header-Daten-Struktur

Eine SafeTensors-Datei besteht aus zwei Teilen: einem JSON-Header und den rohen Tensordaten.

Der Header speichert Metadaten für jeden Tensor, darunter 

• Tensornamen
• Shapes
• Datentypen
• Byte-Offets

Nach dem Header speichert die Datei die rohen Tensor-Bytes zusammenhängend.

Der Header funktioniert wie ein Inhaltsverzeichnis. Er teilt dem Loader mit, welche Tensoren existieren und wo sie in der Datei liegen – ähnlich wie ein Datenbankindex auf gespeicherte Datensätze verweist. SafeTensors begrenzt die Headergröße auf 100 MB, um überdimensionierte Metadaten zu verhindern.

Zero-Copy und Memory-Mapped Loading

SafeTensors beschleunigt das Laden durch speichergemapptes Laden. Statt beim Deserialisieren Python-Objekte neu aufzubauen, können Frameworks Tensordaten direkt von der Festplatte in den Speicher mappen. Das reduziert unnötige Kopien und senkt die CPU-Last beim Laden.

Laut Hugging Face Benchmarks lud SafeTensors Gewichte auf der CPU rund 76× schneller als PyTorch und auf der GPU etwa 2× schneller. Der genaue Speedup hängt natürlich von Hardware und Checkpoint-Größe ab, aber das Vermeiden der Python-Deserialisierung steigert die Ladeleistung durchgängig.

Lazy Loading und partielles Deserialisieren

SafeTensors lädt gezielt Tensoren per Name, statt den kompletten Checkpoint auf einmal in den Speicher zu lesen.

Das ist besonders bei großen verteilten Modellen über mehrere GPUs hilfreich. Nimm BLOOMs Modell mit 176B Parametern: Mit Standard-PyTorch-Checkpoints musste das System zunächst die vollen Modellgewichte deserialisieren, bevor es sie auf die Geräte verteilt – das dauerte etwa 10 Minuten. 

Mit SafeTensors lud jede GPU nur die tatsächlich benötigten Tensor-Shards. Das verkürzte die Startzeit des Modells auf rund 45 Sekunden über 8 GPUs.

SafeTensors im Vergleich zu anderen Serialisierungsformaten

SafeTensors eignet sich hervorragend, um Modellgewichte sicher und effizient zu speichern und zu laden. Das bedeutet jedoch nicht, dass es jedes Format ersetzen kann. Die richtige Wahl hängt davon ab, was du speicherst und wo das Modell in der Pipeline steht.

Über Pickle haben wir schon ausführlich gesprochen, daher konzentriere ich mich hier auf andere Formate.

SafeTensors vs. GGUF

SafeTensors und GGUF lösen unterschiedliche Aufgaben. 

GGUF, kurz für GGML Unified Format, wurde für quantisierte Inferenz-Workloads in Laufzeiten wie llama.cpp entwickelt. Das Format zielt auf effiziente Bereitstellung komprimierter Modelle – insbesondere für CPU-Inferenz und Edge-Geräte. 

SafeTensors sitzt früher in der Pipeline. Die meisten SafeTensors-Checkpoints speichern Vollpräzisions- oder Trainings-taugliche Tensoren für Training, Fine-Tuning, Merging oder verteilte Inferenz. Das Format priorisiert sicheres Laden, Kompatibilität mit Frameworks wie PyTorch und effizienten Tensorzugriff während Training und Serving.

Beide können sich ergänzen statt zu konkurrieren. Beispiel-Workflow: 

• Das Modell mit PyTorch trainieren oder feinabstimmen und SafeTensors-Checkpoints verwenden
• Das finale Modell quantisieren
• Für die Bereitstellung in llama.cpp oder Edge-Inferenz-Laufzeiten nach GGUF exportieren

SafeTensors vs. ONNX

SafeTensors konzentriert sich darauf, Modellgewichte sicher zu speichern und sie effizient innerhalb von Frameworks wie PyTorch zu laden. Es speichert ausschließlich Tensoren und Metadaten – ideal für das Teilen von Checkpoints, Fine-Tuning und Trainings-Workflows.

ONNX verfolgt einen breiteren Ansatz. Es speichert den kompletten Rechengraphen zusammen mit den Modellparametern. Dadurch eignet sich ONNX besonders, wenn du ein Modell aus einem Framework exportieren und in einem anderen ausführen willst.

Teams, die LLMs mit PyTorch trainieren und feinabstimmen, bevorzugen in der Regel SafeTensors-Checkpoints, weil sie schnell laden und sich direkt in bestehende Workflows integrieren. Soll das gleiche Modell jedoch in TensorRT, ONNX Runtime oder eine Edge-Inferenz-Engine deployt werden, ist der Export nach ONNX sinnvoller.

SafeTensors in der Praxis

Ein Grund für die schnelle Verbreitung im PyTorch-Ökosystem: Die API fühlt sich vertraut an. Du arbeitest weiterhin wie gewohnt mit State Dicts und Tensoren.

Tensoren speichern und laden

Der Basis-Workflow sieht identisch zur Standardbehandlung von PyTorch-Checkpoints aus. Hier ein Beispiel:

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() schreibt die Tensoren in das .safetensors-Format, während load_file() sie wieder in den Speicher lädt.

SafeTensors unterstützt außerdem selektives Laden über safe_open() – praktisch bei großen Checkpoints, wenn du nur wenige Tensoren benötigst.

from safetensors import safe_open

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

print(weights)

Statt den kompletten Checkpoint zu laden, liest get_tensor() nur den angeforderten Tensor.

Vorhandene Modelle in SafeTensors konvertieren

Das Standardmuster lautet:

1. Das bestehende Modell laden
2. Das State Dict extrahieren
3. Mit save_file() speichern

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() gibt die Modellgewichte als Tensoren zurück, die SafeTensors direkt speichern kann. 

Wenn das Modell bereits im Hugging Face Hub liegt, brauchst du unter Umständen gar keine lokale Konvertierung. Hugging Face bietet im Hub integrierte Unterstützung für die Checkpoint-Konvertierung gehosteter Modelle.

Serialisierungsformate: Vergleichstabelle

SafeTensors im Jahr 2026: PyTorch Foundation und der Ausblick

Im April 2026 hat Hugging Face SafeTensors der PyTorch Foundation unter der Linux Foundation beigesteuert. Das Projekt steht nun neben PyTorch, vLLM, DeepSpeed und Ray unter Stiftungs-Governance.

Dieser Schritt zeigt: SafeTensors ist nicht mehr nur ein Hugging Face Projekt. Es entwickelt sich zur gemeinsamen Infrastruktur für das ML-Ökosystem. 

Die Ankündigung skizziert auch, wohin sich das Format als Nächstes bewegt.

Device-bewusstes Laden

Ein Schwerpunkt ist device-bewusstes Laden. Heute laden viele Workflows Tensoren erst in den CPU-Speicher, bevor sie auf CUDA- oder ROCm-Geräte verschoben werden. Dieser zusätzliche Zwischenschritt erhöht die Startlatenz – besonders in großen verteilten Systemen. 

Die Maintainer von SafeTensors arbeiten an direkten Device-Ladepfaden, die unnötige CPU-Kopien vermeiden und Tensoren direkt auf Beschleuniger verschieben. 

Verteiltes Laden

Auch die Unterstützung für verteiltes Laden entwickelt sich weiter. Moderne Inferenzsysteme laufen selten noch auf einer einzelnen GPU. Tensor- und Pipeline-Parallelismus sind heute Standardmuster für große Modelle, doch die Checkpoint-Loading-APIs sind über Frameworks hinweg noch fragmentiert. 

SafeTensors baut die Unterstützung für shard-bewusstes Laden und verteilte Tensor-Layouts aus, damit Frameworks das Laden von Checkpoints über Geräte hinweg effizienter koordinieren können. 

Moderne Quantisierungs-Workflows

Das Format passt sich außerdem neueren Quantisierungs-Workflows an. Inferenzsysteme setzen zunehmend auf FP8, GPTQ und AWQ, um Speicherbedarf zu reduzieren und Serving-Kosten zu senken. 

Statt Frameworks auf benutzerdefinierte Serialisierung zu zwingen, ergänzt SafeTensors formale Unterstützung für geringere Präzisionen und block-quantisierte Tensorformate direkt im Format. 

Aktuell müssen Entwickler:innen SafeTensors oft noch manuell wählen, indem sie zwischen Save-/Load-Workflows umschalten. Es gibt jedoch laufende Arbeiten an einer tieferen Integration mit Pythorchs nativer Serialisierung. Gelingt das, könnte SafeTensors vom alternativen Checkpoint-Format zum Standard werden, wie PyTorch Modelle speichert.

Fazit

Lange Zeit teilten Entwickler:innen Modell-Checkpoints über Serialisierungssysteme, die beim Laden beliebigen Python-Code ausführen konnten. Mit öffentlichen Model Hubs, die Millionen Checkpoints hosten, wurden die Sicherheitsrisiken unübersehbar.

SafeTensors hat das geändert, indem es den Fokus verengt. Statt ganze Python-Objekte zu serialisieren, speichert es nur Tensoren und die Metadaten zum Laden. Dieses einfache Design eliminiert die Deserialisierungsrisiken Pickle-basierter Checkpoints – und verbessert zugleich Ladegeschwindigkeit und Speichereffizienz.

Wenn du also nur Modellgewichte brauchst, gibt es keinen Grund, während der Deserialisierung beliebigen Code auszuführen – in diesen Fällen ist SafeTensors die bessere Wahl.

Wenn du tiefer in moderne ML-Tools, Modellformate und Hugging Face Workflows einsteigen möchtest, sind unsere Kurse Deep Learning in Python und Working with Hugging Face ein guter nächster Schritt. Sie decken praxisnahe Workflows zum Trainieren, Fine-Tuning und Deployen von Modellen mit den Tools ab, die im heutigen KI-Ökosystem genutzt werden.