O mito serverless de que “você só paga pelos milissegundos em que seu código é executado” desmorona quando você tenta rodar um agente de IA no AWS Lambda. Na prática, os maiores itens da fatura não são a cobrança de computação do Lambda, mas sim a latência de cold-start, os loops de retry e o uso de tokens que esses loops geram.
Por que a visão usual de serverless engana ao lidar com agentes de IA
A maioria dos desenvolvedores trata uma função Lambda como um sandbox de computação puro: mantenha o handler rápido, defina um tamanho de memória modesto e observe a conta permanecer estável. Isso funciona para endpoints HTTP simples, mas um agente que chama um modelo de linguagem, avalia a resposta e possivelmente repete todo o ciclo não se traduz de forma direta para uma única invocação do Lambda. O fluxo de trabalho interno do agente multiplica o número de chamadas ao modelo, e cada chamada extra adiciona um custo de tokens que pode eclipsar a cobrança de computação.
Cold starts são o custo oculto
Quando um container Lambda é provisionado pela primeira vez, ele precisa descompactar o pacote de implantação (deployment package). O agente em questão importa um grande conjunto de bibliotecas Python, portanto, a imagem pode ser volumosa. Remover ferramentas exclusivas de desenvolvimento — como uma biblioteca de automação de navegador usada apenas para testes locais — reduz o tamanho da imagem, o que, por sua vez, encurta o tempo de descompactação. Um pacote mais enxuto significa que a função fica pronta para lidar com uma requisição mais rápido, reduzindo o tempo gasto esperando o aquecimento (warm up) do container.
Um segundo fator é onde o código de inicialização reside. Ao construir o grafo do agente no momento da importação do módulo, o trabalho pesado acontece apenas uma vez por início de container, em vez de em cada requisição. Invocações "warm" então pulam esse trabalho completamente. A compensação é um cold start ligeiramente mais longo, mas a recompensa é um tempo de configuração por requisição quase zero após o container estar aquecido.
A memória também funciona como um ajuste de latência
No Lambda, a quantidade de memória que você aloca também determina a parcela de CPU que a função recebe. Configurar a função com 1 GB de memória concede a ela um núcleo de CPU virtual completo. O CPU extra acelera a importação de bibliotecas e a criação do grafo do agente, reduzindo tanto a latência de cold-start quanto a de warm-up.
O custo do loop: retries multiplicam o gasto de tokens
O agente segue um loop worker-evaluator. O worker gera uma resposta, o evaluator a verifica e, se o evaluator sinalizar um erro, a tarefa é enviada de volta ao worker. O loop pode se repetir até cinco vezes antes de desistir. Isso significa que uma única requisição externa pode disparar:
- até cinco chamadas ao modelo worker
- até cinco chamadas ao modelo evaluator
- qualquer número de chamadas de ferramentas que o agente decidir fazer
A fatura do Lambda permanece previsível porque a AWS cobra por milissegundo de execução, mas a fatura de tokens pode oscilar drasticamente dependendo de quantos retries são necessários.
A armadilha do timeout: API Gateway vs. Lambda
O API Gateway impõe um timeout rígido de 29 segundos na requisição HTTP que ele gerencia. Um loop de agente de cinco turnos pode facilmente exceder esse limite, mesmo que a função Lambda subjacente esteja configurada para uma janela de execução de cinco minutos. Ignorar o API Gateway usando Lambda Function URLs remove o teto de 29 segundos, permitindo que a função termine seu loop sem ser interrompida.
O que os desenvolvedores devem incluir no orçamento
A lição é simples: orçar um agente de IA serverless exige mais do que apenas somar os milissegundos de tempo de execução do Lambda. Você precisa considerar:
- o tamanho do pacote de implantação e a latência de cold-start resultante
- a configuração de memória que determina a CPU e, consequentemente, a velocidade de importação
- o número esperado de retries no loop worker-evaluator, que impulsiona diretamente o uso de tokens
- a escolha do front-end (API Gateway vs. Function URL) para evitar timeouts prematuros
Ignorar qualquer uma dessas variáveis pode resultar em uma fatura que não se parece em nada com a que você projetou.
