12 de noviembre de 2026 · Equipo de VRAMfarm

No pagues por una GPU inactiva: parada automática, tmux y detener el servidor desde código

Una RTX 4090 que se queda en marcha de 6 de la tarde a 9 de la mañana factura 15 horas: 8,85 € por una noche sin hacer nada. Con la parada automática por inactividad, el mismo descuido suele costar unas tres horas, 1,77 €, y tu carpeta /workspace se guarda antes de que se apague. Aun así, la parada automática es la red de seguridad. El ahorro de verdad sale de unos cuantos hábitos: detener el servidor entre sesiones, lanzar los trabajos nocturnos de forma que no te necesiten y dejar que el propio trabajo detenga el servidor.

Cómo funciona la parada automática por inactividad

Si nadie usa un servidor durante unas dos horas, te enviamos un mensaje: en el chat del panel y, si no estás en la web, por correo. Si sigue inactivo una hora más y su carpeta se puede guardar, el servidor guarda /workspace y se detiene. Recibes un aviso de que se ha detenido y de que tu carpeta te espera en el siguiente servidor. Si la carpeta no se puede guardar (tu propia imagen de Docker, mira más abajo), solo recibes los avisos, y el servidor sigue en marcha hasta que lo detengas. Si falla la subida, el servidor también sigue en marcha, y te lo decimos.

Qué cuenta como uso. Miramos tres señales:

• una conexión abierta con el servidor a través de nuestra dirección: SSH, Jupyter o la app (ComfyUI, el chat, vLLM);
• datos que siguen pasando por esas conexiones en la última media hora;
• carga de la GPU por encima de un pequeño porcentaje.

Basta con una de ellas para considerar que el servidor está ocupado. Un entrenamiento cuenta como carga de GPU, así que nunca se detiene mientras calcula, aunque no haya nadie conectado. Los tiempos de la tabla son aproximados. Las dos horas cuentan desde la última vez que se usó el servidor, así que tras un trabajo largo en la GPU o una sesión cerrada el aviso llega unas dos horas después, con unos diez minutos de margen.

Qué parece inactivo. Un kernel de Jupyter abierto sin ninguna pestaña del navegador y con la GPU parada. Un trabajo que solo usa la CPU, como descomprimir un archivo grande o tokenizar un dataset. Una descarga larga lanzada en el servidor sin nada conectado. Si tu trabajo tiene fases tranquilas así, pulsa Sigo trabajando cuando llegue el mensaje, deja una conexión abierta o desactiva la parada automática durante ese tiempo.

Dónde no se aplica. La parada automática solo detiene servidores cuya carpeta se puede guardar, porque detenerlos sin guardar borraría tus archivos. Eso deja fuera los servidores lanzados con tu propia imagen de Docker: su carpeta todavía no se puede guardar, así que nunca se detienen automáticamente. Recibes igualmente el mensaje de inactividad, pero detenerlos te toca a ti o a tu script, algo que explica la guía de la API para trabajos por lotes.

Desactivarla, y por qué normalmente no deberías

La opción está en Ajustes: «Detener automáticamente un servidor inactivo y guardar su carpeta». Con ella desactivada sigues recibiendo los mensajes de inactividad, como mucho cada seis horas por servidor, pero no se detiene nada.

Desactívala solo si tienes un motivo: un trabajo con horas de CPU entre pasos de GPU, o un servidor que mantienes como endpoint de pruebas al que alguien llama de vez en cuando. Para una fase tranquila puntual es mejor Sigo trabajando, que deja la red de seguridad puesta para la próxima vez.

Sin parada automática, un servidor olvidado sigue funcionando hasta que lo detengas o hasta que se te acabe el saldo. La detención con el saldo a cero no guarda nada: el disco se elimina junto con todo lo que tuvieras en él. La guía de facturación explica en detalle qué pasa cuando el saldo llega a cero.

El problema contrario: conexiones que mantienen ocupado un servidor

Como las conexiones abiertas cuentan como uso, una ventana olvidada puede mantener un servidor en marcha toda la noche igual que un servidor olvidado. Los sospechosos habituales:

• una ventana de PowerShell o de Terminal con una sesión SSH que nunca cerraste;
• una pestaña de Jupyter o ComfyUI abierta en el navegador;
• una ventana de VS Code o Cursor que sigue conectada por Remote SSH.

Desde el lado del servidor, cualquiera de ellas parece alguien trabajando. Así que, cuando termines, cierra las pestañas y la sesión o, mejor aún, detén el servidor en el momento. No esperes a que la parada automática lo haga tres horas después.

Hábitos que recortan el tiempo inactivo

