Entraîner sur un serveur GPU, un cluster SLURM ou une machine derrière un NAT

Nouveauté de la v2.14.0

Ce tutoriel déplace l'entraînement de modèles de Potato du serveur d'annotation vers une machine dotée d'un GPU. Il s'adresse à un administrateur d'étude dont le serveur d'annotation est une petite machine virtuelle dans le cloud ou un portable, et dont les GPU se trouvent sur un serveur de laboratoire, un cluster universitaire ou un poste de travail auquel le serveur ne peut pas se connecter. Pour chacun des trois backends distants, la page couvre les cas où le choisir, ce qui doit être installé sur la machine distante, la configuration, la commande de vérification, ce qui se passe pendant une exécution, la façon d'annuler une exécution et les échecs les plus probables. Le tutoriel suppose un projet qui s'entraîne déjà sur le serveur d'annotation, comme le projet d'avis de Entraîner votre premier modèle.

Quatre endroits où une exécution peut tourner

Un backend est l'endroit où s'exécute une exécution d'entraînement. Potato dispose toujours du backend local, un sous-processus sur le serveur d'annotation. Vous nommez les autres backends sous model_training.backends.

Choisissez ssh quand le serveur d'annotation peut se connecter à la machine GPU avec une clé ssh. Choisissez slurm quand les GPU se trouvent derrière l'ordonnanceur SLURM et que la machine sur laquelle vous pouvez vous connecter est un nœud de connexion. Choisissez agent quand aucune connexion ne peut être ouverte du serveur vers la machine GPU, car l'agent ouvre lui-même toutes les connexions. Un poste derrière une box domestique ou un pare-feu de campus est le cas habituel d'un agent. Les prédictions et le résultat de l'exécution parviennent au serveur depuis tous les backends, donc l'écriture en retour et le score sur items réservés fonctionnent de la même façon, où que le module d'entraînement ait tourné. Tous les modules d'entraînement sauf decision-calibrate tournent sur n'importe quel backend.

La configuration du projet

La configuration ci-dessous est le projet d'avis du premier tutoriel, avec les trois backends distants ajoutés. Un vrai projet n'a besoin que des backends qu'il utilise, et chaque backend a sa propre section plus bas. max_wall_seconds: 3600 arrête toute exécution qui n'a pas fini en une heure. Sur un backend ssh ou agent, le serveur vérifie la limite chaque seconde, donc une exécution qui se bloque sur une machine distante ne retient pas la file d'attente des exécutions au-delà de la limite.

annotation_task_name: "Review Sentiment"
task_dir: "."
data_files:
  - "data/reviews.json"
item_properties:
  id_key: "id"
  text_key: "text"
output_annotation_dir: "annotation_output"
admin_api_key: "change-me"
 
annotation_schemes:
  - annotation_type: "radio"
    name: "sentiment"
    description: "Is this review positive or negative?"
    labels: ["positive", "negative"]
 
model_training:
  enabled: true
  backend: gpu-server        # the default for runs; leave out to keep runs local
  max_wall_seconds: 3600
  writeback:
    schemas: ["sentiment"]
    include_unlabeled: true
    min_confidence: 0.6
  backends:
    gpu-server:
      type: ssh
      host: gpu.example.org
      python: /opt/conda/bin/python3
      gpus: auto
      min_free_gpu_mb: 4000
    cluster:
      type: slurm
      host: login.cluster.example.org
      python: /opt/conda/bin/python3
      job_python: /shared/envs/train/bin/python
      remote_dir: /shared/projects/me/potato-training
      gres: gpu:1
      time: "04:00:00"
      prelude: ["module load cuda/12.4"]
    lab-workstation:
      type: agent
      queue_timeout_s: 3600

Validez la configuration avant de démarrer le serveur.

potato validate config.yaml --strict

