Wanneer heeft u een VPS met GPU echt nodig?

Heeft u een VPS met GPU nodig, of volstaat een CPU?

Een VPS met GPU verandert twee zaken bij het zelf draaien van een model: de snelheid waarmee tokens worden gegenereerd en de maximale grootte van het model dat in het geheugen past. Verder verandert er niets. Als uw werklast bestaat uit een gekwantiseerd 7B tot 27B chatmodel dat één persoon tegelijk bedient, een embedding-taak met een laag volume, of spraaktranscriptie met Whisper small, dan volstaat een standaard CPU-VPS met voldoende RAM. Begin op een CPU, meet de waarde die u stoort en schaal pas daarna op.

De reden hiervoor is geheugenbandbreedte. Wanneer een taalmodel één token genereert, leest het elk gewicht dat nodig is uit het geheugen. Een 8B-model dat is gekwantiseerd naar 4 bits is ongeveer 4,7 GB op schijf en ongeveer even groot in het geheugen; het produceren van een token betekent dus dat er ongeveer 4,7 GB verplaatst moet worden. Deel de geheugenbandbreedte van de machine door dat getal en u heeft het maximum aantal tokens per seconde. Deze ene deling verklaart vrijwel elke benchmark die u zult lezen.

Wat een GPU u daadwerkelijk oplevert

Bandbreedte. Server DDR5 op een moderne host verplaatst tientallen gigabytes per seconde. GPU-geheugen (VRAM, video RAM) verplaatst honderden tot meer dan duizend. De verhouding bepaalt de versnelling, en deze is aanzienlijk.

Capaciteit in combinatie met snelheid. Een CPU-server met 64 GB RAM kan een 70B-model op 4 bits laden. Het zal draaien, in een tempo dat meer lijkt op lezen dan op chatten. Een GPU helpt hier alleen als het model in het VRAM past, want zodra lagen uitwijken naar het systeem-RAM, neemt het trage pad de regie weer over.

Batch-doorvoer. Dit is het aspect dat mensen onderschatten. Een GPU die voor één gebruiker genereert, laat het grootste deel van zijn rekenkracht onbenut, omdat deze wacht op het geheugen. Bedien 20 verzoeken tegelijk en dezelfde gelezen gewichten dienen alle 20 verzoeken. Het totaal aantal tokens per seconde stijgt aanzienlijk, terwijl de snelheid per gebruiker nauwelijks afneemt. Een CPU kan dit niet. Twee gelijktijdige gebruikers op een CPU-server halveren elkaars snelheid ongeveer. Als u een API bouwt die door veel clients wordt aangeroepen, is batching het argument voor een GPU, meer nog dan de pure snelheid van een enkele stream.

Promptverwerking. Het lezen van een lange prompt is rekenintensief (compute-bound), niet geheugenintensief (memory-bound), en dit is waar GPU's met de grootste marge winnen. Een context van 30.000 tokens waar een CPU een minuut over doet, kost een GPU slechts enkele seconden. Retrieval-opstellingen die documenten in elk verzoek proppen, merken dit voortdurend.

Globale cijfers en hoe u deze interpreteert

Het onderstaande blok bevat typische gepubliceerde single-stream-cijfers voor een 8B-model met 4-bit kwantisatie, zoals die in juli 2026 bekend waren. Dit zijn richtlijnen van de juiste grootteorde, geen garanties. Uw kwantisatie, contextlengte en inference engine zullen deze waarden beïnvloeden.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

De rij voor de 24 GB GPU toont 50 tokens per seconde tegenover 11 voor een DDR5 CPU-systeem. Dat is ongeveer vijf keer zoveel, wat overeenkomt met de bandbreedteverhouding in plaats van een verschil in pure rekenkracht. De werkelijke doorvoer ligt ook lager dan de bandbreedte gedeeld door de modelgrootte, omdat attention bij een groeiende context extra werk toevoegt waar de eenvoudige deling geen rekening mee houdt.

Ter vergelijking: een mens leest ongeveer 5 tot 10 woorden per seconde. Alles vanaf 15 tokens per seconde voelt voor een individuele lezer al aan als normaal typen. Daarom voldoen veel CPU-only opstellingen in de praktijk prima.

VRAM-capaciteit bepalen voor aanschaf

