Mise à disposition d'informations d'entraînement par Amazon SageMaker

Cette section explique comment SageMaker met à la disposition de votre conteneur Docker des informations d'entraînement telles que des données d'entraînement, des hyperparamètres et d'autres informations de configuration.

Lorsque vous envoyez une demande CreateTrainingJob à SageMaker pour démarrer l'entraînement du modèle, vous spécifiez le chemin d'Amazon Elastic Container Registry (Amazon ECR) de l'image Docker qui contient l'algorithme d'entraînement. Vous spécifiez également l'emplacement Amazon Simple Storage Service (Amazon S3) dans lequel les données d'entraînement sont stockées, ainsi que les paramètres spécifiques à l'algorithme. SageMaker met ces informations à disposition du conteneur Docker afin que votre algorithme d'entraînement puisse les utiliser. Cette section explique comment ces informations sont rendues disponibles pour votre conteneur Docker. Pour plus d'informations sur la création d'une tâche d'entraînement, consultez CreateTrainingJob. Pour de plus amples informations sur la façon dont les conteneurs SageMaker organisent les informations, veuillez consulter Utilisation des boîtes à outils d'entraînement et d'inférence SageMaker .

Hyperparamètres

SageMaker rend les hyperparamètres d'une requête CreateTrainingJob disponibles dans le conteneur Docker dans le fichier /opt/ml/input/config/hyperparameters.json.

Variables d'environnement

Les variables d'environnement suivantes sont définies dans le conteneur :

• TRAINING_JOB_NAME : spécifiée dans le paramètre TrainingJobName de la requête CreateTrainingJob.

• TRAINING_JOB_ARN : Amazon Resource Name (ARN) de la tâche d'entraînement renvoyée en tant que TrainingJobArn dans la réponse CreateTrainingJob.

• Toutes les variables d'environnement spécifiées dans le paramètre Environnement de la requête CreateTrainingJob.

Configuration des données d'entrée

Vous spécifiez des informations sur le canal de données dans le paramètre InputDataConfig d'une requête CreateTrainingJob. SageMaker rend ces informations disponibles dans le fichier /opt/ml/input/config/inputdataconfig.json du conteneur Docker.

Par exemple, supposons que vous spécifiiez trois canaux de données (train, evaluation et validation) dans votre requête. SageMaker fournit les informations JSON suivantes :

{
  "train" : {"ContentType":  "trainingContentType",
             "TrainingInputMode": "File",
             "S3DistributionType": "FullyReplicated",
             "RecordWrapperType": "None"},
  "evaluation" : {"ContentType":  "evalContentType",
                  "TrainingInputMode": "File",
                  "S3DistributionType": "FullyReplicated",
                  "RecordWrapperType": "None"},
  "validation" : {"TrainingInputMode": "File",
                  "S3DistributionType": "FullyReplicated",
                  "RecordWrapperType": "None"}
} 

Note

SageMaker fournit uniquement des informations pertinentes sur chaque canal de données (par exemple, le nom du canal et le type de contenu) au conteneur, comme indiqué. S3DistributionType est défini à FullyReplicated si vous spécifiez EFS ou FSxLustre comme sources de données d'entrée.

Données d'entraînement

Le paramètre TrainingInputMode dans AlgorithmSpecification de la demande CreateTrainingJob spécifie comment le jeu de données d'entraînement est mis à disposition. Les modes d'entrée suivants sont disponibles :

• File Mode

  • Paramètre TrainingInputMode écrit dans inputdataconfig.json : « File »

  • Répertoire du canal de données dans le conteneur Docker : /opt/ml/input/data/channel_name

  • Sources de données prises en charge : Amazon Simple Storage Service (Amazon S3), Amazon Elastic File System (Amazon EFS) et Amazon FSx for Lustre

  Un répertoire est créé pour chaque canal. Par exemple, si vous disposez de trois canaux nommés training, validation et testing, SageMaker crée trois répertoires dans le conteneur Docker :

  • /opt/ml/input/data/training

  • /opt/ml/input/data/validation

  • /opt/ml/input/data/testing

  Note

  Les canaux qui utilisent des sources de données de système de fichiers telles qu'Amazon EFS et Amazon FSx doivent utiliser le mode File. Si un système de fichiers est spécifié, le chemin d'accès au répertoire fourni dans le canal est monté à /opt/ml/input/data/channel_name.

