Skip to content

English · Español

Lab 00 — Aprovisionar una GPU en la nube de extremo a extremo

Objetivo: alquilar una GPU, entrar por SSH, ejecutar nvidia-smi, correr un benchmark cuBLAS de una sola línea, terminar la instancia, todo en menos de 30 minutos. Documentar el flujo de trabajo que usarán todos los labs posteriores.

Tiempo estimado: 30–60 minutos (primera vez), 5 minutos (a partir de entonces).

Prerrequisito: decisión de plataforma cloud resuelta según PHASE_23_PLAN.md §7.a. Cuenta creada en el proveedor elegido. Método de pago registrado. Tope de presupuesto configurado.


Lo que produces

Un directorio experiments/23-provisioning/ que contiene:

  • provisioning_log.md — paso a paso de lo que hiciste, con timestamps. La receta del Borja-del-futuro.
  • nvidia-smi.txt — salida capturada de nvidia-smi desde tu instancia alquilada.
  • cublas_smoke_test.json — salida de un benchmark de una línea "esto funciona".
  • cost_log.md — hora de inicio, hora de parada, tarifa por hora, coste total.
  • manifest.json.

TODOs

Bloque A — pre-vuelo (5 min)

  • Confirma PHASE_23_PLAN.md §7.a resuelto. Abre la consola del proveedor elegido.
  • Si usas proveedor basado en SSH (RunPod / Vast / Lambda): genera una clave SSH local si no tienes (ssh-keygen -t ed25519 -C "lynx-cortex-phase23"). Sube la clave pública al proveedor. No commitees la clave privada.
  • Configura una alerta de facturación / tope de gasto en tu presupuesto mensual según learners/borja/profile.md (€50–80). La mayoría de proveedores lo soportan.

Bloque B — lanzar (5 min)

  • Elige la GPU razonable más pequeña. Para la Fase 23, una RTX 3090 (24 GB) o A10 (24 GB) sobra. Spot pricing si está disponible.
  • Elige la región razonable más cercana (menor latencia hacia ti; Borja está en España — preferir EU).
  • Usa una plantilla "CUDA pre-instalado Ubuntu 22.04". La mayoría de proveedores la tienen. No instales drivers tú mismo.
  • Lanza. Anota la hora de inicio en cost_log.md.

