Despliega un LLM en GPU serverless: 5 plataformas, precios reales y cold starts sin maquillaje

Despliega un LLM en GPU serverless: 5 plataformas, precios reales y cold starts sin maquillaje

RunPod cobra $2,72/hora por una A100 80GB. Tu endpoint recibe doce peticiones antes del mediodía. Esa GPU se queda ociosa las otras 23 horas, facturando todo el tiempo. Despliega un LLM en GPU serverless y pagas solo mientras se procesa una petición. Cinco plataformas hacen esto. Facturan en cinco unidades distintas. Nadie las normaliza.

Una GPU ociosa cuesta exactamente lo mismo que una ocupada.

Puntos clave

• La GPU serverless solo factura mientras se ejecuta una petición y se escala a cero entre ellas.
• Una GPU por instancia en Cloud Run; los modelos 70B necesitan varias GPUs, así que serverless normalmente no puede alojarlos.
• Los pesos del modelo viven en la imagen, en un volumen de red, o se vuelven a descargar en cada cold start.
• El cold start son tres cosas: arranque del contenedor, carga de pesos, inicio del motor. Solo la primera es rápida.
• Por debajo de unas 47.000 peticiones al día, el escalado a cero gana a una GPU alquilada 24/7.

¿Qué significa realmente "GPU serverless" para un LLM?

Una plataforma de GPU serverless ejecuta tu contenedor de inferencia sobre hardware GPU compartido, lo arranca cuando llega una petición y escala a cero cuando el tráfico se detiene. Pagas por segundo (o por minuto, o por hora, según el proveedor) solo mientras el contenedor está activo. Sin factura por inactividad. Sin instancia reservada.

La unidad de facturación varía según el proveedor, por eso la siguiente sección normaliza todo a $/GPU-hora.

Dos restricciones sorprenden. Primero, Google Cloud Run permite una GPU por instancia como máximo. Eso limita tu techo de VRAM a una sola tarjeta. Segundo, "serverless" no significa estado persistente. No hay un proceso de larga vida que mantenga tus pesos en RAM entre peticiones. Cuando el contenedor muere, todo lo que hay en memoria muere con él. Ese único hecho impulsa la decisión de almacenamiento en la sección de pesos del modelo más abajo.

Serverless no significa sin servidor. Significa sin servidor entre tus peticiones, y ahí es exactamente donde desaparecen los pesos de tu modelo.

¿Qué plataforma de GPU serverless deberías elegir? (Precios 2026, lado a lado)

No vendemos ninguna de estas plataformas y no recibimos ingresos de afiliados de ninguna. De los siete artículos que compiten por esta consulta y sus variantes cercanas, cuatro los publica una empresa que vende GPU serverless. Esta tabla no.

Todas las tarifas leídas de las propias páginas de precios de los proveedores el 30-07-2026. Las tarifas cambian; vuelve a comprobar antes de comprometerte.

La aritmética de normalización, mostrada una vez para que puedas auditarla: Modal A100 80GB a $0,000694/s multiplicado por 3600 segundos equivale a $2,4984/h. Beam: $0,000625 por 3600 equivale a $2,25/h. Baseten: $0,06667/min por 60 equivale a $4,00/h. Esa diferencia de 1,8x entre Beam y Baseten para la misma A100 es real, y se esconde a simple vista porque nadie publica la misma unidad.

Tres advertencias. La página de precios de Beam declara explícitamente que no factura por arranque del servidor ni por carga de imagen del contenedor. La FAQ de precios de Baseten responde a "¿Pago por tiempo de inactividad en Baseten?" con "No, no pagas por tiempo de inactividad", y luego añade que el tiempo facturable es "el tiempo que tu modelo está activamente desplegándose, escalando arriba o abajo, o haciendo predicciones", así que el contador cubre más que el tiempo de predicción, que es la parte que conviene presupuestar. RunPod publica tarifas por hora y ninguna cifra de cold start en su página de precios.

Si Modal es tu elección, hemos escrito la guía completa de Modal por separado.

¿Tu modelo siquiera cabe? VRAM, límites de una GPU y cuota

¿Puedes ejecutar un modelo 70B en una GPU serverless? Normalmente no. En FP16, 70B necesita ~140 GB de VRAM. Cloud Run limita a una GPU por instancia (96 GB máx. en RTX PRO 6000). Las cuentas no cuadran sin cuantización (FP8/GGUF) o una plataforma multi-GPU.

