MARS: Efficient, Adaptive Co-Scheduling for Heterogeneous Agentic Systems

1. Enunciato del Problema

Il documento identifica un cambiamento fondamentale nei paradigmi di servizio dei Large Language Model (LLM) causato dall'ascesa degli agenti autonomi. A differenza dei chatbot tradizionali che eseguono inferenze a turno singolo, gli agenti eseguono flussi di lavoro iterativi che coinvolgono cicli multi-turno di generazione, invocazione di strumenti e aggiornamenti dello stato. Questo cambiamento introduce due sfide critiche che i motori di servizio LLM esistenti (ad esempio, vLLM, TGI) non riescono ad affrontare:

• Spostamento Temporale (Turno Singolo $\to$ Multi-turno): Le sessioni non sono più operazioni GPU continue. Si interrompono per l'esecuzione degli strumenti (limitata dalla CPU) e riprendono successivamente. I sistemi esistenti faticano a decidere se mantenere la cache KV residente (per una rapida ripresa "calda") o espellerla (per risparmiare memoria), portando a carenza di memoria o a costosi ricalcoli dei prefissi.
• Spostamento Spaziale (Solo GPU $\to$ GPU-CPU Co-localizzati): I carichi di lavoro agentici richiedono un'esecuzione accoppiata sia sulle GPU (inferenza) che sulle CPU host (esecuzione degli strumenti). I sistemi esistenti ottimizzano il throughput dei token GPU in isolamento, ignorando i colli di bottiglia della CPU. Ciò porta al blocco della testa della coda (HoL), dove richieste di prefill lunghe bloccano continuazioni interattive brevi, e alla coda accoppiata, dove la capacità GPU rimane inattiva in attesa dell'esecuzione degli strumenti sulla CPU.

Il problema fondamentale è la mancanza di un sistema capace di visibilità olistica e co-scheduling adattivo attraverso risorse GPU e CPU eterogenee per ottimizzare il completamento del flusso di lavoro end-to-end piuttosto che il semplice throughput grezzo dei token.

2. Metodologia: Architettura MARS

MARS (Multi-turn Adaptive Resource Scheduler) è un sistema di co-scheduling progettato per colmare il divario tra inferenza GPU ed esecuzione strumenti CPU. Si basa su tre pilastri fondamentali:

A. Flusso Informativo Unificato

Per eliminare il "punto cieco" tra gli stati GPU e CPU, MARS introduce un percorso di telemetria a basso overhead che esporta eventi strutturati ai confini.

• Piano GPU: Segnala la disponibilità dei blocchi KV, i ritardi di avvio del prefill e la domanda KV proiettata.
• Piano CPU: Traccia le invocazioni degli strumenti attive e le durate di esecuzione per quantificare la congestione lato host.
• Funzione: Questo flusso fornisce telemetria in tempo reale a doppia pressione, consentendo al sistema di prendere decisioni informate basate sulla contesa reale delle risorse piuttosto che su euristiche statiche.

B. Piano di Controllo Esterno (Controllo di Ammissione)

Questo componente disaccoppia l'ammissione dall'esecuzione per prevenire la sovrapposizione delle risorse.

• Bilanciatore di Carico Globale: Riordina la coda di attesa in base alla pressione attuale delle risorse. Ad esempio, sotto un alto carico CPU, dà priorità alle sessioni pesanti per GPU per evitare di iniettare ulteriori chiamate agli strumenti; sotto pressione KV, dà priorità alle sessioni più piccole.
• Controllore di Ammissione Adattivo: Utilizza un ciclo di controllo AIMD (Additive Increase Multiplicative Decrease) guidato dal Flusso Informativo Unificato. Regola dinamicamente la finestra di ammissione ($W_{adm}$) in base alla pressione CPU e KV in tempo reale, assicurando che le richieste entrino nel piano dati solo quando le risorse globali sono sufficienti.

C. Scheduler Interno Centrato sull'Agente (Piano Dati)

Una volta ammesse, lo scheduler gestisce l'ordinamento dell'esecuzione e la residenza KV per minimizzare il percorso critico end-to-end.

