IA auto-gestita di livello enterprise
In questo articolo condividiamo come Saphes IT Systems ha affrontato l'IA auto-gestita di livello enterprise fin dal primo giorno. Abbiamo intrapreso questa strada per due motivi: dovevamo soddisfare rigorosi requisiti di conformità e volevamo mantenere il pieno controllo invece di dipendere da un unico fornitore.
Il nostro lavoro è strettamente legato alla proprietà intellettuale e a dati sensibili dei clienti. Inviare conoscenze proprietarie e asset a un fornitore di IA esterno senza garanzie e controllo chiari solleva una domanda semplice: e se finissimo per regalare la nostra IP per nulla?
Dopo più di due anni di sperimentazione pratica in condizioni di produzione, abbiamo maturato una profonda esperienza nella progettazione e nella gestione di uno stack IA auto-gestito competitivo. Oggi quell'esperienza si traduce in una piattaforma non solo conforme e controllabile, ma anche più veloce e significativamente più economica di molte alternative.
Nelle sezioni seguenti esaminiamo i blocchi fondamentali di una configurazione IA auto-gestita per l'azienda:
- Hardware e dimensionamento (pianificazione basata su capacità e SLO)
- Strategia dei modelli (cosa eseguire per quali compiti e come gestire il ciclo di vita)
- Stack software (inferenza, orchestrazione, RAG, osservabilità)
Hardware e dimensionamento
Il dimensionamento parte da alcuni obiettivi pratici: numero di utenti previsto, concorrenza di picco, latenza accettabile (time-to-first-token e token/sec) e mix di carichi di lavoro (chat, RAG, job batch, embeddings). Da lì puoi scegliere:
- Compute: CPU vs GPU, classe di GPU (consumer o datacenter) e fabbisogno di VRAM determinato da dimensione del modello + lunghezza del contesto + dimensione del batch. Consulta i benchmark GPU di PassMark per confronti tra schede consumer e Pro.
- Memoria e storage: RAM sufficiente per i servizi di supporto più storage locale veloce per i pesi dei modelli e le cache; pianifica la crescita man mano che modelli e finestre di contesto aumentano.
- Rete: rete a bassa latenza tra inferenza e servizi di supporto (database vettoriale, storage, osservabilità), e capacità di uscita sufficiente se più applicazioni chiamano il modello.
Per i team che già gestiscono server, questo assomiglia alla pianificazione della capacità di qualsiasi altra piattaforma interna: definire gli SLO, misurare, poi scalare.
Osservazioni
Queste osservazioni potrebbero non corrispondere esattamente alle tue esigenze. Consigliamo vivamente di analizzare il tuo uso futuro con un esperto invece di tirare a indovinare. Gli esempi seguenti sono osservazioni reali, ma non sono abbastanza precisi per scegliere da soli la configurazione giusta.
| Dimensione azienda | Tipi di uso | Opzioni hardware | Costo iniziale |
|---|---|---|---|
| Piccolo team (2-20 utenti), uso basso | Chat interna, Q&A ad hoc, bassa concorrenza | CPU-first (Apple M3 Ultra) o 1× GPU Pro 48GB VRAM (ad esempio RTX PRO 5000) con 64GB RAM e NVMe veloce | ~2k-5k€ |
| Piccolo team di ingegneri (2-10 utenti), uso elevato | Chat interna, Q&A ad hoc, alta concorrenza, RAG, generazione di codice, completamento del codice | 2× GPU Pro 96GB VRAM (RTX PRO 5000) o 4× GPU consumer premium ed economiche (RTX 3090) con 128GB RAM e NVMe veloce | ~5k-15k€ |
| Azienda media (50-200 utenti), uso misto | Assistente interno + RAG per reparto (HR, Vendite, Supporto), concorrenza moderata, alcuni job batch | 2× GPU datacenter 80GB (A100 / H100) o 2× GPU Pro 96GB RTX 6000, 256-512GB RAM, 2-4× NVMe (RAID); considera un nodo separato per database vettoriale/ETL | ~20k€-50k€ |
Domande frequenti
Quanto costerà l'elettricità per gestire il sistema?
È trascurabile rispetto al costo iniziale o ai costi per token dei provider di IA. Supponiamo che tu usi il 20% del tempo il 100% della tua capacità con 4 GPU consumer (un uso intensivo). Avrai una bolletta di circa 100€/mese. Con lo stesso uso intensivo, presso provider di IA saresti intorno a 3k-6k€ al mese.
Come scegliere la scheda madre giusta e cosa succede con il PCIe?
Dipende dalle tue esigenze. Alcune schede madri professionali come la MZ32-AR0 sono consigliate, soprattutto se vuoi usare più modelli e caricarli/scaricarli rapidamente (versione e linee PCIe per slot, qui PCIe 4 16x). Se ti affidi a uno o due modelli, puoi tenerli caricati e usare una scheda madre consumer come una B550 Eagle, che è molto economica. In effetti, la velocità delle linee, anche a PCIe 3 x1, è sufficiente e non c'è differenza nella velocità di inferenza; solo il caricamento dei modelli diventa molto più lungo.
Come alimentare 4 GPU? Posso usare più alimentatori?
Sì. Consigliamo di usare più alimentatori se non ne trovi uno che soddisfi i tuoi requisiti. Un alimentatore può essere attivato senza la necessità di collegarlo alla workstation.
Quale CPU dovrei abbinare a GPU di fascia alta?
Dai priorità alle linee PCIe e alla larghezza di banda della memoria: le CPU workstation/server (Threadripper/EPYC/Xeon) sono spesso più adatte delle CPU consumer quando esegui 2-4+ GPU. Evita colli di bottiglia della CPU per lo streaming dei token e le pipeline RAG.
Quale configurazione di storage funziona meglio per i pesi dei modelli e il RAG?
Usa NVMe veloce per i pesi dei modelli e le cache attive. Volumi separati (o nodi separati) per il database vettoriale e i log. RAID1/10 aiuta la disponibilità; pianifica anche backup per indici e documenti.
L'hardware GPU consumer è abbastanza affidabile per la produzione?
Nella maggior parte dei casi, sì. Tuttavia, se servi clienti e non accetti un rischio operativo più elevato (senza VRAM con ECC, temperature meno prevedibili), preferisci GPU datacenter, chassis validati e supporto enterprise.
Come gestiamo raffreddamento, rumore e limiti di potenza?
Pianifica prima il flusso d'aria (dal davanti al retro, ventole ad alta pressione statica), dimensiona gli alimentatori con margine e imposta limiti di potenza delle GPU per stabilizzare le prestazioni/watt. In ufficio, considera il posizionamento remoto in rack o build workstation più silenziose (evita i sistemi a ventola blower).
Ci serve una rete ad alta velocità (10/25GbE)?
Non proprio. Il traffico IA è per lo più testo, e il testo è leggero, quindi raramente è il collo di bottiglia.
Posso usare GPU AMD o Intel?
La risposta breve è sì, ma in pratica spesso non ne vale la pena. Il problema è il supporto dell'ecosistema (ROCm e Intel oneAPI) rispetto a CUDA. Anche se risparmi un po' sul costo iniziale, probabilmente incontrerai più difficoltà, e a volte semplicemente non potrai usare un determinato modello o una funzionalità.
Scelta dei modelli
Le configurazioni aziendali traggono vantaggio da una politica dei modelli deliberata invece che da "un modello per tutto". In pratica, consigliamo di definire un piccolo "portafoglio di modelli":
- Modello assistente principale (la migliore qualità che puoi eseguire entro i tuoi vincoli di latenza/SLO)
- Modello economico per compiti ad alto volume (classificazione, estrazione, routing, bozze)
- Modello di embeddings per il RAG (e opzionalmente un reranker se la qualità del recupero conta)
Criteri di selezione che usiamo:
- Aderenza ai compiti: chat vs traduzioni vs estrazione strutturata vs codice; non spendere troppo per un modello grande su una classificazione semplice.
- Efficienza di servizio: la dimensione della cache KV cresce con la finestra di contesto; il contesto è spesso il vero collo di bottiglia della VRAM.
- Licenze e governance: valida la compatibilità delle licenze (uso interno, uso verso i clienti, ridistribuzione) e documenta i modelli approvati. Controlla le licenze dei modelli di Hugging Face prima del deployment.
Le nostre raccomandazioni di base
La tabella seguente è pensata come punto di partenza (la VRAM esatta dipende dal backend, dalla dimensione del batch, dal contesto e dal fatto che tu tenga caricati più modelli).
| Modello | Quantizzazione | Finestra di contesto | Dimensione VRAM | Uso |
|---|---|---|---|---|
| Qwen3.6 35b (a3b) | Q5_K_M | 256k | 50GB | Codice, compiti agentici, compiti generali |
| Qwen3.6 27b | Q5_K_M | 256k | 50GB | Come il 35b, più preciso nei benchmark, ma più lento |
| GLM 4.7 flash | Q5_K_M | 198k | 50GB | Codice, compiti agentici, compiti generali |
| TranslateGemma | Q5_K_M | 128k | 35GB | Traduzioni |
| Qwen2.5 Coder 14b (base) | Q5_K_M | 8k (fino a 32k) | 25GB | Completamento del codice |
| Nomic Embed 0.3b | FP16 | 2k | 1GB | Modello di embeddings leggero, affidabile e portabile |
| Qwen3 Embedding 4b | Q8_0 | 40k | 20GB | Modello di embeddings molto preciso, ma pesante, utile se ti serve una grande finestra di contesto |
| Flux 2 Klein 9b | FP8 | / | 10GB | Buono per risultati fotorealistici |
| GLM Image | FP8/FP16 | / | 20GB | Buono per immagini comuni, incluso il testo |
Domande frequenti
Quale throughput si può attendere?
Ognuno dei nostri esempi è molto pratico. Ad esempio, una 4× RTX 3090 che esegue Qwen 3.6 35B con una finestra di contesto di 256k su llama.cpp offre 120 token/sec per un singolo utente e 70 token/sec per 3 richieste concorrenti, il che è meglio, ad esempio, dell'API Claude 4.6, senza alcun limite di utilizzo.
Come scegliamo la finestra di contesto giusta?
Parti dall'esigenza del prodotto, non dalla scheda tecnica del modello. Per la maggior parte degli assistenti aziendali, 8k-16k è sufficiente se la tua pipeline RAG è buona (recupera meno, recupera meglio). Aumenta il contesto solo quando hai flussi di lavoro reali con documenti lunghi (contratti, grandi specifiche tecniche, revisioni di codice su più file). Ricorda: un contesto più lungo aumenta l'uso della VRAM (cache KV) e spesso riduce il throughput.
Come scegliamo la quantizzazione giusta (FP16 vs 8-bit vs 4-bit)?
Non usare mai FP16, tranne che per modelli molto piccoli o la generazione di immagini; non ne vale la pena. 8-bit è molto buono per attività sensibili alla precisione con un miglior risparmio di memoria. 4-bit è di solito il miglior rapporto costo/prestazioni per chat e RAG in produzione, ma valida sul tuo set di valutazione (alcuni compiti come l'estrazione rigorosa o le sfumature multilingue possono degradarsi). In Saphes consigliamo la quantizzazione Q5; l'equilibrio è perfetto per il nostro uso, e non abbiamo mai identificato un output degradato con questa quantizzazione.
Cosa incide di più sulla VRAM?
Tre fattori principali: (1) i pesi del modello, (2) la finestra di contesto (cache KV) e (3) il batching/concorrenza. Molti team sottovalutano la cache KV: raddoppiare il contesto può aumentare significativamente il fabbisogno di VRAM, soprattutto con concorrenza più elevata.
Dovremmo eseguire un modello grande o più modelli più piccoli?
Preferisci più modelli quando hai una chiara separazione dei compiti: un assistente potente per le richieste "difficili" e un modello più economico per routing, riassunto, estrazione o bozze. Questo riduce i costi e migliora la latenza sotto carico.
Ci serve un reranker per il RAG?
Se i tuoi documenti sono rumorosi o lunghi e la qualità del recupero conta (basi di conoscenza di supporto, contenuti legali/tecnici), un reranker spesso migliora la precisione più di un aumento della dimensione del contesto. Se il tuo corpus è piccolo e pulito, puoi farne a meno.
Perché non un modello grande come Kimi k2.5?
Una volta raggiunta una certa scala, aggiungere parametri ha sempre meno impatto sulla qualità. Un modello come Qwen 3.6 è più che sufficiente per compiti agentici complessi oggi; non devi affidarti a modelli open source "di frontiera" come Deepseek V4. Il divario di prestazioni non vale la pena: un modello più piccolo e ben configurato è più che sufficiente, e molto più veloce.
Dovrei usare più modelli o un unico modello di punta?
Consigliamo di avere un modello di punta, sempre caricato sulle tue GPU, usato per la maggior parte dei compiti. Mantieni un po' di VRAM disponibile per utili modelli più piccoli, come uno specialista di traduzione e il completamento del codice; questi non occupano molta VRAM e sono molto veloci in ciò che fanno. Questo aiuta anche a scaricare le richieste concorrenti dal tuo modello di punta.
Stack software / tooling
Un tipico stack auto-gestito è modulare e può partire in piccolo:
Inferenza
Per l'inferenza, attualmente ci sono tre veri contendenti. Ognuno espone un'API compatibile con OpenAI, e ognuno ha punti di forza e compromessi:
| Soluzione | Vantaggi | Svantaggi |
|---|---|---|
| Ollama | Veloce da configurare, facile da usare: pochi comandi e il tuo modello è in esecuzione. | Più lento delle altre soluzioni; carica/scarica spesso i modelli se una richiesta non corrisponde a ciò che è già caricato. |
| Llama server (llama.cpp) | Molto veloce e solido per la concorrenza; alto livello di personalizzazione; ampia scelta di modelli e supporto dei formati. | Carica un modello alla volta; più lungo da configurare rispetto a Ollama. |
| vLLM | Eccellente per la concorrenza; la scelta giusta per un modello di punta su larga scala; consente un alto livello di personalizzazione. | Più lento di llama.cpp per richieste singole; più lungo da configurare rispetto a Ollama; meno formati supportati di llama.cpp. |
UI / Gateway
C'è un'opzione che spicca: Open WebUI. Open WebUI agisce come gateway e offre un controllo degli accessi granulare. Include anche molte funzionalità, tra cui il proxying di Ollama (se lo usi) e di altre API compatibili con OpenAI collegate.
Open WebUI può essere abbinato a ComfyUI per la generazione di immagini; interagiscono bene tra loro, creando un'esperienza di generazione di immagini simile a GPT.
RAG
Un sistema RAG (Retrieval-Augmented Generation) è cruciale per molti casi d'uso, e più documenti ha la tua azienda, più diventa importante. Il RAG ti permette di memorizzare frammenti dei tuoi documenti e, invece di iniettare 300 pagine nella finestra di contesto per ogni domanda, recuperare solo le parti rilevanti insieme ai metadati (nome del documento, riferimento di pagina, ecc.). Scopri di più sull'architettura RAG e sulle best practice.
Per scopi di sviluppo, il RAG è spesso meno utile (ad esempio, ri-embeddare un intero codebase per ogni branch non è realistico). Al contrario, embeddare documentazione strutturata per un framework o un linguaggio può essere molto utile.
Prima di configurare un sistema RAG (che è semplice da avviare), la parte più importante è definire cosa deve stare nel tuo database e quali metadati ti servono. L'architettura conta: determina se il tuo sistema RAG sarà utilizzabile nella pratica.
Puoi eseguire ChromaDB o Qdrant sul tuo server. Entrambi sono validi; consigliamo Qdrant perché è veloce e ben progettato (questa raccomandazione è soggettiva).
Editor di codice
Per uno sviluppo local-first assistito dall'IA, consigliamo la seguente configurazione:
Zed: la nostra raccomandazione predefinita. Integra l'IA in modo nativo, supporta ACP e altri strumenti moderni, ed è estremamente veloce e reattivo. Consulta la documentazione IA di Zed per i dettagli di configurazione.
VS Code o JetBrains:
- Continue per il completamento del codice e risposte rapide in stile chat.
- Cline per flussi di lavoro più agentici (compiti multi-step, modifiche su tutto il repo, orchestrazione di strumenti).
MCP
Ci sono molti MCP sul mercato. Quelli giusti sono semplicemente quelli che ti servono. Ciò che conta di più è il deployment: gli MCP possono essere eseguiti in vari modi e supportano diversi tipi di connessione. Consigliamo connessioni HTTP streamable per gli MCP che devono connettersi al tuo server, ed eseguirli direttamente sul server.
Un buon set di MCP, o costruire quelli che ti servono, può fare la differenza. Gli MCP sono limitati soprattutto dall'immaginazione: puoi sviluppare un MCP per parlare con la tua piattaforma di e-commerce, CMS, creare e recuperare contenuti, creare prodotti e molto altro. Scopri di più sulla specifica del Model Context Protocol ed esplora il MCP Registry per integrazioni create dalla community.
Considerazioni finali
Oggi, integrare l'IA auto-gestita in un'azienda non è più un progetto impossibile: è concreto e realizzabile. I modelli sono ormai abbastanza intelligenti e veloci per gestire compiti complessi, un sistema RAG ben configurato può superare la maggior parte delle soluzioni RAG automatizzate sul mercato, gli strumenti UI sono diventati facili da usare, e il ROI è spesso raggiunto rapidamente, tipicamente entro 6-24 mesi a seconda della complessità dei tuoi sistemi.
Detto questo, ci sono considerazioni importanti. La configurazione iniziale può essere complicata: problemi di driver, connessione degli strumenti, configurazione del sistema RAG e selezione dei modelli giusti. Per noi, il costo maggiore non è l'hardware, ma la configurazione che richiede tempo, mentre la manutenzione continua è di solito molto più semplice.
