GPUs für Ihre Projekte · Krypto-Zahlung ohne KYC So mieten Sie
Deutsch
Konsole öffnen
Praktischer Leitfaden / KERNODECK

Setzt Ihr Training wirklich am selben Punkt wieder auf?

Um eine Wiederaufnahme zu prüfen, vergleichen Sie zehn kontinuierliche Aktualisierungen mit fünf Aktualisierungen, einer Sicherung und dann fünf weiteren in einem neuen Prozess. Laden Sie das Modell, den Optimierer, den Scheduler, die Zufallsgeneratoren und die Position in den Daten neu. Der Nachweis muss den weiteren Verlauf der Arbeit vergleichen, nicht nur feststellen, dass sich eine Datei laden lässt.

11 Min. Lesezeit · Leitfaden für Entwickler

Was Sie ausführen werden

Das Kernodeck-Miniprojekt enthält einen kleinen synthetischen Datensatz, ein Netz mit Dropout, eine Trainingsschleife und einen Prüfer. Das Protokoll erzwingt die CPU, um die Logik der Sicherung und Wiederaufnahme zu isolieren. Es stellt keine Qualifizierung für CUDA, ROCm oder Mehrfach-GPU dar und auch keine Leistungsmessung einer gemieteten GPU.

Der Prüfer öffnet neue Prozesse für den kontinuierlichen Durchlauf, die Unterbrechung, die vollständige Wiederaufnahme und einen Negativfall, der die Zufallsgeneratoren nicht wiederherstellt. Der Zweck des letzteren besteht darin, zu prüfen, dass die Kontrolle eine unvollständige Wiederaufnahme erkennen kann, selbst wenn Gewichte und Schrittnummer korrekt erscheinen.

Scrollen Sie durch die Tabelle, um alle Spalten zu lesen.
Die vier Durchläufe der Übung
DurchlaufAusführungGeprüfte Frage
Kontinuierlich10 Aktualisierungen ab dem Ausgangszustand.Welchen Zustand erreicht man ohne Unterbrechung?
Unterbrechung5 Aktualisierungen, dann Sicherung und Stopp.Enthält der Zwischenpunkt die erwarteten Zustände?
Vollständige WiederaufnahmeNeuer Prozess, Laden des Punkts 5, dann 5 Aktualisierungen.Erhält man dieselbe Abfolge von Eingaben, Raten und Parametern innerhalb der gewählten Toleranz?
Wiederaufnahme ohne RNGNeuer Prozess, derselbe Wiederaufnahmepunkt, aber ohne Wiederherstellung des Zufallszustands.Erkennt der Test eine Abweichung, die ein bloßes Laden der Gewichte durchgehen ließe?

Voraussetzungen und Start des Protokolls

Laden Sie das Archiv herunter, entpacken Sie es in einen Arbeitsordner und wechseln Sie in den Ordner mit train.py und verify_resume.py. Verwenden Sie eine Python-Umgebung mit PyTorch und NumPy. Das Archiv enthält den Code und die synthetischen Daten; es lädt kein Modell herunter und erfordert kein Kernodeck-Konto, um die Übung auszuführen.

Der mitgelieferte Nachweis wurde mit Python 3.14.6, PyTorch 2.11.0+cu128 und NumPy 2.4.4 ausgeführt. Das Programm erzwingt die CPU, die Genauigkeit float64 und einen PyTorch-Thread. Das Paketsuffix bedeutet also nicht, dass die Wiederaufnahme CUDA verwendet hat. Führen Sie in einer anderen Umgebung Ihre eigene Prüfung aus.

Wählen Sie ein Ausgabeverzeichnis, das noch nicht existiert. Jeder Durchlauf erzeugt checkpoint.pt, dessen Prüfsumme checkpoint.pt.sha256 und summary.json. Der Prüfer fasst den Vergleich in verification.json zusammen. Die Option --steps zählt zusätzliche Schritte: Nach der Unterbrechung bei 5 führt der Wiederaufnahme-Befehl 5 aus, um 10 zu erreichen. Die Python-Option -B vermeidet Bytecode-Caches im Ordner der Übung.