Le validateur signale une clé que le type de backend n'accepte pas, un backend ssh ou slurm sans host, un remote_dir SLURM sous /tmp et un model_training.backend qui ne nomme aucun backend. Le serveur ne démarre pas non plus sur ces erreurs, donc un pyhton mal orthographié arrête le serveur au démarrage au lieu d'envoyer les exécutions vers le python3 par défaut.

Le menu Runs on et l'API

La page Training à l'adresse /admin/training a un menu Runs on qui liste chaque backend avec son type et son hôte, par exemple gpu-server (ssh to gpu.example.org). model_training.backend fixe l'entrée que le menu sélectionne en premier, et le tableau Runs enregistre l'endroit où chaque exécution a tourné dans sa colonne Ran on. Une exécution lancée par l'API nomme son backend dans le champ backend du corps de la requête.

curl -X POST -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  http://localhost:8000/admin/training/api/runs \
  -d '{"trainer": "hf-text-classification", "schemas": ["sentiment"], "backend": "cluster"}'

Un nom de backend absent de la configuration est refusé avec 409. Le réentraînement automatique utilise model_training.backend, sauf si auto_retrain.backend nomme un autre backend, et Le modèle dans la boucle traite auto_retrain en détail. Une seule exécution tourne à la fois, quel que soit le backend, et une exécution lancée pendant qu'une autre est en cours attend dans la file d'attente.

Entraîner sur cette machine

Vérifiez quel périphérique reçoit une exécution locale avant de déplacer les exécutions ailleurs. Avec la valeur par défaut device: auto, une exécution locale prend d'abord CUDA, puis Metal d'Apple (mps), puis le CPU, et device: cuda:1 désigne un seul GPU. La commande de vérification affiche le périphérique qu'utiliserait une exécution locale.

potato training check local config.yaml

Sur un Mac à puce Apple, la commande affiche local: this machine, Apple Metal (mps). Un périphérique demandé mais absent est remplacé par le CPU ou un autre accélérateur, avec un avertissement dans le journal de l'exécution. Quand la réponse est CPU et que le module d'entraînement affine un transformeur, déplacez l'exécution vers un backend distant décrit plus bas. La configuration liste device, num_threads et max_ram_mb pour les exécutions locales.

Un serveur GPU en ssh

Un backend ssh fait tourner le module d'entraînement sur une machine que le serveur d'annotation atteint en ssh, typiquement un serveur GPU de laboratoire. Potato démarre lui-même tout le côté distant, donc rien n'est installé ni démarré à la main là-bas en dehors de Python et des paquets du module d'entraînement. L'hôte GPU n'a pas besoin de Potato, car Potato copie son propre code source Python sur l'hôte à la première exécution et réutilise cette copie tant que le code source ne change pas.

Prérequis d'un backend ssh

Le compte sous lequel tourne le serveur d'annotation a besoin d'une clé ssh qui se connecte à l'hôte GPU sans invite. Potato exécute ssh avec BatchMode=yes, donc une invite de mot de passe fait échouer l'exécution aussitôt au lieu de la bloquer. L'exécution de ssh gpu.example.org true sous ce compte doit réussir, et une clé protégée par une phrase secrète convient quand ssh-agent détient la clé. La valeur de host est tout nom que ssh accepte, et un alias de ~/.ssh/config convient. Les clés user, port et identity_file sont transmises à ssh sous la forme -l, -p et -i.

L'hôte GPU a besoin de Python 3.8 ou plus récent et des paquets du module d'entraînement que vous exécutez. Pour hf-text-classification, ces paquets sont torch, transformers et peft, le contenu de l'extra potato-annotation[train-text]. La page Modules d'entraînement nomme l'installation de chaque module. Quand l'interpréteur de l'hôte manque d'un paquet, faites pointer python vers un interpréteur qui l'a, ou listez le paquet sous packages. Avec packages défini, Potato crée un environnement virtuel sous remote_dir avec --system-site-packages et y installe une fois les paquets listés. La version de torch compilée pour le CUDA de l'hôte reste visible dans l'environnement.

