Kakšen VPS za umetno inteligenco: API ali model na strežniku

Dve potrebi, dve velikosti strežnika

Večina aplikacij, ki „uporabljajo umetno inteligenco“ (asistenti, agenti, povzetki, pridobivanje podatkov, iskanje po dokumentih), prek API-ja kliče model, ki ga gosti njegov ponudnik. Računanje poteka pri njem; vaš strežnik pripravi zahtevo, počaka na odgovor in ga obdela. Dimenzionira se torej kot vsaka spletna aplikacija: po jeziku, podatkovni zbirki in številu sočasnih uporabnikov.

Drugi primer je model, ki teče na samem strežniku, z Ollamo, llama.cpp ali knjižnico v Pythonu. Razlogi so znani: podatki, ki ostanejo v vaši infrastrukturi, stalen strošek ne glede na število zahtev, obdelava velikih količin v ozadju, specializiran model. Tedaj mora biti v pomnilniku celoten model, in prav on določi velikost.

Prek API-ja: dimenzionirajte aplikacijo, ne modela

Zahteva modelu prek API-ja traja od ene do več deset sekund, zlasti kadar se odgovor pretaka sproti (streaming). Ves ta čas vaš strežnik skoraj nič ne računa: čaka. Šteje njegova zmožnost, da hkrati drži veliko zahtev na čakanju, ne da bi blokiral druge:

• Asinhroni strežnik: Node.js, FastAPI z Uvicornom ali asinhroni delovni procesi Gunicorn. Sinhroni delovni proces, ki 20 sekund čaka na odgovor, je delovni proces, blokiran za vse druge obiskovalce.
• Čakalna vrsta opravil za dolge obdelave (povzetek dokumenta, analiza paketa podatkov): zahteva obiskovalca se takoj vrne, delovni proces pa obdeluje v ozadju.
• Nastavljene časovne omejitve na posredniškem strežniku (proxy): Nginx privzeto prekine odgovor, ki ostane nem več kot 60 sekund (proxy_read_timeout).

Potreben pomnilnik je pomnilnik aplikacije in njene podatkovne zbirke: 4 GB ob zagonu pokrijejo aplikacijo v Pythonu ali Node.js s PostgreSQL. Pogosta postavitev, vmesnik Next.js, API FastAPI in podatkovna zbirka PostgreSQL, ki model kličejo prek API-ja, se prilega v 6 do 8 GB, vključno s prevajanjem vmesnika.

Vložitve in vektorsko iskanje: pomnilnik vektorjev

Aplikacija, ki išče po vaših dokumentih (RAG, retrieval-augmented generation), vsak odlomek pretvori v vektor, nato pa poišče tiste, ki so vprašanju najbližji. Dimenzionirati je treba dve postavki:

• Model za vložitve, če teče pri vas: pogosti modeli tehtajo od 100 MB do 1,5 GB in brez težav računajo na procesorju. all-MiniLM-L6-v2 na primer zasede manj kot 100 MB.
• Vektorji: s pgvector vektor zasede 4 bajte na dimenzijo, plus 8. Milijon odlomkov s 1536 dimenzijami pomeni približno 6 GB podatkov, ki se jim doda še indeks HNSW, ki pospeši iskanje. Za hitro iskanje morajo biti indeks in brani vektorji v pomnilniku.

Tip halfvec v pgvector vsako dimenzijo shrani v 2 bajta namesto v 4: polovica pomnilnika, pri kakovosti iskanja, ki ostane zelo blizu.

Model na strežniku: najprej pomnilnik

Jezikovni model je datoteka uteži, ki se za odgovarjanje v celoti naloži v pomnilnik. Njegova velikost je odvisna od števila parametrov in od kvantizacije, natančnosti, s katero je shranjena vsaka utež. Format GGUF, ki ga uporabljata llama.cpp in Ollama, ponuja kvantizacije od 2 do 16 bitov; različica Q4_K_M, okoli 4 bitov, je običajen kompromis med velikostjo in kakovostjo.

Tej velikosti se dodata dve postavki:

• Kontekst (predpomnilnik KV): vsak žeton tekočega pogovora zasede pomnilnik. Za Llama 3.1 8B računajte približno 128 kB na žeton pri 16-bitni natančnosti, torej 1 GB za kontekst z 8000 žetoni, in prav toliko za vsak pogovor, obdelan vzporedno.
• Preostanek strežnika: sistem, aplikacija, podatkovna zbirka, kot pri vsaki spletni aplikaciji.

Primer. Llama 3.1 8B pri 4 bitih, dva sočasna pogovora po 8000 žetonov in manjša aplikacija: 5 GB za model, 2 GB za kontekst, 2 GB za aplikacijo in sistem, skupaj 9 GB, s 25 % rezerve pa približno 12 GB.

Na procesorju: kaj določa hitrost

Za vsak izdelan žeton model znova prebere vse svoje uteži v pomnilniku. Na procesorju je hitrost generiranja zato omejena bolj s pasovno širino pomnilnika kot s številom jeder: model s 5 GB na stroju, ki bere 25 GB na sekundo, doseže zgornjo mejo okoli 5 žetonov na sekundo, še preden upoštevamo računanje.

Ločimo dve fazi:

• Branje vprašanja (prompt processing) je računsko zahtevno: več vCPU ga pospeši, kar šteje pri dolgih dokumentih.
• Generiranje odgovora je odvisno predvsem od pasovne širine pomnilnika in velikosti modela: dvakrat manjši model odgovarja približno dvakrat hitreje.

V praksi na nekaj vCPU model s 7 do 8 milijardami parametrov, kvantiziran na 4 bite, izdela nekaj žetonov na sekundo. To je udobno za obdelavo v ozadju (razvrščanje sporočil, pridobivanje polj iz dokumenta, ponočni povzetek tega, kar je prispelo čez dan) in za notranjega asistenta. Interaktivna raba v velikem obsegu in modeli z več deset milijardami parametrov tečejo na grafični kartici (GPU).

Odloči meritev: llama-bench, ki je priložen llama.cpp, poda hitrost obeh faz na vašem strežniku, za vaš model.

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

Disk: modeli, njihove različice, vektorji

Model na disku zasede približno toliko kot v pomnilniku: 5 GB za model z 8 milijardami parametrov pri 4 bitih. Računajte s prostorom za dva ali tri modele ali različice, vektorske indekse, izvorne dokumente in podatkovno zbirko. NVMe SSD model ob zagonu storitve naloži v nekaj sekundah, kar šteje ob vsakem ponovnem zagonu.

Red velikosti: 50 GB za aplikacijo, ki model kliče prek API-ja, od 80 do 120 GB, takoj ko model in njegovi dokumenti živijo na strežniku.

Varna namestitev

Z Ollamo zagon zahteva dva ukaza:

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

Ollama privzeto posluša na 127.0.0.1:11434, torej samo s samega strežnika. To nastavitev obdržite: njen API ne zahteva nobene overitve, in primerek, odprt v internet, streže komur koli, na vaših virih. Vaša aplikacija na istem strežniku z njo govori lokalno; če mora do nje dostopati drug strežnik, uporabite posredniški strežnik, ki overja zahteve, ali zasebno omrežje.

Nato velikost konteksta (num_ctx) nastavite na to, kar vaše zahteve potrebujejo: prav ta veča porabo pomnilnika, pogovor za pogovorom.