Che hardware serve per far girare un LLM in locale? Una guida ragionata, dal MacBook al cluster da 8 GPU

Un venerdì sera, alle 17:21

Il 12 giugno 2026, alle 17:21 ora di New York, Anthropic riceve una lettera dal Dipartimento del Commercio statunitense. È una direttiva di export control, emessa in base all'Export Controls Reform Act del 2018. Il contenuto è secco: sospendere ogni accesso a Fable 5 e Mythos 5 — i due modelli più potenti dell'azienda, lanciati pochi giorni prima — da parte di qualsiasi cittadino straniero, dentro o fuori dagli Stati Uniti, inclusi i dipendenti non statunitensi di Anthropic stessa. Non potendo separare in tempo gli utenti stranieri da quelli americani, Anthropic fa l'unica cosa possibile per essere conforme: spegne entrambi i modelli per tutti, in tutto il mondo, nel giro di poche ore.

Non è un bug. Non è una scelta commerciale. È una decisione geopolitica presa altrove, su cui i clienti non hanno avuto né voce né preavviso. È anche la prima volta che gli Stati Uniti usano i controlli sull'export non sui chip, ma direttamente su un modello.

Fermiamoci a leggere bene quella riga: il blocco colpisce i cittadini stranieri. Se siete un'azienda europea — come noi, come molti dei nostri clienti — voi siete il cittadino straniero. Siete esattamente la categoria che è stata tagliata fuori da un giorno all'altro. Se aveste costruito un prodotto, un flusso di lavoro o una pipeline su quel modello, ve li sareste trovati spenti il sabato mattina, per una lettera arrivata in un ufficio dall'altra parte dell'oceano.

È la dimostrazione più nitida possibile di cosa significhi costruire sul modello di qualcun altro, dietro il confine di qualcun altro. E rende una domanda, fino a ieri un po' accademica, improvvisamente molto concreta: cosa vuol dire mettere un LLM “in casa”?

La risposta è semplice nel principio: quando fai girare un modello open sul tuo hardware, i pesi sono sul tuo disco, l'inferenza gira sul tuo ferro, e nessuna direttiva, di nessun governo, può spegnertelo con una lettera. Non è una questione di nazionalità del modello — GPT-OSS è americano quanto Fable — ma di controllo operativo: un modello che possiedi non te lo può revocare nessuno da remoto, e il dato non esce dal tuo perimetro. Per chi lavora con clienti regolati (DORA, NIS2), questo cessa di essere un vezzo e diventa un requisito.

La buona notizia è che i modelli open di oggi sono davvero capaci. In questo articolo li useremo come esempi concreti — gli open di OpenAI GPT-OSS 20B e 120B (licenza Apache 2.0) e la famiglia aperta di Google Gemma (da non confondere con Gemini, che è chiuso e in casa non si può mettere) — per mostrare esattamente cosa gira su cosa. Ragioniamo ad ampio spettro: dai Mac che molti sviluppatori hanno già sulla scrivania, fino ai nodi enterprise da 8 GPU.

I due numeri che decidono tutto (più un terzo)

Prima di parlare di marche e modelli, bisogna interiorizzare due grandezze. Tutto il resto è conseguenza.

1. La capacità di memoria (VRAM): decide se il modello entra. Un modello occupa spazio in memoria pari ai suoi parametri moltiplicati per i byte di ciascuno: 2 byte in FP16/BF16, 1 byte in FP8, mezzo byte in INT4/FP4. Un modello da 70 miliardi di parametri vuole quindi ~140 GB in FP16, ~70 GB in FP8, ~35 GB in INT4. A questo va aggiunta la KV cache, che cresce con la lunghezza del contesto. Se il modello più la sua cache non entrano nella memoria, semplicemente non parte.

2. La banda di memoria: decide quanto veloce genera. La generazione di token, uno dopo l'altro, è limitata dalla velocità con cui la GPU legge i pesi dalla memoria (è memory-bound). Più banda, più token al secondo. È questo il motivo per cui una scheda con HBM a 3 TB/s “frusta” un'APU con memoria unificata a 250 GB/s anche se entrambe possono contenere lo stesso modello.