La cuota por defecto de Cloud Run es de 3 GPUs L4 por región por proyecto (RTX PRO 6000 se concede por separado, como 3.000 milliGPU), en seis regiones L4: asia-southeast1, asia-south1, europe-west1, europe-west4, us-central1, us-east4. Esa es la mitad de Cloud Run en la respuesta sobre residencia de datos para quien pregunte por GPU serverless en Europa; Modal y RunPod documentan sus propias regiones EU, y la FAQ tiene el resto.

El tutorial de Cloud Run de Ismaili Simba en dev.to (abril 2025) reporta que la solicitud de cuota "puede tardar un tiempo (hasta 5 días laborables) en ser aprobada", y que "las GPUs L4 disponibles en Cloud Run tienen un límite de 16GB de RAM." Planifica ese retraso.

Para dimensionar VRAM modelo por modelo, consulta nuestra guía de requisitos de VRAM.

¿Dónde viven los pesos de tu modelo (y cuánto cuesta eso)?

Un hilo de Reddit de noviembre 2024 que seguía en el puesto 5 de Google para esta misma consulta cuando comprobamos el 30-07-2026 pregunta, textualmente:

"No he podido encontrar la tarifa por almacenar el modelo de 80 gb… ¿Cuál es la alternativa si no quiero descargar el modelo en cada llamada a la api (pod aprovisionado en la llamada y luego cerrado)? … ¿Por qué estas plataformas no publican el coste de almacenamiento del modelo?"

Tres respuestas con poca puntuación, ninguna es una respuesta. Cuando hicimos esta búsqueda el 30-07-2026, los diez primeros resultados aún incluían ese hilo de dos años preguntando cuánto cuesta el almacenamiento del modelo. Nadie en el hilo lo respondió. Ambas plataformas publican la tarifa. En Modal es $0,09 por GiB al mes con el primer TiB gratis, así que ese checkpoint de 80 GB factura $0,00. En RunPod es $0,07 por GB al mes para almacenamiento de red por debajo de 1 TB, lo que pone el mismo checkpoint en unos $5,60 al mes.

La tercera fila es el modo de fallo. Una revisión de 2024 de la TU München sobre ServerlessLLM (arXiv 2411.15664) reporta que LLaMA-2-70B (130 GB) necesita más de 26 segundos para descargarse a 5 GB/s, más ~84 segundos para cargarse en 8 GPUs, frente a ~100 ms de generación de tokens. Esas cifras se citan en esa revisión, no se miden en ella.

La página de precios de RunPod tiene una sección de Storage: disco de contenedor $0,10/GB/mes, disco de volumen $0,10/GB/mes en ejecución y $0,20/GB/mes en reposo, almacenamiento de red $0,07/GB/mes bajo 1 TB y $0,05/GB/mes por encima, almacenamiento de red de alto rendimiento $0,14/GB/mes. El número existe. Solo que no está junto a las tarifas serverless por GPU que un lector está comparando cuando le surge la pregunta, ni en el flujo de configuración del endpoint. Un problema de encontrabilidad, no de secretismo, y suficiente para mantener viva la pregunta dos años después.

# Point the Hugging Face cache at a mounted network volume
# so weights persist across cold starts (RunPod / Modal pattern)
export HF_HOME=/workspace/hf-cache
export TRANSFORMERS_CACHE=/workspace/hf-cache
export HF_HUB_ENABLE_HF_TRANSFER=1

# Alternative: bake weights into the image at build time
FROM vllm/vllm-openai:latest
COPY ./model-weights /models/qwen3-27b-fp8
ENV MODEL_NAME=/models/qwen3-27b-fp8
# Downside: 30+ GB image, full rebuild to change models

Si aún no has elegido modelo, nuestro resumen de modelos abiertos 2026 dimensiona cada opción para despliegue.

Despliégalo: vLLM en RunPod Serverless, de principio a fin

Seis pasos desde cero hasta un endpoint invocable. Verifica cada uno con el procedimiento de vLLM de RunPod (actualizado el 22 jun 2026), que no publica precios.

1. Elige tu modelo. Escoge un modelo de pesos abiertos dimensionado para tu GPU (mira la tabla de VRAM de arriba). Si está restringido en Hugging Face, genera un token de acceso primero.

