Il ciclo di retry che aumenta la spesa di inferenza
Updated August 27, 2026 · first published August 27, 2026
Un retry non è resilienza gratuita: è una nuova chiamata al modello a pagamento. Un agente autonomo può trasformare un errore temporaneo in cinque tentativi fatturati prima ancora che venga segnalato un blocco. Il primo controllo FinOps consiste nel misurare la tassa sui retry: spesa per retry e fallback divisa per la spesa totale di inferenza.
Tracciare l'intero albero dei tentativi
Registrate richiesta padre, numero di tentativo, provider, modello, invocazione di tool, latenza, classe di errore, token e risultato finale. Un ID richiesta generico non basta quando un tool genera chiamate annidate; tracciate le relazioni padre-figlio per ricostruire l'intero albero di esecuzione.
Distinguere errori utili da sprechi deterministici
Ritentare una richiesta per superamento temporaneo di rate limit può recuperare un task prezioso. Ripetere una validazione fallita con il medesimo prompt compra quasi sempre un altro errore identico. Assegnate a ogni categoria di errore un tetto massimo di tentativi e un percorso di fallback appropriato.
Fissare budget sul confine del loop
Applicate un tetto di token per richiesta, un limite in dollari per workflow e un timeout massimo di esecuzione. I limiti rigidi devono fermare il ciclo a runtime restituendo uno stato recuperabile, senza affidarsi a report mensili.
La soluzione durevole non è disabilitare i retry, ma renderli visibili, circoscritti e giustificati da un miglioramento misurabile dell'outcome.
Related
Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →