Tu aplicación de IA no es "otro servicio web más". Tiene tráfico de inferencia con picos impredecibles, SLOs de latencia exigentes, y pipelines batch que pueden convertirse en el centro de costos más grande sin que te des cuenta. Por eso la decisión entre serverless y contenedores aparece mucho antes de lo que la mayoría de equipos espera — justo después de que el demo se vuelve viral o el primer cliente enterprise pregunta por compliance, uptime y residencia de datos.
Elegir el runtime equivocado se siente en la semana dos: latencia p95 subiendo, facturas sorpresa, throttling durante picos, o una carga operativa que tu equipo no puede sostener. Elegir el correcto significa rendimiento predecible, costos controlables y un camino del MVP a producción sin reescribir todo.
Basado en el análisis de más de una docena de deploys de inferencia en 2026, este artículo presenta un framework práctico de decisión con indicadores tangibles: tiempo por request, concurrencia, requisitos de GPU, tamaño del modelo y madurez operativa del equipo.
El Contexto en 2026: No es una Guerra Ideológica
La gente sigue hablando sin entenderse porque "serverless" puede significar FaaS, plataformas managed o simplemente "no quiero manejar servidores". Y "contenedores" puede ser Docker en una VM o un Kubernetes completo con service mesh, autoescalado y políticas de seguridad.
La CNCF Annual Cloud Native Survey 2026 encontró que el 82% de los usuarios de contenedores ejecuta Kubernetes en producción. La encuesta describe a Kubernetes como una capa operativa común para sistemas modernos y cargas de IA. Pero para un CTO, la decisión real no es "qué runtime es mejor" sino "qué runtime encaja con esta carga de trabajo específica de IA".
Porque el mismo producto de IA puede incluir: inferencia en tiempo real, ingestión batch, pipelines de embeddings, reentrenamiento, colas, búsqueda vectorial y servicios GPU-backed. Cada uno merece un runtime distinto.
Framework de Decisión: 5 Variables Críticas
1. Perfil de Tráfico
Si tu inferencia recibe tráfico en ráfagas (cientos de requests en minutos, luego silencio), serverless te da el mejor costo marginal. Pagas por invocación, no por capacidad ociosa. Si tu tráfico es constante y predecible, los contenedores con reserva de capacidad te dan mejor relación costo/rendimiento.
- Ráfagas impredecibles → Serverless (Lambda, Cloud Run, RunPod Serverless)
- Carga constante 24/7 → Contenedores (EKS, GKE, OKE, autoescalado horizontal)
- Mixto → Híbrido: serverless para inferencia spiky, contenedores para pipelines batch
2. Tolerancia a Cold Starts
Este es el factor más ignorado. Para modelos de lenguaje grandes (70B+ parámetros), los cold starts en serverless auto-manejado promedian 15-30 segundos de latencia inicial. Si tu SLO exige respuestas sub-500ms, los cold starts te matan.
Plataformas especializadas como RunPod han reducido cold starts a sub-200ms con FlashBoot, pero esto aplica a modelos contenerizados precargados. Para la mayoría de FaaS genéricos, si tu p95 no puede tolerar cold starts, inclínate por contenedores.
- Latencia crítica (300ms p95) → Contenedores con reserva de warm capacity
- Latencia flexible (>2s) → Serverless funciona bien
- Modelos pequeños (<7B) → Serverless con keep-warm aceptable
3. Requisitos de GPU
Aquí serverless tradicional tropieza. La mayoría de FaaS (AWS Lambda, Cloud Functions) no soporta GPUs nativas. Plataformas como RunPod Serverless, Modal o Beam ofrecen inferencia serverless con GPU, pero con limitaciones: modelos soportados, memoria de VRAM, y regiones disponibles.
Si necesitas GPUs específicas (A100, H100, L40S) o configuraciones multi-GPU, los contenedores sobre Kubernetes con node pools GPU son el camino probado. El mercado de GPU-as-a-Service alcanzó $7.34 mil millones en 2026, creciendo 28.7% anual — y la mayoría de ese gasto es sobre contenedores.
- GPU serverless disponible → RunPod, Modal, Beam, DigitalOcean Inference
- GPU específica/multi-GPU → Kubernetes + GPU node pools (GKE, EKS, OKE)
- Inferencia CPU-only → Cualquier runtime funciona
4. Costos Operativos y Carga del Equipo
Serverless reduce la carga operativa — no manejas servidores, no parcheas kernels, no escalas clusters. Pero introduce costos invisibles que ya exploramos en artículos anteriores: NAT Gateway, logging excesivo, egresos de red, y el "serverless tax" de ~15-20% sobre el costo base de compute.
Los contenedores, especialmente Kubernetes, requieren un equipo con habilidades en SRE — o al menos alguien que sepa debuggear un CrashLoopBackOff a las 2 AM. Si tu equipo es pequeño (<5 ingenieros) y no tienes DevOps dedicado, serverless reduce significativamente el riesgo operativo.
- Equipo pequeño, sin SRE → Serverless first (Cloud Run, Lambda + API Gateway)
- Equipo mediano con DevOps → Contenedores managed (EKS, GKE Autopilot)
- Equipo grande, SRE maduro → Kubernetes custom con GPU scheduling optimizado
5. Portabilidad y Vendor Lock-in
Serverless FaaS (Lambda, Cloud Functions) te amarra a un ecosistema. Migrar de AWS Lambda a Google Cloud Functions no es trivial — cada plataforma tiene su propio event model, permisos y runtime. Los contenedores, correctamente empaquetados con Docker + Kubernetes manifests, son portables entre cualquier cloud o on-premise.
Para equipos que valoran la soberanía de infraestructura y la opción de rebalanceo multi-cloud (un tema recurrente en este blog), los contenedores ofrecen más flexibilidad estratégica.
La Estrategia Híbrida: Lo Mejor de Ambos Mundos
En la práctica, la mayoría de equipos maduros terminan en una arquitectura híbrida: serverless para el "glue" (webhooks, colas, schedulers, preprocesamiento ligero) y contenedores para la inferencia pesada o el serving de modelos.
Ejemplo concreto: un sistema de recomendaciones con inferencia en tiempo real puede correr serverless en los primeros meses mientras validas tráfico. Cuando alcanzas 10K requests/minuto, migras el modelo a un deployment containerizado con GPU en Kubernetes. Los webhooks de feedback y las colas de reentrenamiento se quedan serverless.
Tabla Decisoria Rápida
Usa esta matriz como punto de partida para tu próxima decisión de arquitectura:
• p95 latencia menor a 300ms y no toleras cold starts → Contenedores primero
• Tráfico impredecible, quieres pagar por uso → Serverless primero
• GPUs específicas o multi-GPU → Contenedores (Kubernetes)
• Modelos pequeños, latencia flexible → Serverless
• Portabilidad multi-cloud → Contenedores
• Equipo pequeño, time-to-market crítico → Serverless MVP, contenedores después
TL;DR — Lo que Debes Recordar
- No hay runtime universal — Elige por carga de trabajo, no por moda
- Serverless es ideal para spikes tempranos pero los cold starts matan latencia estricta
- Contenedores con GPU son el estándar de producción para inferencia seria
- Híbrido es la norma en equipos maduros: serverless para glue, contenedores para heavy lifting
- El camino más rápido: serverless MVP → entiendes unit economics → migras hot paths a contenedores
¿Estás decidiendo la arquitectura de tu próxima carga de inferencia? La respuesta no está en un runtime — está en tus datos de tráfico, latencia y equipo. Mide primero, elige después.