Welke AI-modellen kunt u zelf hosten op uw server?

Wat bepaalt welke AI-modellen u zelf kunt hosten

Welke AI-modellen u zelf kunt hosten, wordt bepaald door één getal: het RAM-geheugen van de server. De model-familie en het framework zijn veel minder belangrijk dan de vraag of de gewichten in het geheugen passen, met nog wat extra ruimte over. Dit artikel bevat de berekening om dit te bepalen. Het installeren van een runtime is een aparte taak, die wordt behandeld in de handleiding voor het draaien van Ollama op een VPS.

Twee kostenposten bepalen het antwoord. De gewichten zijn de vaste kosten, bepaald door het aantal parameters en de kwantisatie. Het contextvenster is de variabele kost, en dit is het punt dat mensen vergeten, totdat een model dat gisteren nog laadde, vandaag weigert te starten.

De rekenmethode voor grootte: bits per parameter

Een modelbestand bestaat vrijwel volledig uit gewichten. Elk gewicht wordt opgeslagen met een bepaald aantal bits. Kwantisatie betekent dat deze worden opgeslagen met minder bits dan de precisie waarmee ze zijn getraind. Dit kost een kleine hoeveelheid nauwkeurigheid, maar bespaart aanzienlijk op het geheugengebruik. De grootte volgt direct uit deze berekening:

weights in GB = (parameters in billions x bits per weight) / 8

Modellen worden uitgebracht op 16 bits, wat neerkomt op 2 GB per miljard parameters. Daarom draait vrijwel niemand de originele precisie op een VPS. Dit zijn de kwantisaties die u in de praktijk zult tegenkomen, met hun werkelijke gemiddelde aantal bits per gewicht:

• Q8_0 slaat ongeveer 8,5 bits per gewicht op, dus ruwweg 1,1 GB per miljard parameters.
• Q6_K slaat ongeveer 6,6 bits op, dus ruwweg 0,83 GB per miljard.
• Q5_K_M slaat ongeveer 5,7 bits op, dus ruwweg 0,71 GB per miljard.
• Q4_K_M slaat ongeveer 4,8 bits op, dus ruwweg 0,6 GB per miljard.

Gebruik 0,6 GB per miljard parameters als uw richtgetal. Q4_K_M is de verstandige standaardkeuze op een systeem met beperkt geheugen: het kwaliteitsverlies ten opzichte van 8 bits is bij de meeste taken klein, terwijl het bestand bijna de helft kleiner is. Onder de 4 bits neemt het verlies snel toe; een 70B-model dat is teruggebracht naar 2 bits presteert doorgaans slechter dan een 32B-model op 4 bits uit dezelfde generatie. Wanneer het geheugen krap is, verlaag dan liever de modelgrootte voordat u onder de 4 bits zakt.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

De bovenstaande gewichtskolom is gebaseerd op de regel van 0,6 GB per miljard. Echte GGUF-bestanden wijken hier slechts enkele procenten van af, omdat de embedding- en output-lagen op een hogere precisie worden gehouden dan de rest. Een 3B-model op 4 bits is ongeveer 1.8 GB. Een 8B-model is 4.8 GB. Een 32B-model is 19.2 GB en een 70B-model is 42 GB.

Waarom contextlengte meer RAM verbruikt dan de gewichten

De KV-cache (key-value cache, de attention-status die het model bijhoudt voor elk token in het huidige gesprek) vormt de tweede kostenpost. Deze wordt toegewezen bij het laden van het model, is gedimensioneerd op de door u gevraagde contextlengte en groeit lineair mee met die lengte.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Bij de standaardcontext van Ollama verbruikt dat 8B-model een halve gigabyte aan cache. Bij 8192 tokens verbruikt het 1 GB. Bij de 128k-context die op de modelkaart wordt geadverteerd, verbruikt het 16 GB, wat meer is dan drie keer het gewicht van het model zelf. Het 70B-model is het tegenovergestelde: de cache bij 128k is 40 GB, minder dan de eigen gewichten, omdat grouped query attention ervoor zorgt dat de kosten per token niet zo snel groeien als het aantal parameters.

