Gli agenti AI passano troppo tempo ad aspettare: TomasuLLM prova l’esecuzione fuori ordine

Un coding agent può ragionare in millisecondi e poi restare fermo trenta secondi ad aspettare una suite di test. Può sapere già che, se quel comando va bene, il passo successivo sarà quasi certamente un altro comando; eppure non lo esegue, perché il modello vede il mondo come una sequenza ordinata di azioni e osservazioni. Prima fai A, poi aspetti il risultato di A, poi decidi B.

È un modello semplice. È anche un modello che spreca tempo quando gli strumenti sono lenti.

Il paper TomasuLLM: Out-of-Order Speculative Execution for LLM Agents prova a rompere proprio questo vincolo. La proposta prende in prestito un’idea vecchia e potentissima dall’architettura dei processori: se riesci a prevedere lavoro futuro senza renderne subito visibili gli effetti, puoi iniziare prima e decidere dopo se quel lavoro merita davvero di essere committato.

La parte interessante non è eseguire più cose in parallelo. È separare il momento in cui il lavoro parte dal momento in cui il risultato diventa vero per il sistema.

Il collo di bottiglia non è sempre il modello

Quando parliamo di performance degli agenti AI tendiamo a guardare token al secondo, dimensione del modello, caching del prompt o costo di inferenza. Ma un agente che lavora davvero su software passa una parte importante del proprio tempo dentro strumenti esterni: compiler, test, grep, build, comandi repository, script, servizi locali.

Durante quell’attesa il modello non sta necessariamente facendo qualcosa di utile. Il paper chiama questo fenomeno observation stall: l’azione successiva non può essere emessa perché l’osservazione precedente non è ancora arrivata, anche quando una parte del lavoro futuro è prevedibile.

Il parallelismo classico aiuta quando il modello emette più tool call nello stesso turno. Non risolve invece il tempo morto tra i turni. Se il passo B può essere ipotizzato soltanto mentre A è ancora in esecuzione, serve un meccanismo diverso.

TomasuLLM non anticipa la verità: anticipa il lavoro

La distinzione è fondamentale. TomasuLLM non prende una previsione del modello e la tratta come se fosse già successa. Il runtime separa tre momenti: predire un’azione futura, eseguirla in isolamento, decidere più tardi se quel risultato è ancora valido rispetto allo stato realmente confermato.

Un Action Drafter propone tool call future. Un Observation Drafter prova a prevedere l’osservazione che permetterebbe di continuare a generare passi successivi. Le azioni anticipate vengono poi eseguite in sandbox copy-on-write private, mentre il percorso canonico dell’agente continua a determinare quali azioni siano davvero autorizzate.

Il risultato speculativo resta invisibile finché non supera la validazione rispetto allo stato committato. Questo è il pezzo che rende l’analogia con l’esecuzione fuori ordine delle CPU più di una metafora: issue ed execution possono anticipare; il commit resta ordinato.

La sandbox serve perché prevedere male è normale

Una previsione sbagliata non deve contaminare il workspace. Per questo TomasuLLM esegue i rami speculativi in overlay copy-on-write isolati e registra ciò che ogni tool legge e ciò che prova a modificare.

Il paper introduce una rappresentazione di tracing, chiamata Trace IR, che conserva l’azione canonica, le versioni dei file lette, l’osservazione prodotta e gli effetti che verrebbero pubblicati. Prima del commit il runtime controlla che le dipendenze non siano diventate obsolete e che l’esecuzione resti compatibile con lo stato confermato.

Se nel frattempo un passo precedente ha cambiato una dipendenza necessaria, il risultato speculativo viene scartato o rieseguito. È lo stesso principio che rende possibile la speculazione nei sistemi seri: puoi sbagliare previsione, ma devi confinare il costo dell’errore.

Questa distinzione richiama un tema che torna continuamente negli agenti: il risultato utile non è “il modello ha fatto progresso”, ma un artefatto verificabile e compatibile con lo stato reale. Ne avevo parlato anche nell’articolo su perché un agente al 60% può comunque aver fallito.

Non tutto può essere speculato

Qui TomasuLLM diventa più interessante di un generico “facciamo tutto in parallelo”. Alcune azioni sono vere e proprie speculation barrier: effetti irreversibili, operazioni non deterministiche o dipendenze che il runtime non riesce a tracciare in modo conservativo non possono essere anticipate con la stessa libertà.

Un test che legge file già esistenti può essere un buon candidato. Una modifica il cui contenuto dipende da ciò che l’agente ha appena letto è diversa: anticiparla significherebbe inventare una scrittura prima che l’agente l’abbia effettivamente scelta. Un riavvio di servizio introduce un altro tipo di dipendenza, perché un overlay può contenere file nuovi ma non può fingere che un processo condiviso li abbia già caricati.

Il valore del runtime non sta quindi nel massimo parallelismo possibile, ma nel trovare il massimo parallelismo corretto dato il grafo reale delle dipendenze.

