Kan een lokale stemassistent in meerdere kamers werken met één inferentieserver?

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 Local Voice Assistant Work Across Multiple Rooms With One Inference Server?

Ja. Meerdere kamers kunnen één lokale server voor steminferentie delen. Elke kamer heeft een microfoon-/luidsprekersatelliet nodig, terwijl zwaardere spraak-naar-tekst, redenering door het taalmodel en tekst-naar-spraak centraal op een homeserver kunnen draaien. Het systeem schaalt het best wanneer wake-worddetectie of stemactiviteitsdetectie dicht bij de microfoon plaatsvindt, zodat inactieve kamers niet voortdurend audio naar de server streamen.

De belangrijkste beperking is niet het aantal kamers, maar hoeveel mensen tegelijkertijd spreken en hoeveel rekenkracht elke pijplijnfase nodig heeft. Zes grotendeels inactieve satellieten kunnen eenvoudiger zijn dan twee kamers die overlappende Whisper-, LLM- en TTS-taken genereren.

Hoe ziet een lokale spraakarchitectuur voor meerdere kamers eruit?

Keukensatelliet ----Slaapkamersatelliet -----Kantoorsatelliet -------> Lokale stemserver
Woonkamersatelliet --/      |
                              +-- STT
                              +-- intentie / LLM
                              +-- TTS
                              +-- Home Assistant / tools

De taak van de satelliet kan eenvoudig blijven: audio vastleggen, een wake word of spraak detecteren, het verzoek van de kameridentiteit voorzien, de ontvangen audio afspelen en optioneel lokale dempingsknoppen beheren.

De huidige Wyoming-integratie van Home Assistant is een goed voorbeeld van deze scheiding. Deze kan Assist verbinden met lokale systemen voor spraak-naar-tekst, tekst-naar-spraak en wake words, zoals Whisper, Piper, Speech-to-Phrase en openWakeWord.

Waarom lokale wake-worddetectie zo veel helpt

Als elke satelliet 24/7 audio naar de server streamt, blijft het netwerkverkeer op een bekabeld of goed functionerend wifilan meestal beheersbaar, maar de centrale machine moet voortdurend meerdere audiostreams controleren. Het zorgt ook voor een groter privacyrisico, omdat de achtergrondaudio uit elke kamer de centrale dienst bereikt.

Een beter ontwerp is:

Kamersatelliet
  |
  +-- lokaal wake word / VAD
  |
  +-- alleen na trigger
          |
          v
      spraakuiting streamen
          |
          v
   centrale inferentie

De documentatie over stemsatellieten van Home Assistant beschrijft modi voor altijd streamen, streamen bij spraak en een lokaal wake word. Er wordt ook vermeld dat kleine satellietapparaten lokaal wake-worddetectie en audio-opruiming kunnen uitvoeren, waardoor veel satellieten mogelijk zijn zonder dezelfde belasting op de centrale server te leggen.

Eén server betekent niet één gedeeld gesprek

Dit is de belangrijkste regel op applicatieniveau. Het inferentieproces kan worden gedeeld, maar elke kamer of gebruiker heeft een eigen sessiestatus nodig.

Centraal gedeeld	Per kamer/sessie gescheiden houden
Gewichten van het Whisper-model	Audiobuffer
Gewichten van het LLM-model	Gespreksgeschiedenis
Piper-stemmodel	Kameridentiteit
Toolkoppelingen	Gebruiker-/machtigingscontext
GPU of NPU	Bestemming van het antwoord

Zonder deze scheiding kan een vervolgvraag zoals “zet hem uit” per ongeluk context uit een andere kamer overnemen. De server moet aan elke uiting een sessie-ID koppelen en die doorgeven aan STT, intentieresolutie, tooluitvoering en TTS-weergave.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Kamercontext kan korte opdrachten verbeteren

Een systeem voor meerdere kamers beschikt over informatie die één slimme speaker niet heeft: het weet waar de microfoon zich bevindt.

In plaats van de gebruiker steeds “doe de lichten in de woonkamer uit” te laten zeggen, kan de satelliet een gebieds-ID meegeven:

uitgesproken: "doe de lichten uit"
kamer:   "keuken"

opgeloste actie:
Home Assistant -> keukenverlichting -> uit

Dit is vooral nuttig voor deterministische huisbediening, waarbij korte opdrachten helemaal geen dure algemene LLM hoeven te gebruiken. ZimaSpace's blik op de toenemende lokale verwerking door Home Assistant legt uit waarom gerichte lokale pijplijnen kunnen samengaan met grotere modellen voor meer open verzoeken.

Wat wordt het eerste knelpunt?

Spraak is een pijplijn, dus de langzaamste vereiste fase bepaalt de ervaren latentie.

Fase	Typische belasting van bronnen	Risico's bij meerdere kamers
Wekwoord / VAD	Kleine CPU op de satelliet	Laag bij distributie
Spraak-naar-tekst	CPU/GPU, geheugenbandbreedte	Hoog bij overlappende spraak
Intentie / LLM	GPU/CPU + KV-cache	Hoog voor open verzoeken
Tooluitvoering	Netwerk-/servicelatentie	Afhankelijk van het doel
Tekst-naar-spraak	CPU/GPU	Gemiddeld
Audioweergave	LAN	Meestal laag

Voor huishoudelijk gebruik komt gelijktijdig spreken vaak weinig voor. Daardoor kan de server korte pieken in een wachtrij plaatsen, in plaats van genoeg rekenkracht te reserveren voor elke kamer om voortdurend tegelijk te praten.

