Riepilogo Tecnico: Dooly

Enunciato del Problema

Il deployment di sistemi di inferenza per Large Language Model (LLM) richiede di navigare in un vasto spazio di configurazioni comprendente hardware, motori di serving, backend di attenzione, architetture di modelli e caratteristiche del carico di lavoro. Nessuna configurazione singola è ottimale per tutti i carichi di lavoro; le classifiche delle prestazioni spesso si invertono in base alla lunghezza della sequenza o al tipo di modello, rendendo essenziale la valutazione pre-deployment.

Gli attuali simulatori basati su profili, strumento standard per questa valutazione, affrontano due limitazioni critiche che ostacolano un'esplorazione efficiente:

1. Dipendenze da Configurazioni Statiche: I simulatori esistenti codificano in modo rigido (hardcode) l'insieme delle operazioni e degli argomenti di input per configurazioni specifiche. Qualsiasi cambiamento nello stack software (ad esempio, un nuovo motore di serving o un nuovo backend di attenzione) o nell'architettura del modello richiede un lavoro manuale per ripristinare la copertura.
2. Elevato Sovraccarico di Profilazione: I simulatori non riescono a riconoscere quando configurazioni diverse invocano calcoli semanticamente identici. Di conseguenza, profilano ogni operazione da zero per ogni nuovo modello o backend. Ad esempio, profilare quattro modelli di dimensioni simili con un singolo backend può richiedere quasi 28 ore di tempo reale su una singola GPU A100, scalando linearmente con il numero di modelli.

Queste limitazioni derivano da una mancanza di comprensione strutturale dell'inferenza LLM: in particolare, che le dimensioni di input sono derivate da configurazioni di modello fisse o da caratteristiche di richiesta variabili, e che molti valori di configurazione del modello (ad esempio, dimensione della testa, numero di livelli) si ripetono tra modelli diversi, portando a una significativa ridondanza nella profilazione.

Metodologia

Gli autori propongono Dooly, un framework per la profilazione agnostica rispetto alla configurazione e consapevole della ridondanza. Dooly sfrutta la ricorrenza strutturale delle operazioni tra le configurazioni per eliminare le esecuzioni di profilazione ridondanti. Il sistema opera attraverso tre componenti principali:

1. Tainted Runner (Annotazione Semantica)

Per distinguere tra i parametri fissi del modello e gli input di richiesta variabili, Dooly impiega la propagazione di taint.

• Tainting di Origine: Il sistema intercetta i punti di ingresso del motore di serving (ad esempio, ModelConfig e la logica di elaborazione delle richieste) per etichettare i valori. I parametri di configurazione del modello sono contrassegnati con MODEL_CONFIG, mentre i valori dipendenti dalla richiesta (numero di token, dimensioni del batch) sono contrassegnati con NUM_TOKS e NUM_REQS.
• Propagazione: Mentre l'esecuzione dell'inferenza procede, questi taint si propagano attraverso operazioni aritmetiche e tensoriali. Sono definite regole su come i taint si combinano (ad esempio, moltiplicare la dimensione del batch per una dimensione della testa risulta in un taint composito MIX).
• Annotazione della Traccia: La traccia risultante annota ogni dimensione del tensore con la sua origine, consentendo al sistema di identificare quali dimensioni sono invarianti tra i carichi di lavoro e quali sono variabili.

2. Operation Set Finder (Risoluzione della Granularità)

Questo componente analizza la traccia taintata in un grafo di chiamate gerarchico per determinare la granularità più fine alla quale le operazioni possono essere profilate in isolamento.

• Costruzione della Gerarchia: La traccia viene potata per collassare sottoalberi strutturalmente identici (ad esempio, livelli transformer ripetuti) in rappresentanti canonici.
• Test di Esecutabilità: Il sistema tenta di eseguire le operazioni foglia (singoli kernel) in isolamento. Se un'operazione fallisce a causa di uno stato di runtime mancante (ad esempio, memoria della cache KV o metadati di attenzione), il sistema torna al suo modulo genitore.
• Risoluzione del Contesto: Per le operazioni con stato che non possono essere eseguite in autonomia, Dooly riutilizza il codice di inizializzazione del motore di serving stesso per ricostruire il contesto di runtime necessario, eliminando la necessità di strumentazione manuale.

3. Duplication-Aware Profiler (Corrispondenza delle Firme)

Questo componente elimina la profilazione ridondante identificando operazioni semanticamente equivalenti tra diverse configurazioni.