Die vollständige Kontrolle auf der CPU ausführen
python -B verify_resume.py --output runs/preuve-cpu
Die drei Hauptdurchläufe manuell wiederholen
python -B train.py --steps 10 --output runs/continu
python -B train.py --steps 5 --output runs/coupure
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --output runs/reprise

Gewichtsexport und Wiederaufnahme-Checkpoint haben nicht dieselbe Rolle

Überlegen Sie zuerst, was Sie wiederherstellen möchten. Ein Export für die Inferenz dient dazu, mit einem trainierten Modell Vorhersagen zu erzeugen. Eine Trainings-Wiederaufnahme muss auch den Zustand wiederherstellen, der die nächsten Aktualisierungen bestimmt. Eine dateibasierte Inferenzverarbeitung benötigt dagegen eine zuverlässige Liste der bereits abgeschlossenen Elemente. Diese drei Anforderungen erzeugen unterschiedliche Sicherungen.

Verwechseln Sie diese persistente Sicherung nicht mit dem Activation Checkpointing. Diese Technik reduziert bestimmte im Speicher gehaltene Aktivierungen, indem sie sie während der Rückpropagation neu berechnet; sie erstellt für sich genommen keine Datei, die eine Wiederaufnahme nach einem Stopp ermöglicht. Geben Sie daher in Ihrem Projekt an, ob das Wort Checkpoint eine Speicheroptimierung oder einen Wiederaufnahmepunkt bezeichnet.

Die Zustände, die zusammenbleiben müssen

Das state_dict des Modells enthält die Parameter und die registrierten Buffer; der Optimierer hat seinen eigenen Zustand. Hier beeinflussen Adam, StepLR, das Dropout und drei Zufallsgeneratoren die nächsten Aktualisierungen. Der Checkpoint muss für all diese Elemente denselben Zeitpunkt darstellen.

Dokumentieren Sie außerdem die Codeversion, die Parameter des Experiments und die Identität der Daten. Mitten in einer Epoche reicht es nicht, nur deren Nummer zu kennen: Man muss die Reihenfolge der Beispiele und die nächste zu verbrauchende Gruppe wiederfinden können. Ein Fehler an dieser Stelle kann Einträge überspringen oder sie doppelt verarbeiten.

Der Datensatz aus 24 Zeilen beschreibt eine synthetische Beziehung zwischen zwei Variablen und einem Zielwert. Das Netzwerk zählt 33 Parameter, mit einer Schicht aus acht Neuronen und einem Dropout von 0,25. Der Batch enthält vier Zeilen. Nach fünf Aktualisierungen steht der Cursor bei 20 von 24: Der Schnitt liegt mitten in einer Epoche. Die zehn Aktualisierungen verbrauchen 40 Beobachtungen, was die Prüfung dazu zwingt, eine neue Permutation der Daten zu durchlaufen.

Scrollen Sie durch die Tabelle, um alle Spalten zu lesen.
Jeder Zustand beantwortet eine Frage der Wiederaufnahme
StatusRolleDurchzuführende Prüfung
ModellGewichte und Buffer behalten.Die endgültigen Parameter und eine Ausgabe der Evaluierung vergleichen.
OptimiererDie von der nächsten Aktualisierung verwendeten Zustände behalten.Dessen Neuladen prüfen, nicht nur seine Hyperparameter.
SchedulerDie Abfolge der Lernraten fortsetzen.Die nächste angewandte Rate und dann die folgenden Raten vergleichen.
RNG Python, NumPy und PyTorchDie tatsächlich verwendeten Ziehungen fortsetzen.Prüfen, dass die negative Übung ohne Wiederherstellung divergiert.
DatenDie Permutation und den Cursor fortsetzen.Die Identifikatoren der Einträge nach dem Schnitt vergleichen.
FortschrittDie Schritte und Epochen interpretieren.Insgesamt 10 Aktualisierungen erreichen, ohne eine erneut auszuführen oder auszulassen.
KonfigurationDasselbe Experiment rekonstruieren.Dimensionen, Genauigkeit, Einstellungen und Versionen behalten.

In der richtigen Reihenfolge wiederherstellen