De bestandsgrootte van het model is de ondergrens, niet de vereiste capaciteit. Reken met de gewichten, plus de KV-cache (key-value cache, het geheugen per token dat nodig is voor attention), plus ongeveer 1 GB aan overhead.

Een praktische vuistregel per juli 2026: neem de bestandsgrootte van het model in gigabytes en tel daar 20 procent bij op voor een normale context van 8k tot 16k. Een 8B-model van 4,7 GB vereist ongeveer 6 GB VRAM. Een 27B-model op 4 bits is ongeveer 16 GB en vereist ruwweg 20 GB. Een 70B-model op 4 bits is ongeveer 40 GB en vereist een kaart van 48 GB, of twee kleinere kaarten. Deze berekening blijft ook ver daarboven geldig, en de VRAM-berekening voor een model met 2,8 biljoen parameters zoals Kimi K3 laat zien waar de keuze voor een videokaart er niet meer toe doet.

Lange contexten doorbreken deze regel. De KV-cache groeit lineair met de contextlengte en kan bij 128k tokens groter worden dan de gewichten zelf. Als u van plan bent lange contexten te gebruiken, bepaal de capaciteit dan eerst op basis van de cache en controleer welke opties uw engine biedt voor cache-kwantisatie.

Controleer wat de machine daadwerkelijk heeft

Bevestig op een GPU-instantie eerst of de driver de kaart herkent voordat u andere stappen onderneemt.

nvidia-smi

U wilt een tabel zien met de GPU-naam, de driverversie en het gebruikte geheugen ten opzichte van het totaal. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver betekent dat de driver ontbreekt of dat de kernelmodule niet opnieuw is gecompileerd na een kernel-upgrade. Op een standaard Ubuntu-image is de oplossing meestal sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, gevolgd door een herstart zodat de nieuwe module wordt geladen.

Voor containers is de driver alleen niet voldoende. Docker heeft de NVIDIA Container Toolkit nodig om het apparaat door te geven.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Controleer vervolgens of de passthrough werkt vanuit een container:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Dezelfde tabel zou moeten verschijnen. Een docker: Error response from daemon: could not select device driver-regel, die een GPU-mogelijkheid noemt waaraan niet kan worden voldaan, betekent dat de toolkit is geïnstalleerd maar dat Docker niet opnieuw is geconfigureerd of herstart. Voer daarom de nvidia-ctk-regel en de herstart opnieuw uit. In Compose is het equivalent een deploy.resources.reservations.devices-item waarvan de driver gelijk is aan nvidia en waarvan de lijst met mogelijkheden gpu bevat, wat past in de standaard servicedefinities die worden behandeld in Docker Compose op een VPS.

Meten voor de upgrade

Draai het model dat u daadwerkelijk wilt gebruiken op de CPU-server die u al heeft en noteer de resultaten. Bij Ollama zelf hosten van een LLM op een VPS is hiervoor één vlag nodig:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

De uitvoer eindigt met tijdsmetingen. eval rate is uw generatiesnelheid in tokens per seconde. prompt eval rate geeft aan hoe snel de machine uw invoer heeft gelezen. Deze twee getallen vertellen u welke upgrade helpt: een lage eval rate duidt op een probleem met de geheugenbandbreedte, en een lage prompt eval rate bij lange invoer duidt op een rekenkrachtprobleem.

Controleer op een machine met een GPU of het model daadwerkelijk op de GPU is geladen:

ollama ps

De kolom PROCESSOR geeft 100% GPU aan wanneer alles past, of iets als 43%/57% CPU/GPU wanneer dit niet het geval is. Een gedeeltelijke verdeling is meestal slechter dan u verwacht, omdat elk token nog steeds moet wachten op de langzame helft.

De kostenkwestie

GPU-instances kosten aanzienlijk meer dan vergelijkbare CPU-instances en worden per uur gefactureerd, ongeacht het aantal gegenereerde tokens. Een GPU die continu draait voor slechts enkele verzoeken per dag is de duurste manier om inferentie uit te voeren. Het omslagpunt wordt bepaald door de bezettingsgraad: een intensief gebruikte GPU is goedkoop per token, terwijl een inactieve GPU puur verlies is.

