Che hardware serve davvero per far girare l'AI sui documenti aziendali

La domanda arriva sempre nella stessa forma, e sempre nello stesso momento: qualcuno in azienda ha capito che si può far leggere a un'intelligenza artificiale i documenti interni senza mandarli fuori, la cosa piace, e subito dopo qualcuno chiede quanto costa il ferro.

La risposta onesta è che dipende, ma «dipende» non aiuta a chiudere un budget. Quindi proviamo a essere più utili: qui sotto ci sono gli ordini di grandezza, cosa cambia davvero all'aumentare delle risorse, e — soprattutto — come misurare il fabbisogno reale sui vostri documenti invece di fidarvi di una tabella trovata in rete, questa inclusa.

Le tre cose che consumano risorse, e non consumano allo stesso modo

In un sistema RAG ci sono tre lavori distinti, e confonderli è la causa più comune di dimensionamenti sbagliati.

L'indicizzazione avviene una volta per documento. Legge il file, ne estrae il testo, lo divide in blocchi e calcola gli embedding. È il lavoro che occupa il sistema quando caricate l'archivio storico, ed è quello che beneficia di più dalla GPU in modo lineare: raddoppiate la potenza, dimezzate l'attesa. È anche l'unico lavoro che, se una notte è lento, non se ne accorge nessuno.

Il recupero avviene a ogni domanda ed è quasi gratuito. Trasformare la domanda in vettore e cercare i passaggi più vicini nel database vettoriale è questione di millisecondi anche su archivi grandi, e dipende dalla RAM molto più che dalla GPU.

La generazione avviene a ogni domanda ed è la parte che l'utente percepisce come «lento» o «veloce». Qui la GPU non è un moltiplicatore: è la differenza fra una risposta che scorre mentre la leggi e una che ti fa aspettare guardando il cursore.

Da qui discende la regola pratica più utile di tutto l'articolo: se dovete scegliere dove mettere i soldi, metteteli dove sta la generazione. L'indicizzazione può aspettare la notte. Un utente davanti allo schermo no.

Senza GPU: quando ha senso e quando no

Ha senso in due casi. Il primo è la valutazione: volete capire se la qualità delle risposte sul vostro archivio è sufficiente prima di comprare qualcosa, e per quello la velocità è irrilevante. Il secondo è un uso davvero sporadico — poche domande al giorno, da poche persone, su un archivio contenuto.

Non ha senso quando il sistema deve entrare nel flusso di lavoro quotidiano di un ufficio. Non perché non funzioni, ma perché uno strumento che risponde lentamente viene abbandonato: le persone tornano a cercare a mano, e il progetto viene archiviato come fallito quando il problema era solo il ferro.

Un dettaglio operativo che vale la pena conoscere: su una macchina con GPU, una configurazione CUDA rotta fa ricadere silenziosamente il calcolo sulla CPU. Il sistema continua a funzionare, ma l'indicizzazione passa da secondi a minuti, e ci si accorge del problema settimane dopo. Nel motore Community esiste un'impostazione apposta, EMBEDDINGS__REQUIRE_GPU=true, che fa fallire l'avvio invece di degradare in silenzio. In produzione va messa.

Con GPU: cosa guardare

La cifra che conta è la VRAM, non i teraflops. Il modello linguistico dev'essere caricato in memoria video: se non ci sta, o gira parzialmente su CPU con un crollo delle prestazioni, o non parte affatto.

Un ordine di grandezza utile: un modello quantizzato nella fascia 7B–14B — che è la fascia giusta per rispondere su documenti propri — sta comodo in una GPU da 16 GB, insieme al modello di embedding che ne occupa una parte. Sotto i 12 GB si comincia a fare i conti con quanto contesto potete permettervi. Sopra i 24 GB avete margine per modelli più grandi o per servire più conversazioni insieme.

C'è un dettaglio di ordine di caricamento che spiega un problema altrimenti incomprensibile: il motore di inferenza dimensiona il proprio spazio in VRAM in base a quanta ne trova libera all'avvio. Per questo il modello di embedding va caricato prima di quello linguistico — altrimenti l'inferenza si prenota memoria che poi non c'è. Nel motore Community questo ordine è già imposto, ma se assemblate uno stack per conto vostro è esattamente il tipo di cosa che vi farà perdere un pomeriggio.

