Robust Batch-Level Query Routing for Large Language Models under Cost and Capacity Constraints

Il paper propone un framework di routing a livello di batch per modelli linguistici su larga scala che, ottimizzando congiuntamente l'assegnazione dei modelli e gestendo l'incertezza delle prestazioni, garantisce il rispetto dei vincoli di costo e risorse GPU mentre migliora significativamente accuratezza e throughput rispetto ai metodi tradizionali.

L'essenziale

Immagina di essere il capo di un grande ristorante (il sistema di intelligenza artificiale) che riceve centinaia di ordini (le domande degli utenti) ogni minuto. Hai a disposizione diversi cuciniere (i diversi modelli di intelligenza artificiale, o LLM):

• Alcuni sono chef stellati (modelli potenti come GPT-4): cucinano piatti perfetti, ma costano una fortuna e impiegano molto tempo.
• Altri sono cuochi veloci ed economici (modelli più piccoli): fanno un buon lavoro per le cose semplici, ma potrebbero sbagliare se il piatto è troppo complicato.

Il problema è che il ristorante ha un budget limitato (costi in denaro) e un numero limitato di fornelli (schede grafiche o GPU). Se chiami sempre lo chef stellato per tutto, vai in bancarotta. Se chiami sempre il cuoco economico per tutto, i clienti si lamentano della qualità.

Il vecchio modo di fare le cose (Routing "per domanda")

Fino a poco tempo fa, i ristoranti decidevano per ogni singolo ordine: "Questa domanda è facile? Chiamo il cuoco economico. È difficile? Chiamo lo chef stellato."

Il problema? Non controllavano il conto totale del turno.
Immagina che arrivi un gruppo di 100 clienti tutti insieme, e per caso tutti vogliono piatti difficilissimi. Il vecchio sistema chiamerebbe lo chef stellato per tutti e 100. Risultato? Il ristorante supera il budget in un attimo, i fornelli si bloccano e il servizio si ferma. Oppure, se arrivano 100 ordini banali, il sistema potrebbe sprecare soldi chiamando lo chef stellato per niente.

La nuova soluzione: "Routing a Blocchi" (Batch-Level)

Gli autori di questo articolo propongono un approccio più intelligente: invece di guardare un solo ordine alla volta, guardano l'intero gruppo di ordini che arriva insieme (il "batch").

È come se il capo del ristorante guardasse il tavolo intero prima di decidere:
"Ok, abbiamo 100 ordini. 80 sono semplici (usiamo i cuochi economici), 15 sono medi (un mix), e 5 sono complessi (usiamo lo chef stellato). Dobbiamo assicurarci che il totale non superi il budget e che abbiamo abbastanza fornelli accesi."

Usano una matematica avanzata (chiamata Programmazione Lineare Interera) per trovare la combinazione perfetta che massimizza la qualità del cibo rispettando il budget e i fornelli disponibili.

Il tocco in più: "La versione Robusta" (Robust Optimization)

C'è un altro problema: a volte non siamo sicuri al 100% di quanto sarà bravo uno chef su un piatto specifico. Forse lo chef stellato è stanco oggi, o forse il cuoco economico è in una giornata di grazia.

Il sistema "normale" si fida ciecamente delle stime: "Penso che questo chef sia bravo, quindi lo chiamo".
Il sistema "Robusto" invece dice: "Ok, penso che sia bravo, ma potrei sbagliarmi. Quindi, per sicurezza, assumiamo il caso peggiore possibile. Se anche lo chef fosse al minimo della forma, riusciremmo comunque a servire un buon pasto senza superare il budget?"

In pratica, il sistema "Robusto" è più prudente. Non scommette tutto sulla perfezione, ma si assicura che, anche se le cose vanno storte, il ristorante non fallisca e i clienti siano comunque soddisfatti.

L'ultimo pezzo del puzzle: "Assegnare i Fornelli" (Instance Allocation)

