Infrastruttura IA privata: eseguire modelli sui propri dati

La maggior parte delle aziende che sperimentano l'IA generativa parte da un'API pubblica. La difficoltà emerge quando il lavoro utile coinvolge dati reali: contratti, ticket di assistenza, codice sorgente, cartelle cliniche, bilanci. A quel punto le domande passano da “il modello può farlo” a “dove vanno questi dati, chi può vederli e possiamo dimostrarlo in seguito”.

Un ambiente di IA privata risponde a queste domande eseguendo i modelli, il livello di retrieval e i servizi di supporto all'interno di un'infrastruttura che si controlla. Prompt, documenti e output restano entro un perimetro definito, soggetti alle proprie policy di accesso e ai propri log.

Che cosa significa davvero “IA privata”

Un deployment di IA privata ha tre proprietà. Primo, l'inferenza gira su capacità di calcolo dedicata a te o isolata per te, non su un servizio multi-tenant condiviso in cui i tuoi prompt vengono elaborati insieme al traffico di altri clienti. Secondo, i tuoi dati e i pesi dei tuoi modelli sono archiviati in località che scegli tu e non vengono copiati altrove senza approvazione. Terzo, ogni accesso al sistema è autenticato, autorizzato e registrato in log di tua proprietà.

Un server single-tenant nel data center di un fornitore, un nodo GPU dedicato o un cluster isolato possono soddisfare la definizione, a condizione che il contratto e i controlli tecnici la sostengano. Ciò che squalifica una configurazione è qualsiasi percorso attraverso cui i dati escono dal perimetro per impostazione predefinita, come un endpoint di modello ospitato che conserva i prompt per l'addestramento o per la verifica degli abusi, oppure un plugin che chiama un servizio di terzi che non hai approvato.

L'architettura di riferimento

Quasi ogni ambiente di IA privata, che serva un solo chatbot interno o una dozzina di carichi di lavoro in produzione, è costruito con gli stessi cinque livelli.

• Calcolo GPU. Gli acceleratori che eseguono l'inferenza dei modelli e, se necessario, il fine-tuning. Di solito è il livello più costoso e quello con i maggiori vincoli di capacità.
• Model serving. Software che carica i pesi del modello, raggruppa le richieste in batch ed espone un'API. Tra le scelte comuni ci sono vLLM e NVIDIA Triton Inference Server, di solito orchestrati con Kubernetes.
• Vector store e retrieval. Un database di embedding che consente al modello di rispondere alle domande usando i propri documenti senza riaddestrarlo. Questo livello include anche la pipeline di ingestione che suddivide in chunk, calcola gli embedding e indicizza i contenuti.
• Controllo degli accessi. Integrazione con il sistema di identità, permessi basati sui ruoli e policy di rete che stabiliscono chi può interrogare quali modelli e quali raccolte di documenti.
• Logging e monitoraggio. Registrazioni di richieste, risposte, risultati del retrieval, azioni amministrative e uso delle risorse, conservate secondo una policy definita.

Sotto, infrastruttura standard: server CPU per l'applicazione e i job di ingestion, storage a blocchi o a oggetti per documenti grezzi e file dei modelli, backup e una rete a indirizzamento privato con un unico punto di accesso controllato.

Dimensionare il calcolo GPU

La memoria della GPU è il primo vincolo da verificare, perché un modello che non entra in memoria non girerà a una velocità utile. Una regola pratica: i pesi del modello richiedono circa 2 byte per parametro con precisione a 16 bit, circa 1 byte a 8 bit e all'incirca mezzo byte con quantizzazione a 4 bit. Un modello da 8 miliardi di parametri richiede quindi circa 16 GB a 16 bit, mentre un modello da 70 miliardi di parametri richiede circa 140 GB a 16 bit o circa 35-40 GB a 4 bit.

Il motore di serving mantiene anche una cache key-value per ogni richiesta attiva, e quella cache cresce con la lunghezza del contesto e con il numero di utenti concorrenti. Prevedi un margine del 30-50 percento oltre l'ingombro dei pesi, poi verifica con un test di carico usando le lunghezze reali dei tuoi prompt.

