Riepilogo Tecnico: Oltre l'Accuratezza e il Costo: Routing di Query LLM Consapevole della Latenza per Carichi di Lavoro Dinamici

Problema

I moderni router di query linguistica ottimizzano il compromesso tra qualità della risposta (accuratezza) e costo monetario assegnando le query a diverse istanze di Large Language Model (LLM). Tuttavia, i router esistenti sono ampiamente insensibili alla latenza. Essi selezionano i modelli basandosi su predittori di accuratezza e costo, ma ignorano la latenza di generazione che una query sperimenterà presso una specifica istanza.

Nella pratica, la latenza è determinata da politiche di bilanciamento del carico a livello di sistema (ad esempio, round-robin, join-the-shortest-queue) che non tengono conto dell'accuratezza o del costo di inferenza del modello. Al contrario, l'ottimizzazione della latenza a livello di sistema assume un'assegnazione query-modello fissa e ignora i compromessi tra accuratezza e costo. Ciò crea un vuoto: i router attuali possono indirizzare le query verso istanze sovraccariche, causando lunghi ritardi di accodamento e violando gli Obiettivi di Livello di Servizio (SLO), mentre gli ottimizzatori di sistema non possono sfruttare le capacità eterogenee di accuratezza-costo di un pool di modelli.

La sfida principale è che la latenza di generazione è non deterministica e dipende da:

1. Specifiche hardware e architettura del modello.
2. La composizione attuale del carico di lavoro (fasi di prefill vs. decode) presso l'istanza.
3. Le specifiche politiche di batching e scheduling del framework di serving (ad esempio, vLLM, Sarathi-Serve).

Stimare accuratamente il Time-to-First-Token (TTFT) per una query in arrivo è difficile perché richiede di simulare come il framework di serving effettuerà il batching della nuova query con le sequenze residenti esistenti, considerando sia l'interferenza di prefill (compute-bound) che di decode (memory-bound).

Metodologia

Gli autori propongono un framework di routing che ottimizza congiuntamente accuratezza, costo e latenza. Il sistema è composto da tre componenti principali:

1. Obiettivo di Routing

Il router seleziona un'istanza di modello $m(i)$ per una query $q_i$ per massimizzare l'utilità accuratezza-costo ($\hat{U}_{i,j}$) soddisfacendo al contempo un vincolo di TTFT ($\tau_i$).

• Utilità: $\hat{U}_{i,j}(\lambda) = \hat{acc}_{i,j} - \lambda \cdot \hat{cost}_{i,j}$, dove $\lambda$ bilancia qualità e costo.
• Vincolo: L'istanza selezionata deve soddisfare $\hat{L}^{ttft}_{i,j}(t) \leq \tau_i$. Se nessuna istanza soddisfa il vincolo, il router seleziona quella con la latenza stimata minima.
• Valutazione: Le prestazioni sono misurate tramite l'OnTimeUtility, che media l'utilità delle query che rispettano i propri vincoli di latenza (assegnando utilità zero a quelle che li violano).

2. Stimatore di Latenza SFS (Serving Framework Simulation)

Per prevedere il TTFT accuratamente senza l'esecuzione in tempo reale, gli autori progettano uno stimatore leggero che simula il comportamento del framework di serving.

• Input: Lo stimatore utilizza lo stato corrente dell'istanza del modello, inclusi l'insieme delle richieste residenti ($R_j(t)$), i loro token di prefill rimanenti e le lunghezze di decode previste.
• Processo di Simulazione:
  1. Costruisce un carico di lavoro aumentato includendo la nuova query e tutte le query residenti.
  2. Simula deterministicamente le politiche di continuous batching e scheduling del framework di serving per formare i batch di token.
  3. Itera attraverso questi batch fino a quando la nuova query genera il suo primo token di decode.
