Inferencia de IA serverless en Cloud Run: cuándo tiene sentido (y cuándo no)
Desde que las GPU en Cloud Run pasaron a disponibilidad general, ejecutar un modelo propio en serverless dejó de ser un experimento y se convirtió en una opción real para producto. La pregunta ya no es si se puede, sino cuándo compensa frente a llamar a una API gestionada o a montar tu propio GKE.
Respuesta directa: Cloud Run con GPU tiene sentido cuando necesitas servir un modelo abierto (o afinado por ti) con tráfico intermitente, quieres escalar a cero cuando no hay peticiones, y puedes tolerar un arranque en frío de unos segundos. No tiene sentido si tu carga es constante 24/7 (una VM con GPU o un endpoint dedicado sale más barato), si necesitas la última generación de modelos cerrados (usa la API del proveedor), o si tu latencia p99 no admite cold starts.
Este artículo desglosa qué ofrece Cloud Run hoy, cómo encaja un backend en Go, y el criterio honesto para decidir.
Qué ofrece Cloud Run con GPU en la práctica
Los datos verificables de la disponibilidad general:
- GPU NVIDIA L4 con 24 GB de memoria, sin necesidad de solicitar cuota.
- Escala a cero: cuando no hay peticiones, no pagas GPU. Facturación por segundo de uso real.
- Arranque en frío: una instancia pasa de cero a GPU con drivers instalados en menos de 5 segundos. Sobre un modelo
gemma3:4b, el time-to-first-token completo (arranque + carga del modelo + inferencia) rondó los 19 segundos en las pruebas de Google. - Escalado: de 0 a 100 GPU en unos 4 minutos en la demo de referencia.
- Streaming HTTP y WebSocket, imprescindible para respuestas token a token.
Para cargas más pesadas, Google ha ido incorporando GPU de gama superior (como la NVIDIA RTX PRO 6000 Blackwell, con 96 GB) capaces de servir modelos de 70B+ parámetros, y un servidor MCP oficial de Cloud Run para gestionar y desplegar apps desde agentes. Verifica siempre disponibilidad por región antes de comprometer una arquitectura.
El patrón: Go como orquestador, GPU bajo demanda
Un error común es meter la inferencia y la lógica de negocio en el mismo servicio. Un patrón más limpio separa responsabilidades:
- Servicio de API en Go (sin GPU): recibe peticiones, valida, aplica auth y rate limiting, decide si la petición necesita el modelo y compone la respuesta. Go brilla aquí por su arranque instantáneo, bajo consumo de memoria y concurrencia barata.
- Servicio de inferencia con GPU (Cloud Run + L4): expone el modelo (por ejemplo vía Ollama o un runtime propio) y escala a cero cuando no hay tráfico.
# Servicio de inferencia con GPU, escala a cero
gcloud run deploy inference \
--image=ollama/ollama --port=11434 \
--gpu=1 --gpu-type=nvidia-l4 \
--min-instances=0 --max-instances=10 \
--no-cpu-throttling
El servicio Go llama al de inferencia por HTTP interno. Cuando el tráfico cae, la GPU se apaga y dejas de pagarla; el servicio Go, barato, puede quedarse encendido para responder al instante lo que no necesite modelo.
Si vienes de un backend Go más clásico, tenemos una guía sobre desarrollo de backend en Go y cómo lo abordamos en proyectos de backend para empresas.
Cloud Run GPU vs API gestionada vs GKE
No hay una respuesta universal. Este es el criterio que usamos:
| Criterio | Cloud Run + GPU | API gestionada (LLM cerrado) | GKE con GPU |
|---|---|---|---|
| Tráfico intermitente / picos | Excelente (escala a cero) | Excelente (pagas por token) | Malo (pagas nodo aunque no uses) |
| Tráfico constante 24/7 | Caro frente a alternativas | Depende del volumen | Óptimo (mejor coste/hora) |
| Modelo propio o afinado | Sí | No | Sí |
| Control de datos / on-premise lógico | Alto | Bajo (sale de tu perímetro) | Alto |
| Cold start aceptable | Requerido (~segundos) | No aplica | No hay cold start |
| Complejidad operativa | Baja | Muy baja | Alta |
Traducción práctica: si solo quieres añadir una feature de IA con el mejor modelo posible y tu volumen es moderado, una API gestionada suele ganar en time-to-market y coste. Si necesitas un modelo propio, afinado o con requisitos de dato, y tu tráfico es irregular, Cloud Run con GPU es el punto dulce. Si tienes carga masiva y constante, GKE o instancias dedicadas amortizan mejor.
Cuándo NO usar Cloud Run con GPU
Siendo honestos —porque el marketing de serverless tiende a la euforia:
- Latencia estricta con tráfico esporádico. Si tu SLA no admite el cold start de una GPU que estaba a cero, tendrás que mantener
min-instances=1, y en ese momento pierdes buena parte de la ventaja económica del escalado a cero. - Carga sostenida. Con una GPU ocupada casi todo el día, pagar por segundo sale peor que una reserva. Haz números con tu perfil de uso real, no con el pico.
- Necesitas el frontier model del momento. Los modelos cerrados de última generación no los vas a autohospedar; ahí la API del proveedor es la respuesta.
- Modelos enormes sin la GPU adecuada. Una L4 de 24 GB no sirve un 70B; necesitarías GPU de más memoria y verificar disponibilidad regional y coste.
La decisión correcta casi siempre depende de una curva de tráfico, no de una preferencia tecnológica. Mídelo antes de comprometerte.
Conclusión
Las GPU serverless en Cloud Run cierran un hueco real: modelos propios, con tráfico irregular, sin gestionar infraestructura y pagando solo por lo que usas. No sustituyen a las APIs gestionadas ni a GKE; amplían el abanico y hacen que "hospedar tu propio modelo" deje de implicar un clúster encendido de forma permanente. La clave es elegir con datos de tráfico y latencia, no con entusiasmo.
En Dribba diseñamos backends en Go y arquitecturas de IA para producto —desde el discovery hasta la puesta en producción— con criterio de coste y mantenibilidad. Si estás decidiendo cómo servir un modelo en tu producto, nuestro equipo de integración de IA puede ayudarte a hacer los números antes de escribir la primera línea. Entre nuestros clientes hay compañías como Rastreator, TravelPerk, Coca-Cola EP, Lactalis-Nestlé e ISDIN.
