Riepilogo Tecnico: Un Livello di Runtime Guidato da Politiche per il Servizio di LLM Agentic

1. Enunciato del Problema

I sistemi multi-agente basati su Modelli Linguistici di Grande Dimensione (LLM) sono diventati il carico di lavoro produttivo dominante, eppure lo stack di servizio esistente è architecturalmente disallineato rispetto alle loro esigenze. I sistemi attuali operano su una struttura a due livelli:

1. Framework Agente (Superiore): Sistemi come AutoGen, LangGraph o MetaGPT che gestiscono le identità degli agenti, gli schemi di ruolo e la logica di instradamento. Emettono chiamate API LLM ma rimangono ciechi agli eventi a livello di motore (ad esempio, generazione di token, stato della cache KV).
2. Motore di Servizio (Inferiore): Motori come vLLM o SGLang che gestiscono il prefilling, il batching e la generazione di token. Osservano ogni evento ma non possiedono alcuna conoscenza delle identità degli agenti o della struttura semantica del flusso di lavoro multi-agente.

Questa "giuntura" crea un divario critico per le politiche trasversali. Molte strategie di ottimizzazione—come l'evizione della cache KV, la modellazione del batch, l'esecuzione speculativa, l'equità e l'applicazione della sicurezza—richiedono l'accesso simultaneo ai metadati dell'identità dell'agente (dal framework) e agli eventi a livello di motore (dal motore di servizio). Attualmente, queste politiche sono implementate come "patch una tantum" all'interno del framework o del motore. Questo approccio è fragile, non modulare e non riesce a sfruttare il contesto completo richiesto per un processo decisionale ottimale.

2. Metodologia: Il Livello di Runtime Agente

Gli autori propongono un intervento architetturale: inserire un terzo livello, il Livello di Runtime Agente, tra il framework e il motore di servizio. Questo livello agisce come un substrato che possiede i metadati trasversali degli agenti ed espone un'interfaccia stabile e agnostica rispetto alle politiche.

Le Quattro Primitive

Il livello definisce quattro primitive generiche attraverso le quali qualsiasi politica consapevole degli agenti può integrarsi. Queste primitive formano un ciclo di feedback osserva → valuta → prevede → agisce, unificato dall'identità dell'agente come coordinata condivisa:

