Think Before You Grid-Search: Floor-First Triage for LLM Serving

Sintesi Tecnica: Triage "Floor-First" per il Serving di LLM

Problema
I team di produzione che ottimizzano il serving di Large Language Model (LLM) si trovano di fronte a uno spazio di configurazione vastissimo che coinvolge layout di parallelismo (TP, EP, DP), batching, quantizzazione e lavoro a livello di kernel. La risposta operativa prevalente di fronte al mancato raggiungimento dei target di latenza è quella di testare numerosi benchmark e implementare profiler pesanti (es. Nsight Systems) in modo indiscriminato. Questo approccio spesso degenera in una ricerca esaustiva (grid search) inefficiente, dove i numeri di performance misurati sono ambigui: un TPOT (Time Per Output Token) lento potrebbe derivare da limiti fondamentali di banda, lacune nell'implementazione, comunicazione esposta, overhead dell'host o kernel sotto-performanti. Il documento sostiene che la comunità ingegneristica manchi di una procedura decisionale sistematica per determinare quando sia giustificato l'uso di un profiler e dove guardare per primo, portando a scelte di deployment imprevedibili (es. strategie di parallelismo contrastanti per modelli DeepSeek su hardware identico) basate sul folklore piuttosto che su un esplicito conteggio delle risorse.

Metodologia: Triage "Floor-First"
Il documento propone il "Floor First", un workflow di triage guidato dai residui che tratta la stima analitica come lo strato primario di profiling. La metodologia consiste in quattro fasi distinte:

