Un server AI domestico può condividere un unico modello tra più sessioni utente?

Sì. Un singolo server AI domestico può caricare un modello una volta e servire più sessioni utente. I moderni server di inferenza sono progettati per condividere i costosi pesi del modello mantenendo separato lo stato delle richieste per ogni conversazione. Questo è molto più efficiente in termini di memoria rispetto al caricamento di una seconda copia dello stesso modello per ogni membro della famiglia.

Il principale limite di scalabilità di solito non sono i pesi. Sono la cache KV in crescita, la lunghezza del contesto, la generazione simultanea di token e l'accodamento creato dagli utenti attivi. L'erogazione multiutente è quindi tanto un problema di pianificazione quanto di dimensioni del modello.

Che cosa condividono effettivamente gli utenti?

                 Un modello caricato
                 pesi nella RAM/VRAM
                         |
       +-----------------+-----------------+
       |                 |                 |
    sessione A        sessione B        sessione C
   cache KV A        cache KV B        cache KV C
   cronologia A         cronologia B         cronologia C

I pesi del trasformatore sono di sola lettura durante la normale inferenza, quindi molte richieste possono utilizzare la stessa copia. Ogni sequenza necessita comunque del proprio stato dei token e della propria cache di attenzione.

Come gestiscono le richieste simultanee i server di inferenza?

I diversi runtime espongono controlli di pianificazione differenti, ma il principio è simile: ammettere più sequenze, raggruppare il lavoro quando possibile e accodare le richieste in eccesso.

Le FAQ di Ollama documentano i controlli sulle richieste parallele e sottolineano che il contesto parallelo aumenta i requisiti di memoria. L'esempio parallelo di llama.cpp mostra più client simulati che utilizzano un unico server del modello.

I server ad alto throughput, come vLLM, utilizzano il batching e una pianificazione che tiene conto della cache KV per mantenere gli acceleratori impegnati su più sequenze in arrivo.

Perché la lunghezza del contesto può consumare più memoria di quanto suggerisca un altro utente

Supponiamo che i pesi del modello entrino comodamente nella VRAM. Quattro utenti aprono ciascuno una conversazione molto lunga. I pesi non si quadruplicano, ma la cache KV può crescere notevolmente per ogni sequenza attiva.

budget VRAM
  |
  +-- pesi del modello      fissi
  +-- cache KV utente A    cresce con il contesto
  +-- cache KV utente B    cresce con il contesto
  +-- cache KV utente C    cresce con il contesto
  +-- sovraccarico di runtime

Ecco perché «il modello entra in memoria» non è sufficiente per pianificare la capacità. I sistemi multiutente dovrebbero impostare una lunghezza massima del contesto, un numero massimo di sequenze simultanee e una coda con dimensioni limitate.

La guida esistente di ZimaSpace sulla pianificazione degli acceleratori per l'IA domestica multiutente approfondisce lo stesso confine delle risorse.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ogni utente dovrebbe avere un processo dedicato per il modello?

Di solito no. I processi separati duplicano i pesi e riducono il numero di modelli che possono essere caricati in memoria. Possono comunque essere appropriati quando:

• gli utenti hanno bisogno di fine-tuning o quantizzazioni differenti;
• l'isolamento efficace dei processi è più importante dell'efficienza;
• un carico di lavoro utilizza un runtime personalizzato;
• desideri un'allocazione rigida della GPU per utente;
• un modello ha requisiti incompatibili di contesto o campionamento.

Per una famiglia o un piccolo team che utilizza lo stesso modello, di solito è più semplice avere un singolo servizio di inferenza dietro un'applicazione autenticata.

Mantieni la memoria delle conversazioni fuori dal server dei modelli

Il server di inferenza non dovrebbe essere il database autorevole per stabilire «chi ha detto cosa». Archivia la cronologia delle chat e le preferenze degli utenti nel livello applicativo, utilizzando un ID esplicito dell'utente o della sessione.

Browser / app
    |
    | user_id autenticato
    v
Applicazione di chat
    |
    +-- database della cronologia (per utente)
    +-- autorizzazioni RAG
    |
    v
Server di modelli condiviso

Prima di ogni generazione, l'applicazione assembla solo la cronologia e il contesto privato recuperato che l'utente corrente è autorizzato a visualizzare.

Questo è particolarmente importante per un assistente IA privato su un NAS, dove lo stesso server può contenere documenti personali appartenenti a diversi membri della famiglia.

