Nei workflow basati su agenti LLM, far partire un’operazione non appena è pronta sembra una scelta intuitiva. Un modello conclude un turno, un tool restituisce un risultato, il passaggio successivo viene inviato al sistema di inferenza. Ma quando molte esecuzioni concorrono per le stesse risorse, questa immediatezza può trasformarsi in un problema: i turni già rilasciati si accumulano in coda, mentre il livello che governa il workflow perde la possibilità di stabilire priorità diverse.
È il punto di partenza di Decoupling Readiness from Release for Tail-Aware Scheduling of Agentic LLM Workflows, preprint pubblicato il 10 settembre su arXiv da Bochao Feng, Jianjiang Li, Haojie Wang, Lin Qiao, Yinghui Li, Yukun Yan e Jidong Zhai. Il lavoro descrive un metodo di pianificazione che separa due momenti normalmente sovrapposti: il fatto che un turno sia pronto a essere eseguito e la decisione effettiva di consegnarlo al runtime. In breve, un passaggio pronto non deve necessariamente essere avviato subito.
La proposta interviene su una componente poco visibile all’utente finale, ma decisiva per chi costruisce servizi agentici: la gestione delle code. Il suo obiettivo non è rendere ogni singola generazione più rapida, né modificare il modello linguistico. Cerca invece di ridurre i tempi di completamento dei casi più lenti, quelli che emergono quando il sistema è sotto pressione e che incidono sulla prevedibilità del servizio.
Perché la logica del rilascio immediato può incepparsi
Un agente LLM raramente è una richiesta isolata. In un’attività di software engineering, per esempio, può analizzare un repository, invocare strumenti per cercare file o eseguire test, leggere gli output e poi produrre un nuovo turno di ragionamento o una nuova chiamata. Ogni workflow diventa così una sequenza di turni del modello alternati a interazioni esterne. I tempi dipendono dalla velocità di inferenza, ma anche dalla disponibilità dei tool, dalla dimensione delle code e dall’ordine in cui vengono servite le attività.
Nei runtime che adottano il rilascio eager, ogni turno pronto passa immediatamente allo strato di esecuzione. In una fase di bassa domanda è un comportamento ragionevole: non aggiunge attese artificiali e, secondo gli autori, il metodo proposto ottiene risultati comparabili in condizioni di carico leggero. Il quadro cambia con molte richieste simultanee. Si formano allora code di lavori già ammessi ma non conclusi; una volta entrati in quella coda, i turni non possono più essere riordinati dalla politica che conosce lo stato complessivo dei workflow.
Questo dettaglio conta soprattutto per la latenza di coda, spesso riassunta da percentili come il P95. Se il sistema impiega molto tempo a completare il 5% più lento dei workflow, l’esperienza percepita diventa irregolare anche quando la media resta accettabile. Per applicazioni interne può significare pipeline meno affidabili; per prodotti esposti a clienti o sviluppatori, tempi di risposta difficili da prevedere e una capacità infrastrutturale utilizzata con minore controllo.
La proposta: controllare l’ingresso nella coda
Il meccanismo studiato dagli autori decide quali turni pronti rilasciare e quanti lavori non ancora terminati mantenere contemporaneamente nel sistema. L’idea non è bloccare indiscriminatamente l’esecuzione, ma lasciare margine alla pianificazione prima che i task diventino parte di una coda difficilmente modificabile.
Per scegliere le priorità, il metodo combina stime online del lavoro richiesto da ciascun turno con un obiettivo che tiene conto del rischio nella coda dei tempi di completamento. Il lavoro usa una formulazione media-CVaR, dove CVaR, Conditional Value-at-Risk, è una misura impiegata per dare maggior peso agli esiti sfavorevoli oltre una certa soglia. Applicata qui, serve a non ottimizzare soltanto il tempo medio, ma a considerare l’evoluzione dei workflow che rischiano di diventare i più ritardati.
Il secondo elemento è un budget dinamico per il lavoro rilasciato ma ancora incompleto. Il sistema lo adatta alla pressione osservata nella coda: se aumentano congestione e rischio di ritardo, può essere più selettivo nell’ammettere nuovi turni; quando la pressione cala, può allentare il controllo. La scelta prova a evitare due estremi: saturare il runtime con richieste in attesa oppure trattenere troppo lavoro, lasciando risorse inutilizzate.
Dal punto di vista architetturale, è un cambio di responsabilità. Il runtime di inferenza continua a eseguire i turni ricevuti, mentre il workflow scheduler conserva più a lungo la facoltà di decidere quali passaggi meritino accesso immediato. La disponibilità tecnica di un turno diventa dunque diversa dalla sua immissione effettiva nella coda di servizio.
I risultati dichiarati e il perimetro della ricerca
La valutazione utilizza tracce reali di esecuzioni agentiche legate a compiti di ingegneria del software, considerate su più LLM e a diversi tassi di arrivo dei workflow. Gli autori riferiscono prestazioni paragonabili al rilascio immediato in condizioni leggere e una riduzione sostanziale del P95 del tempo di flusso sotto contesa. Nel miglior caso riportato, lo speedup arriva fino a 3,50 volte.
Il dato va letto per ciò che è: un risultato sperimentale circoscritto al disegno e alle tracce analizzate nel preprint. L’abstract disponibile non indica quali modelli siano stati usati, non quantifica i risultati per ciascun tasso di arrivo e non permette di valutare qui il costo computazionale dello scheduler, la precisione delle stime di lavoro o l’effetto su metriche come throughput, equità tra utenti e tempi mediani. Non è inoltre una pubblicazione sottoposta a peer review: arXiv ospita una versione iniziale del manoscritto, non una certificazione indipendente delle conclusioni.
Ci sono poi trade-off intrinseci. Ritardare un turno che sarebbe potuto partire subito può peggiorare la risposta di un singolo workflow in un dato istante, pur migliorando l’andamento della coda nel suo insieme. Le stime online sul lavoro futuro possono essere imperfette, soprattutto perché la lunghezza della generazione, l’esito di una chiamata a un tool e i passaggi successivi non sono sempre prevedibili. Un sistema operativo dovrà quindi definire con attenzione quali utenti, flussi o classi di richieste proteggere quando le risorse non bastano per tutti.
Dove può trovare applicazione
La ricerca è rilevante per i gestori di piattaforme che eseguono agenti su larga scala, ma anche per i team che orchestrano modelli e tool in ambienti aziendali. Finora gran parte dell’attenzione sulle prestazioni degli LLM si è concentrata su hardware, batching, caching e velocità di decoding. Nei workflow composti, tuttavia, la qualità del coordinamento tra più turni può pesare quanto il tempo di una singola risposta.
Un sistema di questo tipo potrebbe essere integrato sopra un runtime esistente come livello di admission control e prioritizzazione, a condizione di avere visibilità sui workflow e sulle loro dipendenze. È una condizione importante: la tecnica è più naturale nei servizi che controllano l’intera orchestrazione, meno in scenari nei quali chiamate e code sono distribuite tra fornitori, strumenti esterni o componenti senza uno stato condiviso.
Il prossimo passaggio non è un prodotto annunciato, ma la verifica della generalizzabilità. Serviranno confronti su workload diversi dal software engineering, analisi dell’impatto su costi e throughput, e test in presenza di tool con tempi molto variabili. Se i risultati saranno confermati, la lezione più ampia è che per gli agenti LLM la prontezza di un nuovo passo non coincide sempre con il momento migliore per eseguirlo. Gestire quella differenza può diventare una leva concreta per rendere i sistemi meno esposti ai ritardi estremi.