De standaardcontextlengte van Ollama is 4096 tokens op een server die alleen op CPU draait. Wanneer er een GPU aanwezig is, kiest het systeem de standaardwaarde op basis van het VRAM: 32k tussen 24 en 48 GiB, en 256k bij 48 GiB en meer. Verhoog dit met de variabele OLLAMA_CONTEXT_LENGTH op de server en controleer vervolgens wat een draaiend model daadwerkelijk heeft gekregen in de kolom CONTEXT van ollama ps. De geheugenberekening achter die ene instelling wordt uitgewerkt in het artikel over num_ctx en contextlengte.

Er zijn twee manieren om het cachegebruik te verlagen. Vraag de context aan die u nodig heeft in plaats van de context die op de modelkaart wordt geadverteerd, aangezien het meeste chat- en programmeerwerk binnen 8k tot 32k past. Of kwantiseer de cache zelf naar 8 bits, wat het geheugengebruik halveert, ten koste van enige nauwkeurigheid bij lange contexten.

Een resident model houdt dat RAM vast totdat iets het ontlaadt

Ollama houdt een model 5 minuten na het laatste verzoek in het geheugen en ontlaadt het daarna. Die standaardinstelling is geschikt voor een laptop, maar onjuist voor een server, waar het eerste verzoek na elke periode van inactiviteit opnieuw de laadtijd vereist.

ollama ps
ollama stop qwen3:4b

ollama ps toont wat resident is, met een SIZE-kolom die aangeeft hoeveel geheugen het in beslag neemt en een UNTIL-kolom die toont wanneer het verloopt. Om een model permanent vast te pinnen, stelt u OLLAMA_KEEP_ALIVE=-1 in op de service. Een waarde van 0 ontlaadt het zodra elk antwoord is voltooid.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Verstuur één prompt en voer tien minuten later opnieuw ollama ps uit. Het model staat nog steeds in de lijst, wat precies de bedoeling is: het houdt dat RAM vast, ongeacht of iemand het gebruikt. Een vastgepind model is geen vrije capaciteit. Op een 16 GB VPS neemt een 8B-model met 8k context ongeveer 6 GB in beslag zolang de service draait. Stem de grootte van de server daarom af op het model plus uw applicatie, niet alleen op het model. Een model in het geheugen vastpinnen behandelt de afweging ten opzichte van de latentie bij een koude start.

Wat draait er op een 4 GB VPS

Reserveer ongeveer 1 GB voor het besturingssysteem en de modelserver; dit laat ongeveer 3 GB over. Dat is voldoende voor een 1B tot 4B model op 4 bits, bij de standaard context van 4096 tokens. Sinds augustus 2026 valt in die categorie onder andere Llama 3.2 op 3B, Qwen 3 op 1.7B en 4B, en de kleine Gemma- en Phi-releases. Beschouw dit als voorbeelden van grootte, niet als aanbevelingen. De namen veranderen elke paar maanden, maar de rekenkunde niet.

Verwacht ongeveer 6 tot 14 tokens per seconde. Modellen van dit formaat zijn geschikt voor specifiek werk: classificatie, extractie van tags, korte samenvattingen en het herschrijven van een alinea naar een specifieke huisstijl. Ze zijn minder sterk in redeneringen met meerdere stappen en in code die over meerdere bestanden verspreid is; geen enkele hoeveelheid prompting lost dat op.

Het faalscenario op dit niveau is swap. Als het model niet in het geheugen past, weigert Linux niet om het te laden. In plaats daarvan verplaatst het geheugen naar de schijf (paging). Omdat het genereren van een enkel token elke gewichtswaarde één keer leest, zakt de generatiesnelheid in naar seconden per token. Monitor free -h en de kolommen si en so van vmstat 1 terwijl het model antwoordt. Swap-in en swap-out waarden die niet nul zijn tijdens het genereren, betekenen dat het model te groot is voor het gekozen abonnement.

Wat draait er op een VPS met 8 tot 16 GB RAM