C'è poi un dettaglio che cambia le carte con i modelli moderni: i Mixture-of-Experts (MoE). GPT-OSS 120B ha ~117 miliardi di parametri totali ma ne attiva solo ~5 a ogni token; GPT-OSS 20B ne ha ~21 totali e ~3,6 attivi. La VRAM la occupano tutti (i pesi vanno tenuti in memoria); la velocità, invece, dipende solo da quelli attivi. Risultato: questi modelli sono grandi da contenere ma veloci da eseguire — GPT-OSS 20B su una scheda da 24 GB gira a ~136 token/s, alla velocità di un modello da 7B pur essendone grande tre volte tanto. È proprio ciò che li rende interessanti sull'hardware “leggero”.

3. La concorrenza: decide se servite una persona o una squadra. È l'asse più sottovalutato. Far girare un modello per voi stessi è un conto; servirlo a 10 sviluppatori contemporaneamente è un altro. La concorrenza vera richiede un motore di serving come vLLM (con continuous batching e PagedAttention), che gira sulle GPU NVIDIA/AMD da datacenter ma non sui Mac e solo parzialmente sulle APU. È questa la linea di confine tra una “macchina da sviluppatore” e un “server”.

Teniamo a mente questi tre assi — entra / quanto veloce / per quanti — e percorriamo lo spettro.

Livello 1 — Apple Silicon: Mac mini, MacBook Pro, Mac Studio

La sorpresa, per chi viene dal mondo x86, è che un Mac sia un ottimo dispositivo per LLM. Il merito è dell'architettura a memoria unificata: CPU e GPU condividono un unico grande pool di RAM. Su un PC tradizionale la GPU è vincolata ai pochi GB della sua VRAM dedicata; su un Mac potete dedicare al modello decine di GB di memoria di sistema. In più lo stack software è maturo e liscio — llama.cpp con backend Metal, il framework MLX di Apple, LM Studio, Ollama — spesso più indolore del ROCm su AMD.

Il fattore discriminante tra i vari Mac è la banda, che sale con la fascia del chip:

• Mac mini (M4 / M4 Pro) — fino a 64 GB di unificata, ma banda contenuta (~120 GB/s sull'M4 base, ~273 GB/s sull'M4 Pro). È la macchina da test ed esperimenti, o per uno sviluppatore con modelli piccoli. Qui GPT-OSS 20B (~14 GB, qualità in classe o3-mini) è l'esempio perfetto: entra comodo, è veloce, ha un buon tool-calling. Bene anche Gemma 3 12B e i Qwen3 7B-14B.
• MacBook Pro (M4/M5 Max) — fino a 128 GB, ~546 GB/s. Qui salite a modelli da 30B quantizzati: Gemma 3 27B, Gemma 4, MoE leggeri da 30B. Con la mobilità del modello nello zaino.
• Mac Studio — il desktop. L'M4 Max dà 546 GB/s; l'M3 Ultra arriva a 819 GB/s ed è la macchina Apple più veloce per inferenza single-user. Su un M3 Ultra a 96 GB ci sta persino GPT-OSS 120B quantizzato (il checkpoint MXFP4 è ~61 GB). (Nota di attualità: per la carenza globale di DRAM, a metà 2026 i tagli di memoria alti del Mac Studio sono diventati difficili da ordinare — il configuratore tende a fermarsi sui 96 GB dell'M3 Ultra. Verificate sempre disponibilità e tempi di consegna.)

Il limite, però, è netto e va detto: niente vLLM su macOS. Il Mac è una macchina mono-utente (o per pochissimi). È perfetta per testare, prototipare, o dare a uno sviluppatore un modello locale di qualità — non per servire un team in concorrenza.

Livello 2 — AMD Ryzen AI Max+ 395 (Strix Halo): la memoria unificata su x86

La risposta del mondo PC all'idea di Apple. Lo Strix Halo è un'APU con fino a 128 GB di memoria LPDDR5X unificata, di cui ~96 GB allocabili come VRAM, GPU integrata Radeon 8060S e un NPU. Lo trovate nei mini-PC tipo Framework Desktop, GMKtec EVO-X2, MINISFORUM, a prezzi intorno ai 2.000-3.000 euro (la finestra di prezzo si è alzata parecchio con la crisi RAM) e con consumi bassissimi, ~130 W.

Il fascino è evidente: 128 GB di “VRAM” a quel prezzo non esistono altrove. Ma c'è il rovescio della medaglia, ed è proprio la banda: ~256 GB/s teorici, ~215 misurati. Sono circa un quarto di una RTX 4090 e un quindicesimo di un'H100. E siccome la generazione è memory-bound, quella banda è il tetto sulla velocità.

Tradotto in numeri reali, sui build attuali con llama.cpp/Vulkan:

• modelli MoE leggeri da ~30B (es. Qwen3 30B-A3B): 70-100 token/s — molto usabile;
• GPT-OSS 120B: ~53 token/s — notevole, per un modello da 117B su un mini-PC da duemila euro, ed è merito dei soli ~5B parametri attivi;
• Qwen3-Coder-Next 80B-A3B in Q4: ~42 token/s — usabile per un singolo sviluppatore;
• MoE giganti tipo 235B: ~11 token/s — gira, ma lento;
• modelli densi da 70B: ~5 token/s — qui la banda affossa tutto.

Si vede chiaramente il principio dei MoE: i modelli con pochi parametri attivi volano, quelli densi arrancano. Lo Strix Halo è quindi un'ottima macchina da sviluppatore on-prem — economica, a basso consumo, con il dato che non lascia la scrivania — purché si accetti che, esattamente come il Mac, è un dispositivo mono-utente: una macchina da programmatore, non un server.

Livello 3 — Il salto enterprise: le GPU NVIDIA

Qui si cambia categoria. Si ottengono due cose che né Mac né APU possono dare: banda da TB/s (HBM o GDDR7) e, soprattutto, vLLM e la concorrenza vera. Una GPU NVIDIA in un server Linux serve davvero un team intero. Vediamo le opzioni rilevanti, con costi, consumi e — punto che quasi tutti dimenticano — gli alimentatori necessari.

NVIDIA RTX PRO 6000 Blackwell (96 GB) — è il sweet spot per la maggior parte delle aziende. 96 GB di GDDR7 a ~1,79 TB/s, supporto nativo a FP8 e FP4, su una singola scheda PCIe. Un modello da 70-80B ci sta tutto con margine per la KV cache, e GPT-OSS 120B gira pulito su una sola scheda (cosa che su una 24 GB consumer è impossibile). Esiste in versione Workstation, Max-Q e Server Edition (passiva, per i rack). Prezzo intorno agli 8.500 dollari. Il prezzo da pagare, letteralmente, è il consumo: 600 W (la Max-Q scende a 300 W). Una sola di queste schede, sommata al resto del sistema, vuole un alimentatore robusto da 1.200-1.500 W con margine, e un raffreddamento serio. Non ha NVLink: più schede scalano come repliche, non come pool di memoria.

RTX A6000 / RTX 6000 Ada (48 GB) — la generazione precedente, ancora validissima. 48 GB a scheda, 300 W, più economiche e con driver maturi (zero grattacapi da early adopter). Per un modello da 70-80B, o per GPT-OSS 120B, ve ne servono due (in tensor-parallel). Curiosità utile: la vecchia A6000 (Ampere) ha NVLink e la coppia si collega bene; la 6000 Ada no ma in compenso ha l'FP8. Sono un'eccellente piattaforma per un trial a basso rischio.

NVIDIA H100 (80 GB) — la scheda da datacenter per eccellenza. 80 GB di HBM3, banda fino a ~3,35 TB/s (versione SXM) o ~2 TB/s (PCIe), NVLink sulle SXM. È la “casa” naturale di GPT-OSS 120B, che ci entra pulito a piena velocità. Consumo 350 W (PCIe) - 700 W (SXM), prezzo nell'ordine dei 25.000-30.000 euro a scheda. I sistemi SXM da 4-8 GPU richiedono alimentazione multi-kW e spesso raffreddamento a liquido.

NVIDIA H200 (141 GB) — l'evoluzione: 141 GB di HBM3e a ~4,8 TB/s. Più memoria e più banda dell'H100, è oggi una delle migliori schede per inferenza su modelli grandi. Costo e consumi ancora superiori (~700 W, 30.000+ euro).

Il tema elettrico merita una riga in più, perché è un vincolo fisico reale. Una scheda da 600 W è gestibile; un server con 4 GPU da 600 W significa 2.400 W di sole GPU, oltre 3-4 kW con il resto del sistema — più di quanto eroghi una normale presa domestica/ufficio da 16 A (~3,5 kW). A questi livelli servono alimentatori ridondati da 2.000+ W, circuiti dedicati e un piano di raffreddamento vero. L'hardware è solo metà del problema: l'altra metà è dove lo mettete.

Livello 4 — Cluster: il muro dell'interconnessione

Domanda naturale: se una scheda costa e ha poca memoria, perché non metto in rete tante macchine economiche — diverse APU, o PC con RTX 5090 da 32 GB l'una — e sommo la loro memoria per far girare un modello enorme?

Tecnicamente si può. In pratica si paga un prezzo durissimo, e il motivo è uno solo: la rete tra le macchine è ordini di grandezza più lenta della memoria. La memoria di una GPU va a TB/s; il collegamento tra due PC, anche con un buon USB4/Thunderbolt o 10GbE, rende sui ~10 Gbps reali — un divario di centinaia di volte. Quando spezzate un modello su più nodi collegati in rete, ogni token deve far rimbalzare dati tra le macchine attraverso quel collo di bottiglia. Strumenti come llama.cpp RPC, su modelli grandi, entrano in modalità “round robin”: passano l'elaborazione da un nodo all'altro in sequenza invece di parallelizzare, e la velocità crolla. Il software per il clustering AI, oggi, non è ancora maturo per la produzione.

La regola pratica che ne deriva è importante: per l'inferenza, scalate “in verticale” prima che “in orizzontale”. Più GPU nello stesso computer, collegate tra loro via PCIe Gen5 (~64 GB/s) o, meglio, via NVLink (centinaia di GB/s), scalano bene: il tensor-parallel funziona e le prestazioni sono solide. Le stesse GPU sparse su macchine diverse e collegate via Ethernet danno un degrado severo. Una RTX 5090 (32 GB, 1,79 TB/s, 575 W, ~2.000 euro di listino — spesso molto di più per la carenza GDDR7) è una scheda velocissima ed economica: ma il modo giusto di usarne diverse è metterne 2-4 in un unico server, non costruire una fattoria di PC in rete. Il cluster multi-nodo ha senso solo come ultima risorsa per contenere un modello che non entra altrove, accettando che andrà lento.

Livello 5 — Il vertice: AMD Instinct MI300X e simili

All'estremo superiore ci sono gli acceleratori datacenter di AMD. L'Instinct MI300X porta 192 GB di HBM3 per GPU (la MI325X arriva a 256 GB, la MI355X a 288 GB), con banda sopra i 5 TB/s e ormai un ottimo supporto software via ROCm 7 e vLLM. Sono mostri di capacità: un solo MI300X tiene in memoria un modello che richiederebbe più H100.

C'è però un vincolo strutturale che li tiene fuori dalla portata dei più: si comprano solo come piattaforme da 8 GPU (form factor OAM su Universal Base Board). Un nodo è quindi un sistema con 1,5 TB+ di HBM, doppio EPYC, raffreddamento a liquido obbligatorio sui tagli più spinti, 6 kW e oltre di assorbimento, e un prezzo che parte da 150.000 euro e arriva tranquillamente oltre i 300.000. Ogni assemblatore (Dell, HPE, Supermicro, Lenovo, GIGABYTE) li monta a 8x, e i costi sono, appunto, stratosferici. Ha senso solo per chi vuole ospitare in casa modelli frontier (i DeepSeek o i GLM da centinaia di miliardi di parametri) o servire migliaia di utenti. Per tutti gli altri, è sovradimensionato di ordini di grandezza.

Tirando le fila: quale livello per quale esigenza

Non esiste l'hardware “giusto” in assoluto: esiste quello giusto per il vostro carico. Riassumendo:

Il filo conduttore resta quello dei tre numeri iniziali. La VRAM decide se il modello parte. La banda decide quanto veloce genera. E vLLM su GPU vere decide se state servendo una persona o una squadra.

Ma sopra a tutto c'è la lezione del 12 giugno. Un modello dietro un'API non è davvero vostro: può essere spento da una decisione su cui non avete controllo, in un pomeriggio, senza preavviso. Un modello open sul vostro hardware, no. Per molte aziende — soprattutto quelle che lavorano con clienti regolati — la soluzione più sensata non è né il giocattolo da scrivania né il nodo da 300.000 euro, ma quel gradino di mezzo: una o due GPU enterprise da 96 GB in un server on-prem, che fanno girare un buon modello open per tutto il team, senza che una riga di codice esca dal perimetro aziendale, e senza che nessuno, da nessuna parte, possa staccare la spina.

Luca Vitali