Server e hardware

Intric distribuisce la piattaforma su Kubernetes tramite Helm chart con versioni. Se non usi già Kubernetes (le chart richiedono la versione 1.29 o successiva; scegli una versione che il progetto supporta ancora), installiamo k3s, una distribuzione Kubernetes leggera, su una VM Linux che fornisci tu. Ciò che serve alla VM dipende da quali parti della piattaforma esegui nel tuo ambiente e quali usi come servizio di Intric.

Scegli lo scenario

Scenario	In esecuzione nel tuo ambiente	Usato come servizio	Hardware
1. Piattaforma	App web, API, database, indice di ricerca, object storage	Elaborazione (PDF/OCR, acquisizione dei documenti, trascrizione) e tutti i modelli di AI	Una VM, 4–8 core
2. Piattaforma + elaborazione	Scenario 1, più i worker di elaborazione per PDF/OCR, acquisizione dei documenti e trascrizione audio, che girano su CPU	Modelli di AI che richiedono una GPU: modelli linguistici, embedding, speech-to-text, modello di immagine	Una VM, ~20–72 core
3. Completamente locale	Scenario 2, più tutti i modelli di AI sui tuoi server GPU: modelli linguistici, embedding, speech-to-text e modello di immagine	Niente	La VM dello scenario 2, più uno o più server GPU

Scegli lo scenario che i tuoi requisiti sul trattamento dei dati richiedono davvero, non il più grande.

Da dove vengono i numeri. CPU e memoria sono le prenotazioni (Kubernetes requests) delle nostre Helm chart, sommate per scenario, più un margine. Non sono risultati di test di carico. Le cifre GPU sono indicate come misurate dove usiamo la configurazione in produzione e come stimate dove le abbiamo calcolate. Parti dal livello suggerito, osserva l’utilizzo reale nelle prime settimane e poi adatta (vedi Far crescere l’installazione).

Requisiti per tutti gli scenari

	Requisito
Architettura CPU	x86-64 (amd64). In questa pagina un “core” corrisponde a una vCPU.
Sistema operativo	Ubuntu 22.04 o successivo
Storage	SSD. Tieni /var sul disco di sistema invece che su una piccola partizione separata.
Topologia	Un solo nodo. La piattaforma non offre alta disponibilità integrata; vedi Disponibilità e backup.

Scenario 1: Piattaforma

	Minimo	Consigliato
CPU	4 core	8 core
RAM	16 GB	32 GB
Disco di sistema	100 GB	100 GB
Disco dati	250 GB	500 GB

I servizi della piattaforma prenotano circa 2 core e 6 GB e nei picchi possono arrivare a circa 9 core e 18 GB. Il resto copre Kubernetes stesso e gli eventuali server MCP che esegui sulla stessa VM. Al livello minimo un picco completo non entra in memoria. La memoria è anche il primo limite che incontri quando aggiungi server MCP, quindi scegli il livello consigliato se pensi di eseguirne diversi.

Il disco dati ospita il database, l’indice di ricerca e i file caricati, e cresce con la quantità di contenuti che carichi.

Quando è Intric a occuparsi dell’elaborazione, i servizi di elaborazione di Intric prelevano ogni file caricato dal tuo object storage e rimandano il risultato alla tua piattaforma. La tua API e il tuo object storage devono quindi essere raggiungibili dal servizio di elaborazione di Intric tramite HTTPS con un certificato valido. Puoi limitare l’accesso agli indirizzi IP di origine che Intric ti comunica.

Scenario 2: Piattaforma + elaborazione

Quando carichi un file, la piattaforma deve trasformarlo in testo prima che gli assistenti possano cercarci dentro. Se ne occupano i servizi di elaborazione:

• L’elaborazione PDF legge layout, tabelle e testo dei file PDF e riconosce il testo nelle pagine scansionate (OCR).
• L’acquisizione dei documenti divide il testo in passaggi, e un modello di embedding trasforma ciascuno in un vettore che la ricerca può trovare. Se hai configurato un modello di immagine, l’acquisizione gli invia anche le immagini e i diagrammi dei documenti perché li descriva.
• La trascrizione audio prepara le registrazioni e le invia a un modello di speech-to-text, che restituisce il testo.

I worker girano su CPU. I modelli che chiamano (embedding, speech-to-text e modello di immagine) richiedono una GPU e non girano sulla VM: negli scenari 1 e 2 i worker chiamano tramite la rete modelli ospitati da Intric, nello scenario 3 modelli sui tuoi server GPU. Per questo lo scenario 2 non richiede alcuna GPU.

Una coda di messaggi assegna ogni job al worker giusto. Nello scenario 1 Intric esegue questi servizi per te; nello scenario 2 li esegui tu sulla tua VM. Il numero di worker segue automaticamente il numero di job in attesa, e i worker usano CPU solo mentre elaborano documenti o registrazioni. L’elaborazione PDF occupa la parte più grande: ogni worker PDF prenota 6 core e 5 GB, perché l’OCR sulle pagine scansionate esegue modelli di AI sulla CPU. Un solo worker gestisce ciascun documento, quindi con più worker la piattaforma elabora più documenti in parallelo.

