Ce VPS vă trebuie pentru AI: API sau model rulat pe server

Două nevoi, două dimensiuni de server

Cele mai multe aplicații care „folosesc AI” (asistenți, agenți, rezumate, extragere de date, căutare în documente) apelează un model găzduit de furnizorul său, printr-un API. Calculul se face la furnizor; serverul dumneavoastră pregătește cererea, așteaptă răspunsul și îl prelucrează. El se dimensionează atunci ca orice aplicație web: după limbaj, baza de date și numărul de utilizatori simultani.

Celălalt caz este modelul rulat pe serverul însuși, cu Ollama, llama.cpp sau o bibliotecă Python. Motivele sunt cunoscute: date care rămân pe infrastructura dumneavoastră, un cost fix indiferent de numărul de cereri, o procesare în fundal pe volume mari, un model specializat. Aici, întregul model trebuie să încapă în memorie, iar el stabilește dimensiunea.

Prin API: dimensionați aplicația, nu modelul

O cerere către un model prin API durează de la o secundă la câteva zeci de secunde, mai ales când răspunsul este transmis pe măsură ce se generează (streaming). În acest timp, serverul dumneavoastră aproape nu calculează nimic: așteaptă. Ceea ce contează este capacitatea lui de a ține numeroase cereri în așteptare fără să le blocheze pe celelalte:

• Un server asincron: Node.js, FastAPI cu Uvicorn sau workeri Gunicorn asincroni. Un worker sincron care așteaptă un răspuns de 20 de secunde este un worker blocat pentru toți ceilalți vizitatori.
• O coadă de sarcini pentru procesările lungi (rezumatul unui document, analiza unui lot): cererea vizitatorului primește răspuns imediat, iar un worker lucrează în fundal.
• Timpi de expirare reglați pe proxy: implicit, Nginx întrerupe un răspuns care rămâne mut mai mult de 60 de secunde (proxy_read_timeout).

Memoria necesară este cea a aplicației și a bazei ei de date: 4 GB acoperă o aplicație Python sau Node.js cu PostgreSQL la lansare. O configurație obișnuită (o interfață Next.js, un API FastAPI și o bază PostgreSQL, cu un model apelat prin API) încape în 6 până la 8 GB, inclusiv compilarea interfeței.

Embeddinguri și căutare vectorială: memoria vectorilor

O aplicație care caută în documentele dumneavoastră (RAG, retrieval-augmented generation) transformă fiecare pasaj într-un vector, apoi îi regăsește pe cei mai apropiați de o întrebare. Două elemente de dimensionat:

• Modelul de embeddinguri, dacă rulează la dumneavoastră: modelele uzuale cântăresc între 100 MB și 1,5 GB și calculează pe procesor fără dificultate. all-MiniLM-L6-v2, de exemplu, ocupă mai puțin de 100 MB.
• Vectorii: cu pgvector, un vector ocupă 4 octeți pe dimensiune, plus 8. Un milion de pasaje cu 1.536 de dimensiuni reprezintă aproximativ 6 GB de date, la care se adaugă indexul HNSW care accelerează căutarea. Pentru căutări rapide, indexul și vectorii consultați trebuie să încapă în memorie.

Tipul halfvec din pgvector stochează fiecare dimensiune pe 2 octeți în loc de 4: jumătate din memorie, pentru o calitate a căutării care rămâne foarte apropiată.

Un model pe server: mai întâi memoria

Un model de limbaj este un fișier de ponderi, încărcat integral în memorie pentru a răspunde. Dimensiunea lui depinde de numărul de parametri și de cuantizare, precizia cu care este stocată fiecare pondere. Formatul GGUF, cel folosit de llama.cpp și de Ollama, propune cuantizări de la 2 la 16 biți; varianta Q4_K_M, în jur de 4 biți, este compromisul obișnuit între dimensiune și calitate.

La această greutate se adaugă două elemente:

• Contextul (cache-ul KV): fiecare token al conversației în curs ocupă memorie. Pentru Llama 3.1 8B, socotiți aproximativ 128 KB pe token la precizie de 16 biți, adică 1 GB pentru un context de 8.000 de tokenuri, și tot atât pentru fiecare conversație procesată în paralel.
• Restul serverului: sistemul, aplicația, baza de date, ca pentru orice aplicație web.

Exemplu. Llama 3.1 8B pe 4 biți, două conversații simultane de 8.000 de tokenuri și o aplicație mică: 5 GB pentru model, 2 GB pentru context, 2 GB pentru aplicație și sistem, adică 9 GB, și aproximativ 12 GB cu o marjă de 25%.

Pe procesor: ce stabilește viteza

Pentru a produce fiecare token, modelul recitește toate ponderile din memorie. Pe procesor, viteza de generare este deci limitată de lățimea de bandă a memoriei mai mult decât de numărul de nuclee: un model de 5 GB, pe o mașină care citește 25 GB pe secundă, atinge un plafon în jur de 5 tokenuri pe secundă, înainte chiar de a socoti calculul.

Se disting două faze:

• Citirea întrebării (prompt processing) este un calcul intensiv: mai multe vCPU o fac mai rapidă, ceea ce contează pentru documentele lungi.
• Generarea răspunsului depinde mai ales de lățimea de bandă a memoriei și de dimensiunea modelului: un model de două ori mai mic răspunde cam de două ori mai repede.

În practică, pe câteva vCPU, un model cu 7 până la 8 miliarde de parametri, cuantizat pe 4 biți, produce câteva tokenuri pe secundă. Este confortabil pentru o procesare în fundal (clasificarea mesajelor, extragerea câmpurilor dintr-un document, rezumarea peste noapte a ceea ce a sosit în timpul zilei) și pentru un asistent intern. Utilizările interactive la scară mare și modelele cu câteva zeci de miliarde de parametri rulează pe placă grafică (GPU).

Măsurarea decide: llama-bench, livrat cu llama.cpp, dă viteza celor două faze pe serverul dumneavoastră, pentru modelul dumneavoastră.

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

Discul: modelele, versiunile lor, vectorii

Un model ocupă pe disc cam cât ocupă în memorie: 5 GB pentru un model cu 8 miliarde de parametri pe 4 biți. Socotiți loc pentru două sau trei modele sau versiuni, indecșii vectoriali, documentele sursă și baza de date. Un SSD NVMe încarcă un model în câteva secunde la pornirea serviciului, ceea ce contează la fiecare repornire.

Ordin de mărime: 50 GB pentru o aplicație care apelează un model prin API, între 80 și 120 GB de îndată ce un model și documentele lui se află pe server.

Punerea în funcțiune, în siguranță

Cu Ollama, pornirea încape în două comenzi:

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

Implicit, Ollama ascultă pe 127.0.0.1:11434, adică doar de pe serverul însuși. Păstrați această setare: API-ul său nu cere nicio autentificare, iar o instanță deschisă spre Internet servește pe oricine, pe resursele dumneavoastră. Aplicația dumneavoastră, pe același server, comunică local cu el; dacă un alt server trebuie să îl interogheze, treceți printr-un proxy care autentifică cererile sau printr-o rețea privată.

Reglați apoi dimensiunea contextului (num_ctx) după nevoile cererilor dumneavoastră: ea face să crească memoria ocupată, conversație după conversație.