Detén el servidor entre sesiones. Preparar un servidor lleva 2–5 minutos y no se factura. Un lanzamiento nuevo cuesta como mínimo 15 minutos, y una app lista para usar vuelve a descargar sus modelos, lo que sí se factura. Así que el punto de equilibrio depende de lo que ejecutes:

Una pausa para comer con una RTX 4090 en marcha te cuesta 0,59 € la hora. En una H100 a 3,90 € la hora, o en una máquina con varias GPU, esa misma hora duele bastante más.

Usa Guardar y detener, y no Detener, cuando vayas a volver. Tus LoRA, resultados, notebooks y scripts vuelven en el siguiente servidor, aunque sea con otra tarjeta. El almacenamiento cuesta 0,03 € por GB al mes. Qué se conserva y qué no lo tienes en qué pasa con tus archivos al detener una GPU.

Prepara donde sale barato. Escribir código, arreglar imports y descargar un dataset no necesitan una H100. Hazlo en tu ordenador o en una tarjeta pequeña como la RTX 3060 a 0,12 € la hora, guarda la carpeta y lanza la tarjeta grande solo cuando el trabajo esté listo para ejecutarse.

Prueba con una parte de los datos. Cinco minutos con el 1 % del dataset sacan a la luz el fallo que, si no, aparecería al cabo de una hora de la tirada completa, con la tarjeta cara esperando.

Mete la detención en el trabajo. La mejor forma de no pagar por un trabajo terminado es que el propio trabajo detenga el servidor. De eso va la última sección.

Trabajos nocturnos con tmux

Si lanzas un trabajo en una sesión SSH normal y se corta la conexión (cierras el portátil, falla el wifi, se cae la VPN), el trabajo suele morir con ella. tmux lo mantiene en marcha en el servidor, independientemente de tu conexión. Funciona igual en el terminal de Jupyter.

Comprueba si está instalado con tmux -V. Si no lo está, instálalo; se instala fuera de /workspace, así que repítelo en cada servidor nuevo:

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

Después:

tmux new -s train          # abre una sesión llamada "train"
python train.py            # lanza el trabajo dentro de ella
# pulsa Ctrl+B y luego D para salir; el trabajo sigue en marcha
tmux ls                    # más tarde, lista las sesiones
tmux attach -t train       # vuelve a ella

Sin tmux, nohup hace lo básico y escribe la salida en un archivo de log que puedes seguir:

nohup python train.py > /workspace/train.log 2>&1 &
tail -f /workspace/train.log     # Ctrl+C deja de mostrar el log, no detiene el trabajo

Dos reglas para todo lo que se ejecuta mientras duermes. Escribe checkpoints en /workspace cada 15–30 minutos, para que un fallo te cueste un intervalo y no la noche entera. Y recarga antes de empezar: si el saldo se acaba a las 3 de la madrugada, el servidor se detiene sin guardar.

Mientras el trabajo calcula, la parada automática no lo toca. Cuando termina, la GPU se queda quieta: unas dos horas después recibes el aviso, y una hora más tarde el servidor guarda su carpeta y se detiene. Esa es la red de seguridad. La siguiente sección te ahorra esas horas de inactividad.

Detén el servidor desde código cuando termine el trabajo

Cualquier servidor se puede detener con la API. Crea un token en Ajustes → Tokens de API; empieza por gf_live_ y solo se muestra una vez. Apunta el número de tu servidor en Mis servidores (el #1234 de la tarjeta). En el servidor:

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

El ; es importante: la detención se ejecuta tanto si el entrenamiento sale bien como si falla. Con &&, un fallo dejaría el servidor en marcha. "save": true sube primero /workspace y después detiene el servidor; la facturación sigue durante los pocos minutos que tarda la subida, y si la subida falla, el servidor sigue en marcha. Quítalo para detenerlo al momento, con el disco eliminado. En un servidor con tu propia imagen de Docker, save no tiene efecto y el servidor simplemente se detiene. Ejecuta toda la línea dentro de tmux para que la detención se produzca aunque te desconectes.

En Python, la misma 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()                       # tu bucle de entrenamiento
finally:
    stop_server()

Una advertencia sobre el token. Está en una máquina que pertenece a un anfitrión, así que dalo por expuesto: crea un token aparte para esto, con un nombre como «self-stop», y revócalo cuando termine el proyecto. Un token puede lanzar, listar y detener servidores, pero no puede cambiar tu contraseña ni tu clave SSH, ni crear tokens nuevos. La columna Último uso de Ajustes te muestra si un token se está usando cuando no debería.

Si prefieres que el token no pise el servidor, ejecuta la detención desde tu ordenador o desde tu CI. Un script allí lanza el servidor, espera al trabajo, copia los resultados y lo detiene. En API de GPU para trabajos por lotes tienes esa versión en curl y Python, con un tope de gasto incluido.