2. Crea el endpoint serverless. En la consola de RunPod, selecciona Serverless, elige la plantilla de worker vLLM y escoge tu nivel de GPU.

3. Configura las variables de entorno que importan.

MODEL_NAME=Qwen/Qwen3.6-27B-FP8
MAX_MODEL_LEN=32768
GPU_MEMORY_UTILIZATION=0.90
DTYPE=auto

MODEL_NAME equivocado significa un 404 en el arranque. MAX_MODEL_LEN demasiado alto para tu VRAM significa OOM antes del primer token. GPU_MEMORY_UTILIZATION por encima de 0,95 no deja margen para picos de KV-cache.

1. Configura workers mín./máx. y timeout de inactividad. Workers mínimos en 0 te da escalado a cero (y cold starts). Workers mínimos en 1 elimina cold starts pero factura continuamente. La sección de cold start de abajo trabaja ese compromiso.

2. Adjunta el volumen de red que decidiste en la sección de pesos del modelo, o acepta la ruta de hornear en la imagen. Si te saltas esto, cada cold start vuelve a descargar el checkpoint.

3. Lanza la primera petición. Lee el ID del endpoint en la consola y confirma que vuelven tokens.

curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
  -H "Authorization: Bearer ${RUNPOD_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "input": {
      "messages": [{"role": "user", "content": "Explain cold starts in one sentence."}],
      "max_tokens": 60
    }
  }'

Si estás evaluando el motor de serving en sí, comparamos vLLM y SGLang en throughput y latencia.

¿Cómo llamas al endpoint desde tu app?

Todas las plataformas de la lista hablan una API compatible con OpenAI. Un snippet de Python funciona en todas. Cambiar de proveedor es un cambio de base_url, no una reescritura. Eso replantea "qué proveedor" de una decisión de lock-in a una decisión de configuración.

import os

from openai import OpenAI

ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

client = OpenAI(
    base_url=f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    api_key=os.environ["RUNPOD_API_KEY"],
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.6-27B-FP8",
    messages=[{"role": "user", "content": "What is scale to zero?"}],
    max_tokens=120,
)
print(response.choices[0].message.content)

# Same code, different provider. One line changes.
ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

PROVIDERS = {
    "runpod": f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    "modal": "https://your-app--your-func.modal.run/v1",
    "beam": "https://your-beam-endpoint/v1",
}

client = OpenAI(base_url=PROVIDERS["modal"], api_key="your-key")

Si todos los proveedores hablan el dialecto de OpenAI, "qué proveedor de GPU serverless" deja de ser una decisión de arquitectura y se convierte en una línea de configuración.

Una vez que tienes varios endpoints, nuestra comparativa de gateways LLM cubre enrutamiento y failover. Para una configuración más ligera, un proxy LiteLLM añade reintentos y logging.

¿Qué cold start vas a ver realmente?

Para un modelo 7B en GPU serverless, espera de 10 a 30 segundos en un cold start real (arranque del contenedor más carga de pesos más inicio del motor), según reportes de practitioners. La documentación de proveedores cita de 1 a 5 segundos solo para el arranque del contenedor. La brecha entre esos números es tu checkpoint cruzando una red.

La página de producto de RunPod afirma cold starts FlashBoot por debajo de 200ms (una afirmación del proveedor, no una medición). Un practitioner en r/LLMDevs reporta: "los cold starts en mi experiencia no son geniales … yo diría ~ 10 - 30 s", añadiendo "aunque la mayor parte de mi experiencia gira en torno a modelos de difusión." Ambos son ciertos. Miden cosas distintas.

El número de cold start son tres números apilados:

1. Arranque del contenedor. Documentación de Modal: "Los contenedores arrancan en aproximadamente un segundo." Cloud Run: instancias con drivers preinstalados "arrancan en aproximadamente 5 segundos."

2. Carga de pesos. La parte que nadie anuncia. Una revisión de 2024 de la TU München sobre ServerlessLLM (arXiv 2411.15664) sitúa LLaMA-2-70B en más de 26 segundos de descarga más ~84 segundos de carga en 8 GPUs.

3. Inicio del motor. Captura de grafo y warm-up de vLLM. Logesh Umapathi midió Qwen3.6-27B-FP8 en una A100-80GB pasando de 460s de base a 219s con modo eager a ~70s con modo sleep de vLLM más snapshots de GPU de Modal. Eso es 6,5x, publicado el 17 de mayo de 2026.

