Milyen VPS kell egy MI futtatásához: API vagy modell a szerveren

Két igény, két szerverméret

A legtöbb „MI-t használó” alkalmazás (asszisztensek, ágensek, összefoglalók, adatkinyerés, keresés dokumentumokban) a szolgáltatója által üzemeltetett modellt hívja meg, API-n keresztül. A számítás nála történik; az Ön szervere előkészíti a kérést, megvárja a választ, és feldolgozza. Ilyenkor úgy méretezendő, mint bármely webalkalmazás: a nyelve, az adatbázisa és az egyidejű felhasználók száma szerint.

A másik eset a magán a szerveren futtatott modell, Ollamával, llama.cpp-vel vagy egy Python-könyvtárral. Az okok ismertek: az adatok az Ön infrastruktúráján maradnak, a költség a kérések számától függetlenül rögzített, nagy mennyiségek háttérfeldolgozása, egy szakosodott modell. Ilyenkor a teljes modellnek el kell férnie a memóriában, és ez határozza meg a méretet.

API-n keresztül: az alkalmazást kell méretezni, nem a modellt

Egy API-n keresztüli modellhívás egy másodperctől több tíz másodpercig tart, különösen ha a válasz folyamatosan, darabonként érkezik (streaming). Ezalatt a szervere szinte semmit sem számol: vár. Az számít, hogy sok kérést tudjon várakoztatni anélkül, hogy a többit blokkolná:

• Aszinkron szerver: Node.js, FastAPI Uvicornnal, vagy aszinkron Gunicorn-workerek. Egy szinkron worker, amely 20 másodpercig vár egy válaszra, minden más látogató számára blokkolt worker.
• Feladatsor a hosszú feldolgozásokhoz (egy dokumentum összefoglalása, egy köteg elemzése): a látogató kérése azonnal visszatér, egy worker pedig a háttérben dolgozik.
• Beállított időkorlátok a proxyn: az Nginx alapértelmezés szerint megszakítja azt a választ, amely 60 másodpercnél tovább néma marad (proxy_read_timeout).

A tervezendő memória az alkalmazásé és az adatbázisáé: induláskor 4 GB lefed egy PostgreSQL-t használó Python- vagy Node.js-alkalmazást. Egy gyakori felállás, egy Next.js-felület, egy FastAPI-API és egy PostgreSQL-adatbázis, amelyek API-n keresztül hívnak egy modellt, 6 és 8 GB között elfér, a felület fordításával együtt.

Embeddingek és vektoros keresés: a vektorok memóriája

Az az alkalmazás, amely az Ön dokumentumaiban keres (RAG, retrieval-augmented generation), minden szövegrészt vektorrá alakít, majd megkeresi a kérdéshez legközelebb esőket. Két tételt kell méretezni:

• Az embeddingmodell, ha az Ön szerverén fut: a gyakori modellek mérete 100 MB és 1,5 GB között van, és gond nélkül számolnak processzoron. Az all-MiniLM-L6-v2 például kevesebb mint 100 MB-ot foglal.
• A vektorok: a pgvectorban egy vektor dimenziónként 4 bájtot foglal, plusz 8 bájtot. Egymillió szövegrész 1536 dimenzióban nagyjából 6 GB adatot jelent, amihez hozzáadódik a keresést gyorsító HNSW-index. A gyors kereséshez az indexnek és a lekérdezett vektoroknak el kell férniük a memóriában.

A pgvector halfvec típusa minden dimenziót 4 helyett 2 bájton tárol: feleannyi memória, nagyon hasonló keresési minőség mellett.

Modell a szerveren: először a memória

Egy nyelvi modell egy súlyokat tartalmazó fájl, amelyet a válaszadáshoz teljes egészében be kell tölteni a memóriába. Mérete a paraméterek számától és a kvantálástól függ, vagyis attól a pontosságtól, amellyel minden súlyt tárolnak. A GGUF formátum, a llama.cpp és az Ollama formátuma, 2 és 16 bit közötti kvantálásokat kínál; a nagyjából 4 bites Q4_K_M változat a szokásos kompromisszum a méret és a minőség között.

