12 novembre 2026 · Équipe VRAMfarm

Ne payez pas un GPU inactif : arrêt automatique, tmux et arrêt depuis le code

Une RTX 4090 laissée en marche de 18 h à 9 h facture 15 heures : 8,85 € pour une nuit à ne rien faire. Avec l’arrêt automatique en cas d’inactivité, la même erreur coûte en général environ trois heures, 1,77 €, et votre dossier /workspace est enregistré au passage. L’arrêt automatique n’est pourtant qu’un filet de sécurité. Les vraies économies viennent de quelques habitudes : arrêter entre deux sessions, lancer les tâches de nuit de façon à ce qu’elles se passent de vous, et laisser la tâche arrêter elle-même le serveur.

Comment fonctionne l’arrêt automatique en cas d’inactivité

Un serveur que personne n’utilise pendant environ deux heures reçoit un message de notre part : dans le chat du tableau de bord et, si vous n’êtes pas sur le site, par e-mail. S’il reste inactif une heure de plus et que son dossier peut être enregistré, le serveur enregistre /workspace et s’arrête. Vous êtes prévenu qu’il a été arrêté et que votre dossier attend le prochain serveur. Si le dossier ne peut pas être enregistré (votre propre image Docker, voir plus bas), vous ne recevez que les avertissements, et le serveur tourne jusqu’à ce que vous l’arrêtiez. Si un envoi échoue, le serveur reste lui aussi en marche, et vous en êtes informé.

Ce qui compte comme une utilisation. Nous regardons trois signaux :

• une connexion ouverte au serveur via notre adresse : SSH, Jupyter ou l’application (ComfyUI, le chat, vLLM) ;
• des données qui circulent encore sur ces connexions au cours de la dernière demi-heure ;
• une charge GPU supérieure à quelques pour cent.

Un seul suffit pour considérer le serveur comme occupé. Un entraînement compte comme charge GPU : il n’est donc jamais arrêté tant qu’il calcule, même sans personne de connecté. Les durées du tableau sont approximatives. Les deux heures comptent à partir du dernier moment où le serveur a été utilisé : après une longue tâche GPU ou une session fermée, l’avertissement arrive donc environ deux heures plus tard, à dix minutes près.

Ce qui paraît inactif. Un noyau Jupyter ouvert sans onglet de navigateur et avec un GPU au repos. Une tâche qui ne tourne que sur le CPU, comme décompresser une grosse archive ou tokeniser un jeu de données. Un long téléchargement lancé sur le serveur sans rien de connecté. Si votre travail comporte des phases calmes de ce genre, appuyez sur Je travaille encore à l’arrivée du message, gardez une connexion ouverte, ou désactivez l’arrêt automatique pour cette période.

Là où il ne s’applique pas. L’arrêt automatique n’arrête qu’un serveur dont le dossier peut être enregistré, car arrêter sans enregistrer supprimerait vos fichiers. Cela exclut les serveurs démarrés depuis votre propre image Docker : leur dossier ne peut pas encore être enregistré, ils ne sont donc jamais arrêtés automatiquement. Vous recevez quand même le message d’inactivité, mais les arrêter relève de vous ou de votre script, ce que traite le guide de l’API pour les tâches par lots.

Le désactiver, et pourquoi il vaut mieux s’en abstenir

L’option se trouve dans les Paramètres : « Arrêter automatiquement un serveur inactif et enregistrer son dossier ». Une fois désactivée, vous recevez toujours les messages d’inactivité, au plus toutes les six heures par serveur, mais rien n’est arrêté.

Ne la désactivez que si vous avez une raison : une tâche avec des heures de travail CPU entre deux étapes GPU, ou un serveur gardé comme point de terminaison de test que des gens appellent de temps en temps. Une phase calme ponctuelle se gère mieux avec Je travaille encore, qui laisse le filet de sécurité en place pour la fois suivante.

Sans arrêt automatique, un serveur oublié tourne jusqu’à ce que vous l’arrêtiez ou que votre solde soit épuisé. Un arrêt à solde nul n’enregistre rien : le disque est supprimé avec tout ce qu’il contenait. Le guide de la facturation détaille ce qui se passe à zéro.

Le problème inverse : des connexions qui maintiennent un serveur occupé

Comme les connexions ouvertes comptent comme une utilisation, une fenêtre oubliée peut faire tourner un serveur toute la nuit aussi sûrement qu’un serveur oublié. Les suspects habituels :

• une fenêtre PowerShell ou Terminal avec une session SSH jamais fermée ;
• un onglet Jupyter ou ComfyUI resté ouvert dans le navigateur ;
• une fenêtre VS Code ou Cursor toujours connectée via Remote SSH.

Du point de vue du serveur, chacune ressemble à quelqu’un qui travaille. Quand vous avez fini, fermez donc les onglets et la session, ou mieux, arrêtez le serveur tout de suite. N’attendez pas que l’arrêt automatique s’en charge trois heures plus tard.

Les habitudes qui réduisent le temps d’inactivité

Arrêtez entre deux sessions. La préparation d’un serveur prend 2 à 5 minutes et n’est pas facturée. Un nouveau lancement coûte au moins 15 minutes, et une application prête à l’emploi retélécharge ses modèles, ce qui est facturé. Le seuil de rentabilité dépend donc de ce que vous faites tourner :

