Koji VPS za AI: API ili model na poslužitelju

Dvije potrebe, dvije veličine poslužitelja

Većina aplikacija koje „koriste AI” (asistenti, agenti, sažeci, izdvajanje podataka, pretraživanje dokumenata) poziva model koji hostira njegov izdavač, putem API-ja. Izračun se odvija kod njega; vaš poslužitelj priprema zahtjev, čeka odgovor i obrađuje ga. Tada se dimenzionira kao svaka web aplikacija: prema jeziku, bazi podataka i broju istovremenih korisnika.

Drugi je slučaj model koji radi na samom poslužitelju, uz Ollamu, llama.cpp ili neku Python biblioteku. Razlozi su poznati: podaci koji ostaju na vašoj infrastrukturi, fiksni trošak bez obzira na broj zahtjeva, pozadinska obrada velikih količina podataka, specijalizirani model. Tada cijeli model mora stati u memoriju, i on određuje veličinu.

Putem API-ja: dimenzionirajte aplikaciju, a ne model

Zahtjev modelu putem API-ja traje od jedne do nekoliko desetaka sekundi, osobito kada se odgovor šalje postupno (streaming). Za to vrijeme vaš poslužitelj gotovo ništa ne računa: čeka. Važna je njegova sposobnost da drži mnogo zahtjeva na čekanju, a da pritom ne blokira ostale:

• Asinkroni poslužitelj: Node.js, FastAPI s Uvicornom ili asinkroni Gunicorn workeri. Sinkroni worker koji 20 sekundi čeka odgovor worker je blokiran za sve ostale posjetitelje.
• Red zadataka za duge obrade (sažetak dokumenta, analiza skupa podataka): zahtjev posjetitelja odmah dobiva odgovor, a worker obrađuje u pozadini.
• Podešena vremena čekanja na proxyju: Nginx prema zadanim postavkama prekida odgovor koji ostane bez podataka dulje od 60 sekundi (proxy_read_timeout).

Potrebna memorija je ona aplikacije i njezine baze: 4 GB pokrivaju Python ili Node.js aplikaciju s PostgreSQL-om pri pokretanju. Uobičajena konfiguracija, Next.js sučelje, FastAPI API i PostgreSQL baza koji pozivaju model putem API-ja, staje u 6 do 8 GB, uključujući kompilaciju sučelja.

Embeddingi i vektorsko pretraživanje: memorija za vektore

Aplikacija koja pretražuje vaše dokumente (RAG, retrieval-augmented generation) pretvara svaki odlomak u vektor, a zatim pronalazi one najbliže pitanju. Dvije stavke treba dimenzionirati:

• Model za embeddinge, ako radi kod vas: uobičajeni modeli teže od 100 MB do 1,5 GB i bez poteškoća računaju na procesoru. all-MiniLM-L6-v2, primjerice, zauzima manje od 100 MB.
• Vektori: u pgvectoru vektor zauzima 4 bajta po dimenziji, plus 8. Milijun odlomaka u 1 536 dimenzija iznosi oko 6 GB podataka, čemu se dodaje HNSW indeks koji ubrzava pretraživanje. Za brza pretraživanja indeks i vektori koji se pretražuju moraju stati u memoriju.

Tip halfvec u pgvectoru sprema svaku dimenziju u 2 bajta umjesto 4: upola manje memorije, uz kvalitetu pretraživanja koja ostaje vrlo bliska.

Model na poslužitelju: najprije memorija

Jezični model je datoteka težina koja se za odgovaranje u cijelosti učitava u memoriju. Njegova veličina ovisi o broju parametara i o kvantizaciji, preciznosti s kojom je pohranjena svaka težina. Format GGUF, koji koriste llama.cpp i Ollama, nudi kvantizacije od 2 do 16 bitova; varijanta Q4_K_M, od oko 4 bita, uobičajen je kompromis između veličine i kvalitete.

Toj se težini dodaju dvije stavke:

• Kontekst (KV cache): svaki token tekućeg razgovora zauzima memoriju. Za Llama 3.1 8B računajte oko 128 KB po tokenu uz preciznost od 16 bitova, dakle 1 GB za kontekst od 8 000 tokena, i isto toliko za svaki razgovor koji se obrađuje usporedno.
• Ostatak poslužitelja: sustav, aplikacija, baza podataka, kao kod svake web aplikacije.

Primjer. Llama 3.1 8B uz 4 bita, dva istovremena razgovora od 8 000 tokena i mala aplikacija: 5 GB za model, 2 GB za kontekst, 2 GB za aplikaciju i sustav, ukupno 9 GB, a uz 25 % rezerve oko 12 GB.

Na procesoru: što određuje brzinu

Da bi proizveo svaki token, model iznova čita sve svoje težine iz memorije. Na procesoru je brzina generiranja stoga ograničena propusnošću memorije više nego brojem jezgri: model od 5 GB na stroju koji čita 25 GB u sekundi doseže najviše oko 5 tokena u sekundi, i prije nego što se uračuna sam izračun.

Razlikuju se dvije faze:

• Čitanje pitanja (prompt processing) intenzivan je izračun: više vCPU-a ga ubrzava, što je važno za duge dokumente.
• Generiranje odgovora ovisi prije svega o propusnosti memorije i veličini modela: dvostruko manji model odgovara otprilike dvostruko brže.

U praksi, na nekoliko vCPU-a, model od 7 do 8 milijardi parametara kvantiziran na 4 bita proizvodi nekoliko tokena u sekundi. To je ugodno za pozadinsku obradu (razvrstavanje poruka, izdvajanje polja iz dokumenta, noćno sažimanje onoga što je stiglo tijekom dana) i za internog asistenta. Interaktivna upotreba u velikom opsegu, kao i modeli od nekoliko desetaka milijardi parametara, izvode se na grafičkoj kartici (GPU).

Mjerenje presuđuje: llama-bench, koji dolazi uz llama.cpp, daje brzinu obiju faza na vašem poslužitelju, za vaš model.

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

Disk: modeli, njihove inačice, vektori

Model na disku zauzima otprilike onoliko koliko i u memoriji: 5 GB za model od 8 milijardi parametara uz 4 bita. Predvidite prostor za dva ili tri modela ili inačice, vektorske indekse, izvorne dokumente i bazu podataka. NVMe SSD učitava model za nekoliko sekundi pri pokretanju usluge, što je važno pri svakom ponovnom pokretanju.

Red veličine: 50 GB za aplikaciju koja poziva model putem API-ja, 80 do 120 GB čim model i njegovi dokumenti žive na poslužitelju.

Sigurno postavljanje

S Ollamom pokretanje staje u dvije naredbe:

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

Ollama prema zadanim postavkama sluša na 127.0.0.1:11434, odnosno prihvaća veze samo sa samog poslužitelja. Zadržite tu postavku: njezin API ne traži nikakvu autentifikaciju, a instanca otvorena prema internetu služi bilo koga, na vašim resursima. Vaša aplikacija, na istom poslužitelju, s njom razgovara lokalno; ako je mora pozivati neki drugi poslužitelj, koristite proxy koji autentificira zahtjeve ili privatnu mrežu.

Zatim veličinu konteksta (num_ctx) podesite prema onome što vašim zahtjevima treba: ona povećava zauzetu memoriju, razgovor po razgovor.