Er zijn drie effectieve strategieën. Houd stabiele taken met een laag volume op een CPU VPS. Stuur incidentele, complexe verzoeken naar een hosted API en betaal per token. Huur een GPU per uur voor batchtaken, fine-tuning of het verwerken van grote hoeveelheden embeddings en beëindig de instance daarna direct. Het combineren van deze methoden is gebruikelijk. De budgetdiscipline zoals beschreven in AI-agent kostenbeheersing op een altijd actieve VPS is hier ook van toepassing, met het verschil dat inactieve tijd de voornaamste kostenpost is in plaats van het aantal tokens.

Wat nog steeds prima werkt zonder GPU

Embeddings bij een laag volume. Een klein embedding-model verwerkt honderden korte documenten per minuut op enkele CPU-cores, en een index die u eenmalig opbouwt hoeft niet snel te zijn.

Whisper small en base voor transcriptie. Faster-whisper op de CPU transcribeert bijna in real-time met het small-model, wat voldoende is voor een pipeline die 's nachts draait.

Gekwantiseerde chatmodellen tot ongeveer 27B, voor één of twee gebruikers. Traag, leesbaar, bruikbaar.

Alles wat u een batch-job zou noemen. Als er niemand naar het scherm kijkt, is de verstreken tijd een planningsdetail in plaats van een vereiste.

Wat echt een GPU nodig heeft: trainen of fine-tunen voorbij een kleine adapter, het bedienen van veel gelijktijdige gebruikers, beeld- en videogeneratie, en real-time spraak waarbij latentie het product is.

FAQ

Hoeveel VRAM heb ik nodig voor een 7B of 8B model?

Ongeveer 6 GB voor een 4-bit gekwantiseerd 8B model bij een normale context van 8k tot 16k. De gewichten beslaan ongeveer 4,7 GB en de rest is de KV-cache plus ongeveer 1 GB aan overhead. Een kaart met 12 GB biedt voldoende ruimte voor langere contexten. Als u van plan bent om op 128k context te draaien, moet u de cache apart berekenen, omdat deze groter kan worden dan de gewichten zelf.

Kan ik Ollama draaien zonder GPU?

Ja. Ollama schakelt automatisch over naar de CPU en heeft alleen voldoende RAM nodig om het model te laden. Reken op ongeveer 5 tot 12 tokens per seconde voor een 4-bit 8B model, afhankelijk van de geheugensnelheid; dit is voor één gebruiker vergelijkbaar met leestempo. Lange prompts vormen het echte knelpunt op de CPU, omdat het inlezen van 30.000 tokens aan context rekenintensief is en veel langer duurt dan het genereren van het antwoord.

Waarom is mijn GPU nauwelijks sneller dan de CPU?

De gebruikelijke oorzaak is dat het model niet volledig in het VRAM past, waardoor sommige lagen op de CPU draaien en elk token moet wachten op het trage gedeelte. Voer ollama ps uit en controleer of de kolom PROCESSOR de waarde 100% GPU aangeeft. Als er sprake is van een splitsing, gebruik dan een kleinere kwantisatie of een kleiner model. De andere veelvoorkomende oorzaak is een korte benchmark waarbij de laadtijd van het model de meting domineert.

Is een GPU VPS de moeite waard voor een enkele gebruiker?

Meestal niet. Eén persoon leest met 5 tot 10 woorden per seconde, en een CPU-server produceert tokens al sneller dan dat voor modellen tot ongeveer 13B. De gevallen die de kosten voor een enkele gebruiker rechtvaardigen, zijn lange prompts, het genereren van afbeeldingen en fine-tuning. Het bedienen van veel gebruikers tegelijk is het sterkste argument, omdat batching ervoor zorgt dat één GPU twintig verzoeken kan beantwoorden voor bijna dezelfde kosten als één verzoek.

Moet ik een GPU per uur huren of altijd aan laten staan?

Huur per uur wanneer het werk incidenteel is: fine-tuning, een bulk-embedding run of een batch transcriptie-taak. Laat een GPU alleen altijd aan staan als de kaart continu bezet is, aangezien een GPU-instantie kosten in rekening brengt voor het bestaan ervan in plaats van voor de geproduceerde tokens. Een assistent met weinig verkeer is goedkoper op een CPU VPS, of via een gehoste API waar per token wordt betaald, dan op een inactieve GPU.