💻 computer science

OmniPilot: An Uncertainty-Aware LLM Inference Advisor for Heterogeneous GPU Clusters

OmniPilot è un consulente di inferenza consapevole dell'incertezza per cluster GPU eterogenei che predice i costi di servizio e si astiene da configurazioni inaffidabili utilizzando modelli quantili calibrati conformemente e il rilevamento di dati fuori distribuzione, ottimizzando così l'utilità economica con alta precisione attraverso diversi hardware e impostazioni di precisione.

Autori originali: D. Balamurugan, Thomas W. Bush

Pubblicato 2026-07-03✓ Author reviewed ⓘ

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: D. Balamurugan, Thomas W. Bush

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere il capitano di una massiccia astronave condivisa (un cluster di GPU) che trasporta centinaia di passeggeri diversi (modelli AI) che vogliono tutti raggiungere destinazioni differenti. Prima ancora che l'astronave possa lasciare il molo, devi decidere: Quale motore dobbiamo usare? Quanti motori dobbiamo collegare insieme? E che tipo di carburante dobbiamo bruciare?

Se sbagli il calcolo, l'astronave potrebbe sussultare, rimanere senza carburante o schiantarsi prima ancora di decollare. Questo è il problema che OmniPilot risolve.

Ecco la storia di OmniPilot, spiegata in modo semplice:

1. Il Problema: Indovinare è Costoso

Nel mondo dell'IA, far girare un "Large Language Model" (come quello con cui stai parlando proprio ora) è come guidare un'auto da corsa. Devi scegliere l'auto (la GPU), quanti piloti devono condividere il volante (Parallelismo Tensoriale) e quanto dettaglio deve elaborare l'auto (Precisione).

Il documento ha rilevato che se ti limiti a indovinare o usi una regola "universale", fallisci il 14% delle volte. A volte l'auto è troppo pesante per il motore, o il serbatoio del carburante è troppo piccolo. In un'astronave condivisa, un lancio fallito spreca tempo prezioso e denaro che avrebbero potuto essere utilizzati da qualcun altro.

2. La Soluzione: Il Co-pilota "Consapevole dell'Incertezza"

Gli autori hanno costruito OmniPilot, un consulente intelligente che agisce come un co-pilota esperto. Invece di darti solo una singola risposta, fa due cose speciali:

Prevede il futuro (con una rete di sicurezza): Analizza la tua richiesta e dice: "Se usi questo motore con questo carburante, probabilmente otterrai questa velocità". Ma non si limita a indovinare; ti fornisce un intervallo di confidenza. È come dire: "Andrai probabilmente a 100 miglia orarie, con uno scarto di 5 miglia".
Sa quando dire "Non lo so": Questa è la parte più importante. Se chiedi una configurazione che il co-pilota non ha mai visto prima (come un tipo completamente nuovo di motore o una strana miscela di carburante), non tira a indovinare. Alza una bandiera rossa e dice: "Fermati! Non ho testato questo. Non sono abbastanza sicuro per raccomandarlo". Questo si chiama astensione. Impedisce di schiantare l'astronave su terreni inesplorati.

3. Come Impara: Il "Registro di Volo"

OmniPilot non è magia; è uno studente che ha imparato da un enorme registro di viaggi passati.

Ha studiato 500.000 lavori passati dal cluster per capire quanto spesso le astronavi falliscono il lancio.
Ha eseguito 460 test specifici su diversi tipi di motori hi-tech (A100, H100, H200) per imparare esattamente come si comportano.
Ha imparato che le regole sono complicate. Ad esempio, a volte usare un carburante "meno dettagliato" (quantizzazione) rende l'auto più lenta, non più veloce, a seconda del motore. Un semplice manuale di regole perderebbe questi strani comportamenti, ma OmniPilot li ha imparati.

4. I Risultati: Scelte più Intelligenti

Quando i ricercatori hanno testato OmniPilot contro i metodi standard di processo decisionale:

Accuratezza: Ha scelto la combinazione migliore tra motore e carburante il 95% delle volte.
Costo: Ha risparmiato molti "node-ore" (tempo e denaro) evitando scelte errate.
Sicurezza: Quando hanno cercato di ingannarlo con uno scenario nuovo e non testato, il sistema ha risposto correttamente: "Non lo so", invece di dare una risposta sbagliata.

5. Cosa NON Fa (I Confini)

Il documento è molto chiaro su ciò che OmniPilot non è:

Non ripara il motore mentre è in funzione (questo spetta ad altri strumenti come vLLM).
Non gestisce l'addestramento di nuovi modelli di IA (l'insegnamento dell'IA), ma solo l'esecuzione (inferenza).
Non funziona se l'astronave è guasta (i guasti hardware sono fuori dall'ambito di questo specifico strumento).

