Il mito del serverless secondo cui "paghi solo per i millisecondi in cui il tuo codice viene eseguito" crolla quando si prova a eseguire un agente AI su AWS Lambda. In pratica, le voci di spesa più rilevanti non sono i costi di calcolo di Lambda, ma la latenza del cold start, i cicli di retry e l'utilizzo di token generato da tali cicli.

Perché la visione convenzionale del serverless trae in inganno gli agenti AI

La maggior parte degli sviluppatori tratta una funzione Lambda come una pura sandbox di calcolo: mantieni l'handler veloce, imposta una dimensione di memoria modesta e osserva la bolletta rimanere costante. Questo funziona per semplici endpoint HTTP, ma un agente che chiama un modello linguistico, ne valuta la risposta e possibilmente riprova l'intero ciclo non corrisponde uno a uno a una singola invocazione Lambda. Il workflow interno dell'agente moltiplica il numero di chiamate al modello, e ogni chiamata extra aggiunge un costo in token che può oscurare le spese di calcolo.

I cold start sono il costo nascosto

Quando un container Lambda viene provisionato per la prima volta, deve decomprimere il pacchetto di deployment. L'agente in questione importa un vasto set di librerie Python, quindi l'immagine può essere ingombrante. Eliminare gli strumenti di solo sviluppo — come una libreria di automazione del browser utilizzata solo per i test locali — riduce la dimensione dell'immagine, il che a sua volta accorcia i tempi di decompressione. Un pacchetto più snello significa che la funzione è pronta a gestire una richiesta più velocemente, riducendo il tempo trascorso in attesa del riscaldamento (warm up) del container.

Un secondo fattore è la collocazione del codice di inizializzazione. Costruendo il grafo dell'agente al momento dell'importazione del modulo, il lavoro pesante avviene una sola volta per l'avvio del container, anziché ad ogni richiesta. Le invocazioni "warm" saltano quindi completamente questo passaggio. Il compromesso è un cold start leggermente più lungo, ma il vantaggio è un tempo di configurazione per richiesta quasi nullo una volta che il container è caldo.

La memoria funge anche da regolatore della latenza

Su Lambda, la quantità di memoria allocata determina anche la quota di CPU che la funzione riceve. Impostare la funzione a 1 GB di memoria le garantisce un intero core di CPU virtuale. La CPU extra accelera l'importazione delle librerie e la creazione del grafo dell'agente, riducendo sia la latenza del cold start che quella di warm-up.

Il costo del ciclo: i retry moltiplicano la spesa in token

L'agente segue un ciclo worker-evaluator. Il worker genera una risposta, l'evaluator la controlla e, se l'evaluator segnala un errore, il compito viene rimandato al worker. Il ciclo può ripetersi fino a cinque volte prima di arrendersi. Ciò significa che una singola richiesta esterna può innescare:

  • fino a cinque chiamate al modello worker
  • fino a cinque chiamate al modello evaluator
  • qualsiasi numero di chiamate a tool che l'agente decide di effettuare

La bolletta Lambda rimane prevedibile perché AWS addebita in base ai millisecondi di esecuzione, ma la spesa per i token può oscillare selvaggiamente a seconda di quanti retry sono necessari.

La trappola del timeout: API Gateway vs. Lambda

API Gateway impone un timeout rigido di 29 secondi sulla richiesta HTTP che gestisce. Un ciclo dell'agente di cinque iterazioni può facilmente superare questo limite, anche se la funzione Lambda sottostante è configurata per una finestra di esecuzione di cinque minuti. Aggirare API Gateway utilizzando le Lambda Function URL rimuove il limite dei 29 secondi, consentendo alla funzione di completare il proprio ciclo senza essere interrotta.

Cosa dovrebbero prevedere gli sviluppatori nel budget

La lezione è semplice: pianificare il budget per un agente AI serverless richiede molto più che sommare i millisecondi di runtime di Lambda. È necessario tenere conto di:

  • la dimensione del pacchetto di deployment e la conseguente latenza del cold start
  • l'impostazione della memoria che determina la CPU e quindi la velocità di importazione
  • il numero previsto di retry nel ciclo worker-evaluator, che guida direttamente l'utilizzo dei token
  • la scelta del front-end (API Gateway vs. Function URL) per evitare timeout prematuri

Ignorare una qualsiasi di queste variabili può lasciarti con una bolletta che non somiglia affatto a quella che avevi previsto.