Décimo módulo del Curso de GPU para IA. Tu arquitectura local (Módulo 9) funciona — pero tu escritorio no puede servir usuarios reales 24/7, ni cargar un 70B en FP16, ni escalar cuando algo se viraliza. Para eso se arrienda silicio ajeno. Hoy: el mapa de qué existe, cómo se cobra y cómo elegir.

La tesis del módulo

En la nube no compras una GPU: compras horas de GPU. Y el arte no está en conseguir la más grande, sino en pagar solo por la que tu modelo necesita, solo el tiempo que de verdad la usas. El patrón de tráfico decide más que el hardware.

Las dos modalidades

 ¿tu tráfico es constante o por ráfagas?
        │
   ┌────┴─────────┐
   ▼              ▼
 constante      ráfagas
 POD DEDICADO   SERVERLESS
 por hora       por segundo de uso
 siempre tuyo   escala a cero

Pod dedicado (o instancia GPU): arriendas una máquina con GPU por horas — RunPod, Lambda, Vast.ai, o las grandes (GCP, AWS, Azure). Es tuya mientras pagues: control total, precio predecible, cero cold start. La pagas también cuando nadie la usa.

Serverless GPU (Modal, RunPod Serverless y similares): subes tu código/contenedor y el proveedor levanta GPUs solo cuando llegan peticiones, cobrando por segundo de ejecución. Sin tráfico, escala a cero y pagas cero. El peaje es el cold start: levantar contenedor y cargar gigas de pesos a la VRAM toma de segundos a minutos cuando el servicio estaba frío.

La primera decisión de arquitectura en nube es esta, y es la del diagrama: tráfico constante amortiza un pod; tráfico esporádico o impredecible pide serverless.

El catálogo: qué GPU arrendar

Las protagonistas del mercado de inferencia (precios referenciales 2026, orden de magnitud — cambian rápido y varían fuerte entre proveedores; los especializados suelen ser varias veces más baratos que las nubes grandes):

GPU	VRAM	Perfil	Orden de precio/hora
T4	16 GB	La veterana barata: 7–13B cuantizado	fracciones de dólar
L4	24 GB	Su sucesora eficiente: el caballito de la inferencia media	fracciones de dólar
A10G	24 GB	Clásica del serving 7–14B	~medio dólar
A100	40/80 GB	Modelos grandes, fine-tuning, serving serio	~1–2 dólares
H100	80 GB	El estándar actual: máximo throughput, modelos grandes	~2–4 dólares
H200 / B200	141 / 180–192 GB	La generación siguiente: 70B+ en FP16, contextos enormes	por encima de la H100

Cómo leerla con los ojos del curso: la columna VRAM es la del Módulo 2. Un 8B cuantizado vive feliz en una L4; un 70B en FP16 (~140 GB) no cabe en una sola A100/H100 de 80 GB — exige dos en paralelo, una H200 de 141 GB al límite o una B200; un 70B cuantizado a 4 bits (~40 GB) pide una A100/H100 de 80 GB para respirar. La GPU se elige con la misma cuenta de siempre — solo que ahora el error se factura por hora.

Dos conceptos más del menú:

Instancias spot / interrumpibles: capacidad sobrante con gran descuento, que el proveedor puede quitarte con poco aviso. Excelentes para trabajos por lotes tolerantes a fallas (indexar, transcribir, evaluar); malas para servir usuarios.
Multi-GPU: los modelos que no caben en una tarjeta se parten entre varias (tensor parallelism — vLLM lo hace). Regla de sanidad: antes de pagar 2 GPUs, prueba si una cuantización más agresiva o un modelo menor resuelve.

Los costos que no se ven en el precio por hora

Almacenamiento: los pesos del modelo (decenas de GB) viven en un volumen que se cobra aparte — y que en serverless conviene tener cerca para acelerar el cold start.
Transferencia (egress): sacar datos de la nube cuesta; para un chat es poco, para mover datasets no.
La GPU ociosa: el costo invisible más caro. Un pod al 10% de utilización multiplica por 10 tu costo real por token. Este número protagoniza el módulo 12.

Criterios de elección, en orden

VRAM: ¿qué modelo, en qué cuantización, con cuánto contexto? (módulos 2 y 4). Esto filtra el catálogo.
Patrón de tráfico: ¿constante o ráfagas? Esto decide pod vs serverless.
Throughput objetivo: ¿cuántos usuarios simultáneos? Esto decide cuántas GPUs y confirma el runtime (módulo 7).
Presupuesto de latencia: ¿toleras cold starts de minutos? Si no, pod o serverless con keep-warm (que ya no es escala-a-cero puro: pagas la tibieza).

Errores comunes

Arrendar una H100 “para estar seguro”. Si tu modelo cabe en una L4, la H100 es dinero quemado con estilo. La cuenta de VRAM existe para esto.
Servir usuarios en spot. El descuento se paga en desconexiones. Spot es para lotes que pueden reintentar.
Elegir serverless e ignorar el cold start. El primer usuario tras una pausa espera la carga completa del modelo. O lo aceptas, o pagas keep-warm, o vuelves al pod.
Comparar proveedores solo por el precio por hora. Almacenamiento, egress y mínimos de facturación mueven el total real.

La frase para llevarse

“El escritorio te enseñó la cuenta de la VRAM; la nube le pone precio por hora. La GPU correcta es la más chica donde tu modelo cabe con margen — igual que siempre, pero ahora con boleta.”

Qué viene

Módulo 11: desplegar de verdad — tu servicio vLLM corriendo en un pod de RunPod y en serverless con Modal, con autenticación, la URL pública conectada a tus agentes, y el cold start manejado con perillas reales.

GPU para IA — Módulo 10: GPUs en la nube, el mapa completo