Stima le richieste concorrenti di picco, la lunghezza media di input e output e il tempo di risposta accettabile. I carichi batch tollerano l'accodamento e privilegiano poche GPU più grandi con un utilizzo elevato. I carichi interattivi richiedono capacità sufficiente a mantenere la latenza prevedibile al picco, il che può significare diversi nodi più piccoli dietro un load balancer.

Infine, decidere se serva davvero capacità di addestramento. Il fine-tuning di un modello grande richiede in genere una memoria pari a diverse volte quella necessaria per l'inferenza dello stesso modello, quindi conviene verificare il business case prima di dimensionare per esso.

Modelli open-weight e model serving

I modelli open-weight, i cui parametri addestrati sono pubblicati per il download, sono ciò che rende praticabile un deployment privato. Oggi sono disponibili diverse famiglie con dimensioni da pochi miliardi a diverse centinaia di miliardi di parametri, che coprono chat generica, codice, lavoro multilingue ed embedding.

Valutarli sui propri compiti con un set di test fisso di 100-500 prompt rappresentativi e risposte valutate. Confrontare accuratezza, latenza alla concorrenza obiettivo e ingombro di memoria alla precisione con cui si intende eseguirli. Un modello più piccolo che risponde correttamente grazie a un buon retrieval è spesso una scelta migliore di un modello più grande che richiede il doppio delle GPU.

Prima di tutto leggi la licenza. Open-weight non significa sempre open source. Alcune licenze limitano l'uso commerciale oltre una certa dimensione della base utenti, vietano determinate applicazioni o richiedono l'attribuzione.

Per il serving, un motore come vLLM offre continuous batching e una gestione efficiente della cache, che migliorano in modo significativo il throughput rispetto a un serving ingenuo, una richiesta alla volta. Triton è utile quando si serve un mix di tipi di modello, come un modello di embedding, un reranker e un generatore, dietro un'unica interfaccia.

Retrieval: il vector store e la pipeline dei dati

La retrieval-augmented generation è il pattern su cui si basa la maggior parte dei deployment privati. Il modello risponde a partire dai tuoi contenuti senza che questi diventino mai parte dei pesi del modello.

Un milione di chunk con vettori a 1.024 dimensioni memorizzati come float a 32 bit occupano circa 4 GB di dati vettoriali grezzi, al netto dell'overhead dell'indice e del testo originale. Le opzioni vanno da un'estensione di PostgreSQL come pgvector, adatta ai team che già usano PostgreSQL, a motori dedicati come Qdrant o Milvus per collezioni più grandi, fino alle funzionalità vettoriali di OpenSearch ed Elasticsearch dove la ricerca per parole chiave è già in uso.

La pipeline conta più del database. Se un utente non può aprire un file nel sistema di gestione documentale, l'assistente non deve citarglielo. Il modo affidabile per garantirlo è memorizzare i metadati di accesso con ogni chunk e filtrare al momento della query, invece di affidarsi al modello perché trattenga le informazioni.

Controllo degli accessi, logging e governance dei dati

Integrarlo con l'identity provider esistente tramite SAML o OpenID Connect, così che ingressi, cambi di ruolo e uscite del personale siano gestiti in un unico punto. Definire ruoli che corrispondano a responsabilità reali: chi può interrogare quali modelli, chi può aggiungere raccolte di documenti, chi può distribuire nuove versioni dei modelli e chi può leggere i log. Tenere l'accesso amministrativo separato da quello degli utenti e richiedere l'autenticazione a più fattori per entrambi.

A livello di rete, collocare i nodi GPU, il vector store e lo storage su indirizzi privati, senza accesso in ingresso da internet. Esporre un unico API gateway che termina TLS, autentica ogni richiesta e applica i rate limit. Bloccare per impostazione predefinita il traffico in uscita dai server dei modelli e consentire solo le destinazioni specifiche necessarie, come un mirror interno dei pacchetti.

Gli operatori hanno bisogno di metriche come utilizzo della GPU, profondità della coda, latenza e tassi di errore. I team di sicurezza e conformità hanno bisogno di un audit trail: chi ha chiesto cosa, quali documenti sono stati recuperati, quale versione del modello ha risposto e che cosa è stato restituito. Prompt e risposte possono contenere a loro volta dati sensibili, quindi applica all'archivio dei log gli stessi controlli dei dati di origine, cifralo, limita gli accessi e fissa un periodo di conservazione coerente con la tua policy invece di conservare tutto per sempre.

