# Configuration ## Authentification Vous devez être authentifié avec `hf auth login` pour exécuter des Jobs, et utiliser un jeton disposant de l'autorisation de démarrer et de gérer les Jobs. Sinon, passez un jeton Hugging Face manuellement avec `--token` dans le CLI, ou avec l'argument `token` en Python. ## Passage d'arguments Utilisez `--` pour séparer les options de Jobs de votre commande ou script et de ses arguments. Les options situées après `--`, telles que `--help` ou `--timeout`, sont transmises telles quelles au lieu d’être interprétées par Jobs. Cela s’applique aux Jobs UV et Docker. ```text hf jobs uv run --flavor t4-small -- script.py --early-stopping-patience 3 └─ Jobs option ┘ └─ script + arguments ─────────────┘ ``` ## UV Jobs Spécifiez le script UV ou la commande python à exécuter comme vous le feriez avec UV : ```bash >>> hf jobs uv run train.py ``` ```bash >>> hf jobs uv run python -c 'print("Hello from the cloud!")' ``` La commande `hf jobs uv run` accepte un argument UV tel que `--with` et `--python`. L'argument `--with` permet de spécifier les dépendances python, et `--python` permet de choisir la version de python à utiliser : ```bash >>> hf jobs uv run --with trl train.py >>> hf jobs uv run --python 3.12 train.py ``` Par exemple, passez des arguments à une commande en utilisant `--` : ```bash >>> hf jobs uv run --with trl-jobs -- trl-jobs sft --model_name Qwen/Qwen3-0.6B --dataset_name trl-lib/Capybara ``` Retrouvez la liste de tous les arguments dans la [documentation de l’interface en ligne de commande](https://huggingface.co/docs/huggingface_hub/package_reference/cli#hf-jobs-uv-run) et la [documentation des commandes UV](https://docs.astral.sh/uv/reference/cli/#uv-run). Par défaut, les UV Jobs s’exécutent avec l’image Docker `ghcr.io/astral-sh/uv:python3.12-bookworm`, mais vous pouvez utiliser une autre image, à condition qu’elle ait UV installé, en utilisant `--image `. Consultez [Utilisation des images Docker](./jobs-images#use-an-image-with-uv) pour choisir une image et comprendre comment son environnement interagit avec les dépendances UV. ### Définir la configuration de lancement dans le script Un script qui ne s’exécute correctement que sur un environnement d’exécution spécifique (une image donnée, un type de GPU ou un interpréteur système) peut emporter cette configuration avec lui, dans un tableau optionnel `[tool.hf-jobs]` de son en-tête PEP 723 : ```python # /// script # requires-python = ">=3.11" # dependencies = ["vllm", "datasets"] # # [tool.hf-jobs] # image = "vllm/vllm-openai:unlimited-ocr" # flavor = "l4x1" # python = "/usr/bin/python3" # secrets = ["HF_TOKEN"] # /// ``` `hf jobs uv run ocr.py` lance ensuite le script sur cette image et ce matériel. Un simple `uv run` ignore le tableau, car les tableaux `[tool.*]` font partie de PEP 723 et les outils ignorent ceux qui ne leur appartiennent pas. Clés prises en charge, toutes facultatives : `image`, `flavor`, `python`, `timeout`, `name`, `namespace`, `env`, `secrets`, `labels`, `volumes`, `network_group` et `network_aliases`. Elles correspondent aux drapeaux du même nom. Les valeurs du script sont des valeurs par défaut : un drapeau explicite l’emporte toujours, et `env`, `secrets`, `labels` et `volumes` sont fusionnés entrée par entrée, de sorte que `-e` et `-v` s’ajoutent à ce que le script déclare. Une clé inconnue est une erreur, et `secrets` ne liste que des noms : les valeurs proviennent de l’environnement de la personne qui exécute le script, et un secret non défini localement est également une erreur. Utilisez `--dry-run` pour afficher la configuration résolue sans soumettre ; les valeurs provenant du script sont marquées `(from script)`. Consultez le [guide de la CLI `hf`](https://huggingface.co/docs/huggingface_hub/guides/cli#ship-the-launch-config-with-the-script) pour les règles de fusion complètes. > [!WARNING] > Le tableau est lu uniquement par le CLI `hf`. `run_uv_job()` et `create_scheduled_uv_job()` l’ignorent, il faut donc passer `image=`, `flavor=`, ... explicitement depuis Python. ## Docker Jobs Spécifiez l’image Docker et la commande à exécuter comme vous le feriez avec docker : ```bash >>> hf jobs run ubuntu echo "Hello from the cloud!" ``` Ici, `--help` est transmis à Python au lieu d’afficher l’aide de Jobs : ```bash >>> hf jobs run --flavor cpu-basic python:3.12 -- python --help ``` Retrouvez la liste de tous les arguments dans la [documentation de l’interface en ligne de commande](https://huggingface.co/docs/huggingface_hub/package_reference/cli#hf-jobs-run). Voir [Utilisation des images Docker](./jobs-images) pour des exemples utilisant des images existantes et des images construites par Docker Spaces. ## Variables d'environnement et secrets ### Variables d'environnement intégrées De la même manière que les [variables d’environnement intégrées dans Spaces](./spaces-overview#built-in-environment-variables), les Jobs fournissent automatiquement les variables d’environnement suivantes à l’intérieur du conteneur : | Variable | Description | |----------|-------------| | `JOB_ID` | L'identifiant unique du travail actuel (par exemple, `699d874f1aad19adb8aaeadc`). Il s'agit du même ID affiché dans l'interface utilisateur et dans l'URL du travail. | | `ACCELERATOR` | Le type d'accélérateur disponible (par exemple, `t4-medium`, `a10g-small`, `a100x4`), ou `none` pour les tâches utilisant uniquement le CPU. | | `CPU_CORES` | Le nombre de cœurs CPU alloués au travail. | | `MEMORY` | La quantité de mémoire allouée au travail (par exemple, `8Gi`). | | `HF_NETWORK_GROUP_HOSTNAME` | Nom d'hôte résolu pour chaque tâche du [groupe de réseau](#network-groups) de la tâche. Défini uniquement si la tâche en déclare un. | | `HF_NETWORK_GROUP_PREFIX` | Préfixe à préfixer à un alias pour obtenir le nom d'hôte des membres du groupe qui le revendiquent (par exemple, `${HF_NETWORK_GROUP_PREFIX}master`). Défini uniquement lorsque le job déclare un groupe réseau. | Vous pouvez utiliser ces variables pour suivre les sorties, adapter votre code aux ressources disponibles ou référencer le travail en cours de manière programmatique : ```bash # Access job environment information >>> hf jobs run python:3.12 python -c "import os; print(f'Job: {os.environ.get(\"JOB_ID\")}, CPU: {os.environ.get(\"CPU_CORES\")}, Mem: {os.environ.get(\"MEMORY\")}')" ``` ### Variables d'environnement définies par l'utilisateur Vous pouvez passer des variables d'environnement à votre tâche à l'aide de ```bash # Pass environment variables >>> hf jobs uv run -e FOO=foo -e BAR=bar python -c 'import os; print(os.environ["FOO"], os.environ["BAR"])' ``` ```bash # Pass an environment from a local .env file >>> hf jobs uv run --env-file .env python -c 'import os; print(os.environ["FOO"], os.environ["BAR"])' ``` ```bash # Pass secrets - they will be encrypted server side >>> hf jobs uv run -s MY_SECRET=psswrd python -c 'import os; print(os.environ["MY_SECRET"])' ``` ```bash # Pass secrets from a local .env.secrets file - they will be encrypted server side >>> hf jobs uv run --secrets-file .env.secrets python -c 'import os; print(os.environ["MY_SECRET"])' ``` > [!TIP] > Utilisez `--secrets HF_TOKEN` pour transmettre votre jeton Hugging Face local de manière implicite. Avec cette syntaxe, le secret est récupéré depuis la variable d’environnement. Pour `HF_TOKEN`, il peut lire le fichier de jeton situé dans le dossier Hugging Face home si la variable d’environnement n’est pas définie. ## Volumes Montez les dépôts Hugging Face (modèles, jeux de données), les [Storage Buckets](./storage-buckets) ou les répertoires locaux en tant que volumes dans le conteneur de votre tâche à l’aide de `-v` ou `--volume`. Les sources du Hub utilisent le schéma d’URL `hf://` : `hf://[TYPE/]SOURCE:/MOUNT_PATH[:ro]` ; un répertoire local est transmis directement en tant que source. > [!TIP] > Les fichiers montés étant récupérés de manière différée, le montage permet à un Job de travailler avec des jeux de données bien plus volumineux que son disque local. Consultez [Process Large Datasets](./jobs-large-datasets) pour le montage, le streaming et le traitement de grandes données sur les Jobs. Types de volumes : | Type | Exemple | |------|---------| | Dépôt de modèle | `-v hf://openai/gpt-oss-120b:/model` | | Dépôt de jeu de données | `-v hf://datasets/stanfordnlp/imdb:/data` | | Seau de stockage | `-v hf://buckets/username/my-bucket:/mnt` | | Sous-dossier | `-v hf://datasets/org/my-dataset/train:/data` | | Répertoire local | `-v ./training-data:/data` | Utilisez ensuite le volume monté comme un répertoire local à l'intérieur du conteneur : ```bash # Mount a dataset and query it with DuckDB >>> hf jobs run -v hf://datasets/stanfordnlp/imdb:/dataset \ ... duckdb/duckdb duckdb -c "SELECT * FROM '/dataset/**/*.parquet' LIMIT 5" # Mount a bucket to save training checkpoints >>> hf jobs uv run -v hf://buckets/username/my-bucket:/training-outputs \ ... sft.py --output-dir /training-outputs/training-v3-final ``` Plusieurs volumes peuvent être montés en répétant le drapeau `-v` : ```bash >>> hf jobs run -v hf://datasets/username/my-dataset:/data -v hf://buckets/username/my-bucket:/output \ ... python:3.12 python script.py ``` Les modèles et les jeux de données sont toujours montés en **lecture seule**. Les buckets de stockage sont en **lecture-écriture** par défaut, ce qui est utile pour enregistrer les sorties, les points de contrôle ou les résultats intermédiaires. Utilisez `:ro` pour monter un bucket en mode lecture seule : ```bash >>> hf jobs run -v hf://buckets/username/my-bucket:/mnt:ro python:3.12 ls /mnt ``` ### Répertoires locaux Passer un répertoire local comme source le synchronise dans votre [Storage Bucket](./storage-buckets) privé `jobs-artifacts` (créé automatiquement) avant le démarrage du Job, puis le monte dans le conteneur. Les répertoires locaux sont montés en **lecture seule** par défaut ; utilisez `:rw` pour écrire des sorties : ```bash >>> hf jobs uv run -v ./pdfs:/input -v ./md-out:/output:rw ocr.py ``` La resynchronisation du même répertoire ne téléverse que les nouveaux fichiers ou les fichiers modifiés. Pour récupérer les fichiers qu'un Job a écrits sur un volume en lecture/écriture, synchronisez le dossier de son bucket une fois le Job terminé — le CLI affiche la commande exacte `hf buckets sync` au démarrage du Job. Les jobs planifiés fonctionnent également : le répertoire est synchronisé une fois lors de la création de l'horaire, et chaque déclenchement monte le même dossier. En Python, utilisez [`sync_job_volume`](https://huggingface.co/docs/huggingface_hub/guides/jobs#mount-local-data). En Python, utilisez la classe [`Volume`](https://huggingface.co/docs/huggingface_hub/package_reference/jobs#huggingface_hub.Volume) : ```python from huggingface_hub import Volume, run_job job = run_job( image="python:3.12", command=["python", "-c", "import os; print(os.listdir('/data'))"], volumes=[ Volume(type="dataset", source="username/my-dataset", mount_path="/data"), Volume(type="bucket", source="username/my-bucket", mount_path="/output"), ], ) ``` > [!NOTE] > Le montage de volumes nécessite `huggingface_hub` >= 1.8.0. Consultez la [documentation du client Python](https://huggingface.co/docs/huggingface_hub/guides/jobs#mount-a-volume) et le [guide d’installation](https://huggingface.co/docs/huggingface_hub/installation) pour plus de détails. ## Type de matériel Exécutez des tâches sur des GPU ou des TPU à l’aide de l’argument `flavor`. Par exemple, pour exécuter une tâche PyTorch sur un GPU A10G : ```bash >>> hf jobs uv run --with torch --flavor a10g-small python -c "import torch; print(f'This code ran with the following GPU: {torch.cuda.get_device_name()}')" ``` L'exécution de ce code affichera la sortie suivante ! ``` This code ran with the following GPU: NVIDIA A10G ``` Voici un autre exemple pour exécuter un script de fine-tuning comme [trl/scripts/sft.py](https://github.com/huggingface/trl/blob/main/trl/scripts/sft.py) : ```bash >>> hf jobs uv run --with trl --flavor a10g-small -s HF_TOKEN -- sft.py --model_name_or_path Qwen/Qwen2-0.5B ... ``` > [!TIP] > Pour un guide complet sur l’exécution de tâches d’entraînement de modèles avec TRL sur l’infrastructure Hugging Face, consultez la [documentation TRL Jobs Training](https://huggingface.co/docs/trl/main/en/jobs_training). Elle aborde les recettes de fine-tuning, le choix du matériel et les bonnes pratiques pour entraîner efficacement les modèles. Consultez la liste des options `--flavor` disponibles à l’aide de la commande `hf jobs hardware` (la valeur par défaut est `cpu-basic`) : ```bash >>> hf jobs hardware name pretty name cpu ram storage accelerator cost/min cost/hour cpu-basic CPU Basic 2 vCPU 16 GB 50 GB $0.0002 $0.01 cpu-upgrade CPU Upgrade 8 vCPU 32 GB 50 GB $0.0005 $0.03 cpu-performance CPU Performance 32 vCPU 256 GB 1024 GB $0.0317 $1.90 cpu-xl CPU XL 16 vCPU 124 GB 1000 GB $0.0167 $1.00 t4-small Nvidia T4 - small 4 vCPU 15 GB 50 GB 1x T4 (16 GB) $0.0067 $0.40 t4-medium Nvidia T4 - medium 8 vCPU 30 GB 100 GB 1x T4 (16 GB) $0.0100 $0.60 a10g-small Nvidia A10G - small 4 vCPU 15 GB 110 GB 1x A10G (24 GB) $0.0167 $1.00 a10g-large Nvidia A10G - large 12 vCPU 46 GB 200 GB 1x A10G (24 GB) $0.0250 $1.50 a10g-largex2 2x Nvidia A10G - large 24 vCPU 92 GB 1000 GB 2x A10G (48 GB) $0.0500 $3.00 a10g-largex4 4x Nvidia A10G - large 48 vCPU 184 GB 2000 GB 4x A10G (96 GB) $0.0833 $5.00 a100-large Nvidia A100 - large 12 vCPU 142 GB 1000 GB 1x A100 (80 GB) $0.0417 $2.50 a100x4 4x Nvidia A100 48 vCPU 568 GB 4000 GB 4x A100 (320 GB) $0.1667 $10.00 a100x8 8x Nvidia A100 96 vCPU 1136 GB 8000 GB 8x A100 (640 GB) $0.3333 $20.00 h200 Nvidia H200 23 vCPU 256 GB 3000 GB 1x H200 (141 GB) $0.0833 $5.00 h200x2 Nvidia H200 46 vCPU 512 GB 6000 GB 2x H200 (282 GB) $0.1667 $10.00 h200x4 Nvidia H200 92 vCPU 1024 GB 12000 GB 4x H200 (564 GB) $0.3333 $20.00 h200x8 Nvidia H200 184 vCPU 2048 GB 24000 GB 8x H200 (1128 GB) $0.6667 $40.00 rtx-pro-6000 Nvidia RTX PRO 6000 23 vCPU 256 GB 475 GB 1x RTX PRO 6000 (96 GB) $0.0458 $2.75 rtx-pro-6000x2 Nvidia RTX PRO 6000 46 vCPU 512 GB 950 GB 2x RTX PRO 6000 (192 GB) $0.0917 $5.50 rtx-pro-6000x4 Nvidia RTX PRO 6000 92 vCPU 1024 GB 1900 GB 4x RTX PRO 6000 (384 GB) $0.1833 $11.00 rtx-pro-6000x8 Nvidia RTX PRO 6000 184 vCPU 2048 GB 3800 GB 8x RTX PRO 6000 (768 GB) $0.3667 $22.00 l4x1 1x Nvidia L4 8 vCPU 30 GB 400 GB 1x L4 (24 GB) $0.0133 $0.80 l4x4 4x Nvidia L4 48 vCPU 186 GB 3200 GB 4x L4 (96 GB) $0.0633 $3.80 l40sx1 1x Nvidia L40S 8 vCPU 62 GB 380 GB 1x L40S (48 GB) $0.0300 $1.80 l40sx4 4x Nvidia L40S 48 vCPU 382 GB 3200 GB 4x L40S (192 GB) $0.1383 $8.30 l40sx8 8x Nvidia L40S 192 vCPU 1534 GB 6500 GB 8x L40S (384 GB) $0.3917 $23.50 ``` ## Exposer les ports Les jobs peuvent exposer des ports de conteneur via le proxy public des jobs en utilisant `--expose ` (CLI) ou `expose=[]` (API Python). Chaque port exposé est accessible à l’adresse `https://--.hf.jobs` et nécessite un jeton HF avec un accès `read` à l’espace de noms du job : ```bash curl -H "Authorization: Bearer $HF_TOKEN" https://--.hf.jobs/ ``` Cela fonctionne avec `hf jobs run`, `hf jobs uv run` et leurs variantes planifiées. Répétez le drapeau pour exposer plusieurs ports (`--expose 8000 --expose 8001`) ou passez plusieurs ports dans la liste (`expose=[8000, 8001]`). Pour rendre un port accessible sans jeton HF, utilisez plutôt `--expose-public ` (CLI) ou `expose_public=[]` (API Python). Toute personne disposant de l’URL peut alors accéder au port ; utilisez cette option uniquement pour un service dont le partage est sans risque. Vous pouvez combiner les deux options : certains ports exigeront alors un jeton HF tandis que d’autres resteront publics. > [!NOTE] > Les ports exposés sont facturés à un tarif horaire fixe modique, en plus du prix du matériel du job, uniquement pendant que le job est en cours d'exécution. Consultez la [page de tarification](./jobs-pricing) pour plus de détails. ### CLI ```bash # Expose a web server running on port 8000 >>> hf jobs run --expose 8000 python:3.12 python -m http.server 8000 ✓ Job started id: 6a2aa7cec4f53f9fc5aa4cff url: https://huggingface.co/jobs/Wauplin/6a2aa7cec4f53f9fc5aa4cff Hint: Exposed ports are reachable at (requires an HF token with read access to the job): https://6a2aa7cec4f53f9fc5aa4cff--8000.hf.jobs Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... ``` ### Python ```python >>> from huggingface_hub import run_job >>> job = run_job(image="python:3.12", command=["python", "-m", "http.server", "8000"], expose=[8000]) >>> job.status.expose_urls ['https://6a2ab384c4f53f9fc5aa4d4f--8000.hf.jobs'] ``` ### Modifier les ports d'un Job en cours d'exécution Utilisez `hf jobs expose` pour modifier les ports exposés, sans redémarrer le Job : ```bash # Expose port 8000 (requires an HF token) >>> hf jobs expose 8000 # Expose port 8000 (requires an HF token) and port 9000 publicly >>> hf jobs expose 8000 --public 9000 # Close all exposed ports >>> hf jobs expose --clear ``` La commande remplace la liste complète des ports exposés, de sorte qu’un port omis est fermé. En Python, utilisez `update_job_expose`. ## SSH Vous pouvez ouvrir une session SSH interactive vers un Job en cours d’exécution pour le déboguer, l’inspecter ou travailler directement à l’intérieur du conteneur. Activez-la lors de la création du job avec `--ssh` (CLI) ou `ssh=True` (API Python), puis connectez-vous avec `hf jobs ssh `. Seuls les utilisateurs disposant d'un accès en écriture à l'espace de noms du Job sont autorisés (c'est-à-dire le créateur du Job, ou les membres de l'organisation propriétaire disposant de permissions d'écriture). L'authentification est effectuée via des clés publiques SSH enregistrées sur [https://huggingface.co/settings/keys](https://huggingface.co/settings/keys). SSH est disponible sur `hf jobs run` et `hf jobs uv run`. Il n'est pas pris en charge pour les tâches planifiées. ### CLI ```bash # Start a job with SSH enabled >>> hf jobs run --ssh --detach --timeout 10m python:3.12 sleep infinity ✓ Job started id: 6a2bd1f1871c005b5352ad31 url: https://huggingface.co/jobs/Wauplin/6a2bd1f1871c005b5352ad31 Hint: Use `hf jobs ssh 6a2bd1f1871c005b5352ad31` to open an SSH session into the job. # Open an SSH session into the job >>> hf jobs ssh 6a2bd1f1871c005b5352ad31 ``` Vous pouvez également afficher la commande SSH sans l’exécuter (`--dry-run`), ou passer un fichier d’identité spécifique (`-i`/`--identity-file`) : ```bash >>> hf jobs ssh 6a2bd1f1871c005b5352ad31 --dry-run ssh 6a2bd1f1871c005b5352ad31@ssh.hf.jobs >>> hf jobs ssh 6a2bd1f1871c005b5352ad31 -i ~/.ssh/id_ed25519 ``` ### Python ```python >>> from huggingface_hub import run_job >>> job = run_job(image="python:3.12", command=["sleep", "infinity"], ssh=True) >>> job.status.ssh_url 'ssh://6a2bd1f1871c005b5352ad31@ssh.hf.jobs' ``` Puis connectez-vous depuis un terminal avec `hf jobs ssh `, ou directement avec `ssh @ssh.hf.jobs`. ### Redirection de port Étant donné qu’il s’agit d’une connexion SSH classique, vous pouvez utiliser les options `-L` et `-R` de SSH pour transférer des ports entre votre machine et le Job. Connectez-vous directement avec `ssh` (utilisez `hf jobs ssh --dry-run` pour obtenir la destination exacte) et ajoutez les options de transfert. Utilisez `-L` (transfert local) pour accéder à un service exécuté dans le Job depuis votre machine. Par exemple, pour atteindre un TensorBoard démarré dans un Job d’entraînement : ```bash # Forward local port 6006 to the Job's TensorBoard on port 6006 >>> ssh -L 6006:localhost:6006 6a2bd1f1871c005b5352ad31@ssh.hf.jobs ``` Ouvrez ensuite [http://localhost:6006](http://localhost:6006) dans votre navigateur. Utilisez `-R` (transfert distant) pour permettre au Job d’accéder à un service exécuté sur votre machine. Par exemple, pour exposer une base de données ou une API locale au Job : ```bash # Make your local port 8080 reachable from inside the Job on port 8080 >>> ssh -R 8080:localhost:8080 6a2bd1f1871c005b5352ad31@ssh.hf.jobs ``` ## Groupes de réseaux Les jobs peuvent rejoindre un groupe de réseau à l’aide de `--network-group ` (CLI) ou de `network_group=""` (API Python). Les jobs appartenant au même espace de noms et au même groupe de ressources qui partagent un groupe peuvent se joindre sur tous les ports : `HF_NETWORK_GROUP_HOSTNAME` se résout pour tous les membres, et `${HF_NETWORK_GROUP_PREFIX}` pour les membres ayant réclamé un alias avec `--network-alias ` (CLI) ou `network_aliases=[]` (API Python). Cela fonctionne avec `hf jobs run` et `hf jobs uv run`. Les membres sont résolubles avant d’être prêts, il faut donc se connecter avec des tentatives répétées. Les noms de groupe et les alias sont des chaînes alphanumériques minuscules et des tirets, 46 et 34 caractères maximum ; les alias d’un job doivent être uniques. ### CLI ```bash # Start a server, reachable by the other members of the group as "master" >>> hf jobs run --detach --network-group train --network-alias master python:3.12 python -m http.server 8000 # Start a client in the same group >>> hf jobs run --detach --network-group train python:3.12 sh -c 'curl --retry 10 --retry-connrefused "http://${HF_NETWORK_GROUP_PREFIX}master:8000/"' ``` ### Python ```python >>> from huggingface_hub import run_job >>> server = run_job( ... image="python:3.12", ... command=["python", "-m", "http.server", "8000"], ... network_group="train", ... network_aliases=["master"], ... ) >>> client = run_job( ... image="python:3.12", ... command=["sh", "-c", 'curl --retry 10 --retry-connrefused "http://${HF_NETWORK_GROUP_PREFIX}master:8000/"'], ... network_group="train", ... ) ``` Les cadres d’entraînement multi-nœuds peuvent utiliser un alias en tant qu’hôte de rendez-vous, par exemple `torchrun --master_addr "${HF_NETWORK_GROUP_PREFIX}master"`. ## Délai d'attente Les jobs ont un délai d'expiration par défaut (30 minutes), après lequel ils s'arrêtent automatiquement. C'est un point important à connaître lors de l'exécution de tâches de longue durée, comme l'entraînement de modèles. Vous pouvez spécifier une valeur de délai d'attente personnalisée à l'aide du paramètre `--timeout` lors de l'exécution d'un job. Le délai d'attente peut être spécifié de deux manières : 1. **En tant que nombre** (interprété en secondes) : Utilisez `--timeout` et passez le nombre en secondes (ici 2 heures = 7200 secondes) : ```bash >>> hf jobs uv run --timeout 7200 --with torch --flavor a10g-large train.py ``` 2. **Sous forme de chaîne avec des unités de temps** : Ou utilisez `--timeout` et utilisez différentes unités de temps : ```bash >>> hf jobs uv run --timeout 2h --with torch --flavor a10g-large train.py ``` Autres exemples : ```bash --timeout 30m # 30 minutes --timeout 1.5h # 1.5 hours --timeout 1d # 1 day --timeout 3600s # 3600 seconds ``` Unités de temps prises en charge : - `s` - secondes - `m` - minutes - `h` - heures - `d` - jours > [!WARNING] > Si vous ne spécifiez pas de délai d'attente, un délai d'attente par défaut sera appliqué à votre tâche. Pour les tâches de longue durée comme l'entraînement de modèles, qui peuvent prendre des heures, assurez-vous de définir un délai d'attente approprié afin d'éviter les terminaisons inattendues de la tâche. ## Nouvelles tentatives Par défaut, un Job s’exécute une seule fois. Utilisez `--attempts ` (CLI) ou `attempts=` (API Python) pour relancer un Job en cas d’échec. Ce nombre inclut la première exécution, de sorte que `--attempts 3` autorise jusqu’à deux nouvelles tentatives : ```bash >>> hf jobs uv run --attempts 3 --flavor a10g-large train.py ``` Cela fonctionne avec `hf jobs run`, `hf jobs uv run` et leurs variantes planifiées. Une nouvelle tentative relance la commande depuis le début, sous le même identifiant de Job. Pour permettre à une nouvelle tentative de reprendre là où la tentative précédente s’est arrêtée, écrivez des points de contrôle dans un bucket monté et configurez votre script pour qu’il reprenne à partir de ceux-ci. Consultez [Après sa fin](./jobs-training#after-it-ends) dans Train Models on Jobs. ## Espace de noms Exécutez des Jobs sous votre compte d’organisation à l’aide de l’argument `--namespace`. Assurez-vous d’être connecté avec un jeton disposant de l’autorisation de démarrer et de gérer des Jobs sous votre compte d’organisation. ```bash >>> hf jobs uv run --namespace my-org-name python -c "print('Running in an org account')" ``` Notez que vous pouvez passer manuellement un jeton disposant des autorisations appropriées : ```bash >>> hf jobs uv run --namespace my-org-name --token hf_xxx python -c "print('Running in an org account')" ``` ## Étiquettes Ajoutez un ou plusieurs étiquettes à un Job pour y ajouter des métadonnées à l’aide de `-l` ou `--label`. Vous pouvez utiliser ces métadonnées plus tard pour filtrer les Jobs sur le site web ou dans le CLI. Ajoutez des étiquettes avec `--label my-label` ou des étiquettes clé-valeur avec `--label key=value`. Les clés et les valeurs peuvent contenir des lettres, des chiffres, `-` et `_`. Par exemple : ```bash hf jobs uv run --label fine-tuning --label model=Qwen3-06B --label dataset=Capybara ... ``` Notez que l'utilisation de la même `key` à plusieurs reprises entraîne l'écrasement et le rejet de tout label précédent par la dernière `key=value` portant `key`. ### Nommer un Job Donnez un nom à un Job pour le retrouver et l’identifier plus facilement dans l’interface utilisateur. Le nom est stocké en tant que libellé `name` et n’a pas besoin d’être unique. Dans l’interface utilisateur, les Jobs sont regroupés par nom. ```bash hf jobs run --name daily-report python:3.12 python report.py ``` Si vous ne passez pas `--name`, le Job est nommé d’après son image Docker ou son script, suivi d’un court hachage de la commande. Ainsi, les relances de la même commande partagent le même nom, tandis que des commandes différentes reçoivent des noms distincts (par exemple `python-3-12-6b9d662c` pour un Job exécuté sur `python:3.12`). ### Mettre à jour les étiquettes Mettre à jour les étiquettes d’un Job existant avec `hf jobs labels`. Passer `--label` remplace toutes les étiquettes existantes ; passer `--name` seul les conserve : ```bash # Replace the labels on a Job hf jobs labels --label env=prod --label team=ml # Name an existing Job (keeps its other labels) hf jobs labels --name daily-report # Remove all labels from a Job hf jobs labels --clear ```