Modello senza GPU: quando la CPU basta davvero

La maggior parte delle guide sull'IA locale parte da una domanda: "Quanta VRAM mi serve?" È la domanda giusta se vuoi velocità. Ma non è l'unica. C'è un secondo modo di vivere l'inferenza locale che nel 2026 è diventato pienamente legittimo: far girare il modello solo sulla CPU, senza alcuna GPU dedicata. Non è più un ripiego per chi non ha una scheda video, ma una scelta ragionata che funziona bene per una fascia precisa di usi.

In questo articolo ti diciamo quando la CPU basta davvero, a quale velocità puoi realisticamente aspettarti di arrivare, come misurare il tuo hardware in cinque minuti e quali leve usare per strappare il massimo a un processore. Non ripetiamo la teoria GPU vs CPU (c'è già un articolo dedicato): qui parliamo di pratica.

Perché l'inferenza su CPU oggi non è più un ripiego

La ragione è semplice e misurabile. Decodificare un token su una CPU è un problema di banda di memoria, non di calcolo puro: per ogni token il processore deve leggere i pesi del modello dalla RAM. Se la tua RAM è abbastanza veloce e il modello (quantizzato) sta tutto in memoria, la CPU produce token a un ritmo costante e prevedibile.

Facciamo i conti. Una workstation moderna con DDR5 a doppio canale ha circa 60–70 GB/s di banda. Una GPU di fascia media, la RTX 3060 12GB, ha 360 GB/s di banda sulla VRAM. Prendi un modello da 8B parametri quantizzato a 4 bit, cioè circa 5 GB di pesi:

• Su CPU a 64 GB/s, la decodifica si aggira attorno a 10–12 token al secondo.
• Sulla RTX 3060, a parità di modello, sei tra i 60 e i 90 token al secondo.

Il rapporto è grosso modo la banda: 64 contro 360. La CPU non sta perdendo perché è lenta, ma perché legge i pesi da un bus più stretto. La differenza è enorme, ma è strutturale e prevedibile, non casuale. E su un certo tipo di uso quella differenza non cambia nulla.

C'è anche una seconda fase, il prefill, in cui il modello legge il tuo prompt in un colpo. Qui la CPU perde molto di più, perché il prefill è un problema di calcolo parallelo e la GPU vince netta. Se il tuo prompt è lungo, l'attesa prima della prima risposta è il punto debole della CPU. Tenendolo a bada (prompt brevi, contesto ridotto) il limite diventa gestibile.

Quando la CPU basta davvero

Questi sono i casi in cui, a parità di risultato, la CPU non ti costa nulla.

1. Modelli piccoli, sotto i 4B. Un modello da 0,5B a 4B quantizzato a 4 bit pesa tra 0,4 e 2,5 GB. Sulla CPU lo fai girare a velocità da chat: 20–40 token al secondo per i più piccoli. Per riassunti, classificazione, riorganizzazione del testo, estrazione di campi, completamenti brevi, è più che sufficiente. È il punto dove la CPU non ha solo «basta», ma vince su tutto il resto: zero costi, zero setup, funziona su qualsiasi macchina recente.

2. Conversazione a bassa frequenza. Se usi il modello per un certo numero di domande al giorno, con risposte medio-brevi, e non ti importa che la prima risposta arrivi in un secondo o in tre, la CPU è l'opzione più economica e affidabile. Non è per chi vuole un'esperienza in tempo reale, ma è più che adeguata per chi usa l'IA locale come uno strumento di lavoro, non come un chatbot reattivo.

3. Job batch e notturni. Tradurre un corpus, generare metadata, fare classificazioni di massa, produrre riassunti di centinaia di documenti: qui la velocità non è un problema, è il costo che accetti di pagare una notte. La CPU lavora a 8–15 token al secondo, e se il job è di mille documenti parti la sera e la mattina li hai. Nessun affitto, nessun picco di costo.

4. Edge e dispositivi sempre accesi. Raspberry Pi 5, mini-PC da 40–80 euro, un vecchio notebook con 16GB di RAM: questi sono i posti dove la CPU non è l'unica opzione, è l'unica opzione. Un modello da 1–3B quantizzato ci gira, lentamente ma ci gira, e ti permette di avere un assistente sempre disponibile senza mandare dati a nessun server.

5. Affidabilità prima della velocità. In un contesto produttivo piccolo (un bot interno, un flusso di triage, un summarizer su file ricevuti via email) la variabile più costosa non è il tempo di risposta, ma il fatto che il sistema sia sempre lì, senza dipendenze esterne. La CPU, su un mini-PC con ventole silenziose e 8W di consumo, è l'infrastruttura locale più semplice che esista.

Quando invece la CPU non basta: per conversazione reattiva, per modelli sopra i 14–20B, per generazione di immagini, per throughput alto. In questi casi serve una GPU, o almeno un'ibridazione CPU+GPU che copre parte del collo di bottiglia.

A quale velocità puoi realisticamente aspettarti

Questi sono numeri di riferimento su una workstation CPU tipica (8 core / 16 thread, DDR5 a doppio canale, RAM sufficiente). Il tuo sarà diverso: il fattore che conta è la banda della RAM.

Modello (4-bit)	Decodifica	Prefill	Uso
0,5B – 1B	25–45 tok/s	100–300 tok/s	chat, classificazione, completamento
3B – 4B	12–25 tok/s	50–150 tok/s	conversazione leggera, riorganizzazione testo
8B (dense)	8–15 tok/s	20–60 tok/s	conversazione accettabile, riassunti
8B – 14B (MoE)	15–35 tok/s	30–80 tok/s	MoE: meno pesi attivi → più veloce
14B – 30B	3–8 tok/s	10–30 tok/s	batch, uso non interattivo
30B+	sotto i 5 tok/s	molto lento	impraticabile per uso interattivo

Tre note importanti. Primo: i numeri di decodifica sono banda-limite, quindi dipendono quasi linearmente dalla banda della tua RAM. Passando da DDR4 a doppio canale (40 GB/s) a DDR5 a doppio canale (64 GB/s) guadagni il 50–60% sui token al secondo. Secondo: i modelli MoE (mixture of experts) sono una sorpresa gradita su CPU, perché per ogni token attivano solo una frazione dei pesi totali e quindi leggono meno memoria: un MoE da 30B con 3B attivi può superare un dense da 8B. Terzo: il prefill è dove la CPU soffre di più; se i tuoi prompt sono lunghi, qui perdi.

Come misurare il tuo hardware in 5 minuti

Non fidarti dei numeri di qualcun altro: misurali. Il procedimento standard è questo.

Scarica llama.cpp (compila o prendi un binario), scarica un modello GGUF di riferimento (Qwen3 8B Q4_K_M è lo standard de facto), e lancia il benchmark integrato:

./llama-bench -m modello.gguf -p 512 -n 128 -t <thread>

Il benchmark ti dà tre numeri: pp512 (prefill di 512 token) e tg128 (decodifica di 128 token). Sono i tuoi numeri di riferimento. Ripeti con -t 4, -t 8, -t 16 per trovare il punto di massima decodifica: solitamente coincide con il numero di core fisici, non logici.

Poi verifica il collo di bottiglia reale durante l'uso:

perf stat -e cache-misses,cycles ./llama-cli -m modello.gguf

Se cache-misses è alto e i core sono saturi ma la RAM non, il collo è la banda di memoria e non c'è molto da fare: o modello più piccolo o RAM più veloce. Se i core non arrivano al 100%, hai troppo poco thread o una limitazione SMT (hyperthreading): prova a ridurre i thread. Se la RAM fisica è in esaurimento (scambio su disco), il modello non ci sta: scendi di quantizzazione o di dimensioni.

La regola d'oro è: misura sempre il tuo hardware con il tuo modello e la tua quantizzazione. Un 8B Q4_K_M su una macchina con 64 GB/s fa 11 tok/s; lo stesso modello su una macchina con 40 GB/s ne fa 7. La differenza è 33%, e non la trovi su nessun blog.

Le leve per spremere la CPU

Qui è dove si recupera la maggior parte della performance. Quattro leve, in ordine di impatto.

1. Thread e core. Il numero di thread ottimali per la decodifica è quasi sempre il numero di core fisici, non logici. Su una CPU a 8 core / 16 thread, -t 8 batte -t 16 nella maggior parte dei casi: gli SMT raddoppiano la conteggiata ma non la banda. Testa e verifica con llama-bench.

2. Quantizzazione. La quantizzazione a 4 bit (Q4_K_M) è il punto di equilibrio: qualità ancora alta, dimensione dimezzata rispetto all'8 bit, velocità doppia. Scendere a Q3 o Q2 guadagna velocità ma perde qualità in modo percepibile; salire a Q5 o Q8 non ha senso su CPU perché il collo è la banda. Il formato GGUF è pensato proprio per questo: un solo file, pesi già quantizzati, nessuna dipendenza.

3. Flash attention. La flash attention riduce la memoria letta durante la decodifica e il prefill, con un guadagno particolarmente marcato sui contesti lunghi. In llama.cpp si attiva con la flag -fa: è una cosa sola da aggiungere alla riga di comando e il beneficio è misurabile. Se la tua versione è recente, attivala e fai il before/after con llama-bench: sul tuo hardware il miglioramento è più prevedibile di qualsiasi numero riportato da un blog.

4. Speculative decoding. La tecnica più elegante: un modello piccolo (draft) produce una serie di token velocemente, e il modello grande li verifica tutti in un unico passo di prefill. Se il draft indovina bene — e per la maggior parte dei task di uso comune lo fa — il risultato è un moltiplicatore di 2–3 volte sulla velocità di decodifica senza perdita di qualità. Su CPU, dove la decodifica è il collo di bottiglia, è la leva più potente.

E una quinta, per i modelli grandi: mmap. Mappare i pesi in memoria (--mmap) permette all'OS di caricare in RAM solo i pesi necessari e tenere il resto su disco. Significa che un modello che non sta in RAM può comunque girare, a velocità ridotta ma non nulla. Il trade-off è che ogni accesso su disco è molto più lento di uno su RAM: mmap è una via di uscita, non una soluzione.

Per il serving, Ollama gestisce già tutto questo in background: un singolo comando ollama serve, e i modelli girano con la configurazione giusta per la tua macchina. La release v0.35.0 ha anche aggiunto il supporto ai modelli di decisione in stile Jev, che producono output strutturati per classificazione ed evaluation — esattamente il tipo di carico che va benissimo su CPU. Per carichi batch o di serving, vLLM supporta anche la CPU (tramite OpenMP), anche se il suo cuore è la GPU: è la scelta giusta se un giorno vuoi servire più utenti in parallelo.

Il quadro nel 2026

Il punto è questo: l'inferenza su CPU nel 2026 non è un caso d'angolo. llama.cpp continua a investire specificamente sul lato CPU: la serie di release di ottobre (la più recente è b11337) ha ampliato la matrice di backend per CPU ed edge — Snapdragon con Adreno e Hexagon, OpenVINO, SYCL FP16, CUDA 13, Android — e i modelli diventano sempre più efficienti: i MoE riducono la memoria attiva, le quantizzazioni diventano più aggressive senza perdere qualità.

E il movimento va nella direzione giusta anche dal lato dei modelli: Cloudflare ha reso pubblico clef, un modello da 27B che trasforma uno stato e un insieme di domande tipizzate in decisioni strutturate — probabilità per ogni opzione in un unico passo, senza generazione di testo libero — con una variante più piccola e veloce (clef-flash) pensata per i carichi a bassa latenza. Non è un chatbot: è esattamente la classe di modelli — output strutturati, inferenza breve, latenza minima — che è quella che va bene su CPU. Il confine tra "modello da GPU" e "modello da CPU" si sta spostando verso l'alto, e i modelli compatti e MoE con pesi attivi bassi stanno diventando la classe più interessante per l'inferenza locale su CPU.

La domanda non è più "posso far girare un modello senza GPU?". La domanda è: "il mio uso specifico ha bisogno di più di 15 token al secondo?". Se la risposta è no, la CPU non solo basta: è la scelta migliore.

In sintesi

• La CPU è sufficiente per modelli sotto i 4B, conversazione a bassa frequenza, job batch, edge e affidabilità.
• La decodifica su CPU è banda-limite: la velocità dipende dalla banda della RAM, non dalla frequenza del processore.
• I modelli MoE sono la sorpresa: meno pesi attivi → più veloce a parità di parametri totali.
• Misura sempre con llama-bench i numeri prefill e decodifica del tuo setup.
• Le leve in ordine di impatto: thread = core fisici, quantizzazione Q4_K_M, flash attention, speculative decoding.
• Per serving: Ollama per uso singolo, vLLM per batch e multi-utente.
• Il confine tra "modello da CPU" e "modello da GPU" si sta spostando verso i 20–30B: nel 2027 la CPU farà girare modelli che oggi consideri da GPU.

Articolo generato con IA