Rekonstruieren Sie das Modell, den Optimierer und den Scheduler, bevor Sie ihre Zustände laden. Der Scheduler muss vor optimizer.load_state_dict() erstellt werden: Seine Konstruktion kann sonst die wiederhergestellten Lernraten überschreiben. Laden Sie außerdem seinen eigenen Zustand neu und prüfen Sie die im nächsten Schritt tatsächlich verwendete Rate.

Stellen Sie die Zufallsgeneratoren nach der Konstruktion der Objekte wieder her, die Ziehungen verbrauchen, unmittelbar bevor Sie die Arbeit fortsetzen. Einfach den Anfangsseed zurückzusetzen, würde die Sequenz wieder von vorn beginnen lassen; das bedeutet nicht, den nach der fünften Aktualisierung erreichten Zustand wiederzufinden. Identifizieren Sie in Ihrem Projekt alle verwendeten Generatoren, einschließlich derer der Transformationen und des Ladens der Daten.

In dieser Übung setzt Python einen leichten Gain auf die Eingaben, ein NumPy-Generator PCG64 erzeugt Rauschen und die Permutationen, und PyTorch erzeugt das Dropout. Der Checkpoint behält ihre zum Zeitpunkt des Schnitts erreichten Zustände. Der Prüfer beobachtet außerdem ihre nächsten Ziehungen und stellt den Zustand sofort wieder her, um den weiteren Ablauf der Berechnung nicht zu stören.

Reihenfolge der Wiederherstellung in train.py — Auszug aus dem vollständigen Pfad
optimizer = torch.optim.Adam(model.parameters(), lr=0.03)
scheduler = torch.optim.lr_scheduler.StepLR(optimizer, step_size=3, gamma=0.5)

# Im Pfad der Wiederaufnahme, nach der Konstruktion der Objekte:
state = load_checkpoint(resume)
model.load_state_dict(state["model"])
scheduler.load_state_dict(state["scheduler"])
optimizer.load_state_dict(state["optimizer"])
progress = state["progress"]
history = state["history"]
restore_rng(state["rng"], generator)
model.train()

Eine kohärente Speichergrenze wählen

Legen Sie eine explizite Grenze fest, zum Beispiel nach einer vollständigen Aktualisierung des Optimierers. Wenn Sie mehrere Microbatchs vor dieser Aktualisierung ansammeln, erzwingt ein Speichern in der Mitte auch die Verwaltung des Zwischenzustands. Eine erste Implementierung ist leichter zu prüfen, wenn sie an einer Grenze speichert, an der die akkumulierten Gradienten bereits verbraucht wurden.

Bewahren Sie mehrere Backup-Generationen auf. Schreiben Sie die neue Datei unter einem anderen Namen, warten Sie das Ende des Schreibvorgangs ab, prüfen Sie, ob sie lesbar ist, und markieren Sie sie erst dann als verwendbar. Ersetzen Sie nicht Ihren einzigen gültigen Checkpoint vor dieser Kontrolle. Die Häufigkeit hängt von der Arbeit ab, die Sie bereit sind zu wiederholen, und von der beobachteten Schreibdauer; sie lässt sich nicht allein aus der Mietdauer ableiten.

Das Mini-Projekt speichert nach einer abgeschlossenen Iteration, exportiert dann die Datei und ihren Fingerabdruck. Es verwendet einen neuen Ordner für jeden Durchlauf und ersetzt keinen vorherigen Nachweis. Wenn Ihr Training gemischte Präzision mit einem GradScaler verwendet, gehört sein Zustand ebenfalls zur Wiederaufnahme. Diese Variante ist nicht durch die CPU-Übung abgedeckt.

Den Vergleich und seine Toleranz lesen

Das Protokoll vergleicht die Fortsetzung nach Schritt 5: verbrauchte Daten, Lernrate, Verluste und erreichte Parameter. Eine Übereinstimmung allein der Schrittnummer genügt nicht. Ein zurückgesetzter Optimierer kann die Schleife fortsetzen und dabei dennoch andere Aktualisierungen erzeugen.

Die für diese Übung gewählte Toleranz ist absolut: 1e-12, mit einer relativen Toleranz von 0. Dieser Schwellenwert ist Teil des bereitgestellten CPU-Protokolls; er ist keine allgemeingültige Regel für Ihre Modelle. Der Vergleich muss nicht-finite Werte und strukturelle Unterschiede melden, anstatt stillschweigend eine unbrauchbare Ausgabe zu akzeptieren.

