kermt-setup

Initialiser l'environnement de l'agent KERMT. À exécuter une seule fois sur une machine neuve (ou après des modifications du Dockerfile ou de environment.yml) avant d'invoquer tout autre skill kermt-*.

Chemins des skills et de l'exécution

Définir SKILL_DIR au chemin absolu du répertoire du skill installé. Exporter KERMT_REPO comme chemin absolu du checkout KERMT utilisé pour l'exécution du modèle. L'assistant de conteneur intégré monte ce checkout à /workspace et ce skill à /skill (lecture seule). Les commandes à l'intérieur du conteneur utilisent /skill/scripts/.

Exigences matérielles

GPU : au moins un GPU NVIDIA compatible CUDA visible par l'hôte. L'image est basée sur nvidia/cuda:12.6.3-cudnn-devel-ubuntu22.04, donc le pilote hôte doit supporter CUDA 12.6. Vérifier avec nvidia-smi sur l'hôte avant l'invocation.
Docker sur l'hôte : moteur docker + nvidia-container-toolkit. Sans la boîte à outils, docker run --gpus all échouera à l'étape 2 du workflow ci-dessous.
Disque : ≈ 50 Go libres pour l'image kermt construite (docker image inspect --format '{{.Size}}' rapporte ≈ 44 Go ; la colonne Size dans docker images peut afficher ~100 Go car elle compte les couches d'attestation buildx partageables dédupliquées entre les images). Prévoir ~50 Go de stockage unique sur disque ; ajouter une marge confortable si vous conservez aussi le cache de compilation.
Mémoire : la compilation elle-même culmine à ~4 Go de RAM lors de la résolution de l'environnement conda.
Ce skill ne lance pas lui-même des workloads d'entraînement/inférence ; les exigences matérielles par workflow (VRAM, nombre de GPU) sont déclarées dans les skills respectifs kermt-<workflow>.

Quand invoquer

L'utilisateur demande explicitement (/kermt-setup, "configurer kermt", "construire l'image kermt", etc.).
Ou un autre skill kermt-* détecte que l'image n'existe pas et le routage se fait ici. (La plupart des autres skills appelent eux-mêmes kermt_ensure_image, donc c'est généralement nécessaire seulement pour la première configuration, le débogage ou une reconstruction forcée.)

Entrées

Le skill ne prend aucun argument obligatoire. Surcharges optionnelles (via des variables d'environnement avant l'invocation, ou en les définissant dans le shell de l'utilisateur) :

KERMT_IMAGE — tag d'image à construire/vérifier (par défaut : kermt:latest).
KERMT_REPO — chemin hôte du checkout du repo kermt (par défaut : auto-dérivé de la localisation du script).

Si l'utilisateur n'a pas spécifié de chemin de repo et le répertoire de travail courant n'est pas à l'intérieur d'un clone de repo kermt, demander le chemin du repo avant de procéder.

Workflow

Tout le travail passe par le helper scripts/kermt_container.sh intégré sur l'hôte. La dispatch de sous-commandes du script peut être invoquée directement sans sourcing — c'est la forme préférée pour l'usage du skill.

Soit HELPER="$SKILL_DIR/scripts/kermt_container.sh".

Vérifier que docker est installé et le daemon est accessible.
```
"$HELPER" check_docker
```
Sortie 0 → continuer. Non-zéro → présenter l'erreur à l'utilisateur (généralement "docker not on PATH" ou "daemon not reachable") ; ne pas tenter l'étape 2.
Vérifier que la passthrough GPU fonctionne.
```
"$HELPER" check_gpu
```
Exécute docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu22.04 nvidia-smi et vérifie le statut de sortie. Non-zéro → indiquer à l'utilisateur d'installer nvidia-container-toolkit sur l'hôte et de confirmer qu'un GPU NVIDIA compatible CUDA est visible par l'hôte (nvidia-smi sur l'hôte devrait aussi fonctionner). S'arrêter ici ; sans passthrough GPU l'image kermt se construira mais aucun workflow ne s'exécutera.
Construire ou vérifier l'image kermt.
```
"$HELPER" ensure_image
```
Si l'image existe déjà, elle retourne immédiatement. Sinon elle se construit à partir de $KERMT_REPO/Dockerfile. Avertir l'utilisateur avant l'invocation que la première construction prend ~10–20 minutes sur un poste de travail typique et envoie les logs de construction à la console. Ne pas exécuter en arrière-plan — l'utilisateur veut voir la progression et tout échec de construction doit remonter immédiatement.
Test de fumée GPU à l'intérieur du conteneur. Mettre entre guillemets la commande python entière comme une seule chaîne — l'helper passe les arguments via bash -c "$*", donc les commandes multi-mots non échappées sont réanalysées et tout guillemet intégré est effondré.
```
"$HELPER" run -- 'python -c "import torch; print(\"cuda_available:\", torch.cuda.is_available()); print(\"device_count:\", torch.cuda.device_count())"'
```
Sortie attendue : cuda_available: True et un device_count positif. Si cuda_available est False malgré l'étape 2 réussie, quelque chose ne va pas avec le câblage CUDA du conteneur — rapporter la sortie complète à l'utilisateur et s'arrêter ; ne pas déclarer l'environnement prêt.
Résumé pour l'utilisateur. Rapporter :
- Tag et ID d'image (docker image inspect $KERMT_IMAGE --format '{{.Id}}').
- Taille d'image (docker image inspect $KERMT_IMAGE --format '{{.Size}}').
- Nombre de GPU détecté à l'intérieur du conteneur.
- "Prêt" — l'utilisateur peut maintenant invoquer d'autres skills kermt-*.

Règles strictes

Ne pas tirer ni pousser d'images docker. L'image kermt est construite localement uniquement.
Ne pas supprimer ou nettoyer automatiquement les anciens tags kermt:* sans confirmation explicite de l'utilisateur — l'utilisateur peut exécuter un finetune ou un pretrain dans un autre conteneur qui dépend d'un tag spécifique.
Ne pas modifier la configuration du daemon docker de l'hôte, daemon.json, ou l'appartenance aux groupes d'utilisateurs.
Ne pas modifier le Dockerfile ou environment.yml dans le cadre de ce skill. Si la construction échoue à cause d'un problème de Dockerfile, présenter l'erreur et s'arrêter ; laisser l'utilisateur décider s'il faut éditer.
Ne pas reconstruire l'image si elle existe déjà (c.-à-d. ne pas passer de flag --no-cache ou --pull à ensure_image) à moins que l'utilisateur demande explicitement une reconstruction forcée.

Reconstruction forcée

Si l'utilisateur demande explicitement une reconstruction (p. ex. après avoir modifié le Dockerfile ou environment.yml), le chemin le plus propre est de supprimer d'abord l'ancienne image, puis de relancer ensure_image :

docker image rm $KERMT_IMAGE
"$HELPER" ensure_image

Confirmer avec l'utilisateur avant d'exécuter docker image rm.