Il Punto Fondamentale

OmniPilot è come un agente di viaggio intelligente per l'IA. Guarda la tua destinazione, controlla il meteo, esamina la cronologia di ogni aereo della flotta e ti dice esattamente quale aereo prenotare per arrivare il più velocemente e con il minor costo possibile. Soprattutto, se chiedi una rotta di volo che non ha mai volato, ti dice onestamente: "Non posso raccomandarla ancora", evitandoti un viaggio disastroso.

Combinando previsioni basate sui dati con un onesto pulsante "Non lo so", OmniPilot aiuta gli operatori a gestire i loro cluster di IA in modo più efficiente e sicuro.

Riepilogo Tecnico: OmniPilot

Problema

Servire Large Language Models (LLM) su cluster di GPU eterogenei e condivisi presenta un complesso problema decisionale pre-invio. Gli operatori devono selezionare il tipo di GPU, il grado di parallelismo tensoriale (TP), e la precisione numerica prima di impegnare preziose ore-nodo. Questo processo è pieno di sfide:

Tassi di fallimento elevati: La selezione cieca della configurazione porta a fallimenti immediati dovuti a incompatibilità hardware o esaurimento della memoria (OOM). Nei benchmark degli autori, il 14% dei job è fallito immediatamente.
Interazioni non intuitive: Le ricette di deployment statiche non riescono a catturare le intricate dinamiche hardware-software. Ad esempio, la quantizzazione a 4-bit può essere più lenta rispetto a quella a 16-bit su runtime specifici, e la pressione della KV-cache crea trade-off dimensionali non monotoni rispetto alla precisione.
Limitazioni dei dati: I tradizionali scheduler di cluster (es. Slurm) mancano di visibilità sui comportamenti specifici del carico di lavoro (famiglia di modelli, precisione, concorrenza) e si affidano a una telemetria obsoleta (es. intervalli di campionamento DCGM di 60 secondi) che rappresenta erroneamente le prestazioni di serving attive.
Incertezza: I sistemi esistenti ottimizzano l'esecuzione all'interno di una configurazione pre-selezionata, ma non forniscono stime di incertezza calibrate per la scelta di tale configurazione, lasciando gli operatori impossibilitati a distinguere tra richieste supportate e non supportate (Out-of-Distribution).

Metodologia

OmniPilot è un consulente di lancio progettato per prevedere i costi di serving e raccomandare configurazioni ottimali gestendo esplicitamente l'incertezza. La sua architettura si compone di tre componenti principali:

1. Infrastruttura Dati

OmniPilot utilizza due distinti depositi di dati per garantire la linea di derivazione e la riproducibilità:

Personal Store: Una griglia di benchmark controllata (1.667 righe) che copre specifiche famiglie di modelli, GPU e precisioni.
Cluster-wide Store: Telemetria aggregata da 500.000 job storici, utilizzata per derivare i priori di successo del lancio e i pattern di domanda.
Feature Engineering: Il sistema codifica circa 28 feature, inclusi numerici log-trasformati (dimensione del modello, concorrenza), numerici lineari (grado TP, memoria) e codifiche one-hot per famiglie di modelli, tipi di GPU e formati di quantizzazione. Fondamentalmente, nuove dimensioni (es. tipi di quantizzazione) sono rappresentate nel featurizer prima della raccolta dati per prevenire il leakage delle feature.

2. Modello di Costo di Inferenza

Il predittore centrale è un insieme di regressori gradient-boosted che utilizzano la quantile loss, addestrati nello spazio logaritmico per gestire errori moltiplicativi.

Target: Prevede otto target, tra cui throughput aggregato (token/s), throughput delle richieste, Time to First Token (TTFT), tempo di cold-start, picco di utilizzo della KV-cache e potenza media.
Calibrazione: Il modello impiega la Conformalized Quantile Regression (CQR) per generare intervalli di predizione. Utilizza un offset additivo split-conformal calibrato sui residui delle celle tenute da parte (held-out) per raggiungere una copertura dell'80% su carichi di lavoro non visti.
Meccanismo di Astensione: Per gestire le richieste Out-of-Distribution (OOD), OmniPilot utilizza un controllo della distanza di supporto (support-distance). Se una richiesta cade al di fuori dell'inviluppo di supporto misurato (definito su sette assi), il sistema la segnala come a bassa confidenza e si astiene, indipendentemente dall'ampiezza dell'intervallo.

3. Utilità Decisionale e Posizionamento

