Kan een Home AI Server één model delen over meerdere gebruikerssessies?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Can a Home AI Server Share One Model Across Multiple User Sessions? - Zima Store Online

Ja. Eén thuis-AI-server kan een model eenmaal laden en meerdere gebruikerssessies bedienen. Moderne inferentieservers zijn ontworpen om de kostbare modelgewichten te delen en tegelijkertijd voor elk gesprek een afzonderlijke aanvraagstatus bij te houden. Dit is veel geheugenefficiënter dan voor elk gezinslid een tweede kopie van hetzelfde model te laden.

De belangrijkste schaalbaarheidsbeperking zit meestal niet in de gewichten. Het gaat om de groeiende KV-cache, de contextlengte, het gelijktijdig genereren van tokens en de wachtrij die door actieve gebruikers ontstaat. Bediening voor meerdere gebruikers is daarom net zo goed een planningsprobleem als een probleem van modelgrootte.

Wat wordt er daadwerkelijk gedeeld tussen gebruikers?

                 Eén geladen model
                 gewichten in RAM/VRAM
                         |
       +-----------------+-----------------+
       |                 |                 |
    Sessie A        Sessie B        Sessie C
   KV-cache A        KV-cache B        KV-cache C
   geschiedenis A         geschiedenis B         geschiedenis C

De transformergewichten worden tijdens gewone inferentie alleen gelezen, zodat veel aanvragen dezelfde kopie kunnen gebruiken. Elke reeks heeft nog steeds een eigen tokenstatus en aandachtscache nodig.

Resource	Gedeeld?	Waarom
Modelgewichten	Ja	Dezelfde parameters bedienen alle aanvragen
KV-cache	Nee, behalve bij gecontroleerd hergebruik van prefixes	Hangt af van elke reeks
Gespreksgeschiedenis	Nee	Applicatie-/gebruikersgegevens
Tokenizer	Ja	Dezelfde modelwoordenschat
GPU-berekening	Gepland	Aanvragen delen de doorvoer
Authenticatie	Nee	Moet elke aanroeper identificeren

Hoe verwerken inferentieservers gelijktijdige aanvragen?

Verschillende runtimes bieden verschillende planningsopties, maar het principe is vergelijkbaar: laat meerdere reeksen toe, bundel werk waar mogelijk en plaats overtollige aanvragen in de wachtrij.

De FAQ van Ollama documenteert instellingen voor parallelle aanvragen en vermeldt dat parallelle context het geheugenverbruik verhoogt. Het parallelle voorbeeld van llama.cpp demonstreert meerdere gesimuleerde clients die één modelserver gebruiken.

Servers met een hogere doorvoer, zoals vLLM, gebruiken batching en KV-cachebewuste planning om accelerators bezig te houden met meerdere binnenkomende reeksen.

Waarom de contextlengte meer geheugen kan gebruiken dan een andere gebruiker suggereert

Stel dat de modelgewichten gemakkelijk in het VRAM passen. Vier gebruikers openen elk een zeer lang gesprek. De gewichten worden niet verviervoudigd, maar de KV-cache kan voor elke actieve reeks aanzienlijk groeien.

VRAM-budget
  |
  +-- modelgewichten      vast
  +-- KV-cache gebruiker A    groeit mee met context
  +-- KV-cache gebruiker B    groeit mee met context
  +-- KV-cache gebruiker C    groeit mee met context
  +-- runtime-overhead

Daarom is ‘het model past’ geen toereikende capaciteitsplanning. Systemen voor meerdere gebruikers moeten een maximale contextlengte, een maximaal aantal gelijktijdige reeksen en een begrensde wachtrij instellen.

De bestaande gids van ZimaSpace over acceleratorscheduling voor multi-user thuis-AI gaat dieper in op dezelfde resourcegrens.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Moet elke gebruiker een toegewezen modelproces krijgen?

Meestal niet. Afzonderlijke processen dupliceren gewichten en verminderen het aantal modellen dat in het geheugen past. Ze kunnen toch zinvol zijn wanneer:

gebruikers verschillende fine-tunes of kwantiseringen nodig hebben;
sterke procesisolatie belangrijker is dan efficiëntie;
één workload een aangepaste runtime gebruikt;
je een harde GPU-toewijzing per gebruiker wilt;
één model incompatibele context- of samplingvereisten heeft.

Voor een gezin of klein team dat hetzelfde model gebruikt, is één inferentieservice achter een geauthenticeerde applicatie doorgaans eenvoudiger.

Houd gespreksgeheugen buiten de modelserver

De inferentieserver mag niet de gezaghebbende database zijn voor ‘wie wat heeft gezegd’. Sla chatgeschiedenis en gebruikersvoorkeuren op in de applicatielaag onder een expliciete gebruikers-/sessie-ID.

Browser / app
    |
    | geauthenticeerde user_id
    v
Chatapplicatie
    |
    +-- geschiedenisdatabase (per gebruiker)
    +-- RAG-machtigingen
    |
    v
Gedeelde modelserver

Voor elke generatie stelt de applicatie alleen de geschiedenis en privé-retrievalcontext samen die de huidige gebruiker mag zien.

Dit is vooral belangrijk voor een privé-AI-assistent op een NAS, waarop dezelfde server persoonlijke documenten van meerdere gezinsleden kan bevatten.