Dit is het punt waarop een zelfgehost model doorgaans nuttig wordt. Op 8 GB kunt u een 7B of 8B model draaien op 4 bits, wat neerkomt op ongeveer 4.8 GB aan gewichten, met een context van 8k. Op 16 GB kunt u een 13B of 14B model draaien op 4 bits, ongeveer 8.4 GB, of u kunt een 8B model op 8 bits draaien als u het geheugen liever besteedt aan precisie dan aan het aantal parameters.

Snelheid is het knelpunt. Een 8B model op een CPU genereert ongeveer 3 tot 7 tokens per seconde, en een 14B model ongeveer 1.5 tot 3.5. Een mens leest met een snelheid van ongeveer 5 tot 10 tokens per seconde, dus een 8B model op een CPU-gebaseerde VPS voelt aan als kijken naar een langzame typist. Dat is prima voor achtergrondtaken, maar vermoeiend voor interactieve chats. Gemeten runs van Qwen 3 op 8B en groter op een VPS laten zien hoe dit er in de praktijk uitziet.

Wat draait er op een 32 tot 64 GB VPS

Een 32B-model op 4 bits is ongeveer 19.2 GB, dus het past op een 32 GB-abonnement met een korte context en draait comfortabel op 48 GB of 64 GB. Een 70B-model op 4 bits is ongeveer 42 GB, dus dit vereist 64 GB voordat u überhaupt cache toevoegt.

Bekijk vervolgens de snelheid realistisch. Een 32B-model op de CPU draait op ongeveer 0.6 tot 1.5 tokens per seconde, en een 70B-model op 0.2 tot 0.5. Een antwoord van 500 tokens van dat 70B-model duurt ongeveer twintig minuten. Dit zijn batch-tools. Voer ze 's nachts een wachtrij met documenten en de snelheid is irrelevant. Plaats ze achter een chatvenster en de snelheid is cruciaal.

Mixture of Experts-routing verandert deze berekening, en dit is het enige architectuurdetail dat de moeite waard is om te leren. Een MoE-model stuurt elk token slechts door een klein deel van zijn gewichten. Een model met 30B totale parameters en 3B actieve parameters per token heeft het geheugen van een 30B-model nodig en genereert tekst met een snelheid die dicht bij die van een dense 3B-model ligt, omdat elk token alleen de actieve experts leest. Op een 32 GB-server is een MoE-model met die configuratie veel bruikbaarder dan een dense 30B-model. De regel om te onthouden: het totaal aantal parameters bepaalt het geheugengebruik, het aantal actieve parameters bepaalt de snelheid.

Hoe snel is CPU-inference in werkelijkheid?

Het genereren van één token vereist dat elk actief gewicht één keer uit het geheugen wordt gelezen. Dit is onvermijdelijk, waardoor de generatiesnelheid op een CPU wordt bepaald door de geheugenbandbreedte en niet door het aantal cores. Het maximum wordt bepaald door een deling: de bruikbare geheugenbandbreedte gedeeld door de grootte van de gewichten in bytes. Een kleine gedeelde VPS levert in de praktijk 10 tot 25 GB per seconde over de vCPU's, waardoor een model van 4,8 GB uitkomt op ongeveer 2 tot 5 tokens per seconde.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Dit zijn bereiken die vaak worden gerapporteerd op standaard VPS-hardware; het is geen benchmark van één specifieke machine. Uw cijfer hangt af van de geheugengeneratie, het aantal kanalen op de host en hoeveel buren erom strijden. Meet uw eigen snelheid met een model-tag die u al heeft:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

De samenvatting die na het antwoord wordt afgedrukt, eindigt met een regel die eval rate: ... tokens/s bevat. Dat is uw generatiesnelheid. Negeer de eerste run van een sessie, omdat load duration in dezelfde samenvatting het inlezen van de gewichten vanaf de schijf meerekent. Correct tokens per seconde meten beschrijft hoe u een waarde krijgt die de moeite waard is om te vergelijken.

