La serverless se partió en dos. Cloudflare Workers alcanzó cold starts de nanosegundos vía V8 isolates para APIs de latencia crítica, mientras AWS Lambda sumó instancias GPU para inferencia de LLMs serverless. La brecha de cold start es de 240x entre ambas plataformas, y la arquitectura más coherente de 2026 usa ambas.
El Gran Cisma de la Serverless
En 2014, AWS Lambda inventó la función serverless moderna. En 2017, Cloudflare Workers llegó con un enfoque radicalmente diferente: ejecutar JavaScript en el edge usando V8 isolates en lugar de contenedores. Durante años, compitieron en el mismo espacio con filosofías distintas pero casos de uso que se solapaban parcialmente.
2026 cambió eso. Tres eventos redefinieron el panorama:
- Cloudflare Workers eliminó efectivamente el cold start — V8 isolates que existen permanentemente en los 330+ POPs globales, con latencias de inicio medidas en microsegundos en lugar de milisegundos.
- AWS Lambda lanzó Managed Instances — Capacidad de ejecutar funciones Lambda en instancias EC2 dedicadas, incluyendo GPU (G5/G6 con NVIDIA A10G/L4), rompiendo el techo de cómputo tradicional.
- El auge de la IA local y edge — La inferencia de LLMs necesita GPU; los APIs globales necesitan latencia de un solo dígito. Un solo runtime ya no puede servir ambos mundos.
El resultado es una bifurcación clara: Workers para el edge de baja latencia, Lambda para el backend pesado con GPU.
Cloudflare Workers 2026: La Era del Cold Start Cero
¿Cómo lo Logran?
Mientras AWS Lambda inicia un micro-VM Firecracker por invocación (100ms-2s de cold start), Cloudflare Workers ejecuta tu código en V8 isolates que son procesos ligeros dentro de un runtime persistentemente activo.
La metáfora correcta: Lambda es como prender un auto cada vez que necesitas usarlo. Workers es como tener el motor ya encendido y solo abrir la puerta.
En producción, las pruebas de 2026 muestran:
| Métrica | AWS Lambda (Node.js 20) | Cloudflare Workers |
|---|---|---|
| Cold start p50 | 450 ms | < 1 ms |
| Cold start p95 | 1.2 – 2.8 s | 5 ms |
| Diferencia | 240x más lento | Baseline |
| Distribución geográfica | 1-3 regiones | 330+ POPs globales |
Latencia Geográfica: La Ventaja Imbatible
Un usuario en São Paulo consultando una API alojada en us-east-1 tiene ~150ms de RTT. Con Workers, esa misma consulta se sirve desde el POP de Cloudflare en São Paulo: ~5ms.
| Ubicación del usuario | Lambda (us-east-1) | Workers (POP local) |
|---|---|---|
| São Paulo | ~150ms RTT | ~5ms RTT |
| Lisboa | ~120ms RTT | ~10ms RTT |
| Tokio | ~180ms RTT | ~10ms RTT |
| Sídney | ~200ms RTT | ~15ms RTT |
Para APIs que responden en < 50ms, esta es la diferencia entre «rápido» y «instantáneo».
Precios Workers 2026
| Plan | Costo |
|---|---|
| Gratuito | 100k requests/día |
| Workers Standard ($5/mes) | 10M requests + 30M CPU ms incluidos |
| Exceso de requests | $0.30 por 1M adicionales |
| Exceso de CPU | $0.02 por 1M CPU ms adicionales |
Para cargas de trabajo pequeñas y medianas, Workers suele ser 3-10x más barato que Lambda.
Limitaciones
Workers no es perfecto:
- 10 MB de bundle (15 MB en plan pago) — No puedes ejecutar Puppeteer, Sharp, o SDKs pesados
- 128 MB de memoria — Sin posibilidad de aumentarla
- 50ms-5min de tiempo de CPU — Procesamiento pesado requiere alternativas
- 50-1000 subrequests por invocación — Llamadas externas limitadas
- Ecosistema de datos propio — KV, D1, R2, Durable Objects, Queues (funcional pero no es AWS)
AWS Lambda 2026: GPU y Cómputo Dedicado
Lambda Managed Instances: El Game Changer
La limitación más frustrante de Lambda clásico era el modelo de cómputo compartido. No podías elegir instancias específicas, no había GPU, y los 10 GB de memoria eran un techo duro.
Lambda Managed Instances (lanzado en re:Invent 2025 y madurado en 2026) cambia esto por completo. Ahora puedes configurar una función Lambda para ejecutarse en instancias EC2 de tu cuenta, especificando:
ManagedInstanceConfig:
InstanceType: g5.2xlarge # 1x NVIDIA A10G GPU, 8 vCPU, 32 GB RAM
MinInstances: 1 # GPU caliente para evitar cold start
MaxInstances: 10
AWS continúa manejando el aprovisionamiento, auto-escalado, parches de seguridad y el runtime Lambda. Tu código y handler siguen siendo idénticos. Ganas control de cómputo sin ganar overhead operativo.
GPU Inference como Lambda Function
Los casos de uso que antes requerían ECS Fargate o EC2 ahora caben en Lambda:
| Carga de trabajo | Instancia | GPU | Costo típico |
|---|---|---|---|
| Inferencia LLM (7B-70B params) | g5.2xlarge | 1× NVIDIA A10G | ~$1.21/h |
| Embeddings / Clasificación | g5.xlarge | 1× NVIDIA A10G | ~$0.86/h |
| Procesamiento de video | g6.4xlarge | 1× NVIDIA L4 | ~$1.54/h |
| Document Intelligence | c7g.4xlarge (CPU) | N/A (ARM64 Graviton3) | ~$0.68/h |
El Costo: Managed Instances vs EC2 Always-On
Para cargas de trabajo bursty e irregularmente distribuidas, el ahorro es dramático:
Escenario: 2,000 requests/día de inferencia ML, 3 segundos cada una en GPU.
| Modelo | Costo mensual | Utilización |
|---|---|---|
| EC2 g5.2xlarge 24/7 | $876/mes | 6.9% |
| Lambda Managed (MinInstances: 0) | ~$60/mes | Bajo demanda |
| Lambda Managed (MinInstances: 1) | ~$936/mes | GPU siempre caliente |
| Ahorro | 93% (vs always-on) |
El punto de equilibrio está en ~40% de utilización diaria de GPU. Por debajo, Managed Instances gana. Por encima, EC2 reservado es más barato.
La Otra Cara: Lambda Sin GPU (Lambda Clásico 2026)
Para cargas de trabajo que no requieren GPU, Lambda clásico sigue siendo una bestia diferente:
| Característica | Lambda Clásico 2026 | Workers 2026 |
|---|---|---|
| Cold start | 100ms – 2s | < 5ms |
| Memoria máxima | 10 GB | 128 MB |
| Timeout máximo | 15 minutos | 5 minutos CPU |
| Runtimes | Node.js, Python, Java, Go, Ruby, .NET, Custom | JavaScript, WASM |
| Bundle máximo | 250 MB | 10-15 MB |
| Precio requests | $0.20/1M + GB-segundo | $0.30/1M (tras free tier) |
La Arquitectura Coherente: Workers + Lambda GPU
El patrón emergente en 2026 no es «Workers vs Lambda» sino Workers + Lambda GPU. La arquitectura más racional usa ambos:
┌─────────────────────────────────────────────────────┐
│ Usuario │
└─────────────────┬───────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ Cloudflare Workers (Edge) │
│ │
│ ● Routing / Autenticación / Rate Limiting │
│ ● RAG ligero (Vectorize) │
│ ● Gating de prompts │
│ ● Caché de respuestas frecuentes (KV) │
│ ● < 5ms cold start, 330+ ubicaciones │
└─────────────────┬───────────────────────────────────┘
│ (LLM payloads)
▼
┌─────────────────────────────────────────────────────┐
│ AWS Lambda (GPU Managed Instances) │
│ │
│ ● Inferencia de LLMs (DeepSeek, Llama, Qwen) │
│ ● Procesamiento pesado asíncrono │
│ ● GPU bajo demanda (g5/g6) │
│ ● Escala a cero cuando no se usa │
│ ● Integración con ecosistema AWS (S3, Bedrock) │
└─────────────────────────────────────────────────────┘
¿Por qué Tiene Sentido?
Workers maneja la capa de presentación de IA: autenticación, rate limiting, RAG ligero, gating de prompts, caché de respuestas frecuentes. Todo a latencia de edge global.
Lambda GPU maneja la capa de cómputo de IA: la inferencia pesada del LLM. Pagas por GPU solo cuando alguien hace un prompt. La GPU escala a cero cuando nadie la usa — algo imposible con instancias dedicadas.
Cloudflare lo confirma: «la respuesta real suele ser ambos — Workers en el edge para la llamada del usuario, RAG, gating e inferencia serverless GPU; Lambda cuando la carga de trabajo es intensiva en memoria, larga o está encadenada a datos residentes en AWS.»
Tabla Decisoria: ¿Cuándo Usar Cada Uno?
Elige Cloudflare Workers si…
- La latencia es crítica (chat, APIs globales, juegos, fintech)
- Tu bundle cabe en 10 MB
- Quieres pagar centavos por workloads pequeños
- Usas el stack de Cloudflare (Pages, R2, D1, KV)
- Eres equipo pequeño que valora DX y despliegues en 5 segundos
- Un cold start de 1s es inaceptable
Elige AWS Lambda si…
- Ya estás en el ecosistema AWS (RDS, S3, IAM, VPC)
- Necesitas GPU para inferencia de modelos
- Tu bundle excede los 10 MB (FFmpeg, Puppeteer, ML models)
- Tienes procesamiento pesado y de larga duración (hasta 15 min)
- Cumplimiento normativo exige datos en una región específica
- Necesitas más de 128 MB de memoria
Elige Ambos si…
- Tienes un frontend edge (Workers) que orquesta backend GPU (Lambda)
- Quieres lo mejor de ambos mundos sin comprometer ni latencia ni capacidad
Conclusión: No es una Guerra, es una División del Trabajo
La bifurcación serverless de 2026 no es una batalla donde uno gana y el otro pierde. Es una especialización natural:
Cloudflare Workers ganó la carrera del edge: latencia de un solo dígito, sin cold starts, desplegable en segundos, con un modelo de precios que hace que pagar por computación ociosa parezca un pecado.
AWS Lambda ganó la carrera del cómputo pesado: GPU bajo demanda, memoria de hasta 10 GB, timeouts de 15 minutos, integración profunda con el ecosistema AWS más maduro del mundo.
La estrategia ganadora en 2026 no es elegir uno. Es diseñar sistemas donde cada uno hace lo que mejor sabe hacer: Workers en la puerta de entrada para todo lo rápido y ubicuo; Lambda GPU en el cuarto de máquinas para todo lo pesado.
