Checkpoint-Konfiguration
Beim Training eines Modells entstehen regelmäßig Zwischenstände. Welche davon gespeichert werden, wie oft und in welcher Form, legt die Checkpoint-Konfiguration fest.
Ein Checkpoint ist ein vollständiger oder teilweiser Schnappschuss eines Modells zu einem bestimmten Zeitpunkt im Training. Die Konfiguration dieser Sicherungspunkte entscheidet darüber, ob nach einem Hardwareausfall Stunden an Rechenzeit verloren gehen oder ob das Training nahtlos fortgesetzt werden kann. Sie bestimmt auch, welche Modellversionen später für Evaluation, Fine-Tuning oder Deployment zur Verfügung stehen.
Die Konfiguration umfasst drei Kernfragen: Wann wird gespeichert? Was wird gespeichert? Wie lange wird es aufbewahrt? Jede dieser Entscheidungen hat direkte Auswirkungen auf Speicherkosten, Trainingsgeschwindigkeit und die Flexibilität bei der späteren Modellauswahl.
Wann und wie oft gespeichert wird
Das Speicherintervall legt fest, nach wie vielen Trainingsschritten oder Epochen ein neuer Checkpoint geschrieben wird. Ein zu kurzes Intervall erzeugt hohe I/O-Last und verlangsamt das Training. Ein zu langes Intervall riskiert den Verlust großer Trainingsfortschritte bei einem Abbruch.
Beispiel: Ein Sprachmodell wird mit 500.000 Schritten trainiert. Bei einem Intervall von 5.000 Schritten entstehen 100 Checkpoints. Bei einem Intervall von 50.000 Schritten nur 10. Fällt die Hardware nach Schritt 490.000 aus, gehen im ersten Fall maximal 5.000 Schritte verloren, im zweiten Fall bis zu 50.000.
Beispiel: Bei einem Bildklassifikator mit 200 Epochen und epochenbasiertem Checkpointing wird nach jeder abgeschlossenen Epoche gesichert. Damit steht für jede Epoche ein reproduzierbarer Modellzustand zur Verfügung.
In der Praxis kombinieren viele Teams schrittbasiertes und epochenbasiertes Speichern. Das schrittbasierte Intervall schützt vor Hardwareausfällen innerhalb einer Epoche, das epochenbasierte liefert saubere Bewertungspunkte.
Fachliche Einordnung: Die Wahl des Speicherintervalls ist ein Kompromiss zwischen Trainingseffizienz und Wiederherstellungssicherheit. In der Forschung, wo GPU-Stunden teuer sind, wird tendenziell häufiger gesichert. In produktionsnahen Umgebungen mit stabiler Infrastruktur können längere Intervalle akzeptabel sein.
Was ein Checkpoint enthält
Nicht jeder Checkpoint muss alle Informationen enthalten. Der Inhalt richtet sich nach dem Verwendungszweck.
Ein vollständiger Trainings-Checkpoint umfasst:
- Modellgewichte (die gelernten Tensoren)
- Den Optimizer-State (Momentumwerte, adaptive Lernratenstatistiken)
- Den Scheduler-Zustand (aktuelle
Learning Rate, Warmup-Position) - Den Schrittzähler und die aktuelle Epoche
- Optional: Zufallszustände für exakte Reproduzierbarkeit
Beispiel: Ein Transformer-Modell mit 7 Milliarden Gewichten belegt etwa 14 GB im FP16-Format. Der Optimizer-State (bei Adam) verdreifacht diesen Wert auf rund 42 GB pro vollständigem Checkpoint.
Beispiel: Für das Deployment eines fertig trainierten Modells reichen die Modellgewichte allein. Der Optimizer-State wird nicht mehr benötigt, da kein weiteres Training stattfindet. Ein solcher Inference-Checkpoint ist deutlich kleiner.
Die Unterscheidung zwischen Training-Checkpoints (vollständig) und Export-Checkpoints (nur Gewichte) ist in jedem größeren Trainingsprojekt relevant. Manche Frameworks unterstützen diese Trennung nativ, in anderen muss sie manuell konfiguriert werden.
Aufbewahrung und Rotation
Checkpoints verbrauchen erheblichen Speicherplatz. Eine Rotationsstrategie bestimmt, welche Checkpoints behalten und welche gelöscht werden.
Gängige Strategien:
- Last-k: Nur die letzten k Checkpoints werden aufbewahrt. Ältere werden automatisch gelöscht.
- Best-k: Nur die k Checkpoints mit dem niedrigsten Validation Loss bleiben erhalten.
- Kombination: Die letzten k plus die besten m Checkpoints werden aufbewahrt.
Beispiel: Ein Team trainiert ein Modell über 100 Epochen. Mit einer Best-3-Strategie werden nur die drei Checkpoints mit dem niedrigsten Validation Loss behalten. Epoche 47, 63 und 89 erweisen sich als die besten. Alle anderen werden nach der Evaluierung gelöscht.
Beispiel: Eine Last-5-Strategie behält immer die fünf jüngsten Checkpoints. Wenn Checkpoint 50 geschrieben wird, wird Checkpoint 45 gelöscht. Diese Strategie schützt vor kurzfristigen Abstürzen, garantiert aber nicht die Aufbewahrung des besten Modellzustands.
Speicherformate und ihre Eigenschaften
Das Dateiformat eines Checkpoints beeinflusst Ladegeschwindigkeit, Dateigröße, Sicherheit und Portabilität zwischen Frameworks.
PyTorch speichert Checkpoints standardmäßig als .pt oder .pth-Dateien. Intern nutzt dieses Format Pythons pickle-Modul, was ein bekanntes Sicherheitsrisiko darstellt: Manipulierte Checkpoint-Dateien können beim Laden beliebigen Code ausführen.
Beispiel: Ein Team lädt einen vortrainierten Checkpoint aus einem öffentlichen Repository. Ohne Prüfung der Dateiquelle kann eine manipulierte .pt-Datei Schadcode auf dem Server ausführen. Aus diesem Grund bieten neuere Formate wie Safetensors eine sichere Alternative.
Das Safetensors-Format speichert ausschließlich Tensordaten ohne ausführbaren Code. Es unterstützt Memory-Mapping, was das Laden großer Modelle beschleunigt, da nicht die gesamte Datei in den Arbeitsspeicher gelesen werden muss.
Beispiel: Ein 70-Milliarden-Parameter-Modell im Safetensors-Format wird per Memory-Mapping geladen. Nur die tatsächlich angeforderten Tensoren landen im RAM. Beim pickle-basierten Format müsste die gesamte Datei deserialisiert werden.
TensorFlow verwendet das SavedModel-Format, das neben den Gewichten auch den Berechnungsgraphen enthält. Frameworkunabhängige Formate wie ONNX und Safetensors ermöglichen den Austausch zwischen verschiedenen Frameworks.
Checkpoints bei verteiltem Training
Wenn ein Modell über mehrere GPUs oder Knoten verteilt trainiert wird, verändert sich die Checkpoint-Konfiguration grundlegend. Jeder Prozess hält nur einen Teil des Modells oder der Optimizer-Zustände im Speicher.
Bei Datenparallelismus besitzt jeder Prozess eine vollständige Kopie des Modells. Hier reicht es, wenn ein einzelner Prozess den Checkpoint schreibt. Bei Modellparallelismus oder ZeRO-basierten Strategien verteilt sich der Modellzustand auf mehrere Prozesse. Der Checkpoint muss dann aus allen Teilzuständen zusammengesetzt werden.
Beispiel: Ein Modell mit 70 Milliarden Gewichten wird mit ZeRO Stage 3 auf 8 GPUs trainiert. Jede GPU hält nur ein Achtel der Gewichte und des Optimizer-States. Beim Checkpointing müssen alle 8 Teile koordiniert geschrieben und beim Laden wieder zusammengefügt werden.
Beispiel: Bei Pipeline-Parallelismus hält jede GPU unterschiedliche Schichten des Modells. GPU 0 speichert die Schichten 0 bis 15, GPU 1 die Schichten 16 bis 31. Der Checkpoint besteht aus mehreren Teildateien, die zusammen den vollständigen Modellzustand ergeben.
Verteiltes Checkpointing stellt besondere Anforderungen an die Synchronisation: Alle Prozesse müssen denselben Trainingsschritt gesichert haben, bevor das Training fortgesetzt wird. Asynchrones Checkpointing kann die Wartezeit reduzieren, erhöht aber die Komplexität der Implementierung.
Konfiguration in gängigen Frameworks
Jedes Framework bietet eigene Abstraktionen für die Checkpoint-Konfiguration. Die Grundprinzipien ähneln sich, die Details in der Syntax unterscheiden sich.
In PyTorch Lightning konfiguriert der ModelCheckpoint-Callback das Speicherverhalten deklarativ:
from pytorch_lightning.callbacks import ModelCheckpoint
checkpoint_callback = ModelCheckpoint(
dirpath="checkpoints/",
filename="model-{epoch:02d}-{val_loss:.2f}",
save_top_k=3,
monitor="val_loss",
mode="min",
every_n_epochs=1
)Der Parameter save_top_k=3 behält die drei besten Modelle (gemessen an val_loss). monitor und mode legen die Bewertungsmetrik fest.
Beispiel: Ein Forschungsteam setzt save_top_k=5 und monitor="val_accuracy". Damit werden die fünf Checkpoints mit der höchsten Validierungsgenauigkeit aufbewahrt. Alle anderen werden nach der Evaluierung gelöscht.
In Hugging Face Transformers steuert die TrainingArguments-Klasse das Checkpointing:
from transformers import TrainingArguments
args = TrainingArguments(
output_dir="checkpoints/",
save_strategy="steps",
save_steps=1000,
save_total_limit=5,
load_best_model_at_end=True,
metric_for_best_model="eval_loss"
)save_total_limit=5 entspricht einer Last-5-Rotation. load_best_model_at_end=True stellt sicher, dass nach dem Training der beste Checkpoint geladen wird.
Häufige Konfigurationsfehler
Fehler in der Checkpoint-Konfiguration zeigen sich oft erst nach Stunden oder Tagen Training, wenn ein Recovery benötigt wird und der gespeicherte Zustand unbrauchbar ist.
Beispiel: Ein Team setzt save_top_k=1 und bemerkt nach dem Training, dass der beste Checkpoint auf einer fehlerhaften Evaluierungsmetrik basierte. Es existiert kein alternativer Checkpoint. Das gesamte Training muss wiederholt werden.
Beispiel: Bei verteiltem Training wird der Checkpoint nur von Prozess 0 geschrieben, obwohl ZeRO Stage 3 aktiv ist. Der gespeicherte Checkpoint enthält nur ein Achtel der Modellgewichte. Beim Laden schlägt die Wiederherstellung fehl.
Weitere verbreitete Fehler:
- Kein Checkpoint des Optimizer-States, obwohl das Training fortgesetzt werden soll. Der Optimizer-State enthält Momentumwerte und adaptive Statistiken, die bei Verlust neu aufgebaut werden müssen.
- Speicherplatz auf dem Trainingserver läuft voll, weil keine Rotation konfiguriert ist. Das Training bricht ab.
- Checkpoint-Dateien werden ohne Versionierung überschrieben. Bei einem fehlerhaften Trainingsschritt existiert kein älterer Zustand.
Grenzen und offene Fragen
Die Checkpoint-Konfiguration kann nicht alle Probleme lösen, die beim Training großer Modelle auftreten.
Bei Modellen mit hunderten Milliarden Gewichten werden einzelne Checkpoints mehrere Terabyte groß. Selbst mit Rotation und Best-k-Strategien können die Speicherkosten den Trainingskosten nahekommen. Komprimierungsverfahren für Checkpoints, etwa Quantisierung vor dem Speichern, sind ein aktives Forschungsfeld.
Beispiel: Ein Modell mit 175 Milliarden Gewichten erzeugt Checkpoints von jeweils über 350 GB (FP16). Bei 100 Checkpoints ergeben sich 35 TB Speicherbedarf. Cloud-Speicher dieser Größenordnung verursacht laufende Kosten, die in die Trainingskalkulation einfließen müssen.
Die Reproduzierbarkeit über verschiedene Hardware-Konfigurationen ist nicht garantiert. Ein Checkpoint, der auf 8 GPUs mit einer bestimmten Parallelisierungsstrategie erstellt wurde, lässt sich nicht ohne Konvertierung auf 4 GPUs mit einer anderen Strategie laden. Universelle Checkpoint-Formate, die von der Trainingsinfrastruktur abstrahieren, sind noch nicht ausgereift.
Fachliche Einordnung: Die Checkpoint-Konfiguration ist ein zentraler, aber oft unterschätzter Aspekt des Trainingsmanagements. In der Praxis verursachen Konfigurationsfehler beim Checkpointing mehr verlorene GPU-Stunden als die meisten Fehler im Modelldesign. Die Standardisierung von Checkpoint-Formaten und Metadatenschemata ist ein laufender Prozess in der Deep-Learning-Community, angetrieben durch die wachsende Modellgröße und die zunehmende Heterogenität der Trainingsinfrastruktur.