Skip to main content
Ihre Anwendung entscheidet, was gesampelt, wie es bewertet und wann es aktualisiert wird. Fastino führt die interaktiven Modelloperationen aus. Ein TrainingClient repräsentiert während des gesamten Loops einen interaktiven Fastino-Job.

Der Kontrollloop

1

Interaktiven Job erstellen

Wählen Sie base_model und weitere Optionen aus der Antwort zu den Fähigkeiten und rufen Sie anschließend create_lora_training_client(...) auf. Lesen Sie die kanonische Job-ID aus training_client.get_info().model_data.model_id.
2

Gewichte für Sampling als Checkpoint speichern

Rufen Sie save_weights_for_sampler(name) auf und erstellen Sie anschließend aus dem zurückgegebenen Checkpoint-Pfad einen Sampling-Client. Dadurch wird die Rollout-Policy an ein explizites Artefakt desselben Jobs gebunden.
3

Rollout-Gruppen sammeln

Sampeln Sie für jeden Prompt mehrere Antwortkandidaten. Ihre Anwendung ist für Prompt-Erstellung, Rendering der Antworten und Gruppierung verantwortlich.
4

Rewards und Advantages berechnen

Bewerten Sie jede Antwort und wandeln Sie die Rewards anschließend in die Advantages um, die von Ihrer ausgewählten und durch die Fähigkeiten unterstützten Trainingsoperation benötigt werden.
5

Trainings-Datums erstellen

Kombinieren Sie Modelleingaben, gesampelte Antwort-Tokens, Sampling-Metadaten und Trainingssignale auf Token-Ebene in der vom SDK erwarteten Form.
6

Denselben Job aktualisieren

Senden Sie unterstützte Forward-/Backward-Arbeit und anschließend einen Optimierungsschritt über den bestehenden TrainingClient.
7

Wiederherstellungsgrenze speichern

Speichern Sie einen Status-Checkpoint und persistieren Sie seine ID mit dem Anwendungsschritt und Datensatz-Cursor, bevor die nächste Iteration beginnt.

Objektmodell

Die SDK-Modell-ID ist die kanonische Fastino-Job-ID. Futures und Sampling-Clients erstellen keine unabhängigen Läufe. Wie Sie deterministisches Grading in gruppenrelative Advantages umwandeln, erfahren Sie unter Mit verifizierbaren Rewards trainieren.

Ausgerichtete Datums erstellen

Bei einem Loop im Importance-Sampling-Stil ist der Prompt der Kontext und die gesampelte Vervollständigung die Aktion. Halten Sie Token-Arrays auf das SDK und den Renderer des ausgewählten Modells ausgerichtet:
  • Modelleingabe mit Prompt- und Vervollständigungs-Tokens
  • An der Modelleingabe ausgerichtete Ziel-Tokens
  • An generierten Tokens ausgerichtete Sampling-Log-Wahrscheinlichkeiten
  • Auf Positionen der Vervollständigung angewendete Advantages
Prompt-Rendering, Tokenisierung, Erstellung von Datums und Reward-Ausführung liegen beim Client. Validieren Sie ihre Formen anhand von tinker==0.33.1 und der aktuellen Antwort zu den Fähigkeiten, bevor Sie einen größeren Workload ausführen.

Abhängige Arbeit geordnet halten

Lösen Sie ein Forward-/Backward-Future auf, bevor Sie diese Phase als abgeschlossen behandeln, und lösen Sie das Optimizer-Future auf, bevor Sie den aktualisierten Status als Checkpoint speichern. Lassen Sie nicht mehrere unabhängige Controller denselben Job ohne Koordination auf Anwendungsebene verändern. Das SDK führt diese interaktiven Operationen aus. Bilden Sie sie nicht als direkte HTTP-Aufrufe nach. Verfolgen Sie jedes Future, das ein unterstützter Aufruf zurückgibt. Lösen Sie Futures einzeln auf oder brechen Sie sie einzeln ab. Der Batch-Abruf über retrieve_futures wird nicht unterstützt.

Loop wiederherstellen

Speichern Sie die kanonische Job-ID, den Anwendungsschritt, den Datensatz-Cursor und die relevanten Future- oder Checkpoint-IDs dauerhaft. Ein neu gestarteter Controller kann dann ermitteln, welche Arbeit abgeschlossen wurde, ohne ein Update zu wiederholen. Die Wiederherstellungsreihenfolge und die Checkpoint-Arten finden Sie unter Checkpoints und Wiederherstellung.