Riepilogo Tecnico: AGENTSERVESIM

Problematica

Le moderne implementazioni di Large Language Model (LLM) si stanno spostando da query di chat stateless e a turno singolo verso sistemi agentici multi-turno. A differenza del serving tradizionale, dove ogni coppia prompt-completamento è una richiesta indipendente, i sistemi agentici eseguono programmi stateful che intercalano chiamate LLM con invocazioni di strumenti esterni (ad esempio, esecuzione di codice, ricerca web). Queste invocazioni di strumenti introducono intervalli di durata variabile che vanno da millisecondi a minuti.

Questo cambiamento altera fondamentalmente i requisiti di serving:

1. Esecuzione Stateful: La latenza percepita dall'utente è il Job Completion Time (JCT) dell'intero programma, non la latenza dei singoli turni.
2. Dipendenze Cross-Turn: I turni successivi spesso estendono la stessa conversazione, rendendo il riutilizzo del prefisso cross-turno sistematico.
3. Dinamiche della KV-Cache: Lo stato della KV-cache deve sopravvivere agli intervalli indotti dagli strumenti per evitare costosi re-prefill, ma la ritenzione dello stato durante lunghi intervalli spreca memoria scarsa.
4. Complessità di Routing: Nelle implementazioni multi-istanza, il routing deve preservare l'affinità di sessione per mantenere la località della cache, piuttosto che limitarsi al bilanciamento del carico.

Valutare le politiche di scheduling, routing e gestione della KV-cache per questi carichi di lavoro su hardware reale è proibitivamente costoso. Ogni punto di design richiede tempo dedicato su acceleratori, e lo spazio di configurazione (tassi di arrivo, scale del modello, gerarchie di memoria) è troppo vasto per esplorazioni esaustive nel mondo reale. I simulatori esistenti (ad esempio, Vidur, APEX, LLMServingSim) mirano a carichi di lavoro stateless e non riescono a catturare l'identità del programma, i gap degli strumenti o la residenza della KV cross-turno.

Metodologia

Gli autori presentano AGENTSERVESIM, un simulatore hardware-aware progettato specificamente per il serving di agenti LLM multi-turno. Il simulatore tratta il programma agente come l'unità di esecuzione anziché le singole chiamate LLM. È costruito su un'architettura modulare composta da cinque componenti chiave:

1. Program Orchestrator: Mantiene una macchina a stati per ogni programma, tracciando l'ordine dei turni e gli stati degli strumenti in sospeso. Garantisce che il turno $t+1$ venga rilasciato solo dopo che il turno $t$ e il relativo gap dello strumento siano trascorsi nel tempo simulato, preservando l'identità del programma e le dipendenze.
2. Tool Simulator: Materializza i gap indotti dagli strumenti. Opera in due modalità:
   • Replay Mode: Utilizza durate di wall-clock catturate da tracce reali per la validazione.
   • Generative Mode: Campiona le durate da distribuzioni adattate per l'esplorazione controfattuale.
3. Session-Aware Router: Gestisce l'implementazione multi-istanza. Mantiene una tabella di affinità programma-istanza per instradare i turni successivi allo stesso motore "home", preservando la località della prefix-cache. Se l'engine home è oltre la capacità, calcola il costo di migrazione o di re-prefilling.
4. Program-Aware Batch Scheduler: Estende lo scheduler per dare priorità all'identità del programma. Espone lo stato a livello di programma (ad esempio, servizio ottenuto) a hook di policy sostituibili, consentendo FCFS a livello di programma o prioritizzazione dell'attained-service, mantenendo al contempo la logica standard di admission e continuous-batching.
5. KV Residency Model: Traccia il posizionamento della KV-cache attraverso i tier di memoria (HBM, Host DRAM, CXL). Assegna deadline definite dalle policy ai blocchi KV in base alla durata del tool-gap e ai costi di ricalcolo. Modella esplicitamente l'evizione, lo swapping in memoria host e le decisioni di ritenzione durante i gap degli strumenti.

