Quale VPS per far girare un'IA: API o modello sul server

Due esigenze, due taglie di server

La maggior parte delle applicazioni che «usano l'IA» (assistenti, agenti, riassunti, estrazione di dati, ricerca nei documenti) chiama un modello ospitato dal suo fornitore, tramite un'API. Il calcolo avviene da lui; il vostro server prepara la richiesta, attende la risposta e la elabora. Si dimensiona quindi come qualsiasi applicazione web: in base al linguaggio, al database e al numero di utenti simultanei.

L'altro caso è il modello eseguito sul server stesso, con Ollama, llama.cpp o una libreria Python. Le ragioni sono note: dati che restano sulla vostra infrastruttura, un costo fisso qualunque sia il numero di richieste, un'elaborazione in background su grandi volumi, un modello specializzato. Qui il modello intero deve stare in memoria, ed è lui a decidere la taglia.

Tramite API: dimensionare l'applicazione, non il modello

Una richiesta a un modello tramite API dura da uno a diverse decine di secondi, soprattutto quando la risposta viene trasmessa man mano che si forma (streaming). In quel tempo, il vostro server non calcola quasi nulla: attende. Ciò che conta è la sua capacità di tenere molte richieste in attesa senza bloccare le altre:

• Un server asincrono: Node.js, FastAPI con Uvicorn, o worker Gunicorn asincroni. Un worker sincrono che attende una risposta di 20 secondi è un worker bloccato per tutti gli altri visitatori.
• Una coda di job per le elaborazioni lunghe (riassunto di un documento, analisi di un lotto): la richiesta del visitatore riceve subito risposta, e un worker elabora in background.
• Timeout regolati sul proxy: Nginx interrompe per impostazione predefinita una risposta che resta muta per più di 60 secondi (proxy_read_timeout).

La memoria da prevedere è quella dell'applicazione e del suo database: 4 GB coprono un'applicazione Python o Node.js con PostgreSQL al lancio. Una configurazione comune, un'interfaccia Next.js, un'API FastAPI e un database PostgreSQL che chiamano un modello tramite API, sta tra 6 e 8 GB, compilazione dell'interfaccia compresa.

Embedding e ricerca vettoriale: la memoria dei vettori

Un'applicazione che cerca nei vostri documenti (RAG, retrieval-augmented generation) trasforma ogni passaggio in un vettore, poi ritrova i più vicini a una domanda. Due voci da dimensionare:

• Il modello di embedding, se gira da voi: i modelli più diffusi pesano da 100 MB a 1,5 GB e calcolano su processore senza difficoltà. all-MiniLM-L6-v2, per esempio, occupa meno di 100 MB.
• I vettori: con pgvector, un vettore occupa 4 byte per dimensione, più 8. Un milione di passaggi a 1.536 dimensioni rappresentano circa 6 GB di dati, a cui si aggiunge l'indice HNSW che accelera la ricerca. Per ricerche rapide, l'indice e i vettori consultati devono stare in memoria.

Il tipo halfvec di pgvector memorizza ogni dimensione su 2 byte invece di 4: metà della memoria, per una qualità di ricerca che resta molto vicina.

Un modello sul server: prima di tutto la memoria

Un modello linguistico è un file di pesi, caricato per intero in memoria per rispondere. La sua dimensione dipende dal numero di parametri e dalla quantizzazione, la precisione con cui è memorizzato ogni peso. Il formato GGUF, quello di llama.cpp e di Ollama, propone quantizzazioni da 2 a 16 bit; la variante Q4_K_M, intorno ai 4 bit, è il compromesso più comune tra dimensione e qualità.

A questo peso si aggiungono due voci:

• Il contesto (la cache KV): ogni token della conversazione in corso occupa memoria. Per Llama 3.1 8B, contate circa 128 KB per token con precisione a 16 bit, cioè 1 GB per un contesto di 8.000 token, e altrettanto per ogni conversazione elaborata in parallelo.
• Il resto del server: sistema, applicazione, database, come per qualsiasi applicazione web.

Esempio. Llama 3.1 8B a 4 bit, due conversazioni simultanee da 8.000 token e una piccola applicazione: 5 GB di modello, 2 GB di contesto, 2 GB per l'applicazione e il sistema, cioè 9 GB, e circa 12 GB con il 25% di margine.

Su processore: che cosa decide la velocità

Per produrre ogni token, il modello rilegge l'insieme dei suoi pesi in memoria. Su processore, la velocità di generazione è quindi limitata dalla banda di memoria più che dal numero di core: un modello da 5 GB, su una macchina che legge 25 GB al secondo, si ferma intorno ai 5 token al secondo, prima ancora di contare il calcolo.

Si distinguono due fasi:

• La lettura della domanda (prompt processing) è un calcolo intensivo: più vCPU la rendono più rapida, e questo conta per i documenti lunghi.
• La generazione della risposta dipende soprattutto dalla banda di memoria e dalla dimensione del modello: un modello due volte più piccolo risponde circa due volte più velocemente.

In pratica, su qualche vCPU, un modello da 7 a 8 miliardi di parametri quantizzato a 4 bit produce qualche token al secondo. È comodo per un'elaborazione in background (classificare messaggi, estrarre campi da un documento, riassumere di notte ciò che è arrivato di giorno) e per un assistente interno. Gli usi interattivi su larga scala, e i modelli da diverse decine di miliardi di parametri, girano su scheda grafica (GPU).

La misura decide: llama-bench, fornito con llama.cpp, dà la velocità delle due fasi sul vostro server, per il vostro modello.

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

Il disco: i modelli, le loro versioni, i vettori

Un modello occupa su disco più o meno quanto occupa in memoria: 5 GB per un modello da 8 miliardi di parametri a 4 bit. Contate spazio per due o tre modelli o versioni, gli indici vettoriali, i documenti sorgente e il database. Un SSD NVMe carica un modello in pochi secondi all'avvio del servizio, e questo conta a ogni riavvio.

Ordine di grandezza: 50 GB per un'applicazione che chiama un modello tramite API, da 80 a 120 GB appena un modello e i suoi documenti vivono sul server.

La messa in opera, in sicurezza

Con Ollama, l'avvio sta in due comandi:

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

Ollama ascolta per impostazione predefinita su 127.0.0.1:11434, cioè solo dal server stesso. Mantenete questa impostazione: la sua API non richiede alcuna autenticazione, e un'istanza aperta su Internet serve chiunque, con le vostre risorse. La vostra applicazione, sullo stesso server, gli parla in locale; se un altro server deve interrogarlo, passate da un proxy che autentica le richieste o da una rete privata.

Regolate poi la dimensione del contesto (num_ctx) su ciò di cui le vostre richieste hanno bisogno: è lei a far crescere la memoria occupata, conversazione dopo conversazione.