Classificare i dati che si intende usare, decidere quali classi sono ammesse in quali ambienti e documentare dove risiede fisicamente ciascun dataset. Tenere la valutazione e la sperimentazione separate dalla produzione, con una fase di revisione prima che un nuovo dataset o modello passi dall'una all'altra. In caso di fine-tuning, conservare i dati di addestramento, i pesi risultanti e una registrazione del processo, perché un modello sottoposto a fine-tuning può riprodurre frammenti dei propri dati di addestramento e va governato con la stessa cura dei dati stessi.

Domande da porre a un fornitore di infrastruttura

Che tu acquisti server GPU, un cluster gestito o una piattaforma completamente gestita, le risposte alle domande seguenti determinano se l'ambiente è davvero privato.

• Tenancy. GPU, server e storage sono dedicati a noi o condivisi con altri clienti? Se condivisi, come viene garantito l'isolamento a livello di hardware, hypervisor e rete?
• Localizzazione. In quale paese e in quale struttura risiederanno ciascun server e ciascuna copia dei nostri dati, backup inclusi? I dati possono essere spostati senza la nostra approvazione?
• Impegno sull'hardware. Quale modello esatto di GPU e in quale quantità viene quotato, e qual è il tempo di consegna confermato? Cosa succede se la consegna slitta?
• Accessi da parte del personale del fornitore. Quali dipendenti del fornitore possono accedere ai nostri sistemi, in quali circostanze, e come viene registrato e comunicato a noi tale accesso?
• Responsabilità. Chi applica le patch al sistema operativo, ai driver e al software di serving? Chi monitora le GPU, interviene in caso di guasto hardware ed esegue i ripristini dai backup?
• Rete. Quale velocità della porta e quale traffico sono inclusi? Come riferimento, una porta da 1 Gbps trasferisce circa 10 TB al giorno a pieno carico, il che conta quando si caricano grandi raccolte di documenti o file di modelli.
• Uscita. Come recuperiamo dati, pesi e log alla fine del contratto, e come viene confermata la cancellazione delle copie rimanenti?
• Prezzi. Il prezzo è fisso al mese per una configurazione definita, e quali voci, come storage aggiuntivo, traffico od ore di supporto, sono fatturate a parte?

Checklist per il deployment di IA privata

Usa l'elenco seguente durante la pianificazione e di nuovo prima della messa in produzione.

• Casi d'uso scritti: utenti, concorrenza di picco, lunghezza dei prompt, latenza obiettivo.
• Ogni fonte di dati classificata, con ambienti approvati per classe.
• Modelli open-weight candidati valutati su un set interno fisso. Licenze esaminate e documentate.
• Memoria GPU per pesi e KV cache al picco, con il 30-50% di margine, validata con test di carico.
• Stack di serving scelto (es. vLLM o Triton su Kubernetes), versioni e checksum fissati.
• Vector store dimensionato; l'ingestion gestisce aggiornamenti, eliminazioni e metadati dei permessi.
• Identity provider integrato, ruoli definiti, MFA obbligatoria per utenti e amministratori.
• Rete privata, un unico gateway autenticato, uscita negata per impostazione predefinita dai server dei modelli.
• Log di audit e operativi: cifrati, ad accesso limitato, conservati secondo policy.
• Valutazione e produzione separate, con fase di approvazione.
• Documenti, indici, configurazione e file dei modelli sotto backup. Ripristino testato.
• Risposte scritte del fornitore: tenancy, località, accesso del personale, responsabilità, uscita.

Come può aiutare Vonahost

Vonahost fornisce infrastruttura IA per deployment privati, in cui dati e modelli restano nell'ambiente del cliente e girano su strumenti standard come PyTorch, vLLM, Triton e Kubernetes. La capacità GPU viene quotata per progetto, con modello di GPU, quantità e tempi di consegna confermati per iscritto. I workload di supporto, come ingestione, application server e database vettoriali, possono girare su server dedicati AMD EPYC single-tenant con NVMe locale o storage a blocchi di rete, nella regione che scegliete.

Ogni proposta Vonahost indica configurazione, località, responsabilità e prezzo mensile in dollari statunitensi. Il paese di ciascun server è scelto dal cliente, e i dati non vengono spostati senza la sua approvazione.