Il 2026 è diverso: l’IA locale è di serie, ma non tutto si accelera allo stesso modo

Nel 2026 i sistemi operativi principali includono funzionalità di IA sul dispositivo e molte app si affidano ad accelerazione eterogenea. In Windows 11, funzioni come Recall e Windows Studio Effects sfruttano la NPU per scaricare lavoro da CPU e GPU, con soglie minime di prestazioni chiaramente definite. In macOS, Apple Silicon integra CPU, GPU, un Neural Engine e memoria unificata che favoriscono carichi misti. In Linux, la maturità dei percorsi CUDA/ROCm e Vulkan continua a dettare il ritmo per creatori e sviluppatori.

La conseguenza pratica: non esiste una singola “specifica IA”. Un portatile che eccelle nel montaggio video con effetti camera in tempo reale può non essere il migliore per inferire un grande LLM o per generare immagini in batch. Questa guida scompone, con criteri verificabili, il ruolo di ciascun acceleratore, quanta memoria serve davvero a un 7B/13B/70B con diverse quantizzazioni, e come tradurre il tutto in decisioni d’acquisto realistiche per i prossimi 3–6 mesi. Inoltre, chiarisce il significato di metriche comuni (TOPS, token/s, latenze) e come collegarle ai tuoi flussi di lavoro senza cadere in confronti poco utili tra architetture diverse.

CPU, GPU e NPU: chi fa cosa e con quali API

- CPU: orchestra, gestisce pre/post‑processing e da sola basta per modelli piccoli o tooling (tokenizzazione, I/O). Quando la libreria non ha un backend accelerato, la CPU è il paracadute universale. La metrica utile è la resa in virgola mobile per thread e la disponibilità di istruzioni vettoriali; oltre 8–10 thread lo scaling perde efficienza per gli LLM a causa dei colli di bottiglia della memoria. Contano anche la latenza di accesso e la banda sostenuta della memoria, perché prefill e aggiornamento della cache KV sono sensibili a questi percorsi anche quando parte del calcolo vive su un acceleratore.

- GPU: domina con tensori grandi e batch; è la via principale per LLM medi e generazione di immagini. In Windows, il percorso “agnostico” passa per Windows ML con ONNX Runtime e la sua politica di selezione dei provider di esecuzione; su NVIDIA, CUDA resta il percorso più maturo; su AMD, ROCm abilita i kernel HIP. Vulkan e WebGPU spingono la portabilità del compute, soprattutto in app e browser moderni. In pratica, le GPU offrono throughput migliore quando puoi raggruppare richieste (batching) o quando l’app concatena più fasi tensoriali con operatori ben supportati dal backend scelto.

- NPU: accelera l’inferenza a bassa latenza e consumo per modelli ottimizzati (vision, effetti camera, assistenti del SO, parti di LLM compatti). In Windows, alcune esperienze di sistema richiedono una soglia ~40 TOPS sulla NPU. In macOS, il Neural Engine convive con GPU/Metal e la conversione a Core ML decide cosa cade su ANE e cosa su GPU. La chiave con le NPU è che il percorso di esecuzione sia predisposto per sfruttarle; senza quel percorso, il lavoro ricadrà su GPU o CPU anche se il dispositivo dispone di NPU.

Modelli e memoria: 7B/13B/70B in fp16, int8 e 4 bit, e perché RAM/VRAM comandano

La memoria necessaria si divide in due parti: pesi del modello e cache KV. Regola rapida: pesi ≈ byte_per_parametro×n_parametri; fp16/bf16 ≈ 2 B/param, int8 ≈ 1 B/param, 4 bit ≈ 0,5 B/param. Quindi un 7B in fp16 è ~14 GB solo di pesi; lo stesso 7B quantizzato a 4 bit scende a ~3–4 GB, con un po’ di perdita di qualità. La cache KV può sommare diversi GB con contesti lunghi o alta concorrenza e spesso fa collassare VRAM/RAM prima dei pesi. La cache KV cresce con la lunghezza di contesto effettiva e con la profondità del modello, quindi dimensiona in base al tuo uso tipico (catene di strumenti con contesto esteso vs prompt brevi).

Nell’uso da portatile, un 7B quantizzato entra e risponde in modo fluido con 8–16 GB disponibili al processo; un 13B richiede 16–24 GB per stare comodo; un 70B in 4 bit tocca già 40 GB solo in pesi e richiede sistemi con molta memoria unificata o overflow in RAM. Se la tua GPU ha VRAM limitata, spostare la cache KV nella RAM di sistema o suddividere il modello tra GPU e CPU/NPU può tenere in vita la sessione, ma aumenta la latenza. Considera anche il costo del loader e delle librerie del runtime, che aggiungono qualche centinaio di MB e possono fare la differenza quando il budget di VRAM è al limite.

NPU nel 2026: come leggere i TOPS e quando la GPU comanda ancora

I TOPS misurano operazioni intere al secondo (tipicamente int8/int4) sotto ipotesi specifiche del vendor. Servono a filtrare la compatibilità minima del sistema e a stimare classi di compiti in tempo reale (per esempio effetti camera, traduzione live, piccole reti di visione), ma non sostituiscono metriche di compito come token/s o latenza P95 sul tuo modello. In Windows, funzioni di sistema come Recall e il livello superiore di Studio Effects attivano requisiti minimi attorno ai 40 TOPS sulla NPU, insieme a condizioni di memoria e sicurezza del dispositivo. Nel confronto tra macchine, interpreta i TOPS come una soglia di capacità, non come una scala lineare di prestazioni tra marchi o generazioni.

