In che modo la pianificazione degli acceleratori influisce sull’IA domestica multiutente?
La pianificazione dell’acceleratore influisce sull’uso dell’IA domestica da parte di più utenti, decidendo quali richieste iniziano, condividono ogni iterazione, mantengono lo stato in memoria o attendono dietro ad altre attività.
Diversi utenti della famiglia possono inviare richieste con costi molto differenti: una breve domanda sul controllo delle luci, un documento lungo, un’immagine, una richiesta vocale o un agente che genera numerose chiamate. L’acceleratore non può dedurre l’importanza per la famiglia basandosi solo sull’ordine di arrivo. Uno scheduler deve combinare ordine della coda, budget di token, batching, priorità, ammissione in memoria e permanenza dei modelli, mentre gli output restano imprevedibili. Le sezioni seguenti spiegano perché lo stesso hardware può sembrare equo, veloce o inutilizzabile a seconda di come vengono effettuate queste scelte.
FIFO considera l’ordine di arrivo come unica priorità
Una coda first in, first out è semplice, ma un prompt o una risposta lunghi possono ritardare molte richieste brevi arrivate in seguito.
Le richieste LLM hanno costi in token differenti, quindi un’equità basata solo sul numero di richieste può assegnare a un utente molto più tempo di acceleratore rispetto a un altro.
FIFO è prevedibile con un carico ridotto, ma produce blocchi in testa alla coda quando i carichi di lavoro domestici diventano eterogenei.
Il batching continuo condivide le iterazioni tra gli utenti
Gli scheduler a livello di iterazione possono aggiungere nuove sequenze tra un passaggio di decodifica e l’altro e rimuovere quelle completate senza ricostruire un unico batch fisso.
Lo scheduling delle iterazioni di Orca migliora l’utilizzo, consentendo a più utenti di procedere insieme.
La condivisione non garantisce la stessa velocità. Uno scheduler decide comunque quante sequenze ammettere, con quale frequenza far avanzare ciascuna e se un nuovo prefill debba interrompere le decodifiche attive.
Le politiche di priorità proteggono le richieste sensibili alla latenza
Il controllo vocale e le brevi conversazioni interattive possono meritare un’ammissione più rapida rispetto ai riepiloghi in background, agli embedding o alla generazione di immagini.
Llumnix gestisce le priorità di latenza per richieste LLM eterogenee.
La priorità deve includere un meccanismo di invecchiamento o quote, affinché le attività in background possano essere eseguite prima o poi e un utente privilegiato non possa penalizzare continuamente il resto della famiglia.
L’ammissione in memoria può bloccare una richiesta prima del calcolo
Una richiesta necessita della cache KV e di spazio di lavoro oltre ai pesi del modello. Lo scheduler può ritardarne l’ammissione anche quando le unità di calcolo sembrano inattive, perché la memoria disponibile non è sufficiente.
La guida di ZimaSpace sulla pressione sulla memoria con più utenti spiega perché contesti più lunghi riducono il numero di conversazioni che possono rimanere attive.
La prelazione di una sequenza libera capacità, ma in seguito può richiedere il ricalcolo o il ripristino del suo stato, trasformando la politica di memoria in ulteriore latenza.
Prefill e decodifica richiedono una pianificazione differente
I prefill lunghi utilizzano intensamente il calcolo, mentre la decodifica dei token legge ripetutamente i pesi e lo stato della cache. Eseguirli insieme senza controllo può bloccare l’output in streaming.
Sarathi-Serve utilizza uno scheduling senza blocchi e il prefill suddiviso in blocchi per migliorare il throughput limitando al contempo l’impatto sulla latenza.
Uno scheduler domestico può riservare opportunità di decodifica alle conversazioni attive e suddividere i prefill di documenti lunghi, invece di consentire a una singola richiesta di monopolizzare un’iterazione prolungata.
L’equità deve essere misurata in termini percepibili dall’utente
Il numero complessivo di token al secondo può aumentare mentre un utente attende molto più a lungo di un altro. Monitora il tempo in coda, il tempo al primo token, il ritardo tra i token, il tempo di completamento e la quota di servizio per utente o classe di carico di lavoro.
Il Virtual Token Counter definisce un’equità basata sui token, invece di considerare tutte le richieste uguali.
Utilizza classi esplicite per voce, chat interattive, agenti, embedding e attività di manutenzione. Poi prova richieste lunghe e brevi sovrapposte per verificare che la politica scelta corrisponda alle aspettative della famiglia.
La pianificazione non può creare maggiore capacità di accelerazione, ma può decidere se la carenza si manifesta come un rallentamento equo, picchi di latenza di coda o un utente che blocca tutti gli altri.
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...