Twee resultaten verrassen gebruikers hier vaak. Het toevoegen van vCPU's helpt al snel niet meer, omdat na ongeveer 8 cores de extra cores wachten op het geheugen in plaats van berekeningen uit te voeren. En op een gedeeld abonnement geeft hetzelfde commando van uur tot uur andere getallen terug; dit is CPU steal time door een luidruchtige buur en niet iets dat u verkeerd heeft geconfigureerd.

Het lezen van uw prompt is een andere taak dan het genereren van het antwoord. Promptverwerking is rekenintensief (compute bound), dus dit schaalt wel met het aantal cores, en dit is waar een GPU de grootste voorsprong pakt. Een lang document kost een CPU minuten om te lezen en een GPU seconden. Dat is de eerste barrière waar u tegenaan loopt bij het koppelen van een coding agent aan een model dat u zelf host, omdat bij elke beurt de bestandscontext en de tooldefinities opnieuw worden verzonden voordat er ook maar één token van het antwoord terugkomt.

Wat verandert er bij het toevoegen van een GPU

De berekening verandert niet, alleen de pool waarop deze van toepassing is. VRAM is een harde limiet, dus bepaal wat past voordat u huurt:

• 8 GB VRAM biedt ruimte voor een 7B of 8B model op 4 bits met een korte context.
• 16 GB biedt ruimte voor een 14B model op 4 bits met een reële context, of een 8B model op 8 bits.
• 24 GB biedt ruimte voor een 32B model op 4 bits met een beperkte context.
• 48 GB en meer biedt ruimte voor een 70B model op 4 bits met ruimte voor cache en gelijktijdigheid.

Wanneer een model niet past, splitst Ollama het: enkele lagen op de GPU, de rest op de CPU. ollama ps rapporteert de splitsing in de kolom PROCESSOR, bijvoorbeeld als 78%/22% CPU/GPU. Beschouw dit als een waarschuwing in plaats van een functie. De CPU-helft bepaalt het tempo, omdat elk token nog steeds moet wachten op die lagen. Een model waarvan een kwart van de lagen op de CPU draait, presteert daarom veel dichter bij de CPU-snelheid dan bij de GPU-snelheid. Als u een splitsing ziet die u niet had voorzien, verlaag dan eerst de contextlengte. De cache is meestal de oorzaak van de overschrijding.

Gelijktijdigheid is de andere reden om op te schalen. De gewichten worden gedeeld tussen gelijktijdige verzoeken, maar elk actief verzoek heeft zijn eigen KV-cache nodig. Tien gelijktijdige gebruikers van een 8B model met een 8k context hebben dus tien keer 1 GB aan cache nodig, bovenop de gewichten. Gelijktijdige gebruikers bedienen vanuit één zelfgehost model behandelt waar dat plafond ligt.

Of het huren van een GPU de moeite waard is, is eveneens een rekenkundige vraag. Het hangt af van hoeveel tokens u per maand daadwerkelijk genereert. Het omslagpunt tussen een GPU VPS en API-tokens bevat die cijfers.

Wat u niet zelf kunt hosten

Er zijn hier twee verschillende barrières, en het helpt om te weten tegen welke u aanloopt.

De eerste betreft gesloten gewichten. Commerciële topmodellen worden niet gedistribueerd, dus er is geen bestand om te downloaden en geen enkele hoeveelheid RAM-geheugen verandert dat. U kunt alles eromheen zelf hosten: de interface, de retrieval-laag, de agent-loop en de logs. Het model zelf blijft een externe API. Of u Claude zelf kunt hosten behandelt dit volledig.

De tweede betreft open gewichten die simpelweg te groot zijn. De grootste open releases zijn ontwerpen met 'mixture of experts' die in totaal honderden miljarden parameters bevatten. Dezelfde regel is op hen van toepassing: een model met 400B totale parameters op 4 bits heeft ongeveer 240 GB nodig voor alleen de gewichten, nog voor enige cache. Dat vereist gespecialiseerde hardware, en het maandelijks huren daarvan kost veel meer dan de meeste mensen in een jaar aan API-tokens uitgeven. Wat er nodig is om een model van de Kimi-klasse zelf te hosten loopt de werkelijke vereisten door.