Kunnen STT, de LLM en TTS één GPU delen?

Dat kan, maar geheugen en planning zijn belangrijk. Het gelijktijdig laden van meerdere modellen kan meer VRAM verbruiken dan voor één fase nodig is. Een kleine server kan verschillende apparaten of uitvoeringsmodi gebruiken:

STT op de CPU of iGPU;
LLM op de GPU;
TTS op de CPU;
of korte STT/LLM/TTS-taken op één accelerator na elkaar uitvoeren.

Het tweede ontwerp bespaart hardware, maar kan de latentie verhogen wanneer twee kamers tegelijk praten. Meet de tijd tot het eerste transcript en de tijd tot de eerste audio, in plaats van alleen het ruwe aantal tokens per seconde.

Voorkom dat de speaker in de ene kamer een andere microfoon activeert

Spraak in meerdere kamers brengt een akoestisch probleem met zich mee: de eigen TTS van de assistent kan door een andere satelliet worden gehoord en als een nieuw verzoek worden geïnterpreteerd.

Gebruik:

lokale wekwoorden in plaats van alle geluiden openlijk te transcriberen;
echo-onderdrukking en ruisonderdrukking;
afspeelstatus, zodat een satelliet indien nodig zijn microfoon kan onderdrukken tijdens zijn eigen antwoord;
kamervolume;
korte formuleringen voor routinematige bediening.

Los feedbackproblemen niet oplossen door elke microfoon in huis te dempen zodra één speaker praat; daardoor wordt gelijktijdig gebruik van kamers onnodig kwetsbaar.

Hoe moet een homeserver de wachtrij dimensioneren?

Begin met realistische gelijktijdigheid. In een huishouden van vier personen met acht satellieten zullen er zelden meer dan twee gelijktijdige aanvragen zijn. Configureer een begrensde wachtrij in plaats van audiotaken onbeperkt te laten opstapelen.

spraakopdracht
   |
   +-- slot beschikbaar -> nu uitvoeren
   |
   +-- korte wachtrij -> "een momentje" / wachten
   |
   +-- wachtrij vol -> duidelijk mislukken

Prioritering kan ook helpen: deterministische opdrachten voor lichtbediening moeten niet wachten op een lang, conversatiegericht LLM-antwoord. Stuur snelle intenties voor huisbediening door een kleinere pipeline en reserveer het grote model voor vragen waarvoor het echt nodig is.

Privacy verbetert wanneer de server lokaal is, maar machtigingen blijven belangrijk

Centrale lokale inferentie houdt audio buiten een clouddienst, maar elke satelliet maakt nu verbinding met een geprivilegieerd systeem dat sloten, verlichting, media, alarmen en privégegevens kan beheren.

Koppel de context van de kamer en de gebruiker aan het machtigingsbeleid. Een satelliet in de logeerkamer kan bijvoorbeeld de verlichting en temperatuur bedienen zonder toegang te krijgen tot agenda's of privébestanden op de NAS. Een kinderkamer kan een volledig andere toolset hebben.

Voor de bredere orkestratielaag legt de handleiding over de vertrouwensgrens voor lokale AI-tools uit waarom spraakherkenning alleen geen beheerdersbevoegdheden mag verlenen.

Checklist voor spraakimplementatie in meerdere kamers

Geef elke satelliet een stabiele kamer-ID.
Voer waar praktisch het wake word of VAD uit op de satelliet.
Houd de gespreksstatus per kamer/sessie gescheiden.
Gebruik een snel, deterministisch pad voor routinematige opdrachten voor huisbediening.
Plaats dure STT-/LLM-taken in een wachtrij met een begrensde limiet voor gelijktijdigheid.
Meet de latentie bij gelijktijdig gebruik door meerdere gebruikers.
Schakel echo-onderdrukking en terugkoppelingspreventie in.
Geef elke kamer alleen de tools die daar nodig zijn.
Houd een lokale fallback aan voor essentiële opdrachten voor huisbediening.

Veelgestelde vragen

Heeft elke kamer een eigen AI-computer nodig?

Nee. Satellieten kunnen betaalbare microfoon-/luidsprekereindpunten zijn. De dure modellen kunnen één keer op een centrale server draaien.

Kunnen meerdere kamers tegelijkertijd met de server praten?

Ja, als de runtime voldoende capaciteit voor gelijktijdige aanvragen of een korte wachtrij heeft. Elke aanvraag heeft een eigen sessie- en audiostatus nodig, ook wanneer de modelgewichten gedeeld worden.

Moet wake-worddetectie centraal worden uitgevoerd?

Dat kan, maar lokale wake-worddetectie vermindert het voortdurend streamen van audio, de belasting van de centrale server en de blootstelling van privacygevoelige gegevens. Over het algemeen is dit de nettere opzet voor meerdere kamers wanneer de satelliethardware dit ondersteunt.

Eindoordeel

Eén lokale inferentieserver kan een heel huis met spraaksatellieten bedienen. Houd de eindpunten eenvoudig, verplaats de wake-worddetectie zoveel mogelijk naar de betreffende ruimte, centraliseer dure modellen en isoleer elke sessie. Dimensioneer op gelijktijdige uitingen in plaats van op het aantal luidsprekers, en stuur routineopdrachten via een snel lokaal pad zodat een lang LLM-gesprek in één kamer de rest van het huis niet traag laat aanvoelen.