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.

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 :

>>> hf jobs uv run train.py

>>> 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 :

>>> 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 -- :

>>> 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 et la documentation des commandes UV.

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 <docker-image>.

Consultez Utilisation des images Docker 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 :

# /// 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 la 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 pour les règles de fusion complètes.

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 :

>>> hf jobs run ubuntu echo "Hello from the cloud!"

Ici, --help est transmis à Python au lieu d’afficher l’aide de Jobs :

>>> 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.

Voir Utilisation des images Docker 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, les Jobs fournissent automatiquement les variables d’environnement suivantes à l’intérieur du conteneur :

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 :

# 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

# Pass environment variables
>>> hf jobs uv run -e FOO=foo -e BAR=bar python -c 'import os; print(os.environ["FOO"], os.environ["BAR"])'

# 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"])'

# 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"])'

# 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"])'

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 d’accueil Hugging Face 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 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.

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 pour le montage, le streaming et le traitement de grandes données sur les Jobs.

Types de volumes :

Utilisez ensuite le volume monté comme un répertoire local à l'intérieur du conteneur :

# 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 :

>>> 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 :

>>> 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 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 :

>>> 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.

En Python, utilisez la classe Volume :

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"),
    ],
)

Le montage de volumes nécessite huggingface_hub >= 1.8.0. Consultez la documentation du client Python et le guide d’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 :

>>> 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 :

>>> hf jobs uv run --with trl --flavor a10g-small -s HF_TOKEN -- sft.py --model_name_or_path Qwen/Qwen2-0.5B ...

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. 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) :

>>> 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 <port> (CLI) ou expose=[<port>] (API Python). Chaque port exposé est accessible à l’adresse https://<job_id>--<port>.hf.jobs et nécessite un jeton HF avec un accès read à l’espace de noms du job :

curl -H "Authorization: Bearer $HF_TOKEN" https://<job_id>--<port>.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 <port> (CLI) ou expose_public=[<port>] (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.

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 pour plus de détails.

CLI

# 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

>>> 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 :

# Expose port 8000 (requires an HF token)
>>> hf jobs expose <job_id> 8000

# Expose port 8000 (requires an HF token) and port 9000 publicly
>>> hf jobs expose <job_id> 8000 --public 9000

# Close all exposed ports
>>> hf jobs expose <job_id> --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 <job_id>.

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.

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

# 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) :

>>> hf jobs ssh 6a2bd1f1871c005b5352ad31 --dry-run
ssh 6a2bd1f1871c005b5352ad31@ssh.hf.jobs

>>> hf jobs ssh 6a2bd1f1871c005b5352ad31 -i ~/.ssh/id_ed25519

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 <job_id>, ou directement avec ssh <job_id>@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 <job_id> --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 :

# 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 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 :

# 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 <name> (CLI) ou de network_group="<name>" (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}<alias> pour les membres ayant réclamé un alias avec --network-alias <alias> (CLI) ou network_aliases=[<alias>] (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

# 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

>>> 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) :

>>> 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 :

>>> hf jobs uv run --timeout 2h --with torch --flavor a10g-large train.py

Autres exemples :

--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

Si vous ne spécifiez pas de délai d’expiration, un délai par défaut sera appliqué à votre tâche. Pour les tâches de longue durée, comme l’entraînement de modèles qui peut prendre des heures, assurez-vous de définir un délai 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 <n> (CLI) ou attempts=<n> (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 :

>>> 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 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.

>>> 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 :

>>> 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 :

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.

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 :

# Replace the labels on a Job
hf jobs labels <job_id> --label env=prod --label team=ml

# Name an existing Job (keeps its other labels)
hf jobs labels <job_id> --name daily-report

# Remove all labels from a Job
hf jobs labels <job_id> --clear