DriftSched: Adaptive QoS-Aware Scheduling under Runtime Token Drift for Multi-Tenant GPU Inference

Sintesi Tecnica: DriftSched

Definizione del Problema
La rapida adozione dei Large Language Models (LLM) ha intensificato la domanda di uno scheduling efficiente delle GPU in ambienti multi-tenant per i datacenter AI. Sebbene i moderni runtime di inferenza come vLLM abbiano ottimizzato il throughput attraverso il continuous batching e la gestione della memoria, stimare accuratamente il costo di esecuzione di richieste di inferenza eterogenee rimane una sfida significativa. Gli approcci di scheduling esistenti si affidano tipicamente a limiti di token statici, vincoli di output specificati dall'utente o assunzioni di carico predefinite. Questi metodi statici non riescono a catturare il comportamento dinamico dei carichi di lavoro reali degli LLM, dove la lunghezza dell'output osservata devia frequentemente dai valori attesi a causa della complessità del prompt, delle caratteristiche della risposta e del comportamento del modello.

Il documento identifica questa discrepanza come runtime token drift (deriva dei token a runtime). Questo fenomeno introduce errori di stima che si propagano nelle decisioni di scheduling, portando a una classificazione errata del carico di lavoro, squilibrio delle code, inflazione della latenza di coda (tail latency), allocazione non equa delle risorse tra i tenant e degradazione della Qualità del Servizio (QoS) sotto contesa di GPU. Gli algoritmi di scheduling tradizionali (ad es., FIFO, SJF), progettati per sistemi con costi di esecuzione prevedibili, faticano negli ambienti multi-tenant di LLM dove il comportamento a runtime dipende da fattori dinamici come la crescita della KV-cache e la dinamica del batching.

Metodologia e Architettura del Sistema
Per affrontare queste sfide, gli autori propongono DriftSched, un framework di scheduling adattivo consapevole della QoS, progettato per l'inferenza LLM multi-tenant su GPU NVIDIA L4. L'architettura del sistema integra la classificazione del carico di lavoro, la stima del budget di token, la gestione delle code consapevole del tenant e un meccanismo di compensazione della deriva guidato dal feedback a runtime.

1. Stima Adattiva dei Token: A differenza degli approcci statici, DriftSched stima il costo dell'inferenza prima dell'esecuzione sulla GPU combinando la classificazione del carico di lavoro, fattori di sicurezza consapevole del tenant e la complessità del prompt. Fondamentalmente, impiega un fattore di bias adattivo ($B_{runtime}$) che viene continuamente aggiornato tramite il feedback di esecuzione. Il conteggio stimato dei token di output è calcolato come:
   $$T_{estimated\_output} = T_{base} \times B_{runtime} \times S_{tenant} \times F_{input}$$
   dove $B_{runtime}$ viene appreso dal rapporto tra le lunghezze di output osservate e le stime di base.

2. Classificazione del Carico di Lavoro e Accodamento: Le richieste di inferenza vengono classificate in categorie semantiche (short_qa, summary, technical, report) e mappate in classi di scheduling a runtime (short, medium, long) in base al budget di token stimato. Le richieste sono assegnate a code specifiche per tenant (Premium, Standard, Batch) gestite tramite Redis.

3. Strategie di Scheduling: Il framework valuta cinque politiche di scheduling: First-Come First-Serve (FIFO), Priority Scheduling, Weighted Scheduling, Shortest-Job-First (SJF) e Aging Priority Scheduling.

4. Ciclo di Feedback: Il sistema opera in due fasi: una fase di calibrazione (primi 1.000 input) per raccogliere il feedback a runtime e far convergere i fattori di bias, e una fase di valutazione dello stress (successivi 2.000 input) in cui lo scheduler utilizza i valori di bias appresi continuando l'adattamento online. La regola di aggiornamento adattivo utilizza una Media Mobile Esponenziale (EMA) per affinare i fattori di bias in base alla deviazione tra i token stimati e quelli osservati.

Contributi Chiave

