Perché un server AI domestico ha bisogno di code di lavoro separate?

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Un server AI domestico necessita di code di lavoro separate perché le richieste interattive e i processi in background hanno requisiti diversi in termini di latenza, memoria, tentativi e completamento.

Una sola macchina può gestire chat, controllo vocale, acquisizione di documenti, embedding, analisi delle foto, download di modelli, flussi di lavoro degli agenti e riepiloghi programmati. Una coda unica in ordine di arrivo tratta questi lavori come intercambiabili, anche se un ritardo di cinque secondi è accettabile per l’indicizzazione ma fastidioso per un comando vocale. Inoltre, i processi lunghi possono riservare memoria o larghezza di banda dello storage prima dell’arrivo delle richieste brevi. Le code separate rendono visibili le classi di carico di lavoro, così le politiche di ammissione, priorità, concorrenza e ripristino possono proteggere le funzioni domestiche che devono rispondere per prime.

Una coda FIFO unica crea il blocco della prima richiesta

Un prompt lungo, una richiesta di immagini, il caricamento di un modello o un batch di embedding in testa a una sola coda può ritardare molte richieste brevi che seguono.

FastServe affronta il blocco della prima richiesta con la pianificazione preemptive e più livelli di priorità, invece di un servizio che esegue ogni attività fino al completamento.

Un server domestico non ha bisogno dello stesso design distribuito per adottare questo principio. I processi interattivi brevi non dovrebbero aspettare una richiesta in background di durata sconosciuta solo perché è arrivata più tardi.

I processi interattivi e quelli in background richiedono obiettivi di servizio diversi

Le chiamate vocali, le chat e le automazioni tengono conto del tempo in coda e del tempo al primo token. Gli embedding, l’indicizzazione e i riepiloghi notturni puntano invece soprattutto al throughput complessivo e al completamento finale.

JITServe studia obiettivi di latenza diversi per richieste i cui flussi end-to-end e le cui scadenze non sono equivalenti.

Inserisci i processi interattivi in una coda a bassa latenza con concorrenza limitata. Inserisci i processi massivi in una coda orientata al throughput, che possa mettersi in pausa, elaborare batch o cedere risorse quando aumenta la domanda domestica.

La priorità dovrebbe includere l’invecchiamento, così un servizio chat continuamente occupato non finisce per affamare indefinitamente le attività di manutenzione.

Prefill, decodifica e preparazione dei modelli possono ostacolarsi a vicenda

Un prefill lungo utilizza le risorse di calcolo in modo diverso dalla decodifica dei token, mentre il caricamento dei modelli e la preparazione della cache possono attendere trasferimenti da storage e memoria.

DistServe separa prefill e decodifica perché la loro collocazione sullo stesso percorso può peggiorare la latenza anche quando l’utilizzo complessivo appare elevato.

Le code separate permettono alle chat attive di continuare ad avere opportunità di decodifica, mentre i prompt documentali di grandi dimensioni entrano attraverso un percorso di prefill controllato.

Una coda per il caricamento dei modelli può anche limitare il numero di modelli non presenti in cache che competono contemporaneamente per la larghezza di banda del disco e la memoria dell’acceleratore.

Il lavoro pronto non dovrebbe aspettare quello in fase di preparazione

Alcune richieste sono immediatamente eseguibili perché il modello e lo stato della cache sono già residenti. Altre richiedono il ripristino dei dati da uno storage più lento o il caricamento preventivo di un modello.

Bidaw utilizza due code per le richieste per impedire che il lavoro pronto attenda richieste il cui stato deve prima essere preparato.

L’equivalente domestico consiste nell’evitare di occupare la coda interattiva con una richiesta che non può essere eseguita finché non termina il download di un modello da dieci gigabyte o il ripristino della cache.

Anche le code dello storage e della CPU devono essere separate

I processi AI non competono solo sull’acceleratore. OCR, analisi dei PDF, tokenizzazione, scrittura dei vettori, miniature, backup e letture dei modelli possono saturare le code della CPU e dello storage.

L’analisi di ZimaSpace sulla contesa nella coda dello storage mostra perché un’attività massiva prolungata possa ritardare le applicazioni interattive self-hosted anche prima di considerare la pianificazione della GPU.

Limita la profondità delle operazioni di I/O in background, separa quando possibile i percorsi dei modelli e dei database e sospendi le scansioni dell’intera libreria durante i periodi di maggiore utilizzo domestico.

Una politica delle code che protegge il tempo della GPU ma consente all’OCR in background di saturare ogni core della CPU non riesce comunque a proteggere la latenza del recupero dati della chat.

Le politiche delle code richiedono ammissione, quote e osservabilità

I soli nomi separati non creano isolamento. Ogni coda necessita di un limite di concorrenza, un budget di memoria, una priorità, una politica per i tentativi, un timeout e una regola per prendere in prestito la capacità inutilizzata.

Agentix considera le dipendenze del flusso di lavoro come informazioni di pianificazione, così una chiamata breve che sblocca i passaggi successivi può ricevere un servizio adeguato.

Misura la profondità della coda, l’attesa più lunga, i processi in esecuzione, la memoria riservata, le preemption, il numero di tentativi e la latenza per classe di carico di lavoro. Gli avvisi dovrebbero indicare quale coda sta violando il proprio obiettivo.

Il design pratico è work-conserving: le code in background utilizzano la capacità disponibile, ma l’arrivo di richieste interattive può riprendersi tale capacità senza destabilizzare i processi già in esecuzione.

Domande frequenti

Un server AI domestico necessita di una macchina fisica separata per ogni coda?

No. Le code sono confini di pianificazione. Possono condividere una sola macchina applicando priorità, limiti di concorrenza e budget di risorse diversi.

I processi in background devono interrompersi sempre quando inizia una chat?

Non necessariamente. Possono continuare con una concorrenza ridotta quando rimane sufficiente margine di CPU, memoria, storage e accelerazione.

I container possono sostituire le code separate?

I container isolano i processi, ma non offrono automaticamente una pianificazione equa o un controllo dell’ammissione tra più carichi di lavoro AI.

Hub Tecnologico e AI

Altro da leggere

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.