RAM e disco: meno drammatici, ma non trascurabili

Sedici gigabyte di RAM sono il minimo praticabile; con trentadue si sta comodi e il database vettoriale può tenere in memoria indici più grandi, che è ciò che mantiene il recupero istantaneo mano a mano che l'archivio cresce.

Sul disco la sorpresa più frequente riguarda il primo avvio. Il motore Community scarica circa dodici gigabyte fra modello linguistico, modello di embedding, database vettoriale, motore di inferenza e dati OCR, verificando ognuno contro uno sha256 dichiarato prima di usarlo. Non è un download che si fa in pausa caffè su una linea lenta, e va pianificato. Tutti gli avvii successivi sono immediati, perché un componente viene riscaricato solo se manca o se non supera la verifica.

Dopodiché lo spazio cresce con l'archivio: i documenti originali, i vettori e il database applicativo. Sono numeri modesti rispetto ai dodici gigabyte iniziali, ma vale la pena mettere la directory dei dati su un volume dedicato prima del primo avvio: spostarla dopo significa far ripartire tutti i download da zero, perché nel nuovo percorso non c'è ancora niente.

Il modo serio: misurare invece di stimare

Tutto quello che avete letto fin qui sono ordini di grandezza. Il vostro fabbisogno reale dipende da cose che nessuna tabella può sapere: quanto sono lunghi i vostri documenti, quanti sono scansionati e vanno passati all'OCR, quante persone faranno domande nella stessa ora.

Per questo il motore sa cronometrarsi da solo:

./i3k-rag-engine --bench /percorso/a/un/documento-vero.pdf

Produce un report in Markdown con i tempi di ogni fase — estrazione, suddivisione, embedding, scrittura sull'indice, prefill, decode — e i grafici di dove se ne va il tempo. Guardare quel report vi dice immediatamente se siete corti di GPU, corti di CPU, o se il collo di bottiglia è l'OCR e la GPU non c'entra niente.

C'è anche una modalità che registra una sessione reale, --bench-live, e produce il report alla chiusura: utile per capire il comportamento sotto un uso vero, non su un singolo file scelto bene.

Il consiglio pratico è banale ma quasi nessuno lo segue: fate il benchmark su un documento vostro, brutto e rappresentativo. Non sul PDF pulito da dieci pagine, ma sulla scansione storta da duecento pagine che rappresenta metà del vostro archivio. È quello il carico reale.

Un percorso di acquisto sensato

Se dovete arrivare a una decisione, questo ordine funziona quasi sempre:

1. Installate su quello che avete già, anche senza GPU. Serve solo a rispondere alla domanda che conta più di tutte: le risposte sui nostri documenti sono utili?
2. Fate girare il benchmark su documenti veri e rappresentativi. Ora avete numeri vostri.
3. Comprate la GPU sulla base di quei numeri, non su una tabella generica — questa inclusa.
4. Rimandate ogni ottimizzazione finché non avete un utente che si lamenta di qualcosa di specifico.

L'errore che vediamo più spesso è invertire i primi due passi con il terzo: comprare il ferro sulla base di un preventivo, e solo dopo scoprire se il caso d'uso reggeva. Il software si scarica gratis; la GPU no. Provarlo prima costa solo tempo.

In sintesi

• Il collo di bottiglia percepito è quasi sempre la generazione, quindi è lì che va la GPU.
• La VRAM conta più della potenza bruta: 16 GB sono un buon punto di partenza per la fascia di modelli adatta a questo compito.
• 16 GB di RAM sono il minimo, 32 GB il punto comodo.
• Mettete in conto circa 12 GB di download al primo avvio, e scegliete il volume dati prima di farlo.
• In produzione fate fallire l'avvio se la GPU non c'è, invece di scoprirlo dai tempi.
• E soprattutto: misurate sui vostri documenti. Il benchmark è dentro il binario, e ci vogliono dieci minuti.