In che modo il batching continuo influisce sull’equità su un server AI domestico?
Il batching continuo migliora l'utilizzo riempiendo nuovamente i batch attivi, ma l'equità dipende da come gli utenti ricevono accesso, servizio dei token e memoria nel tempo.
Un server AI domestico può gestire diverse conversazioni senza aspettare che ogni sequenza termini insieme alle altre. Le richieste completate escono, le nuove richieste entrano e gli utenti attivi condividono iterazioni di inferenza ripetute. Questo aumenta il throughput, ma le richieste non sono equivalenti: un utente può inviare un comando breve, un altro un documento lungo e un altro ancora un agente che genera centinaia di token. Uno scheduler equo deve stabilire quale unità di lavoro considerare, come ammettere le nuove richieste e come far interagire le priorità con lunghezze di output imprevedibili.
Il batching continuo cambia l'unità di scheduling: da un batch fisso alle iterazioni
Il batching statico mantiene un unico gruppo fino al completamento dell'intero gruppo, sprecando capacità quando le richieste brevi terminano in anticipo. Il batching continuo può riempire nuovamente gli slot disponibili tra un'iterazione di generazione e l'altra.
Orca ha introdotto lo scheduling a livello di iterazione, così le richieste possono entrare e uscire man mano che cambia lo stato della loro sequenza.
Questo migliora l'utilizzo, ma significa anche che gli utenti competono ripetutamente per un posto nell'iterazione successiva, invece di ricevere uno slot indivisibile per l'intera richiesta.
L'ordine di ammissione determina chi inizia ad accumulare servizio
Una richiesta al di fuori del batch attivo non riceve alcun avanzamento dal modello. Lo scheduler può ammettere le richieste in base all'ordine di arrivo, alla lunghezza stimata, alla priorità, ai blocchi KV disponibili o a un contatore di equità.
vLLM combina l'ammissione continua con la gestione paginata della cache KV, così la memoria può essere allocata man mano che le sequenze crescono.
Il principio first come, first served è semplice, ma una coda di richieste lunghe può ritardare i successivi comandi brevi degli utenti domestici, anche quando questi terminerebbero rapidamente.
Contare le richieste allo stesso modo può produrre un servizio diseguale dell'acceleratore
Una risposta di cinque token e una di cinquecento token sono entrambe una richiesta, ma occupano un numero molto diverso di iterazioni di decodifica. Anche la lunghezza dei prompt comporta quantità diverse di lavoro di prefill.
Il Virtual Token Counter definisce l'equità basata sui token, perché il semplice conteggio delle richieste non rappresenta il servizio consumato da carichi LLM eterogenei.
Una politica domestica dovrebbe stabilire se per equità si intende un'uguale quantità di lavoro in token, un uguale tempo di attesa, un'uguale opportunità di completamento o la priorità per le attività sensibili alla latenza.
Nessuna metrica soddisfa ogni carico di lavoro. Un comando vocale e un riepilogo in background non devono necessariamente ricevere un trattamento identico.
La lunghezza sconosciuta dell'output rende difficile prevedere il servizio futuro
Al momento dell'ammissione, lo scheduler conosce la dimensione del prompt, ma di solito non sa esattamente quanti token di output genererà il modello. Una richiesta può rimanere attiva molto più a lungo del previsto.
La ricerca sull'equità evidenzia le lunghezze imprevedibili delle richieste come una difficoltà specifica della gestione degli LLM.
Addebitare il servizio in base ai token effettivamente elaborati evita di dipendere completamente da una stima approssimativa della lunghezza, ma può comunque consentire a una richiesta lunga di occupare memoria per molte iterazioni.
I prefill di grandi dimensioni possono disturbare gli utenti che stanno già ricevendo token
Un nuovo prompt con un documento può entrare mentre diversi utenti stanno eseguendo la decodifica. Il suo prefill, intensivo dal punto di vista computazionale, può allungare l'iterazione che le conversazioni attive devono attendere.
Sarathi-Serve utilizza lo scheduling senza stalli per suddividere i prefill di grandi dimensioni e ridurne l'effetto sulla latenza di decodifica delle richieste in corso.
Uno scheduler che conta solo i token di decodifica può comunque essere ingiusto se un utente introduce ripetutamente prefill di grandi dimensioni che ritardano l'output trasmesso in streaming di tutti gli altri.
Un conteggio equo dovrebbe quindi includere l'elaborazione dell'input oltre ai token generati.
La pressione sulla memoria può creare problemi di equità prima che il calcolo raggiunga la saturazione
Ogni conversazione attiva richiede una cache KV e i contesti più lunghi consumano più blocchi. Un utente con un unico contesto di grandi dimensioni può ridurre il numero di altre richieste che entrano nel batch attivo.
L'analisi multiutente di ZimaSpace collega la concorrenza domestica alla memoria condivisa del modello e alle decisioni dello scheduler.
Sospendere o spostare una richiesta può ripristinare la capacità, ma l'utente interrotto potrebbe in seguito dover pagare il costo della ricalcolazione, del ricaricamento della cache o di un tempo di completamento più lungo.
L'ammissione in memoria e lo scheduling del calcolo devono quindi seguire la stessa politica di equità, invece di funzionare come limiti non correlati.
Le priorità richiedono invecchiamento, quote e misurazioni visibili agli utenti
Il controllo vocale, gli strumenti di accessibilità e le chat interattive brevi possono meritare una priorità maggiore rispetto agli embedding o ai riepiloghi notturni. Tuttavia, uno scheduling basato esclusivamente sulle priorità può lasciare senza servizio le attività a bassa priorità.
Llumnix utilizza lo scheduling dinamico per adattare il posizionamento delle richieste e le decisioni sulle risorse al variare delle condizioni di servizio.
Aggiungi l'invecchiamento delle richieste, quote per utente, limiti massimi per il contesto o l'output e una quota riservata per le attività in background, così il lavoro preferenziale risponde rapidamente senza bloccare indefinitamente tutto il resto.
Misura il tempo in coda, il tempo al primo token, il ritardo tra i token, il tempo di completamento, i token serviti e le sospensioni per utente o classe di carico. Il batching continuo è equo solo quando la distribuzione osservata corrisponde alla politica domestica, non semplicemente quando il numero totale di token al secondo è elevato.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Quali funzionalità consentono di creare un confine di fiducia per l’IA domestica attorno ai file sensibili?
Un confine di fiducia per l’IA domestica combina la crittografia dei dati inattivi, autorizzazioni con il principio del privilegio minimo, sandboxing in fase di...
Cosa fa sì che i risultati di ricerca privati favoriscano i file modificati frequentemente?
I file modificati frequentemente ottengono vantaggi nel ranking quando ogni aggiornamento aggiunge segnali di freschezza, segmenti, versioni o interazioni senza normalizzarli in base alla...
Cosa porta i modelli di rilevamento della presenza nelle smart home a confondere gli ospiti con i residenti?
Gli ospiti possono sembrare residenti quando il sistema osserva i modelli di attività domestica, ma non dispone di un segnale d’identità stabile per la...