• Coordinatore Consapevole delle Priorità: Sostituisce il First-Come-First-Served (FCFS) con una Coda a Feedback Multi-Livello. Dà priorità alle richieste in base a:
  1. Impronta KV iniziale (più piccola = priorità più alta).
  2. Servizio accumulato (per evitare la carestia).
  3. Tempo di attesa.
     Ciò impedisce che attività di prefill lunghe blocchino continuazioni brevi e sensibili alla latenza.
• Co-Scheduler Opportunistico: Gestisce dinamicamente i vincoli di risorse.
  • Riduzione dei Chunk: Se un prefill completo non può entrare in memoria, riduce la dimensione del chunk di token per consentire un progresso parziale invece di bloccare.
  • Mantenimento Intelligente della KV: Decide se mantenere una cache KV residente durante l'esecuzione degli strumenti. Mantiene lo stato solo se il beneficio della "ripresa calda" supera il costo opportunità della memoria, prevenendo l'abbandono della memoria.

3. Contributi Chiave

1. Caratterizzazione del Carico di Lavoro: Il documento identifica formalmente gli spostamenti temporali e spaziali nei carichi di lavoro agentici e dimostra come creino richieste dinamicamente disallineate tra calcolo GPU, capacità della cache KV e risorse CPU host.
2. Telemetria Unificata: Introduzione del Flusso Informativo Unificato, che rende esplicita la pressione delle risorse eterogenee esportando eventi ai confini di esecuzione sia dal piano GPU che da quello CPU.
3. Architettura di Controllo Accoppiata: Un design innovativo che combina un Piano di Controllo Esterno (per l'ammissione) e uno Scheduler Interno Centrato sull'Agente (per l'esecuzione) che ottimizza congiuntamente ammissione, scheduling e residenza KV.
4. Implementazione e Integrazione: MARS è implementato sopra vLLM e integrato con il framework di agenti di codifica OpenHands, dimostrando l'applicabilità pratica.

4. Risultati Sperimentali

Gli autori hanno valutato MARS su GPU H100 e H200 utilizzando modelli come Qwen3-Coder-30B e GPT-OSS-120B, attraverso benchmark tra cui SWE-bench, GitTaskBench e RepoBench.

• Riduzione della Latenza: MARS riduce la latenza media end-to-end fino a 5,94× rispetto ai baseline all'avanguardia (inclusi FCFS, Autellix, Infercept e Continuum) sotto carico pesante.
• Throughput e Goodput: Mantenendo un throughput di sistema quasi massimo, MARS migliora significativamente il Dynamic SLO-Aware Goodput (il tasso di richieste completate entro gli obiettivi di latenza). I baseline spesso collassano nel goodput sotto carico, mentre MARS mantiene alti tassi di completamento.
• Deployment Reale: In un deployment realistico con OpenHands, MARS ha accelerato il tempo di completamento delle attività end-to-end fino a 1,87×.
• Studi di Ablazione: La rimozione del Coordinatore Consapevole delle Priorità ha causato un aumento della latenza di 2×–5× a causa del blocco HoL. La rimozione del Piano di Controllo Esterno ha causato un rallentamento di 1,5×–3× a causa dell'accumulo non gestito della coda.

5. Significato

MARS rappresenta un cambiamento di paradigma nell'infrastruttura di servizio LLM. Si allontana dai modelli centrati sulla richiesta e ottimizzati per il throughput del passato verso l'ottimizzazione del flusso di lavoro end-to-end consapevole della sessione.

• Impatto Sistemico: Risolve il problema della "pressione accoppiata" dove le risorse GPU e CPU sono interdipendenti, un collo di bottiglia critico per la prossima generazione di agenti autonomi.
• Praticità: Integrandosi con OpenHands e vLLM, dimostra che questi cambiamenti architetturali possono essere implementati in framework agentici reali senza riscrivere l'intera pila tecnologica.
• Direzione Futura: Il documento evidenzia la necessità di astrazioni simili a quelle del sistema operativo nel servizio LLM per gestire contesti multi-turno con stato, aprendo la strada a sistemi agentici più robusti ed efficienti.

In sintesi, MARS fornisce il piano di controllo e la logica di scheduling necessari per rendere i sistemi agentici eterogenei efficienti, scalabili e reattivi, colmando il divario critico tra la capacità hardware grezza e il completamento effettivo del flusso di lavoro.