As requisições mais importantes de uma aplicação serverless são exatamente as que têm maior chance de sofrer um cold start.
Um usuário novo carregando um dashboard, um pico de tráfego após uma campanha de marketing, uma API interna de baixo volume chamada com pouca frequência, onde as instâncias nunca ficam aquecidas. Esses não são casos extremos: são os padrões onde a experiência do usuário e os resultados do negócio estão em jogo. E são exatamente onde os cold starts se concentram.
Resumo: Um cold start ocorre quando uma função serverless é inicializada do zero porque não existe nenhuma instância aquecida. A inicialização adiciona de 200 ms a mais de 1 segundo de latência nas requisições afetadas. Cold starts não são aleatórios, eles se concentram nos padrões de tráfego de maior valor. Arquiteturas que os eliminam fazem isso mantendo instâncias aquecidas ou usando runtimes que não exigem inicialização a frio.
O que acontece durante um cold start
Um cold start é o tempo entre o recebimento de uma requisição pela plataforma serverless e o início da execução do código da função. Ele inclui várias etapas sequenciais: alocação de um container ou ambiente de execução, carregamento do runtime, importação de dependências e execução de qualquer código de inicialização fora da função handler.
A duração depende do runtime e do tamanho do pacote de deployment. Funções Python e Node.js na AWS Lambda tem cold start em 200 a 800 ms em condições normais. Funções Java e .NET, com runtimes mais pesados, levam de 800 ms a mais de 3 segundos. Uma função com árvores de dependências grandes ou código de inicialização global estende esses números ainda mais.
Para a requisição afetada, esse tempo é somado diretamente ao tempo de resposta visto pelo usuário. Uma função que executa em 20 ms após a inicialização tem um tempo de resposta com cold start de 420 a 3.020 ms. O código da função é rápido. O overhead de infraestrutura não é.
Por que cold starts se concentram nas requisições que mais importam
Cold starts não se distribuem aleatoriamente pelo tráfego. Eles se concentram em três padrões.
Primeiras requisições de novos usuários. Quando um usuário acessa pela primeira vez, nenhuma instância aquecida está esperando. A primeira requisição paga o custo do cold start. Para aplicações onde a primeira impressão importa — onboarding, primeira compra, ativação de trial — esse é o pior momento possível para um pico de latência.
Picos de tráfego. Quando o tráfego cresce mais rápido do que as instâncias aquecidas conseguem absorver, a plataforma escala inicializando novas instâncias. Cada nova instância paga um cold start. Uma campanha de marketing que envia 10x o tráfego normal para uma landing page inicializa muitas instâncias simultaneamente, adicionando latência de cold start exatamente nas requisições que a campanha foi projetada para capturar.
Endpoints de baixo tráfego. Funções chamadas com pouca frequência nunca mantêm instâncias aquecidas. Uma API interna chamada uma vez por hora, um webhook handler, um trigger de background job — todos pagam um cold start em cada chamada. A baixa frequência que torna o cold start inevitável também dificulta o diagnóstico, porque o volume de chamadas é baixo demais para aparecer claramente nos percentis de latência agregados.
Por que pipelines de inferência de AI são especialmente vulneráveis
Cold starts se acumulam dentro de pipelines de inferência de AI de uma forma que não acontece com workloads serverless de função única.
Um AI agent completando uma tarefa geralmente encadeia múltiplas tool calls: uma função recupera contexto, outra consulta um banco de dados, uma terceira chama uma API externa, uma quarta formata e retorna o resultado. Cada chamada nessa cadeia é uma invocação de função separada. Se qualquer uma delas sofrer um cold start, o atraso se soma aos demais. Um pipeline com quatro tool calls, cada uma com 50% de chance de um cold start de 400 ms em média, pode adicionar mais de um segundo de overhead de inicialização a uma tarefa que o modelo subjacente completa em milissegundos.
O problema é estrutural. Pipelines de inferência de AI se expandem para muitas funções em paralelo ou em sequência, e fazem isso em velocidade de máquina — o que significa que o padrão de chamadas infrequentes que causa cold starts no serverless tradicional é comum para funções de ferramentas chamadas apenas quando um tipo específico de tarefa chega. Uma função que lida com análise de imagem pode ser chamada 20 vezes por dia. Ela quase nunca tem uma instância aquecida.
Para aplicações de AI em tempo real — interfaces de voz, assistentes ao vivo, agentes interativos — essa latência não é uma preocupação secundária. Um usuário esperando dois segundos por uma resposta que deveria levar 200 ms experimenta um produto quebrado, não um produto lento. O cold start é indistinguível de uma falha do ponto de vista dele.
Um runtime que elimina cold starts remove completamente esse modo de falha do design de pipeline de AI. As Functions na plataforma da Azion usam V8 isolates e não tem cold start, então uma função de ferramenta chamada uma vez por hora responde com a mesma latência que uma chamada 10.000 vezes por hora. Designers de pipeline não precisam considerar tempo de aquecimento, provisionar concorrência por função ou arquitetar em torno de atrasos de inicialização.
Os padrões arquiteturais que causam cold starts
Cold starts são uma propriedade de como um runtime gerencia ambientes de execução, não uma característica inerente da computação serverless. Runtimes baseados em container geram cold starts porque inicializar um container tem um overhead fixo de inicialização. Reduzir cold starts nesses ambientes exige manter instâncias aquecidas por meio de pings periódicos, provisioned concurrency ou configurações de instância mínima — tudo isso adiciona custo e overhead operacional.
O problema raiz é o próprio modelo de container. Containers oferecem isolamento forte, mas são relativamente pesados. Carregar um runtime, inicializar um processo JVM ou Node.js e importar dependências leva tempo que não pode ser completamente ocultado independentemente de como a infraestrutura é gerenciada.
Uma abordagem diferente usa ambientes de execução mais leves. V8 isolates — a mesma tecnologia que roda JavaScript no Chrome — inicializam em microssegundos em vez de milissegundos. Eles compartilham um único processo mantendo isolamento de memória entre tenants. Não há container para inicializar, nenhum runtime para carregar separadamente e nenhuma fase de importação de dependências no sentido tradicional.
O que zero cold starts realmente significa
As Azion Functions usam o modelo de V8 isolates para execução de JavaScript e TypeScript. Como não há etapa de inicialização de container, a primeira requisição a uma função é executada no mesmo tempo que a centésima. Não há período de aquecimento, nenhuma provisioned concurrency para configurar e nenhum ping periódico para manter instâncias ativas.
Isso não é uma otimização de performance aplicada sobre uma arquitetura de container. É um modelo de execução diferente onde a categoria de cold start simplesmente não existe. A função está disponível para a primeira requisição sem overhead que não esteja presente em todas as requisições subsequentes.
Combinado com a rede distribuída da Azion, o Functions executa na localização mais próxima ao usuário, não em uma região centralizada na nuvem. Um usuário novo em São Paulo chamando uma função deployada na rede da Azion não paga a latência de uma origem centralizada mais um cold start. Ele recebe uma resposta do nó mais próximo sem nenhuma penalidade de inicialização.
Como diagnosticar cold starts em produção
Antes de resolver cold starts, é preciso medi-los. Percentis de latência padrão — p50, p95, p99 — podem ocultar o impacto dos cold starts se as requisições afetadas forem uma pequena porcentagem do volume total. A assinatura do impacto de cold start em dados de produção parece uma distribuição com uma cauda longa em p99 e p99.9 que não corresponde ao tempo de execução esperado da função.
Puxar traces de execução por requisição em vez de percentis agregados revela isso. Um trace que mostra 20 ms de execução do handler e 600 ms de overhead de inicialização é um cold start. Latência p99 agregada que é 10x a latência p50 sem uma explicação clara na complexidade da função é geralmente impacto de cold start em escala.
O Real-Time Events na camada de observabilidade da Azion captura dados de execução por requisição na borda, permitindo identificar overhead de inicialização antes que ele se acumule em um problema visível de produto.
Cold starts não são uma troca aceitável por simplicidade serverless. São um artefato de ambientes de execução baseados em container que modelos de runtime mais leves já resolveram. A questão não é como minimizar o impacto dos cold starts — é se o ambiente de execução exige cold starts.
Fale com um especialista da Azion para ver como as Azion Functions eliminam cold starts com execução em V8 isolates numa rede globalmente distribuída.
Perguntas frequentes
O que é um cold start serverless? Um cold start é a latência adicionada quando uma função serverless é inicializada do zero porque não existe nenhum ambiente de execução aquecido. Inclui alocação de container, carregamento de runtime, importação de dependências e execução de código de inicialização. A duração do cold start varia de 200 ms para funções Node.js leves a mais de 3 segundos para runtimes Java ou .NET com grandes árvores de dependências.
Por que cold starts afetam a performance nas requisições mais importantes? Cold starts se concentram em três padrões de tráfego: primeiras requisições de novos usuários (nenhuma instância aquecida existe ainda), picos de tráfego (o scale-out inicializa novas instâncias simultaneamente) e endpoints de baixo tráfego (instâncias nunca ficam aquecidas entre chamadas). Esses são os padrões onde a experiência do usuário e os resultados do negócio são mais sensíveis à latência, tornando os cold starts um problema de produto, não apenas uma métrica de performance.
Quanta latência os cold starts adicionam? Uma função Node.js ou Python no AWS Lambda adiciona 200 a 800 ms em um cold start. Runtimes Java e .NET adicionam de 800 ms a mais de 3 segundos. Para uma função que executa em 20 ms após a inicialização, o tempo de resposta com cold start é de 10 a 150 vezes o tempo de execução da própria função.
O que é provisioned concurrency e resolve cold starts? Provisioned concurrency mantém um número especificado de instâncias de função inicializadas e prontas, eliminando cold starts para requisições que atingem essas instâncias. Resolve o problema para tráfego previsível, mas adiciona custo proporcional ao número de instâncias mantidas aquecidas. Não ajuda com picos imprevisíveis que exigem scale-out além da contagem provisionada e requer configuração operacional e gerenciamento de custo contínuo.
O que são V8 isolates e como eliminam cold starts? V8 isolates são contextos de execução JavaScript leves que compartilham um único processo V8 mantendo isolamento de memória entre tenants. Ao contrário de containers, inicializam em microssegundos em vez de milissegundos porque não há container a alocar, nenhum runtime a carregar separadamente e nenhuma fase de importação de dependências no sentido tradicional. Funções construídas sobre V8 isolates não têm cold start — as primeiras requisições são executadas com o mesmo overhead de todas as requisições subsequentes.
Por que cold starts são especialmente prejudiciais para pipelines de inferência de IA? AI agents encadeiam múltiplas chamadas de função por tarefa, então a latência de cold start se acumula em cada invocação do pipeline. Uma cadeia de quatro tool calls onde cada função tem 50% de chance de um cold start de 400 ms pode adicionar mais de um segundo de overhead de inicialização a uma tarefa que o modelo subjacente completa em milissegundos. Funções chamadas para tipos específicos de tarefa — análise de imagem, parsing de documentos, lookups especializados — frequentemente são chamadas com pouca frequência a ponto de quase nunca terem instâncias aquecidas, tornando os cold starts quase certos em cada chamada.
Como diagnosticar cold starts em produção? Métricas de latência agregadas padrão ocultam o impacto de cold start. A assinatura em dados de produção é uma cauda longa em p99 e p99.9 desproporcional à latência p50 que não corresponde à complexidade da função. Puxar traces de execução por requisição em vez de percentis agregados revela o overhead de inicialização diretamente — um trace mostrando 20 ms de execução do handler e 600 ms de overhead da plataforma é um cold start.