Nuestra interpretación de los datos publicados: las cifras de proveedores miden el contenedor. Las cifras de practitioners miden la petición completa. Entre esos dos cronómetros hay 80 GB de pesos cruzando una red. La columna Tipo es el punto.

Qué hacer: modo sleep de vLLM, snapshots de GPU y ajustar la ventana de escalado. La inactividad por defecto de Modal es 60 segundos (configurable 2s-20min). Un worker caliente elimina cold starts pero factura como siempre activo.

# Modal scaledown config (illustrative)
# A 60s window means you pay for 60 idle seconds per burst.
# A warm worker (min_containers=1) costs ~$2.50/hr on A100 80GB, 24/7.
@app.function(
    gpu="A100",
    scaledown_window=60,  # seconds idle before shutdown
    # min_containers=1,   # uncomment to kill cold starts; costs $60/day
)

¿Es la GPU serverless más barata que una GPU siempre activa?

La GPU serverless es más barata cuando tu GPU está ociosa la mayor parte del día. Con 3.000 peticiones/día de media 2 segundos cada una en una A100 80GB, serverless cuesta unos $4,17/día frente a $65,28/día por una GPU alquilada funcionando 24/7. El punto de cruce es una cuestión de ciclo de trabajo, no de volumen.

Supuestos (nuestros, declarados para que puedas recalcularlos): A100 80GB a $2,50/h de Modal, 2 segundos de media de tiempo GPU por petición, GPU alquilada a $2,72/h de RunPod las 24 horas, API de tokens alojada a $0,40/1M tokens (una tarifa publicada de gama media), y ~1.000 tokens por petición.

El cruce cae alrededor de 47.000 peticiones/día. Por debajo, serverless gana. Una API de tokens alojada gana a ambas a bajo volumen con un modelo commodity. El punto de equilibrio no trata de cuántas peticiones recibes. Trata de cuántas horas pasa tu GPU sin hacer nada.

El análisis de agosto 2024 de BentoML enmarca bien este compromiso, aunque sus ejemplos de precios son de la era GPT-3.5-turbo y tienen dos años de antigüedad.

Para lo que cuesta una API de tokens alojada a tu volumen, consulta nuestra comparativa de precios de APIs LLM. Para reducir el coste por petición en el lado de inferencia, la caché de prompts normalmente ahorra un 30-60% en contexto repetido.

# Break-even calculator: adjust these and re-run
REQUESTS_PER_DAY = 3000
SECONDS_PER_REQUEST = 2
SERVERLESS_RATE_HR = 2.50   # Modal A100 80GB
RENTED_RATE_HR = 2.72       # RunPod A100 80GB, 24/7

serverless_daily = REQUESTS_PER_DAY * SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR
rented_daily = RENTED_RATE_HR * 24

print(f"Serverless: ${serverless_daily:.2f}/day")
print(f"Rented 24/7: ${rented_daily:.2f}/day")
print(f"Crossover: {int(RENTED_RATE_HR * 24 / (SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR))} req/day")

Cuándo la GPU serverless es la decisión equivocada

• Tráfico alto sostenido. Por encima de ~47.000 peticiones/día a estas tarifas, el ciclo de trabajo se invierte y una GPU alquilada es más barata por petición.
• SLOs estrictos por debajo del segundo en ruta fría. Ningún truco de snapshot hace instantánea una primera petición. Mantén un worker caliente o alquila la máquina.
• Modelos 70B+ que necesitan varias GPUs. Una GPU por instancia en Cloud Run termina esa conversación.
• Residencia de datos estricta. Seis regiones L4 es todo el menú en Cloud Run.
• Economía por petición que pierde frente a un slot de worker que ya estás pagando. Si tienes margen de GPU libre, añadir inferencia no cuesta nada extra.

Si tu GPU está ocupada dieciséis horas al día, serverless es la opción cara y quien te diga lo contrario está vendiendo serverless.

Para la ruta local primero, consulta nuestra guía de herramientas locales para LLM.

Preguntas frecuentes

¿Qué es una GPU serverless?

Una plataforma de GPU serverless ejecuta tu contenedor de modelo en hardware compartido, escala a cero entre peticiones y factura solo por cómputo activo. Obtienes un endpoint de inferencia sin gestionar una instancia GPU persistente. El compromiso es un retraso de cold start en el arranque.