Livello	Worker PDF	Worker di acquisizione documenti	Worker di trascrizione	CPU	RAM
Base	1	2	1	~20 core	~40 GB
Standard	4	4	3	~40 core	~60 GB
Alta capacità	9	9	5	~72 core	~88 GB

Ogni totale è il minimo dello scenario 1 (4 core / 16 GB), più le prenotazioni dei servizi di elaborazione, più 8 core / 16 GB di margine per i picchi. Un esempio per Standard: 4 worker PDF (24 core / 20 GB), 4 worker di acquisizione documenti (1,2 core / 2 GB), 3 worker di trascrizione (0,6 core / 2,3 GB) e la coda di messaggi, il coordinamento dei job, la sandbox per il codice e il servizio di esportazione, sempre attivi (1,4 core / 1,9 GB), arrivano insieme a circa 27 core / 26 GB. Con la piattaforma e il margine si arriva a circa 40 core / 60 GB.

Base funziona, ma i caricamenti grandi finiscono in coda e un documento scansionato di grandi dimensioni richiede molto più tempo. Standard è un buon punto di partenza per la maggior parte delle organizzazioni.

Sotto carico un worker PDF può usare fino al doppio della CPU prenotata e fino a 8 GB di memoria. Se tutti i worker PDF del livello Alta capacità raggiungono il picco nello stesso momento, l’uso di memoria può superare il totale indicato sopra; aggiungi RAM se noti segni di carenza di memoria. L’elaborazione resta ferma per la maggior parte del tempo, quindi su VMware e piattaforme simili la CPU inutilizzata rimane disponibile per altre VM. Per questo riserva alla VM la memoria, non la CPU.

Disco: aggiungi circa 50 GB per le immagini dei container (la sola immagine dell’elaborazione PDF occupa circa 9 GB). Ogni worker di trascrizione scrive fino a 2 GB di file temporanei mentre lavora, e la sandbox per il codice fino a 1 GB, sul file system che contiene /var/lib/kubelet. Se /var si riempie, Kubernetes inizia a sfrattare (evict) i workload su tutta la VM.

La Helm chart parte con limiti prudenti sul numero di worker: consumers.pdfPreProcessing.scaling.maxReplicas vale 2 per impostazione predefinita, e 5 per l’acquisizione dei documenti e la trascrizione audio. Alza ogni limite almeno al numero previsto per il tuo livello, altrimenti i worker non scalano fino alla capacità che hai messo a disposizione.

Scenario 3: Completamente locale

Tutti i modelli di AI girano su server GPU separati che la VM raggiunge tramite la rete: il modello linguistico e i modelli di supporto che i worker di elaborazione chiamano (embedding, speech-to-text e modello di immagine). Dimensiona la VM come nello scenario 2.

Modello linguistico. La capacità dipende molto più da quante domande sono in corso nello stesso momento, e da quanto sono lunghi i documenti allegati, che dal numero di utenti. Presso uno dei nostri clienti comunali più grandi, il picco in produzione è di circa 10 richieste simultanee.

Queste raccomandazioni cambiano di continuo. Modelli e generazioni di GPU evolvono in fretta, e ciò che consigliamo oggi può essere superato nel giro di pochi mesi. Le configurazioni qui sotto riflettono la nostra valutazione a ottobre 2026. Le aggiorniamo man mano che misuriamo nuovi modelli e nuovo hardware, e confermiamo il dimensionamento con te prima che tu ordini qualcosa.

Configurazione	Modello	Adatto per	Stato
1× H200 (141 GB)	Gemma 4 31B	Chat e domande sui documenti	Misurato in produzione
2× B200	Inkling Small (276B parametri, 12B attivi)	Risposte più rapide, documenti lunghi, compiti più complessi in più passaggi	Stimato
8× B200 (un nodo)	Inkling (circa 950B parametri, 40B attivi)	Molti utenti simultanei e i compiti più impegnativi	Stimato

1× H200 è la configurazione che usiamo oggi in produzione. Misurato con Gemma 4 31B (pesi a 4 bit, vLLM): ~100 tokens/s per risposta con una singola richiesta, e spazio nella memoria GPU per circa 900.000 token di contesto conversazionale. Bastano per circa 9 conversazioni simultanee con un contesto completo di 100.000 token, o per molte di più con prompt di dimensioni abituali. Secondo le nostre stime, una scheda in più con una propria copia del modello aggiunge la stessa capacità e offre anche ridondanza. La H200 appartiene alla generazione Hopper di NVIDIA (H100/H200), che Blackwell (B200 e successive) sta sostituendo. NVIDIA vende e supporta ancora le schede Hopper, ma ha iniziato ad annunciare l’end-of-life per parte della generazione. Per un nuovo acquisto ti consigliamo quindi di verificare la disponibilità e di valutare Blackwell. Gemma 4 dovrebbe stare anche su una sola B200, che ha più memoria e banda della H200, ma non l’abbiamo ancora provato.