PyTorch garantiert keine identischen Ergebnisse zwischen Versionen, Plattformen, CPU und GPU. Wenn Sie die Übung übertragen, führen Sie den Nachweis auf dem Zielsystem erneut durch und erläutern Sie die gewählte Toleranz. Erweitern Sie den Schwellenwert nicht einfach, um einen Fehlschlag verschwinden zu lassen, dessen Ursache Sie nicht verstanden haben.

Im bereitgestellten Nachweis sind alle Abweichungen des vollständigen Durchlaufs null: Parameter, Optimiererzustand, Verluste, Raten und MSE. Auch die Reihenfolge der Zeilen, der Fortschritt, der Zustand des Schedulers und die nächsten Ziehungen stimmen überein. Die nächste Lernrate nach Schritt 10 beträgt in beiden Durchläufen 0,00375. Das Ergebnis hängt also nicht allein von einer abschließenden Metrik ab, die Zwischenunterschiede verdecken könnte.

Scrollen Sie durch die Tabelle, um alle Spalten zu lesen.
Messwerte des CPU-Nachweises; die Abweichungen sind absolut.
VergleichVollständige WiederaufnahmeWiederaufnahme ohne RNG-Wiederherstellung
Maximale Abweichung der Gewichte00,011669328447718508
Finale MSE0,095388585917750970,0936034144665111
MSE-Abweichung gegenüber dem kontinuierlichen Durchlauf00,001785171451239867
Urteil des Übereinstimmungs-SubtestsÜbereinstimmend innerhalb der Toleranz von 1e-12Abweichung erkannt

Warum der Negativfall ohne wiederhergestellte Zufälligkeit beibehalten wird

Eine Kontrolle ist nützlicher, wenn Sie wissen, welchen Fehler sie erkennt. Die Negativvariante lädt dieselben Gewichte, Optimierer-, Scheduler-Zustände und Fortschritte, lässt aber bewusst die RNG-Wiederherstellung aus. Der Prozess kann ohne Python-Ausnahme enden und dennoch eine andere Trajektorie verfolgen.

Im bereitgestellten Nachweis erzeugt dieses Auslassen eine maximale Gewichtsabweichung von über 0,011 und eine MSE-Differenz von über 0,0017. Die negative MSE ist hier niedriger als die des kontinuierlichen Durchlaufs: Das macht die Wiederaufnahme nicht korrekt. Das Ziel besteht darin, dasselbe Experiment wiederzufinden, nicht darin, zwei Modelle nach ihrem finalen Fehler zu ordnen.

Der Verifizierer ist nur dann erfolgreich, wenn der vollständige Durchlauf übereinstimmt und der Negativfall abweicht. Er zeigt dann all_checks_passed: true, positive: true und negative_divergence_detected: true an. Sein Exit-Code beträgt 0 bei erfolgreichem Protokoll, 1 wenn der Vergleich fehlschlägt und 2 wenn die Verifikation nicht abgeschlossen werden konnte.

Bewusst eine unvollständige Wiederaufnahme in einem neuen Ordner starten
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --omit-rng-restore --output runs/reprise-incomplete

Die Datei der Übung laden, ohne die Schutzmaßnahmen zu lockern

Das Projekt lädt ausschließlich den Checkpoint, den Sie mit dieser Übung erstellt und unter Ihrer Kontrolle aufbewahrt haben. Es verwendet explizit torch.load(..., map_location="cpu", weights_only=True). Der Python-Zustand enthält Primitive, der Zustand des NumPy-Generators PCG64 Ganzzahlen und Zeichenketten, und der Zustand von PyTorch CPU einen Byte-Tensor. Es wird kein beliebiges NumPy-Array im gespeicherten RNG-Zustand abgelegt.

Der Loader prüft den zugehörigen Fingerprint, die Größe, das Schema, den Fortschritt, die Versionen sowie die Identität von Code und Daten. Er lehnt einen inkonsistenten Zustand ab, statt stillschweigend ein fehlendes Element zurückzusetzen. Der Fingerprint erkennt eine Änderung; er authentifiziert nicht den Absender einer Datei.

