AI locale su PC: guida hardware e modelli offline
La AI on-device è la capacità di eseguire modelli offline direttamente sul proprio computer, senza dipendere dal cloud. In questo contesto rientrano LLM per testo modelli di diffusion per immagini e reti per audio o visione. Il cuore della scelta è capire come combinare CPU, GPU o NPU, quanta RAM serva davvero, quale storage privilegiare e come gestire calore e rumore. Questa guida illustra principi solidi per progettare o ottimizzare un PC capace, stabile e sostenibile.
È rilevante perché permette privacy controllo dei costi e latenza prevedibile. Un sistema ben bilanciato riduce sprechi, evita colli di bottiglia e consente di usare quantizzazione e runtime efficienti. L’articolo segue un percorso pratico: architettura CPU/GPU/NPU, memoria e dischi, differenze tra LLM e diffusion, quantizzazione e toolchain, benchmark realistici e profili di build per diversi budget e scenari d’uso.
CPU, GPU e NPU: architettura e ruoli
La CPU gestisce il coordinamento e offre prestazioni per thread singolo, utili a LLM leggeri e a pipeline con operatori non accelerati. Molti modelli testuali possono girare su CPU con quantizzazione spinta e librerie ottimizzate. La GPU eccelle nei calcoli paralleli: serve per diffusion, vision e LLM di dimensioni medio-grandi, grazie a VRAM ampia e throughput elevato. Le NPU dedicate, integrate o discrete, accelerano operatori comuni a bassi consumi, ideali per assistenti locali e inferenze continue. La scelta si basa su carico tipico, budget energetico e necessità di portabilità.
In generale, per diffusion conviene prioritizzare una GPU con sufficiente VRAM mentre per LLM piccoli o medi una CPU moderna con molte cache e set istruzioni ottimizzati può sorprendere. Le NPU offrono vantaggi in efficienza e autonomia ma richiedono modelli e runtime compatibili. La vera chiave è l’equilibrio: una CPU capace evita colli di bottiglia alla GPU, e una GPU proporzionata evita sprechi di denaro e calore. Considerare sempre il TDP e la qualità della scheda madre per alimentazione stabile.
RAM e storage: colli di bottiglia e scelte pratiche
La RAM determina la fluidità nella gestione dei pesi modello, dei buffer e del contesto. Per LLM a media lunghezza di contesto, una dotazione generosa riduce swap e latenza. Frequenza e latenza aiutano, ma la capacità resta prioritaria. Lo storage incide sul tempo di caricamento: SSD NVMe con buone prestazioni in lettura random riducono i tempi di avvio dei modelli. Mantenere i checkpoint più usati su storage veloce e archiviare il resto su unità capienti è una strategia solida.
Attenzione al PCIe collegamenti ridotti possono limitare la banda tra CPU e GPU, influenzando l’upload dei pesi e lo streaming. Evitare mix disomogenei che costringono a paging aggressivo tra RAM e VRAM. Per chi gestisce collezioni di modelli, considerare SSD dedicati e una struttura di cartelle ordinata, utile a toolchain e backup. Un file system con compressione leggera può aiutare con checkpoint ripetitivi, bilanciando spazio e prestazioni.
LLM offline vs diffusion: carichi, dimensioni e VRAM
Gli LLM sono sensibili a larghezza di banda memoria e ottimizzazioni del grafo; il carico è spesso sequenziale misurato in token al secondo. Con quantizzazione adeguata, modelli medio-piccoli possono risiedere in RAM o VRAM limitata. La diffusion, invece, richiede molti operatori convoluzionali e attenzione alla precisione numerica: step per immagine, risoluzione e sampler definiscono la richiesta di VRAM e tempo. La differenza pratica è che la diffusion scala quasi linearmente con la GPU, mentre gli LLM traggono beneficio anche da CPU/NPU capaci.
Per LLM lunghi, la gestione del context aumenta memoria e latenza; batching e kv-cache on-device vanno pianificati. Nella diffusion, risoluzioni più alte e pipeline di controllo (ad esempio mask o conditioning) moltiplicano l’uso di VRAM. Chi crea immagini ambiziose privilegerà una GPU con più memoria e bus ampio; chi scrive o sviluppa agenti locali può preferire memoria di sistema abbondante e una CPU robusta, mantenendo la GPU come acceleratore opzionale.
Quantizzazione e toolchain: come far entrare i modelli
La quantizzazione riduce la precisione dei pesi (ad esempio int8int4) per comprimere i modelli e accelerare l’inferenza, con una perdita di qualità spesso tollerabile. Per LLM, formati ottimizzati e schemi misti (peso quantizzato, attivazioni a precisione più alta) offrono un buon compromesso tra memoria e fedeltà. Per diffusion, la quantizzazione è più delicata: molte pipeline preferiscono fp16 o ibridi per preservare dettagli e stabilità del campionamento. Conviene testare profili diversi e scegliere in base all’uso reale.
Le toolchain contano quanto l’hardware. Runtime generici e compilers per grafi (ad esempio ONNX e motori specifici della GPU/NPU) permettono fusione di operatori e uso della memoria più efficiente. Librerie ottimizzate per CPU sfruttano vettorizzazione e thread pinning; per GPU, kernel custom e attenzione ai driver riducono la latenza. Integrare un sistema di logging della memoria e profili ripetibili aiuta a capire dove intervenire: spesso il guadagno più grande arriva da pipeline pulite, non dal solo upgrade di componenti.
Benchmark realistici: metriche che contano
Per gli LLM, misurare token/s latenza al primo token e stabilità sotto carico prolungato è più utile dei picchi teorici. Valutare anche l’uso di RAM e VRAM con contesti diversi e batching variabile. Per diffusion, osservare step/s tempo per immagine a una risoluzione specifica e consumo energetico. I benchmark devono riflettere il proprio flusso di lavoro: prompt tipici, lunghezze realistiche, modelli effettivamente usati. Evitare configurazioni “da laboratorio” che mascherano i veri colli di bottiglia.
Un approccio sano è creare scenari riproducibili: stesso seed stessi hyperparameter, identiche librerie. Documentare versioni di runtime e impostazioni di precisione evita confronti fuorvianti. Valutare il rumore acustico e le temperature massime durante i test: un sistema che regge lunghe sessioni senza throttling fornisce prestazioni percepite migliori di una macchina più veloce solo per pochi minuti.
Profili di build: dev, creator, privacy-first
Essenziale, privacy-first (assistente locale, note, trascrizioni):
- CPU solida con buone prestazioni per core; NPU integrata se disponibile; GPU opzionale o di fascia contenuta.
- RAM abbondante rispetto al budget; SSD NVMe di qualità per tempi di caricamento brevi.
- Dissipatore silenzioso a torre o AIO compatto; case con airflow lineare; alimentatore efficiente.
Bilanciato, developer (LLM medi, fine-tuning leggero, toolchain mista):
- CPU multi-core con cache ampia; GPU con VRAM moderata; valutare NPU per inferenze a basso consumo.
- RAM capiente per contesti lunghi e build; SSD NVMe principale + SSD secondario per dataset.
- Airflow curato, più ventole a basso regime; margine sull’alimentatore; monitoraggio termico continuo.
Alto profilo, creator (diffusion ad alta risoluzione, video, control pipelines):
- GPU con molta VRAM e buona banda; CPU che non limiti l’upload dei pesi; storage NVMe veloce e capiente.
- RAM adeguata a editing e multitasking pesante; eventuale RAID per asset e cache.
- Dissipazione liquida o aria di fascia alta; case spazioso; gestione cavi per pressione positiva e silenzio.
Una regola trasversale: pianificare la crescita. Lasciare slot RAM liberi, linee PCIe disponibili e un alimentatore con riserva evita ricostruzioni premature. La macchina ideale per AI on-device non è la più estrema, ma quella più coerente con i propri modelli, i tempi di lavoro e il comfort termico-acustico quotidiano.
