VPS met GPU nodig? Wanneer CPU volstaat

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

Een VPS met GPU verandert twee aspecten van het zelf uitvoeren van een model: hoe snel tokens worden gegenereerd en hoe groot een model maximaal in het geheugen past. Voor het overige verandert er niets. Als uw workload bestaat uit een gequantiseerd chatmodel van 7B tot 27B dat telkens één persoon antwoord geeft, een embedding-taak met een lage belasting of spraaktranscriptie met Whisper small, voert een gewone CPU-VPS met voldoende RAM de taak al uit. Begin met CPU, meet de waarde die u beperkt en schaal daarna op.

De reden is de geheugenbandbreedte. Wanneer een taalmodel één token genereert, leest het alle benodigde gewichten uit het geheugen. Een 8B-model dat naar 4 bits is gequantiseerd, is ongeveer 4.7 GB groot op schijf en neemt in het geheugen ongeveer evenveel ruimte in. Voor het genereren van één token moet daarom ongeveer 4.7 GB worden verplaatst. Deel de geheugenbandbreedte van de machine door dat getal. Dan krijgt u de bovengrens voor het aantal tokens per seconde. Deze ene deling verklaart vrijwel elke benchmark die u zult lezen.

Wat een GPU u daadwerkelijk oplevert

Bandbreedte. Server-DDR5 in een moderne host verwerkt tientallen gigabytes per seconde. GPU-geheugen (VRAM, videogeheugen) verwerkt honderden tot meer dan duizend gigabytes per seconde. De verhouding bepaalt de snelheidswinst, en die is groot.

Capaciteit met snelheid. Een CPU-systeem met 64 GB RAM kan een 70B-model met 4 bits laden. Het model werkt dan, maar eerder in een tempo dat bij lezen past dan bij chatten. Een GPU helpt hier alleen als het model in VRAM past, omdat de trage verwerking opnieuw bepalend wordt zodra lagen naar het systeem-RAM overlopen.

Batchdoorvoer. Dit wordt vaak onderschat. Een GPU die voor één gebruiker genereert, laat het grootste deel van zijn rekenvermogen ongebruikt, omdat de GPU op geheugen wacht. Verwerk 20 verzoeken tegelijk en dezelfde gewichtswaarden worden voor alle 20 verzoeken gelezen. Het totale aantal tokens per seconde stijgt dan meerdere keren, terwijl de snelheid per gebruiker nauwelijks afneemt. Een CPU doet dit niet. Twee gelijktijdige gebruikers op een CPU-systeem halveren elkaars snelheid ongeveer. Als u een API bouwt die door veel clients wordt aangeroepen, is batching het belangrijkste argument voor een GPU, meer dan de onbewerkte snelheid van één gegevensstroom.

Promptverwerking. Het lezen van een lange prompt is rekenintensief en niet geheugenintensief. Hier presteren GPU's met de grootste marge beter. Een context van 30,000 tokens die een CPU in een minuut verwerkt, duurt op een GPU enkele seconden. Dit merkt u voortdurend bij retrieval-opstellingen die documenten aan elk verzoek toevoegen.

Schattingen en hoe u ze leest

Het onderstaande blok bevat typische gepubliceerde cijfers voor één gegevensstroom voor een 8B-model met 4-bitskwantisatie, geldig vanaf juli 2026. Ze geven een orde van grootte aan en zijn geen garantie. Uw kwantisatie, contextlengte en inference engine beïnvloeden deze waarden.