1. osserva(evento): Il runtime riceve eventi rilevanti per le politiche dai vicini (ad esempio, tocchi di blocco, arrivi di richieste, ritorni di strumenti). Aggiorna lo stato interno etichettato per identità dell'agente.
2. valuta(oggetto): Il runtime restituisce una priorità per oggetto utilizzata da un vicino per classificare le decisioni (ad esempio, quale blocco KV evicere, quale richiesta ammettere).
3. prevedi(orizzonte): Il runtime restituisce una previsione probabilistica dell'attività futura dell'agente (ad esempio, il prossimo ruolo dell'agente, la prossima chiamata allo strumento).
4. agisci(effetto_collaterale): Il runtime emette effetti collaterali fuori dal percorso critico a un vicino (ad esempio, riscaldamento di una cache, precaricamento di pesi, copertura di una chiamata speculativa). Questa è l'unica primitiva che modifica lo stato del vicino.

Caso di Studio: CacheSage

Per validare questa astrazione, gli autori istanziano il livello per la caching KV, la politica con il maggiore impatto immediato sui costi di servizio. Introducono CacheSage, che affronta il problema delle cache di prefisso reattive che eliminano gli "ancoraggi degli agenti" (prompt di sistema e definizioni degli strumenti) prima dell'arrivo della sessione successiva.

CacheSage implementa le quattro primitive tramite tre componenti:

• Apprenditore di Transizioni (osserva): Mantiene una finestra scorrevole di conteggi di transizioni a coppie tra agenti ($n(a', a)$) per calcolare online una matrice di transizione di Markov del primo ordine. Identifica l'"ancoraggio dell'agente" (sistema + strumenti) tramite hashing del contenuto.
• Valutatore di Probabilità di Sopravvivenza (valuta): Approssima la probabilità che un agente si attivi entro i prossimi $K$ passi. Invece di calcoli esatti costosi, utilizza un Grafo Aciclico Diretto (DAG) con soglia e una Ricerca in Ampiezza (BFS) per calcolare un proxy di "conteggio dei salti". Questo punteggio viene combinato con l'orologio di recenza esistente del motore per determinare la priorità di evizione.
• Prefetching tra Sessioni (prevedi + agisci): Tra i passi dello scheduler, il runtime prevede il prossimo agente ($a^*$) ed emette una richiesta di "riscaldamento". Questa richiesta contiene solo il prompt di sistema e un messaggio utente minimale per popolare la cache KV per l'ancoraggio dell'agente previsto, senza iniettare contenuti specifici dell'intera sessione.

3. Contributi Chiave

1. Il Livello di Runtime Agente: Un terzo livello proposto per lo stack di servizio che espone un'interfaccia a quattro primitive (osserva, valuta, prevedi, agisci). Gli autori mappano nove politiche distinte consapevoli degli agenti (inclusi caching KV, memoizzazione dei risultati degli strumenti, modellazione del batch ed equità) su questa interfaccia, sostenendo che condividono tutti la stessa esigenza architetturale di eventi etichettati con l'identità dell'agente.
2. CacheSage: Un'implementazione concreta del livello per il caching KV. Impara online le matrici di transizione degli agenti per carico di lavoro e le utilizza per l'evizione basata sulla sopravvivenza e il prefetching tra i passi. Opera con uno stato limitato ($\le$ 20 KB per carico di lavoro) e include un fallback elegante alla LRU standard se non viene appresa alcuna struttura.
3. Validazione Empirica: Risultati preliminari su cinque carichi di lavoro multi-agente reali (MMLU, MT-Bench, GAIA, GSM8K, HumanEval) che dimostrano l'efficacia dell'approccio.

4. Risultati

Gli esperimenti sono stati condotti su GPU NVIDIA H100 utilizzando Llama-3.1-8B-Instruct, confrontando CacheSage con vLLM e Continuum.

• Tasso di Hit della Cache: CacheSage ha ottenuto un aumento di +13 a +37 punti percentuali (pp) nei tassi di hit della cache rispetto a vLLM su tutti e cinque i carichi di lavoro. Ciò è attribuito al mantenimento degli ancoraggi degli agenti attraverso i confini delle sessioni che le cache reattive eliminano tipicamente.
• Latenza: Il Tempo Medio al Primo Token (TTFT) e la latenza end-to-end per turno sono stati ridotti del 12% al 29%.
• Throughput: Il throughput del sistema è aumentato del 6% al 14%.
• Sovraccarico: Il sovraccarico del percorso critico è trascurabile. La funzione osserva viene eseguita in $\sim1 \mu s$ per tocco di blocco, e il valutatore viene eseguito in microsecondi a una sola cifra. Lo stato del coordinatore rimane sotto i 25 KB.

È notevole che il sistema di base Continuum, che utilizza pin TTL, abbia effettivamente ridotto i tassi di hit di 9–23 pp su tre carichi di lavoro di compiti reali, evidenziando i compromessi delle politiche statiche rispetto alla natura adattiva del livello di runtime.

5. Significato e Affermazioni

Il documento afferma che la "giuntura" tra il framework agente e il motore di servizio è meglio affrontata da un cambiamento architetturale piuttosto che da correzioni puntuali incrementali.

• Modularità: L'interfaccia a quattro primitive consente a politiche distinte di condividere lo stesso flusso di osservazione e comporsi rispetto alle stesse primitive senza richiedere nuove modifiche chirurgiche al motore per ogni politica.
• Generalità: Il livello è agnostico rispetto al framework (supporta AutoGen, LangGraph, ecc.) e portabile tra motori, richiedendo solo hook specifici piuttosto che modifiche interne profonde.
• Validazione del Divario: Dimostrando significativi guadagni di prestazioni sul caching KV, gli autori sostengono che il divario architetturale è reale e che un livello di runtime agente è un componente necessario per un servizio efficiente di LLM agentic.

Gli autori rimangono modesti riguardo alla portata del loro lavoro attuale, notando che, sebbene CacheSage validi l'astrazione, le altre otto politiche mappate sul livello (ad esempio, memoizzazione dei risultati degli strumenti, esecuzione speculativa di agenti, equità) rimangono sfide aperte per lavori futuri. Il contributo principale è l'interfaccia e l'argomento architetturale, non il completamento di ogni implementazione di politica.