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 modelfamilie en het framework zijn veel minder belangrijk dan de vraag of de gewichten in het geheugen passen, met nog wat ruimte over. Dit bericht 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 laden.

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 fractie aan nauwkeurigheid, maar bespaart veel geheugen. 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 standaardinstelling voor 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, verklein dan liever de modelklasse 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 kolom voor gewichten 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 kost dan de gewichten

De KV cache (key value cache, de attention-status die het model bijhoudt voor elk token in het huidige gesprek) is de tweede kostenpost. Deze wordt toegewezen bij het laden van het model, krijgt de grootte van 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 dan drie keer het gewicht van de parameters is. 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 een CPU gebruikt. Wanneer er een GPU aanwezig is, kiest het programma 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 de modelkaart adverteert, aangezien het meeste chat- en programmeerwerk binnen 8k tot 32k past. Of kwantiseer de cache zelf naar 8 bits, wat de omvang halveert, ten koste van enige nauwkeurigheid bij lange contexten.

Een resident model houdt het RAM bezet totdat het wordt ontladen

Ollama houdt een model 5 minuten na het laatste verzoek in het geheugen en ontlaadt het daarna. Deze standaardinstelling is geschikt voor een laptop, maar onjuist voor een server. Op een server zorgt dit ervoor dat bij elk verzoek na een periode van inactiviteit opnieuw de laadtijd moet worden afgewacht.

ollama ps
ollama stop qwen3:4b

ollama ps toont welke modellen resident zijn, waarbij een SIZE-kolom aangeeft hoeveel geheugen ze in beslag nemen en een UNTIL-kolom toont wanneer ze verlopen. Om een model permanent vast te pinnen, stelt u OLLAMA_KEEP_ALIVE=-1 in op de service. Een waarde van 0 ontlaadt het model 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, en dat is precies de bedoeling: het houdt het RAM bezet, ongeacht of het wordt 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, waardoor er ruwweg 3 GB overblijft. 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 klasse onder andere Llama 3.2 met 3B, Qwen 3 met 1.7B en 4B, en de kleine releases van Gemma en Phi. Beschouw deze namen als voorbeelden van grootte, niet als aanbevelingen. De namen veranderen elke paar maanden, maar de rekenkunde niet.

Verwacht ruwweg 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 in een specifieke huisstijl. Ze presteren minder bij redeneringen in meerdere stappen en bij code die meerdere bestanden beslaat; geen enkele hoeveelheid prompting lost dat op.

Het faalscenario op dit niveau is swap. Als het model niet in het geheugen past, weigert Linux het laden niet. In plaats daarvan wordt geheugen naar de schijf verplaatst (paging). Omdat het genereren van een enkel token elk gewicht één keer leest, zakt de generatiesnelheid in naar seconden per token. Houd free -h en de kolommen si en so van vmstat 1 in de gaten 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 op 4 bits draaien, wat ongeveer 4.8 GB aan gewichten inneemt, met een context van 8k. Op 16 GB kunt u een 13B of 14B model op 4 bits draaien, ongeveer 8.4 GB, of u kunt een 8B model op 8 bits behouden 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 een achtergrondtaak, maar vermoeiend voor interactieve chat. 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 dit 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.

Lees vervolgens de snelheid realistisch. Een 32B-model op de CPU haalt ongeveer 0.6 tot 1.5 tokens per seconde, en een 70B-model 0.2 tot 0.5. Een antwoord van 500 tokens van dat 70B-model duurt ongeveer twintig minuten. Bij die snelheid wordt de aanvraag meestal afgebroken voordat het model klaar is, omdat een client- of proxy-time-out vóór Ollama eerst optreedt. Daar komt de fout contextdeadline overschreden vandaan. Dit zijn batchtools. Voer ze 's nachts een wachtrij met documenten aan; dan maakt de snelheid niet uit. Plaats ze achter een chatvenster en de snelheid wordt wel zeer belangrijk.

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 elke 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 elke token alleen de actieve experts leest. Op een 32 GB machine is een MoE-model met deze 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-inferentie in de praktijk?

Voor het genereren van één token moet elk actief gewicht één keer uit het geheugen worden gelezen. Dit is onvermijdelijk, waardoor de generatiesnelheid op een CPU wordt bepaald door de geheugenbandbreedte en niet door het aantal cores. Het maximum wordt berekend door de bruikbare geheugenbandbreedte te delen 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 een maximum bereikt van 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 resultaat 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 ook het inlezen van de gewichten vanaf de schijf meerekent. Tokens per seconde correct meten beschrijft hoe u een getal krijgt dat geschikt is voor vergelijking.

