Efficient LLM Serving for Agentic Workflows: A Data Systems Perspective

1. Il Problema: Redundanza nei Flussi di Lavoro Agentic

I moderni sistemi di intelligenza artificiale si basano sempre più su flussi di lavoro agentic (agentic workflows), ovvero sequenze di passi interdipendenti orchestrati da Agenti basati su Large Language Models (LLM). Questi flussi spesso coinvolgono:

• Esplorazione speculativa: Gli agenti tentano parallelamente o in sequenza diverse strategie o sottocompiti.
• Ridondanza massiccia: A causa della natura esplorativa, si generano molti prompt sovrapposti, risultati intermedi ripetuti e chiamate LLM ridondanti.

Limiti degli approcci attuali:
I sistemi di serving LLM all'avanguardia (come vLLM) sono ottimizzati per chiamate singole o batch indipendenti. Trattano ogni chiamata LLM come un'unità discreta, ignorando la struttura del flusso di lavoro globale.

• Mancanza di visibilità: Non vedono le dipendenze tra le chiamate (es. prompt condivisi o stati KV riutilizzabili).
• Gestione passiva della cache: Le tecniche attuali di caching dei prefissi sono reattive (opportunistiche) e non possono anticipare i pattern di carico tipici dei flussi batch agentic.
• Astrazione come UDF: I framework di orchestrazione (es. LangGraph, Spark) trattano spesso gli LLM come "scatole nere" (User-Defined Functions), impedendo l'ottimizzazione interna dello stato (KV cache) e la riorganizzazione del piano di esecuzione.

2. Metodologia: Helium

Il paper introduce Helium, un framework di serving consapevole del flusso di lavoro (workflow-aware) che applica i principi dell'ottimizzazione delle query dei database ai flussi di lavoro agentic. Helium modella i flussi di lavoro come piani di query (query plans) e tratta le invocazioni LLM come operatori di prima classe.

L'architettura di Helium si basa su tre pilastri principali:

A. Modellazione come Piano di Query (DAG)

Il sistema rappresenta il flusso di lavoro come un Grafo Aciclico Diretto (DAG) dove i nodi sono operatori (recupero dati, invocazione LLM) e gli archi rappresentano il flusso di dati/prompt.

• DSL (Domain Specific Language): Gli utenti definiscono i flussi di lavoro tramite un linguaggio specifico che costruisce un grafo simbolico.
• Ottimizzazione Logica: Prima dell'esecuzione, l'ottimizzatore analizza il DAG per eliminare ridondanze strutturali (es. codice morto, sottografi comuni) e sostituire operatori ridondanti con operatori leggeri di recupero dalla cache (CacheFetch).

B. Caching Proattivo (Proactive Caching)

A differenza dei sistemi tradizionali che cacheano solo quando una richiesta arriva, Helium utilizza una strategia proattiva:

• Analisi del Carico: Durante la fase di compilazione, Helium analizza il batch di input per identificare prefissi statici condivisi tra diverse chiamate e flussi di lavoro.
• Prefill Anticipato: I prefissi statici vengono pre-calcolati e i relativi stati KV (Key-Value) vengono caricati nella memoria GPU prima dell'esecuzione effettiva.
• Cache Globale dei Prompt: Per operatori deterministici, Helium mantiene una cache globale che mappa gli input agli output, permettendo di bypassare completamente l'esecuzione LLM se l'input è già stato processato.

C. Scheduling Consapevole della Cache (Cache-Aware Scheduling)

Helium introduce un nuovo algoritmo di scheduling basato sui costi per massimizzare il riutilizzo della cache KV.

• Templated Radix Tree (TRT): Viene costruita una struttura dati innovativa (un albero Radix modellato) che cattura non solo le dipendenze tra operatori, ma anche la gerarchia globale dei prefissi dei prompt.
• Ottimizzazione dell'Ordine di Esecuzione: L'algoritmo riordina le chiamate LLM per:
  1. Eseguire consecutivamente chiamate che condividono lo stesso prefisso statico (massimizzando il riutilizzo della KV cache).
  2. Interleavare chiamate indipendenti per mantenere i GPU saturi mentre si attendono i risultati delle dipendenze.
