ParallelRunConfig Classe

Définition de l’environnement qui configure l’environnement Python. Il peut être configuré pour utiliser un environnement Python existant ou pour configurer un environnement temporaire pour l’expérience. La définition de l’environnement est chargée de définir les dépendances d’application nécessaires, comme les packages conda ou pip.

Script utilisateur qui sera exécuté en parallèle sur plusieurs nœuds. Il s’agit du chemin du fichier local. Si source_directory est spécifié, entry_script est un chemin relatif dans le répertoire. Dans le cas contraire, il peut s’agir de n’importe quel chemin d’accès accessible sur l’ordinateur. Le entry_script doit contenir deux fonctions : init() : cette fonction doit être utilisée pour toute préparation coûteuse ou courante pour les inférences ultérieures, par exemple, la désérialisation et le chargement du modèle dans un objet global. run(mini_batch) : méthode à paralléliser. Chaque appel aura un mini-lot. « mini_batch» : l’inférence par lots va appeler la méthode d’exécution et transmettre soit une liste, soit un dataframe Pandas en tant qu’argument de la méthode. Chaque entrée de min_batch sera un filepath (chemin de fichier) si l’entrée est un FileDataset, ou un dataframe Pandas si l’entrée est un TabularDataset. La méthode run() doit retourner un dataframe Pandas ou un tableau. Pour append_row output_action, les éléments retournés sont ajoutés au fichier de sortie commun. Pour summary_only, le contenu des éléments est ignoré. Pour toutes les actions de sortie, chaque élément de sortie retourné indique la réussite de son inférence dans le mini-lot d’entrée. Chaque processus Worker parallèle appelle init une fois, puis effectue une boucle sur la fonction run jusqu’à ce que tous les mini-lots soient traités.

nombre d’échecs d’enregistrement pour TabularDataset et d’échecs de fichiers pour FileDataset qui doivent être ignorés pendant le traitement. Si le nombre d’erreurs dépasse cette valeur, le travail sera interrompu. Le seuil d’erreurs concerne la totalité de l’entrée et non chacun des mini-lots envoyés à la méthode. La plage est [-1, int.max]. -1 indique d’ignorer toutes les défaillances lors du traitement.

Mode d’organisation de la sortie. Les valeurs actuellement prises en charge sont « append_row » et « summary_only ».

1. « append_row » : toutes les valeurs générées par les appels de la méthode run() sont agrégées dans un fichier unique nommé parallel_run_step.txt, qui est créé dans l’emplacement de sortie.
2. « summary_only » : le script utilisateur doit stocker la sortie elle-même. Une ligne de sortie est toujours attendue pour chaque élément d’entrée réussi traité. Le système utilise cette sortie uniquement pour le calcul du seuil d’erreur (en ignorant la valeur réelle de la ligne).

Cible de calcul à utiliser pour l’exécution ParallelRunStep. Ce paramètre peut être spécifié sous la forme d’un objet de cible de calcul ou du nom d’une cible de calcul dans l’espace de travail.

Nombre de nœuds dans la cible de calcul utilisée pour l’exécution de ParallelRunStep.

Nombre de processus Worker par nœud pour exécuter le script d’entrée en parallèle. Pour une machine GPU, la valeur par défaut est 1. Pour un ordinateur UC, la valeur par défaut est le nombre de cœurs. Un processus Worker appellera run() de manière répétée en transmettant le mini lot qu’il obtient. Le nombre total de processus Worker dans votre travail est process_count_per_node * node_count, qui détermine le nombre maximal de run() à exécuter en parallèle.

Pour une entrée FileDataset, ce champ correspond au nombre de fichiers que le script utilisateur peut traiter dans un appel de la méthode run(). Pour une entrée TabularDataset, ce champ correspond à la taille approximative des données que le script utilisateur peut traiter dans un appel de la méthode run(). Les exemples de valeurs sont 1 024, 1 024 Ko, 10 Mo et 1 Go. (Facultatif, la valeur par défaut est 10 fichiers pour FileDataset et 1 Mo pour TabularDataset.)

Chemins du dossier qui contient le entry_script et les fichiers complémentaires utilisés pour une exécution sur la cible de calcul.

Description du service Batch utilisé à des fins d’affichage.

Chaîne du nom du niveau de journalisation, définie dans « Logging ». Les valeurs possibles sont « WARNING », « INFO »et « DEBUG ». (Facultatif : la valeur par défaut est « INFO ».)

Délai d’expiration en secondes de chaque appel à la méthode run(). (La valeur par défaut facultative est 60.)

Nombre maximal de nouvelles tentatives pour un mini-lot ayant échoué ou dont le délai a expiré. La plage est [1, int.max]. La valeur par défaut est 3. Un mini-lot dont le nombre de dépilements est supérieur à cette valeur n’est pas retraité mais directement supprimé.

