Glossareintrag
Wir denken. KI tippt mit.
Checkpoint bei KI (deutsch Trainings-Zwischenstand, auch Modell-Checkpoint) ist der gespeicherte Zustand eines KI-Modells zu einem bestimmten Zeitpunkt des Trainings. Ein Checkpoint enthält alle Parameter (die Gewichte) und bei einem vollständigen Trainings-Checkpoint dazu den Zustand des Optimierers, den Lernraten-Plan, den Schrittzähler und den Stand des Zufallsgenerators. Mit diesen Daten lässt sich ein unterbrochenes Training an der gespeicherten Stelle fortsetzen. Das fertige Modell, das ein Anbieter später ausliefert, ist technisch der letzte ausgewählte Checkpoint.
Der Begriff hat zwei Lesarten. In den KI-Laboren meint er den Zwischenstand eines laufenden Trainings, darunter die Release-Kandidaten (englisch pre-release checkpoint), an denen die Sicherheitstests vor der Veröffentlichung laufen. In der Bild-KI-Szene rund um Stable Diffusion steht „Checkpoint“ dagegen für die komplette Modelldatei, die ein Programm wie ComfyUI lädt. Beide Bedeutungen haben denselben Ursprung, denn auch diese Modelldatei ist der letzte gespeicherte Trainingsstand eines Diffusionsmodells. Eine feste deutsche Übersetzung gibt es nicht. Google nennt Checkpoints in der deutschen Fassung seiner Cloud-Dokumentation „Prüfpunkte“. Fachmedien wie The Decoder schreiben „Zwischenstände eines Modells“.
(Hinweis: Verwechselbar mit Activation Checkpointing, einer Speichertechnik innerhalb eines Trainingsschritts, die keine Datei erzeugt. Anthropics Responsible Scaling Policy verwendet „Checkpoint“ zudem für eine Fähigkeitsschwelle, und der Sicherheitsanbieter Check Point Software hat mit dem Begriff nichts zu tun.)
Der wichtigste Grund für Checkpoints sind Ausfälle der Hardware während langer Trainingsläufe. Meta hat für das Training von Llama 3 405B auf bis zu 16.000 GPUs vom Typ H100 einen Zeitraum von 54 Tagen ausgewertet. Laut dem Llama-3-Paper gab es in dieser Zeit 466 Unterbrechungen des Trainings, 419 davon ungeplant. Rund 78 Prozent der ungeplanten Unterbrechungen gingen auf bestätigte oder vermutete Hardware-Probleme zurück, allein die GPUs verursachten 58,7 Prozent. Ohne Checkpoints hätte jeder dieser Ausfälle das Training auf null zurückgeworfen. Meta beschreibt als Ziel, die GPU-Pausen beim Speichern zu minimieren und häufiger zu speichern, damit nach einem Ausfall weniger Arbeit verloren geht. Die effektive Trainingszeit lag so über 90 Prozent. Schon beim Vorgänger OPT-175B von 2022 hat Meta im OPT-Paper mindestens 35 manuelle Neustarts in zwei Monaten dokumentiert, jeweils vom letzten gespeicherten Checkpoint aus.
Was ein Checkpoint enthält, legt das Trainings-Framework fest. Die PyTorch-Dokumentation empfiehlt, neben den Gewichten auch den Zustand des Optimierers und die Nummer der Epoche zu speichern, weil der Optimierer eigene Puffer führt, die sich während des Trainings verändern. Ein solcher vollständiger Checkpoint ist laut PyTorch zwei- bis dreimal so groß wie das Modell allein. Beim Adam-Optimierer mit gemischter Genauigkeit rechnet das ZeRO-Paper von Microsoft mit 16 Byte je Parameter während des Trainings. Davon entfallen nur 2 Byte auf die Gewichte in halber Genauigkeit. Der Rest sind Gradienten, eine Kopie der Gewichte in voller Genauigkeit und zwei Statistiken des Optimierers. Ein Modell mit 7 Milliarden Parametern belegt als reine Gewichtsdatei rund 14 Gigabyte, als Trainings-Checkpoint mit Optimierer-Zustand ein Vielfaches davon. Bei Modellen mit Hunderten Milliarden Parametern schreibt deshalb jede GPU nur ihren eigenen Teil auf die Platte (Sharded Checkpoint). PyTorch Distributed Checkpoint erzeugt pro Stand mehrere Dateien und kann ihn beim Laden auf eine andere Zahl von GPUs verteilen. Der Trainer von Hugging Face Transformers speichert standardmäßig alle 500 Schritte und begrenzt auf Wunsch die Zahl der aufbewahrten Stände. Eine Option legt nur die Gewichte ohne Optimierer-Zustand ab. Diese Variante ist deutlich kleiner, ein Training lässt sich daraus aber nicht fortsetzen.
Die Dateiformate spiegeln diese Unterscheidung. PyTorch speichert Checkpoints als .pt, .pth oder .bin im Python-Format Pickle. Pickle kann beim Laden beliebigen Code ausführen, Hugging Face warnt in seiner Sicherheits-Dokumentation zu Pickle vor Angriffen über präparierte Dateien. Als Ersatz entwickelte Hugging Face das Format safetensors, das laut safetensors-Dokumentation nur Zahlenfelder ohne Programmcode enthält und Modelle ohne zusätzliche Kopie im Arbeitsspeicher lädt (Zero-Copy). Das ältere .ckpt aus der Bild-KI-Szene ist ebenfalls eine Pickle-Datei und wurde aus diesem Grund weitgehend durch safetensors ersetzt. Wer ein Sprachmodell auf dem eigenen Rechner betreibt, wandelt die Gewichte außerdem in GGUF um, das Format von llama.cpp. Es führt laut GGUF-Dokumentation von Hugging Face neben den Tensoren auch Metadaten und die Quantisierung mit. Ein Checkpoint enthält laut TensorFlow-Dokumentation nur die Werte der Parameter, nicht die Beschreibung der Rechenvorschrift. Ohne den passenden Quellcode des Modells ist die Datei deshalb nicht nutzbar.
Für die Wissenschaft sind Zwischenstände ein eigenes Untersuchungsobjekt. EleutherAI hat laut Pythia-Paper 16 Sprachmodelle von 70 Millionen bis 12 Milliarden Parametern veröffentlicht und dazu 154 Checkpoints je Modell. Am Anfang liegen die gespeicherten Stände dicht (Schritt 0, 1, 2, 4, 8 bis 512), danach folgt alle 1.000 Schritte einer bis zum Schritt 143.000. Das Allen Institute for AI legt auf der Modellseite von OLMo 2 Hunderte Zwischen-Checkpoints offen, benannt nach Schritt und verarbeiteten Tokens (z. B. „step1000-tokens5B“). Beide Modellfamilien fallen unter Open Weights. Ein zweiter Verwendungszweck ist die Mittelung mehrerer Stände. Schon das Transformer-Paper von 2017 bildete für das Basismodell den Durchschnitt der letzten fünf Checkpoints, die im Abstand von zehn Minuten geschrieben wurden, für das große Modell den der letzten 20. Die Studie „Model soups“ von 2022 übertrug das Prinzip auf mehrere getrennt feinabgestimmte Modelle.
Vor jeder Veröffentlichung wählt ein Labor aus den späten Checkpoints den Release-Kandidaten aus. Die System Cards dokumentieren, an welchem Stand welche Prüfung lief. In der System Card zu o1 schreibt OpenAI, dass externes Red Teaming und die Preparedness-Prüfungen an einem „near-final checkpoint“ stattfanden, während andere Tests am veröffentlichten Stand vom 5. Dezember 2024 („o1-dec5-release“) liefen. In der System Card zu GPT-5.5 vom April 2026 heißt es, SecureBio habe zwei Vorab-Checkpoints geprüft, und diese unterschieden sich leicht vom ausgelieferten Modell. Das Preparedness Framework sieht in seiner zweiten Fassung vor, während der Entwicklung einen geeigneten Checkpoint auszuwählen, der unter das Rahmenwerk fällt. Anthropic spricht in seinen System Cards meist von „snapshots“ und vom „production release candidate“. Laut der System Card zu Claude Opus 5 erhielt das britische AI Security Institute Zugang zu frühen Checkpoints des Modells. Die Financial Times berichtete im April 2025, viele Sicherheitstests bei OpenAI liefen an früheren Ständen statt an der ausgelieferten Version. Ein früherer Mitarbeiter bezeichnete es dort als „schlechte Praxis“, ein anderes Modell auszuliefern als das geprüfte. OpenAI hielt laut dem Bericht von The Decoder dagegen, die Checkpoints seien mit den finalen Modellen nahezu identisch.
Nach außen dringen Checkpoints als Stealth-Modelle und über Leaks. Im August 2025 bestätigte OpenRouter auf X, dass die anonymen Testmodelle Horizon Alpha und Horizon Beta „early checkpoints“ der GPT-5-Familie waren. Vor dem Start von GPT-6 Astra nannten Leaks im August 2026 einen Checkpoint mit dem internen Namen „mewfour“ als Release-Kandidaten. OpenAI-Mitarbeiter nutzten ihn laut diesen Leaks bereits intern (Dogfooding), und sein Name stand kurzzeitig in der GitHub-Historie des Codex-Projekts. OpenAI hat den Namen nie bestätigt. In der System Card zu GPT-6 Astra, das am 3. September 2026 erschien, kommt er nicht vor. Dieselbe System Card zählt Checkpoints zu den Schutzobjekten. Für Astra-Stände gelten laut OpenAI Verschlüsselung und verschärfte Zugriffskontrollen. Ein früher Checkpoint von Grok 4.6 hat laut der Model Card von xAI fünf Stunden lang die eigene Inferenz-Software optimiert. In den Programmierschnittstellen heißt der eingefrorene Stand eines fertigen Modells nicht Checkpoint, sondern Snapshot. Auf der Modellseite zu GPT-4o führt OpenAI die Snapshots gpt-4o-2024-05-13, gpt-4o-2024-08-06 und gpt-4o-2024-11-20 und erklärt, Snapshots hielten eine bestimmte Version fest, damit Leistung und Verhalten gleich bleiben.
Für Handwerksbetriebe und lokale Unternehmen taucht der Begriff an drei Stellen auf, an zweien davon in der Bedeutung „komplette Modelldatei“. Wer Bilder für Website oder Social Media mit einem Bildgenerator auf dem eigenen Rechner erzeugt, lädt einen Stable Diffusion Checkpoint als Datei von Civitai oder Hugging Face und legt ihn im Programm ab. Die Dokumentation von ComfyUI nennt dafür den Ordner „models/checkpoints“. Fooocus lädt seine Standardmodelle beim ersten Start selbst in denselben Ordner. AUTOMATIC1111 erwartet die Dateien laut seinem Wiki im Ordner „models/Stable-Diffusion“. Das Auswahlfeld oben links heißt dort „Stable Diffusion checkpoint“. Solche Dateien sind mehrere Gigabyte groß, bevorzugt im Format safetensors, weil eine .ckpt-Datei aus unbekannter Quelle beim Laden Programmcode ausführen kann. Ein LoRA ist dagegen ein kleiner Aufsatz auf einen Checkpoint. Ein Fliesenleger, der Bilder im eigenen Stil oder mit dem eigenen Produkt möchte, trainiert deshalb kein neues Modell, sondern ein LoRA auf einem vorhandenen Checkpoint. Der Civitai-Leitfaden zu Checkpoints führt LoRAs entsprechend als „Additional Resources“ neben den Checkpoints selbst.
Die zweite Stelle ist das Fine-Tuning über die Schnittstellen der Anbieter. Wer ein Modell auf die eigenen Angebotstexte oder E-Mail-Antworten feinabstimmt, bekommt bei OpenAI laut Fine-Tuning-Dokumentation am Ende jeder Trainings-Epoche einen vollständigen Checkpoint. OpenAI bewahrt die Checkpoints der letzten drei Epochen auf. Jeder davon lässt sich wie das fertige Modell ansprechen. Seine Kennung endet auf „ckpt-step“ plus Schrittzahl. Google speichert laut seiner Dokumentation zu Prüfpunkten bei der Gemini-Abstimmung bei weniger als zehn Epochen ungefähr nach jeder Epoche einen Prüfpunkt, darüber rund zehn gleichmäßig verteilte, und lässt den besten Stand als Standard festlegen. Läuft ein Training zu lange, lernt das Modell die Beispiele auswendig (Overfitting). Der beste Checkpoint liegt dann vor dem letzten. Der Vergleich der Stände zeigt ihn.
Die dritte Stelle sind fertige Modelle zum Herunterladen, die auf Hugging Face als Checkpoints bezeichnet werden. Die Modellkarte zu Whisper large-v3 von OpenAI, dem Spracherkennungsmodell hinter vielen Diktier- und Transkriptionswerkzeugen, spricht von zehn vortrainierten Checkpoints in fünf Größen.
Wer ChatGPT, Claude oder Gemini als fertigen Dienst nutzt, bekommt nie einen Checkpoint zu sehen. Der Anbieter wählt den Stand aus und rollt ihn aus. Programme wie LM Studio sprechen beim lokalen Betrieb von Sprachmodellen von „Modellen“, nicht von Checkpoints. Der eingefrorene Stand wird erst in Automatisierungen über Make oder Zapier wichtig. Dort lohnt es sich, statt eines Aliasnamens wie „gpt-4o“ den datierten Snapshot einzutragen, damit ein stiller Modellwechsel des Anbieters die eingespielten Abläufe nicht verändert.