model_training:
  enabled: true
  backends:
    gpu-server:
      type: ssh
      host: gpu.example.org
      python: /opt/conda/bin/python3
      packages: ["transformers>=4.46.0", "peft>=0.13.0"]
      gpus: auto
      min_free_gpu_mb: 4000
      num_threads: 8

Avec gpus: auto, chaque exécution prend le GPU qui a le plus de mémoire libre et refuse de démarrer quand aucun GPU n'a min_free_gpu_mb de libre (2000 par défaut). Potato compare la mémoire libre plutôt que l'utilisation, car une carte peu utilisée sur un serveur partagé peut quand même avoir peu de mémoire libre. Fixez min_free_gpu_mb près de la mémoire dont votre module d'entraînement a besoin. gpus: "1" épingle le GPU 1, "0,1" en épingle deux, et gpus: none entraîne sur le CPU. Un hôte sans aucun GPU entraîne aussi sur son CPU avec auto. num_threads fixe OMP_NUM_THREADS, MKL_NUM_THREADS et OPENBLAS_NUM_THREADS pour l'exécution. Certains serveurs partagés définissent OMP_NUM_THREADS=1 dans les shells de connexion, et num_threads remplace la valeur du shell de connexion.

La commande de vérification d'un backend ssh

Lancez la vérification depuis le serveur d'annotation, sous le compte qui fait tourner le serveur.

potato training check gpu-server config.yaml

La commande se connecte et rapporte la version de Python distante, chaque GPU avec sa mémoire libre et son utilisation, le GPU qu'obtiendrait une exécution et les paquets d'entraînement qui manquent à l'interpréteur distant. Un GPU pour lequel le torch installé n'a pas de noyaux est marqué (torch there has no kernels for it), et gpus: auto ignore un tel GPU. --json affiche le même rapport en JSON. La commande se termine avec 0 quand une exécution pourrait démarrer et avec 1 sinon. Le bouton Check à côté du menu Runs on lance la même vérification depuis la page Training.

Les étapes d'une exécution ssh

Pour chaque exécution, Potato effectue ces étapes.

1. Il se connecte avec ssh et ouvre un transfert inverse depuis une socket unix du /tmp distant vers le serveur d'annotation.
2. Il vérifie l'interpréteur, lit nvidia-smi et choisit le GPU.
3. Il copie le code source de Potato dans remote_dir/code/<hash> quand l'hôte n'a pas cette version, et construit l'environnement virtuel quand packages est défini et que l'environnement manque. remote_dir vaut ~/.cache/potato-training par défaut.
4. Il démarre python -m potato.training.agent pour l'exécution. Le jeton de l'exécution parvient à l'agent sur l'entrée standard et n'apparaît jamais sur une ligne de commande, car les lignes de commande sont visibles de tous les comptes d'un serveur partagé.
5. L'agent télécharge le lot d'items, d'étiquettes et de médias de l'exécution. L'agent exécute le même processus d'entraînement que le backend local et renvoie la progression, les prédictions et le résultat par la socket.
6. Quand l'exécution réussit, Potato recopie le répertoire des artefacts dans artifacts/ de l'exécution, supprime le répertoire de tâche distant et ferme la connexion.

La ligne d'étape de la page Training suit ces phases, par exemple copying Potato's code to gpu.example.org et waiting for the agent on gpu.example.org. Le journal de l'exécution nomme le Python de l'hôte et le GPU obtenu.

Un affinage complet recopie le modèle entier, et sur une liaison lente un modèle de 330 Mo prend plusieurs minutes. La ligne d'étape montre quelle part du modèle est arrivée. Les fichiers plus gros que max_artifact_mb (2048 par défaut) restent sur l'hôte GPU et sont nommés dans le journal de l'exécution. fetch_artifacts: false laisse tous les fichiers du modèle sur l'hôte GPU, et keep_remote: true garde le répertoire de tâche distant pour inspection. La publication sur le Hugging Face Hub depuis la page de l'exécution a besoin des fichiers du modèle sur le serveur d'annotation, donc un modèle laissé sur l'hôte GPU ne peut pas être publié depuis la page de l'exécution.

