Seguimiento de experimentos y observabilidad

AI Runtime se integra de forma nativa con MLflow para el seguimiento de experimentos e incluye un panel integrado de recursos de GPU para supervisar el uso, la memoria y la temperatura. Use MLflow para registrar métricas y ejecuciones, ver la salida de entrenamiento en el cuaderno y la interfaz de usuario de MLflow, guardar los puntos de control del modelo en volúmenes de Catálogo de Unity y realizar un seguimiento del estado de la GPU mientras se ejecuta el código.

Integración de MLflow

AI Runtime se integra de forma nativa con MLflow para el seguimiento de experimentos, el registro de modelos y la visualización de métricas.

Recomendaciones de configuración:

• Actualice MLflow a la versión 3.7 o posterior y siga los patrones de flujo de trabajo de aprendizaje profundo.

• Habilite el registro automático para PyTorch Lightning:

  import mlflow
  mlflow.pytorch.autolog()
  

• Personalice el nombre de ejecución de MLflow encapsulando el código de entrenamiento del modelo dentro del ámbito de la mlflow.start_run() API. Esto le proporciona control sobre el nombre de ejecución y le permite reiniciar desde una ejecución anterior. Puede personalizar el nombre de ejecución mediante el run_name parámetro en mlflow.start_run(run_name="your-custom-name") o en bibliotecas de terceros que admitan MLflow (por ejemplo, Hugging Face Transformers). De lo contrario, el nombre de ejecución predeterminado es jobTaskRun-xxxxx.

  from transformers import TrainingArguments
  args = TrainingArguments(
      report_to="mlflow",
      run_name="llama7b-sft-lr3e5",  # <-- MLflow run name
      logging_steps=50,
  )
  

• Al usar la API de GPU sin servidor, cada llamada a .distributed() crea automáticamente una ejecución de experimento en MLflow. Si se invoca dentro de una ejecución activa de MLflow, se crea una ejecución secundaria anidada bajo la ejecución principal activa.

  import mlflow
  
  with mlflow.start_run() as outer_run:
      ...
      run_train.distributed()  # creates a nested child run under outer_run
  

• Para personalizar el experimento usado por .distributed(), llame mlflow.set_experiment() a antes de invocar .distributed()o establecer la MLFLOW_EXPERIMENT_NAME variable de entorno. El nombre predeterminado del experimento es /Users/{WORKSPACE_USER}/{notebook-name}. Use siempre rutas de acceso absolutas.

  import mlflow
  mlflow.set_experiment("/Users/<username>/my-experiment")
  run_train.distributed()
  

  Alternatively:

  import os
  os.environ["MLFLOW_EXPERIMENT_NAME"] = "/Users/<username>/my-experiment"
  

• Para reanudar una ejecución anterior de MLflow, use mlflow.start_run(run_id="<previous-run-id>").

• Para reanudar una ejecución de MLflow anterior con .distributed(), establezca MLFLOW_RUN_ID antes de llamarla:

  os.environ["MLFLOW_RUN_ID"] = "<previous-run-id>"
  run_train.distributed()
  

• Establezca el parámetro step en MLFlowLogger a números de lote razonables. MLflow tiene un límite de 10 millones de pasos métricos, por lo que registrar cada lote en ejecuciones de entrenamiento de gran tamaño puede alcanzar este límite. Consulte Límites de los recursos.

Visualización de registros

• Salida del cuaderno: La salida estándar y los errores de tu código de entrenamiento aparecen en la salida de la celda del cuaderno.
• Registros de MLflow: la interfaz de usuario del experimento de MLflow muestra métricas de entrenamiento, parámetros y artefactos.

Puntos de control de modelos