• Formulazione del Problema: Il problema di scheduling è modellato come un problema di minimizzazione del makespan (tempo totale di esecuzione) considerando i "token step" e i vincoli di precedenza, risolvendo un problema NP-hard tramite un algoritmo euristico greedy ottimizzato.

3. Contributi Chiave

1. Helium Framework: Un layer di serving che tratta i flussi di lavoro agentic come piani di query, abilitando l'ottimizzazione olistica intra- e inter-query.
2. Strategia di Caching Proattivo: Un meccanismo che "riscalda" (pre-warms) la KV cache per i prefissi statici e mantiene una cache globale degli output per evitare calcoli ridondanti.
3. Algoritmo di Scheduling Consapevole della Cache: Un algoritmo basato su costi che utilizza il TRT per massimizzare il riutilizzo dei prefissi nei batch agentic, superando le limitazioni degli scheduler online tradizionali.
4. Validazione Sperimentale: Implementazione e valutazione completa che dimostra miglioramenti significativi rispetto allo stato dell'arte.

4. Risultati Sperimentali

Gli autori hanno valutato Helium su diversi benchmark, inclusi flussi di lavoro primitivi (Map-Reduce, Debate, Reflection) e un caso d'uso complesso di trading finanziario ("Trading Workflow").

• Performance vs. vLLM (Baseline Naive): Helium ha ottenuto un speedup fino a 100.92× rispetto all'esecuzione sequenziale su vLLM non ottimizzato, dimostrando l'importanza dell'orchestrazione batch.
• Performance vs. Sistemi Agentic (LangGraph, AgentScope, Parrot):
  • Fino a 1.83× più veloce di LangGraph.
  • Fino a 4.32× più veloce di AgentScope.
  • Fino a 2.51× più veloce di Parrot (un sistema che tenta di ottimizzare i flussi ma usa euristiche di scheduling subottimali).
  • Fino a 1.56× più veloce di KVFlow (un framework specializzato nella gestione della cache KV).
• Efficienza Globale: In un flusso di lavoro complesso di trading, Helium ha ridotto la latenza end-to-end fino a 39.50× rispetto a vLLM e 1.34× rispetto a KVFlow.
• Ottimalità dello Scheduling: Confrontando l'algoritmo di Helium con la soluzione ottima teorica (calcolata tramite MILP), Helium ha mostrato un optimality gap medio di solo 0.9%, dimostrando un'eccellente capacità di pianificazione.
• Scalabilità: Le prestazioni di Helium migliorano all'aumentare della dimensione del batch e della complessità del flusso di lavoro, grazie alla migliore capacità di sfruttare la condivisione dei prefissi.

5. Significato e Impatto

Questo lavoro segna un cambio di paradigma nel serving degli LLM:

• Dall'ottimizzazione locale a quella globale: Sposta il focus dall'ottimizzazione di singole inferenze (livello kernel o batch di richieste indipendenti) all'ottimizzazione dell'intero grafo di calcolo del flusso di lavoro.
• Convergenza Database-AI: Dimostra che i principi consolidati dell'ottimizzazione delle query (come l'eliminazione delle sotto-espressioni comuni e la riorganizzazione dei piani) sono applicabili e cruciali per l'efficienza degli agenti AI.
• Riduzione dei Costi: Eliminando la ridondanza computazionale (prefill e decodifica ripetuti), Helium riduce drasticamente l'uso di GPU e la latenza, rendendo gli agenti AI complessi più scalabili ed economici da eseguire.

In sintesi, Helium dimostra che trattare gli agenti come un sistema di elaborazione dati coerente, piuttosto che come una collezione di chiamate API isolate, è essenziale per il futuro scalabile dei sistemi AI basati su agenti.