La socket unix est créée avec le mode 0600, donc seul le compte sous lequel Potato s'est connecté peut s'y connecter. Les requêtes qui passent par la socket arrivent au serveur d'annotation comme des requêtes de bouclage. Un serveur démarré avec debug: true accorde l'accès d'administration aux requêtes de bouclage. Toute personne qui peut utiliser ce compte sur l'hôte GPU a alors l'accès d'administration à un serveur en mode debug pendant une exécution. Laissez debug désactivé sur un serveur qui entraîne en ssh.

Annulation et délai du signal de vie

Cancel run dans la page Training parvient à l'agent par la socket, dans la réponse au prochain rapport de progression de l'agent. L'agent envoie SIGTERM au processus d'entraînement, et SIGKILL si celui-ci tourne encore après model_training.grace_seconds (20 par défaut), que le serveur envoie avec la tâche. Une tâche venue d'un serveur Potato plus ancien ne porte pas grace_seconds, et l'agent attend alors 20 secondes. Côté serveur, l'exécution se termine comme annulée une fois grace_seconds écoulées, et le serveur ferme la session ssh de l'agent. Une exécution dont l'agent n'envoie rien pendant heartbeat_timeout_s (120 par défaut) échoue, et agent.log dans le répertoire de l'exécution contient la dernière sortie de l'agent.

Un cluster SLURM

Un backend slurm convient à un cluster dont les GPU se trouvent derrière l'ordonnanceur SLURM. Sur un tel cluster, la machine que Potato atteint en ssh est un nœud de connexion sans GPU, et les nœuds de calcul ne peuvent pas atteindre Potato du tout. Potato démarre donc l'agent sur le nœud de connexion, comme pour un backend ssh, et l'agent soumet seulement le processus d'entraînement à un nœud de calcul avec sbatch. La progression revient par un fichier sur un stockage que le nœud de connexion et les nœuds de calcul partagent.

Prérequis d'un backend SLURM

Le nœud de connexion a besoin d'une clé ssh sans invite et de Python 3.8 ou plus récent pour l'agent, comme l'hôte d'un backend ssh. Le nœud de connexion a aussi besoin de sbatch, squeue et scancel dans le PATH. L'agent appelle aussi scontrol là où le cluster a cette commande. Potato n'appelle jamais srun ni sacct, donc un cluster dont srun est désactivé et sans base de comptabilité fonctionne. remote_dir est obligatoire et doit se trouver sur un stockage que les nœuds de calcul partagent, car la tâche y lit le lot et y écrit le modèle. Le validateur signale une erreur pour un remote_dir sous /tmp ou /var/tmp, car ces répertoires sont locaux à chaque nœud.

Les nœuds de calcul ont besoin d'un interpréteur avec les paquets du module d'entraînement, nommé par job_python. packages n'est pas pris en charge sur un backend SLURM, car un environnement virtuel créé sur le nœud de connexion peut ne pas fonctionner sur les nœuds de calcul. Faites pointer job_python vers un environnement que les nœuds de calcul possèdent, et mettez les chargements de modules ou l'activation d'un environnement dans prelude.

model_training:
  enabled: true
  backends:
    cluster:
      type: slurm
      host: login.cluster.example.org
      python: /opt/conda/bin/python3                    # on the login node, for the agent
      job_python: /shared/envs/train/bin/python         # on the compute nodes, for the worker
      remote_dir: /shared/projects/me/potato-training   # storage the compute nodes share
      partition: gpu
      gres: gpu:1
      time: "04:00:00"
      prelude: ["module load cuda/12.4"]