De eerlijke grens tussen beide: host zelf wanneer de belasting constant is en de data uw server niet mag verlaten. Koop tokens wanneer de belasting grillig is, of wanneer de antwoordkwaliteit van topmodellen precies is wat u nodig heeft.

Controleer uw beschikbare middelen voordat u een keuze maakt

free -h
nproc
lscpu | grep 'Model name'

Baseer uw planning op de available-kolom van free -h, niet op de total-kolom, omdat total geheugen bevat dat het systeem al in gebruik heeft. Trek ongeveer 1 GB af voor het besturingssysteem en de modelserver. Deel het restant door 0,6 om het maximale aantal parameters in miljarden te bepalen dat u op 4 bits kunt laden. Trek vervolgens de KV-cache af voor de context die u daadwerkelijk wilt gebruiken. Wat overblijft is uw antwoord; in tegenstelling tot een lijst met modelnamen veroudert dit niet.

FAQ

Hoeveel RAM heb ik nodig om een 8B model te draaien?

Ongeveer 4.8 GB voor de gewichten bij 4-bit kwantisatie, plus de KV-cache voor uw contextlengte, plus ongeveer 1 GB voor het besturingssysteem en de modelserver. Bij een context van 8192 tokens voegt de cache ongeveer 1 GB toe, dus een 8 GB plan volstaat en een 4 GB plan niet. Als u de volledige 128k context wilt gebruiken die in de modelkaart wordt geadverteerd, is de cache alleen al 16 GB en heeft u een 32 GB plan nodig.

Waarom is mijn model traag, ook al heeft de VPS voldoende vCPU's?

Omdat generatie wordt beperkt door geheugenbandbreedte, niet door cores. Voor elk token moet de volledige actieve set gewichten uit het RAM worden opgehaald. Zodra een paar cores de geheugenkanalen verzadigen, wachten de overige cores simpelweg. De andere veelvoorkomende oorzaak is swap. Als vmstat 1 een niet-nul waarde toont voor si en so terwijl het model antwoordt, passen de gewichten niet in het RAM en wordt een deel van elk token vanaf de schijf gelezen. Dit kost veel meer tijd dan men op basis van de specificaties zou verwachten.

Heeft een groter contextvenster echt meer geheugen nodig?

Ja, en de groei is lineair ten opzichte van het aantal tokens. Een typisch 8B model verbruikt ongeveer 128 KiB aan KV-cache per token, dus 8192 tokens kosten 1 GB en 131072 tokens kosten 16 GB. De cache wordt toegewezen wanneer het model wordt geladen, niet wanneer het gesprek groeit. Een 128k context aanvragen reserveert dat geheugen dus direct, zelfs als elke prompt die u verstuurt slechts 200 tokens lang is.

Kan ik beter een groot model op 2 bits draaien of een kleiner model op 4 bits?

Kies het kleinere model op 4 bits. De kwaliteit neemt langzaam af van 8 bits naar 4 bits, maar daalt snel onder de 4 bits. Een 70B model dat is gecomprimeerd naar 2 bits geeft doorgaans slechtere antwoorden dan een 32B model op 4 bits uit dezelfde modelgeneratie. Zware kwantisatie uit zich in herhalingen en genegeerde instructies in plaats van in een foutmelding, waardoor het makkelijk is om de schuld aan uw prompt te geven. Beschouw 4 bits als de ondergrens en pas liever het aantal parameters aan.

Kan ik zelf een model hosten dat even capabel is als de grote commerciële modellen?

Niet op een standaard VPS. De krachtigste open-weight modellen bevatten honderden miljarden parameters. Bij 4 bits betekent dit meer dan 200 GB RAM nog voordat er enige KV-cache is toegewezen. De krachtigste commerciële modellen worden bovendien helemaal niet gedistribueerd. Wat standaard hardware wel goed kan, is een degelijk 8B tot 32B model draaien voor een specifieke taak, waarbij een nauwkeurig en goed geprompt klein model vaak niet onderdoet voor een algemeen model. Als u topkwaliteit nodig heeft, vergelijk dan de API-kosten met de hardwarekosten voordat u een keuze maakt.