In breve: Per LLM locali la scelta Mac Apple Silicon vs GPU NVIDIA non si decide sui TFLOPS di brochure. Si decide su quanto modello e quanto contesto entrano in memoria senza spezzare il resto del sistema. Sul Mac la memoria è unificata: CPU e GPU leggono lo stesso pool (documentazione MLX). Su NVIDIA la VRAM dedicata è un tetto duro: pesi, KV cache e runtime devono starci dentro, o offloadi sulla RAM di sistema e perdi velocità. Scegli Mac se lavori da solo, vuoi silenzio e un solo box che fa tutto. Scegli NVIDIA se ti serve throughput, serving multi-utente o lo stack CUDA/vLLM maturo. Non ho un banco tok/s misurato da me su entrambi i lati per questo pezzo: sotto uso solo docs ufficiali e il conto memoria di ep3.
Spoke della Guida AI locale 3 (modelli, quantizzazione, VRAM). I runtime sono in ep2; il perché del locale in ep1. Percorso nell'hub AI Engineering. Termini come VRAM, GGUF e KV cache sono nel glossario.
La domanda sbagliata e quella giusta
Non "il Mac è più potente della 4090?". È: quale memoria posso impegnare per i pesi e per il contesto, e cosa ci faccio — chat interattiva, coding agent, o serving a più client.
I TFLOPS di picco non ti dicono se un 70B in Q4 entra. La memoria sì. Su Apple Silicon il pool è uno solo e lo condividi con macOS e le app in primo piano. Su una scheda NVIDIA il pool del modello è la VRAM; la RAM di sistema è un piano B lento se offloadi layer.
Tabella rapida
Criterio | Mac Apple Silicon | GPU NVIDIA (desktop/workstation) |
|---|---|---|
Memoria per il modello | Unified memory (stesso pool CPU/GPU) | VRAM dedicata (tetto fisso per scheda) |
Tetto tipico consumer | Laptop 16–48 GB; Mac Studio fino a 128 GB (M5 Max) o 512 GB (M5 Ultra) (specs Apple) | 8–24 GB sulle GeForce comuni; 48 GB+ su workstation |
Runtime maturi | Ollama (Metal), llama.cpp (Metal default), MLX / mlx-lm, vLLM-Metal (community) | Ollama (CUDA), llama.cpp (CUDA), vLLM (CUDA nativo) |
Serving multi-utente | Possibile, ecosistema più giovane (vLLM-Metal) | vLLM e CUDA sono lo standard di riferimento |
Rumore / consumo | Mac Studio: max continuo 480 W da scheda tecnica Apple | TDP GPU spesso alti; ventole dedicate più rumorose in carico (qualitativo, non misurato qui) |
Quando vince | Un utente, privacy on-device, Mac già in casa | Batch, team, modelli grandi a Q alto, stack CUDA |
Verdict di riga: nessuno "vince" in assoluto. Vince il vincolo che ti stringe di più: capienza del pool vs serving e CUDA.
Memoria unificata vs VRAM dedicata
Apple vince sul "quanto modello posso caricare senza una seconda scheda" perché la GPU non ha un silos separato. MLX lo dice in modo esplicito: gli array vivono in memoria condivisa; scegli il device sull'operazione, non spostando i tensori (Unified Memory). Il prezzo è che modello, KV cache, browser e IDE competono sullo stesso gigabyte.
NVIDIA vince sul "il modello ha un budget isolato" perché la VRAM è dedicata all'acceleratore. Pesi + KV + overhead del runtime devono stare lì. Se non ci stanno, llama.cpp e Ollama possono offloadare layer sulla RAM di sistema: il modello "gira", ma il percorso PCIe e il round-trip host↔device tipicamente abbassano il throughput. Non invento percentuali: il punto architetturale è il tetto.
Il conto operativo resta quello di ep3: pesi + KV cache + margine. I pesi li decide il file (GGUF o quant MLX). La cache la decidi tu con contesto e parallelismo. Il margine evita di progettare al 100% del dispositivo.
Esempio solo su carta (numeri da ep3 / tabelle llama.cpp, non un mio bench): Llama 3.1 8B in Q4_K_M ≈ 4,6 GiB di pesi; a 32k token di contesto la KV in f16 su quel modello è nell'ordine di 4 GiB. Su una 12 GB di VRAM il conto è stretto. Su un Mac da 32 GB di memoria unificata lo stesso file "entra" più facilmente, ma 32 GB non sono tutti del modello: resta macOS e il resto.
Runtime: cosa gira dove
Ollama
Ollama documenta NVIDIA (compute capability 5.0+, driver 550+, con note per le schede più vecchie) e Metal su Apple (Hardware support). Stessa UX, backend diversi. Su Mac usi Metal; su PC CUDA (o Vulkan dove applicabile). Per la memoria, le FAQ restano valide: contesto e OLLAMA_NUM_PARALLEL moltiplicano la cache — indipendentemente dal vendor.
llama.cpp
Su macOS Metal è attivo di default; puoi disabilitarlo a build con -DGGML_METAL=OFF o a runtime con --n-gpu-layers 0 (docs/build.md). Su Linux/Windows con NVIDIA il percorso tipico è il backend CUDA. Stesso formato GGUF, stesso server OpenAI-compatible, device diverso. È il ponte più onesto se vuoi confrontare Mac e PC senza cambiare formato modello.
MLX
MLX è il framework Apple Silicon: memoria unificata, lazy eval, API NumPy-like. Per gli LLM di solito passi da mlx-lm e dai modelli della community MLX su Hugging Face. Non è un backend di llama.cpp: è un altro percorso di esecuzione. Ha senso se vivi in Python sul Mac e vuoi sfruttare il design unificato, non se ti serve la stessa binaria GGUF ovunque.
vLLM
vLLM su NVIDIA richiede CUDA e compute capability 7.5+ (installazione GPU). È la scelta se servi più utenti o vuoi continuous batching e paged KV maturi. Su Apple Silicon la stessa pagina punta a vLLM-Metal, plugin community basato su MLX: utile, ma non è lo stesso prodotto CUDA. Se il vincolo è "serving di produzione come in datacenter", oggi il percorso documentato e battuto è NVIDIA.
Per API OpenAI-compatible in locale (Ollama, vLLM, llama.cpp server) vedi anche questo pezzo. Su Ollama e spazio disco dopo gli aggiornamenti: Ollama 0.40.
Velocità: cosa posso dire senza inventare tok/s
Non pubblico una tabella tok/s mia Mac vs 4090. Non l'ho misurata per questo articolo su hardware allineato (stesso modello, stessa quant, stesso contesto, stesso prompt).
Cosa posso dire dalle fonti:
- Su Apple Silicon, paper e guide di terze parti confrontano MLX, llama.cpp/Metal, Ollama e affini; i ranking dipendono da modello, quant e carico (singolo stream vs batch). Usali come orientamento, non come verità assoluta.
- Su NVIDIA, vLLM è progettato per throughput multi-richiesta; llama.cpp resta spesso ottimo sul singolo stream. Anche questo è un fatto di prodotto, non un mio numero.
Regola pratica: se confronti due macchine, fissa modello, quantizzazione, contesto, batch e misura TTFT + tok/s sul *tuo* prompt. Un numero letto su Reddit senza setup non decide un acquisto.
Rumore, calore, consumo (qualitativo)
Da scheda tecnica Apple, Mac Studio dichiara maximum continuous power 480 W (specs). È un tetto di sistema, non il consumo medio in chat. Le GPU NVIDIA desktop di fascia alta hanno TDP elevati e ventole dedicate: in carico prolungato tipicamente senti più rumore di un Mac Studio o di un MacBook chiuso sulla scrivania. Non ho dB misurati qui: se il vincolo è "ufficio condiviso / notte", pesa l'esperienza d'uso, non solo i GB.
Il Mac laptop vince sul "lo porto via e non disturbo nessuno". Il tower NVIDIA vince quando puoi isolare il rumore (altra stanza, rack, orari).
Quando scegliere Mac
- Hai già (o vuoi) un Mac come macchina unica: IDE, browser, modello locale.
- Lavori principalmente single-user: chat, coding agent, RAG personale.
- Ti serve caricare modelli grandi in quantizzazione aggressiva sfruttando 36–128 GB (o più su Ultra) di memoria unificata, accettando che non tutta sia del modello.
- Preferisci Metal / MLX e non dipendi da CUDA o da vLLM "come in cloud".
Quando scegliere NVIDIA
- Devi servire più client o massimizzare throughput: vLLM + CUDA è il percorso documentato.
- Vuoi 24 GB (o più) di VRAM dedicata senza condividere il pool col desktop.
- Il tuo stack (PyTorch, fine-tuning, tool CUDA) è già NVIDIA.
- Accetti rumore, PSU e calore in cambio di un ecosistema serving maturo.
Errori comuni
1. Comprare sui TFLOPS. Conta quanto entra di pesi + cache. Rileggi ep3. 2. Riempire la VRAM (o la unified memory) di pesi e scoprire dopo che 32k di contesto non ci stanno. 3. Confrontare un MacBook 16 GB con una 4090 24 GB come se fossero la stessa classe di macchina. 4. Assumere che vLLM su Mac = vLLM su CUDA. Su Apple è un plugin diverso (vLLM-Metal). 5. Fidarsi di un tok/s senza setup. Stesso GGUF, stesso -c, stesso prompt, o non confrontare. 6. Dimenticare disco e aggiornamenti modelli — i GB di VRAM non bastano se il volume si riempie di layer (vedi Ollama 0.40).
Cosa conviene fare adesso
1. Scrivi il vincolo: un utente o un team? Contesto tipico? Modello target (8B, 32B, 70B)? 2. Fai il conto pesi + KV + margine (ep3) contro i GB reali che puoi dare al modello — su Mac sottrai una fetta onesta a OS e app; su NVIDIA parti dalla VRAM della scheda. 3. Se sei su Mac: prova lo stesso GGUF con Ollama o llama.cpp (Metal); se vivi in Python, valuta mlx-lm. 4. Se sei su NVIDIA e servi altri: punta a vLLM (CC ≥ 7.5) o a llama.cpp/Ollama per il singolo utente. 5. Misura sul tuo prompt prima di comprare hardware. Un foglio con TTFT e tok/s batte qualsiasi thread.
La serie continua sull'hub AI Engineering. Prossimo pezzo utile sul formato file: GGUF vs safetensors vs MLX (in calendario). Per ora: scegli la memoria che puoi riempire senza mentire al tuo carico di lavoro.