Setzen Sie weights_only=False nicht einfach, um einen Ladefehler zum Schweigen zu bringen. Das gespeicherte Format und seine Rekonstruktion müssen konsistent sein. Das eingeschränkte Laden verringert die Möglichkeiten der Deserialisierung, macht aber eine unbekannte Datei nicht vertrauenswürdig.

Was sich für verteiltes Training ändert

Prüfen Sie bei mehreren Prozessen oder über GPUs verteilten Zuständen, wer was schreibt. Eine von einem einzelnen Prozess erzeugte Datei ist nicht zwangsläufig eine vollständige Sicherung der verteilten Arbeit. Verwenden Sie das in Ihrer Strategie vorgesehene Sicherungsverfahren und warten Sie dessen Abschluss bei den betroffenen Teilnehmern ab. Kennzeichnen Sie klar die Fragmente, die zum selben Wiederaufsetzpunkt gehören.

Eine Änderung der GPU-Anzahl kann eine Neuverteilung der Zustände erfordern und die Datenaufteilung verändern. Mechanismen für verteilte Checkpoints können bestimmte Änderungen bewältigen, doch diese Möglichkeit muss für Ihr Format und Ihre Konfiguration überprüft werden. Führen Sie einen Ladetest auf dem vorgesehenen Ziel durch. Das Hinzufügen von Batches zur Bestellung verwandelt eine Single-GPU-Sicherung nicht automatisch in ein verteiltes Programm.

Mit einem tatsächlich wiederherstellbaren Export abschließen

Exportieren Sie vor Fristablauf die nützlichen Checkpoints mit ihrer Konfiguration, den Metriken, den Ladeanweisungen und den Datenkennungen. Prüfen Sie die Größe und einen Fingerprint der kopierten Dateien und laden Sie dann mindestens eine Sicherung von ihrem Zielort. Ein identischer Fingerprint kontrolliert die Kopie; das Neuladen überprüft, ob der Inhalt tatsächlich ausreicht, um die Arbeit zu rekonstruieren.

Laden Sie nur Dateien, deren Herkunft Sie kennen, und wählen Sie ein geeignetes Format sowie geeignete Deserialisierungsoptionen. Behalten Sie den letzten validierten Wiederaufsetzpunkt, solange der neue Ihre Kontrollen nicht bestanden hat. Das erwartete Ergebnis ist ein wiederherstellbarer Ordner und ein kurzer Nachweis der Wiederaufnahme: ausgeführter Befehl, wiedergefundener Schritt, bestandene Kontrolle und exportiertes Ergebnis. Planen Sie diese Zeit in Ihren 3, 7 oder 30 Tagen ein.

Umfang des Nachweises und Wahl der Miete

Der Nachweis vom 24. September 2026 vergleicht vier neue Prozesse auf CPU, mit einer absoluten Toleranz von 1e-12 und keiner relativen Toleranz. Er deckt weder CUDA noch ROCm, AMP, verteiltes Training oder Datenlade-Worker ab. Er validiert die Wiederaufnahmelogik der bereitgestellten Version in der beschriebenen Umgebung und misst nicht die Fähigkeiten einer gemieteten GPU.

Übertragen Sie nach dieser kleinen Übung dasselbe Protokoll auf Ihr Modell, Ihre Daten und Ihr Backend. Eine Karte mit 80 GB oder eine Karte mit 192 GB korrigiert keinen unvollständigen Checkpoint: Wählen Sie zuerst die kompatible Kette und dimensionieren Sie dann den Speicher eines realen Schritts. Die unten verlinkten Angebote werden nicht als für diesen Nachweis getestete Hardware präsentiert.

Planen Sie in Ihrem Zeitraum von 3, 7 oder 30 Tagen einen ersten Zyklus aus Sicherung, Stopp und Wiederaufnahme sowie die Zeit für den abschließenden Export ein. Das nützliche Ergebnis ist ein Ordner, dessen Versionen, Wiederaufsetzpunkt, Vergleichskontrolle und Grenzen Sie erläutern können; die bloße Existenz einer .pt-Datei gibt diese Sicherheit nicht.