Welke VPS om AI te draaien: via een API of een model op de server

Twee behoeften, twee serverformaten

De meeste applicaties die “AI gebruiken” (assistenten, agents, samenvattingen, gegevensextractie, zoeken in documenten) roepen via een API een model aan dat door de aanbieder wordt gehost. De berekening gebeurt daar; uw server bereidt het verzoek voor, wacht op het antwoord en verwerkt het. U dimensioneert hem dan zoals elke webapplicatie: op zijn taal, zijn database en het aantal gelijktijdige gebruikers.

Het andere geval is een model dat op de server zelf draait, met Ollama, llama.cpp of een Python-bibliotheek. De redenen zijn bekend: gegevens die op uw eigen infrastructuur blijven, vaste kosten ongeacht het aantal verzoeken, achtergrondverwerking van grote volumes, een gespecialiseerd model. Dan moet het hele model in het geheugen passen, en is het het model dat het formaat bepaalt.

Via een API: de applicatie dimensioneren, niet het model

Een verzoek aan een model via een API duurt van één tot enkele tientallen seconden, vooral wanneer het antwoord gaandeweg wordt doorgestuurd (streaming). Intussen rekent uw server bijna niets: hij wacht. Wat telt, is zijn vermogen om veel verzoeken in de wacht te houden zonder de andere te blokkeren:

• Een asynchrone server: Node.js, FastAPI met Uvicorn, of asynchrone Gunicorn-workers. Een synchrone worker die 20 seconden op een antwoord wacht, is een worker die voor alle andere bezoekers geblokkeerd is.
• Een takenwachtrij voor lange verwerkingen (een document samenvatten, een batch analyseren): het verzoek van de bezoeker krijgt meteen antwoord, een worker verwerkt het werk op de achtergrond.
• Afgestelde time-outs op de proxy: Nginx verbreekt standaard een antwoord dat langer dan 60 seconden stil blijft (proxy_read_timeout).

Het benodigde geheugen is dat van de applicatie en haar database: 4 GB dekt een Python- of Node.js-applicatie met PostgreSQL bij de lancering. Een gangbare opzet, een Next.js-frontend, een FastAPI-API en een PostgreSQL-database die een model via een API aanroepen, past in 6 tot 8 GB, de build van de frontend inbegrepen.

Embeddings en vectorzoeken: het geheugen van de vectoren

Een applicatie die in uw documenten zoekt (RAG, retrieval-augmented generation), zet elke passage om in een vector en zoekt daarna de vectoren die het dichtst bij een vraag liggen. Twee posten om te dimensioneren:

• Het embeddingmodel, als het bij u draait: gangbare modellen wegen 100 MB tot 1,5 GB en rekenen zonder moeite op een processor. all-MiniLM-L6-v2 bijvoorbeeld neemt minder dan 100 MB in.
• De vectoren: met pgvector neemt een vector 4 bytes per dimensie in, plus 8. Een miljoen passages van 1.536 dimensies zijn samen ongeveer 6 GB aan gegevens, en daar komt de HNSW-index bij die het zoeken versnelt. Voor snelle zoekopdrachten moeten de index en de geraadpleegde vectoren in het geheugen passen.

Het type halfvec van pgvector slaat elke dimensie op in 2 bytes in plaats van 4: de helft van het geheugen, voor een zoekkwaliteit die er heel dicht bij blijft.

Een model op de server: eerst het geheugen

Een taalmodel is een bestand met gewichten, dat volledig in het geheugen wordt geladen om te antwoorden. De grootte hangt af van het aantal parameters en van de kwantisatie, de precisie waarmee elk gewicht wordt opgeslagen. Het GGUF-formaat, dat van llama.cpp en Ollama, biedt kwantisaties van 2 tot 16 bits; de variant Q4_K_M, rond 4 bits, is het gangbare compromis tussen grootte en kwaliteit.

Bij dat gewicht komen nog twee posten:

• De context (de KV-cache): elk token van het lopende gesprek neemt geheugen in. Reken voor Llama 3.1 8B op ongeveer 128 KB per token bij 16-bitprecisie, dus 1 GB voor een context van 8.000 tokens, en evenveel voor elk gesprek dat parallel wordt verwerkt.
• De rest van de server: systeem, applicatie, database, zoals bij elke webapplicatie.

Voorbeeld. Llama 3.1 8B in 4 bits, twee gelijktijdige gesprekken van 8.000 tokens en een kleine applicatie: 5 GB model, 2 GB context, 2 GB voor de applicatie en het systeem, samen 9 GB, en ongeveer 12 GB met 25% marge.

Op een processor: wat de snelheid bepaalt

Om elk token te produceren, leest het model al zijn gewichten opnieuw uit het geheugen. Op een processor wordt de generatiesnelheid dus eerder begrensd door de geheugenbandbreedte dan door het aantal cores: een model van 5 GB, op een machine die 25 GB per seconde leest, haalt hooguit zo’n 5 tokens per seconde, nog voordat de berekening zelf meetelt.

Er zijn twee fasen te onderscheiden:

• Het lezen van de vraag (prompt processing) is rekenintensief: meer vCPU’s maken het sneller, wat telt voor lange documenten.
• Het genereren van het antwoord hangt vooral af van de geheugenbandbreedte en de grootte van het model: een model dat half zo groot is, antwoordt ongeveer twee keer zo snel.

In de praktijk produceert een model van 7 tot 8 miljard parameters, gekwantiseerd in 4 bits, op enkele vCPU’s een paar tokens per seconde. Dat is ruim voldoende voor achtergrondverwerking (berichten sorteren, velden uit een document halen, ’s nachts samenvatten wat er overdag binnenkwam) en voor een interne assistent. Interactief gebruik op grote schaal, en modellen van enkele tientallen miljarden parameters, draaien op een grafische kaart (GPU).

De meting geeft de doorslag: llama-bench, dat met llama.cpp wordt meegeleverd, geeft de snelheid van beide fasen op uw server, voor uw model.

llama-bench -m model-Q4_K_M.gguf -p 512 -n 128

De schijf: de modellen, hun versies, de vectoren

Een model neemt op schijf ongeveer evenveel ruimte in als in het geheugen: 5 GB voor een model van 8 miljard parameters in 4 bits. Reken op ruimte voor twee of drie modellen of versies, de vectorindexen, de brondocumenten en de database. Een NVMe-SSD laadt een model in enkele seconden bij het starten van de dienst, wat bij elke herstart telt.

Orde van grootte: 50 GB voor een applicatie die een model via een API aanroept, 80 tot 120 GB zodra een model en zijn documenten op de server staan.

De installatie, veilig opgezet

Met Ollama volstaan twee commando’s om te beginnen:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b

Ollama luistert standaard op 127.0.0.1:11434, dus alleen vanaf de server zelf. Houd die instelling aan: de API vraagt geen enkele authenticatie, en een instantie die openstaat voor internet bedient iedereen, op uw resources. Uw applicatie, op dezelfde server, praat er lokaal mee; moet een andere server het model bevragen, gebruik dan een proxy die de verzoeken authenticeert, of een privénetwerk.

Stel daarna de contextgrootte (num_ctx) in op wat uw verzoeken nodig hebben: die laat het ingenomen geheugen groeien, gesprek na gesprek.