Toutes les clés ssh s'appliquent à un backend SLURM, sauf gpus et packages. Les GPU viennent de gres, et l'ordonnanceur définit CUDA_VISIBLE_DEVICES pour les GPU qu'il accorde. Une tâche sans gres n'obtient aucun GPU. Les paramètres SLURM correspondent à des options de sbatch.

Un time supérieur à 6 heures fait signaler à potato validate et au démarrage du serveur model_training.backends.cluster.time is 12:00:00. A job that holds a GPU for more than 6 hours is long on a shared cluster; check its policy, et potato validate --strict échoue sur cet avertissement. Une fois que la politique du cluster autorise la tâche plus longue, reconnaissez l'avertissement pour ce seul backend dans un bloc validation de premier niveau, que seul potato validate lit.

validation:
  acknowledge:
    - "model_training.backends.cluster.time is"

Chaque entrée est comparée au texte de l'avertissement comme sous-chaîne sensible à la casse d'au moins 12 caractères, et un avertissement reconnu passe dans la liste des avertissements reconnus et ne fait plus échouer --strict. Une entrée qui nomme le backend reconnaît l'avertissement pour ce backend seulement. Une entrée trop courte ou qui ne correspond à aucun avertissement devient un avertissement à son tour.

La commande de vérification d'un backend SLURM

potato training check cluster config.yaml

La vérification se connecte au nœud de connexion et confirme que sbatch, squeue et scancel sont dans le PATH et que remote_dir n'est pas sous /tmp. Le rapport nomme la version de Python du nœud de connexion et le job_python que la tâche utilisera. La vérification ne voit pas quels paquets les nœuds de calcul possèdent, donc un paquet manquant sur un nœud de calcul se manifeste par une exécution en échec avec l'erreur d'import dans le journal de l'exécution. Lancez une première tâche courte avec un petit time pour trouver tôt ce genre de problème.

Les étapes d'une exécution SLURM

Potato se connecte au nœud de connexion et y copie son code, comme pour un backend ssh. L'agent effectue ensuite ces étapes.

1. Il télécharge le lot dans remote_dir/jobs/<run>/.
2. Il écrit job.sh et soumet le script avec sbatch --parsable. Le journal de l'exécution consigne Submitted SLURM job avec l'identifiant de la tâche et les options.
3. Dans le répertoire de la tâche, le processus d'entraînement sur le nœud de calcul écrit ses événements dans events.jsonl, ses erreurs dans stderr.log et son code de sortie dans exit_code. La sortie propre de SLURM va dans slurm.out.
4. L'agent lit events.jsonl à mesure que le fichier grandit et relaie la progression au serveur. L'agent exécute squeue une fois par poll_interval_s, et le journal de l'exécution consigne chaque changement d'état de la tâche dans la file, par exemple SLURM job 4242: PENDING (Priority) puis RUNNING on node07.
5. Quand la tâche se termine, l'agent envoie les prédictions et rapporte le résultat. Les artefacts reviennent au serveur et le répertoire de la tâche est supprimé, comme pour un backend ssh.

Cancel run envoie scancel --full --signal=TERM à la tâche, puis un scancel simple si le processus d'entraînement ne s'est pas arrêté. Quand la session ssh vers le nœud de connexion tombe, l'agent annule sa tâche, et l'allocation de GPU est libérée. Quand l'ordonnanceur termine lui-même une tâche, l'exécution échoue avec la raison de l'ordonnanceur, lue dans scontrol show job ou slurm.out. Les raisons que Potato rapporte incluent la limite de temps, une panne de nœud, une préemption, un manque de mémoire et un scancel venu de l'extérieur de Potato.

La suite de tests de Potato exécute la séquence SLURM contre un substitut de sbatch, squeue et scancel, et couvre la soumission des tâches, l'état dans la file, le relais de la progression et l'annulation. Les limites des partitions et la politique de préemption diffèrent d'un cluster à l'autre, donc surveillez le journal de l'exécution de votre première tâche sur un nouveau cluster.

