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 aspecten 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. Andere zaken veranderen niet. Als uw werklast bestaat uit een gekwantiseerd 7B tot 27B chatmodel dat één gebruiker 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 als traag ervaart en schaal pas daarna op.

De reden hiervoor is geheugenbandbreedte. Wanneer een taalmodel één token genereert, leest het elk benodigd gewicht uit het geheugen. Een 8B-model dat is gekwantiseerd naar 4 bits is ongeveer 4.9 GB op schijf en neemt ongeveer evenveel ruimte in het geheugen in beslag; het produceren van een token betekent dus dat er ongeveer 4.9 GB aan data wordt verplaatst. Deel de geheugenbandbreedte van de machine door dat getal en u heeft het maximum aantal tokens per seconde. Deze eenvoudige deling verklaart vrijwel elke benchmark die u zult tegenkomen.

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 is de versnelling, en deze is aanzienlijk.

Capaciteit in combinatie met snelheid. Een CPU-systeem 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 nauwlijks afneemt. CPU-inferentie-engines zoals llama.cpp ondersteunen ook batching, waarbij de winst afhangt van de hardware en de werklast. Als u een API bouwt die door veel clients wordt aangeroepen, is batching een sterker argument voor een GPU 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.

Ruwe cijfers en hoe u deze moet interpreteren

De werkelijke doorvoer ligt ook lager dan de bandbreedte gedeeld door de modelgrootte, omdat aandacht over een groeiende context extra werk toevoegt waar de eenvoudige deling geen rekening mee houdt.

Ter vergelijking: volwassenen die in stilte Engels lezen, halen gemiddeld ongeveer 4,0 tot 4,3 woorden per seconde: 238 woorden per minuut voor non-fictie en 260 voor fictie. Alles vanaf 15 tokens per seconde voelt voor een individuele lezer al aan als normaal typen. Daarom voldoen veel opstellingen die alleen op een CPU draaien in de praktijk prima.

VRAM-capaciteit bepalen voor aanschaf

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

Bereken de cache in plaats van een vast percentage toe te voegen, aangezien het kwantiseren van de gewichten de cache niet kwantiseert. Voor elk token slaat een full-attention model een key en een value op voor elke laag en elke KV-head, met 2 bytes per getal in FP16, het standaard cachetype van Ollama. De modelmetadata van Ollama, gecontroleerd op 2026-10-27, geeft voor Llama 3.1 8B 32 lagen en 8 KV-heads van 128 dimensies aan. Dit komt neer op 128 KiB per token: ongeveer 1,07 GB bij een context van 8k en 2,15 GB bij 16k. Een 8B-model van 4,9 GB vereist dus ongeveer 7 GB VRAM bij 8k en ongeveer 8 GB bij 16k. Een 27B-model op 4 bits is ongeveer 17 GB (Gemma 3 27B in de bibliotheek van Ollama). De metadata van Gemma 3 vermeldt een sliding window van 1.024 tokens, waardoor de cache niet onbeperkt groeit; reken dus op 20 GB of meer. Een 70B-model op 4 bits is ongeveer 43 GB (Llama 3.3 70B). Met 80 lagen voegt de FP16-cache ongeveer 2,7 GB toe bij 8k en 5,4 GB bij 16k. Dit vereist een kaart van 48 GB met weinig reserve, of twee kleinere kaarten. Deze rekenmethode blijft ook ver daarbuiten werken, en de VRAM-berekening voor een model met 2,8 biljoen parameters zoals Kimi K3 laat zien wanneer de keuze voor een kaart er niet meer toe doet.

Bij lange contexten is dit het meest relevant. Bij full-attention modellen zoals Llama 3.1 groeit de KV-cache lineair met de contextlengte, en bij 128k tokens kan deze groter worden dan de gewichten zelf. Modellen met sliding-window of chunked attention werken anders: de Transformers-documentatie van Hugging Face noemt Mistral, Gemma 2 en Llama 4 als voorbeelden waarbij de cache op die lagen stopt met groeien zodra de window- of chunk-grootte is bereikt, waardoor de totalen langzamer toenemen. Als u van plan bent lange contexten te gebruiken, dimensioneer dan eerst voor de cache en controleer wat uw engine biedt voor cache-kwantisatie. In Ollama gebruikt OLLAMA_KV_CACHE_TYPE=q8_0 ongeveer de helft van het geheugen van de standaard f16, en cache-kwantisatie is alleen van toepassing wanneer Flash Attention is ingeschakeld. Stel de contextlengte ook expliciet in. Ollama kiest de standaardwaarde op basis van VRAM: 4k onder 24 GiB, 32k van 24 tot 48 GiB, en 256k bij 48 GiB en meer. Op een kaart van 48 GB die een 70B-model draait, vraagt die standaardinstelling om veel meer cache dan de kaart kan bevatten.

Controleer wat de machine daadwerkelijk heeft

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

nvidia-smi

U wilt een tabel zien met de naam van de GPU, 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 NVIDIA-SMI de driver niet kan bereiken; controleer of de driver is geïnstalleerd en de kernelmodule is geladen. 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 rekenmachines adviseert de serverdocumentatie van Ubuntu sudo ubuntu-drivers install --gpgpu, waarmee de server-driverbranch wordt geselecteerd.

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

Bewijs vervolgens dat 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 Docker geen apparaatdriver kon vinden die overeenkomt met het verzoek; controleer of de toolkit is geïnstalleerd en voer daarna 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 gebruikelijke 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 worden gefactureerd op basis van de gereserveerde rekentijd in plaats van tokens, waarbij de tarieven en kosten voor gestopte instances door de provider worden vastgesteld. Een GPU die altijd aan staat en slechts een handvol verzoeken per dag verwerkt, brengt het grootste deel van de betaalde tijd inactief door. Het omslagpunt is de bezettingsgraad: een intensief gebruikte GPU is goedkoop per token, terwijl een inactieve GPU puur verlies is.

Drie eerlijke patronen werken goed. Houd stabiel werk met een laag volume op een CPU VPS. Stuur incidentele zware 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 deze daarna. 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 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 7 GB voor een 4-bit gekwantiseerd 8B model met een context van 8k, en ongeveer 8 GB bij 16k, uitgaande van de standaard FP16-cache van Ollama. De gewichten beslaan ruwweg 4,9 GB, de KV-cache voegt ongeveer 1,07 GB toe bij 8k of 2,15 GB bij 16k, en de rest is ongeveer 1 GB aan overhead. Een kaart met 8 GB kan dit aan bij 8k, maar zit krap bij 16k, terwijl een kaart met 12 GB comfortabel ruimte biedt voor langere contexten. Het overschakelen van de cache naar q8_0 halveert het aandeel van de cache ongeveer. Als u van plan bent om met een context van 128k te werken, bereken de cache dan apart, 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 komt voor één gebruiker in de buurt van leessnelheid. Lange prompts zijn het echte pijnpunt op een CPU, omdat het verwerken 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 paste, 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. Gemiddeld leest een volwassene in stilte ongeveer 4,0 tot 4,3 woorden per seconde; tokens per seconde moeten worden omgerekend naar woorden per seconde voordat u een CPU-server met dat tempo vergelijkt. 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 het lezen van gewichten over meerdere verzoeken kan delen.

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-opdracht. Laat een GPU alleen altijd aanstaan als de kaart constant bezet is, aangezien voor GPU-rekenkracht wordt betaald op basis van tijd in plaats van geproduceerde tokens. Een assistent met weinig verkeer is goedkoper op een CPU VPS, of via een gehoste API waarbij per token wordt betaald, dan op een inactieve GPU.