LLM e retry: perché cancellare non basta al recupero

In breve: La sola cancellazione non ha ripristinato il servizio nei run di sovraccarico studiati mentre i client continuavano a ritentare. Il controllo deve anche limitare le nuove esecuzioni oppure collegare il retry a un’esecuzione ancora viva. Non segue che cancellare sia inutile: il punto è scegliere se proteggere soprattutto le chiamate successive o recuperare anche quelle già in ritardo. Scheda canonica e cronologia.

Preprint v1 del 5 novembre 2026, verificato il 9 novembre. Lettura integrale e confronto con fonti originali; gli esperimenti appartengono agli autori, non sono stati replicati per questa analisi.

Una chiamata può diventare quattro esecuzioni

Il passaggio utile è separare la richiesta dell’applicazione, i tentativi del client e il lavoro creato nel motore. Nel protocollo ogni chiamata può avere un tentativo iniziale e tre retry. Se ciascuno crea un’esecuzione distinta, un flusso di nuove chiamate al 60% della capacità può offrire lavoro equivalente al 240% della capacità: il traffico nuovo è sceso, ma il lavoro complessivo no.

Il test usa un client emulato con scadenza complessiva di 120 secondi per tentativo e attese casuali di 0,25-3 secondi prima del retry. Non riproduce semplicemente le impostazioni standard di un SDK. Il carico resta aperto: arrivano nuove chiamate anche se le precedenti non sono finite. Per questo il risultato descrive una specifica dinamica di coda, non qualsiasi applicazione che usi un modello linguistico. Definizioni e protocollo sperimentale.

Nelle tracce di Qwen2.5-7B-Instruct, tutti gli abort registrati seguono l’abbandono del client entro mezzo secondo. Eppure i retry che arrivano a essere eseguiti iniziano tipicamente il prefill quasi alla propria scadenza. Il problema osservato non richiede quindi una cancellazione persa nella rete: può sopravvivere anche quando la cancellazione arriva, perché la coda continua a ricevere nuovi tentativi destinati a scadere. Gli autori presentano questa spiegazione come coerente con le tracce, non come una legge universale. Tracce e tempi dei retry.

Recupero del servizio e consegna delle risposte sono metriche diverse

Gli autori caricano il motore al 60% della capacità calibrata, applicano un picco di 107 secondi al 270% e osservano altri 720 secondi al carico iniziale. Una risposta conta come consegnata se arriva completa entro 840 secondi dall’arrivo previsto della sua chiamata. È un orizzonte di misura, non una promessa di risposta rapida.

Il recupero richiede invece due finestre consecutive di 60 secondi in cui almeno il 98% delle chiamate sia completato entro 120 secondi, con code piccole e stabili. Un sistema può soddisfare questo criterio sulle chiamate recenti e avere già perso quelle del picco. Dire soltanto che una protezione “ripristina il servizio” nasconde questa differenza. Definizione delle coorti, della consegna e del recupero.

Nel blocco diagnostico con retry e cancellazione attivi, le chiamate arrivate dopo il picco consegnate entro l’orizzonte sono il 13,3-15,2% per Qwen2.5-7B-Instruct, il 28,1-35,7% per Qwen3-14B e il 36,9-37,7% per Llama-3.1-8B-Instruct. Il 12-38% dell’abstract comprende anche il distinto esperimento con prompt misti, che scende al 12,1%. Non è un unico intervallo statistico ottenuto ripetendo molte volte lo stesso caso. Risultati diagnostici e variante con prompt misti.

Il budget protegge il seguito; il coalescing conserva il lavoro

Il budget sperimentale limita i retry al 10% dei primi tentativi in una finestra mobile di 60 secondi. Rifiuta l’eccesso con una risposta 429 e un’attesa suggerita. Così può evitare che i retry mantengano il sovraccarico, ma non garantisce che il client riceva il risultato della chiamata originaria.

Il request coalescing percorre un’altra strada: riaggancia il retry all’esecuzione viva della stessa chiamata e gli ripropone l’output già prodotto. Non è una cache dei risultati conclusi e non significa unire richieste di utenti diversi solo perché hanno prompt simili. Nel confronto senza cancellazione, ripristina il servizio su tutti e tre i modelli e consegna tutte le chiamate del picco e del periodo successivo entro l’orizzonte osservato, alcune oltre 120 secondi. Confronto tra budget e riaggancio.

Non esiste però un vincitore indipendente dall’obiettivo. In un blocco separato su Qwen2.5-7B-Instruct, budget più cancellazione consegnano entro 120 secondi il 99,1-99,4% della coorte primaria, che esclude i primi 120 secondi dopo il picco. Il riaggancio con cancellazione differita si ferma all’88,7-89,3% entro quel termine, ma recupera tutte le chiamate del picco. Il confronto combina due differenze, riaggancio e differimento: non isola l’effetto del solo timer. Un agente che deve completare ogni passaggio e un’interfaccia che preferisce un rifiuto a una risposta tardiva stanno ottimizzando risultati diversi. Confronto con cancellazione attiva.

L’ordine delle decisioni conta più di un interruttore

Se il proxy cancella l’esecuzione appena il client si scollega, il retry non trova più nulla a cui riagganciarsi. Negli esperimenti su Qwen2.5-7B-Instruct, attendere 10 secondi dall’uscita dell’ultimo sottoscrittore, più del backoff del client, permette il riaggancio e il recupero. Ma in quei run nessuna esecuzione viene poi cancellata: la pulizia dopo un abbandono definitivo non è stata verificata. Dieci secondi non sono quindi un valore da copiare senza misurare client, code e vincoli applicativi. Riaggancio e cancellazione differita.

