ClodeiCLODEI
22 de abril de 2026 · 4 min de lectura

De registro a modelo corriendo en 60 segundos: walkthrough Clodei

Lo que pasa entre pulsar 'Lanzar GPU' y tu primera inferencia. Un click a click literal de Clodei, con tiempos.

Muchos flujos de alquiler de GPU en 2026 siguen siendo procesos de 30 minutos. Eliges región, pides subida de cuota, esperas aprobación, configuras red, depuras la SSH key, y al final abres JupyterLab. El nuestro lo medimos en 60 segundos extremo a extremo y queremos que siga así. Este es el click a click literal.

Qué incluye "60 segundos"

Medimos desde que pulsas Lanzar una GPU en la home hasta que JupyterLab carga en tu navegador, con cuenta nueva. Eso cubre:

  • Crear cuenta.
  • Verificar email.
  • Elegir plan.
  • Provisionar el contenedor GPU.
  • Propagar DNS del hostname por instancia.
  • Handshake del túnel Cloudflare.
  • Traefik enrutando al contenedor.
  • JupyterLab sirviendo su primera página.

Aproximadamente la mitad es provisioning. La otra mitad son handshakes de red y arranque de JupyterLab.

Paso 1: Registro (~10 segundos)

Pulsa Lanzar una GPU en la landing. Vas directo a un formulario de un solo paso: email y contraseña. Sin tamaño de empresa. Sin "selecciona tu rol". Sin checkboxes de marketing.

Recibes un magic link. El enlace verifica el email y te identifica a la vez. No hay paso "iniciar sesión" aparte.

Paso 2: Elige plan (~10 segundos)

Aterrizas en /plans con los cuatro tiers estándar visibles:

  • S (24 GB VRAM): 0,39 €/h. Modelos pequeños, fine-tunes cortos.
  • M (48 GB VRAM): 0,64 €/h. Clase 7B–13B.
  • L (80 GB VRAM): 1,73 €/h. Tier A100 80GB.
  • XL (141 GB VRAM): 3,46 €/h. Territorio H200.

La tarjeta muestra el precio por hora, la clase de GPU y la carga recomendada. No hay paso "configurar región". Clodei es solo UE, así que la región es implícita.

Eliges un plan y pulsas Lanzar.

Paso 3: Provisioning (~25 segundos)

Lo que pasa en el backend:

  1. El plano de control reserva capacidad en un nodo con la GPU adecuada disponible. Si no hay capacidad, la API responde 409 Conflict al instante. No se crea una instancia placeholder que luego pase a failed. (Es uno de los contratos internos que no doblamos.)
  2. El node agent recibe el comando, descarga la imagen Docker (cacheada en la mayoría de nodos), y arranca el contenedor con GPU passthrough.
  3. JupyterLab y SSHd arrancan dentro.
  4. El nodo abre un túnel Cloudflare para i-<instance-id>.clodei.com.
  5. Traefik en el nodo acepta la regla de routing para /i/<instance-id>.

Paso 4: Abrir JupyterLab (~15 segundos)

El dashboard hace polling sobre la instancia hasta que el ingress está sano. En cuanto el handshake del túnel completa, se activa el botón Abrir JupyterLab. Pulsas, abre pestaña nueva, carga.

Ya estás dentro. Desde aquí puedes:

  • Abrir un notebook e importar torch.
  • Usar el CLI clodei que viene preinstalado.
  • Conectar por SSH a ssh-i-<id>.clodei.com con la clave que registraste (para flujos sin Jupyter).

El contenedor es tuyo hasta que lo pares. Con facturación por minuto, dejarlo cinco minutos extra mientras hablas con un compañero cuesta unos 0,04 € en Plan S. Es el tipo de margen para el que no tienes que diseñar la arquitectura.

Lo que no te pedimos

Lista corta de cosas que los hyperscalers te hacen hacer y nosotros no:

  • Tickets de subida de cuota. Los lanzamientos no están detrás de tickets de soporte. El único límite es tu wallet.
  • Selección de región. EU-West por defecto. Si añadimos regiones, serán opt-in.
  • Configurar VPC, subnet o security groups. La instancia es accesible por el túnel Cloudflare. Nada más expuesto. Sin NACLs que depurar.
  • Roles IAM para storage. El object storage compatible con S3 se provisiona con la instancia y se accede por env vars.
  • Elegir instance type por código SKU. Los planes son S, M, L y XL. La GPU subyacente está en la tarjeta del plan.

Cuantas menos decisiones tomas al lanzar, más rápido lanzas.

Qué pasa de verdad en el nodo

Para los de infra curiosos, esto hace el node agent, en corto:

  1. Recibe un descriptor de trabajo del control plane (imagen, modo GPU, env, clase de red).
  2. Pre-flight de dos gates: runtime GPU sano, ingress alcanzable. Si alguno falla, el lanzamiento falla con un código accionable (gpu_runtime_unavailable, ingress_unavailable, corporate_network_restriction).
  3. Ejecuta docker run con --gpus, la imagen del cliente, env vars y la red correcta.
  4. Hace health-probe contra :8888 (Jupyter) y :22 (SSH).
  5. Avisa al control plane: estado running.

La máquina de estados es provisioning → pending → running → stopping → terminated|failed. Es determinista. No hay sitio donde una instancia se evapore en "unknown".

Por qué nos importan los 60 segundos

La latencia de cold-start en una experiencia de desarrollador compone. Si lanzar una GPU es un proyecto de 30 minutos, lanzas una a la semana y la tratas como recurso escaso. Si son 60 segundos, lanzas una para cada café y la paras al volver. El comportamiento alrededor de la plataforma cambia, y la factura también (más barata, sorprendentemente, porque dejas de tener GPUs corriendo "por si acaso").

Esa es la intención. Pruébalo. Mira si los 60 segundos se cumplen para ti. Dinos dónde no.