Per una prima prova con l’IA locale non è necessario acquistare subito un nuovo server. Un computer già disponibile può mostrare se un modello linguistico più piccolo produce risultati utili per il compito previsto. Per il lavoro quotidiano contano poi anche i tempi di attesa, la capacità disponibile e una gestione affidabile.
La domanda principale è quindi: che cosa deve fare il modello? Una breve revisione di un testo ha esigenze diverse dall’analisi di documenti lunghi, da attività di programmazione complesse o dal lavoro simultaneo di più persone. «Il modello si avvia» è un primo riscontro tecnico. Non dimostra ancora l’adeguatezza di una postazione o di un servizio aziendale.
Che cosa è possibile senza una scheda grafica particolare
I modelli linguistici possono funzionare su una CPU supportata. Il runtime llama.cpp supporta diverse piattaforme di processori e anche la ripartizione del lavoro tra CPU e GPU. Una GPU non è quindi un requisito generale per ogni prova, anche se può accelerare sensibilmente l’elaborazione. La differenza effettiva si misura con il compito scelto. llama.cpp: hardware supportato ed esecuzione (link esterno).
Una prova su CPU può servire, per esempio, a creare una bozza da appunti non sensibili, organizzare una breve nota o valutare un piccolo esempio di codice. Il modello deve essere adeguato alla lingua e alla materia. Un testo iniziale lungo, una risposta impegnativa o una seconda richiesta simultanea possono modificare molto l’esito inizialmente utile di una prova individuale.
32 o 64 GB di RAM: scenari di pianificazione, non un minimo universale
I livelli seguenti sono indicati espressamente come esempi. Non sostituiscono né la verifica del file del modello concreto né una prova di carico. Modelli più piccoli possono richiedere meno memoria; modelli più grandi, contesti lunghi o più servizi possono averne bisogno di molta di più.
| Livello di ampliamento | Base di esempio | Che cosa deve chiarire la prova |
|---|---|---|
| Valutare il computer disponibile | CPU supportata, per esempio 32 GB di RAM e sufficiente spazio libero su SSD; inizialmente senza GPU aggiuntiva. | Un modello più piccolo è adeguato alla materia? L’attesa è accettabile per singoli compiti brevi? |
| Postazione usata regolarmente | Per esempio 32–64 GB di RAM, SSD NVMe e una GPU scelta in base al modello e al contesto. | Il lavoro resta fluido quando altre applicazioni funzionano in parallelo e gli input si allungano? |
| Servizio condiviso | Risorse dedicate; per esempio 64 GB di RAM di sistema come punto di partenza della pianificazione, accelerazione adeguata e gestione definita. | Quali livelli di utilizzo simultaneo, qualità delle risposte e disponibilità sono raggiungibili con un carico reale? |
64 GB di RAM di sistema non sostituiscono una memoria grafica sufficientemente capiente. Allo stesso modo, un file del modello che trova spazio sull’SSD non dimostra che l’intero modello, con il contesto desiderato, entri nella GPU. Nei sistemi con memoria condivisa occorre considerare tutta la ripartizione della memoria.
Perché la sola dimensione del modello non basta
Un semplice calcolo chiarisce l’ordine di grandezza: otto miliardi di parametri con quattro bit teorici per parametro danno 8.000.000.000 × 4 ÷ 8 = 4.000.000.000 byte, cioè circa 4 GB o 3,73 GiB di soli pesi. Non è il fabbisogno completo di memoria di un modello eseguibile.
Si aggiungono, tra l’altro, informazioni sulla quantizzazione, parti memorizzate in altri formati, buffer del runtime e memoria per il contesto. Sono determinanti il file effettivo e il runtime scelto. GGUF, per esempio, contiene metadati oltre ai tensori e supporta diversi formati di quantizzazione. Hugging Face: GGUF e quantizzazione (link esterno).
Una finestra di contesto più ampia richiede memoria aggiuntiva. Per questo la lunghezza dell’input desiderata viene documentata esplicitamente nella prova. Una breve chat con un input ridotto dice poco sul successivo lavoro con documenti lunghi. Ollama: lunghezza del contesto e memoria necessaria (link esterno).
Una GPU deve essere compatibile con l’intero ambiente
La scelta dipende dalla memoria grafica utilizzabile, dai driver e dal runtime supportati, dall’assorbimento elettrico, dal raffreddamento e dallo spazio di installazione. Due schede con nomi commerciali simili possono avere quantità di memoria diverse. Anche il fatto che il sistema operativo riconosca una scheda non significa che il runtime del modello la utilizzi correttamente.
Prima dell’acquisto si verificano quindi il modello esatto della scheda, il sistema operativo e la versione del driver rispetto al supporto attuale del runtime. Ollama documenta percorsi diversi per NVIDIA, AMD, Apple Metal e altri backend. Questo non implica il supporto generale di ogni scheda di una marca. Ollama: supporto hardware attuale (link esterno).
Il contributo di NVMe e Linux
Un SSD NVMe è un’opzione sensata nella pianificazione dei file dei modelli locali, degli aggiornamenti e dei dati di lavoro. Lo spazio libero viene riservato ai modelli effettivamente utilizzati e alle versioni aggiuntive. Un’unità più capiente non sostituisce però la RAM o la memoria grafica; anche un SSD veloce non rende automaticamente utilizzabile in modo interattivo un modello troppo grande.
Linux può essere adatto a un servizio gestito in modo continuativo se driver, manutenzione e responsabilità sono compatibili con l’azienda. Ollama descrive, tra l’altro, il funzionamento come servizio di sistema dedicato. Il sistema operativo viene scelto in base all’ambiente esistente; non deve essere introdotto nuovamente su ogni postazione. Ollama: gestione su Linux e aggiornamento delle versioni (link esterno).
Un breve progetto pilota produce una lista di acquisti più utile
- Definire un compito: per esempio creare una bozza da appunti approvati, prima di collegare l’intero archivio delle conoscenze.
- Annotare le condizioni della prova: versione del modello, quantizzazione, contesto, hardware e altre applicazioni in esecuzione.
- Valutare i risultati: correttezza dei contenuti, correzioni necessarie e lavoro effettivamente risparmiato.
- Misurare le attese: input tipici e più lunghi, insieme all’utilizzo simultaneo previsto.
- Verificare anche la gestione: percorsi dei dati, autorizzazioni, aggiornamenti, backup e ripristino del servizio.
La procedura di verifica più dettagliata è descritta nell’articolo Provare l’IA locale: un progetto pilota con un carico significativo. Per il passaggio a un servizio condiviso, Ollama e Open WebUI nella rete aziendale spiega la suddivisione tra accesso, interfaccia e modello.
Usare bene ciò che c’è e integrare in modo mirato
Per iniziare può bastare un computer già disponibile. Se il progetto pilota dimostra un’utilità concreta, si procede con un potenziamento mirato o con la pianificazione di un servizio dedicato. Per compiti rari o particolarmente impegnativi può essere conveniente anche un’API cloud approvata o un modello ibrido. Sono decisivi i dati, la qualità, l’utilizzo e l’impegno di gestione.
DAXS aiuta a valutare queste opzioni e a integrarle nell’IT esistente. Per iniziare sono disponibili LLM locali e infrastruttura e la richiesta di consulenza su IA e automazione.
Fonti: i valori di memoria sono scenari di pianificazione espressamente descritti oppure un calcolo teorico dei pesi. Non costituiscono un benchmark, un’offerta economica o la dimostrazione del supporto di un determinato numero di utenti. La licenza del modello specifico e la compatibilità del sistema vengono verificate prima dell’utilizzo.