Une pause déjeuner sur une RTX 4090 coûte 0,59 € de l’heure si vous la laissez tourner. Sur une H100 à 3,90 € de l’heure, ou sur une machine multi-GPU, la même heure fait bien plus mal.

Utilisez Enregistrer et arrêter, pas Arrêter, si vous revenez. Vos LoRA, résultats, notebooks et scripts reviennent sur le prochain serveur, même sur une autre carte. Le stockage coûte 0,03 € par Go et par mois. Ce qui est conservé ou non est détaillé dans ce que deviennent vos fichiers quand vous arrêtez un GPU.

Préparez là où c’est bon marché. Écrire du code, corriger des imports et télécharger un jeu de données ne demandent pas une H100. Faites-le sur votre ordinateur ou sur une petite carte comme la RTX 3060 à 0,12 € de l’heure, enregistrez le dossier, et ne lancez la grosse carte que lorsque la tâche est prête à tourner.

Testez sur un extrait des données. Cinq minutes sur 1 % du jeu de données révèlent le plantage qui, sinon, apparaîtrait au bout d’une heure de l’exécution complète, pendant que la carte chère attend.

Mettez l’arrêt dans la tâche. Le meilleur moyen de ne pas payer une tâche terminée, c’est que la tâche arrête le serveur. C’est l’objet de la dernière section.

Les tâches de nuit avec tmux

Si vous lancez une tâche dans une session SSH normale et que la connexion tombe (écran du portable rabattu, Wi-Fi, VPN), la tâche meurt généralement avec elle. tmux la fait tourner sur le serveur, indépendamment de votre connexion. Cela fonctionne de la même façon dans le terminal Jupyter.

Vérifiez s’il est installé avec tmux -V. Sinon, installez-le ; il s’installe en dehors de /workspace, donc répétez l’opération sur chaque nouveau serveur :

apt-get update && apt-get install -y tmux

Ensuite :

tmux new -s train          # ouvre une session nommée "train"
python train.py            # lance la tâche dedans
# appuyez sur Ctrl+B, puis D, pour vous détacher ; la tâche continue
tmux ls                    # liste les sessions plus tard
tmux attach -t train       # pour y revenir

Sans tmux, nohup fait l’essentiel et écrit la sortie dans un fichier journal que vous pouvez suivre :

nohup python train.py > /workspace/train.log 2>&1 &
tail -f /workspace/train.log     # Ctrl+C arrête l'affichage, pas la tâche

Deux règles pour tout ce qui tourne pendant votre sommeil. Écrivez des checkpoints dans /workspace toutes les 15 à 30 minutes, pour qu’une panne coûte un intervalle et non la nuit. Et rechargez avant de commencer : un solde épuisé à 3 h du matin arrête le serveur sans enregistrer.

Tant que la tâche calcule, l’arrêt automatique la laisse tranquille. Quand elle se termine, le GPU se calme : environ deux heures plus tard, vous recevez l’avertissement, et une heure après, le serveur enregistre son dossier et s’arrête. C’est le filet de sécurité. La section suivante vous fait économiser ces heures d’inactivité.

Arrêter le serveur depuis le code à la fin de la tâche

Chaque serveur peut être arrêté via l’API. Créez un token dans Paramètres → Tokens API ; il commence par gf_live_ et n’est affiché qu’une fois. Notez le numéro de votre serveur dans Mes serveurs (le #1234 sur la carte du serveur). Sur le serveur :

export GF_TOKEN=gf_live_xxxxxxxxxxxxxxxx
export GF_ID=1234

python train.py; curl -s https://vramfarm.com/api/instances/stop \
  -H "Authorization: Bearer $GF_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"id\": $GF_ID, \"save\": true}"

Le ; compte : l’arrêt s’exécute que l’entraînement réussisse ou plante. Avec && à la place, un plantage laisserait le serveur en marche. "save": true envoie d’abord /workspace puis arrête le serveur ; la facturation continue pendant les quelques minutes de l’envoi, et si l’envoi échoue, le serveur reste en marche. Retirez-le pour arrêter immédiatement, disque supprimé. Sur un serveur lancé depuis votre propre image Docker, save n’a aucun effet et le serveur s’arrête simplement. Lancez toute la ligne dans tmux pour que l’arrêt ait lieu même si vous vous déconnectez.

En Python, la même idée avec try/finally :

import os, requests

def stop_server(save=True):
    requests.post("https://vramfarm.com/api/instances/stop",
                  headers={"Authorization": f"Bearer {os.environ['GF_TOKEN']}"},
                  json={"id": int(os.environ["GF_ID"]), "save": save}, timeout=30)

try:
    train()                       # votre boucle d'entraînement
finally:
    stop_server()

Un mot sur le token. Il se trouve sur une machine qui appartient à un hôte : considérez-le comme exposé. Créez un token dédié, avec un nom comme « self-stop », et révoquez-le à la fin du projet. Un token peut lancer, lister et arrêter des serveurs, mais il ne peut pas changer votre mot de passe ou votre clé SSH, ni créer de nouveaux tokens. La colonne Dernière utilisation des Paramètres montre si un token est utilisé alors qu’il ne devrait pas l’être.

Si vous préférez ne pas mettre le token sur le serveur du tout, lancez l’arrêt depuis votre ordinateur ou votre CI. Un script y lance le serveur, attend la fin de la tâche, copie les résultats et l’arrête. L’API GPU pour les tâches par lots en donne la version en curl et en Python, avec un plafond de dépenses intégré.