I benchmark mostrano un guadagno, non una magia

Gli autori riportano tre risultati principali: uno speedup medio di 1,31× su 100 task SWE-bench Verified, 1,35× su 28 task Terminal-Bench 2.0 e 1,27× di matched progress su 18 sessioni SWE-Marathon. Su 4.010 record di commit-validation auditati dichiarano zero false accept.

Questi numeri vanno letti nel loro perimetro. Sono risultati del paper, non una replica indipendente, e il campione cambia tra benchmark. “Zero false accept” non significa che qualsiasi speculazione sia corretta: significa che, nei record auditati e secondo gli invarianti usati dagli autori, nessun risultato non valido è stato accettato come valido.

Il dato più utile, però, è un altro: il vantaggio cresce quando la latenza dei tool cresce. Per chiamate molto rapide l’infrastruttura speculativa può costare più del tempo che riesce a nascondere.

Nel setup descritto dal paper, preparare la speculazione introduce costi nell’ordine dei secondi; le sandbox private possono richiedere ancora di più. Gli autori stimano inoltre circa 2,1 secondi di compute speculativo per ogni secondo di wall-clock eliminato, oltre ai token del drafter. Quindi no: non è “performance gratis”.

La latenza può diminuire mentre il consumo totale aumenta. Ottimizzare il tempo e ottimizzare il costo non sono la stessa cosa.

È qui che il parallelismo speculativo incontra il budget

Questo articolo arriva quasi come il complemento naturale del tema del tool retrieval sotto budget. Lì la domanda era quali strumenti vale la pena considerare prima di spendere chiamate reali. Qui la domanda è diversa ma confinante: quale lavoro futuro vale la pena iniziare prima che sia certamente necessario?

In entrambi i casi l’agente smette di essere una sequenza ingenua di prompt e tool call. Diventa un sistema che deve allocare risorse: slot di esecuzione, sandbox, token di predizione, tempo, memoria, probabilità di riuso.

La policy sensata non è “specula sempre”. È “specula quando il valore atteso del tempo nascosto supera il costo della speculazione e il rischio può essere confinato”. Tradotto in termini operativi: tool lenti, read set tracciabile, effetti reversibili, buona prevedibilità e dipendenze stabili sono terreno fertile; comandi istantanei o mutazioni opache molto meno.

Il problema vero è il commit, non la previsione

È facile innamorarsi della parte “AI” del sistema: un modello che indovina le prossime azioni e perfino le prossime osservazioni. Ma dal punto di vista architetturale quella è forse la parte meno nuova.

La parte difficile è stabilire quando un lavoro eseguito in anticipo può essere promosso nello stato vero. Devi sapere cosa ha letto, cosa ha scritto, quali effetti esterni ha prodotto, quali versioni sono cambiate e quali invarianti devono ancora valere.

Se non possiedi queste informazioni, la speculazione resta una demo. Se le possiedi, stai costruendo qualcosa che assomiglia molto di più a un runtime transazionale per agenti.

Cosa prenderei da TomasuLLM anche senza implementare TomasuLLM

Non credo che il messaggio utile sia “da domani tutti MCTS, drafter e COW overlay”. Il prototipo descritto nel paper è complesso, ha costi non trascurabili e dipende da wrapper capaci di catturare correttamente dipendenze ed effetti.

• Misurare quanto tempo l’agente passa realmente nei tool prima di ottimizzare il modello.
• Distinguere azioni read-only, reversibili e irreversibili.
• Rendere esplicite dipendenze e versioni dello stato usato da ogni tool.
• Separare il risultato “prodotto” dal risultato “committato”.
• Trattare la speculazione come investimento: ha un costo e deve avere un break-even misurabile.

Questi principi sono utili anche in sistemi molto più semplici. Un worker che prepara una query mentre un’altra operazione è in attesa, un pipeline runner che costruisce un artefatto in una directory temporanea, un agente che prefetch-a documentazione prima di sapere se servirà: sono tutte forme di lavoro anticipato. La differenza tra ottimizzazione e caos è quanto bene sappiamo invalidarlo.

Gli agenti stanno diventando runtime, non soltanto modelli

TomasuLLM è interessante perché sposta ancora una volta l’attenzione dal modello all’infrastruttura che gli sta attorno. Se gli agenti devono eseguire lavoro lungo, costoso e mutativo, la qualità non dipende soltanto dalla capacità di “ragionare” sul prossimo passo.

Dipende da scheduling, isolamento, versionamento dello stato, validazione degli effetti, policy di commit e contabilità delle risorse. Sono problemi da sistemi operativi e database infilati dentro un prodotto che, da fuori, continuiamo a chiamare chatbot.

E forse è proprio questo il segnale più interessante: quando per accelerare un agente iniziamo a parlare di esecuzione fuori ordine, operand readiness, sandbox copy-on-write e commit in-order, significa che il settore sta finalmente pagando il prezzo di rendere il software autonomo davvero operativo.