La memorizzazione nella cache dei prefissi condivisi non equivale alla memoria condivisa delle conversazioni

Alcuni runtime possono riutilizzare la cache KV o altri calcoli per prefissi di prompt comuni. Un'istruzione di sistema condivisa o il prefisso ripetuto di un documento possono quindi essere elaborati una sola volta e riutilizzati in modo efficiente.

Questa ottimizzazione non deve essere confusa con la possibilità che il contesto privato di un utente confluisca nel prompt di un altro. I sistemi di caching richiedono un corretto isolamento e una semantica di hashing appropriata; sono le autorizzazioni dell'applicazione a decidere quali contenuti possono essere forniti a una richiesta.

Usa una pianificazione equa per impedire a un singolo utente di occupare il server

Una singola richiesta che richiede un output molto lungo può consumare la capacità di decodifica mentre gli altri utenti aspettano. Aggiungi controlli di ammissione come:

• limite di richieste simultanee per utente;
• numero massimo di token generati;
• finestra di contesto massima;
• numero massimo globale di sequenze attive;
• timeout della coda;
• priorità per le richieste interattive brevi;
• coda batch separata per i processi in background.

La chat interattiva e la sintesi notturna dei documenti non dovrebbero competere applicando la stessa politica di pianificazione.

Cosa succede quando il server esaurisce la memoria?

Un buon servizio rifiuta o accoda il nuovo lavoro prima che l'acceleratore vada in crash. I controlli della capacità dovrebbero usare il contesto effettivamente configurato, non solo una media ottimistica.

Non ridurre silenziosamente la finestra di contesto di ogni utente finché il server non smette di andare in crash. Rendi visibile la politica del contesto, così gli utenti sanno cosa il sistema può conservare.

La privacy e l'autenticazione sono ancora più importanti in modalità multiutente

Quando un modello serve un solo amministratore, potrebbe essere sufficiente un endpoint accessibile solo da localhost. Quando lo usano più persone, l'applicazione dovrebbe autenticare gli utenti e autorizzarne le origini dati.

Proteggi:

• cronologie delle chat;
• collezioni RAG e ACL dei documenti;
• prompt salvati;
• credenziali degli strumenti;
• file generati;
• log e tracce.

Un processo del modello condiviso dovrebbe vedere solo il contesto della richiesta corrente e non dovrebbe diventare una comoda scappatoia per aggirare il normale modello di autorizzazioni del NAS.

Quanti utenti può supportare un singolo server IA domestico?

Non esiste un numero fisso utile. Un server può supportare molti utenti registrati se solo uno o due sono attivi, mentre due utenti simultanei con contesti lunghi possono esaurire una GPU di piccole dimensioni.

Confronta tre scenari:

1. un utente interattivo;
2. il carico domestico simultaneo previsto;
3. un utente intenso più diverse richieste brevi.

Misura il tempo al primo token, i token al secondo per utente, il tempo di coda, l'utilizzo della cache KV, l'uso di RAM/VRAM e il tasso di richieste non riuscite.

Domande frequenti

Gli utenti vedranno le conversazioni degli altri perché il modello è condiviso?

Non se l'applicazione mantiene separati la cronologia delle conversazioni e il contesto di recupero. Condividere i pesi del modello non implica condividere la cronologia delle chat.

L'inferenza parallela rende più veloce ogni utente?

Può aumentare il throughput totale, ma ogni singola richiesta potrebbe ricevere meno risorse di calcolo quando sono attive più sequenze. L'obiettivo è solitamente offrire un servizio aggregato migliore e ridurre i tempi di coda.

Un server può anche ospitare diversi modelli?

Sì, se la memoria lo consente. Alcuni runtime caricano e scaricano i modelli quando necessario, mentre altri sono progettati attorno a uno o più processi persistenti di servizio. La pianificazione di più modelli aggiunge un ulteriore livello di gestione della capacità oltre a quella multiutente.

Verdetto finale

Un modello caricato è esattamente la risorsa che, di norma, dovrebbe condividere un piccolo servizio IA domestico. Mantieni condivisi i pesi del modello, isola la cronologia delle sessioni e lo stato KV, autentica ogni utente, limita il contesto e la concorrenza e pianifica separatamente le attività in background rispetto alla chat interattiva. L'IA multiutente diventa affidabile quando si pianificano lo stato per sessione e il comportamento delle code, invece di moltiplicare i processi del modello.