Chiosa
IT
Systems & Infrastructure

Uno scheduler usa i tempi degli strumenti per assegnare le sessioni AI in attesa

TAO: Tool-Aware Joint Scheduling for LLM-Based Agentic Serving · arXiv:2610.37230

4 min
Aggiornato
The TAO evaluate-then-decide framework in CGDC. External tools on distributed CPUs provide historical tool-call durations, while the serving engines on clustered GPUs provide cache observations.…
The TAO evaluate-then-decide framework in CGDC. External tools on distributed CPUs provide historical tool-call durations, while the serving engines on clustered GPUs provide cache observations. Then, the session evaluation component constructs triplets (decayed KV-cache…Figure 2 · TAO: Tool-Aware Joint Scheduling for LLM-Based Agentic Serving · Shuhuai Li et al. · CC BY 4.0

In parole semplici

Gli agenti AI si alternano tra richieste a un modello linguistico e attese per strumenti esterni, come un compilatore. Mentre un agente aspetta, la sua GPU può servire un altro agente.

Il paper presenta TAO, uno scheduler che usa il possibile momento di ritorno degli strumenti, i dati riutilizzabili della conversazione e la dimensione della sessione per decidere quali sessioni in attesa assegnare a quali GPU.

Nelle 12 combinazioni riportate di modello, carico di lavoro e concorrenza, la riduzione massima della durata media delle attività con TAO è stata del 26.8% rispetto al miglior scheduler valutato per quella misura. La durata include anche l'esecuzione degli strumenti e il miglior risultato non si è verificato in ogni configurazione.

La ricerca

Quando un agente AI aspetta uno strumento esterno, la capacità GPU che usava può servire un'altra sessione, ma lo scheduler deve anche stimare quando l'agente riprenderà.

Come può scegliere tra sessioni che competono per gli stessi nodi GPU, tenendo conto dei dati di cache riutilizzabili e dando servizio a quelle che probabilmente avranno presto bisogno del modello?

TAO combina i tempi di ritorno degli strumenti, il riuso della cache e la dimensione delle sessioni per scegliere e posizionare gli agenti in attesa entro i limiti di capacità delle GPU.

TAO confronta il proprio scheduler con alternative valutate in 12 configurazioni di modello, carico di lavoro e concorrenza. Le riduzioni massime riportate sono del 26.8% nella latenza media delle attività e del 36.3% nel tempo medio fino al primo token; il throughput di decodifica è aumentato al massimo del 29.5%.

La latenza delle attività include l'esecuzione degli strumenti e ciascun massimo è relativo al miglior metodo di confronto valutato per quella misura e configurazione.

Questi risultati sostengono l'affermazione che TAO possa migliorare le prestazioni del serving nelle condizioni testate, ma i guadagni non sono uniformi. A 128 worker, con Qwen3-32B e SWE-verified, la latenza media delle attività con TAO era superiore del 2.5% a quella con ThunderAgent.

I miglioramenti riportati sono i massimi osservati in 12 combinazioni di modello, carico di lavoro e concorrenza; non valgono per ogni configurazione.

Il limite calcolato dal paper per i piani applicati dopo uno snapshot riguarda il valore della pianificazione nelle condizioni dichiarate: non limita la latenza delle attività né lo scarto rispetto a uno scheduler online globalmente ottimale.

Cosa mostrano le prove

  • La domanda di pianificazione

    TAO è un framework di pianificazione congiunta che considera gli strumenti per il serving di agenti basati su modelli linguistici. Le sessioni degli agenti alternano richieste a un modello su GPU in cluster e chiamate a strumenti esterni su CPU distribuite.

    Quando uno strumento è in esecuzione, la sessione non ha bisogno dell'inferenza su GPU: lo scheduler può quindi assegnare quella capacità altrove. La domanda è come stimare quando la sessione tornerà e scegliere tra più sessioni che competono per gli stessi nodi.

  • Perché le scelte congiunte contano

    Gli scheduler esistenti possono trascurare i tempi di ritorno degli strumenti e decidere ammissione e posizionamento con euristiche applicate a ogni sessione separatamente. Ma le sessioni competono per la capacità condivisa dei nodi: sceglierne una può escludere una combinazione più vantaggiosa di altre.

    TAO assegna un valore a ogni coppia idonea sessione–nodo in base, nell'ordine, al credito della cache, alla probabilità che uno strumento restituisca presto il controllo e al numero di token; poi sceglie congiuntamente le assegnazioni rispettando i limiti di capacità dei nodi.

  • Cosa mostrano i risultati principali

    Il paper confronta TAO con gli scheduler valutati in 12 configurazioni di modello, carico di lavoro e concorrenza. Riporta miglioramenti relativi massimi del 26.8% nella latenza media end-to-end delle attività, del 36.3% nel tempo medio fino al primo token e del 29.5% nel throughput di decodifica.

    La latenza include l'inferenza del modello e l'esecuzione degli strumenti; il throughput conta i token in uscita al secondo. Ogni massimo è relativo al miglior metodo di confronto valutato per quella misura e configurazione, che può variare.

  • Una configurazione con latenza più alta

    I massimi non indicano miglioramenti in ogni configurazione. In un confronto riportato con Qwen3-32B su SWE-verified a 128 worker, la latenza media delle attività con TAO era superiore del 2.5% a quella con ThunderAgent.

    Questo caso chiarisce la portata dei risultati principali: il paper riporta i migliori miglioramenti relativi in un insieme di configurazioni, non garantisce che TAO riduca la latenza in ciascuna di esse.

  • Cosa aggiunge il confronto tra componenti

    Un confronto separato tra componenti ha usato DeepSeek-V4 Flash su SWE-Lite con 32 worker distribuiti su due nodi. TAO completo ha prodotto 1,417.97 token in uscita al secondo; le varianti che rimuovevano il valore della cache o il segnale di prontezza, cambiavano l'ordine di sospensione o sostituivano la ripresa congiunta hanno ottenuto un throughput inferiore.

    In quella configurazione, il confronto sostiene l'interpretazione che contribuiscano sia la valutazione sia le decisioni di ripresa, ma il singolo caso limita la portata con cui si possono estendere tali effetti.

Dettagli

Paper successivoKVStream sfrutta lo storage inattivo per accelerare il serving dei modelli con contesti lunghi