Hoeveel VRAM heeft een lokale documentassistent nodig?

Een lokale documentassistent heeft geen speciale VRAM nodig wanneer de generatie op afstand of op een aparte inferentieserver plaatsvindt. Voor inferentie op dezelfde machine is 8 GB een praktisch startpunt voor kleine gekwantiseerde modellen, terwijl grotere modellen, langere context en gelijktijdige verzoeken de vereiste capaciteit ruim boven 16–24 GB kunnen brengen. Bepaal het exacte model en de werkcontext voordat je koopt, omdat de RAG-toepassing zelf niet bepaalt hoeveel VRAM vereist is.

Bepaal of de assistent daadwerkelijk een lokale GPU nodig heeft

Een documentassistent heeft minstens twee lagen: de toepassing die bestanden opslaat, tekst in stukken verdeelt, passages doorzoekt of ophaalt en antwoorden presenteert; en de modelbackend die de generatie uitvoert. Die lagen hoeven niet op dezelfde hardware te draaien. Een compacte server kan de privé-documentbibliotheek en retrievalstack hosten, terwijl modelverzoeken naar een andere lokale GPU-machine of een externe provider worden gestuurd.

De zelfgehoste documentatie van AnythingLLM maakt deze scheiding expliciet door de toepassing verbinding te laten maken met model- en embeddingservices elders. De vereisten voor zelfhosting liggen daardoor veel lager dan de hardware die nodig is voor een LLM op dezelfde machine.

Als de vereiste is dat “documenten op mijn server blijven” in plaats van dat “elke modeltoken op deze server moet worden gegenereerd”, kan nul speciale VRAM een geldige aankoopkeuze zijn. Controleer wel welke tekst de machine verlaat, waar embeddings worden gegenereerd, hoe het externe model verzoeken verwerkt en of de privacygrens bij de toepassing past.

De eerste aankoopbeslissing is architectonisch: bij externe of aparte inferentie stem je CPU, RAM en opslag af op retrieval; bij inferentie op dezelfde machine wordt VRAM een belangrijke beperking bij de modelkeuze.

Bepaal de modelgewichten voordat je RAG-overhead toevoegt

VRAM-planning begint met het exacte model en de precisie. Gewichten met volledige precisie zijn veel groter dan 8-bits- of 4-bitsvarianten. Daarom kunnen twee gebruikers die zeggen “ik draai een 7B-model” sterk verschillende geheugenvereisten hebben. Kwantisatie kan ervoor zorgen dat een bruikbaar kleiner model op gangbare hardware past, maar kan ook het uitvoergedrag veranderen en moet daarom met de documenttaak worden geëvalueerd.

Hugging Face documenteert dat kwantisatie geheugen- en rekenkosten verlaagt door gewichten en activaties met gegevenstypen met een lagere precisie weer te geven, en ondersteunt gangbare 8-bits- en 4-bitspaden. Daardoor is precisie een variabele bij de aankoop, niet slechts een software-instelling die je toepast nadat de hardware is gekozen.

Als grove actuele planningsregel passen 4-bitsmodellen in de klasse van 7–8B vaak binnen 6–8 GB, gaan modellen in de klasse van 13–14B meestal richting ongeveer 10–12 GB en hebben modellen in de klasse van 27–32B vaak ongeveer 20 GB nodig, nog vóór extra ruimte voor context. De VRAM-planningsgids van Spheron voor 2026 geeft vergelijkbare INT4-cijfers en voegt expliciet runtime-overhead toe boven op de schatting voor de gewichten.

Koop niet precies op basis van de bestandsgrootte van het gedownloade model. Laat ruimte over voor de runtime en de contextstatus en controleer het werkelijke model vervolgens in de beoogde inferentie-engine. Een model dat met een kleine testprompt wordt geladen, kan alsnog mislukken of offloaden wanneer de assistent een lange opgehaalde context ontvangt.

De contextlengte kan de VRAM-tier veranderen nadat het model past

Een documentassistent heeft vaak meer context nodig dan een gewone chatbot, omdat opgehaalde passages, citaten, syste instructies, gespreksgeschiedenis en gebruikersvragen in één verzoek worden samengevoegd. De modelgewichten blijven mogelijk gelijk, terwijl de key-value-cache en andere verzoekstatus meegroeien met de contextlengte.