OmniPilot classifica le "braccia" di configurazione (combinazioni di GPU, TP e precisione) utilizzando una metrica di utilità economica calibrata sulle preferenze dell'operatore.

Funzione di Utilità: $Utility = (Throughput \times Runtime \times Value) - (Compute Cost + Queue Wait + Expected Failure Cost + SLO Violation Cost + KV-Saturation Penalty)$ .
Prior di Successo del Lancio: Un estimatore beta-binomialo restringe i tassi di fallimento per configurazione verso un tasso aggregato del cluster, tenendo conto del fatto che le configurazioni multi-GPU (es. TP=4) hanno un successo di lancio significativamente inferiore (~38%) rispetto alle configurazioni a singola GPU.
Penalità di Saturazione KV: Una penalità di throughput moltiplicativa viene applicata quando l'occupazione della KV-cache supera lo 0.85, convertendo le preemption in costi di utilità.

Contributi Chiave

Consulente Calibrato e Consapevole dell'Astensione: OmniPilot è il primo sistema che combina modelli di costo quantile conformemente calibrati con uno strato di astensione OOD esplicito per l'inferenza LLM. Predice metriche di performance insieme a intervalli calibrati e un segnale di sicurezza per bloccare richieste non supportate.
Valutazione Accoppiata alla Decisione: Il paper introduce un framework di valutazione privo di leakage utilizzando GroupKFold (raggruppato per cella di carico di lavoro) per confrontare l'advisor con baseline model-free. Dimostra che ottimizzare per l'utilità economica (incorporando costi e rischio di fallimento) produce un'accuratezza di posizionamento significativamente migliore rispetto a policy basate solo sul throughput o su regole.
Studio sulla Telemetria del Cluster (Risultato Negativo): Gli autori dimostrano che, sebbene i metadati dello scheduler (Slurm) siano sufficienti per derivare la domanda e i priori di successo del lancio, sono insufficienti per costruire un advisor di throughput per l'intero cluster perché registrano l'allocazione delle risorse (come una GPU è stata usata) piuttosto che il carico di lavoro software specifico (cosa vi è girato sopra).

Risultati

Valutato su 460 run di benchmark su hardware A100, H100 e H200:

Accuratezza della Predizione: OmniPilot predice il throughput aggregato con un Mean Absolute Percentage Error (MAPE) del 6.2% e un $R^2$ nello spazio logaritmico di 0.92.
Accuratezza del Posizionamento: L'advisor raggiunge il 95% di accuratezza top-1 nella selezione della configurazione ottimale, con un regret di utilità media di 0.003. È un ordine di grandezza migliore rispetto alle baseline come le regole "size-threshold" (regret 1.97) o le policy "throughput-max" (regret 4.73).
Gestione OOD: Su un set di holdout di 5 celle non supportate (nuove famiglie di modelli o contesti estremi), l'errore di predizione è salito al 24–46% e gli intervalli conformi non hanno coperto i valori reali. Tuttavia, lo strato di astensione ha identificato con successo tutte e cinque come a bassa confidenza, prevenendo deployment rischiosi.
Efficienza dei Dati: L'accuratezza satura dopo circa 150 righe di addestramento una volta coperti gli assi del task, indicando che la copertura dello spazio di configurazione è più critica del volume grezzo di dati.

Significato e Dichiarazioni

Il paper sostiene che OmniPilot colma una lacuna critica a livello macro nel serving di inferenza LLM in cluster GPU condivisi e multi-utente, trasformando la selezione della configurazione hardware in una decisione economica calibrata. La sua importanza risiede in:

Sicurezza e Affidabilità: Astendosi esplicitamente sulle richieste OOD, previene i fallimenti costosi che le ricette statiche o gli scheduler "best-effort" subirebbero.
Ottimizzazione Economica: Va oltre la semplice massimizzazione del throughput per ottimizzare una funzione di utilità complessa che bilancia costi, rischio di fallimento e SLO, allineandosi ai vincoli reali degli operatori.
Rigore Metodologico: Stabilisce un framework di design "feature-before-data" e dimostra che molti problemi di performance sono meglio risolti attraverso un design raffinato dell'utilità (es. penalità di saturazione KV) o la precisione della misurazione (es. finestre di freschezza) piuttosto che semplicemente aumentando la capacità del modello.

Gli autori rimangono modesti riguardo all'ambito, notando che il sistema è attualmente limitato al serving di inferenza vLLM a singolo nodo. I carichi di lavoro di training, il recupero dai guasti e le architetture di serving multi-nodo sono esplicitamente rimandati a ricerche future. Il sistema si basa su dati empirici di un cluster specifico (Kempner AI), e le soglie assolute (es. knee della saturazione KV) sono specifiche del deployment.