• Modello di Tempo di Elaborazione Token-Batch: Invece di simulare i kernel a basso livello, lo stimatore utilizza un modello lineare calibrato (Eq. 9) per prevedere il tempo per ogni batch di token. Questo modello tiene conto di:
  • Overheads fissi.
  • Computazione dei layer densi per token (lineare con la dimensione del batch).
  • Computazione dell'attenzione e letture della KV-cache (lineare con la lunghezza del contesto per il decode).
  • Costi di attenzione del prefill (quadratico all'interno del chunk di prefill).
• Output: La somma dei tempi di elaborazione previsti per tutti i batch simulati fino al primo token di decode fornisce la stima del TTFT.

3. Stima del Caso Medio (Senza Dati in Tempo Reale)

In scenari in cui non sono disponibili snapshot del carico di lavoro in tempo reale (ad esempio, routing verso cloud di terze parti), gli autori propongono un'astrazione basata sulla teoria delle code utilizzando un modello di Limited Processor Sharing (LPS). Questo modella l'istanza come un server che condivide la capacità tra fino a $k$ query concorrenti, con le altre in attesa in una coda FIFO. Ciò consente di stimare i tempi di attesa medi basandosi sui tassi di arrivo e sulle capacità di servizio.

Contributi Chiave

1. Framework di Ottimizzazione Congiunta: Il paper colma il divario tra il routing accuratezza-costo e l'ottimizzazione della latenza a livello di sistema, progettando un router che prende decisioni di routing basate su tutte e tre le metriche simultaneamente.
2. Stimatore SFS Leggero: Gli autori introducono un nuovo stimatore di latenza che simula l'elaborazione autoregressiva dei batch di token. Esso cattura l'interazione complessa tra i carichi di lavoro di prefill e decode e le politiche del framework di serving (come i chunked prefill) senza richiedere l'esecuzione completa.
3. Alta Accuratezza e Basso Overhead: Lo stimatore SFS raggiunge un Errore Assoluto Medio Percentuale (MAPE) inferiore al 5% nelle previsioni del TTFT con un overhead al tempo di test di circa 0,14 ms (sub-millisecondo), rendendolo adatto al percorso critico del routing.
4. Robustezza: Il framework è valutato sia sotto arrivi Poisson standard che sotto arrivi bursty di tipo Markov-Modulated Poisson Process (MMPP), dimostrando miglioramenti costanti delle prestazioni.

Risultati Sperimentali

Gli autori hanno valutato il loro approccio utilizzando tre modelli Qwen3 (0.6B, 8B, 32B) implementati su GPU H100 con il framework di serving vLLM. Hanno confrontato il loro router basato su SFS con tre baseline:

• Round Robin: Assegnazione ciclica che ignora il carico di lavoro.
• Shortest Queue: Assegna all'istanza con meno richieste (orientato alla latenza, agnostico rispetto all'accuratezza).
• Latency-Agnostic: Massimizza l'utilità ignorando la latenza.

Risultati Principali:

• Miglioramento dell'Utilità: Il metodo proposto produce un miglioramento dell'utilità accuratezza-costo fino al 40% rispetto alle standard baseline di bilanciamento del carico (come Shortest Queue) mantenendo gli stessi vincoli di latenza.
• OnTimeUtility: In vari scenari di tasso di arrivo delle query, il router SFS ha ottenuto un AUC (Area Under the Curve) per l'OnTimeUtility superiore del 33% rispetto alla migliore baseline.
• Controllo del Compromesso: Variando il parametro di penalità della latenza $\delta$ nella rilassazione Lagrangiana, il router fornisce una curva di compromesso controllabile tra utilità e latenza, superando le baseline che non riescono a bilanciare efficacemente queste metriche.
• Prestazioni dello Stimatore: La baseline basata sul throughput (che ignora l'interferenza di decode) ha mostrato un MAPE dell'85%, mentre lo stimatore SFS ha ridotto tale valore al 5%, evidenziando la necessità di simulare l'intera dinamica del framework di serving.

Significato e Rivendicazioni

Il paper sostiene che l'ottimizzazione congiunta di accuratezza, costo e latenza è essenziale per un deployment efficiente di LLM in carichi di lavoro dinamici. Gli autori affermano che i router esistenti falliscono perché trattano la latenza come una questione di sistema separata dalla selezione del modello, portando a un utilizzo subottimale delle risorse e a violazioni degli SLO.

Integrando uno stimatore di latenza leggero basato sulla simulazione direttamente nella decisione di routing, il framework proposto evita istanze sovraccariche preservando al contempo le forti prestazioni di accuratezza-costo. Il lavoro dimostra che è possibile ottenere guadagni significativi in utilità (fino al 40%) senza sacrificare i vincoli di latenza, unificando efficacementamente gli obiettivi precedentemente separati di "smart routing" (accuratezza/costo) e "load balancing" (latenza). Gli autori lo posizionano come una soluzione pratica per i deployment nel mondo reale dove i carichi di lavoro delle query sono dinamici e gli SLO sono rigorosi.