De actuele contextdocumentatie van Ollama maakt deze afweging zichtbaar: de standaardcontextlengte neemt toe met de beschikbare VRAM, van 4K onder 24 GiB tot 32K bij 24–48 GiB en veel hoger bij 48 GiB of meer. De exacte standaardwaarden zijn runtimekeuzes, maar de les voor de aankoop is dat lange documentcontext geheugen verbruikt boven op de modelgewichten.

Reageer hier niet op door de context zonder onderscheid maximaal te maken. Retrieval moet de kleinste set passages selecteren die de vraag beantwoordt, en chunking of reranking moet irrelevante tekst vóór de generatie verwijderen. Een documentassistent die elk document in één prompt moet plaatsen, gebruikt VRAM als compensatie voor een zwak retrievalontwerp.

Ga naar de volgende VRAM-tier wanneer het geteste model nauwkeurig genoeg is, maar echte documentprompts leiden tot offloading, out-of-memory-fouten of onaanvaardbare latentie bij de contextlengte die je daadwerkelijk nodig hebt. Als de retrievalkwaliteit al slecht is voordat de context het model bereikt, verbeter dan eerst de index en rangschikking.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Reserveer afzonderlijk capaciteit voor embeddings, reranking, OCR en gelijktijdige verzoeken

De lokale LLM is niet het enige onderdeel dat GPU-geheugen kan gebruiken. Sommige documentassistenten versnellen ook embeddings, rerankers, OCR, spraaktranscriptie of visiemodellen op dezelfde GPU. Wanneer deze modellen gelijktijdig draaien, kan de voor de generator beschikbare VRAM afnemen, ook al past elk onderdeel afzonderlijk tijdens tests.

Het ZimaSpace-artikel over de volledige geheugenvoetafdruk van modellen legt uit waarom runtimebuffers en verzoekstatus naast de checkpointgrootte moeten worden meegenomen. Bij een documentassistent voegen opgehaalde context en parallelle services nog een extra laag gedeelde geheugendruk toe.

Gelijktijdigheid verandert het antwoord eveneens. Twee actieve gebruikers kunnen afzonderlijke KV-cache-status nodig hebben, ook wanneer ze één geladen model delen. Een batchgerichte server kan het gebruik van de accelerator verbeteren, maar laat het geheugen per verzoek niet verdwijnen. Meet de langste normale documentquery bij het verwachte aantal gelijktijdige gebruikers.

Als de generator de enige GPU-belasting vormt, kun je dichter bij de geteste werkset dimensioneren. Als OCR, embeddings, reranking en generatie elkaar moeten overlappen, koop dan meer VRAM, voer zware stappen na elkaar uit of verdeel services over CPU- en GPU-resources. De goedkoopste keuze is de keuze die de vereiste latentie behoudt zonder te betalen voor ongebruikte versnelling.

Gebruik VRAM-tiers om modellen te selecteren en test daarna de kwaliteit

Een nuttige shortlist kan worden geordend op wat de documentassistent moet uitvoeren, in plaats van op het grootste model dat past. Begin bij ongeveer 6–8 GB VRAM met kleine 4-bitsmodellen in de klasse van 7–8B en begrensde retrieval. Bij ongeveer 12–16 GB krijg je ruimte voor grotere modellen, een hogere precisie of meer context. Bij ongeveer 24 GB worden veel gekwantiseerde modellen in de klasse van 27–32B praktisch, met meer werkruimte. Vanaf ongeveer 40–48 GB wordt de klasse waarin 4-bitsmodellen op schaal van 70B realistisch worden zonder zware offloading.

De lokale-LLM-gids van SitePoint voor 2026 vermeldt dat een 7B Q4_K_M-model comfortabel past in ongeveer 6 GB VRAM. Andere actuele planningsgidsen plaatsen gekwantiseerde modellen van 14B en 32B hoger. Dat bevestigt de regel dat de tier wordt bepaald door het exacte checkpoint, niet door een algemeen label als “AI-pc”.

Stel vóór de aankoop een evaluatieset samen op basis van je eigen documenten. Neem vragen op die exacte extractie, synthese van meerdere passages, weigering wanneer de bron ontbreekt, tabellen of gestructureerde tekst indien relevant en de langste verwachte context vereisen. Vergelijk antwoordkwaliteit, citeergedrag, latentie tot het eerste token, generatiesnelheid en piekgebruik van VRAM.

Koop meer VRAM wanneer het kleinere model tekortschiet omdat modelcapaciteit of contextcapaciteit daadwerkelijk onvoldoende is. Upgrade niet alleen omdat er een groter checkpoint bestaat. Retrieval kan een kleiner, sneller model nuttiger maken voor een afgebakende privékennisbank dan een trager model met zwakke bronverankering.