Twee resultaten verrassen gebruikers hier vaak. Het toevoegen van vCPU's helpt al snel niet meer, omdat de extra cores na ongeveer 8 cores vooral wachten op het geheugen in plaats van berekeningen uit te voeren. En op een gedeeld abonnement geeft hetzelfde commando elk uur andere getallen terug; dit is CPU steal time door een luidruchtige buur en ligt niet aan een verkeerde configuratie van uw kant.

Het inlezen 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 het punt waarop een GPU de grootste voorsprong neemt. 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 inzetten van een coding agent op een zelfgehost model, 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 korte 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 PROCESSOR kolom, als bijvoorbeeld 78%/22% CPU/GPU. Beschouw dit eerder als een waarschuwing dan als een functie. De CPU-helft bepaalt het tempo, omdat elk token nog steeds moet wachten op die lagen. Een model met een kwart van zijn lagen op de CPU draait dus veel dichter bij de CPU-snelheid dan bij de GPU-snelheid. Als u een splitsing ziet die u niet had beoogd, 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 op 8k context hebben dus tien keer 1 GB aan cache nodig bovenop de gewichten. Gelijktijdige gebruikers bedienen vanaf één zelfgehost model behandelt waar dat plafond ligt.

Of het huren van een GPU de moeite waard is, is eveneens een rekenkundige vraag, en het komt neer op 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 is nuttig om te weten tegen welke u aanloopt.

De eerste betreft gesloten gewichten. Commerciële grensverleggende modellen worden niet gedistribueerd, dus er is geen bestand om te downloaden en geen hoeveelheid RAM die daar verandering in brengt. U kunt alles eromheen zelf hosten: de interface, de retrieval-laag, de agent-loop, 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 'mixture of experts'-ontwerpen met in totaal honderden miljarden parameters. 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. Dezelfde splitsing is zichtbaar in de eigen bibliotheek van Ollama, waar GLM 5.2 alleen als cloudmodel wordt vermeld en een veel kleinere variant degene is die daadwerkelijk naar een VPS kan worden gedownload.

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 grensverleggende modellen precies is wat u nodig heeft.

Controleer wat u heeft voordat u kiest

free -h
nproc
lscpu | grep 'Model name'

Plan op basis van de available-kolom van free -h, niet 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 wat overblijft door 0,6 om het grootste aantal parameters in miljarden te bepalen dat u op 4 bits kunt opslaan. Trek vervolgens de KV-cache af voor de context die u daadwerkelijk wilt gebruiken. Wat overblijft is uw antwoord, en in tegenstelling tot een lijst met modelnamen raakt dit niet verouderd.

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 plan van 8 GB volstaat en een plan van 4 GB niet. Als u de volledige 128k context wilt die de modelkaart adverteert, is de cache alleen al 16 GB en heeft u een plan van 32 GB nodig.

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

Omdat generatie wordt beperkt door geheugenbandbreedte, niet door cores. Elk token vereist dat de volledige actieve gewichtenset uit het RAM wordt gehaald. Zodra enkele cores de geheugenkanalen verzadigen, wachten de overige cores. De andere veelvoorkomende oorzaak is swap. Als vmstat 1 een waarde ongelijk aan nul 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 geladen. Dit kost veel meer tijd dan verwacht.

Heeft een langere contextwindow echt meer geheugen nodig?

Ja, en de groei is lineair met 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 in plaats van wanneer het gesprek groeit. Een context van 128k reserveren betekent dus dat dit geheugen direct wordt geclaimd, 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 teruggebracht naar 2 bits geeft doorgaans slechtere antwoorden dan een 32B model op 4 bits uit dezelfde modelgeneratie. Zware kwantisatie uit zich in herhalingen en het negeren van 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 bestaan uit honderden miljarden parameters. Bij 4 bits betekent dit meer dan 200 GB RAM voordat er überhaupt KV-cache wordt gebruikt. 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 compact en goed aangestuurd klein model vaak niet onderdoet voor een algemeen model. Als u topkwaliteit nodig heeft, vergelijk dan de kosten van de API met die van de hardware voordat u een keuze maakt.