Skip to main content
Un checkpoint d’état protège l’état d’entraînement côté serveur. Un enregistrement de récupération complet protège également l’état contrôlé par l’utilisateur qui indique à votre contrôleur ce qu’il doit faire ensuite.

Éléments à enregistrer

Le client d’entraînement du SDK représente un job interactif Fastino. Lisez son ID canonique dans training_client.get_info().model_data.model_id.

1. Enregistrer l’état et la progression de la boucle

Enregistrez l’état via le SDK, puis conservez le checkpoint renvoyé avec les champs contrôlés par le client nécessaires à la poursuite :
Utilisez des noms de checkpoint uniques afin que chaque enregistrement de boucle identifie une limite de récupération sans ambiguïté. Ne supposez pas une durée de vie de checkpoint non documentée.

2. Lire l’enregistrement complet le plus récent

Un processus peut s’arrêter pendant l’écriture de la dernière ligne. Parcourez les lignes à rebours et ignorez une fin mal formée :

3. Valider avant le chargement

Comparez l’enregistrement avec la poursuite demandée :
  • ID canonique du job
  • Modèle de base et configuration entraînable
  • Révision et curseur du dataset
  • Révision de l’implémentation de la récompense
  • Configuration de l’optimiseur
  • Hypothèses du renderer et du tokenizer
Arrêtez-vous pour obtenir une décision explicite si ces champs sont incompatibles. Ne combinez pas silencieusement un checkpoint avec une expérience différente. Utilisez ensuite le flux de chargement d’état pris en charge par le SDK :
Cette opération du SDK correspond au chargement d’un checkpoint Fastino. Ne construisez pas directement la requête vers l’adaptateur et ne déduisez aucune lignée d’exécution supplémentaire à partir de l’opération.

4. Rendre la limite récupérable

Respectez cet ordre :
  1. Résolvez les futures de passe avant/arrière et d’optimisation.
  2. Enregistrez le checkpoint d’état.
  3. Conservez l’enregistrement de boucle contenant son identifiant.
  4. Marquez l’étape de l’application comme terminée.
  5. Commencez l’étape suivante.
Si le processus s’arrête après l’enregistrement du checkpoint, mais avant la persistance de l’enregistrement de boucle, conservez l’enregistrement complet précédent comme point de récupération fiable. Ne marquez pas une étape comme terminée avant que son enregistrement ne soit durable.

5. Séparer les types de checkpoints

Utilisez un checkpoint d’état pour la récupération de l’entraînement. Utilisez un checkpoint d’échantillonneur pour les rollouts ou l’évaluation. N’utilisez pas un checkpoint d’échantillonneur comme point de récupération de l’état de l’optimiseur. L’API d’entraînement publique permet de lister les checkpoints. Elle permet de télécharger un checkpoint interactif lorsque l’équipe dispose à la fois de l’accès à l’entraînement interactif et de l’autorisation de télécharger les poids. Le SDK prend aussi en charge des méthodes de suppression, de publication, de rétention et d’utilisation du stockage des checkpoints. Ce sont des opérations SDK, et non des routes publiques de l’API d’entraînement. Ne construisez pas de requêtes vers l’adaptateur et ne supposez pas une durée de rétention non documentée.

6. Vérifier la poursuite

Avant d’augmenter la taille du workload repris :
  1. Chargez le checkpoint d’état sélectionné.
  2. Confirmez l’ID de job canonique du client SDK via GET /v1/training/jobs/{job_id}.
  3. Exécutez une petite évaluation sur un ensemble de validation.
  4. Soumettez une mise à jour d’entraînement prise en charge.
  5. Enregistrez un nouveau checkpoint d’état sous un nouveau nom.
  6. Conservez l’enregistrement de boucle suivant.
Utilisez le SDK pour toutes les opérations interactives sur le modèle.

Diagnostiquer les erreurs de récupération