Un agent démarré à la main sur un nœud de connexion qui peut atteindre le serveur peut aussi soumettre à SLURM, avec potato training agent --server ... --backend <name> --workdir <shared dir> --slurm-config slurm.json. Le fichier slurm.json contient les paramètres du tableau ci-dessus sous forme d'objet JSON, et --workdir doit se trouver sur un stockage que les nœuds de calcul partagent.

Une machine que Potato ne peut pas atteindre

Un backend agent convient à une machine à laquelle le serveur d'annotation ne peut pas se connecter, comme un poste derrière un NAT. Quelqu'un démarre potato training agent sur cette machine, et l'agent interroge le serveur pour obtenir des tâches. L'agent n'a besoin d'aucun port entrant, car l'agent ouvre toutes les connexions. Une annulation parvient à l'agent dans la réponse du serveur à son prochain rapport de progression. Les fichiers du modèle restent sur la machine d'entraînement, et seuls les prédictions et le résultat reviennent.

Prérequis d'un backend agent

La machine d'entraînement a besoin de Potato, des paquets du module d'entraînement que vous exécutez et d'une route réseau vers l'URL du serveur d'annotation. Pour hf-text-classification, une seule installation couvre Potato et les paquets du module.

pip install "potato-annotation[train-text]"

Le serveur n'a besoin que de l'entrée du backend. Un backend agent accepte type, description, heartbeat_timeout_s (120 par défaut) et queue_timeout_s, et aucune autre clé.

model_training:
  enabled: true
  backends:
    lab-workstation:
      type: agent
      queue_timeout_s: 3600

Enregistrer et démarrer l'agent

Émettez un jeton pour le backend sur le serveur d'annotation.

potato training register lab-workstation config.yaml

La commande affiche le jeton une seule fois, avec les commandes à exécuter sur la machine d'entraînement.

Token for backend 'lab-workstation' (shown once; registering again replaces it):
 
  <token>
 
On the training machine:
 
  export POTATO_TRAINING_TOKEN=<token>
  potato training agent --server http://<this-server>:8000 --backend lab-workstation

Démarrez l'agent sur la machine d'entraînement avec l'URL réelle du serveur.

export POTATO_TRAINING_TOKEN=<the token>
potato training agent --server https://annotate.example.org --backend lab-workstation

L'agent exécute les tâches de son backend jusqu'à ce que vous l'arrêtiez. --token-file lit le jeton dans un fichier au lieu de POTATO_TRAINING_TOKEN, et --python nomme l'interpréteur dans lequel tourne le processus d'entraînement, avec l'interpréteur de l'agent par défaut. --once se termine après une tâche, --workdir déplace les fichiers de l'agent hors de ~/.cache/potato-training, et --keep conserve le lot de chaque tâche. Enregistrer à nouveau le même nom émet un nouveau jeton et invalide l'ancien.

potato training check lab-workstation config.yaml affiche l'enregistrement du jeton du backend, avec last_seen renseigné dès qu'un agent s'est connecté. Avant l'enregistrement, la commande affiche no token issued yet et la commande d'enregistrement à lancer.

Les étapes d'une exécution d'agent

Une exécution destinée à un backend agent attend dans l'état queued jusqu'à ce qu'un agent demande du travail. Avec queue_timeout_s: 3600, l'exécution échoue après une heure sans agent, et sans queue_timeout_s l'exécution attend jusqu'à ce que vous l'annuliez. L'agent télécharge le lot sous forme de fichier tar.gz et reprend un téléchargement interrompu là où il s'est arrêté, jusqu'à cinq tentatives. L'agent exécute ensuite le processus d'entraînement, envoie la progression, téléverse predictions.jsonl et rapporte le code de sortie. Le serveur répond 413 à un fichier de prédictions plus gros que max_predictions_mb (512 par défaut).