Nom du fichier de sortie si output_action a la valeur « append_row ». (Facultatif, la valeur par défaut est « parallel_run_step.txt »)

Nombre de mini-lots ayant échoué qui doivent être ignorés pendant le traitement. Si le nombre d’échec dépasse cette valeur, le travail est abandonné. Ce seuil concerne l’ensemble de l’entrée plutôt que le mini-lot envoyé à la méthode run(). La plage est [-1, int.max]. -1 indique d’ignorer toutes les défaillances lors du traitement. Un mini-lot peut échouer la première fois qu’il est traité, puis réussir à la deuxième tentative. Une vérification entre la première et la deuxième fois le compte la tentative comme un échec. Une vérification après la deuxième tentative ne la compte pas comme un échec. Les arguments –error_threshold, –allowed_failed_count and –allowed_failed_percent peuvent fonctionner ensemble. Si plusieurs éléments sont spécifiés, le travail est abandonné si l’une des valeurs est dépassée.

Pourcentage de mini-lots ayant échoué qui doivent être ignorés pendant le traitement. Si le pourcentage d’échec dépasse cette valeur, le travail est abandonné. Ce seuil concerne l’ensemble de l’entrée plutôt que le mini-lot envoyé à la méthode run(). La plage est [0, 100]. 100 ou 100.0 indique d’ignorer toutes les défaillances lors du traitement. La vérification démarre une fois tous les mini-lots planifiés. Les arguments –error_threshold, –allowed_failed_count and –allowed_failed_percent peuvent fonctionner ensemble. Si plusieurs éléments sont spécifiés, le travail est abandonné si l’une des valeurs est dépassée.

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 à la fois partition_keys et mini_batch_size sont spécifiés, une erreur est générée. Il doit s’agir d’une liste d’éléments str, chacun d’entre eux étant une clé utilisée pour partitionner le jeu de données d’entrée. Toutefois, si elle est promue en PipelineParameter, les valeurs par défaut doivent être l’élément str de vidage JSON de la liste, car le type de liste n’est pas pris en charge dans PipelineParameter actuellement. Les entrées doivent être des jeux de données partitionnés et partition_keys doit être un sous-ensemble des clés de chaque jeu de données d’entrée pour que cela fonctionne.

Dictionnaire des noms et valeurs des variables d’environnement. Ces variables d’environnement sont définies sur le processus où le script utilisateur est en cours d’exécution.

Définition de l’environnement qui configure l’environnement Python. Il peut être configuré pour utiliser un environnement Python existant ou pour configurer un environnement temporaire pour l’expérience. La définition de l’environnement est chargée de définir les dépendances d’application nécessaires, comme les packages conda ou pip.

Script utilisateur qui sera exécuté en parallèle sur plusieurs nœuds. Il s’agit du chemin du fichier local. Si source_directory est spécifié, entry_script est un chemin relatif dans le répertoire. Dans le cas contraire, il peut s’agir de n’importe quel chemin d’accès accessible sur l’ordinateur. Le entry_script doit contenir deux fonctions : init() : cette fonction doit être utilisée pour toute préparation coûteuse ou courante pour les inférences ultérieures, par exemple, la désérialisation et le chargement du modèle dans un objet global. run(mini_batch) : méthode à paralléliser. Chaque appel aura un mini-lot. « mini_batch» : l’inférence par lots va appeler la méthode d’exécution et transmettre soit une liste, soit un dataframe Pandas en tant qu’argument de la méthode. Chaque entrée de min_batch sera un filepath (chemin de fichier) si l’entrée est un FileDataset, ou un dataframe Pandas si l’entrée est un TabularDataset. La méthode run() doit retourner un dataframe Pandas ou un tableau. Pour append_row output_action, les éléments retournés sont ajoutés au fichier de sortie commun. Pour summary_only, le contenu des éléments est ignoré. Pour toutes les actions de sortie, chaque élément de sortie retourné indique la réussite de son inférence dans le mini-lot d’entrée. Chaque processus Worker parallèle appelle init une fois, puis effectue une boucle sur la fonction run jusqu’à ce que tous les mini-lots soient traités.

nombre d’échecs d’enregistrement pour TabularDataset et d’échecs de fichiers pour FileDataset qui doivent être ignorés pendant le traitement. Si le nombre d’erreurs dépasse cette valeur, le travail sera interrompu. Le seuil d’erreurs concerne la totalité de l’entrée et non chacun des mini-lots envoyés à la méthode. La plage est [-1, int.max]. -1 indique d’ignorer toutes les défaillances lors du traitement.

Mode d’organisation de la sortie. Les valeurs actuellement prises en charge sont « append_row » et « summary_only ».

