For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/public-cloud/ai-machine-learning/ai-cli-run-job.md.

CLI - Lancer un job AI Training

Voir en Markdown

Découvrez comment lancer un job AI Training avec la CLI

Objectif

Ce guide couvre la soumission de jobs via la CLI ovhai. Pour illustrer la soumission, nous allons construire de façon itérative une commande permettant de lancer une image notebook ovhcom/ai-training-transformers:3.1.0 avec le framework Huggingface préinstallé. Cette image Docker est disponible gratuitement.

Prérequis

En pratique

job run

Si vous avez besoin d'aide lors de la soumission d'un nouveau job, lancez ovhai job run --help :

Usage:
    ovhai job run [OPTIONS] [IMAGE] [COMMAND]...

Arguments:
  [IMAGE]
          Docker image

  [COMMAND]...
          List of command arguments to pass to job. If some job arguments start with '-' or '--' don't forget to add '--' as first argument to avoid interpreting following ones as ovhai parameter. Example: `ovhai job run ubuntu -- bash -c 'echo $(date)'`

Options:
  -e, --env <name=value>
          Environment variable to be set inside job

      --token `<TOKEN>`
          Authentication using Token rather than OAuth

  -p, --default-http-port `<DEFAULT_HTTP_PORT>`
          Port use as the default one to access HTTP service inside job

  -t, --timeout `<TIMEOUT>`
          Maximum time to spend before killing the job (30s, 1h, ...)

      --unsecure-http
          HTTP services inside job will not require authentication to be accessed from the outside

  -g, --gpu `<GPU>`
          Number of GPUs

  -f, --flavor `<FLAVOR>`
          the flavor to use, `ovhai capabilities flavor list` to get the whole list

  -c, --cpu `<CPU>`
          Number of CPUs (ignored if GPUs is specified)

  -v, --volume <container@alias/prefix:mount_path(:permission)(:cache) or url:mount_path(:permission)(:cache)>
          Volumes mounted on the image. `alias` is the data store alias of your data. You can get a list of all available data stores for the object storage by typing `ovhai data store list`. `/prefix` is optional [default: ""]. `:permission` is optional [default: ro] [possible values: ro, rw, rwd]. `:cache` is optional [default: "no-cache"] [possible values: cache, no-cache].
          
          A URL can be given instead of container@alias/prefix for containers that are publicly available.

  -n, --name `<NAME>`
          Optional name, only informative

  -l, --label <name=value>
          Optional labels, only informative

  -o, --output `<OUTPUT>`
          Command output format
          
          [possible values: json, yaml]

  -s, --ssh-public-keys `<ssh-public-key-file>`
          Enable the job ssh feature, specify each ssh public key files or give the public key directly

      --no-color
          Remove colors from output

  -h, --help
          Print help (see a summary with '-h')

Dimensionner votre run

Vous devez d'abord ajuster les ressources nécessaires à votre nouveau run en fonction de la charge de travail attendue.

Par exemple, si vous êtes à l'étape d'exploration des données ou de conception de votre réseau de neurones à entraîner, vous pouvez commencer avec quelques vCPU. Une fois votre expérimentation prête, passez à l'utilisation de GPU pour l'entraînement.

Les flags --cpu et --gpu sont exclusifs : si des ressources GPU sont spécifiées, le flag CPU est ignoré et le ratio standard GPU/CPU est appliqué. Vous trouverez plus d'informations sur ces ratios dans les capacités.

Si vous provisionnez des GPU pour votre run, vous pouvez également sélectionner le modèle de GPU que vous souhaitez utiliser avec le flag --gpu-model. Si ce flag n'est pas spécifié, le modèle de GPU par défaut du cluster sur lequel vous soumettez est utilisé. Vous pouvez connaître le GPU par défaut de votre cluster avec la commande ovhai capability.

La quantité maximale de vCPU ou de GPU disponible dépend du modèle de GPU et du cluster que vous utilisez. Vous pouvez connaître les limitations de ressources de votre cluster avec ovhai capability.

Pour cette expérimentation, nous allons déployer un notebook avec 1 GPU du modèle par défaut

ovhai job run --gpu 1 ovhcom/ai-training-transformers:3.1.0
Info
  • Si aucun flag de ressource n'est spécifié, le job s'exécutera avec une unité du modèle de GPU par défaut.
  • Si les flags CPU et GPU sont tous deux fournis, seul celui du GPU est pris en compte

Attacher des volumes

Cette étape suppose que vous disposez de données dans votre OVHcloud Object Storage que vous souhaitez utiliser pendant votre expérimentation, ou que vous devez sauvegarder les résultats de votre job dans l'Object Storage. Pour en savoir plus sur les données, les volumes et les permissions, consultez la page données.

Vous pouvez attacher autant de volumes que vous le souhaitez à votre job avec diverses options. Passons en revue ces options et présentons quelques bonnes pratiques concernant les montages de volumes.

Le flag --volume permet d'attacher un conteneur en tant que volume au job. La description du volume définit l'option pour le volume et le processus de synchronisation <container@region/prefix:mount_path:permission:cache> :

  • container le conteneur dans OVHcloud Object Storage à synchroniser
  • region la région Object Storage sur laquelle se trouve le conteneur
  • prefix les objets du conteneur sont filtrés sur la base de ce préfixe, seuls les objets correspondants sont synchronisés
  • mount_path l'emplacement dans le job où les données synchronisées sont montées
  • permission les droits d'accès sur les données montées. Les droits disponibles sont lecture seule (ro), lecture-écriture (rw) ou lecture-écriture-suppression (rwd). Les données montées avec la permission ro ne sont pas resynchronisées à la fin du job, ce qui évite un délai de synchronisation inutile sur des données statiques.
  • cache indique si les données synchronisées doivent être ajoutées au cache du projet. Les options disponibles sont cache ou no-cache. Les données présentes dans le cache peuvent être utilisées par d'autres jobs sans synchronisation supplémentaire ; pour bénéficier du cache, les nouveaux jobs doivent également monter les données avec l'option cache.

