# Kernodeck Reprise v1 — ein tatsächlich neu gestarteter Checkpoint Diese ursprüngliche Übung erlernt eine kleine numerische Beziehung auf 24 synthetischen Zeilen. Ihr Ziel ist es, **die Wiederaufnahme eines Trainings zu überprüfen**, nicht das beste Modell zu erhalten oder eine GPU zu messen. Die Berechnung wird ausdrücklich auf **CPU** erzwungen, in `float64`, mit einem PyTorch-Thread. Die Kontrolle vergleicht 10 aufeinanderfolgende Schritte mit 5 Schritten, einem Checkpoint und dann 5 neuen Schritten in **einem anderen Python-Prozess**. Ein vierter Prozess lässt die Wiederherstellung der Zufallsgeneratoren absichtlich aus: Seine Abweichung muss erkannt werden. Es werden keine entfernten Ressourcen, Kundendaten oder vortrainierten Gewichte heruntergeladen. ## Voraussetzungen - Eine Python-Umgebung mit bereits installiertem PyTorch und NumPy. Der bereitgestellte Nachweis wurde mit **Python 3.14.6, PyTorch 2.11.0+cu128 und NumPy 2.4.4** ausgeführt. - Etwa 1 MB verfügbarer Speicher für die vier kleinen Ausgabeordner. Die Python-Abhängigkeiten belegen ihren eigenen Speicherplatz. - Führen Sie die Befehle aus dem entpackten Ordner `kernodeck-reprise-v1` aus. Das Suffix `+cu128` beschreibt das zum Testzeitpunkt vorhandene Paket; es bedeutet nicht, dass diese Übung CUDA verwendet hat. **Es wird keine CUDA-, ROCm-, AMP-, Multi-GPU- oder verteilte Berechnung durch diese Ressource validiert.** Sie verwendet keine DataLoader-Worker. Eine andere Umgebung muss ihren eigenen Nachweis erbringen; Gleichheit zwischen Versionen oder Plattformen wird nicht zugesichert. ## Der Verifikationsbefehl ```console python -B verify_resume.py --output runs/preuve-cpu ``` `-B` vermeidet Bytecode-Caches im Projektordner. Das Ausgabeverzeichnis muss neu sein: Kein bestehender Versuch wird überschrieben. Um neu zu beginnen, verwenden Sie zum Beispiel `runs/preuve-cpu-2`. Das Programm führt vier Befehle mit demselben Python-Interpreter aus und schreibt dann `runs/preuve-cpu/verification.json`. Ein vollständiger Lauf erwartet: ```json {"device":"cpu","all_checks_passed":true,"positive":true,"negative_divergence_detected":true,"report":"verification.json"} ``` Der Exit-Code beträgt **0**, wenn das Protokoll erfolgreich ist, **1**, wenn der Vergleich fehlschlägt, **2**, wenn die Verifikation nicht abgeschlossen werden konnte. Der Erfolg erfordert sowohl die positive Wiederaufnahme als auch das beobachtbare Scheitern der negativen Kontrolle. Eine bloß vorhandene Checkpoint-Datei genügt nicht. ## Die drei Schritte manuell ausführen ```console 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 ``` Jede Zeile startet einen eigenen Prozess. `--steps` bedeutet **zusätzliche Schritte**, daher endet der dritte Befehl bei Schritt 10. Jeder Ordner enthält `checkpoint.pt`, seinen Fingerabdruck `checkpoint.pt.sha256` und eine lesbare Zusammenfassung `summary.json`. Die Checkpoints werden von der Übung zur Laufzeit erstellt; sie sind nicht im Archiv enthalten. Um den unvollständigen Fall zu beobachten, verwenden Sie einen neuen Ordner: ```console python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --omit-rng-restore --output runs/reprise-incomplete ``` Dieser letzte Befehl kann ohne Python-Fehler enden. **Das beweist keine korrekte Wiederaufnahme.** Der Befehl `verify_resume.py` vergleicht die Ergebnisse und stellt die Differenz fest. ## Was das Modell tatsächlich tut `data.csv` enthält ein Raster mit zwei Variablen und ein synthetisches Ziel: `target = 0.7*x1 - 0.4*x2 + 0.15*x1*x2 + 0.1`. Es bildet keine Kundenerhebung nach. Das Netzwerk hat zwei Eingaben, eine Schicht mit acht Neuronen, `Tanh`, ein Dropout von 0,25 und eine Ausgabe, also 33 Parameter. Das Training verwendet Adam mit einer Anfangsrate von 0,03. StepLR halbiert diese Rate alle drei Schritte. Jeder Batch umfasst vier Zeilen: 10 Schritte verbrauchen also 40 Beobachtungen, wobei einige Zeilen nach der ersten Epoche erneut durchlaufen werden. Die Permutation, die Epoche, der Cursor und die Anzahl der verbrauchten Beobachtungen werden beibehalten. Bei der Unterbrechung nach fünf Schritten beträgt der Cursor 20 von 24: Die Wiederaufnahme erfolgt **innerhalb des Daten-Durchlaufs**. Drei Zufallsquellen beeinflussen die Arbeit: Python setzt einen leichten Gain auf die Eingaben, ein NumPy-PCG64-Generator erzeugt das Rauschen und die Permutationen, PyTorch erzeugt das Dropout. Das erneute Setzen des Anfangs-Seeds stellt die zum Zeitpunkt der Unterbrechung erreichten Zustände nicht wieder her. ## Was der Checkpoint speichert und in welcher Reihenfolge er erneut eingelesen wird Das Wörterbuch enthält die Gewichte, den Adam-Zustand, den StepLR-Zustand, den Datenfortschritt, die drei RNGs, den Verlauf der Verluste und Raten sowie die Fingerabdrücke des Codes und der CSV. Der Modus `train()` wird für die Wiederaufnahme wiederhergestellt; die abschließende MSE-Messung verwendet `eval()` und verbraucht kein Dropout. Bei der Wiederaufnahme erstellt der Code zuerst das Modell, den Optimierer und **den Scheduler** und lädt dann die Gewichte, den Zustand des Schedulers und den des Optimierers. Die RNGs werden zuletzt wiederhergestellt, nach den Konstruktionen, die Zufälligkeit verbrauchen. Diese Wahl folgt dem Hinweis in der Dokumentation zu [Optimizer.load_state_dict](https://docs.pytorch.org/docs/2.11/generated/torch.optim.Optimizer.load_state_dict.html). Der Python-Zustand ist eine Struktur aus Primitiven. PCG64 liefert ein Wörterbuch aus Ganzzahlen und Zeichenketten; kein NumPy-`ndarray`-Objekt wird als RNG-Zustand serialisiert. Der PyTorch-CPU-Zustand ist ein Byte-Tensor. Die nächsten Ziehungen werden kontrolliert, ohne den gespeicherten Zustand zu verändern. ## Lesen des Nachweises und Toleranz `verification-cpu.json` ist der öffentliche Nachweis aus einer realen Ausführung dieser Version. `source` enthält die SHA-256 der Skripte und der CSV. `protocol` beschreibt die vier Prozesse, die Genauigkeit und die Toleranz. `resume_boundary` prüft die nächste Ziehung jedes RNG und die nächste verwendete Rate nach der Unterbrechung. Der Vergleich erfordert dieselbe Zeilenreihenfolge, denselben Fortschritt und denselben Scheduler-Zustand. Die maximal akzeptierte absolute Abweichung für die Gewichte, den Optimierer-Zustand, die Verluste, die MSE und die Raten beträgt **1e-12**, ohne relative Toleranz (`rtol=0`). Der Bericht behält die gemessenen Abweichungen bei, auch wenn sie null betragen. Er prüft außerdem die nächste Ziehung der RNGs am Ende beider Durchläufe. Die Negativkontrolle muss zeigen, dass das Vergessen der RNGs das Ergebnis verändert. Ihre MSE kann niedriger oder höher sein: Dieser Test prüft eine Wiederaufnahme-Trajektorie, keine Qualitätsrangfolge. Eine erwartete Divergenz ergibt daher `passed: false` in diesem Untertest und `divergence_detected: true`; das Gesamtprotokoll kann dann trotzdem erfolgreich sein. ## Nur den eigenen Checkpoint laden Der Loader verwendet ausdrücklich `torch.load(..., map_location="cpu", weights_only=True)` und bietet keinen Fallback auf `weights_only=False` an. Er prüft zuerst den zugehörigen Fingerabdruck, begrenzt die Größe und prüft das Schema, die Versionen, den Code und die Daten. Er lehnt einen unvollständigen Zustand ab, statt stillschweigend einen Teil des Trainings zurückzusetzen. Verwenden Sie ausschließlich Checkpoints, die **Sie mit dieser Übung erstellt und unter Ihrer Kontrolle aufbewahrt haben**. Der Fingerabdruck dient dazu, eine Veränderung zu erkennen; er authentifiziert keinen Absender. Das eingeschränkte Laden macht eine unbekannte Datei nicht vertrauenswürdig. Siehe [torch.load](https://docs.pytorch.org/docs/2.11/generated/torch.load.html) und [die PyTorch-Serialisierung](https://docs.pytorch.org/docs/2.11/notes/serialization.html). ## Die Übung an Ihr Projekt anpassen Identifizieren Sie die Zustände, die Ihr eigenes Training tatsächlich verbraucht: Sampler, Augmentation, Optimierer, Scheduler und besondere Generatoren. Wenn Sie AMP verwenden, fügen Sie den Zustand des Scalers an einer konsistenten Grenze hinzu; diese Übung tut das nicht. Ein verteiltes Training erfordert außerdem, seine Prozesse und ihre Datenverteilung zu behandeln. Leiten Sie aus diesem kleinen Nachweis keine Mietdauer, keinen Durchsatz, keinen VRAM-Fingerabdruck oder eine Wiederaufnahme-Garantie für ein anderes Modell ab. Gehen Sie nach derselben Methode vor: kurzes repräsentatives Set, Unterbrechung mitten in der Arbeit, anderer Prozess, expliziter Vergleich und Negativkontrolle. ## Inhalt und Lizenzen - `train.py`, `verify_resume.py`, diese Dokumentation und das Manifest: MIT-Lizenz, siehe `LICENSE-MIT.txt`. - `data.csv`: ursprüngliche synthetische Daten, bereitgestellt unter CC0 1.0, siehe `DATA-LICENSE-CC0.txt`. - `verification-cpu.json`: Messungen dieser Übung, ohne personenbezogene Daten, vollständige Umgebung, Pfade des Rechners, Token oder Sitzungs-IDs. - `manifest.json`: exakte Liste der verteilten Dateien und ihrer SHA-256. Das Manifest referenziert sich nicht selbst. - `SOURCES.md`: offizielle Links und dokumentarische Grenzen. Die Abhängigkeiten PyTorch, NumPy und Python behalten ihre eigenen Lizenzen. Sie werden nicht im ZIP weitergegeben. ## Vorstellung von Kernodeck und Kompatibilität des Projekts Diese Neuausgabe vom 25. September 2026 aktualisiert den Namen des Archivs, die Dokumentation und die Marke. Die Skripte `train.py` und `verify_resume.py`, die CSV und `verification-cpu.json` bleiben identisch mit der am 24. September 2026 ausgeführten Lieferung. Das technische Feld `project` behält seine Kennung für bestehende Berichtsleser. Für diese Neuausgabe wurden keine CPU/GPU-Berechnungen oder -Prüfungen erneut ausgeführt.