Plier dans les nuages avec vast.ai

[JWhy]

Bonjour, 

J'ai mis à jour le guide  (chapitre 3 de la partie 2) pour documenter l'utilisation d'un nouveau template :
- s'appuyant sur une nouvelle image Docker que j'ai créée from scratch à partir d'un Ubuntu 24.04 "nu" (on passe de l'image Vast de 12 Go à moins de 50 Mo, donc nettement plus rapide à déployer)
- intégrant les modifications du script de lancement de Firedfly mentionnées précédemment (gestion des caractères interdits dans le nom du "compte" F@h v8, paramètres pour positionner la cause, l'activation des projets Beta ou encore le positionnement d'une PK) 
- déportant l'intégration des runtimes CUDA adaptés à l'instance dans le script  de lancement

Testé intensivement (merci encore, EmpireHell) toute cette semaine, et fonctionnel* sur CUDA 12.8/12.9/13.0 pour toutes familles (30xx/40xx/50xx) & modèles (xx60/xx70/xx80/xx90) de RTX.

Pour ceux que ça intéresse : script de lancement et Dockerfile dispo dans mon GitHub, image Docker dans mon DockerHub

Je rappelle également que, pour les plus experts, seuls 3 "Extra filters" sont réellement indispensables (cf. guide). Les autres peuvent être supprimés ou modifiés si vous souhaitez voir plus d'instances, mais à vous de faire "les bons choix" dans la page affichant les résultats.

(*) "fonctionnel" ... jusqu'à ce que ça ne le soit plus: modif chez Vast, maj de drivers/runtime nvidia, etc... 😉

[GtevoOne82]

Hello.

Merci JWhy, ça tourne parfaitement.

Nice job.

[toTOW]

A l'inverse, si vous voyez ce type d'affichage, alors 100% du système hôte sera dédié à votre instance :


Ce critère gpu_frac positionné à 1 permet donc de ne trouver que les instances hébergées sur une machine qui vous est 100% dédiée.

Alors ça c'est pas forcément vrai !

Je me suis retrouvé plusieurs fois avec une instance montrant le même nombre de CPU alloués que le nombre de CPU de la machine qui avait de la charge CPU parasite, surtout avec beaucoup de CPUs ... il faut bien vérifier lorsqu'on démarre se type d'instance.

[JWhy]

Faut pas s'énerver comme ça 😉

Il y a quand plus de risque d'avoir une instance moins performante avec 1/8 des CPU affichés de la machine , qu'avec 100% pour ton instance ... même si -certes- il peut rester des cas de parasitage, comme tu le dis.

Et donc preneur de la méthode que tu préconises pour 

bien vérifier lorsqu'on démarre se type d'instance.

🙏

[toTOW]

Tu te connectes en Terminal Jupyter ou SSH, tu fais un top et tu vérifie que ton load average est à 0 (ou proche de 0).

[JWhy]

Il y a eu qq retours sur le discord, mais globalement ça marche comme vous voulez ?
des trucs à améliorer ?

Pour info, suite à un échange avec EmpireHell, j'avais fait un script (dispo sur le github) qui affiche dans la log vast s'il y a un pb d'heure dans le container.
c'est pas forcément indispensable, les logs standard disent assez clairement quand il y a un pb (via les mises à jour apt qui ne se font pas), mais ce script donne plus explicitement qu'il y a un pb de synchro horaire.

si ça vous intéresse de l'utiliser, il faut juste ajouter ces 3 lignes au début  de la zone texte "Bash commands that are invoked whenever your instance starts, see FAQ/Docs for details."

Code :

curl https://raw.githubusercontent.com/JWhyFR/fah-v8/main/diff_ntp.sh -o diff_ntp.sh
chmod +x diff_ntp.sh
./diff_ntp.sh

mais vraiment pas indispensable 

Exemple de "instance log" , quand ça se passe bien (l'API publique renvoie souvent des erreurs, on se croirait avec les API EDF pour l'EJP  ) 

Code :

=======================================
Vérification de l'heure système...
Heure système UTC : 1758828170
API publique : Impossible de récupérer l'heure.
Serveur NTP : synchronisé (écart de 0s).
=======================================