• Architettura Adattiva Consapevole del Drift: Un nuovo framework di scheduling che tratta la stima del carico di lavoro come un problema di compensazione del drift dei token a runtime, aggiornando dinamicamente i fattori di bias per allineare le previsioni al comportamento osservato.
• Meccanismo di Compensazione del Runtime Token Drift: Un metodo guidato dal feedback che riduce l'errore di stima confrontando continuamente i budget di token stimati con le lunghezze effettive dell'output, migliorando l'accuratezza dello scheduling al momento dell'ammissione.
• Framework di Benchmarking Riproducibile: Una configurazione di valutazione completa utilizzando vLLM su GPU NVIDIA L4, simulando traffico multi-tenant eterogeneo con diverse complessità di prompt e tassi di arrivo per valutare equità, latenza e throughput.

Risultati Sperimentali
Gli esperimenti sono stati condotti utilizzando 3.000 richieste di inferenza attraverso tre livelli di tenant e quattro tipi di carico di lavoro semantico su una GPU NVIDIA L4.

• Esistenza del Token Drift: Lo studio ha confermato un misurabile runtime token drift attraverso le categorie di carico di lavoro. La stima statica del budget di token sovrastimava costantemente il comportamento di generazione effettivo.
• Accuratezza della Stima: Il meccanismo di feedback adattivo ha ridotto l'errore di stima del carico di lavoro in media del 38,8% (MAE) e del 40,5% (RMSE) in tutte le politiche di scheduling valutate rispetto ai baseline statici.
• Prestazioni di Latenza: Tra le politiche di scheduling, Shortest-Job-First (SJF) ha ottenuto le migliori prestazioni complessive. Rispetto a FIFO, SJF ha ridotto la latenza end-to-end mediana (P50) di circa il 42% e la latenza P99 di circa il 16%. Questo miglioramento è stato attribuito alla prioritizzazione dei carichi di lavoro più brevi e alla riduzione dell'occupazione delle code.
• Trade-off: Mentre SJF ha ottimizzato la latenza globale, gli scheduler consapevoli del tenant (Priority, Weighted, Aging) hanno fornito una differenziazione della QoS più forte per i tenant Premium. Ad esempio, lo scheduling Priority ha ridotto la latenza del tenant Premium a ~77 secondi, ma ha aumentato la latenza del tenant Batch a ~427 secondi.
• Utilizzo della GPU: L'analisi ha rivelato che la latenza di esecuzione della GPU e l'utilizzo della memoria sono rimasti relativamente costanti in tutte le politiche di scheduling. Ciò indica che le differenze di prestazione sono originate dalla gestione delle code e dall'ordinamento dei carichi di lavoro piuttosto che da cambiamenti nell'efficienza di esecuzione della GPU.

Significatività e Rivendicazioni
Il documento sostiene che il runtime token drift sia un fenomeno misurabile e praticamente significativo nei sistemi di serving LLM multi-tenant. La significatività primaria di DriftSched risiede nella sua dimostrazione che la stima guidata dal feedback adattivo può migliorare sostanzialmente la caratterizzazione del carico di lavoro e l'efficacia dello scheduling sotto contesa di GPU.

Gli autori affermano che i loro risultati forniscono intuizioni pratiche per le piattaforme enterprise di serving AI, evidenziando che una stima accurata del carico di lavoro a runtime è critica per i futuri runtime di inferenza adattivi. Il lavoro completa le architetture esistenti (ad es., Orca, Sarathi, vLLM) introducendo la stima adattiva del carico di lavoro come un segnale di scheduling aggiuntivo. Lo studio conclude che, sebbene lo scheduling consapevole del carico di lavoro (come SJF) riduca significativamente la latenza di coda, esso comporta un compromesso con l'equità a livello di tenant, suggerendo che i sistemi futuri debbano bilanciare l'efficienza globale con le garanzie del livello di servizio. Il documento nota con modestia che la valutazione è stata condotta su una singola piattaforma GPU e un singolo modello, e che il lavoro futuro esplorerà scenari multi-GPU e lo scheduling basato sul reinforcement learning.