Las solicitudes más importantes de una aplicación serverless son exactamente las que tienen más probabilidad de sufrir un cold start.
Un usuario nuevo cargando un dashboard. Un pico de tráfico después de una campaña de marketing. Una API interna de bajo volumen llamada con tan poca frecuencia que sus instancias nunca se mantienen calientes. Estos no son casos extremos: son los patrones donde la experiencia del usuario y los resultados del negocio están en juego. Y son exactamente donde los cold starts se concentran.
El resumen: Un cold start ocurre cuando una función serverless se inicializa desde cero porque no existe ninguna instancia caliente. La inicialización agrega de 200 ms a más de 1 segundo de latencia a las solicitudes afectadas. Los cold starts no son aleatorios — se concentran en los patrones de tráfico de mayor valor. Las arquitecturas que los eliminan lo hacen manteniendo instancias calientes o usando runtimes que no requieren inicialización en frío.
Qué pasa durante un cold start
Un cold start es el tiempo entre que una plataforma serverless recibe una solicitud y el código de la función empieza a ejecutarse. Incluye varios pasos secuenciales: asignar un container o entorno de ejecución, cargar el runtime, importar dependencias y ejecutar cualquier código de inicialización fuera de la función handler.
La duración depende del runtime y del tamaño del paquete de deployment. Las funciones de Python y Node.js en AWS Lambda hacen cold start en 200 a 800 ms en condiciones normales. Las funciones de Java y .NET, con runtimes más pesados, tardan de 800 ms a más de 3 segundos. Una función con árboles de dependencias grandes o código de inicialización global extiende estos números aún más.
Para la solicitud afectada, ese tiempo se suma directamente al tiempo de respuesta que ve el usuario. Una función que ejecuta en 20 ms después de la inicialización tiene un tiempo de respuesta con cold start de 420 a 3,020 ms. El código de la función es rápido. El overhead de infraestructura no lo es.
Por qué los cold starts se concentran en las solicitudes que más importan
Los cold starts no se distribuyen de forma aleatoria en el tráfico. Se concentran en tres patrones.
Primeras solicitudes de usuarios nuevos. Cuando un usuario entra por primera vez, no hay ninguna instancia caliente esperando. La primera solicitud paga el costo del cold start. Para aplicaciones donde la primera impresión importa — onboarding, primera compra, activación de un trial — este es el peor momento posible para un pico de latencia.
Picos de tráfico. Cuando el tráfico crece más rápido de lo que las instancias calientes pueden absorber, la plataforma escala inicializando nuevas instancias. Cada nueva instancia paga un cold start. Una campaña de marketing que envía 10x el tráfico normal a una landing page inicializa muchas instancias simultáneamente, agregando latencia de cold start exactamente a las solicitudes que la campaña fue diseñada para capturar.
Endpoints de bajo tráfico. Las funciones llamadas con poca frecuencia nunca mantienen instancias calientes. Una API interna llamada una vez por hora, un webhook handler, un trigger de background job — todos pagan un cold start en cada llamada. La baja frecuencia que hace inevitable el cold start también lo hace difícil de diagnosticar, porque el volumen de llamadas es demasiado bajo para aparecer claramente en los percentiles de latencia agregados.
Por qué los pipelines de inferencia de IA son especialmente vulnerables
Los cold starts se acumulan dentro de los pipelines de inferencia de IA de una forma que no ocurre con workloads serverless de función única.
Un AI agent completando una tarea típicamente encadena múltiples tool calls: una función recupera contexto, otra consulta una base de datos, una tercera llama a una API externa, una cuarta formatea y devuelve el resultado. Cada llamada en esa cadena es una invocación de función separada. Si cualquiera de ellas sufre un cold start, el retraso se suma a los demás. Un pipeline con cuatro tool calls, cada una con 50% de probabilidad de un cold start promedio de 400 ms, puede agregar más de un segundo de overhead de inicialización a una tarea que el modelo subyacente completa en milisegundos.
El problema es estructural. Los pipelines de inferencia de IA se dispersan hacia muchas funciones en paralelo o en secuencia, y lo hacen a velocidad de máquina — lo que significa que el patrón de llamadas poco frecuentes que causa cold starts en el serverless tradicional es común para funciones de herramientas que se llaman solo cuando llega un tipo específico de tarea. Una función que maneja análisis de imágenes puede ser llamada 20 veces al día. Casi nunca tiene una instancia caliente.
Para aplicaciones de IA en tiempo real — interfaces de voz, asistentes en vivo, agentes interactivos — esta latencia no es una preocupación secundaria. Un usuario esperando dos segundos por una respuesta que debería tomar 200 ms experimenta un producto roto, no uno lento. El cold start es indistinguible de una falla desde su perspectiva.
Un runtime que elimina cold starts remueve completamente este modo de falla del diseño de pipelines de IA. Functions en la plataforma de Azion usa V8 isolates y no tiene cold start, así que una función de herramienta llamada una vez por hora responde con la misma latencia que una llamada 10,000 veces por hora. Los diseñadores de pipelines no necesitan considerar tiempos de calentamiento, provisionar concurrencia por función ni arquitectar en torno a retrasos de inicialización.
Los patrones arquitectónicos que causan cold starts
Los cold starts son una propiedad de cómo un runtime gestiona los entornos de ejecución, no una característica inherente de la computación serverless. Los runtimes basados en container generan cold starts porque inicializar un container tiene un overhead fijo de inicialización. Reducir cold starts en estos entornos requiere mantener instancias calientes mediante pings periódicos, provisioned concurrency o configuraciones de instancia mínima — todo lo cual agrega costo y overhead operativo.
El problema raíz es el propio modelo de container. Los containers ofrecen aislamiento fuerte pero son relativamente pesados. Cargar un runtime, inicializar un proceso JVM o Node.js e importar dependencias lleva tiempo que no puede ocultarse completamente sin importar cómo se gestione la infraestructura.
Un enfoque diferente usa entornos de ejecución más ligeros. Los V8 isolates — la misma tecnología que ejecuta JavaScript en Chrome — se inicializan en microsegundos en lugar de milisegundos. Comparten un único proceso manteniendo aislamiento de memoria entre tenants. No hay container que inicializar, ningún runtime que cargar por separado y ninguna fase de importación de dependencias en el sentido tradicional.
Lo que realmente significa cero cold starts
Azion Functions usa el modelo de V8 isolates para la ejecución de JavaScript y TypeScript. Como no hay paso de inicialización de container, la primera solicitud a una función se ejecuta en el mismo tiempo que la centésima. No hay período de calentamiento, ninguna provisioned concurrency que configurar y ningún ping periódico para mantener instancias activas.
Esto no es una optimización de rendimiento aplicada sobre una arquitectura de container. Es un modelo de ejecución diferente donde la categoría de cold start simplemente no existe. La función está disponible para la primera solicitud sin overhead que no esté presente en todas las solicitudes subsecuentes.
Combinado con la red distribuida de Azion, Functions se ejecuta en la ubicación más cercana al usuario, no en una región centralizada en la nube. Un usuario nuevo en Ciudad de México llamando a una función deployada en la red de Azion no paga la latencia de un origen centralizado más un cold start. Recibe una respuesta del nodo más cercano sin ninguna penalización de inicialización.
Cómo diagnosticar cold starts en producción
Antes de resolver cold starts, hay que medirlos. Los percentiles de latencia estándar — p50, p95, p99 — pueden ocultar el impacto de los cold starts si las solicitudes afectadas son un porcentaje pequeño del volumen total. La firma del impacto de cold start en datos de producción se parece a una distribución con una cola larga en p99 y p99.9 que no corresponde al tiempo de ejecución esperado de la función.
Obtener traces de ejecución por solicitud en lugar de percentiles agregados revela esto. Un trace que muestra 20 ms de ejecución del handler y 600 ms de overhead de inicialización es un cold start. Una latencia p99 agregada que es 10x la latencia p50 sin una explicación clara en la complejidad de la función es generalmente impacto de cold start a escala.
Real-Time Events en la capa de observabilidad de Azion captura datos de ejecución por solicitud en la borda, haciendo posible identificar el overhead de inicialización antes de que se acumule en un problema visible de producto.
Los cold starts no son un trade-off aceptable por la simplicidad serverless. Son un artefacto de los entornos de ejecución basados en container que los modelos de runtime más ligeros ya resolvieron. La pregunta no es cómo minimizar el impacto de los cold starts — es si el entorno de ejecución los requiere.
Habla con un especialista de Azion para ver cómo Azion Functions elimina cold starts con ejecución en V8 isolates en una red globalmente distribuida.
Preguntas frecuentes
¿Qué es un cold start serverless? Un cold start es la latencia que se agrega cuando una función serverless se inicializa desde cero porque no existe ningún entorno de ejecución caliente. Incluye asignación de container, carga de runtime, importación de dependencias y ejecución de código de inicialización. La duración del cold start va de 200 ms para funciones Node.js ligeras a más de 3 segundos para runtimes Java o .NET con grandes árboles de dependencias.
¿Por qué los cold starts afectan el rendimiento en las solicitudes más importantes? Los cold starts se concentran en tres patrones de tráfico: primeras solicitudes de usuarios nuevos (no existe ninguna instancia caliente aún), picos de tráfico (el scale-out inicializa nuevas instancias simultáneamente) y endpoints de bajo tráfico (las instancias nunca se mantienen calientes entre llamadas). Estos son los patrones donde la experiencia del usuario y los resultados del negocio son más sensibles a la latencia, haciendo de los cold starts un problema de producto, no solo una métrica de rendimiento.
¿Cuánta latencia agregan los cold starts? Una función Node.js o Python en AWS Lambda agrega 200 a 800 ms en un cold start. Los runtimes Java y .NET agregan de 800 ms a más de 3 segundos. Para una función que ejecuta en 20 ms después de la inicialización, el tiempo de respuesta con cold start es de 10 a 150 veces el tiempo de ejecución de la función.
¿Qué es provisioned concurrency y resuelve los cold starts? Provisioned concurrency mantiene un número especificado de instancias de función inicializadas y listas, eliminando cold starts para las solicitudes que llegan a esas instancias. Resuelve el problema para tráfico predecible pero agrega costo proporcional al número de instancias mantenidas calientes. No ayuda con picos impredecibles que requieren scale-out más allá de la cantidad provisionada y requiere configuración operativa y gestión de costos continua.
¿Qué son los V8 isolates y cómo eliminan cold starts? Los V8 isolates son contextos de ejecución de JavaScript ligeros que comparten un único proceso V8 manteniendo aislamiento de memoria entre tenants. A diferencia de los containers, se inicializan en microsegundos en lugar de milisegundos porque no hay container que asignar, ningún runtime que cargar por separado y ninguna fase de importación de dependencias en el sentido tradicional. Las funciones construidas sobre V8 isolates no tienen cold start — las primeras solicitudes se ejecutan con el mismo overhead que todas las solicitudes subsecuentes.
¿Por qué los cold starts son especialmente dañinos para los pipelines de inferencia de IA? Los AI agents encadenan múltiples llamadas de función por tarea, así que la latencia de cold start se acumula en cada invocación del pipeline. Una cadena de cuatro tool calls donde cada función tiene 50% de probabilidad de un cold start de 400 ms puede agregar más de un segundo de overhead de inicialización a una tarea que el modelo subyacente completa en milisegundos. Las funciones llamadas para tipos específicos de tarea — análisis de imágenes, parsing de documentos, lookups especializados — frecuentemente se llaman con tan poca frecuencia que casi nunca tienen instancias calientes, haciendo los cold starts casi seguros en cada llamada.
¿Cómo diagnostico cold starts en producción? Las métricas de latencia agregadas estándar ocultan el impacto de cold start. La firma en datos de producción es una cola larga en p99 y p99.9 desproporcionada a la latencia p50 que no corresponde a la complejidad de la función. Obtener traces de ejecución por solicitud en lugar de percentiles agregados revela el overhead de inicialización directamente — un trace que muestra 20 ms de ejecución del handler y 600 ms de overhead de la plataforma es un cold start.
