Partager via

Schéma YAML du travail parallèle CLI (v2)

  • Article

S’APPLIQUE À : Extension ml Azure CLI v2 (actuelle)

Important

Un travail parallèle peut uniquement être utilisé en tant qu’étape unique dans un travail de pipeline Azure Machine Learning. Pour l’instant, il n’existe donc aucun schéma JSON source pour les travaux parallèles. Ce document liste les clés qui sont valides, ainsi que leurs valeurs, pour la création d’un travail parallèle dans un pipeline.

Notes

La syntaxe YAML détaillée dans ce document est basée sur le schéma JSON pour la dernière version de l’extension ML CLI v2. Le fonctionnement de cette syntaxe est garanti uniquement avec la dernière version de l’extension ML CLI v2. Vous trouverez les schémas des versions d’extension plus anciennes sur https://azuremlschemasprod.azureedge.net/.

Syntaxe YAML

Clé Type Description Valeurs autorisées Valeur par défaut
type const Obligatoire. Le type de travail. parallel
inputs object Dictionnaire d’entrées dans le travail parallèle. La clé est un nom pour l’entrée dans le contexte du travail et la valeur est la valeur d’entrée.

Les entrées peuvent être référencées dans la program_arguments à l’aide de l’expression ${{ inputs.<input_name> }}.

Les entrées de travail parallèle peuvent être référencées par des entrées de pipeline à l’aide de l’expression ${{ parent.inputs.<input_name> }}. Pour savoir comment lier les entrées d’une étape parallèle aux entrées du pipeline, consultez Liaison d’entrées et de sorties entre les étapes d’un travail de pipeline.
inputs.<input_name> nombre, entier, booléen, chaîne ou objet Une valeur littérale (de type nombre, entier, booléen ou chaîne) ou un objet contenant une spécification de données d’entrée de travail.
outputs object Dictionnaire des configurations de sortie du travail parallèle. La clé est un nom pour l’entrée dans le contexte du travail et la valeur est la configuration de sortie.

Les sorties de travail parallèle peuvent être référencées par des sorties de pipeline à l’aide de l’expression ${{ parents.outputs.<output_name> }}. Pour savoir comment lier les sorties d’une étape parallèle aux sorties du pipeline, consultez Liaison d’entrées et de sorties entre les étapes d’un travail de pipeline.
outputs.<output_name> object Vous pouvez laisser l’objet vide. Dans ce cas, par défaut, la sortie sera de type uri_folder et Azure Machine Learning générera un emplacement de sortie pour la sortie en fonction du modèle de chemin d’accès suivant : {settings.datastore}/azureml/{job-name}/{output-name}/. Les fichiers dans le répertoire de sortie sont écrits via le montage en lecture-écriture. Si vous souhaitez spécifier un mode différent pour la sortie, fournissez un objet contenant la spécification de sortie du travail.
compute string Nom de la cible de calcul sur laquelle exécuter le travail. Cette valeur peut être une référence à un calcul existant dans l’espace de travail (avec la syntaxe azureml:<compute_name>), ou local pour désigner l’exécution locale.

Lorsque vous utilisez un travail parallèle dans le pipeline, vous pouvez laisser ce paramètre vide, auquel cas le calcul sera sélectionné automatiquement par le default_compute du pipeline.		 local
task object Obligatoire. Modèle de définition des tâches distribuées pour le travail parallèle. Consultez Attributs de la clé task.
input_data object Obligatoire. Définissez les données d’entrée qui seront divisées en mini-lots pour exécuter le travail parallèle. Applicable uniquement pour référencer l’une des inputs du travail parallèle à l’aide de l’expression ${{ inputs.<input_name> }}
mini_batch_size string Définissez la taille de chaque mini-lot pour diviser l’entrée.

Si input_data est un dossier ou un ensemble de fichiers, ce nombre définit le nombre de fichiers de chaque mini-lot. Par exemple : 10, 100.
Si input_data correspond à des données tabulaires issues de mltable, ce nombre définit la taille physique approximative de chaque mini-lot. Par exemple, 100 Ko, 100 Mo.		 1
partition_keys list Clés utilisées pour partitionner le jeu de données en mini-lots.

Si la valeur est spécifiée, les données avec la même clé sont partitionnées dans le même mini-lot. Si les deux partition_keys et mini_batch_size sont spécifiés, les clés de partition prennent effet.
mini_batch_error_threshold entier Définissez le nombre de mini-lots ayant échoué qui peuvent être ignorés dans ce travail parallèle. Si le nombre de mini-lots ayant échoué est supérieur à ce seuil, le travail parallèle est marqué comme ayant échoué.

Le mini-lot est marqué comme ayant échoué si :
- le nombre de retours de run() est inférieur au nombre d’entrées par mini-lot.
- des exceptions ont été interceptées dans le code run() personnalisé.