Houd de opslag- en retrievalhost los van de VRAM-beslissing

Een documentassistent heeft ook permanente opslag nodig voor originele bestanden, geëxtraheerde tekst, indexen, toepassingsdatabases, logboeken en back-ups. Deze middelen gebruiken doorgaans systeem-RAM en schijfcapaciteit in plaats van GPU-VRAM. Door alle resources samen te voegen tot één getal voor “AI-geheugen” ontstaan slechte hardwarebeslissingen.

Het ZimaSpace-overzicht van een privé-AI-assistent op een NAS beschrijft de retrieval-firstrol van lokale bestanden. Dankzij die architectuur kan het opslagsysteem stabiel blijven, ook wanneer de inferentiehardware later verandert.

ZimaBoard 2 1664 is geschikt wanneer de compacte server verantwoordelijk is voor documentopslag, indexering, toepassingen en orkestratie, terwijl de LLM op afstand of op een aparte GPU-machine draait. De geïntegreerde Intel-graphics mogen niet worden beschouwd als speciale LLM-VRAM.

Kies de opslaghost op basis van documentvolume, back-ups, toepassingsgeheugen en netwerkbehoeften. Kies de accelerator op basis van het exacte model, de kwantisatie, context en gelijktijdigheid. Door deze beslissingen gescheiden te houden, kun je de GPU upgraden zonder de gezaghebbende documentopslag opnieuw op te bouwen.

Controleer elke GPU-configuratie in één behuizing vóór aankoop

Als je opslag, retrieval en lokale generatie in één behuizing wilt combineren, is de laatste aankoopcontrole de exacte hoeveelheid GPU-geheugen die voor de runtime beschikbaar is. Productnamen zoals “AI”, “Creator” of “RTX” geven niet aan of het gekozen lokale model past. VRAM, driverondersteuning, containertoegang, voeding, koeling en fysieke uitbreidingsmogelijkheden moeten allemaal worden gecontroleerd.

Het actuele ZimaCube 2 Creator Pack is de Zima-optie die je moet bekijken wanneer je meerbaysopslag en een speciale NVIDIA-GPU in hetzelfde systeem wilt. De actuele productpagina vermeldt de GPU-familie, maar publiceert geen VRAM-capaciteit in de belangrijkste specificatietekst. Koppel het systeem daarom niet aan de tier van 8 GB, 16 GB, 24 GB of 48 GB voordat de exacte geïnstalleerde GPU-geheugencapaciteit is bevestigd.

Voer vóór het afrekenen waar mogelijk een representatieve modeltest uit of vraag daar om. Noteer het piekgebruik van VRAM met de normale kwantisatie en context en herhaal de test terwijl de embeddings, reranker, OCR of andere GPU-services van de assistent actief zijn. Controleer of de runtime daadwerkelijk de beoogde GPU gebruikt en niet stilzwijgend lagen naar het systeemgeheugen offloadt.

De eindregel is: koop VRAM voor de gevalideerde werkset, niet voor de marketingcategorie. Gebruik nul speciale VRAM wanneer inferentie elders kan plaatsvinden; begin rond 6–8 GB voor kleine lokale gekwantiseerde modellen; ga richting 12–16 GB voor grotere modellen of meer speelruimte; en overweeg pas 24 GB of meer wanneer de geteste documentworkflow aantoont dat modelgrootte, context of gelijktijdigheid dit vereist.

Veelgestelde vragen

Vermindert RAG de hoeveelheid VRAM die ik nodig heb?

RAG kan ervoor zorgen dat een kleiner model antwoorden geeft op basis van opgehaald bewijsmateriaal in plaats van te vertrouwen op de interne kennis van een groter model. Daardoor kan de vereiste modeltier lager uitvallen. Opgehaalde passages gebruiken echter nog steeds contextgeheugen. Slechte retrieval die te veel tekst doorstuurt, kan de VRAM-druk dus verhogen.

Hebben embeddings evenveel VRAM nodig als het chatmodel?

Nee. Embeddingmodellen hebben hun eigen CPU-, RAM- of GPU-voetafdruk en kunnen op de CPU of als afzonderlijke service draaien. Als embeddings en generatie dezelfde GPU gebruiken, meet dan hun gecombineerde piekgebruik in plaats van de bestandsgroottes van de modellen op papier bij elkaar op te tellen.