1. « append_row » : toutes les valeurs générées par les appels de la méthode run() sont agrégées dans un fichier unique nommé parallel_run_step.txt, qui est créé dans l’emplacement de sortie.
2. « summary_only » : le script utilisateur doit stocker la sortie elle-même. Une ligne de sortie est toujours attendue pour chaque élément d’entrée réussi traité. Le système utilise cette sortie uniquement pour le calcul du seuil d’erreur (en ignorant la valeur réelle de la ligne).

Cible de calcul à utiliser pour l’exécution ParallelRunStep. Ce paramètre peut être spécifié sous la forme d’un objet de cible de calcul ou du nom d’une cible de calcul dans l’espace de travail.

Nombre de nœuds dans la cible de calcul utilisée pour l’exécution de ParallelRunStep.

Nombre de processus Worker par nœud pour exécuter le script d’entrée en parallèle. Pour un ordinateur GPU, la valeur par défaut est 1. Pour un ordinateur processeur, la valeur par défaut est le nombre de cœurs. Un processus Worker appellera run() de manière répétée en transmettant le mini lot qu’il obtient. Le nombre total de processus Worker dans votre travail est process_count_per_node * node_count, qui détermine le nombre maximal de run() à exécuter en parallèle.

Pour une entrée FileDataset, ce champ correspond au nombre de fichiers que le script utilisateur peut traiter dans un appel de la méthode run(). Pour une entrée TabularDataset, ce champ correspond à la taille approximative des données que le script utilisateur peut traiter dans un appel de la méthode run(). Les exemples de valeurs sont 1 024, 1 024 Ko, 10 Mo et 1 Go. (Facultatif, la valeur par défaut est 10 fichiers pour FileDataset et 1 Mo pour TabularDataset.)

Chemins du dossier qui contient le entry_script et les fichiers complémentaires utilisés pour une exécution sur la cible de calcul.

Description du service Batch utilisé à des fins d’affichage.

Chaîne du nom du niveau de journalisation, définie dans « Logging ». Les valeurs possibles sont « WARNING », « INFO »et « DEBUG ». (Facultatif : la valeur par défaut est « INFO ».)

Délai d’expiration en secondes de chaque appel à la méthode run(). (La valeur par défaut facultative est 60.)

Nombre maximal de nouvelles tentatives pour un mini-lot ayant échoué ou dont le délai a expiré. La plage est [1, int.max]. La valeur par défaut est 3. Un mini-lot dont le nombre de dépilements est supérieur à cette valeur n’est pas retraité mais directement supprimé.

Nom du fichier de sortie si output_action a la valeur « append_row ». (Facultatif, la valeur par défaut est « parallel_run_step.txt »)

Nombre de mini-lots ayant échoué qui doivent être ignorés pendant le traitement. Si le nombre d’échec dépasse cette valeur, le travail est abandonné. Ce seuil concerne l’ensemble de l’entrée plutôt que le mini-lot envoyé à la méthode run(). La plage est [-1, int.max]. -1 indique d’ignorer toutes les défaillances lors du traitement. Un mini-lot peut échouer la première fois qu’il est traité, puis réussir à la deuxième tentative. Une vérification entre la première et la deuxième fois le compte la tentative comme un échec. Une vérification après la deuxième tentative ne la compte pas comme un échec. Les arguments –error_threshold, –allowed_failed_count and –allowed_failed_percent peuvent fonctionner ensemble. Si plusieurs éléments sont spécifiés, le travail est abandonné si l’une des valeurs est dépassée.

Pourcentage de mini-lots ayant échoué qui doivent être ignorés pendant le traitement. Si le pourcentage d’échec dépasse cette valeur, le travail est abandonné. Ce seuil concerne l’ensemble de l’entrée plutôt que le mini-lot envoyé à la méthode run(). La plage est [0, 100]. 100 ou 100.0 indique d’ignorer toutes les défaillances lors du traitement. La vérification démarre une fois tous les mini-lots planifiés. Les arguments –error_threshold, –allowed_failed_count and –allowed_failed_percent peuvent fonctionner ensemble. Si plusieurs éléments sont spécifiés, le travail est abandonné si l’une des valeurs est dépassée.

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 à la fois partition_keys et mini_batch_size sont spécifiés, une erreur est générée. Il doit s’agir d’une liste d’éléments str, chacun d’entre eux étant une clé utilisée pour partitionner le jeu de données d’entrée. Toutefois, si elle est promue en PipelineParameter, les valeurs par défaut doivent être l’élément str de vidage JSON de la liste, car le type de liste n’est pas pris en charge dans PipelineParameter actuellement. Les entrées doivent être des jeux de données partitionnés et partition_keys doit être un sous-ensemble des clés de chaque jeu de données d’entrée pour que cela fonctionne.

Dictionnaire des noms et valeurs des variables d’environnement. Ces variables d’environnement sont définies sur le processus où le script utilisateur est en cours d’exécution.