« -1 » est le nombre par défaut, ce qui signifie ignorer tous les mini-lots ayant échoué pendant le travail parallèle.		 [-1, int.max] -1
logging_level string Définissez quel niveau de journaux sera sauvegardé vers les fichiers journaux utilisateur. INFORMATIONS, AVERTISSEMENT, DÉBOGAGE INFO
resources.instance_count entier Nombre de nœuds à dédier au travail. 1
max_concurrency_per_instance entier Définissez le nombre de processus à exécuter sur chaque nœud de calcul.

Pour un calcul GPU, la valeur par défaut est 1.
Pour un calcul CPU, la valeur par défaut est le nombre de cœurs.
retry_settings.max_retries entier Définissez le nombre de nouvelles tentatives lors de l’échec ou du délai d’expiration du mini-lot. Si toutes les nouvelles tentatives ont échoué, le mini-lot est marqué comme ayant échoué par calcul mini_batch_error_threshold. 2
retry_settings.timeout entier Définissez le délai d’expiration en secondes pour l’exécution de la fonction run() personnalisée. Si le temps d’exécution est supérieur à ce seuil, le mini-lot est abandonné et marqué comme un mini-lot ayant échoué pour déclencher une nouvelle tentative. (0, 259200] 60
environment_variables object Dictionnaire de paires clé-valeur de variable d’environnement à définir sur le processus dans lequel la commande est exécutée.

Attributs de la clé task

Clé Type Description Valeurs autorisées Valeur par défaut
type const Obligatoire. Type de la tâche. Applicable uniquement à run_function.

En mode run_function, vous devez fournir code, entry_script et program_arguments pour définir un script Python comprenant des fonctions et des arguments exécutables. Remarque : Dans ce mode, le travail parallèle prend uniquement en charge le script Python.		 run_function run_function
code string Chemin d’accès local au répertoire du code source à télécharger et à utiliser pour le travail.
entry_script string Fichier Python qui contient l’implémentation de fonctions parallèles prédéfinies. Pour plus d’informations, consultez Préparer le script d’entrée d’un travail parallèle.
environment chaîne ou objet Obligatoire L’environnement à utiliser pour exécuter la tâche. Cette valeur peut être une référence à un environnement versionné existant dans l’espace de travail ou une spécification d’environnement inline.

Pour référencer un environnement existant, utilisez la syntaxe azureml:<environment_name>:<environment_version> ou azureml:<environment_name>@latest (pour référencer la version la plus récente d’un environnement).

Pour définir un environnement inline, consultez Schéma de l’environnement. Excluez les propriétés name et version, car elles ne sont pas prises en charge pour les environnements inline.
program_arguments string Les arguments à passer au script d’entrée. Peut contenir la référence « --<nom_arg> ${{inputs.<nom_entrée>}} » aux entrées ou sorties.

Le travail parallèle fournit une liste d’arguments prédéfinis permettant de définir la configuration de l’exécution parallèle. Pour plus d’informations, consultez Arguments prédéfinis pour un travail parallèle.
append_row_to string Agrégez tous les retours de chaque exécution de mini-lot et sortez-le dans ce fichier. Peut faire référence à l’une des sorties du travail parallèle à l’aide de l’expression ${{outputs.<>output_name}}

Entrées du travail

Clé Type Description Valeurs autorisées Valeur par défaut
type string Le type d’entrée de travail. Spécifiez mltable pour les données d’entrée qui pointent vers un emplacement où se trouve le métafichier mltable, ou spécifiez uri_folder pour les données d’entrée qui pointent vers une source de dossier. mltable, uri_folder uri_folder
path string Le chemin vers les données à utiliser comme entrée. La valeur peut être spécifiée de plusieurs façons :

- Chemin local du fichier ou dossier de source de données, par exemple path: ./iris.csv. Les données seront chargées lors de l’envoi du travail.

- URI d’un chemin d’accès cloud au fichier ou dossier à utiliser comme entrée. Les types d’URI pris en charge sont azureml, https, wasbs, abfss et adl. Pour plus d’informations sur l’utilisation du format d’URI azureml://, consultez Syntaxe YAML fondamentale.

- Une ressource de données Azure Machine Learning inscrite existante à utiliser comme entrée. Pour référencer une ressource de données inscrite, utilisez la syntaxe azureml:<data_name>:<data_version> ou azureml:<data_name>@latest (pour référencer la dernière version de cette ressource de données), par exemple path: azureml:cifar10-data:1 ou path: azureml:cifar10-data@latest.
mode string Mode de remise des données à la cible de calcul.

Pour un montage en lecture seule (ro_mount), les données sont consommées en tant que chemin de montage. Un dossier est monté en tant que dossier et un fichier est monté en tant que fichier. Azure Machine Learning résout l’entrée vers le chemin de montage.

Pour le mode download, les données sont téléchargées sur la cible de calcul. Azure Machine Learning résout l’entrée vers le chemin téléchargé.

