12 novembre 2026 · Team VRAMfarm

Non pagare una GPU inattiva: arresto automatico, tmux e stop dal codice

Una RTX 4090 lasciata accesa dalle 18 alle 9 del mattino fattura 15 ore: 8,85 € per una notte di niente. Con l’arresto automatico per inattività, lo stesso errore di solito costa circa tre ore, 1,77 €, e la tua cartella /workspace viene salvata prima dello stop. L’arresto automatico però è solo la rete di sicurezza. Il vero risparmio viene da poche abitudini: fermare il server tra una sessione e l’altra, far girare i lavori notturni in modo che non abbiano bisogno di te, e lasciare che sia il lavoro stesso a fermare il server.

Come funziona l’arresto automatico per inattività

Se nessuno usa un server per circa due ore, ti mandiamo un messaggio: nella chat della dashboard e, se non sei sul sito, via email. Se resta inattivo per un’altra ora e la sua cartella si può salvare, il server salva /workspace e si ferma. Ricevi un avviso che è stato fermato e che la tua cartella ti aspetta sul prossimo server. Se la cartella non si può salvare (una tua immagine Docker, vedi sotto) ricevi solo gli avvisi, e il server resta acceso finché non lo fermi tu. Anche se il caricamento non riesce il server resta acceso, e te lo comunichiamo.

Cosa conta come utilizzo. Guardiamo tre segnali:

• una connessione aperta al server attraverso il nostro indirizzo: SSH, Jupyter o l’app (ComfyUI, la chat, vLLM);
• dati che sono ancora passati su quelle connessioni nell’ultima mezz’ora;
• un carico sulla GPU sopra qualche punto percentuale.

Ne basta uno per considerare il server occupato. Un training conta come carico sulla GPU, quindi non viene mai fermato mentre calcola, anche se non c’è nessuno connesso. I tempi della tabella sono indicativi. Le due ore partono dall’ultimo momento in cui il server è stato usato: dopo un lungo lavoro sulla GPU o una sessione chiusa, l’avviso arriva quindi circa due ore dopo, con una decina di minuti di scarto.

Cosa sembra inattivo. Un kernel Jupyter aperto senza nessuna scheda del browser e con la GPU ferma. Un lavoro che gira solo sulla CPU, come scompattare un grosso archivio o tokenizzare un dataset. Un lungo download avviato sul server senza niente di connesso. Se il tuo lavoro ha fasi tranquille come queste, premi Ci sto ancora lavorando quando arriva il messaggio, tieni aperta una connessione, oppure disattiva l’arresto automatico per quel periodo.

Dove non si applica. L’arresto automatico ferma solo un server la cui cartella si può salvare, perché fermarlo senza salvare cancellerebbe i tuoi file. Questo esclude i server avviati da una tua immagine Docker: la loro cartella non si può ancora salvare, quindi non vengono mai fermati in automatico. Il messaggio di inattività lo ricevi comunque, ma fermarli tocca a te o al tuo script, come spiega la guida all’API per i lavori batch.

Disattivarlo, e perché di solito non conviene

L’opzione è nelle Impostazioni: “Ferma automaticamente un server inattivo e salva la sua cartella”. Se è disattivata ricevi comunque i messaggi di inattività, al massimo ogni sei ore per server, ma non viene fermato niente.

Disattivala solo se hai un motivo: un lavoro con ore di elaborazione sulla CPU tra uno step sulla GPU e l’altro, o un server che tieni come endpoint di test e che qualcuno chiama ogni tanto. Per una fase tranquilla occasionale è meglio Ci sto ancora lavorando, che lascia la rete di sicurezza al suo posto per la prossima volta.

Senza arresto automatico, un server dimenticato resta acceso finché non lo fermi o finché il credito non si esaurisce. Uno stop con il credito a zero non salva niente: il disco viene cancellato insieme a tutto quello che c’era sopra. La guida alla fatturazione spiega nel dettaglio cosa succede a credito zero.

Il problema opposto: connessioni che tengono occupato un server

Siccome le connessioni aperte contano come utilizzo, una finestra dimenticata può tenere acceso un server tutta la notte, proprio come un server dimenticato. Questi sono i soliti sospetti:

• una finestra di PowerShell o del Terminale con una sessione SSH che non hai mai chiuso;
• una scheda di Jupyter o ComfyUI rimasta aperta nel browser;
• una finestra di VS Code o Cursor ancora connessa tramite Remote SSH.

Dal lato del server, ognuna di queste sembra qualcuno al lavoro. Quindi quando hai finito chiudi le schede e la sessione o, meglio ancora, ferma subito il server. Non aspettare che lo faccia l’arresto automatico tre ore dopo.

Abitudini che riducono il tempo di inattività