• FastFile Mode

  • Paramètre TrainingInputMode écrit dans inputdataconfig.json : « FastFile »

  • Répertoire du canal de données dans le conteneur Docker : /opt/ml/input/data/channel_name

  • Sources de données prises en charge : Amazon S3

  Le répertoire du canal est monté en lecture seule.

  Les algorithmes qui prennent en charge le mode File peuvent fonctionner de manière transparente avec le mode FastFile sans modification de code.

  Note

  Les canaux qui utilisent le mode FastFile doivent utiliser un S3DataType « S3Prefix ».

  Le mode FastFile présente une vue de dossier qui utilise la barre oblique (/) comme délimiteur pour regrouper les objets Amazon S3 dans des dossiers. Les préfixes S3Uri ne doivent pas correspondre à un nom de dossier partiel. Par exemple, si un jeu de données Amazon S3 contient s3://my-bucket/train-01/data.csv, ni s3://my-bucket/train ni s3://my-bucket/train-01 ne sont autorisés comme préfixes S3Uri.

  Une barre oblique finale est recommandée pour définir un canal correspondant à un dossier. Par exemple, le canal s3://my-bucket/train-01/ du dossier train-01. Sans la barre oblique finale, le canal serait ambigu s'il existait un autre dossier s3://my-bucket/train-011/ ou fichier s3://my-bucket/train-01.txt/.

• Pipe Mode

  • Paramètre TrainingInputMode écrit dans inputdataconfig.json : « Pipe »

  • Répertoire du canal de données dans le conteneur Docker : /opt/ml/input/data/channel_name_epoch_number

  • Sources de données prises en charge : Amazon S3

  Vous devez lire à partir d'un tuyau séparé pour chaque canal. Par exemple, si vous disposez de trois canaux nommés training, validation et testing, vous devez lire à partir des canaux suivants :

  • /opt/ml/input/data/training_0, /opt/ml/input/data/training_1, ...

  • /opt/ml/input/data/validation_0, /opt/ml/input/data/validation_1, ...

  • /opt/ml/input/data/testing_0, /opt/ml/input/data/testing_1, ...

  Lisez les tubes de manière séquentielle. Par exemple, si vous avez un canal appelé training, lisez les tubes selon cette séquence :

  1. Ouvrez /opt/ml/input/data/training_0 en mode lecture et lisez-le jusqu'à la fin de fichier (EOF) ou, si vous avez fini d'utiliser la première époque, fermez le fichier tube de manière anticipée.

  2. Après avoir fermé le premier fichier de canal, recherchez /opt/ml/input/data/training_1 et lisez-le jusqu'à ce que vous ayez terminé la deuxième époque, etc.

  Si le fichier correspondant à une époque donnée n'existe pas encore, votre code devra peut-être réessayer jusqu'à ce que le tube soit créé. Il n'y a aucune restriction de séquençage parmi les types de canal. Par exemple, vous pouvez lire plusieurs époques pour le canal training et commencer à lire le canal validation lorsque vous êtes prêt. Vous pouvez également les lire simultanément si votre algorithme le nécessite.

  Pour bénéficier d'un exemple de bloc-notes Jupyter qui montre comment utiliser le mode Pipe lorsque vous apportez votre propre conteneur, consultezApporter votre propre algorithme en mode Pipe sur Amazon SageMaker.

Configuration d'entraînement distribué

Si vous effectuez un entraînement distribué avec plusieurs conteneurs, SageMaker rend les informations sur tous les conteneurs disponibles dans le fichier /opt/ml/input/config/resourceconfig.json.

Pour activer la communication entre les conteneurs, ce fichier JSON contient des informations pour tous les conteneurs. SageMaker rend ce fichier disponible pour les algorithmes en mode File et Pipe. Le fichier fournit les informations suivantes :

• current_host : nom du conteneur actuel sur le réseau de conteneurs. Par exemple, algo-1. Les valeurs d'hôte peuvent changer à tout moment. N'écrivez pas de code contenant des valeurs spécifiques pour cette variable.

• hosts : liste des noms de tous les conteneurs sur le réseau de conteneurs, triée de manière lexicographique. Par exemple, ["algo-1", "algo-2", "algo-3"] pour un cluster à trois nœuds. Les conteneurs peuvent utiliser ces noms pour traiter d'autres conteneurs sur le réseau de conteneurs. Les valeurs d'hôte peuvent changer à tout moment. N'écrivez pas de code contenant des valeurs spécifiques pour ces variables.

• network_interface_name : nom de l'interface réseau qui est exposée à votre conteneur. Par exemple, les conteneurs utilisant l'interface Message Passing Interface (MPI) peuvent utiliser ces informations pour définir le nom de l'interface réseau.

• N'utilisez pas les informations de /etc/hostname ou /etc/hosts car elles peuvent être inexactes.

• Les informations sur les noms d'hôte peuvent ne pas être immédiatement disponibles pour le conteneur de l'algorithme. Nous vous recommandons d'ajouter une stratégie de nouvelle tentative aux opérations de résolution de nom d'hôte quand les nœuds deviennent disponibles dans le cluster.

Voici un exemple de fichier sur le nœud 1 d'un cluster à trois nœuds :

{
    "current_host": "algo-1",
    "hosts": ["algo-1","algo-2","algo-3"],
    "network_interface_name":"eth1"
}