Para el entrenamiento distribuido, guarde y cargue los puntos de control del modelo de forma asincrónica en volúmenes de Catálogo de Unity, que proporcionan la misma gobernanza que otros objetos de Catálogo de Unity. Utiliza UCVolumeWriter y UCVolumeReader del paquete serverless_gpu.data con la API Torch Distributed Checkpoint (DCP). Estos back-ends de almacenamiento preparan toda la E/S a través de un directorio local rápido (/tmp, que son nodos de GPU sin servidor basados en NVMe) y cargan o descargan del volumen de Unity Catalog, lo que resulta más rápido que escribir particiones de puntos de control directamente en el montaje de FUSE. Se conserva la atomicidad de metadatos: el escritor publica el .metadata archivo solo después de que sus particiones de datos terminen de cargarse.

El punto de control suele ser suficiente para limitar el trabajo perdido después de una interrupción, pero no con tanta frecuencia que la sobrecarga de E/S ralentice el entrenamiento. Apunte a un punto de control cada 30 minutos a una hora y ajuste el intervalo en función del tiempo del paso y el tamaño del punto de comprobación.

Para subir puntos de control en segundo plano mientras continúa el entrenamiento, pase un UCVolumeWriter como storage_writer a dcp.async_save. Los almacenamientos asincrónicos requieren un back-end de CPU en el grupo de procesos, por tanto, inicialícelo con torch.distributed.init_process_group(backend="cpu:gloo,cuda:nccl", ...):

import torch.distributed.checkpoint as dcp
from serverless_gpu.data import UCVolumeWriter

checkpoint_path = "/Volumes/my_catalog/my_schema/model/checkpoints"
writer = UCVolumeWriter(checkpoint_path)

future = dcp.async_save(state_dict, storage_writer=writer)
# ...continue training...
future.result()  # blocks until the upload lands on the UC volume

Cargue un punto de control con UCVolumeReader:

from serverless_gpu.data import UCVolumeReader

reader = UCVolumeReader(checkpoint_path)
dcp.load(state_dict, storage_reader=reader)

Punto de control del canal de datos

Un punto de control de modelo captura el estado del optimizador y del modelo, pero no la posición de la canalización de datos dentro del conjunto de datos, por lo que una ejecución reanudada no puede avanzar rápidamente al ejemplo exacto donde se detuvo. Tenga esto en cuenta al reanudar: reinicie desde un límite de época, o realice un seguimiento de las muestras o particiones procesadas en su propio estado de entrenamiento para poder omitirlas al reanudar.

Supervisión de recursos de GPU

Use el panel recursos de GPU para supervisar el estado y el uso de LA GPU mientras el código se ejecuta en el entorno de ejecución de IA. El panel admite cargas de trabajo de nodo único y de varios nodos.

Para abrir el panel, conecte el cuaderno a AI Runtime y, a continuación, haga clic en Recursos de GPU en el panel derecho.

En el panel se muestran las métricas siguientes para cada GPU:

• Porcentaje de uso de GPU
• Uso de memoria de GPU
• Temperatura

El panel sondea las métricas cada 10 segundos y conserva hasta 2 horas de historial. Haga clic en Actualice para capturar los valores más recientes inmediatamente. Después de 5 minutos de inactividad, el panel se pausa; vuelva a abrirlo para reanudar la supervisión.

Colaboración multiusuario

• Para asegurarse de que todos los usuarios pueden acceder al código compartido (por ejemplo, módulos auxiliares o archivos YAML de entorno), almacénelos en /Workspace/Shared lugar de carpetas específicas del usuario como /Workspace/Users/<your_email>/.
• En el caso del código que esté en desarrollo activo, use carpetas de Git en carpetas específicas del usuario /Workspace/Users/<your_email>/ e insértelas en repositorios de Git remotos. Esto permite a varios usuarios tener un clon y una rama específicos del usuario, mientras sigue usando un repositorio de Git remoto para el control de versiones. Consulte los procedimientos recomendados para usar Git en Databricks.
• Los colaboradores pueden compartir y comentar en cuadernos.

Límites globales en Azure Databricks

Consulte Límites de los recursos.