Aký VPS na spustenie AI: API alebo model na serveri

Dve potreby, dve veľkosti servera

Väčšina aplikácií, ktoré „používajú AI“ (asistenti, agenti, zhrnutia, extrakcia údajov, vyhľadávanie v dokumentoch), volá model hostovaný jeho vydavateľom, cez API. Výpočet prebieha u neho; váš server pripraví požiadavku, čaká na odpoveď a spracuje ju. Dimenzuje sa teda ako ktorákoľvek webová aplikácia: podľa jazyka, databázy a počtu súčasných používateľov.

Druhým prípadom je model spustený priamo na serveri, s Ollamou, llama.cpp alebo knižnicou v Pythone. Dôvody sú známe: údaje, ktoré zostávajú na vašej infraštruktúre, pevné náklady bez ohľadu na počet požiadaviek, spracovanie veľkých objemov na pozadí, špecializovaný model. Tu sa celý model musí zmestiť do pamäte a veľkosť určuje práve on.

Cez API: dimenzovať aplikáciu, nie model

Požiadavka na model cez API trvá od jednej do niekoľkých desiatok sekúnd, najmä keď sa odpoveď posiela priebežne (streaming). Počas tejto doby váš server takmer nič nepočíta: čaká. Rozhoduje jeho schopnosť držať mnoho čakajúcich požiadaviek bez toho, aby blokoval ostatné:

• Asynchrónny server: Node.js, FastAPI s Uvicornom alebo asynchrónne workery Gunicorn. Synchrónny worker, ktorý čaká 20 sekúnd na odpoveď, je worker zablokovaný pre všetkých ostatných návštevníkov.
• Front úloh pre dlhé spracovania (zhrnutie dokumentu, analýza dávky): požiadavka návštevníka sa vráti okamžite a worker úlohu spracuje na pozadí.
• Nastavené časové limity na proxy: Nginx predvolene preruší odpoveď, ktorá mlčí dlhšie ako 60 sekúnd (proxy_read_timeout).

Pamäť treba naplánovať pre aplikáciu a jej databázu: 4 GB pokryjú aplikáciu v Pythone alebo Node.js s PostgreSQL pri spustení. Bežná zostava, rozhranie v Next.js, API vo FastAPI a databáza PostgreSQL, ktoré volajú model cez API, sa zmestí do 6 až 8 GB, vrátane kompilácie rozhrania.

Embeddingy a vektorové vyhľadávanie: pamäť pre vektory

Aplikácia, ktorá vyhľadáva vo vašich dokumentoch (RAG, retrieval-augmented generation), premení každú pasáž na vektor a potom nájde tie, ktoré sú otázke najbližšie. Dimenzovať treba dve položky:

• Model pre embeddingy, ak beží u vás: bežné modely majú od 100 MB do 1,5 GB a na procesore počítajú bez problémov. Napríklad all-MiniLM-L6-v2 zaberá menej ako 100 MB.
• Vektory: v pgvector zaberá vektor 4 bajty na dimenziu, plus 8. Milión pasáží s 1 536 dimenziami predstavuje približne 6 GB údajov, ku ktorým sa pridá index HNSW, ktorý zrýchľuje vyhľadávanie. Pri rýchlom vyhľadávaní sa index a čítané vektory musia zmestiť do pamäte.

Typ halfvec v pgvector ukladá každú dimenziu na 2 bajty namiesto 4: polovica pamäte pri kvalite vyhľadávania, ktorá zostáva veľmi blízka.

Model na serveri: najprv pamäť

Jazykový model je súbor váh, ktorý sa pri odpovedaní celý načíta do pamäte. Jeho veľkosť závisí od počtu parametrov a od kvantizácie, teda presnosti, s akou je uložená každá váha. Formát GGUF, ktorý používajú llama.cpp a Ollama, ponúka kvantizácie od 2 do 16 bitov; variant Q4_K_M, približne 4 bity, je bežným kompromisom medzi veľkosťou a kvalitou.

K veľkosti modelu sa pridávajú ďalšie dve položky:

• Kontext (KV cache): každý token prebiehajúcej konverzácie zaberá pamäť. Pri Llama 3.1 8B počítajte približne 128 KB na token pri 16-bitovej presnosti, teda 1 GB pre kontext s 8 000 tokenmi, a rovnako veľa pre každú paralelne spracúvanú konverzáciu.
• Zvyšok servera: systém, aplikácia, databáza, ako pri každej webovej aplikácii.

Príklad. Llama 3.1 8B v 4 bitoch, dve súčasné konverzácie s 8 000 tokenmi a malá aplikácia: 5 GB model, 2 GB kontext, 2 GB aplikácia a systém, spolu 9 GB, a s 25 % rezervou približne 12 GB.

Na procesore: čo určuje rýchlosť

Pri tvorbe každého tokenu model znova prečíta všetky svoje váhy z pamäte. Na procesore je preto rýchlosť generovania obmedzená skôr priepustnosťou pamäte než počtom jadier: model s veľkosťou 5 GB na stroji, ktorý číta 25 GB za sekundu, dosiahne strop okolo 5 tokenov za sekundu, a to ešte pred započítaním samotného výpočtu.

Rozlišujú sa dve fázy:

• Čítanie otázky (prompt processing) je výpočtovo náročné: viac vCPU ho zrýchli, čo je dôležité pri dlhých dokumentoch.
• Generovanie odpovede závisí najmä od priepustnosti pamäte a veľkosti modelu: dvakrát menší model odpovedá približne dvakrát rýchlejšie.

V praxi model so 7 až 8 miliardami parametrov kvantizovaný na 4 bity vytvorí na niekoľkých vCPU niekoľko tokenov za sekundu. To pohodlne stačí na spracovanie na pozadí (triedenie správ, extrakcia polí z dokumentu, nočné zhrnutie toho, čo prišlo cez deň) a na interného asistenta. Interaktívne použitie vo veľkom rozsahu a modely s niekoľkými desiatkami miliárd parametrov bežia na grafických kartách (GPU).

Rozhodne meranie: llama-bench, ktorý je súčasťou llama.cpp, udáva rýchlosť oboch fáz na vašom serveri a pre váš model.

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

Disk: modely, ich verzie, vektory

Model zaberá na disku približne toľko ako v pamäti: 5 GB pre model s 8 miliardami parametrov v 4 bitoch. Počítajte s miestom pre dva alebo tri modely či verzie, vektorové indexy, zdrojové dokumenty a databázu. SSD NVMe načíta model za niekoľko sekúnd pri štarte služby, čo sa prejaví pri každom reštarte.

Rádovo: 50 GB pre aplikáciu, ktorá volá model cez API, 80 až 120 GB, len čo na serveri žije model a jeho dokumenty.

Bezpečné nastavenie

S Ollamou zvládnete spustenie dvoma príkazmi:

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

Ollama predvolene počúva na 127.0.0.1:11434, teda len zo samotného servera. Toto nastavenie si ponechajte: jej API nevyžaduje žiadnu autentifikáciu a inštancia otvorená do internetu obslúži kohokoľvek, na vaše prostriedky. Vaša aplikácia na tom istom serveri s ňou komunikuje lokálne; ak ju má dopytovať iný server, použite proxy, ktorá požiadavky overuje, alebo privátnu sieť.

Potom nastavte veľkosť kontextu (num_ctx) podľa toho, čo vaše požiadavky potrebujú: práve ona zväčšuje obsadenú pamäť, konverzáciu po konverzácii.