Skip to main content
Tu aplicación decide qué muestrear, cómo puntuarlo y cuándo actualizar. Fastino ejecuta las operaciones interactivas del modelo. Un TrainingClient representa un trabajo interactivo de Fastino durante todo el bucle.

​
El bucle de control

1

Crea el trabajo interactivo

Elige un base_model y otras opciones de la respuesta de capacidades, llama a create_lora_training_client(...) y lee el ID canónico del trabajo de training_client.get_info().model_data.model_id.
2

Captura los pesos para el muestreo

Llama a save_weights_for_sampler(name) y crea un cliente de muestreo con la ruta del checkpoint devuelta. Esto vincula la política de rollout a un artefacto explícito del mismo trabajo.
3

Recopila grupos de rollouts

Muestrea varias respuestas candidatas para cada prompt. Tu aplicación controla la construcción de prompts, el renderizado y la agrupación.
4

Calcula recompensas y ventajas

Puntúa cada respuesta y transforma las recompensas en las ventajas que requiera la operación de entrenamiento compatible seleccionada.
5

Construye los datums de entrenamiento

Combina entradas del modelo, tokens de respuestas muestreadas, metadatos de muestreo y señales de entrenamiento por token con la forma esperada del SDK.
6

Actualiza el mismo trabajo

Envía el trabajo compatible hacia delante/hacia atrás y después un paso del optimizador mediante el TrainingClient existente.
7

Guarda un límite de recuperación

Guarda un checkpoint de estado y conserva su identificador con el paso de la aplicación y el cursor del dataset antes de iniciar la siguiente iteración.

​
Modelo de objetos

El ID de modelo del SDK es el ID canónico del trabajo de Fastino. Los futures y los clientes de muestreo no crean ejecuciones independientes. Para convertir una evaluación determinista en ventajas relativas al grupo, sigue Entrenar con recompensas verificables.

​
Construye datums alineados

En un bucle de muestreo por importancia, el prompt es el contexto y la finalización muestreada es la acción. Mantén los arrays de tokens alineados con el SDK y el renderizador del modelo seleccionado:
  • Entrada del modelo con tokens del prompt y de la finalización
  • Tokens objetivo alineados con la entrada del modelo
  • Probabilidades logarítmicas de muestreo alineadas con los tokens generados
  • Ventajas aplicadas a las posiciones de la finalización
El renderizado de prompts, la tokenización, la construcción de datums y la ejecución de recompensas pertenecen al cliente. Valida sus formas con tinker==0.33.1 y la respuesta de capacidades activa antes de aumentar la carga.

​
Mantén ordenado el trabajo dependiente

Resuelve un future hacia delante/hacia atrás antes de considerar completa esa etapa y el future del optimizador antes de crear el checkpoint del estado actualizado. No permitas que controladores independientes muten el mismo trabajo sin coordinación en la aplicación. El SDK realiza estas operaciones interactivas. No las reproduzcas como llamadas HTTP directas. Haz un seguimiento de cada future que devuelva una llamada compatible. Resuelve o cancela los futures de forma individual. No se admite la recuperación por lotes mediante retrieve_futures.

​
Recupera el bucle

Conserva el ID canónico del trabajo, el paso de la aplicación, el cursor del dataset y los identificadores de futures o checkpoints relevantes. Así, un controlador reiniciado puede determinar qué trabajo se completó sin repetir una actualización. Para conocer la secuencia de recuperación y los tipos de checkpoint, sigue Checkpoints y recuperación.