Ehhez a súlyhoz két további tétel adódik:

• A kontextus (a KV-gyorsítótár): a folyamatban lévő beszélgetés minden tokenje memóriát foglal. A Llama 3.1 8B esetében 16 bites pontosság mellett tokenenként nagyjából 128 kB-tal számoljon, azaz 1 GB-tal egy 8000 tokenes kontextusra, és ugyanennyivel minden párhuzamosan kezelt beszélgetésre.
• A szerver többi része: rendszer, alkalmazás, adatbázis, mint bármely webalkalmazásnál.

Példa. Llama 3.1 8B 4 biten, két egyidejű, 8000 tokenes beszélgetés és egy kis alkalmazás: 5 GB a modell, 2 GB a kontextus, 2 GB az alkalmazás és a rendszer, összesen 9 GB, 25% tartalékkal pedig nagyjából 12 GB.

Processzoron: mi határozza meg a sebességet

Minden token előállításához a modell újraolvassa a memóriából az összes súlyát. Processzoron a generálás sebességét ezért inkább a memória sávszélessége korlátozza, mint a magok száma: egy 5 GB-os modell egy másodpercenként 25 GB-ot olvasó gépen nagyjából másodpercenként 5 tokennél éri el a plafonját, még mielőtt a számítást figyelembe vennénk.

Két fázis különíthető el:

• A kérdés beolvasása (prompt processing) számításigényes: több vCPU gyorsítja, ami a hosszú dokumentumoknál számít.
• A válasz generálása főként a memória sávszélességétől és a modell méretétől függ: egy feleakkora modell nagyjából kétszer olyan gyorsan válaszol.

A gyakorlatban néhány vCPU-n egy 7 vagy 8 milliárd paraméteres, 4 bitre kvantált modell másodpercenként néhány tokent állít elő. Ez kényelmes háttérfeldolgozáshoz (üzenetek osztályozása, mezők kinyerése egy dokumentumból, a nap folyamán beérkezettek éjszakai összefoglalása) és belső asszisztenshez. A nagy léptékű interaktív felhasználás és a több tízmilliárd paraméteres modellek grafikus kártyán (GPU) futnak.

A mérés dönt: a llama.cpp-vel együtt szállított llama-bench megadja a két fázis sebességét az Ön szerverén, az Ön modelljével.

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

A lemez: a modellek, verzióik, a vektorok

Egy modell a lemezen nagyjából annyi helyet foglal, mint a memóriában: egy 4 bites, 8 milliárd paraméteres modell 5 GB-ot. Számoljon helyet két vagy három modellnek vagy verziónak, a vektorindexeknek, a forrásdokumentumoknak és az adatbázisnak. Egy NVMe SSD a szolgáltatás indulásakor néhány másodperc alatt betölti a modellt, ami minden újraindításkor számít.

Nagyságrendileg: 50 GB egy API-n keresztül modellt hívó alkalmazásnak, 80 és 120 GB között, amint egy modell és a dokumentumai a szerveren élnek.

A telepítés, biztonságosan

Az Ollamával az indulás két parancs:

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

Az Ollama alapértelmezés szerint a 127.0.0.1:11434 címen figyel, vagyis csak magáról a szerverről érhető el. Tartsa meg ezt a beállítást: az API-ja semmilyen hitelesítést nem kér, és egy internet felé nyitott példány bárkit kiszolgál, az Ön erőforrásain. Az Ön alkalmazása ugyanazon a szerveren helyben kommunikál vele; ha egy másik szervernek is el kell érnie, használjon olyan proxyt, amely hitelesíti a kéréseket, vagy egy privát hálózatot.

Ezután állítsa a kontextus méretét (num_ctx) arra, amire a kéréseinek szükségük van: ez növeli a foglalt memóriát, beszélgetésről beszélgetésre.