Configuration TAO

Bootstrap de session unique pour la banque de skills TAO. Les skills TAO sont autonomes — chaque skill de modèle, de données et de plateforme dispose de sa propre image de conteneur épinglée et d'instructions — mais les workflows multi-skills les chaînent (préparation des données, entraînement, évaluation, déploiement). Ce skill fournit les éléments au niveau de la session qui rendent ce chaînage possible quand les skills sont installés individuellement : le flux de découverte, les conventions de credentials, et la vérification préalable du host.

Quand la banque de skills complète est installée en tant que plugin depuis ce repository, un hook SessionStart injecte automatiquement cette guidance et vous n'avez pas besoin de lancer ce skill. Quand les skills ont été installés un par un à partir d'un catalog de skills, lancez ce skill en premier.

Démarrage rapide

set -a; source /path/to/.env; set +a   # omit if already exported

# 1. Host preflight — most TAO skills dispatch docker containers on a GPU host.
docker info > /dev/null && echo "OK: docker" || echo "MISSING: docker"
nvidia-smi > /dev/null && echo "OK: GPU" || echo "MISSING: NVIDIA GPU/driver"

# 2. Credential presence check — names only, never print values.
for v in NGC_KEY HF_TOKEN WANDB_API_KEY ACCESS_KEY SECRET_KEY S3_BUCKET_NAME S3_ENDPOINT_URL BREV_API_TOKEN; do
  [ -n "${!v:-}" ] && echo "SET:   $v" || echo "unset: $v"
done

# 3. NGC registry login (needed for nvcr.io image pulls). Key goes over
#    stdin — never as an argv flag, where it lands in the process table.
[ -n "${NGC_KEY:-}" ] && printf '%s' "$NGC_KEY" | docker login nvcr.io -u '$oauthtoken' --password-stdin

Si Docker ou le runtime host NVIDIA est manquant, utilisez le skill tao-setup-nvidia-gpu-host — il vérifie et (avec approbation) installe le driver NVIDIA 580 ou plus récent, CUDA Toolkit 13.0 ou plus récent, et NVIDIA Container Toolkit 1.19.0 ou plus récent, et peut installer Docker lui-même sur les hosts Debian/RHEL/SUSE. Ce sont les minimums TAO-wide. Si le modèle sélectionné déclare runtime_requirements.gpu_host dans references/skill_info.yaml, passez ces minimums spécifiques au modèle au skill de configuration du host.

Credentials

Chargez un fichier env approuvé par l'utilisateur avec set -a; source /path/to/.env; set +a dans le même appel bash que la commande qui consomme la variable. Ce skill ne crée jamais de fichier de credentials pour vous ; la seule écriture de credentials ici est l'étape 3 docker login, qui stocke un token nvcr.io dans ~/.docker/config.json.

NGC_KEY — tirages d'images nvcr.io (la plupart des skills)
HF_TOKEN — poids HuggingFace fermés (plusieurs skills de modèles)
WANDB_API_KEY — experiment tracking (optionnel)
ACCESS_KEY / SECRET_KEY / S3_BUCKET_NAME / S3_ENDPOINT_URL — I/O S3
BREV_API_TOKEN — dispatch de plateforme Brev

Flux de découverte (comment les skills TAO se chaînent)

Lisez le skill de tâche. Les skills de modèles (tao-train-*, tao-finetune-*) maîtrisent les spécificités réseau ; les skills de données (tao-generate-*, tao-analyze-*, tao-mine-*, …) maîtrisent les transformations ; les skills d'application (tao-run-automl, tao-run-deft-aoi, …) composent modèle + données + plateforme en workflows.
Lisez le references/skill_info.yaml du skill (quand présent) pour le contrat structuré : container_image (un URI épinglé), ou backend_contracts.<backend>.container_image pour un frontend multi-backend ; command, mode, config_format, inputs, outputs par action, et runtime_requirements.gpu_host optionnel. Les exigences runtime du modèle remplacent les defaults TAO-wide pour ce workflow.
Choisissez une plateforme d'exécution et lisez son skill pour les mounts, les variables d'env, et les conventions de ressources : les conventions tao-run-on-docker s'appliquent à tout docker run local ; tao-run-on-slurm, tao-run-on-kubernetes, et tao-run-on-brev couvrent le dispatch géré ; tao-run-on-virtualenv exécute un script Python docker-free dans un venv local. Les skills de plateforme installés externement (ex. kratos) rejoignent comme pairs — aucune enregistrement nécessaire. Les plateforme sont des pairs de classe égale — si l'utilisateur n'a pas choisi, demandez ; ne defaultez jamais silencieusement. Chaque skill de plateforme implémente le même contrat consommateur quatre-verbes (submit/status/logs/cancel) sur son CLI natif (docker/kubectl/ssh+sbatch/brev exec) — il n'y a pas de nvidia-tao-sdk.
Construisez le spec sous forme de dicts imbriqués ({"train": {"num_epochs": 12}}, jamais des clés pointées plates), confirmez auprès de l'utilisateur, puis exécutez les quatre verbes : tao-launch-workflow pilote la barrière de lancement partagée ; scripts/tao_job_record.py open frappé l'id job et lie results_dir avant le lancement (enregistrement puis lancement) ; le skill de plateforme exécute submit ; puis surveillez avec status/logs, en mappant les états natifs au vocabulaire fixe PENDING RUNNING COMPLETE ERROR CANCELED UNKNOWN.

Conventions que tous les skills TAO suivent

Confirmez avant les effets de bord. docker run, soumission de jobs, pushes, et mutations de fichiers en dehors du répertoire de travail nécessitent d'abord la confirmation de l'utilisateur. Installer une dépendance Python manquante prérequise est la seule exception : installez-la par défaut et rapportez ce qui a été installé.
Ne demandez jamais les credentials en chat et ne printez jamais les valeurs de credentials ou le contenu d'un fichier de credentials ; nommez la variable manquante pour que l'utilisateur puisse l'exporter ou l'ajouter à un fichier env que vous sourçez ensuite.
Les images de conteneur sont épinglées par skill. Chaque skill porte l'URI d'image exacte contre laquelle il a été validé ; ne swappez pas silencieusement les tags. Offrez des overrides seulement quand le skill documente un chemin d'override.
Les exigences runtime sont en couches. Les skills de plateforme maîtrisent les exigences host par défaut et le mécanisme check/install. Un modèle peut overrider seulement les versions minimums qu'il a validées en déclarant runtime_requirements.gpu_host dans references/skill_info.yaml ; passez ces valeurs à la vérification de configuration du host partagée plutôt que de changer les defaults pour les modèles non liés.
L'exécution est SDK-free. Job tracking (scripts/tao_job_record.py), staging S3/données (tao-data-io, tiers de stockage A/B/C), et multi-nœud (les templates SLURM/K8s + scripts/nccl_allreduce_probe.py) sont intégrés à la banque — pas de nvidia-tao-sdk. La seule exception est la recherche AutoML (tao-run-automl), qui utilise la wheel nvidia-tao-automl et son SDK transitif.

Optionnel : identité d'agent Codex

Pour les sessions Codex, scripts/install-codex-agents.sh enregistre la TAO skill marketplace, installe le plugin, et copie l'identité d'agent TAO dans ~/.codex/AGENTS.md pour qu'il se charge dans chaque session :

bash scripts/install-codex-agents.sh