Skip to main content
Ein Status-Checkpoint schützt den serverseitigen Trainingsstatus. Ein vollständiger Wiederherstellungsdatensatz schützt außerdem den benutzereigenen Status, der Ihrem Controller vorgibt, was als Nächstes zu tun ist.

Was gespeichert werden muss

Der SDK-Trainingsclient repräsentiert einen interaktiven Fastino-Job. Lesen Sie seine kanonische ID aus training_client.get_info().model_data.model_id.

1. Status und Loop-Fortschritt speichern

Speichern Sie den Status über das SDK und persistieren Sie anschließend den zurückgegebenen Checkpoint mit den clientseitigen Feldern, die zum Fortfahren benötigt werden:
Verwenden Sie eindeutige Checkpoint-Namen, damit jeder Loop-Datensatz eine eindeutige Wiederherstellungsgrenze identifiziert. Gehen Sie nicht von einer undokumentierten Lebensdauer eines Checkpoints aus.

2. Neuesten vollständigen Datensatz lesen

Ein Prozess kann beim Schreiben der letzten Zeile beendet werden. Durchsuchen Sie die Datei rückwärts und überspringen Sie ein fehlerhaftes Ende:

3. Vor dem Laden validieren

Vergleichen Sie den Datensatz mit der gewünschten Fortsetzung:
  • kanonische Job-ID,
  • Basismodell und trainierbare Konfiguration,
  • Datensatzrevision und -Cursor,
  • Revision der Reward-Implementierung,
  • Optimizer-Konfiguration,
  • Annahmen zu Renderer und Tokenizer.
Halten Sie an und fordern Sie eine ausdrückliche Entscheidung an, wenn diese Felder im Konflikt stehen. Kombinieren Sie einen Checkpoint nicht stillschweigend mit einem anderen Experiment. Verwenden Sie anschließend den unterstützten Ablauf des SDK zum Laden des Status:
Diese SDK-Operation wird dem Laden eines Fastino-Checkpoints zugeordnet. Konstruieren Sie den Adapter-Request nicht direkt und leiten Sie aus der Operation keine zusätzliche Laufabstammung ab.

4. Grenze wiederherstellbar gestalten

Verwenden Sie diese Reihenfolge:
  1. Lösen Sie die Forward-/Backward- und Optimizer-Futures auf.
  2. Speichern Sie den Status-Checkpoint.
  3. Persistieren Sie den Loop-Datensatz mit seiner ID.
  4. Markieren Sie den Anwendungsschritt als abgeschlossen.
  5. Beginnen Sie den nächsten Schritt.
Wenn der Prozess nach dem Speichern des Checkpoints, aber vor dem Persistieren des Loop-Datensatzes beendet wird, behalten Sie den vorherigen vollständigen Datensatz als vertrauenswürdigen Wiederherstellungspunkt. Markieren Sie einen Schritt nicht als abgeschlossen, bevor sein Datensatz dauerhaft gespeichert ist.

5. Checkpoint-Arten getrennt halten

Verwenden Sie einen Status-Checkpoint zur Wiederherstellung des Trainings. Verwenden Sie einen Sampler-Checkpoint für Rollouts oder Evaluierung. Verwenden Sie einen Sampler-Checkpoint nicht als Wiederherstellungspunkt für den Optimizer-Status. Die öffentliche Training API kann Checkpoints auflisten. Sie kann einen interaktiven Checkpoint herunterladen, wenn das Team sowohl Zugriff auf interaktives Training als auch die Berechtigung zum Herunterladen von Gewichten hat. Das SDK unterstützt außerdem Methoden zum Löschen, Veröffentlichen und Aufbewahren von Checkpoints sowie zur Speichernutzung. Das sind SDK-Operationen, keine öffentlichen Routen der Training API. Konstruieren Sie keine Adapter-Requests und gehen Sie nicht von einer undokumentierten Aufbewahrungsdauer aus.

6. Fortsetzung prüfen

Vor dem Skalieren des fortgesetzten Workloads:
  1. Laden Sie den ausgewählten Status-Checkpoint.
  2. Bestätigen Sie die kanonische Job-ID des SDK-Clients über GET /v1/training/jobs/{job_id}.
  3. Führen Sie eine kleine zurückgehaltene Evaluierung aus.
  4. Senden Sie ein unterstütztes Trainingsupdate.
  5. Speichern Sie einen neuen Status-Checkpoint unter einem neuen Namen.
  6. Persistieren Sie den nächsten Loop-Datensatz.
Verwenden Sie das SDK für alle interaktiven Modelloperationen.

Wiederherstellungsfehler diagnostizieren