¿Cuánto cuesta ejecutar un LLM en una GPU serverless?

Una A100 80GB funciona a $2,25/h en Beam, $2,50/h en Modal, $2,72/h en RunPod (verificado el 30-07-2026). Tu factura depende del ciclo de trabajo: 3.000 peticiones/día a 2s cada una cuesta ~$4/día en Modal. El almacenamiento añade $0,09/GiB/mes, con 1 TiB gratis.

¿Pago por almacenar los pesos del modelo?

Sí, pero es barato. Modal cobra $0,09/GiB/mes con 1 TiB/mes gratis, así que un checkpoint de 80 GB no cuesta nada. La página de precios de RunPod lista almacenamiento de red a $0,07/GB/mes bajo 1 TB, unos $5,60/mes para los mismos 80 GB.

¿Mi modelo se vuelve a descargar en cada petición?

Solo si nada está cacheado. Los pesos en un volumen persistente u horneados en la imagen sobreviven a los cold starts. Apunta la caché de Hugging Face a almacenamiento efímero y un modelo de 130 GB se vuelve a descargar en cada arranque. Ese es el modo de fallo a evitar.

¿Cuánto dura el cold start para un modelo 7B?

Espera 10-30 segundos en un cold start real, según reportes de practitioners (r/LLMDevs, dic 2024). El contenedor arranca en 1-5s (docs de Modal, Cloud Run). El resto es carga de pesos e inicio del motor. Con snapshots y modo sleep, Umapathi midió ~70s para un modelo 27B, bajando desde 460s.

¿Puedo ejecutar un modelo 70B en GPU serverless?

Normalmente no. Un modelo 70B en FP16 necesita ~140 GB de VRAM. Cloud Run permite una GPU por instancia (96 GB máx.). Necesitarías cuantización FP8 para caber en una sola tarjeta de 80 GB, o una plataforma multi-GPU. La mayoría de superficies serverless limitan a una GPU.

¿Es la GPU serverless más barata que alquilar una GPU 24/7?

Por debajo de ~47.000 peticiones/día (a 2s/petición en una A100 80GB), sí. Serverless factura solo segundos activos; una GPU alquilada factura 24 horas independientemente. Por encima, la GPU alquilada gana. Una API de tokens alojada gana a ambas a bajo volumen. Mira la tabla de punto de equilibrio de arriba.

¿Puedo desplegar un LLM en GPU serverless gratis?

Modal da $30/mes en créditos gratis (Starter). Beam da $30/mes. El crédito de $300 para cuentas nuevas de GCP cubre uso de GPU en Cloud Run. Suficiente para prototipar, no para tráfico de producción. Ninguna plataforma ofrece un tier gratuito permanente para inferencia GPU.

¿Qué proveedores de GPU serverless están disponibles en Europa?

Cloud Run sirve GPUs L4 en europe-west1 (Bélgica) y europe-west4 (Países Bajos). Modal documenta selección de región EU (eu-west, eu-north, eu-south) con precios a 1,5-1,75x las tarifas base. RunPod nombra centros de datos europeos incluyendo EU-NL-1 y EU-FR-1. Fija la región explícitamente; ninguno tiene la EU por defecto.

¿Necesito Docker para desplegar un LLM en GPU serverless?

No siempre. RunPod ofrece plantillas de worker vLLM precompiladas que omiten Docker. Modal construye contenedores desde una definición de imagen Python en código. Para dependencias personalizadas escribirás un Dockerfile. Para serving estándar de vLLM, la ruta precompilada funciona en minutos.

Conclusión

Cinco plataformas, cinco unidades de facturación, una tabla normalizada. La decisión es más simple de lo que las páginas de proveedores la hacen parecer:

• Elige tu GPU por VRAM, no por marca.
• Pon tus pesos en un volumen, no en la imagen, a menos que nunca cambies modelos.
• Espera cold starts de 10-30 segundos y planifica en torno a ellos.
• Por debajo de ~47.000 peticiones/día, el escalado a cero gana en coste.
• El motor de serving detrás del endpoint es intercambiable; el base_url es una línea.

Tienes un endpoint invocable. Siguiente: ¿qué se pone delante cuando necesitas enrutamiento y failover? Nuestra comparativa de gateways LLM responde eso. O cuéntanos tu configuración.