Per LLM medi o diffusione in batch, la GPU resta davanti per throughput e copertura operatori. La NPU vince quando l’app è adattata (via Windows ML/ONNX Runtime con politica “prefer NPU” o in Core ML con layer compatibili) e quando conta l’autonomia: si osservano spesso risparmi energetici sostanziali rispetto alla GPU su carichi continui a bassa potenza, con limiti sugli operatori e sulla taglia del modello. In scenari misti, una strategia efficace è lasciare il prefill pesante alla GPU e scaricare su NPU i processi di visione o post‑processing, contenendo i consumi senza penalizzare troppo la latenza percepita.

Windows, macOS e Linux: stato reale di toolchain e compatibilità

- Windows (ARM e x86): Windows ML offre un livello uniforme su ONNX Runtime e consente di scegliere un execution provider (CPU, NPU, GPU via DirectML, CUDA, ecc.) o di lasciare che una politica selezioni «massime prestazioni» o «massima efficienza». DirectML si appoggia a qualsiasi GPU compatibile con DirectX 12, utile per hardware vario e per deployment che non dipendono da un singolo vendor. Per app che già usano ONNX Runtime, adottare una politica come MAX_EFFICIENCY o PREFER_NPU è un modo pratico per bilanciare prestazioni e autonomia senza riscrivere operatori.

- macOS (Apple Silicon): il flusso consigliato è convertire a Core ML (con coremltools) e lasciare che Metal/ANE esegua in base alla compatibilità. La memoria unificata semplifica i carichi misti (modello su GPU, pre‑processing su CPU/ANE) e, sulla generazione M5, sono offerte configurazioni fino a 128 GB unificati con maggiore banda, utile per contesti lunghi nei LLM e batch nella creazione di contenuti. In progetti che mescolano visione, audio e testo, questa unificazione riduce le copie tra dispositivi e può tradursi in latenze più stabili sotto carico.

- Linux: CUDA resta il percorso più rifinito su NVIDIA; ROCm abilita le AMD recenti con una matrice di compatibilità da controllare prima dell’acquisto. Per soluzioni portabili e ambienti senza CUDA/ROCm, Vulkan offre compute generale, e alcuni runtime sperimentano percorsi via SPIR‑V. Nell’open‑source, progetti come llama.cpp espongono backend multipli (CPU/Metal/CUDA/ROCm/Vulkan) con maturità diversa. Prima di scegliere piattaforma, verifica che il backend prescelto supporti gli operatori critici del tuo modello e che le dipendenze (driver, kernel, librerie) siano su versioni compatibili.

Storage, I/O e porte: perché 1–2 TB NVMe non è un capriccio

I file dei modelli occupano spazio reale anche quantizzati: un 7B vale ~3–4 GB; un 13B ~7–8 GB; un 70B ~35–40 GB a 4 bit. Se prevedi di alternare famiglie (Llama, Mistral, embedding, TTS, VAD) e mantenere più quantizzazioni/versioni, 1–2 TB NVMe evitano pulizie continue. La lettura sequenziale di modelli grandi favorisce l’avvio della sessione e il reload dopo sospensione; avere margine libero aiuta paging e cache del framework. Mantenere un singolo volume NVMe veloce semplifica la gestione dei checkpoint e riduce la tentazione di spostare i modelli su supporti più lenti che poi penalizzano il tempo al primo token.

In connettività, Thunderbolt 5 e USB4 v2.0 alzano il tetto di banda per SSD esterni o eGPU (dove supportato) e per monitor 8K/alte frequenze. Per i carichi IA, il vantaggio pratico è collegare storage esterno veloce condividendo il bus senza strozzare la GPU interna. Se lavori con chassis esterni o dock, verifica certificazione e versione per evitare colli di bottiglia. E se il tuo flusso dipende dallo spostamento di modelli tra macchine, valuta un SSD NVMe esterno in box compatibile TB5/USB4 v2.0: i tempi di copia e caricamento migliorano sensibilmente rispetto all’USB legacy quando i progetti occupano molti gigabyte.

Come misurare le prestazioni utili e tradurle in profili d’acquisto

Le metriche che contano: 1) token/s sul tuo modello e quantizzazione con contesto tipico; 2) latenza del primo token (prefill) e di decodifica; 3) throughput per batch in generazione di immagini/audio. Evita TOPS grezzi o FLOPS teorici senza legame con la tua pipeline (tokenizer, cache KV, streaming). Quando possibile, usa benchmark riproducibili e open del runtime che intendi impiegare. Completa con prove energetiche quando l’autonomia è prioritaria: il divario tra NPU e GPU in carichi prolungati a bassa potenza può essere decisivo anche se il tempo totale è simile.

Profili minimi indicativi, se acquisti tra Q4 2026–Q1 2027: 1) Chat locale 7B (4 bit), multitasking leggero: CPU moderna 8 core, GPU integrata o dGPU modesta, 16 GB di RAM e NPU se dipendi da funzioni del SO; 2) Assistente al codice e trascrizione accelerati: dGPU con ≥ 8–12 GB di VRAM o Apple Silicon con ≥ 24–32 GB unificati; 3) Diffusione d’immagini in batch e LLM 13B comodo: dGPU ≥ 16 GB VRAM o memoria unificata ≥ 48–64 GB; 4) Laboratorio locale con 70B 4 bit: sistemi con ≥ 64–96 GB effettivi (unificati o somma RAM+overflow), accettando compromessi di latenza. Regola operativa: dai priorità alla memoria sufficiente rispetto a piccole differenze di TOPS/FLOPS e verifica che le API previste (Windows ML/DirectML, Core ML, CUDA/ROCm, Vulkan/WebGPU) funzionino con il tuo stack software.