• Generazione della Firma: Un'operazione è identificata univocamente da un hash di firma composto da:
  1. Il nome dell'operazione e le sue dimensioni taintate con MODEL_CONFIG (fisse dall'architettura).
  2. L'insieme dei simboli del kernel GPU dispatchati (catturando la selezione del kernel specifica del backend).
  3. Un digest degli attributi a livello di modulo (ad esempio, dimensione della finestra scorrevole) per il branching a runtime.
     Nota: Le dimensioni dipendenti dal carico di lavoro (NUM_TOKS, NUM_REQS) sono escluse dalla firma in quanto parametrizzano la scansione, non l'identità dell'operazione.
• Profilazione Selettiva: Prima di inviare una misurazione, il profiler controlla il database delle latenze. Se una firma esiste già, l'operazione viene saltata. Solo le firme uniche vengono profilate su intervalli definiti dall'utente di lunghezze di sequenza e dimensioni del batch.
• Database delle Latenze: I risultati sono archiviati in un database SQLite indicizzato per hash della firma. Questo database funge da backend plug-and-play per simulatori esistenti, che addestrano modelli di regressione per firma per prevedere la latenza.

Contributi Chiave

• Profilazione Agnostica rispetto alla Configurazione: Dooly estrae dinamicamente le operazioni e le profila senza codificare in modo rigido template, consentendo di supportare nuovi modelli, backend e motori di serving senza lavoro manuale.
• Eliminazione della Ridondanza: Utilizzando la propagazione di taint per distinguere le dimensioni derivate dal modello da quelle derivate dalla richiesta, Dooly rileva operazioni equivalenti tra diversi modelli e configurazioni, riducendo lo sforzo di profilazione.
• Isolamento delle Operazioni con Stato: Attraverso la risoluzione gerarchica del contesto, Dooly isola operazioni complesse dipendenti dallo stato (come i kernel di attenzione) riutilizzando la logica interna di inizializzazione del motore di serving, evitando la necessità di ricostruzione manuale del contesto.
• Integrazione Plug-and-Play: Il database delle latenze risultante addestra modelli di regressione che i simulatori esistenti possono adottare come backend per eseguire simulazioni end-to-end.

Risultati

Gli autori hanno valutato Dooly su due piattaforme GPU (NVIDIA A100 e H100), tre backend di attenzione (FlashInfer, FlashAttention, TritonAttention) e 12 diverse architetture di modelli (inclusi modelli densi, MoE e famiglie eterogenee).

• Accuratezza della Simulazione: Quando integrato in un simulatore (DoolySim), il sistema prevede il Time to First Token (TTFT) con un errore percentuale assoluto medio (MAPE) entro il 5% e il Time Per Output Token (TPOT) entro l'8% rispetto alle misurazioni live. Riproduce inoltre le decisioni di scheduling del batch con un MAPE inferiore allo 0,5%.
• Riduzione del Sovraccarico di Profilazione: Su 12 modelli profilati con tre backend di attenzione (36 configurazioni totali), Dooly ha ridotto le ore GPU totali di profilazione del 56,4% rispetto a un approccio ingenuo e non deduplicante.
  • Nello specifico, la profilazione di Llama-3.1-8B e Command-R7B ha richiesto 5,2 ore GPU con Dooly contro 8,1 ore con l'approccio ingenuo.
  • Il sistema ha identificato solo 100 firme uniche su 612 occorrenze totali di operatori, con le firme di attenzione che rappresentano il 95% del tempo risparmiato.
• Scalabilità: Una volta che alcuni modelli esercitano le configurazioni di attenzione distinte in un corpus, i modelli successivi aggiungono un sovraccarico trascurabile (sotto le 0,2 ore GPU) poiché ereditano le firme esistenti.

Significato e Affermazioni

Il paper afferma che Dooly cambia fondamentalmente l'economia della simulazione dell'inferenza LLM passando da un approccio "profilare-tutto" a un approccio "profilare-cosa-è-unico". Sfruttando la ricorrenza strutturale delle configurazioni di modello, Dooly consente a ricercatori e professionisti di valutare strategie di serving su un'ampia gamma di configurazioni con costi significativamente ridotti.

Gli autori sottolineano che il loro approccio è modesto riguardo agli impatti più ampi, affermando che il lavoro non ha impatti etici o sociali significativi oltre alla sua utilità tecnica. Riconoscono limitazioni, come l'incapacità di tracciare operazioni che bypassano il dispatcher di PyTorch (sebbene i moduli contenenti rimangano coperti) e l'assunzione di instradamento casuale degli esperti per i modelli MoE, notando che la modellazione dell'instradamento dipendente dai dati è al di fuori dello scopo del paper. Il contributo principale è un framework pratico che rende l'esplorazione tra configurazioni fattibile ed efficiente senza richiedere ingegneria manuale per ogni aggiornamento dello stack.