Checkpoint
Wenn ein KI-Modell trainiert wird, speichert das System in regelmäßigen Abständen den aktuellen Zustand ab. Diese Sicherungspunkte heißen Checkpoints. Sie ermöglichen es, nach einer Unterbrechung weiterzumachen, den besten Trainingszustand auszuwählen und ein Modell für neue Aufgaben weiterzuverwenden.
Ein Checkpoint enthält mindestens die gelernten Gewichte des Modells. In der Praxis umfasst er zusätzlich den Optimizer-State, den Scheduler-Zustand und Metadaten wie die aktuelle Trainingsepisode oder den Zeitstempel. Zusammen bilden diese Daten einen vollständigen Schnappschuss, von dem aus das Training exakt fortgesetzt werden kann.
Warum Trainingszustände gesichert werden
Das Training großer Modelle dauert Tage bis Wochen. Hardware fällt aus, Cluster werden neu zugeteilt, Stromversorgungen unterbrechen. Ohne Checkpoints bedeutet jede Unterbrechung einen Neustart von Stunde null.
Beispiel: Ein Sprachmodell wird auf 8 GPUs über 14 Tage trainiert. Nach 11 Tagen fällt ein Knoten aus. Mit einem Checkpoint vom Ende von Tag 10 verliert das Team einen Tag Rechenzeit. Ohne Checkpoint verliert es 11 Tage.
Beispiel: Ein Forschungsteam trainiert ein Bildklassifikationsmodell auf einem gemieteten GPU-Cluster. Das Budget reicht für 72 Stunden Rechenzeit. Mit stündlichen Checkpoints kann das Team später mit neuem Budget nahtlos weitermachen.
Checkpoints sind damit eine Grundvoraussetzung für jedes Training, das länger als wenige Stunden dauert. Die Speicherfrequenz ist ein Kompromiss: Häufige Checkpoints reduzieren den maximalen Verlust, belegen aber Speicherplatz und kosten I/O-Bandbreite.
Was ein Checkpoint enthält
Ein minimaler Checkpoint besteht aus den Modellgewichten. Ein vollständiger Checkpoint umfasst mehrere Komponenten:
- Modellgewichte: Die aktuellen Parameter des Netzwerks.
- Optimizer-State: Laufende Statistiken des Optimizers, z.B. Momentschätzungen bei Adam. Ohne diesen State startet der Optimizer nach dem Laden effektiv kalt.
- Scheduler-State: Die Position im Lernraten-Zeitplan.
- Trainingsmetadaten: Aktuelle Epoche, Schrittzahl, Zufallsgenerator-Seeds, Konfigurationsdateien.
Beispiel: Ein Checkpoint eines 7-Milliarden-Parameter-Modells in FP16 belegt etwa 14 GB allein für die Gewichte (7 Milliarden mal 2 Byte). Der Optimizer-State (bei Adam: zwei zusätzliche Vektoren pro Parameter) verdreifacht diesen Wert auf etwa 42 GB.
Beispiel: Bei PyTorch speichert torch.save() den Checkpoint als serialisierte Python-Objekte. Das Ergebnis ist eine einzelne Datei, die Gewichte, Optimizer und Metadaten enthält. Frameworks wie Hugging Face Transformers verwenden stattdessen Formate wie safetensors, die schnelleres Laden und Sicherheitsvorteile bieten.
Den besten Trainingszustand auswählen
Das Modell am Ende des Trainings ist nicht zwangsläufig das beste. Wenn ein Modell zu lange trainiert wird, beginnt es, die Trainingsdaten auswendig zu lernen, statt zu generalisieren. Dieser Effekt heißt Overfitting. Checkpoints ermöglichen es, den Zustand mit der besten Generalisierung auszuwählen.
Beispiel: Ein Sentimentanalyse-Modell erreicht nach Epoche 5 eine Validierungsgenauigkeit von 91,3 %. Nach Epoche 8 sinkt sie auf 89,1 %, während die Trainingsgenauigkeit weiter steigt. Der Checkpoint von Epoche 5 ist die bessere Wahl für den produktiven Einsatz.
Dieses Verfahren heißt Best Model Selection oder Early Stopping Checkpoint Selection. Der Ablauf: Nach jeder Epoche (oder nach einer definierten Anzahl von Schritten) wird das Modell auf einem Validierungsset evaluiert. Der Checkpoint mit dem besten Validierungsergebnis wird behalten.
Beispiel: Ein Team trainiert einen BERT-Classifier für medizinische Texte. Es speichert nach jeder halben Epoche einen Checkpoint und evaluiert auf einem Validierungsset von 2.000 annotierten Dokumenten. Von 20 Checkpoints zeigt Checkpoint 14 den niedrigsten Validierungsverlust. Dieser wird für die Produktion verwendet.
Fachliche Einordnung: Best Model Selection über Checkpoints ist in der Praxis Standard. Alternativ existieren Ansätze wie Stochastic Weight Averaging (SWA), bei denen die Gewichte mehrerer Checkpoints gemittelt werden, um die Generalisierung zusätzlich zu verbessern. SWA nutzt Checkpoints als Rohstoff für eine robustere Endlösung.
Checkpoints als Ausgangspunkt für Fine-Tuning
Vortrainierte Modelle werden als Checkpoints veröffentlicht. Andere Teams laden diese Checkpoints und trainieren sie auf eigenen Daten weiter. Dieses Verfahren heißt Fine-Tuning und ist die Grundlage des modernen Deep Learning.
Beispiel: Ein Unternehmen lädt den öffentlichen Checkpoint eines Sprachmodells mit 7 Milliarden Parametern herunter. Es trainiert diesen Checkpoint mit eigenen Kundensupport-Dialogen weiter. Nach wenigen Stunden Fine-Tuning antwortet das Modell im unternehmensspezifischen Stil und Wissensbereich.
Ohne Checkpoints müsste jedes Team jedes Modell von Grund auf trainieren. Der Rechenaufwand wäre für die meisten Organisationen nicht tragbar. Checkpoints sind damit die technische Grundlage für den Transfer von Wissen zwischen Trainingsszenarien.
Beispiel: Die öffentlichen Checkpoints von BERT wurden seit 2018 in tausenden Forschungsarbeiten als Startpunkt verwendet. Jede Arbeit lädt denselben Checkpoint und trainiert ihn auf einen spezifischen Datensatz. Ohne diesen geteilten Checkpoint wäre der Großteil dieser Forschung nicht möglich gewesen.
Ablauf: Vom Speichern zum Wiederherstellen
Der Speichervorgang selbst ist nicht trivial. Bei großen Modellen müssen die Gewichte von der GPU in den Hauptspeicher kopiert und dann auf einen persistenten Datenträger geschrieben werden. Bei verteiltem Training müssen die Fragmente von mehreren GPUs koordiniert zusammengeführt werden.
Speicherformate und Dateigrößen
Checkpoints werden in verschiedenen Formaten gespeichert. Die Wahl des Formats beeinflusst Dateigröße, Ladegeschwindigkeit und Sicherheit.
Beispiel: PyTorch nutzt standardmäßig pickle-Serialisierung. Dieses Format erlaubt beim Laden die Ausführung beliebigen Codes. Ein manipulierter Checkpoint kann Schadcode enthalten. Das Format safetensors speichert ausschließlich Tensoren ohne ausführbaren Code und eliminiert dieses Risiko.
Die Dateigröße eines Checkpoints hängt von der Parameterzahl und dem Zahlenformat ab:
- 1 Milliarde Parameter in FP16 (2 Byte pro Wert): ca. 2 GB nur Gewichte
- 7 Milliarden Parameter in FP16: ca. 14 GB nur Gewichte
- 70 Milliarden Parameter in FP16: ca. 140 GB nur Gewichte
Mit Optimizer-State (z.B. Adam: 2 zusätzliche Vektoren) verdreifacht sich der Speicherbedarf. Ein vollständiger Checkpoint eines 70B-Modells kann über 400 GB belegen.
Beispiel: Wird ein Checkpoint alle 1.000 Trainingsschritte gespeichert und das Training läuft 100.000 Schritte, entstehen 100 Checkpoints. Bei einem 7B-Modell (ca. 42 GB pro vollständigem Checkpoint) summiert sich das auf über 4 TB. In der Praxis werden deshalb nur die letzten N Checkpoints behalten und ältere automatisch gelöscht.
Checkpoints bei verteiltem Training
Große Modelle werden auf mehreren GPUs parallel trainiert. Je nach Parallelisierungsstrategie liegen die Modellgewichte verteilt über verschiedene Geräte. Das verändert die Struktur der Checkpoints grundlegend.
Bei Data Parallelism hat jede GPU eine vollständige Kopie der Gewichte. Ein Checkpoint von einer beliebigen GPU genügt. Bei Model Parallelism oder Tensor Parallelism sind die Gewichte über mehrere GPUs aufgeteilt. Der Checkpoint muss dann alle Fragmente einsammeln und konsistent zusammenführen.
Beispiel: Ein 70-Milliarden-Parameter-Modell wird mit Tensor Parallelism auf 8 GPUs trainiert. Jede GPU hält ein Achtel der Gewichte. Beim Checkpointing müssen alle 8 Fragmente synchron auf die Festplatte geschrieben werden. Wenn eine GPU beim Schreiben ausfällt, ist der gesamte Checkpoint unbrauchbar.
Frameworks wie PyTorch Distributed und DeepSpeed bieten spezialisierte Checkpoint-Mechanismen für verteilte Szenarien. DeepSpeed implementiert z.B. ein Format namens Universal Checkpointing, das Checkpoints unabhängig von der ursprünglichen Parallelisierungskonfiguration ladbar macht.
Fachliche Einordnung: Die Herausforderung beim verteilten Checkpointing liegt nicht nur in der Datenmenge, sondern in der Konsistenz. Alle beteiligten Prozesse müssen zum exakt gleichen Trainingsschritt schreiben. In der Praxis wird dafür eine Barriere-Synchronisation eingesetzt, die das Training kurzzeitig pausiert. Bei Tausenden von GPUs kann allein dieser Synchronisationsoverhead mehrere Minuten betragen.
Checkpoints und Quantisierung
Ein Checkpoint kann nach dem Training in ein kompakteres Zahlenformat umgewandelt werden. Dieser Vorgang heißt Quantisierung. Die Gewichte werden dabei von höherer Präzision (z.B. FP16, 2 Byte) in niedrigere Präzision (z.B. INT4, 0,5 Byte) konvertiert.
Beispiel: Ein 7B-Modell-Checkpoint in FP16 belegt 14 GB. Nach Quantisierung auf INT4 schrumpft er auf etwa 3,5 GB. Dieses quantisierte Modell läuft auf Consumer-Hardware mit 8 GB VRAM, während die Originalversion mindestens 16 GB VRAM benötigt.
Die Qualitätseinbußen durch Quantisierung variieren je nach Modell und Aufgabe. Bei vielen Anwendungen ist der Unterschied zwischen FP16 und INT4 gering. Bei Aufgaben, die hohe numerische Präzision erfordern (z.B. mathematisches Schließen), können die Einbußen spürbar sein.
Grenzen und praktische Einschränkungen
Checkpoints lösen nicht alle Probleme des Trainingsmanagements. Einige relevante Einschränkungen:
Speicherplatz ist endlich. Ein einzelner vollständiger Checkpoint eines großen Modells kann mehrere Hundert Gigabyte belegen. Bei regelmäßigem Speichern über Tausende von Schritten entstehen Terabytes an Daten. Organisationen müssen eine Aufbewahrungsstrategie definieren: Welche Checkpoints werden behalten, welche gelöscht?
Beispiel: Ein Cloud-basiertes Trainingsprojekt speichert Checkpoints auf S3. Der Speicher kostet pro Monat. Nach drei Monaten Training mit einem 70B-Modell liegen 50 TB an Checkpoints vor. Die monatlichen Speicherkosten übersteigen dann die eigentlichen Rechenkosten.
Reproduzierbarkeit ist begrenzt. Auch mit identischem Checkpoint führt ein Neustart des Trainings nicht zwangsläufig zu identischen Ergebnissen. Unterschiedliche GPU-Architekturen, andere CUDA-Versionen oder nichtdeterministische Operationen verursachen Abweichungen. Ein Checkpoint garantiert denselben Startzustand, nicht dasselbe Endergebnis.
Kompatibilität bricht. Ein Checkpoint, der mit Version 1.x eines Frameworks erstellt wurde, lässt sich unter Umständen mit Version 2.x nicht mehr laden. Änderungen an der Modellarchitektur (z.B. ein zusätzlicher Layer) machen bestehende Checkpoints inkompatibel. Migrationsscripts sind dann nötig.
Fachliche Einordnung: Die langfristige Archivierung von Checkpoints ist ein offenes Problem im ML-Engineering. Es fehlt ein universelles, frameworkunabhängiges Format. Ansätze wie safetensors und GGUF gehen in diese Richtung, decken aber nicht den vollständigen Trainingsstate ab. Die Community arbeitet an Standards, aber ein allgemein akzeptiertes Archivformat existiert Stand 2026 nicht.