Il simulatore integra questi moduli con un motore di esecuzione a grafo di operatori (basato su LLMServingSim 2.0 e ASTRA-sim) per modellare hardware eterogenei, interconnessioni e accesso alla memoria multi-tier.

Contributi Chiave

1. Architettura di Simulazione Centrata sul Programma: Un framework innovativo che astrae il programma agente come unità di esecuzione, consentendo lo studio delle dipendenze tra i turni, degli intervalli di idle indotti dagli strumenti e della residenza della KV cross-turno all'interno di un unico framework hardware-aware.
2. Validazione rispetto a Deployment Reali: Gli autori hanno validato AGENTSERVESIM rispetto a run di sistemi reali su tre piattaforme hardware (RTX 3090, H100-SXM, B200) utilizzando il workload SWE-Bench Verified. Il simulatore riproduce il comportamento del sistema reale con un errore inferiore al 6% su metriche chiave (JCT e throughput) pur eseguendosi interamente su CPU commodity.
3. Analisi del Design-Space Hardware-Aware: Il paper utilizza il simulatore per studiare sistematicamente l'interazione tra prefix caching, scheduling, routing e gestione della KV. Identifica condizioni specifiche in cui le policy agent-aware forniscono benefici, come l'impatto dei tassi di riutilizzo del prefisso e delle distribuzioni di latenza degli strumenti.

Risultati

• Accuratezza: Attraverso 80 celle di configurazione (variando hardware, dimensione del modello e policy), AGENTSERVESIM ha eguagliato il JCT del sistema reale con un errore relativo medio <5%. Anche gli errori di throughput sono stati altrettanto bassi (<2%).
• Impatto del Routing: Nei cluster multi-istanza, il routing consapevole della sessione ha preservato i tassi di hit della prefix-cache vicino ai limiti di singola istanza (96,26%), mentre il routing round-robin e least-loaded ha ridotto i tassi di hit di 3,3–3,6 punti percentuali, aumentando significativamente il JCT.
• Sensibilità della Policy: Il beneficio dello scheduling agent-aware (ad esempio, Autellix, InferCept) rispetto alle baseline a livello di richiesta (vLLM-FCFS) dipende fortemente dal tasso di riutilizzo del prefisso ($\eta$). Quando $\eta < 0,3$, i costi di ricalcolo dominano e le differenze di policy sono trascurabili. Quando $\eta \ge 0,5$, scegliere la policy errata può causare un aumento moltiplicativo del JCT.
• Latenza degli Strumenti: Man mano che la latenza degli strumenti scala, le policy agent-aware (specificamente quelle con ritenzione adattiva o a TTL statico) superano significativamente FCFS. Per tracce di strumenti bimodali, una regola di ritenzione a soglia statica è stata spesso sufficiente per catturare la maggior parte dei guadagni.
• Memory Tiering: L'aggiunta di un secondo tier di memoria (CPU DRAM o CXL) mitiga il collasso delle prestazioni dei sistemi HBM-only sotto carico elevato. La banda CXL fornisce un beneficio misurabile (fino a circa il 10% di riduzione del JCT) in specifici punti di saturazione, beneficiando principalmente la tail latency.

Significato

Il paper sostiene che AGENTSERVESIM permetta un'esplorazione controllata e ripetibile delle policy di serving degli agenti senza la necessità di deployment esaustivi su costosi acceleratori. Modellando fedelmente la natura stateful dell'esecuzione degli agenti, il simulatore consente ai ricercatori di:

• Valutare le interazioni tra policy (scheduling, routing, gestione KV) che sono strettamente accoppiate e difficili da isolare nei sistemi reali.
• Esplorare configurazioni che non sono disponibili o sono troppo costose da testare fisicamente (ad esempio, cluster più grandi, tier di memoria ipotetici come CXL o specifiche distribuzioni di latenza degli strumenti).
• Andare oltre le metriche a livello di richiesta per ottimizzare obiettivi a livello di programma come il Job Completion Time.

Questo lavoro stabilisce le fondamenta per la progettazione di prossime generazioni di stack di serving LLM capaci di gestire i complessi carichi di lavoro stateful della moderna IA agentica.