Prima ancora che i clienti arrivino, il proprietario deve decidere: "Quanti fornelli devo accendere per ogni tipo di cuoco?"
Se ne accendo troppi per gli chef stellati, spreco soldi di elettricità. Se ne accendo pochi per i cuochi veloci, non riesco a servire la folla.

Gli autori hanno creato un metodo per calcolare esattamente quanti "posti lavoro" (GPU) assegnare a ogni tipo di modello prima che inizi la giornata, basandosi sui dati storici, per ottenere il massimo rendimento.

I Risultati in Pillole

Grazie a questo metodo, il ristorante (il sistema di intelligenza artificiale):

1. Risparmia soldi: Non spreca risorse su cose semplici.
2. Mantiene la promessa: Anche se arriva un gruppo di clienti "difficili" (batch avversari), il sistema non va in crisi e rispetta il budget.
3. È più sicuro: La versione "Robusta" evita errori disastrosi quando le previsioni non sono perfette.
4. Migliora la qualità: Riesce a dare risposte migliori rispetto ai metodi vecchi, anche con lo stesso budget.

In sintesi: Hanno trasformato la gestione delle intelligenze artificiali da un gioco di "chi risponde per primo" a una gestione strategica di gruppo, dove ogni risorsa viene usata nel modo più intelligente possibile, tenendo sempre conto del portafoglio e della possibilità che le cose vadano storte.

Sommario tecnico

1. Il Problema

I sistemi di inferenza per i Modelli Linguistici su Grande Scala (LLM) devono bilanciare la qualità della risposta con i costi computazionali e le risorse hardware (GPU). Sebbene esistano metodi di routing (instradamento) che decidono quale modello utilizzare per ogni singola query, questi approcci per-query presentano limitazioni fondamentali quando applicati in scenari reali di produzione:

• Controllo dei costi a livello di batch: I metodi attuali ottimizzano query per query, ignorando che i sistemi di inferenza lavorano in batch dinamici. Questo porta a una variabilità incontrollata dei costi per batch, rendendo difficile rispettare budget rigorosi, specialmente sotto carichi di lavoro "avversari" (dove molte query difficili arrivano insieme).
• Vincoli di capacità: Non tengono conto dei limiti fisici delle istanze dei modelli (es. numero di GPU disponibili o concorrenza massima), rischiando di sovraccaricare modelli costosi o con capacità limitata.
• Incertezza nelle stime: Le stime di performance dei modelli sono spesso rumorose. Un routing basato su stime puntuali può portare a decisioni catastrofiche se la stima è sovrastimata.
• Allocazione delle risorse statica: Spesso non si ottimizza preventivamente quante istanze di un modello locale (self-hosted) deployare rispetto ai modelli cloud.

2. Metodologia Proposta

Gli autori propongono un framework di routing a livello di batch basato sulla Programmazione Lineare Interi (ILP) e sull'Ottimizzazione Robusta.

A. Routing a Livello di Batch (Online)

Invece di decidere query per query, il sistema risolve un problema di ottimizzazione per ogni batch di $N$ query e $M$ modelli disponibili.

• Obiettivo: Massimizzare la qualità media di routing per il batch.
• Vincoli:
  1. Costo: Il costo totale del batch non deve superare un budget $C$.
  2. Capacità: Il numero di query assegnate a un modello $j$ non deve superare la sua capacità totale ($l_j \times I_j$, dove $I_j$ è il numero di istanze).
  3. Assegnazione: Ogni query deve essere assegnata a esattamente un modello.
• Soluzione: Il problema è formulato come un ILP risolvibile efficientemente (in millisecondi) con solver come SCIP, anche per batch di grandi dimensioni.

B. Ottimizzazione Robusta

Per gestire l'incertezza nelle stime di performance ($a_{i,j}$), il framework utilizza un approccio robusto:

• Invece di usare la stima puntuale della performance, si utilizza il limite inferiore di un intervallo di previsione (es. il 10° percentile di una distribuzione generata tramite bootstrap).
• Questo garantisce che il routing ottimizzi la performance nel caso peggiore (worst-case), riducendo il rischio di fallimenti catastrofici quando le stime sono imprecise.

C. Allocazione Offline delle Istanze

Prima dell'inferenza online, viene risolto un problema di ottimizzazione offline per determinare il numero ottimale di istanze ($I_j$) da allocare per ciascun modello (specialmente per quelli self-hosted su GPU).

• Questo processo simula le prestazioni del router su batch di calibrazione per bilanciare qualità e capacità, massimizzando l'efficienza delle risorse hardware disponibili.

3. Contributi Chiave

1. Identificazione delle carenze: Dimostrazione empirica che il routing per-query fallisce nel controllare i costi a livello di batch e non gestisce bene scenari avversari o vincoli di capacità eterogenei.
2. Framework di Routing Robusto: Introduzione di un framework ILP che integra vincoli di costo e capacità hardware, utilizzando l'ottimizzazione robusta per mitigare l'incertezza delle stime.
3. Pianificazione delle Risorse: Un metodo per l'allocazione ottimale delle istanze dei modelli (GPU) prima del deployment, colmando il divario tra pianificazione offline e routing online.
4. Validazione Sperimentale: Dimostrazione che l'approccio proposto è computazionalmente efficiente (risolvibile in tempo reale) e superiore agli stati dell'arte.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su due benchmark multi-task (Dataset 1 e Dataset 2) confrontando il metodo proposto con approcci esistenti (come MIRT, kNN, XGBoost) e baselines per-query.

• Miglioramento della Robustezza: L'uso dell'ottimizzazione robusta ha migliorato l'accuratezza del 1-14% rispetto alle controparti non robuste, a seconda dello stimatore di performance utilizzato. Il routing robusto tende a selezionare modelli con minore incertezza predittiva.
• Vantaggio del Batch-Level:
  • In scenari di batching avversario (query difficili raggruppate), il routing a livello di batch supera i metodi per-query fino al 24% in termini di performance.
  • Garantisce il rispetto rigoroso dei vincoli di budget per ogni singolo batch, eliminando i picchi di costo.
• Ottimizzazione delle Istanze: L'allocazione ottimizzata delle istanze dei modelli (rispetto a un'allocazione fissa) ha portato a guadagni aggiuntivi fino al 3% di performance, specialmente sotto vincoli di budget stringenti.
• Efficienza delle Risorse: Il sistema completo (routing + allocazione) ha raggiunto performance superiori ai singoli modelli migliori (es. DeepSeek_Chat) richiedendo significativamente meno GPU (es. 177 GPU contro 800 per un singolo modello) e mantenendo costi inferiori.

5. Significato e Implicazioni

Questo lavoro rappresenta un passo fondamentale verso il deployment industriale di sistemi LLM scalabili ed economici.

• Gestione Reale dei Costi: Passa da un controllo teorico del costo (tramite parametri $\lambda$) a un controllo pratico e vincolato a livello di batch, essenziale per la fattibilità economica delle applicazioni enterprise.
• Affidabilità: L'approccio robusto rende i sistemi di routing più resilienti agli errori di stima, un requisito critico per la produzione.
• Integrazione Olistica: Unisce la pianificazione delle risorse hardware (GPU) con la logica di routing software, offrendo una visione d'insieme per l'ottimizzazione end-to-end dell'inferenza LLM.
• Scalabilità: La dimostrazione che problemi ILP complessi possono essere risolti in millisecondi rende questa soluzione praticabile per sistemi ad alto throughput.

In sintesi, il paper propone una soluzione matematicamente rigorosa e praticamente applicabile per gestire il trade-off tra qualità, costo e risorse hardware nell'inferenza di LLM, superando i limiti degli approcci tradizionali basati su singola query.