Hvilken VPS til at køre AI: API eller model på serveren

To behov, to serverstørrelser

De fleste applikationer, der «bruger AI» (assistenter, agenter, resuméer, dataudtræk, søgning i dokumenter), kalder en model, der hostes af udbyderen, via et API. Beregningen sker hos udbyderen; din server forbereder forespørgslen, venter på svaret og behandler det. Den dimensioneres da som enhver anden webapplikation: efter sit sprog, sin database og antallet af samtidige brugere.

Det andet tilfælde er modellen, der kører på selve serveren, med Ollama, llama.cpp eller et Python-bibliotek. Grundene er velkendte: data, der bliver på din infrastruktur, en fast omkostning uanset antallet af forespørgsler, baggrundsbehandling af store mængder, en specialiseret model. Her skal hele modellen kunne ligge i hukommelsen, og det er den, der bestemmer størrelsen.

Via API: dimensionér applikationen, ikke modellen

En forespørgsel til en model via API varer fra et til flere titals sekunder, især når svaret sendes løbende (streaming). I mellemtiden regner din server næsten ikke: den venter. Det, der tæller, er dens evne til at holde mange forespørgsler i venteposition uden at blokere de andre:

• En asynkron server: Node.js, FastAPI med Uvicorn eller asynkrone Gunicorn-workers. En synkron worker, der venter 20 sekunder på et svar, er en worker, der er blokeret for alle andre besøgende.
• En opgavekø til lange behandlinger (resumé af et dokument, analyse af et parti): den besøgendes forespørgsel får svar med det samme, og en worker behandler opgaven i baggrunden.
• Indstillede timeouts på proxyen: Nginx afbryder som standard et svar, der er tavst i mere end 60 sekunder (proxy_read_timeout).

Den hukommelse, du skal regne med, er applikationens og databasens: 4 GB dækker en Python- eller Node.js-applikation med PostgreSQL ved lanceringen. En almindelig opsætning, en Next.js-brugerflade, et FastAPI-API og en PostgreSQL-database, der kalder en model via API, kan være i 6 til 8 GB, kompilering af brugerfladen medregnet.

Embeddings og vektorsøgning: vektorernes hukommelse

En applikation, der søger i dine dokumenter (RAG, retrieval-augmented generation), omdanner hvert tekststykke til en vektor og finder derefter dem, der ligger tættest på et spørgsmål. To poster skal dimensioneres:

• Embeddingmodellen, hvis den kører hos dig: de gængse modeller vejer fra 100 MB til 1,5 GB og regner uden besvær på processor. all-MiniLM-L6-v2 fylder for eksempel under 100 MB.
• Vektorerne: med pgvector fylder en vektor 4 byte pr. dimension plus 8. En million tekststykker i 1.536 dimensioner svarer til omkring 6 GB data, hvortil kommer HNSW-indekset, der gør søgningen hurtigere. For at søgningerne går hurtigt, skal indekset og de vektorer, der søges i, kunne ligge i hukommelsen.

Typen halfvec i pgvector gemmer hver dimension på 2 byte i stedet for 4: halvdelen af hukommelsen, med en søgekvalitet, der forbliver meget tæt på.

En model på serveren: hukommelsen først

En sprogmodel er en fil med vægte, som indlæses i sin helhed i hukommelsen for at kunne svare. Dens størrelse afhænger af antallet af parametre og af kvantiseringen, den præcision, hver vægt gemmes med. GGUF-formatet, som llama.cpp og Ollama bruger, tilbyder kvantiseringer fra 2 til 16 bit; varianten Q4_K_M, omkring 4 bit, er det gængse kompromis mellem størrelse og kvalitet.

Oven i vægtene kommer to poster:

• Konteksten (KV-cachen): hvert token i den igangværende samtale fylder i hukommelsen. For Llama 3.1 8B skal du regne med omkring 128 KB pr. token ved 16-bit-præcision, det vil sige 1 GB for en kontekst på 8.000 tokens, og det samme igen for hver samtale, der behandles parallelt.
• Resten af serveren: system, applikation, database, som for enhver anden webapplikation.

Eksempel. Llama 3.1 8B i 4 bit, to samtidige samtaler på 8.000 tokens og en lille applikation: 5 GB model, 2 GB kontekst, 2 GB til applikationen og systemet, altså 9 GB, og omkring 12 GB med 25 % margin.

På processor: det, der bestemmer hastigheden

For at producere hvert token læser modellen alle sine vægte i hukommelsen igen. På processor er genereringshastigheden derfor begrænset af hukommelsesbåndbredden mere end af antallet af kerner: en model på 5 GB, på en maskine, der læser 25 GB i sekundet, når et loft på omkring 5 tokens i sekundet, før selve beregningen overhovedet er talt med.

To faser skiller sig ud:

• Indlæsningen af spørgsmålet (prompt processing) er en tung beregning: flere vCPU gør den hurtigere, hvilket tæller for lange dokumenter.
• Genereringen af svaret afhænger først og fremmest af hukommelsesbåndbredden og modellens størrelse: en model, der er halvt så stor, svarer omkring dobbelt så hurtigt.

I praksis producerer en model med 7 til 8 milliarder parametre, kvantiseret i 4 bit, nogle få tokens i sekundet på nogle få vCPU. Det er rigeligt til baggrundsbehandling (sortere beskeder, trække felter ud af et dokument, om natten opsummere det, der kom ind i løbet af dagen) og til en intern assistent. Interaktiv brug i stor skala og modeller med flere titals milliarder parametre kører på grafikkort (GPU).

Målingen afgør det: llama-bench, der følger med llama.cpp, giver hastigheden for de to faser på din server, for din model.

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

Disken: modellerne, deres versioner, vektorerne

En model fylder omtrent det samme på disken som i hukommelsen: 5 GB for en model med 8 milliarder parametre i 4 bit. Regn med plads til to eller tre modeller eller versioner, vektorindeksene, kildedokumenterne og databasen. En NVMe-SSD indlæser en model på få sekunder, når tjenesten starter, hvilket tæller ved hver genstart.

Størrelsesorden: 50 GB til en applikation, der kalder en model via API, og 80 til 120 GB, så snart en model og dens dokumenter ligger på serveren.

Opsætningen, på en sikker måde

Med Ollama klares opstarten med to kommandoer:

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

Ollama lytter som standard på 127.0.0.1:11434, det vil sige kun fra selve serveren. Behold den indstilling: dens API kræver ingen autentificering, og en instans, der er åben mod internettet, betjener hvem som helst på dine ressourcer. Din applikation på samme server taler med den lokalt; skal en anden server forespørge den, så gå gennem en proxy, der autentificerer forespørgslerne, eller gennem et privat netværk.

Indstil derefter kontekststørrelsen (num_ctx) til det, dine forespørgsler har brug for: det er den, der får den optagne hukommelse til at vokse, samtale for samtale.