Vilken VPS för att köra AI: via API eller med en modell på servern

Två behov, två serverstorlekar

De flesta applikationer som ”använder AI” (assistenter, agenter, sammanfattningar, dataextraktion, sökning i dokument) anropar en modell som leverantören själv driftar, via ett API. Beräkningen sker hos leverantören; din server förbereder förfrågan, väntar på svaret och bearbetar det. Den dimensioneras då som vilken webbapplikation som helst: efter sitt språk, sin databas och antalet samtidiga användare.

Det andra fallet är en modell som körs på själva servern, med Ollama, llama.cpp eller ett Python-bibliotek. Skälen är välkända: data som stannar i din egen infrastruktur, en fast kostnad oavsett antalet förfrågningar, bakgrundsbearbetning av stora volymer, en specialiserad modell. Då måste hela modellen rymmas i minnet, och det är den som bestämmer storleken.

Via API: dimensionera applikationen, inte modellen

En förfrågan till en modell via API tar från en till flera tiotals sekunder, särskilt när svaret strömmas fram bit för bit (streaming). Under tiden räknar din server nästan ingenting: den väntar. Det som räknas är förmågan att hålla många förfrågningar väntande utan att blockera de andra:

• En asynkron server: Node.js, FastAPI med Uvicorn, eller asynkrona Gunicorn-workers. En synkron worker som väntar 20 sekunder på ett svar är en worker som är blockerad för alla andra besökare.
• En jobbkö för långa bearbetningar (sammanfattning av ett dokument, analys av en omgång): besökarens förfrågan får svar direkt, och en worker gör jobbet i bakgrunden.
• Inställda tidsgränser på proxyn: som standard avbryter Nginx ett svar som är tyst i mer än 60 sekunder (proxy_read_timeout).

Minnet att planera för är applikationens och databasens: 4 GB räcker för en Python- eller Node.js-applikation med PostgreSQL vid lanseringen. En vanlig uppsättning, ett Next.js-gränssnitt, ett FastAPI-API och en PostgreSQL-databas som anropar en modell via API, ryms i 6 till 8 GB, kompileringen av gränssnittet inräknad.

Embeddings och vektorsökning: minnet för vektorerna

En applikation som söker i dina dokument (RAG, retrieval-augmented generation) omvandlar varje textavsnitt till en vektor och hittar sedan de avsnitt som ligger närmast en fråga. Två poster att dimensionera:

• Embedding-modellen, om den körs hos dig: vanliga modeller väger från 100 MB till 1,5 GB och räknar på processor utan svårighet. all-MiniLM-L6-v2 tar till exempel mindre än 100 MB.
• Vektorerna: med pgvector tar en vektor 4 byte per dimension, plus 8. En miljon textavsnitt med 1 536 dimensioner motsvarar omkring 6 GB data, och till det kommer HNSW-indexet som snabbar upp sökningen. För snabba sökningar måste indexet och de vektorer som efterfrågas rymmas i minnet.

Typen halfvec i pgvector lagrar varje dimension på 2 byte i stället för 4: halva minnet, med en sökkvalitet som ligger mycket nära.

En modell på servern: minnet först

En språkmodell är en fil med vikter som laddas helt i minnet för att kunna svara. Dess storlek beror på antalet parametrar och på kvantiseringen, den precision som varje vikt lagras med. GGUF-formatet, som llama.cpp och Ollama använder, erbjuder kvantiseringar från 2 till 16 bitar; varianten Q4_K_M, runt 4 bitar, är den vanliga kompromissen mellan storlek och kvalitet.

Utöver vikterna tillkommer två poster:

• Kontexten (KV-cachen): varje token i den pågående konversationen tar minne. För Llama 3.1 8B räknar du med omkring 128 kB per token med 16-bitars precision, alltså 1 GB för en kontext på 8 000 tokens, och lika mycket för varje konversation som hanteras parallellt.
• Resten av servern: system, applikation, databas, som för vilken webbapplikation som helst.

Exempel. Llama 3.1 8B med 4 bitar, två samtidiga konversationer på 8 000 tokens och en liten applikation: 5 GB för modellen, 2 GB för kontexten, 2 GB för applikationen och systemet, totalt 9 GB, och omkring 12 GB med 25 % marginal.

På processor: det som bestämmer hastigheten

För att producera varje token läser modellen igenom alla sina vikter i minnet. På processor begränsas genereringshastigheten därför av minnesbandbredden mer än av antalet kärnor: en modell på 5 GB, på en maskin som läser 25 GB per sekund, stannar runt 5 tokens per sekund, redan innan själva beräkningen räknas in.

Två faser skiljer sig åt:

• Läsningen av frågan (prompt processing) är beräkningsintensiv: fler vCPU gör den snabbare, vilket spelar roll för långa dokument.
• Genereringen av svaret beror främst på minnesbandbredden och modellens storlek: en modell som är hälften så stor svarar ungefär dubbelt så snabbt.

I praktiken producerar en modell med 7 till 8 miljarder parametrar, kvantiserad till 4 bitar, några tokens per sekund på några vCPU. Det räcker gott för bakgrundsbearbetning (sortera meddelanden, extrahera fält ur ett dokument, under natten sammanfatta det som kommit in under dagen) och för en intern assistent. Interaktiv användning i stor skala, och modeller med flera tiotals miljarder parametrar, körs på grafikkort (GPU).

Mätningen avgör: llama-bench, som följer med llama.cpp, ger hastigheten för båda faserna på din server, för din modell.

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

Disken: modellerna, deras versioner, vektorerna

En modell tar ungefär lika mycket plats på disk som i minnet: 5 GB för en modell med 8 miljarder parametrar i 4 bitar. Räkna med plats för två eller tre modeller eller versioner, vektorindexen, källdokumenten och databasen. En NVMe-SSD laddar en modell på några sekunder när tjänsten startar, vilket märks vid varje omstart.

Storleksordning: 50 GB för en applikation som anropar en modell via API, 80 till 120 GB så snart en modell och dess dokument finns på servern.

Driftsättningen, på ett säkert sätt

Med Ollama räcker två kommandon för att komma i gång:

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

Ollama lyssnar som standard på 127.0.0.1:11434, det vill säga bara från själva servern. Behåll den inställningen: dess API kräver ingen autentisering, och en instans som är öppen mot internet betjänar vem som helst, med dina resurser. Din applikation, på samma server, talar med den lokalt; om en annan server behöver fråga den går du via en proxy som autentiserar förfrågningarna eller via ett privat nätverk.

Ställ sedan in kontextens storlek (num_ctx) efter vad dina förfrågningar behöver: det är den som får det använda minnet att växa, konversation för konversation.