1. Costruzione del Floor Analitico: Prima di qualsiasi benchmark, il sistema calcola un "floor a due lati" per una data configurazione. Questo modello tratta ogni step di decode come un vettore di risorse a cinque dimensioni: byte HBM, FLOPs, byte di rete, messaggi di rete e capacità KV.

   • Optimistic Floor ($t_{opt}$): Calcolato come il massimo dei tempi delle risorse indipendenti ($max(t_{HBM}, t_{compute}, t_{network})$), assumendo una sovrapposizione perfetta.
   • Pessimistic Floor ($t_{sum}$): Calcolato come la somma di tutti i tempi delle risorse ($t_{HBM} + t_{compute} + t_{network}$), assumendo l'assenza di sovrapposizione.
   • Intervallo Diagnostico: La posizione di una misurazione di benchmark all'interno dell'intervallo $[t_{opt}, t_{sum}]$ funge da diagnostica a costo zero per la sovrapposizione del sistema. Se la misurazione è vicina a $t_{opt}$, la sovrapposizione è buona; se è vicina a $t_{sum}$, lo scheduling/overlap è il collo di bottiglia; se è sopra $t_{sum}$, il tempo sta perdendo verso costi non modellati (gap dell'host, stragglers).

2. Disciplina del Benchmark: I benchmark devono essere condotti sotto regole rigorose: generazione del carico in loop aperto (per evitare il bias di auto-throttling), distribuzioni di lunghezza realistiche, operatività a regime stazionario e reporting dei percentili della coda (P99).

3. Riconciliazione e Triage: Il tempo misurato viene confrontato con il floor.

   • Piccolo Residuo (< 1.3× floor): L'indagine si ferma. Il sistema è vicino al limite teorico per quell'asse; l'ulteriore ottimizzazione richiede il cambiamento dell'architettura (es. attenzione sparsa, quantizzazione) piuttosto che il tuning dei kernel.
   • Grande Residuo: Il profiling viene scalato. Nsight Systems viene utilizzato solo per rispondere a tre domande specifiche: Ci sono gap tra i kernel? La comunicazione è esposta? Quale classe di kernel eccede il proprio budget analitico? Nsight Compute è riservato esclusivamente alle classi di kernel che eccedono il proprio budget dopo che altre cause sono state escluse.

4. Wall Ordering: Invece di confrontare la latenza di un singolo batch, i deployment vengono valutati tramite "wall ordering" (ordinamento per barriera): determinare quale vincolo di risorsa (capacità KV, banda KV, banda dei pesi o compute) si manifesta per primo all'aumentare del carico. La capacità è trattata come una dimensione di risorsa di prima classe, non come un controllo di memoria post-hoc.

Contributi Chiave

1. Workflow di Triage Guidato dai Residui: Un ciclo decisionale che separa la definizione del target, la costruzione del floor e l'escalation del profiler, con regole di arresto esplicite che indirizzano gli sforzi di ottimizzazione verso il lavoro di pipeline (layout/scheduling) o il lavoro di kernel.
2. Modello di Floor a Due Lati: Un modello analitico che fornisce limiti ottimistici e pessimistici, utilizzando il gap tra di essi per diagnosticare l'efficienza della sovrapposizione senza eseguire un profiler.
3. Wall Ordering come Output: Un metodo per confrontare le alternative di deployment in base a quale barriera di risorsa si attiva per prima all'aumentare della concorrenza, rivelando che un layout con una latenza di singolo batch peggiore può dominare la frontiera del goodput se possiede una barriera di capacità più alta.
4. Disciplina delle Metriche: Una sistematizzazione delle metriche di utilizzo (MFU vs. MBU) basata sulla "identità della cresta" ($MFU/MBU = I_{work}/I_{ridge}$), garantendo che la metrica corretta venga riportata per la risorsa che determina il vincolo.
5. Artefatto e Skill dell'Agente: Un artefatto Python senza dipendenze (floor.py) e una skill leggibile dagli agenti (SKILL.md) che impongono questa disciplina nei loop di ottimizzazione agentici, impedendo agli agenti di ricorrere riflessivamente ai profiler.

Risultati del Case Study
Il documento applica questa metodologia a un modello MoE stile DeepSeek-V3.2 da 671B su 16 GPU NVIDIA H20.

• Caratterizzazione dell'Hardware: La GPU H20 viene identificata come avente un punto di cresta (ridge point) di ~74 FLOP/byte (rispetto a ~590 per H100), rendendola una parte estremamente orientata al decode, dove la regione limitata dalla memoria è 8× più ampia.
• Giudizio sul Layout:
  • TP16: Con batch size 64 e contesto 8K, TP16 è limitato dalla capacità KV a circa 70 richieste concorrenti. Il termine della banda KV è significativo, e la barriera di compute è irraggiungibile nell'area fattibile.
  • EP16 + DP Attention: Questo layout scambia un traffico di pesi leggermente peggiore per una barriera di capacità di circa 644 richieste (un ordine di grandezza superiore). Sebbene TP16 abbia una latenza di singolo stream inferiore (2.4× più veloce a B=1), EP16+DP domina la frontiera del goodput ad alta concorrenza.
  • Sparse Attention (DSA): Rimuove la barriera della banda KV ma non la barriera di capacità, poiché l'intero KV deve rimanere indirizzabile.
• Risoluzione del Disaccordo: Lo studio spiega perché team diversi abbiano implementato layout opposti (TP vs. DP) sullo stesso hardware: la scelta ottimale è una funzione computabile del punto operativo (concorrenza). L'alta concorrenza favorisce DP; la bassa concorrenza favorisce TP.

Significatività e Claim
Il documento afferma che i disaccordi di produzione nel serving di LLM sono spesso prevedibili da un piccolo conteggio delle risorse (cinque numeri per GPU più le dimensioni del modello) piuttosto che richiedere estese sperimentazioni. Rendendo questo conteggio sistematico, il workflow fornisce una procedura di triage generale che:

• Previene sforzi di profiling sprecati quando le misurazioni sono vicine al floor analitico.
• Identifica l'asse di ottimizzazione corretto (pipeline vs. kernel) prima di impegnare strumenti costosi.
• Spiega le scelte di deployment attraverso la "wall ordering" piuttosto che tramite benchmark puntuali.
• Offre un metodo robusto per hardware con caratteristiche estreme (come l'H20) dove gli standard euristici falliscono.

Gli autori notano modestamente che l'attuale bozza si basa su floor analitici e costanti calibrate, con una campagna di misurazione pianificata (Sezione 8) necessaria per validare empiricamente le soglie dei residui e le regole di escalation. Il metodo è presentato come una procedura decisionale per l'ingegneria, non come un sostituto per simulatori o profiler, che rimangono essenziali per i residui che sopravvivono al controllo del floor.