TL;DR: un cluster di Mac Studio rende l’AI locale molto più credibile, ma non trasforma l’hardware in una scelta automatica. Per la maggior parte delle PMI conviene partire dalle API cloud: richiedono meno capitale, scalano subito e riducono il lavoro sistemistico. Il locale vince quando il carico è continuo, i dati non devono uscire dall’organizzazione e il team sa gestire modelli, code e guasti.
Il criterio giusto non è “quale soluzione genera più token al secondo?”. È il costo totale per ottenere un risultato affidabile: hardware o consumo API, tempo tecnico, privacy, continuità operativa e libertà di cambiare modello. Se il confronto si ferma al benchmark, la decisione è già impostata male.
Cosa cambia con i cluster Mac
Il 25 agosto 2026 Apple ha presentato il Mac Studio con M5 Max e M5 Ultra. La configurazione M5 Ultra arriva fino a 512 GB di memoria unificata e 1,2 TB/s di banda. La novità più interessante per l’AI è il supporto al clustering tramite Thunderbolt 5 e RDMA: più macchine possono distribuire inferenza e training con MLX.
Apple dichiara fino a tre volte le prestazioni di inferenza usando quattro Mac Studio rispetto a una sola macchina. È un dato del produttore, legato a workload specifici, ma contiene già un avvertimento utile: quattro nodi non danno automaticamente quattro volte le prestazioni. Comunicazione, topologia e strategia di parallelizzazione hanno un costo.
La sessione tecnica WWDC dedicata a MLX lo mostra bene. Ogni nodo deve avere librerie e modelli coerenti; l’orchestrazione passa da SSH; la configurazione descrive host, rete locale e collegamenti RDMA. Il tensor parallelism può accelerare l’inferenza, ma comunica a ogni layer e per ogni token. Il pipeline parallelism richiede meno scambi, però serve soprattutto a far entrare in memoria modelli troppo grandi per un singolo nodo.
Approccio A: AI locale su hardware proprio
Il vantaggio più concreto è il controllo. Prompt, documenti e output possono restare nella rete aziendale. Per uno studio professionale che analizza contratti, un’azienda che elabora documentazione riservata o un’agenzia che indicizza archivi dei clienti, questo riduce la superficie di esposizione e semplifica alcune scelte di governance.
Il secondo vantaggio è economico, ma solo con utilizzo elevato. L’hardware è una spesa iniziale prevedibile e non presenta una fattura per token. Se il cluster lavora molte ore al giorno su code stabili, il costo unitario può scendere. Inoltre si possono usare modelli open-weight senza dipendere dal listino o dalla disponibilità di una singola API.
I contro sono meno visibili nella scheda tecnica. Qualcuno deve aggiornare macOS, MLX, dipendenze e modelli; monitorare memoria, temperature e processi; gestire backup, sicurezza e capacità. Servono anche ridondanza e procedure di ripristino: quattro workstation sulla stessa scrivania non sono un servizio ad alta disponibilità. A questo vanno aggiunti energia, spazio, ammortamento e tempo del personale.
Approccio B: modelli via API cloud
Le API spostano il costo dall’hardware all’uso. Per partire bastano credenziali, un gateway applicativo e limiti di spesa. Un plugin WordPress, un flusso n8n o un gestionale può inviare una richiesta senza installare driver, distribuire pesi o dimensionare la memoria. I picchi vengono assorbiti dal fornitore e i modelli più recenti diventano disponibili senza sostituire macchine.
Questa semplicità ha tre vincoli. Il costo cresce con token, strumenti e volume; rate limit o incidenti esterni entrano nel proprio servizio; un cambio di modello può modificare qualità, latenza e comportamento. Per questo il prezzo per milione di token, da solo, non basta: avevo già affrontato il tema nel confronto su OpenAI, Anthropic e costo reale delle API.
Anche “cloud” non significa automaticamente “dati usati per addestrare”. Per esempio, OpenAI dichiara che i dati API non vengono usati per il training salvo opt-in. Restano però policy di conservazione, differenze tra endpoint e controlli come Zero Data Retention riservati ai clienti idonei. La privacy si valuta sul contratto e sulla configurazione effettiva, non sull’etichetta locale/cloud.
Il conto che una PMI deve fare
Il break-even si calcola su dodici o trentasei mesi, non su una demo. Da una parte: acquisto, energia, assistenza, ore sistemistiche, capacità inutilizzata e costo di un fermo. Dall’altra: consumo API, storage, traffico, osservabilità e margine per i picchi. Poi si divide per le richieste realmente completate con qualità accettabile, non per i token generati.
Per WordPress e automazioni aggiungerei un’altra voce: il costo del lock-in applicativo. Il sito o il workflow non dovrebbe chiamare direttamente un modello in dieci punti diversi. Meglio un gateway unico con code, timeout, log privi di dati sensibili, cache e selezione del provider. In questo modo lo stesso processo può usare un modello locale per documenti riservati e un’API per ricerca, picchi o task complessi.
Pro e contro, senza scorciatoie
- Locale: controllo dei dati, costo più stabile ad alto utilizzo e accesso a modelli open-weight; in cambio richiede capitale, competenze e capacità di gestione.
- API: avvio rapido, elasticità e modelli aggiornati; in cambio porta costo variabile, dipendenza dal fornitore e verifiche contrattuali sui dati.
- Ibrido: instrada ogni lavoro verso l’ambiente adatto; è l’opzione più solida, ma funziona solo con un’architettura comune e regole chiare sui dati.
La mia take
Per una PMI partirei dalle API e progettarei fin dal primo giorno la possibilità di sostituire provider. Aggiungerei un singolo nodo locale quando privacy, continuità o costo di un workload ricorrente lo giustificano. Comprerei un cluster solo dopo aver misurato per mesi una coda stabile che satura quel nodo e dopo aver assegnato a qualcuno la responsabilità operativa.
Il cluster Mac è una vera opzione infrastrutturale, non un giocattolo. Proprio per questo non va comprato per evitare una fattura API: va scelto quando l’organizzazione vuole gestire un servizio AI. Sono due decisioni molto diverse.