Jaký VPS pro provoz AI: API, nebo model přímo na serveru

Dvě potřeby, dvě velikosti serveru

Většina aplikací, které „využívají AI“ (asistenti, agenti, shrnutí, extrakce dat, vyhledávání v dokumentech), volá model hostovaný jeho poskytovatelem přes API. Výpočet probíhá u něj; váš server připraví požadavek, počká na odpověď a zpracuje ji. Dimenzuje se proto jako kterákoli webová aplikace: podle jazyka, databáze a počtu souběžných uživatelů.

Druhým případem je model spuštěný přímo na serveru, s Ollamou, llama.cpp nebo knihovnou v Pythonu. Důvody jsou známé: data, která zůstávají na vaší infrastruktuře, pevné náklady bez ohledu na počet požadavků, zpracování velkých objemů na pozadí, specializovaný model. Tady se celý model musí vejít do paměti a velikost určuje právě on.

Přes API: dimenzovat aplikaci, ne model

Požadavek na model přes API trvá od jedné do několika desítek sekund, zvlášť když se odpověď posílá průběžně (streaming). Po tu dobu váš server skoro nic nepočítá: čeká. Rozhoduje jeho schopnost držet mnoho čekajících požadavků, aniž by blokoval ostatní:

• Asynchronní server: Node.js, FastAPI s Uvicornem nebo asynchronní workery Gunicornu. Synchronní worker, který 20 sekund čeká na odpověď, je worker zablokovaný pro všechny ostatní návštěvníky.
• Fronta úloh pro dlouhá zpracování (shrnutí dokumentu, analýza dávky): požadavek návštěvníka se vrátí okamžitě a worker úlohu zpracuje na pozadí.
• Nastavené časové limity na proxy: Nginx ve výchozím nastavení ukončí odpověď, která mlčí déle než 60 sekund (proxy_read_timeout).

Paměť se plánuje pro aplikaci a její databázi: 4 GB pokryjí aplikaci v Pythonu nebo Node.js s PostgreSQL v době spuštění. Běžná sestava, tedy rozhraní v Next.js, API ve FastAPI a databáze PostgreSQL, které volají model přes API, se vejde do 6 až 8 GB, včetně sestavení rozhraní.

Embeddingy a vektorové vyhledávání: paměť pro vektory

Aplikace, která vyhledává ve vašich dokumentech (RAG, retrieval-augmented generation), převede každou pasáž na vektor a pak k otázce vyhledá ty nejbližší. Dimenzovat je třeba dvě položky:

• Model pro embeddingy, pokud běží u vás: běžné modely mají 100 MB až 1,5 GB a na procesoru počítají bez potíží. Například all-MiniLM-L6-v2 zabírá méně než 100 MB.
• Vektory: v pgvector zabírá vektor 4 bajty na dimenzi plus 8 bajtů. Milion pasáží s 1 536 dimenzemi představuje zhruba 6 GB dat, k nimž se přidává index HNSW, který vyhledávání zrychluje. Pro rychlé vyhledávání se index a často čtené vektory musí vejít do paměti.

Typ halfvec v pgvector ukládá každou dimenzi do 2 bajtů místo 4: poloviční paměť při kvalitě vyhledávání, která zůstává velmi blízká.

Model na serveru: nejdřív paměť

Jazykový model je soubor vah, který se pro odpovídání celý načte do paměti. Jeho velikost závisí na počtu parametrů a na kvantizaci, tedy přesnosti, s jakou je každá váha uložena. Formát GGUF, který používají llama.cpp a Ollama, nabízí kvantizace od 2 do 16 bitů; varianta Q4_K_M, kolem 4 bitů, je běžným kompromisem mezi velikostí a kvalitou.

K těmto vahám se přidávají dvě položky:

• Kontext (KV cache): každý token probíhající konverzace zabírá paměť. U modelu Llama 3.1 8B počítejte zhruba se 128 kB na token při 16bitové přesnosti, tedy s 1 GB pro kontext o 8 000 tokenech, a stejně tolik na každou paralelně zpracovávanou konverzaci.
• Zbytek serveru: systém, aplikace, databáze, jako u každé webové aplikace.

Příklad. Llama 3.1 8B ve 4bitové kvantizaci, dvě souběžné konverzace po 8 000 tokenech a malá aplikace: 5 GB pro model, 2 GB pro kontext, 2 GB pro aplikaci a systém, celkem 9 GB, a s rezervou 25 % zhruba 12 GB.

Na procesoru: co určuje rychlost

Pro vytvoření každého tokenu model znovu přečte všechny své váhy v paměti. Na procesoru je rychlost generování proto omezena spíše propustností paměti než počtem jader: model o 5 GB na stroji, který čte 25 GB za sekundu, dosáhne nanejvýš zhruba 5 tokenů za sekundu, a to ještě před započtením samotného výpočtu.

Rozlišují se dvě fáze:

• Zpracování otázky (prompt processing) je náročný výpočet: více vCPU ho zrychlí, což je důležité u dlouhých dokumentů.
• Generování odpovědi závisí hlavně na propustnosti paměti a velikosti modelu: dvakrát menší model odpovídá zhruba dvakrát rychleji.

V praxi vytvoří model se 7 až 8 miliardami parametrů kvantizovaný na 4 bity na několika vCPU několik tokenů za sekundu. To pohodlně stačí pro zpracování na pozadí (třídění zpráv, extrakce polí z dokumentu, noční shrnutí toho, co přišlo během dne) i pro interního asistenta. Interaktivní použití ve velkém měřítku a modely s několika desítkami miliard parametrů běží na grafické kartě (GPU).

Rozhodne měření: llama-bench, dodávaný s llama.cpp, změří rychlost obou fází na vašem serveru a pro váš model.

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

Disk: modely, jejich verze, vektory

Model zabírá na disku zhruba tolik jako v paměti: 5 GB pro model s 8 miliardami parametrů ve 4bitové kvantizaci. Počítejte s místem pro dva nebo tři modely či verze, vektorové indexy, zdrojové dokumenty a databázi. SSD NVMe načte model během několika sekund při spuštění služby, což se projeví při každém restartu.

Řádově: 50 GB pro aplikaci, která volá model přes API, 80 až 120 GB, jakmile na serveru žije model a jeho dokumenty.

Bezpečné nasazení

S Ollamou se spuštění vejde do dvou příkazů:

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

Ollama ve výchozím nastavení naslouchá na 127.0.0.1:11434, tedy jen pro samotný server. Toto nastavení si ponechte: její API nevyžaduje žádné ověření a instance otevřená do internetu obslouží kohokoli, na vaše prostředky. Vaše aplikace na stejném serveru s ní komunikuje lokálně; pokud se na ni musí obracet jiný server, použijte proxy, která požadavky ověřuje, nebo privátní síť.

Pak nastavte velikost kontextu (num_ctx) podle toho, co vaše požadavky potřebují: právě ona zvětšuje obsazenou paměť, konverzaci po konverzaci.