Ferma tra una sessione e l’altra. Preparare un server richiede 2–5 minuti e non si paga. Un nuovo avvio costa almeno 15 minuti, e un’app pronta scarica di nuovo i suoi modelli, cosa che si paga. Quindi il punto di pareggio dipende da cosa fai girare:

Una pausa pranzo su una RTX 4090 costa 0,59 € all’ora se la lasci accesa. Su una H100 a 3,90 € all’ora, o su una macchina con più GPU, la stessa ora pesa molto di più.

Usa Salva e ferma, non Ferma, quando pensi di tornare. LoRA, output, notebook e script tornano sul prossimo server, anche su un’altra scheda. Lo storage costa 0,03 € per GB al mese. Cosa viene conservato e cosa no lo trovi in cosa succede ai tuoi file quando fermi una GPU.

Prepara dove costa poco. Scrivere codice, sistemare gli import e scaricare un dataset non richiedono una H100. Fallo sul tuo computer o su una scheda piccola come la RTX 3060 a 0,12 € all’ora, salva la cartella e avvia la scheda grande solo quando il lavoro è pronto a partire.

Prova su una fetta dei dati. Cinque minuti sull’1% del dataset ti mostrano il crash che altrimenti arriverebbe dopo un’ora di training completo, con la scheda costosa lì ad aspettare.

Metti lo stop dentro il lavoro. Il modo migliore per non pagare un lavoro già finito è fare in modo che sia il lavoro a fermare il server. Ne parla l’ultima sezione qui sotto.

Lavori notturni con tmux

Se avvii un lavoro in una normale sessione SSH e la connessione cade (coperchio del portatile, Wi-Fi, VPN), di solito il lavoro muore con lei. tmux lo tiene in esecuzione sul server, indipendentemente dalla tua connessione. Funziona allo stesso modo nel terminale di Jupyter.

Controlla se è installato con tmux -V. Se non c’è, installalo; finisce fuori da /workspace, quindi ripeti l’operazione su ogni nuovo server:

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

Poi:

tmux new -s train          # apre una sessione chiamata "train"
python train.py            # avvia il lavoro al suo interno
# premi Ctrl+B, poi D, per staccarti; il lavoro continua
tmux ls                    # più tardi, elenca le sessioni
tmux attach -t train       # torna alla sessione

Senza tmux, nohup fa il minimo indispensabile e scrive l’output in un file di log che puoi seguire:

nohup python train.py > /workspace/train.log 2>&1 &
tail -f /workspace/train.log     # Ctrl+C smette di seguire il log, non ferma il lavoro

Due regole per tutto ciò che gira mentre dormi. Scrivi i checkpoint in /workspace ogni 15–30 minuti, così un guasto ti costa un intervallo, non la notte. E ricarica il credito prima di iniziare: un credito che si esaurisce alle 3 di notte ferma il server senza salvare.

Mentre il lavoro calcola, l’arresto automatico lo lascia in pace. Quando finisce la GPU si quieta: circa due ore dopo ricevi l’avviso, e un’ora più tardi il server salva la sua cartella e si ferma. Questa è la rete di sicurezza. La prossima sezione ti fa risparmiare anche quelle ore di inattività.

Fermare il server dal codice quando il lavoro finisce

Ogni server si può fermare tramite l’API. Crea un token in Impostazioni → Token API; inizia con gf_live_ e viene mostrato una sola volta. Annota il numero del server da I miei server (il #1234 sulla scheda del server). Sul server:

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

Il ; è importante: lo stop parte sia che il training riesca sia che vada in crash. Con && al suo posto, un crash lascerebbe il server acceso. "save": true prima carica /workspace e poi ferma il server; la fatturazione continua per i pochi minuti del caricamento, e se il caricamento non riesce il server resta acceso. Toglilo per fermare subito, con il disco cancellato. Su un server avviato da una tua immagine Docker, save non ha effetto e il server si ferma e basta. Lancia l’intera riga dentro tmux, così lo stop avviene anche se ti disconnetti.

In Python, la stessa idea con 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()                       # il tuo ciclo di training
finally:
    stop_server()

Due parole sul token. Si trova su una macchina che appartiene a un host, quindi consideralo esposto: crea un token apposta, con un nome come “self-stop”, e revocalo quando il progetto finisce. Un token può avviare, elencare e fermare server, ma non può cambiare la tua password o la chiave SSH, né creare nuovi token. La colonna Ultimo utilizzo nelle Impostazioni ti mostra se un token viene usato quando non dovrebbe.

Se preferisci non tenere affatto il token sul server, lancia lo stop dal tuo computer o dalla CI. Uno script lì avvia il server, aspetta il lavoro, copia i risultati e lo ferma. La guida API GPU per i lavori batch ha quella versione in curl e Python, con un tetto di spesa già incluso.