Non esiste una risposta valida per tutti: il dimensionamento di un server per l'AI — l'intelligenza artificiale — installata in azienda dipende da quanti agenti lavorano, quante fonti dati osservano, quanti utenti li consultano e quanto il carico crescerà. Il metodo corretto non è cercare un numero su una scheda tecnica, ma misurare il carico reale della tua azienda in una prova controllata, prima di firmare l'ordine dell'hardware. Questa guida elenca le variabili che contano, spiega perché i benchmark di laboratorio ingannano e propone una checklist da portare al confronto con il fornitore.
Le variabili che contano davvero
Quando si installa l'intelligenza artificiale su un server nel CED — il Centro Elaborazione Dati, cioè la sala server dell'azienda — il carico non dipende da un solo fattore. Le variabili principali sono cinque, e ciascuna va stimata sul tuo caso, non su quello di un altro cliente.
| Variabile | Perché influenza il carico | Come stimarla prima dell'acquisto |
|---|---|---|
| Numero di agenti attivi | Ogni agente che osserva, correla o prepara proposte consuma capacità di calcolo. Un presidio con pochi moduli è diverso da uno che copre sicurezza, identità, backup e dispositivi. | Elenca i moduli previsti nel progetto, non quelli del catalogo completo. |
| Fonti dati collegate | Log, inventari, configurazioni e telemetria alimentano l'analisi. Più fonti e più volume significano più lavoro di lettura, correlazione e conservazione delle evidenze. | Conta le fonti e stima il volume giornaliero con chi gestisce i sistemi. |
| Utenti e richieste contemporanee | Le persone che consultano l'app, chiedono spiegazioni o approvano interventi generano richieste. Conta il picco di simultaneità, non il totale degli account. | Stima quanti responsabili useranno il sistema nello stesso momento e in quali orari. |
| Crescita attesa | Nuove sedi, nuovi servizi o nuovi moduli aumentano il carico nel tempo. Un server giusto oggi può diventare stretto fra due anni. | Scrivi un piano di crescita realistico con le date previste, anche approssimative. |
| Continuità e ridondanza | Se il sistema deve restare attivo durante un guasto, servono copie, alimentazione protetta e una strategia di ripresa: non solo più calcolo. | Definisci quanto tempo di fermo è accettabile e chi ripristina il servizio. |
Prima di parlare di hardware serve quindi una mappa: quali dati alimentano l'analisi, chi li produce e cosa non deve mai uscire dall'azienda. A questo tema è dedicato l'articolo su come mappare i dati prima di introdurre l'AI, che conviene leggere prima di questa fase. Sulla continuità operativa del server in sede, con guasti e ripristino, vedi invece come garantire la continuità del server AI in sede.
Perché i numeri di targa ingannano
I benchmark di laboratorio misurano prestazioni in condizioni controllate: carichi sintetici, dati puliti, un solo compito alla volta. La tua azienda non è un laboratorio. Il carico reale arriva a ondate — l'avvio del turno, la chiusura del mese, un incidente che riempie i log — e mescola attività diverse sullo stesso server: analisi, risposte agli utenti, conservazione delle evidenze. Un numero ottenuto su un modello e un compito specifici non dice come si comporterà il tuo insieme di agenti sulle tue fonti.
C'è anche una ragione commerciale per diffidare: chi vende hardware ha interesse a proporti la macchina più grande «per stare tranquilli», e chi vende software ha interesse a dichiarare requisiti minimi ottimistici. Entrambe le cifre possono essere vere e allo stesso tempo inutili per la tua decisione. La domanda giusta non è «quanto è potente questo server», ma «come lo proviamo sul mio carico prima di comprarlo».
Vale la stessa trasparenza verso di noi: OverZeus non pubblica schede prestazionali con valori consigliati di processore (CPU), scheda grafica per il calcolo (GPU) o memoria, perché questi valori dipendono dalla configurazione concordata. Il percorso corretto è ricavarli insieme in prova, come descritto più avanti. Il NIST AI Risk Management Framework, un riferimento volontario del National Institute of Standards and Technology statunitense, raccomanda proprio di documentare le decisioni sui sistemi AI in base al contesto d'uso, non a parametri generici: un criterio utile anche per motivare l'investimento a chi lo approva.
Esempio illustrativo: il preventivo prima della misura
Esempio illustrativo. Lo scenario seguente è inventato per spiegare il metodo; non racconta un caso reale.
Un'azienda di logistica con una sede e due depositi vuole un presidio AI sui sistemi interni. Il fornitore hardware propone una macchina «taglia media» citando un benchmark; l'amministrazione è tentata di raddoppiare la dotazione «per il futuro». Il responsabile dei sistemi informativi chiede invece una prova in sola osservazione, su una macchina in comodato, senza toccare la produzione.
Durante la prova emergono tre fatti che nessun benchmark avrebbe mostrato:
- Il picco non dipende dagli utenti. Il momento più pesante è l'avvio del turno del mattino, quando i log dei tre magazzini arrivano insieme; le richieste delle persone, distribuite nel giorno, pesano molto meno del previsto.
- Una fonte vale più delle altre. La telemetria di un sistema di smistamento genera da sola gran parte del volume da analizzare; escluderla o campionarla cambia il dimensionamento più di qualsiasi upgrade.
- La crescita prevista era sovrastimata. Il «raddoppio per il futuro» nasceva da un progetto di nuova sede poi rimandato: acquistarlo subito avrebbe immobilizzato budget per anni.
L'azienda esce dalla prova con un dimensionamento motivato dai propri numeri, un margine di crescita definito e una data di verifica per riesaminarlo. Nessuna cifra di targa, nessun acquisto d'impulso: il metodo, non il modello di server, è ciò che rende difendibile la decisione di fronte alla direzione.
Pianificare prova, misura e crescita
Il percorso che consigliamo a qualsiasi fornitore — OverZeus compreso — ha tre passaggi.
1. Prova in sola osservazione. Il sistema lavora sulle fonti reali senza modificare la produzione, mentre si misurano carichi, picchi e volumi. In OverZeus questa fase è lo Shadow Mode di Oracle: una prova di 15-30 giorni su macchina in comodato, concordata sul perimetro del cliente, che rende visibile il valore potenziale e il consumo reale prima dell'attivazione. Le misure raccolte diventano la base del dimensionamento, non una promessa di prestazioni.
2. Margine di crescita esplicito. Invece di comprare il doppio «per sicurezza», si concorda un margine motivato dal piano di crescita e si fissa una verifica periodica: se le fonti o gli utenti aumentano oltre la previsione, si ridimensiona con dati alla mano. Sovradimensionare non è prudenza gratuita: è budget immobilizzato, consumi e complessità che restano anche se la crescita non arriva.
3. Continuità come requisito separato. Ridondanza, alimentazione protetta e ripristino sono una decisione a parte dal dimensionamento del calcolo, perché rispondono a una domanda diversa: quanto fermo è accettabile. Va discussa con numeri tuoi e messa per iscritto nell'offerta.
L'alternativa senza hardware: API in Europa
Se gestire un server nel CED non è la strada giusta per te, esiste l'opzione delle API, le interfacce applicative (Application Programming Interface) con cui i programmi della tua azienda interrogano un servizio remoto: l'elaborazione viene affidata a servizi AI su Azure o AWS, in una regione europea concordata, come prevede anche la modalità via API di OverZeus. Il problema del dimensionamento si sposta — paghi la capacità che usi — ma non sparisce il lavoro di verifica: cambia soltanto oggetto.
In particolare, la dicitura «regione europea» non basta. La documentazione Microsoft su dati e privacy dei modelli Azure spiega che il luogo di elaborazione dipende dal tipo di deployment: quelli di tipo Global possono elaborare in qualsiasi geografia in cui il modello è distribuito, e quelli DataZone in qualsiasi paese della data zone, anche con risorsa creata in Europa. Analogamente, la guida AWS sull'inferenza cross-region di Bedrock distingue profili geografici, che instradano dentro una geografia come l'Unione europea, da profili globali, che possono elaborare in qualsiasi regione supportata nel mondo. Configurazione ed evidenze vanno verificate per iscritto: il confronto completo tra le due architetture è nell'articolo AI locale nel CED o API cloud europee.
Come OverZeus affronta il dimensionamento
Su questo tema, due agenti di OverZeus svolgono un ruolo documentato:
- Oracle conduce la prova in Shadow Mode: osserva il perimetro collegato, prepara proposte senza modificare la produzione e produce un report che distingue evidenze, interpretazioni e condizioni di attivazione. È il contesto in cui misurare il carico reale prima di scegliere l'hardware.
- Odysseus coordina i moduli: collega gli indizi provenienti dalle fonti e riunisce analisi e proposte in un piano comprensibile. Il numero di moduli coordinati nel tuo progetto è una delle variabili che determinano il carico, e va definito nella configurazione concordata.
Le regole generali del progetto restano valide anche qui: gli interventi attivi richiedono l'approvazione prevista e il silenzio non autorizza; integrazioni, modalità di installazione e perimetro vengono definiti insieme. Prestazioni specifiche e disponibilità delle funzioni vanno confermate nell'offerta del tuo progetto, non assunte da una pagina web.
La checklist da portare al fornitore
Stampa questa lista e usala nel confronto. Un fornitore serio risponde a ogni punto; uno che risponde solo con un prezzo e una scheda tecnica ti sta chiedendo di decidere al buio.
- Quali moduli e quanti agenti saranno attivi nel mio progetto, e come influiscono sul carico?
- Quali fonti dati collegheremo, con quale volume stimato? Cosa succede se aggiungo una fonte?
- Come misuriamo il carico reale prima dell'acquisto? È prevista una prova in sola osservazione, con macchina in comodato?
- Quale margine di crescita proponi, su quale piano, e quando lo riesaminiamo?
- Quali requisiti di continuità (guasti, alimentazione, ripristino) sono inclusi e quali esclusi?
- Se scelgo le API invece del server locale: quale tipo di deployment o profilo di inferenza, in quale geografia avviene l'elaborazione, quali evidenze me lo dimostrano?
- Quali voci di costo esistono oltre all'hardware o alla licenza: installazione, integrazioni, assistenza, manutenzione?
In sintesi
Il dimensionamento giusto per l'AI in azienda non si legge su una scheda: si misura. Definisci le variabili del tuo caso — agenti, fonti, utenti, crescita, continuità — diffida dei benchmark di laboratorio, esigi una prova sul carico reale e metti margine e verifiche per iscritto. Così l'investimento diventa una decisione difendibile, non una scommessa.
Confronta con noi un’installazione nel CED e una configurazione API europea.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.