Bloque C — conectar (5 min)

  • Entra por SSH. Confirma: lsb_release -a (Ubuntu 22.04), nvidia-smi (driver + GPU detectada).
  • Pipea la salida de nvidia-smi a nvidia-smi.txt, scp de vuelta a tu máquina.
  • git clone git@github.com:borjatarraso/lynx-cortex.git en la instancia. El repo es privado por A16, así que autentica con una deploy key (solo lectura basta para la Fase 23) o un PAT de corta vida — sin clones HTTPS anónimos.
  • cd lynx-cortex && uv sync — instala las dependencias del proyecto en la instancia. (uv debe estar instalado: curl -LsSf https://astral.sh/uv/install.sh | sh.)

Bloque D — smoke test (5 min)

  • Corre un cuBLAS GEMM de una línea vía cupy (o PyTorch — ver Plan §7.g; para la Fase 23 usamos cupy):
    import cupy as cp, time
    A = cp.random.randn(4096, 4096, dtype=cp.float16)
    B = cp.random.randn(4096, 4096, dtype=cp.float16)
    cp.cuda.runtime.deviceSynchronize()
    t0 = time.perf_counter()
    for _ in range(100):
        C = A @ B
    cp.cuda.runtime.deviceSynchronize()
    t1 = time.perf_counter()
    flops = 2 * 4096**3 * 100 / (t1 - t0)
    print(f"{flops / 1e12:.1f} TFLOPS fp16")
    
  • Guarda el resultado en cublas_smoke_test.json con {tflops_measured, gpu_name, dtype, matrix_size, iters}.
  • Confirma: el número debería estar al 30–80% del pico del fabricante para fp16 en la GPU alquilada. Si es <10%, algo va mal — comprueba en nvidia-smi el modo "default" (vs particionado MIG), comprueba la versión de CUDA frente a tu build de cupy.

Bloque E — terminar (2 min — no te lo saltes)

  • git add -A && git commit -m "phase: 23 provisioning smoke test" desde la instancia. Push.
  • Anota la hora de parada en cost_log.md. Calcula coste total = (parada - inicio) × tarifa_por_hora. Apúntalo.
  • Termina la instancia desde la consola del proveedor. Confirma en la consola que ya no está (no "parada" — terminada; las instancias paradas en algunos proveedores siguen facturando el almacenamiento).
  • Verifica tu gasto en el dashboard del proveedor.

Bloque F — escribir la receta (10 min)

En provisioning_log.md, escribe una receta para el Borja-del-futuro con:

  • Comandos exactos que ejecutaste (copiar-pegables).
  • Cualquier cosa que te sorprendiera (por ejemplo, "la instancia spot me la reclamaron una vez, tuve que relanzar").
  • La tarifa exacta por hora que conseguiste (spot vs on-demand).
  • Una estimación de "tiempo-desde-decisión-hasta-benchmark-corriendo" — esto es lo que ahorrarás en sesiones futuras.

Bloque G — manifest

manifest.json:

{
  "experiment": "23-provisioning",
  "date": "YYYY-MM-DD",
  "cloud_provider": "<runpod | lambda | vast | colab | other>",
  "region": "<eu-west | us-east | ...>",
  "gpu_name": "<RTX 3090 | A10 | A100 | ...>",
  "gpu_vram_gib": null,
  "pricing_model": "<spot | on-demand>",
  "hourly_rate_usd": null,
  "session_minutes": null,
  "total_cost_usd": null,
  "cuda_version": null,
  "driver_version": null,
  "ubuntu_version": "22.04",
  "smoke_test_tflops_fp16": null,
  "smoke_test_fraction_of_peak": null
}

Restricciones

  • No instales drivers tú mismo. Usa la imagen del proveedor con CUDA pre-instalado.
  • No commitees claves privadas SSH, tokens de API ni credenciales de proveedor. .gitignore debería cubrir ya ~/.ssh, .env, etc.
  • No te saltes la terminación. Una instancia olvidada es un error de $50–500/día.
  • No corras trabajos de entrenamiento en la Fase 23. Esta fase es solo medición. Cualquier cosa que tarde >5 minutos es sospechosa — revísala y para.

Condiciones de parada

Listo cuando:

  1. Los seis archivos de salida commiteados en experiments/23-provisioning/.
  2. La instancia está terminada (confirmado en el dashboard).
  3. El cost log muestra el gasto real de esta sesión.
  4. Los TFLOPS del smoke test están en el rango 30–80% del pico.
  5. manifest.json completo.

Trampas

  • "Parada" vs "terminada". Parar una instancia de RunPod o Vast te sigue facturando el almacenamiento. Termina.
  • Desajuste de versión CUDA / cupy. Si cupy-cuda12x está instalado pero la imagen tiene CUDA 11.8, los imports fallan. Instala el build de cupy que case: pip install cupy-cuda11x o cupy-cuda12x casando con CUDA de la imagen.
  • nvidia-smi muestra la GPU pero los lanzamientos de kernel fallan. Problema de permisos; asegúrate de que tu usuario pueda acceder a /dev/nvidia*. La plantilla CUDA Ubuntu lo gestiona, pero AMIs personalizadas pueden no.
  • Instancia spot reclamada a media sesión. Pierdes el shell. Relanza y re-ejecuta. Documéntalo si ocurre.
  • El primer cudaMemcpy es 100× más lento que el estado estacionario. Overhead de inicialización de contexto. No cronometres la primera iteración.

Cuándo consultar solutions/

Tras cumplir todas las condiciones de parada. La referencia en solutions/00-provision-cloud-gpu-ref.md (escrita al abrir la fase) muestra los comandos exactos que usó la implementación de referencia en RunPod con una A10, más el desglose de coste.


Siguiente lab: lab/01-device-query.md.