Si vous souhaitez uniquement l’URL de l’emplacement de stockage des artefacts de données plutôt que de monter ou de télécharger les données elles-mêmes, vous pouvez utiliser le mode direct. Elle passera l’URL de l’emplacement de stockage en tant qu’entrée du travail. Dans ce cas, vous êtes entièrement responsable de la gestion des informations d’identification pour accéder au stockage.		 ro_mount, , downloaddirect ro_mount

Sorties du travail

Clé Type Description Valeurs autorisées Valeur par défaut
type string Type de sortie du travail. Pour le type uri_folder par défaut, la sortie correspond à un dossier. uri_folder uri_folder
mode string Mode de remise du ou des fichiers de sortie dans le stockage de destination. Pour le mode de montage en lecture-écriture (rw_mount), le répertoire de sortie est un répertoire monté. Pour le mode chargement, le ou les fichiers écrits sont chargés à la fin du travail. rw_mount, upload rw_mount

Arguments prédéfinis pour un travail parallèle

Clé Description Valeurs autorisées Valeur par défaut
--error_threshold Le seuil des éléments ayant échoué. Les éléments ayant échoué sont comptabilisés par l’écart de nombre entre les entrées et les retours de chaque mini-lot. Si le nombre de mini-lots ayant échoué est supérieur à ce seuil, le travail parallèle est marqué comme ayant échoué.

Remarque : « -1 » est le nombre par défaut, ce qui signifie ignorer tous les mini-lots ayant échoué pendant le travail parallèle.		 [-1, int.max] -1
--allowed_failed_percent Similaire à mini_batch_error_threshold mais utilise le pourcentage de mini-lots ayant échoué au lieu du nombre. [0, 100] 100
--task_overhead_timeout Délai d’expiration en seconde pour l’initialisation de chaque mini-lot. Par exemple, chargez des données mini-batch et transmettez-la à la fonction run(). (0, 259200] 30
--progress_update_timeout Délai d’expiration en seconde pour surveiller la progression de l’exécution de mini-lots. Si aucune mise à jour de progression n’est reçue dans ce paramètre de délai d’expiration, le travail parallèle est marqué comme ayant échoué. (0, 259200] Calculé dynamiquement par d’autres paramètres.
--first_task_creation_timeout Le délai en secondes pour contrôler le temps entre le début du travail et l'exécution du premier mini-lot. (0, 259200] 600
--copy_logs_to_parent Option booléenne permettant de copier la progression, la vue d’ensemble et les journaux du travail vers le pipeline parent. True, False Faux
--metrics_name_prefix Fournissez le préfixe personnalisé de vos métriques dans ce travail parallèle.
--push_metrics_to_parent Option booléenne pour indiquer si les métriques doivent être poussées (push) vers le travail de pipeline parent. True, False Faux
--resource_monitor_interval Intervalle de temps en secondes pour sauvegarder l’utilisation des ressources de nœud (par exemple, processeur, mémoire) dans le dossier journal sous le chemin « logs/sys/perf ».

Remarque : les journaux de ressources de sauvegarde fréquents ralentiront légèrement la vitesse d’exécution de votre mini-lot. Définissez cette valeur sur « 0 » pour arrêter la sauvegarde de l’utilisation des ressources.		 [0, int.max] 600

Notes

Les commandes az ml job peuvent être utilisées pour gérer les travaux Azure Machine Learning.

Exemples

Des exemples sont disponibles dans le référentiel d’exemples GitHub. Vous en trouverez plusieurs ci-dessous.

YAML : Utilisation d’un travail parallèle dans le pipeline

$schema: https://azuremlschemas.azureedge.net/latest/pipelineJob.schema.json
type: pipeline

display_name: iris-batch-prediction-using-parallel
description: The hello world pipeline job with inline parallel job
tags:
  tag: tagvalue
  owner: sdkteam

settings:
  default_compute: azureml:cpu-cluster

jobs:
  batch_prediction:
    type: parallel
    compute: azureml:cpu-cluster
    inputs:
      input_data: 
        type: mltable
        path: ./neural-iris-mltable
        mode: direct
      score_model: 
        type: uri_folder
        path: ./iris-model
        mode: download
    outputs:
      job_output_file:
        type: uri_file
        mode: rw_mount

    input_data: ${{inputs.input_data}}
    mini_batch_size: "10kb"
    resources:
        instance_count: 2
    max_concurrency_per_instance: 2

    logging_level: "DEBUG"
    mini_batch_error_threshold: 5
    retry_settings:
      max_retries: 2
      timeout: 60

    task:
      type: run_function
      code: "./script"
      entry_script: iris_prediction.py
      environment:
        name: "prs-env"
        version: 1
        image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04
        conda_file: ./environment/environment_parallel.yml
      program_arguments: >-
        --model ${{inputs.score_model}}
        --error_threshold 5
        --allowed_failed_percent 30
        --task_overhead_timeout 1200
        --progress_update_timeout 600
        --first_task_creation_timeout 600
        --copy_logs_to_parent True
        --resource_monitor_interva 20
      append_row_to: ${{outputs.job_output_file}}

Étapes suivantes