Les fichiers du modèle restent sur la machine d'entraînement sous --workdir, et l'artifact_uri de l'enregistrement de l'exécution nomme l'hôte et le répertoire. Si l'agent ne peut pas joindre le serveur pendant 300 secondes au cours d'une exécution, l'agent annule lui-même l'exécution. Une exécution dont l'agent n'envoie rien pendant heartbeat_timeout_s échoue côté serveur avec No word from the agent on lab-workstation for 120 seconds.

Échecs courants

Chaque entrée donne le message du journal de l'exécution ou du rapport de vérification, puis la solution. La liste complète pour chaque backend et chaque module d'entraînement se trouve dans la section de dépannage du dépôt amont.

• ssh to gpu.example.org failed: Permission denied. Potato a besoin d'une clé qui fonctionne sans invite. ssh gpu.example.org true depuis le compte du serveur doit réussir.
• /opt/conda/bin/python3 was not found on gpu.example.org. Définissez python dans le backend avec un interpréteur qui existe sur l'hôte.
• No GPU has 4000 MB free. Chaque GPU de l'hôte est plus occupé que min_free_gpu_mb ne le permet. potato training check gpu-server config.yaml liste les GPU. Attendez, baissez le seuil ou épinglez un GPU avec gpus: "1".
• Trainer 'hf-text-classification' could not be imported. L'interpréteur distant manque d'un paquet dont le module d'entraînement a besoin. Faites pointer python vers un interpréteur qui l'a, ou listez le paquet sous packages. Sur un backend SLURM, corrigez l'environnement que nomme job_python.
• This host's torch has no kernels for any of its GPUs. Le torch distant a été compilé pour des GPU plus récents que ceux de l'hôte. Installez une version de torch pour ces GPU, ou utilisez un autre hôte.
• No word from the agent on gpu-server for 120 seconds. La machine distante ou le réseau a disparu. Sur un backend ssh, agent.log dans le répertoire de l'exécution contient la dernière sortie de l'agent.
• The copy from gpu.example.org sent nothing for 180 s. Le réseau vers l'hôte s'est arrêté pendant la recopie du modèle. Les prédictions de l'exécution sont déjà conservées, et seuls les fichiers du modèle manquent dans artifacts/.
• login.cluster.example.org has no sbatch on PATH, so it cannot submit jobs. Le host n'est pas le nœud de connexion du cluster, ou les commandes se trouvent dans un PATH que seul un shell de connexion définit. Définissez PATH sous env dans le backend.
• SLURM job 4242 ended before the worker finished: it reached its time limit. Augmentez time dans le backend, ou entraînez sur moins d'items. Définissez keep_remote: true pour conserver slurm.out afin de le lire après d'autres échecs de l'ordonnanceur.
• Une exécution sur un backend agent reste en attente. Aucun agent portant ce nom de backend n'interroge le serveur. Démarrez un agent avec potato training agent --backend lab-workstation, et vérifiez le jeton avec Check dans la page Training.
• nvrtc: error: failed to open libnvrtc-builtins.so.13.0. Le torch de l'hôte et son paquet nvidia-cuda-nvrtc correspondent à des versions de CUDA différentes. Installez le nvidia-cuda-nvrtc qui correspond à la version de torch, ou faites pointer python vers un autre interpréteur.

Pour aller plus loin

• Vue d'ensemble de l'entraînement de modèles couvre la page Training, la boucle d'entraînement et la publication d'un modèle sur le Hugging Face Hub.
• La configuration liste chaque clé model_training, les scores sur items réservés et l'endroit où les exécutions sont stockées.
• Affiner des LLM couvre les modules d'entraînement qui ont le plus souvent besoin d'un GPU distant, avec LoRA et des poids de base en 4 bits.
• La référence amont sur l'endroit où tournent les exécutions donne le tableau complet des clés de chaque backend, et la section sur le protocole de l'agent documente les routes pour qui écrit son propre agent.