Procedimientos recomendados para el proceso de GPU sin servidor

En este artículo se presentan las recomendaciones de mejores prácticas para usar el cómputo de GPU sin servidor en tus cuadernos y trabajos.

Siguiendo estas recomendaciones, mejorará la productividad, la rentabilidad y la confiabilidad de las cargas de trabajo en Azure Databricks.

Utilice el cómputo adecuado

• Utilice cómputo de GPU sin servidor. Esta opción incluye antorcha, cuda y torchvision optimizada para compatibilidad. Las versiones exactas del paquete dependerán de las versiones del entorno.
• Seleccione su acelerador en la barra lateral del entorno.
  • Para cargas de trabajo de entrenamiento distribuido remoto, use una GPU A10, que será el cliente para enviar un trabajo al H100 remoto más adelante.
  • Para ejecutar trabajos interactivos de gran tamaño en el propio cuaderno, puede adjuntar el cuaderno a H100, que ocupará 1 nodo (8 GPU H100).
• Para evitar el uso de GPUs, puede conectar su notebook a un clúster de CPU para algunas operaciones, como "git clone" y la conversión del Dataframe de Spark al formato de Partición de Datos de Mosaico (MDS).

Recomendaciones de MLflow

Para obtener un ciclo de desarrollo óptimo de ML, use MLflow 3 en Databricks. Siga estas sugerencias:

• Actualice MLflow en su entorno a la versión 3.6 o posterior y siga el flujo de aprendizaje profundo en el flujo de trabajo de aprendizaje profundo de MLflow 3.

• Establezca el parámetro step en MLFlowLogger a un número razonable de lotes. MLflow tiene un límite de 10 millones de pasos de métrica que se pueden registrar. Consulte Límites de los recursos.

• Habilite mlflow.pytorch.autolog() si se utiliza Pytorch Lightning como formador.

• 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,
  )
  

• La API de GPU sin servidor inicia un experimento de MLflow para registrar las métricas del sistema. De forma predeterminada, usa el nombre /Users/{WORKSPACE_USER}/{get_notebook_name()} a menos que el usuario lo sobrescriba con la variable MLFLOW_EXPERIMENT_NAMEde entorno .

  • Al establecer la variable de entorno MLFLOW_EXPERIMENT_NAME, utilice una ruta de acceso absoluta. Por ejemplo,/Users/<username>/my-experiment .
  • El nombre del experimento no debe contener el nombre de carpeta existente. Por ejemplo, si my-experiment es una carpeta existente, se producirá un error en el ejemplo anterior.

  import os
  from serverless_gpu import distributed
  os.environ['MLFLOW_EXPERIMENT_NAME'] = '/Users/{WORKSPACE_USER}/my_experiment'
  @distributed(gpus=num_gpus, gpu_type=gpu_type, remote=True)
  def run_train():
  # my training code
  

• Para reanudar el entrenamiento de una ejecución anterior, especifique el MLFLOW_RUN_ID de la ejecución anterior como se indica a continuación.

  import os
  os.environ[‘MLFLOW_RUN_ID’] = <previous_run_id>
  run_train.distributed()
  

Colaboración multiusuario

• Para asegurarse de que todos los usuarios pueden acceder al código compartido (por ejemplo, módulos auxiliares, environment.yaml), cree carpetas git en /Workspace/Repos o /Workspace/Shared en 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 /Workspace/Users/<your_email>/ específicas del usuario e inserte en repositorios de Git remotos. Esto permite a varios usuarios tener un clon específico del usuario (y una rama), pero seguir 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 Databricks

Consulte Límites de los recursos.