Gedeelde caching van voorvoegsels is geen gedeeld gespreksgeheugen

Sommige runtimes kunnen de KV-cache of ander werk voor gemeenschappelijke promptvoorvoegsels hergebruiken. Een gedeelde systeeminstructie of herhaald documentvoorvoegsel kan daardoor één keer worden verwerkt en efficiënt worden hergebruikt.

Deze optimalisatie mag niet worden verward met het toestaan dat de privécontext van één gebruiker in de prompt van een andere gebruiker terechtkomt. Cachesystemen hebben correcte isolatie- en hashsemantiek nodig; de applicatierechten bepalen nog steeds welke inhoud aan een verzoek mag worden meegegeven.

Gebruik eerlijke planning zodat één gebruiker de server niet kan bezetten

Eén verzoek om een zeer lange uitvoer kan decodeercapaciteit verbruiken terwijl andere gebruikers wachten. Voeg toelatingscontroles toe, zoals:

limiet voor gelijktijdige verzoeken per gebruiker;
maximaal aantal uitvoertokens;
maximale contextvenster;
globaal maximumaantal actieve reeksen;
wachtrijtime-out;
prioriteit voor korte interactieve verzoeken;
afzonderlijke batchwachtrij voor achtergrondtaken.

Interactieve chats en nachtelijke documentsamenvattingen mogen niet onder identiek planningsbeleid met elkaar concurreren.

Wat gebeurt er wanneer de server geen geheugen meer heeft?

Een goede service weigert of plaatst nieuw werk in de wachtrij voordat de accelerator crasht. Capaciteitsregelingen moeten de werkelijk geconfigureerde context gebruiken, niet alleen een optimistisch gemiddelde.

Belasting	Veiliger antwoord
Alle reeksslots bezet	Plaats het kort in de wachtrij
Wachtrij te lang	Geef een signaal dat de server bezet is of dat opnieuw moet worden geprobeerd
Context overschrijdt beleid	Vat samen of wijs af
Achtergrondbatch actief	Pauzeer het of geef het een lagere prioriteit
Geheugen bijna vol	Verlaag de gelijktijdigheid vóór een OOM-fout

Verklein niet stilzwijgend het contextvenster van elke gebruiker totdat de server niet meer crasht. Maak het contextbeleid zichtbaar, zodat gebruikers weten wat het systeem kan bewaren.

Privacy en authenticatie zijn belangrijker in de modus voor meerdere gebruikers

Wanneer één model één beheerder bedient, kan een endpoint dat alleen via localhost bereikbaar is voldoende zijn. Zodra meerdere mensen het gebruiken, moet de applicatie gebruikers authenticeren en hun toegang tot gegevensbronnen autoriseren.

Bescherm:

chatgeschiedenissen;
RAG-collecties en document-ACL's;
opgeslagen prompts;
inloggegevens voor tools;
gegenereerde bestanden;
logboeken en traces.

Een gedeeld modelproces mag alleen de context voor het huidige verzoek zien en mag geen gemakkelijke omweg worden rond het normale machtigingsmodel van de NAS.

Hoeveel gebruikers kan één AI-thuisserver ondersteunen?

Er is geen vast, bruikbaar aantal. Een server kan veel geregistreerde gebruikers ondersteunen als er slechts één of twee actief zijn, terwijl twee gelijktijdige gebruikers met een lange context een kleine GPU kunnen uitputten.

Benchmark drie scenario's:

één interactieve gebruiker;
de verwachte gelijktijdige belasting in het huishouden;
één zware gebruiker plus meerdere korte verzoeken.

Meet de tijd tot het eerste token, het aantal tokens per seconde per gebruiker, de wachttijd, het gebruik van de KV-cache, het RAM-/VRAM-gebruik en het percentage mislukte verzoeken.

Veelgestelde vragen

Krijgen gebruikers elkaars gesprekken te zien omdat het model gedeeld wordt?

Niet als de applicatie gespreksgeschiedenis en ophaalcontext gescheiden houdt. Het delen van modelgewichten betekent niet automatisch dat de chatgeschiedenis wordt gedeeld.

Maakt parallelle inferentie elke gebruiker sneller?

Dit kan de totale doorvoer verhogen, maar elk afzonderlijk verzoek krijgt mogelijk minder rekenkracht wanneer meerdere reeksen actief zijn. Het doel is doorgaans een betere totale dienstverlening en een kortere wachttijd.

Kan één server ook meerdere modellen hosten?

Ja, als het geheugen dit toelaat. Sommige runtimes laden modellen naar behoefte en verwijderen ze weer, terwijl andere zijn ontworpen rond één of meerdere permanente serveerprocessen. Planning van meerdere modellen voegt een extra capaciteitslaag toe boven op planning voor meerdere gebruikers.

Eindoordeel

Eén geladen model is precies de resource die een kleine AI-thuisservice doorgaans moet delen. Houd modelgewichten gemeenschappelijk, isoleer sessiegeschiedenis en de KV-status, verifieer elke gebruiker, begrens context en gelijktijdigheid en plan achtergrondtaken afzonderlijk van interactieve chats. AI voor meerdere gebruikers wordt betrouwbaar wanneer je plant voor status per sessie en wachtrijgedrag, in plaats van het modelproces te vermenigvuldigen.