Anche controllare il budget prima della ricerca dell’esecuzione può rifiutare un retry che non aggiungerebbe lavoro al motore. Cercare prima aumenta soprattutto le consegne tardive, senza aumentare le esecuzioni ammesse nel confronto riportato. È una ragione concreta per distinguere un nuovo lavoro da un nuovo collegamento allo stesso lavoro. Il paper, però, non testa la combinazione di ricerca prima del budget e cancellazione differita, né coalescing insieme ai limiti di coda. Queste combinazioni restano da verificare. Ordine tra ricerca e budget e limiti dichiarati dagli autori.

Un contatore dei token non è un misuratore del costo GPU

Le tracce attribuiscono alle esecuzioni poi abortite circa il 79-85% dei token di prompt effettivamente calcolati. È un risultato sul prefill di Qwen2.5-7B-Instruct nel testbed: non significa che l’85% dell’energia, della fattura o del tempo fisico GPU sia sprecato. Gli autori non eseguono un profiler GPU e separano esplicitamente token calcolati e tempo attribuito agli step dello scheduler. Come viene contato il lavoro di prefill.

C’è poi una lacuna di osservabilità. Il contatore dei prompt viene aggiornato al completamento del prefill, quando compare il primo output. Il lavoro di un’esecuzione abortita prima di quel punto non entra nel conteggio. Con step da 8.192 token, le esecuzioni abortite prima del primo output detengono il 47,3-50,3% dei token di prompt calcolati sull’intero run. Non è una misura equivalente al divario con il contatore dei token ammessi, che usa un’altra base di confronto e include anche token da cache. Analisi del contatore nel paper e progetto delle metriche nella versione vLLM studiata.

La conseguenza operativa è tenere un registro separato di chiamate, tentativi, esecuzioni create, ammesse, abortite e risposte complete ricevute. Un contatore basso, da solo, non dimostra che il servizio stia recuperando o che stia consumando poche risorse.

Cosa trasferire a un workflow, e cosa lasciare al testbed

Per un workflow serve prima una domanda di prodotto: una risposta in ritardo è ancora utile oppure deve essere abbandonata? Poi serve un’identità stabile della chiamata attraverso i retry. Riagganciare richiede anche che ogni tentativo raggiunga lo stato della sua esecuzione: più proxy dietro un bilanciatore non lo garantiscono automaticamente. Il paper non prova questa architettura distribuita. Requisiti e limiti della proposta.

Va inoltre distinta l’identità del calcolo dall’idempotenza degli effetti. Non duplicare un’inferenza non dimostra che un workflow eviti due invii o due aggiornamenti successivi. La guida n8n AI su retry, idempotenza, approval gate e audit affronta quel livello applicativo: è un approfondimento collegato, non un’implementazione validata da questo paper.

Le 137 esecuzioni sperimentali complessive sono distribuite tra condizioni diverse, spesso con poche ripetizioni: gli intervalli sono minimi e massimi, non intervalli di confidenza. Il tracciamento dettagliato riguarda un solo modello. Con un picco più piccolo, pari a 1,5 volte la capacità, tutti e tre recuperano anche con i retry. Non c’è quindi una soglia universale né la prova che qualsiasi retry provochi il collasso. Restano fuori altri motori, tensor parallelism, client a ciclo chiuso e più repliche. Numerosità degli esperimenti, variazione del picco e limitazioni.

Checklist pratica, senza cambiare subito la produzione

Questa è una verifica documentale e progettuale proposta, non un test già eseguito.

• Scegli un solo workflow e un solo endpoint; scrivi se conta la consegna entro la scadenza o anche il completamento tardivo.
• Elenca timeout, numero massimo di tentativi, backoff e gestione di Retry-After a ogni livello. Non assumere che client, proxy e motore abbiano la stessa scadenza.
• Disegna tre identità distinte: chiamata applicativa, tentativo ed esecuzione del motore. Verifica dove un retry crea nuovo lavoro.
• Se prevedi il riaggancio, conserva un identificatore stabile della stessa chiamata e parametri coerenti; documenta dove risiede lo stato e chi può accedervi.
• Separa uno stop esplicito dell’utente da una disconnessione recuperabile. Stabilisci durata massima, limiti di memoria e pulizia degli orfani, senza adottare i 10 secondi come default universale.
• Prepara soltanto in ambiente isolato un eventuale replay di input sintetici autorizzati, con limiti di concorrenza, durata e consumo fissati prima dell’avvio. Questo articolo non lo ha eseguito.
• Se una prova viene autorizzata, confronta una modifica alla volta e registra anche chiamate perse, ritardi, abort ed esecuzioni duplicate, non soltanto token al secondo.
• Non promuovere una configurazione perché torna “verde”: controlla separatamente recupero delle chiamate recenti, destino di quelle del picco e pulizia dopo un abbandono definitivo.

Condizioni e limitazioni

Preprint del 5 novembre 2026, con vLLM 0.30.0, una H100 per run, tre modelli e carico sintetico. Non è una prova su n8n, su altri engine o su un servizio distribuito; non è stato eseguito un benchmark indipendente per questa analisi.