Supposons que vous ayez une équipe de data scientists travaillant sur le même jeu de données d'entrée mais exécutant chacun leur propre expérimentation. Dans ce cas, une bonne pratique consiste à monter le jeu de données d'entrée avec la permission ro et le cache activé pour chaque expérimentation : les données d'entrée sont synchronisées une seule fois et ne sont jamais resynchronisées. De plus, chaque expérimentation produira des résultats spécifiques qui devront être stockés dans un conteneur dédié. Pour chaque job, nous monterions alors un conteneur de sortie avec la permission rw et sans cache. Si un conteneur n'existe pas encore dans l'object storage, il est créé lors de la synchronisation des données.

En supposant que nos données se trouvent dans l'Object Storage de Gravelines, dans un conteneur nommé dataset, la commande serait désormais :

ovhai job run --gpu 1 \
-v dataset@GRA:/workspace/dataset:ro:cache \
-v output@GRA:/workspace/output:rw \
ovhcom/ai-training-transformers:3.1.0
Info
  • Les données présentes dans le cache ne sont pas persistées indéfiniment. Après une période d'inactivité, les données sont vidées du cache. L'inactivité est définie par l'absence de job en cours d'exécution utilisant les données du cache.

Définir votre processus

Une fois les ressources et les volumes configurés, vous devez maintenant définir les spécificités du processus s'exécutant au sein de votre job. Vous avez d'abord besoin d'une image Docker que vous avez construite vous-même ou trouvée librement disponible sur un dépôt public tel que DockerHub. Dans notre exemple, nous utiliserons l'image notebook ovhcom/ai-training-transformers:3.1.0.

Vous pouvez ajuster le comportement de votre image Docker sans avoir à la reconstruire à chaque fois (par exemple pour mettre à jour le nombre d'epochs d'un entraînement) en utilisant le flag --env. Cela vous permet de définir simplement des variables d'environnement directement dans votre job, par exemple :

--env NB_EPOCHS=20

Dans notre exemple, nous n'avons besoin d'aucune variable d'environnement.

Il est également possible de surcharger le CMD ou l'Entrypoint par défaut de l'image Docker en ajoutant simplement la nouvelle commande à la fin de la requête job run. Pour vous assurer que les flags de votre commande ne sont pas interprétés comme des paramètres ovhai, vous pouvez préfixer votre commande par --. Pour simplement afficher Hello World, la commande serait :

ovhai job run ubuntu -- echo 'Hello World'

Lorsqu'un job est en cours d'exécution, une job_url lui est associée, vous permettant d'accéder à tout service exposé dans votre job. Par défaut, le port exposé pour cette URL est le 8080 ; dans notre cas, le Jupyter Notebook est directement exposé sur le 8080 et nous n'avons pas besoin de le surcharger. Cependant, si vous exécutez une expérimentation et la surveillez avec Tensorboard, le port par défaut doit être 6006, vous pouvez surcharger le port avec :

--default-http-port 6006

Options supplémentaires

Quelques autres options sont disponibles pour vos jobs.

  • --timeout délai après lequel le job s'arrêtera même si le processus du job ne s'est pas terminé, ce qui vous aide à contrôler votre consommation
  • --label labels libres pour vous aider à organiser vos jobs ; les labels sont également utilisés pour restreindre la portée des app_token, en savoir plus sur les app_token et comment les créer ici
  • --read-user vous pouvez ajouter un read-user à un job ; un read-user n'aura accès qu'au service exposé derrière la job_url. Le read-user doit correspondre au nom d'utilisateur d'un utilisateur de la plateforme AI disposant d'un rôle AI Training read.
  • --ssh-public-keys vous permet d'accéder à votre job via SSH ; particulièrement utile pour configurer un VSCode Remote
  • --from lance un job basé sur la spécification d'un job précédent. Toutes les options écraseront les valeurs du job de base. Le flag --image permet de surcharger l'image du job de base.

Lancer un job

Enfin, pour soumettre un job notebook avec 1 GPU, un conteneur de dataset et un conteneur de sortie, nous exécutons

ovhai job run --gpu 1 
-v dataset@GRA:/workspace/dataset:ro:cache 
-v output@GRA:/workspace/output:rw 
ovhcom/ai-training-transformers:3.1.0

Vous pouvez ensuite suivre la progression de tous vos jobs à l'aide des commandes suivantes :

ovhai job ls

Si vous souhaitez récupérer le job spécifique que vous venez de sélectionner, récupérez son ID, puis :

ovhai job get <job-id>

Pour plus d'informations sur le job et son cycle de vie, reportez-vous à la page des jobs.

Aller plus loin

Pour en savoir plus sur la CLI et les commandes disponibles pour interagir avec votre job, consultez la présentation de ovhai

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Votre avis nous intéresse !

N’hésitez pas à nous faire part de vos questions, retours et suggestions pour améliorer le service :

Cette page vous a-t-elle aidé ?