Per 2× B200 con Inkling Small stimiamo ~150 tokens/s per risposta e spazio per 17–53 conversazioni simultanee con un contesto completo di 100.000 token. Il modello Inkling completo entra solo in un nodo intero; per 8× B200 stimiamo ~110 tokens/s per risposta e spazio per 44–142 conversazioni di questo tipo. Questa configurazione offre capacità e un modello più grande, non risposte più rapide per il singolo utente. I modelli Inkling richiedono GPU Blackwell e non funzionano su H100/H200. Abbiamo calcolato le cifre per B200 dalle nostre misure su H200 e dalle specifiche dell’hardware; non le abbiamo ancora provate sotto carico reale.

Modelli di supporto. Gli embedding (ricerca), lo speech-to-text e il modello di immagine che interpreta immagini e diagrammi nei documenti sono più piccoli. Nella nostra installazione locale più grande condividono una GPU da 94 GB e ne usano circa 50 GB. Se devono girare insieme, prevedi quindi una scheda da almeno 80 GB (per esempio una NVIDIA RTX PRO 6000 Blackwell Server Edition, 96 GB).

I server GPU richiedono GPU da data center (a raffreddamento passivo) in un server certificato per montarle, con flusso d’aria e alimentazione adeguati.

Far crescere l’installazione

• I documenti impiegano molto a diventare ricercabili: controlla le code di elaborazione. Se i worker sono al loro limite, alza maxReplicas e aggiungi CPU e RAM alla VM.
• Carenza di memoria o pod sfrattati: aggiungi prima la RAM. È il limite più comune sulla VM della piattaforma.
• Sotto carico le risposte tardano a partire (scenario 3): aggiungi una GPU per il modello linguistico.

Disponibilità e backup

Tutti gli scenari girano su una sola VM. Se la tua piattaforma di virtualizzazione riavvia una VM su un altro host dopo un guasto hardware (per esempio vSphere HA), questo copre la maggior parte delle esigenze di disponibilità, al prezzo di pochi minuti di interruzione. Gli snapshot della VM non sono un backup coerente del database. Configuriamo dump regolari del database, che devi conservare fuori dalla VM.

Rete e Firewall

Traffico in entrata (Porte)

• Porta 443: Interfaccia web (HTTPS), dalle reti dei tuoi utenti.
• Porta 80: Reindirizzamento automatico a HTTPS.
• Porta 22: SSH, per l’installazione e la gestione. Limitala al percorso di accesso di Intric (per esempio la tua VPN); non deve essere aperta verso internet.

Traffico in uscita (Whitelist - Infrastruttura)

Oltre ai modelli linguistici (vedi la sezione qui sotto), il server ha bisogno di accesso HTTPS a:

• get.k3s.io, github.com, objects.githubusercontent.com (installazione di k3s)
• ghcr.io, pkg-containers.githubusercontent.com (immagini dei container e Helm chart di Intric)
• registry-1.docker.io, auth.docker.io, production.cloudflare.docker.com (immagini dei container di terze parti)
• login.intric.ai (Intric usa il proprio IdP per l’autenticazione)

Se il tuo proxy o firewall ispeziona il TLS, escludi questi host. Puoi installare anche senza accesso in uscita, se replichi tutte le immagini in un registry privato.

Modelli linguistici per operazione on-prem

Negli scenari 1 e 2 la piattaforma e i worker di elaborazione chiamano tramite la rete modelli linguistici, embedding e speech-to-text. Consenti il traffico in uscita verso:

Modelli Hosted da Intric (UE):

• gpu6.intric.ai (modello linguistico ospitato da Intric)
• embedding-model.intric.ai (embedding ospitati da Intric)
• Speech-to-text: l’indirizzo dipende dal fornitore di trascrizione configurato per la tua installazione, e te lo forniamo noi
• mcp.intric.ai/* (server MCP ospitati da Intric)
• mcp-servers.intric.ai/* (server MCP ospitati da Intric)

Trovi l’elenco aggiornato dei modelli nel pannello di amministrazione, alla voce Modelli.

Modelli Pubblici Esterni (API):

• api.openai.com/v1
• api.anthropic.com
• api.berget.ai/v1
• api.mistral.ai/v1

Dominio e Certificato

1. DNS: Fai puntare il dominio che hai scelto (ad es. app.company.com) all’indirizzo IP del server con un record A o AAAA.

2. Certificato SSL/TLS: Devi fornire certificati validi:

   • File del certificato (.crt): Catena completa in formato PEM.
   • Chiave privata (.key): Chiave privata in formato PEM.
   • Nota: Il cliente è responsabile del rinnovo del certificato.