Een AI-server voor thuis routeert modellen op basis van hun geheugengebruik door elk verzoek te koppelen aan een model waarvan de volledige werkset binnen de beschikbare geheugencapaciteit van het apparaat past.
Een lokale router kan kiezen uit kleine en grote taalmodellen, embeddingmodellen, vision-encoders, spraaksystemen en uitvoerpaden via de CPU of GPU. Het checkpointbestand is slechts het uitgangspunt. De daadwerkelijke toelating hangt ook af van quantisatiemetagegevens, runtimecontext, de KV-cache, promptlengte, gelijktijdigheid, vision-tokens, tijdelijke werkruimten en geheugen dat al door andere services is gereserveerd. Een bruikbare router brengt die kosten vóór uitvoering in kaart en kiest een model, precisie, contextlimiet en hardwarepad die gedurende het volledige verzoek stabiel kunnen blijven.
De grootte van het checkpoint is slechts het vaste deel van het geheugengebruik
Gewichten en quantisatiemetagegevens vormen een voorspelbare vaste basis in het geheugen. De runtime voegt daar bibliotheken, allocatorpools, uitvoeringsgrafieken, invoerbuffers, activaties en verzoekstatus aan toe.
De hardwaregids van ZimaSpace beschouwt volledig AI-geheugengebruik als meer dan alleen de grootte van het modelbestand.
Een router die alleen de bestandsgrootte gebruikt, kan een model toelaten dat probleemloos wordt geladen, maar tijdens een lange prefill, multimodaal verzoek of gelijktijdige chat mislukt.
Elk model heeft een empirisch geheugenprofiel nodig
Leg voor elk model en elke quantisatie het inactieve geheugengebruik, het piekgeheugen tijdens prefill, het aantal bytes per contexttoken, de KV-precisie, batchlimieten, de kosten van visuele tokens en de runtime-reserve vast.
Een multi-modelplanningsonderzoek uit 2026 beschrijft het geheugengedrag van modellen voor verschillende architecturen en heterogene hardware, in plaats van ervan uit te gaan dat één plaatsingsformule voor elk model werkt.
Profielen moeten zowel koude als warme toestanden bevatten, omdat compilatiecaches en hoogste allocator-geheugenniveaus het beschikbare geheugen na eerdere verzoeken kunnen veranderen.
Stel het profiel opnieuw op nadat je de runtime, driver, contextinstelling, quantisatie of het modelformaat hebt gewijzigd.
De router moet vóór toelating dynamische geheugencapaciteit reserveren
Het verzoek levert aanvullende informatie: promptlengte, verwachte uitvoerlengte, het aantal en de resolutie van afbeeldingen, de gewenste batchgrootte en de huidige gelijktijdigheid van gebruikers.
De globale geheugenscheduler van Prism past modelactivatie en verwijdering aan op basis van werklast- en wachtrijgegevens, in plaats van vaste reserveringen te gebruiken.
Een thuisrouter kan een eenvoudigere toelatingsformule gebruiken: het vrije apparaatgeheugen min een veiligheidsmarge moet groter zijn dan de modelbasis plus de geschatte verzoekstatus en werkruimte.
Als de schatting niet past, kan de router de context inkorten, de batchgrootte verlagen, een kleiner model kiezen, een lagere cacheprecisie gebruiken, het verzoek in de wachtrij plaatsen of naar een ander apparaat routeren.
Volledige GPU-passing, gedeeltelijke offloading en CPU-uitvoering zijn verschillende routes
Een model dat volledig in het VRAM past, vermijdt doorgaans herhaalde overdrachten van gewichten tussen host en apparaat. Een groter model kan via gedeeltelijke CPU-offloading of unified memory worden uitgevoerd, maar heeft dan andere latentie- en bandbreedtebeperkingen.
ATSInfer gebruikt plaatsing op tensorniveau om opslag, overdracht en berekening over het geheugen van consumenten-CPU's en -GPU's te coördineren.
De router moet onderscheid maken tussen “kan worden uitgevoerd” en “voldoet aan de deadline van de workflow”. Een gedeeltelijk ge-offload model kan geschikt zijn voor een nachtelijke analyse, maar ongeschikt voor spraakinteractie.
Populariteit en herlaadkosten bepalen welke modellen resident blijven
Modellen waar vaak om wordt gevraagd kunnen warm blijven, terwijl grote, zelden gebruikte modellen op de opslag blijven totdat een taak de laadkosten rechtvaardigt.
Weaver analyseert veelgevraagde en weiniggevraagde modellen in systemen die veel eindpunten met ongelijke populariteit bedienen.
Een verzoek kan naar een iets kleiner warm model worden gerouteerd wanneer dat aan de kwaliteitseisen voldoet en een lange cyclus van verwijderen en opnieuw laden voorkomt. Een moeilijke taak kan het laden van het grotere model rechtvaardigen wanneer de verwachte kwaliteitswinst groter is dan de vertraging.
Taakvereisten moeten beslissingen op basis van alleen geheugen beperken
De kleinste geheugenvoetafdruk is niet altijd de juiste route. Voor programmeren, meertalige tekst, complexe redeneringen, OCR en toolplanning kunnen mogelijkheden nodig zijn die in een kleiner model ontbreken.
MuxServe combineert plaatsing en planning, omdat efficiënte bediening zowel afhangt van de vraag naar modellen als van hun gedrag ten opzichte van resources.
Bepaal eerst een minimumniveau voor de vereiste mogelijkheden en kies vervolgens het model met de kleinste geheugenvoetafdruk dat voldoet aan de kwaliteits-, veiligheids-, latentie- en formaattests van de workflow.
Een deterministische extractietaak kan naar een klein resident model worden gerouteerd, terwijl een moeilijk planningsverzoek naar een groter model wordt gestuurd of op capaciteit wacht.
Routing moet zich aanpassen aan live geheugen en recente uitvoeringsgeschiedenis
Statische profielen kunnen niet elke allocator-reservering, gefragmenteerde geheugenregio, concurrerende container of thermische vertraging vastleggen. De router heeft ook het actuele vrije geheugen, de wachtrijdiepte, resident modellen en recente fouten nodig.
Onderzoek naar agentische CPU-GPU-planning combineert geheugenvoetafdrukken, koude opstartkosten, uitvoeringsgeschiedenis en hardwaregegevens bij het toewijzen van heterogeen AI-werk.
Log de gekozen route, het voorspelde geheugengebruik, de werkelijke piek, de laadtijd, de latentie tot het eerste token, de uitvoersnelheid en eventuele fallback. Werk het modelprofiel bij wanneer de voorspellingsfout een vastgestelde marge overschrijdt.
Geheugenbewuste routing is geslaagd wanneer verzoeken binnen een stabiele capaciteit blijven en de server toch het krachtigste model kiest dat aan de servicenorm van de huidige taak kan voldoen.
Veelgestelde vragen
Kan een router de grootte van het modelbestand als snelle schatting gebruiken?
Dat is een nuttige basis, maar de router heeft nog steeds runtime-overhead, KV-cache, prompt, batchgrootte en een veiligheidsmarge nodig voordat het verzoek wordt toegelaten.
Moet een model altijd naar de CPU worden gerouteerd wanneer het VRAM vol is?
Alleen wanneer CPU- of hybride uitvoering aan de latentie- en geheugenvereisten van de taak voldoet. Een verzoek in de wachtrij plaatsen of een kleiner model kiezen kan beter zijn.
Is voor geheugenbewuste routing een GPU-cluster nodig?
Nee. De router kan kiezen uit één GPU, CPU-uitvoering, gedeeltelijke offloading, verschillende quantisaties en meerdere modelgroottes op één thuisserver.
Tech & AI HUB
Meer om te lezen

Welke functies maken een vertrouwensgrens voor thuis-AI rond gevoelige bestanden mogelijk?
Een vertrouwensgrens voor thuis-AI combineert versleuteling van gegevens in rust, rechten volgens het principe van minimale bevoegdheden, sandboxing tijdens runtime en retrieval met beperkte...

Waardoor krijgen vaak bewerkte bestanden voorrang in privézoekresultaten?
Vaak bewerkte bestanden krijgen een hogere ranking wanneer elke update versheid, chunks, versies of interactiesignalen toevoegt zonder te normaliseren op basis van de bron.

Waardoor verwarren slimme-aanwezigheidsmodellen gasten met bewoners?
Gasten kunnen op bewoners lijken wanneer het systeem activiteitspatronen in het huishouden waarneemt, maar geen stabiel identiteitssignaal heeft voor de persoon die deze veroorzaakt.

