RunPod Serverless (2026): precios reales y cuándo gana un pod

RunPod Serverless reduce tu endpoint a cero entre peticiones y factura por segundo. La cifra que todo el mundo repite, $0.16/h, no es un precio serverless: es el suelo del catálogo de pods. El worker serverless más barato cuesta $0.58/h y una A100 sale por $2.72/h.

La diferencia importa, porque serverless cuesta entre 1,5 y 2,8 veces el precio del pod Secure Cloud con la misma tarjeta. Lo que compras es escalar a cero, y eso no sale gratis.

Precios serverless por GPU

Precios serverless verificados en runpod.io/pricing el 3 de agosto de 2026; precios de pods en la misma página el 31 de julio de 2026.

El punto de equilibrio es el uso, no el precio por hora

Un pod factura de forma continua lleguen peticiones o no. Serverless solo cobra mientras hay un worker levantado. Así que la pregunta nunca es cuál cuesta menos por hora, duelo que serverless pierde siempre, sino qué parte del día trabaja realmente tu endpoint.

Divide 1 entre el factor de la tabla y obtienes el nivel de uso en el que ambos cuestan lo mismo:

• A40 48 GB a 2,77×: el pod gana por encima del 36 % de uso
• RTX 4090 a 1,59×: por encima del 63 %
• A100 80 GB a 1,83×: por encima del 55 %
• H100 80 GB a 1,52×: por encima del 66 %

Un endpoint que atiende tráfico en horario laboral se sitúa por definición cerca del 33 %, y por eso serverless le encaja. Un proceso por lotes que satura la GPU seis horas cada noche está en el 25 % y también encaja. Todo lo que responde tráfico de producción constante a cualquier hora debería estar en un pod, y la A40 es la tarjeta donde eso cambia antes.

Se factura bastante más que la ejecución

Esta es la parte que sorprende al leer la primera factura. RunPod factura desde que el worker arranca hasta que se detiene por completo, redondeando al segundo, a lo largo de tres fases: arranque del contenedor, ejecución de la petición y el idle timeout posterior. Por defecto, esa ventana es de cinco segundos.

Haz la cuenta con una petición corta. Una A100 a $2.72/h son $0.000756 por segundo. Una inferencia de 400 ms no te cuesta 400 ms:

• Solo ejecución: 0,4 s × $0.000756 = $0.0003
• Ejecución más la ventana de inactividad de 5 s: 5,4 s × $0.000756 = $0.0041

Acabas pagando unas 13,5 veces el tiempo de cómputo, y eso antes de cualquier arranque en frío. Hay dos palancas. Agrupa más trabajo en cada petición para que la ejecución pese más que la cola de inactividad, o recorta el idle timeout, aunque acortarlo hace más probable que la siguiente petición pague un arranque en frío. FlashBoot existe precisamente para suavizar ese compromiso manteniendo templados los workers usados hace poco.

Workers flex y activos

Los workers flex escalan a cero y son a los que se refieren los precios anteriores. Los workers activos funcionan 24/7 y nunca arrancan en frío; RunPod anuncia hasta un 40 % de descuento para ellos, aunque el importe concreto se negocia con ventas y no aparece en la página de precios.

Un worker activo es un pod con pasos de más, salvo que necesites de verdad el enrutado de peticiones de serverless. Si la máquina va a estar encendida igualmente, compara antes con un pod Secure Cloud.

Desplegar un endpoint

RunPod descarga tu imagen desde un registro que controlas tú. No existe un registro propio de RunPod al que subirla, y ahí es donde tropiezan las guías antiguas.

1. Construye un contenedor con un handler, no con un servidor web. El SDK de Python de RunPod envuelve tu función de inferencia, así que no necesitas FastAPI ni Flask, y una aplicación Node/Express tiene directamente la forma equivocada para esto.
2. Súbela a Docker Hub o GHCR, pública o con credenciales facilitadas a RunPod.
3. Crea el endpoint, apúntalo a la etiqueta de la imagen y elige clases de GPU. Seleccionar varias permite al planificador recurrir a otra cuando tu primera opción no está disponible.
4. Fija los límites de workers y el idle timeout. El máximo de workers pone techo al gasto; el idle timeout es la palanca de la sección anterior.
5. Incrusta los pesos del modelo en la imagen o en un volumen de red. Descargar un checkpoint de 14 GB en cada arranque en frío es el motivo más habitual de que un endpoint barato acabe siendo caro.

Para probarlo basta curl contra la ruta /runsync en trabajos cortos y /run para todo lo que sobreviva al tiempo de espera de la petición.

FAQ

¿RunPod Serverless cuesta $0.16 por hora?

No. Esa cifra corresponde al pod más barato del catálogo, no a un worker serverless. Serverless arranca en $0.58/h para la clase de 16 GB y llega a $9.98/h en una B300. Las comparativas que enfrentan $0.16/h con otras plataformas serverless están comparando dos productos distintos.

¿Por qué mi factura supera el tiempo de inferencia que he medido?

Porque la ejecución es solo una de las tres fases facturadas. También pagas el arranque del contenedor y el idle timeout posterior a cada petición, cinco segundos por defecto. En inferencias por debajo del segundo, esa ventana de inactividad puede salir un orden de magnitud más cara que el trabajo en sí.

¿Cuándo conviene un pod?

Por encima del 55-65 % de uso aproximado en la mayoría de tarjetas de centro de datos, y ya desde el 36 % en una A40. Calcula qué fracción del día está computando de verdad tu endpoint y contrástala con los factores de la tabla. El tráfico constante a todas horas pertenece a un pod.

¿Necesito un framework web dentro del contenedor?

No. El modelo de handler espera una función que reciba la carga del trabajo y devuelva un resultado; RunPod se encarga alrededor del HTTP, la cola y el escalado. Meter Flask o FastAPI dentro del worker duplica infraestructura que ya estás pagando.

Para ver cómo se desglosan las tarifas de los pods, consulta la comparativa RunPod Community vs Secure Cloud, y para el panorama completo la comparativa general de GPU cloud.