[
  {
    "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 GPU van 24 GB toont 50 tokens per seconde, tegenover 11 voor een CPU-systeem met DDR5. Dat is ongeveer vijf keer zo snel. Dit komt overeen met de verhouding in bandbreedte en niet met een verschil in onbewerkte rekenkracht. De werkelijke doorvoer ligt ook onder bandbreedte gedeeld door modelgrootte. Attention over een groeiende context voegt namelijk werk toe dat deze eenvoudige deling buiten beschouwing laat.

Ter vergelijking: een persoon leest ongeveer 5 tot 10 woorden per seconde. Bij 15 tokens per seconde of meer voelt de uitvoer voor één lezer al aan als normaal typen. Daarom voldoen veel configuraties die alleen CPU gebruiken in de praktijk prima.

VRAM dimensioneren voordat u koopt

De bestandsgrootte van het model is de ondergrens, niet de vereiste capaciteit. Reserveer ruimte voor de gewichten, de KV-cache (key-value cache, het geheugen per token dat attention bijhoudt) en ongeveer 1 GB overhead.

Een praktische vuistregel per juli 2026: neem de bestandsgrootte van het model in gigabytes en tel 20 procent op voor een normale context van 8k tot 16k. Een 8B-model van 4.7 GB heeft ongeveer 6 GB VRAM nodig. Een 27B-model met 4 bits is ongeveer 16 GB groot en heeft ongeveer 20 GB nodig. Een 70B-model met 4 bits is ongeveer 40 GB groot en vereist een kaart van 48 GB of twee kleinere kaarten.

Lange contexten maken deze vuistregel onbruikbaar. De KV-cache groeit lineair met de contextlengte en kan bij 128k tokens groter worden dan de gewichten zelf. Als u lange contexten wilt gebruiken, dimensioneer dan eerst voor de cache en controleer welke mogelijkheden uw engine biedt voor cachekwantisatie.

Controleer wat de machine daadwerkelijk heeft

Controleer op een GPU-instantie eerst of het stuurprogramma de kaart detecteert.

nvidia-smi

De uitvoer moet een tabel bevatten met de naam van de GPU, de versie van het stuurprogramma en het gebruikte geheugen ten opzichte van het totale geheugen. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver betekent dat het stuurprogramma ontbreekt of dat de kernelmodule na een kernelupgrade niet opnieuw is gebouwd. 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 alleen het stuurprogramma 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 vanuit een container of het doorgeven van het apparaat werkt:

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

Dezelfde tabel moet worden weergegeven. Een regel met docker: Error response from daemon: could not select device driver waarin een GPU-mogelijkheid wordt genoemd waaraan niet kan worden voldaan, betekent dat de toolkit is geïnstalleerd, maar dat Docker niet opnieuw is geconfigureerd of herstart. Voer daarom de regel nvidia-ctk en de herstart opnieuw uit. In Compose is het equivalent een item deploy.resources.reservations.devices waarvan driver gelijk is aan nvidia en waarvan de lijst met mogelijkheden gpu bevat. Dit kan worden toegevoegd aan de gewone service-definities die worden behandeld in Docker Compose op een VPS.

Meet vóór u upgradet

Voer het model dat u daadwerkelijk wilt gebruiken uit op de bestaande CPU-server en noteer de resultaten. Met Ollama zelf een LLM hosten op een VPS hebt u hiervoor één vlag nodig:

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

De uitvoer eindigt met tijdmetingen. eval rate is uw generatiesnelheid in tokens per seconde. prompt eval rate is de snelheid waarmee de machine uw invoer heeft gelezen. Deze twee waarden laten zien welke upgrade helpt: een lage eval rate wijst op een probleem met de geheugenbandbreedte, en een lage prompt eval rate bij lange invoer wijst op een rekenprobleem.

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

ollama ps

De kolom PROCESSOR bevat 100% GPU als alles op de GPU past, of iets zoals 43%/57% CPU/GPU als dat niet het geval is. Een gedeeltelijke verdeling is meestal slechter dan u verwacht, omdat elk token nog steeds op het trage deel moet wachten.

De kostenkwestie

GPU-instanties kosten meerdere keren zoveel als een vergelijkbare CPU-instantie. U betaalt voor elk uur dat ze bestaan, niet voor de tokens die ze produceren. Een GPU die altijd aanstaat en slechts enkele verzoeken per dag verwerkt, is de duurste manier om inference uit te voeren. Het omslagpunt is benutting: een drukbezette GPU is goedkoop per token, terwijl een inactieve GPU pure verspilling is.

Er zijn drie praktische patronen. Houd stabiel werk met een laag volume op een CPU VPS. Stuur incidentele complexe verzoeken naar een gehoste API en betaal per token. Huur een GPU per uur voor batchtaken, fine-tuning of een bulk embedding-run en verwijder de instantie daarna. Combinaties hiervan zijn normaal. De budgetdiscipline uit Kostenbeheersing voor AI-agents op een VPS die altijd aanstaat is hier ook van toepassing. Het verschil is dat inactieve tijd de kostenlek vormt, niet het aantal tokens.

Wat nog goed werkt zonder GPU

Embeddings met een laag volume. Een klein embeddingmodel verwerkt op enkele CPU-cores honderden korte documenten per minuut. Een index die u eenmaal opbouwt, hoeft niet snel te zijn.

Whisper small en base voor transcriptie. Faster-whisper transcribeert op een CPU met het small-model bijna in realtime. Dat is voldoende voor een pipeline die 's nachts draait.

Quantized chatmodellen tot ongeveer 27B, voor een of twee gebruikers. Traag, leesbaar en bruikbaar.

Alles wat u als batchtaak zou beschouwen. Als niemand naar het scherm kijkt, is de doorlooptijd alleen van belang voor de planning en geen vereiste.

Wat daadwerkelijk een GPU nodig heeft: training of fine-tuning die verder gaat dan een kleine adapter, dienstverlening aan veel gelijktijdige gebruikers, het genereren van afbeeldingen en video, en realtime spraak waarbij latency 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 nemen ongeveer 4.7 GB in beslag. De rest bestaat uit de KV-cache en ongeveer 1 GB overhead. Met een kaart van 12 GB houdt u voldoende ruimte over voor langere contexten. Als u een context van 128k wilt gebruiken, moet u de cache afzonderlijk dimensioneren. Deze kan groter worden dan de gewichten.

Kan ik Ollama zonder GPU uitvoeren?

Ja. Ollama schakelt automatisch over op de CPU en heeft alleen voldoende RAM nodig om het model te bevatten. Reken voor een 4-bit 8B-model, afhankelijk van de geheugensnelheid, op ongeveer 5 tot 12 tokens per seconde. Dat ligt voor één gebruiker dicht bij de leessnelheid. Lange prompts vormen het grootste probleem op een CPU. Het verwerken van 30,000 tokens context is rekenintensief en duurt veel langer 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 paste. Daardoor worden sommige lagen op de CPU uitgevoerd en wacht elke token op het traagste deel. Voer ollama ps uit en controleer of de kolom PROCESSOR de waarde 100% GPU bevat. Als daar een verdeling wordt weergegeven, gebruikt u een kleinere quantisatie of een kleiner model. Een andere veelvoorkomende oorzaak is een korte benchmark waarbij de laadtijd van het model het grootste deel van de meting bepaalt.

Is een GPU VPS de moeite waard voor één gebruiker?

Meestal niet. Eén persoon leest 5 tot 10 woorden per seconde. Een CPU-systeem genereert voor modellen tot ongeveer 13B al sneller tokens dan dat. Voor één gebruiker zijn lange prompts, beeldgeneratie en fine-tuning de belangrijkste redenen om de kosten te rechtvaardigen. Veel gebruikers gelijktijdig bedienen is het sterkste argument. Door batching kan één GPU twintig aanvragen verwerken tegen ongeveer de kosten van één aanvraag.

Kan ik beter per uur een GPU huren of er permanent één uitvoeren?

Huur per uur als het werk in pieken plaatsvindt, zoals bij fine-tuning, een bulkbewerking voor embeddings of een batchtranscriptietaak. Laat een GPU alleen permanent draaien als deze continu wordt belast. Een GPU-instantie wordt namelijk gefactureerd zolang deze bestaat, niet op basis van het aantal geproduceerde tokens. Een assistent met weinig verkeer is goedkoper op een CPU VPS of via een gehoste API waarvoor u per token betaalt dan op een ongebruikte GPU.