Collegare due Mac Studio o comprare 512 GB? Gli LLM locali su M5 Ultra alla prova dei fatti

Prima la risposta breve: Sì. Da macOS 26.2 due Mac Studio da 256 GB ciascuno possono essere collegati via Thunderbolt 5 con RDMA e ospitare insieme un modello che non entrerebbe in uno solo. Ma a fine ottobre 2026 un cluster serve soprattutto ad aumentare la capacità, non la velocità. Per il modello aperto più interessante del momento, DeepSeek V4.1 Flash 1017, basta un solo M5 Ultra da 256 GB. Nelle misurazioni degli sviluppatori genera circa 90-100 token al secondo e legge prompt lunghi a 3.000 fino a quasi 3.900 token al secondo. Le misurazioni di cluster pubblicate finora per questo modello vanno da 16 a 36 token al secondo, e non esiste ancora una misurazione pubblicata per due M5 Ultra con RDMA funzionante. La nostra raccomandazione: comprare una macchina da 256 GB e aggiungere la seconda solo quando un modello ne ha davvero bisogno. La configurazione da 512 GB ormai conviene solo come assicurazione.

Stato di questa analisi: 31 ottobre 2026. Il panorama dei motori per Apple Silicon cambia di settimana in settimana. Per ogni numero indichiamo hardware, pacchetto del modello e fonte, e distinguiamo chiaramente tra valori misurati, riportati e stimati.

La tecnologia: RDMA su Thunderbolt 5

Fino alla fine del 2025, collegare dei Mac in cluster era più che altro un esperimento. Il collegamento passava per TCP, e ogni salto tra due macchine costava circa 300 microsecondi di latenza. Per i metodi in cui le macchine si scambiano dati decine di volte per token, era troppo lento.

Con macOS 26.2 Apple ha introdotto un driver RDMA per Thunderbolt 5. RDMA sta per Remote Direct Memory Access: una macchina può scrivere direttamente nella memoria dell'altra senza passare dallo stack di rete. Secondo Jeff Geerling la latenza scende sotto i 50 microsecondi, con un throughput pratico di 50-60 Gbit/s. Il framework di machine learning di Apple, MLX, usa il driver dalla versione 0.30.1 tramite il backend di comunicazione jaccl.

Due modi per distribuire un modello

• Parallelismo a pipeline: il modello viene diviso in profondità. Il Mac 1 calcola i primi strati, il Mac 2 i restanti. Tra le macchine passa per ogni token solo un piccolo risultato intermedio. È robusto anche su collegamenti lenti, ma in generazione non porta praticamente velocità, perché gli strati continuano a essere eseguiti uno dopo l'altro. Aiuta solo nella lettura di prompt molto lunghi, perché i blocchi possono sovrapporsi. Apple misura fino a 1,8 volte più veloce a 64.000 token.
• Parallelismo tensoriale: ogni singolo strato viene diviso in larghezza tra le due macchine. Entrambe calcolano contemporaneamente, ma devono sincronizzarsi a ogni token e a ogni strato. Senza RDMA la comunicazione annulla il guadagno. Con RDMA è la strada verso una vera accelerazione.

Cosa misura Apple

Il 15 ottobre 2026 Apple ha pubblicato le proprie misurazioni su M5 Ultra. Velocità di decodifica in token al secondo:

La lettura è chiara: la pipeline porta capacità, il parallelismo tensoriale porta capacità e velocità, con due macchine circa un fattore da 1,6 a 1,8. È questa distinzione a decidere poi se un cluster conviene.

Cosa serve per l'installazione

• L'RDMA va attivato una volta su ogni Mac in modalità di recupero con rdma_ctl enable.
• I Mac si collegano direttamente con cavi Thunderbolt 5, e con più di due macchine ognuna con tutte le altre. La porta Thunderbolt 5 accanto a quella Ethernet non è adatta. Nei suoi test Apple usa due cavi per collegamento per raddoppiare la larghezza di banda.
• Tutte le macchine devono avere esattamente la stessa versione di macOS. Gli aggiornamenti vanno quindi sempre installati insieme.
• Un tranello frequente nella pratica: se il collegamento Thunderbolt ha solo un indirizzo 169.254 assegnato automaticamente, la connessione ripiega silenziosamente sulla LAN o addirittura sul Wi-Fi. La soluzione è un indirizzo IPv4 manuale sulla porta Thunderbolt di entrambi i Mac, per esempio 10.10.0.1 e 10.10.0.2.

Il calcolo della memoria: cosa entra in 2 × 256 GB?

Un Mac da 256 GB non mette a disposizione della GPU tutti i 256 GB. macOS ha bisogno di memoria propria, e il limite della GPU va alzato con sudo sysctl iogpu.wired_limit_mb. Un utente usa due M5 Ultra senza monitor con 250 GB impostati manualmente per macchina. Realisticamente, in un cluster restano quindi circa 450-500 GB per pesi, cache KV e buffer di lavoro. È una nostra stima, non un dato del produttore.

La regola pratica per i pesi: numero di parametri per bit per peso, diviso otto.

* Considerando i fattori di scala del formato NVFP4, Apple stima Muse Spark Open in circa 493 GB.

Il risultato: a 3-3,5 bit per peso, l'intera classe di modelli da 750 a 820 miliardi di parametri entra in due macchine da 256 GB. I modelli con più di mille miliardi di parametri no. Per la versione a 4 bit di Muse Spark Open, Meta indica due Mac Studio da 512 GB ciascuno.

Caso di studio: DeepSeek V4.1 Flash 1017

Il 17 ottobre 2026 DeepSeek ha pubblicato un aggiornamento del suo modello Flash, con pesi aperti sotto licenza MIT. Per l'hardware locale il modello è particolare per diversi motivi:

• Architettura: è il primo modello DeepSeek con un'architettura encoder-decoder causale. I 40 strati sono divisi in 20 di encoder e 20 di decoder. Il backbone ha 552 miliardi di parametri, di cui solo 8 miliardi attivi per token in lettura e 16 miliardi in generazione.
• Cache KV minuscola: secondo la scheda del modello, la cache KV richiede solo 890 byte per token. Anche un milione di token di contesto occupa meno di un gigabyte. Per questo modello il collo di bottiglia non è il contesto, ma solo i pesi.
• Dimensione totale: Hugging Face conta 763 miliardi di parametri. La differenza rispetto al backbone deriva probabilmente da componenti aggiuntivi come le tabelle Engram, l'encoder visivo e gli strati per la decodifica speculativa. I due file Engram insieme superano di poco i 200 GB e possono restare sull'SSD.
• Già nativamente a 4 bit: DeepSeek distribuisce gli esperti già in FP4 e il resto in FP8. Il consueto risparmio di una quantizzazione a 4 bit quindi per questo modello non si applica.

Quanto valgono i quant?

Per far entrare un modello da 552B in una sola macchina da 256 GB bisogna scendere sotto i 3 bit per peso. Conta quanta qualità costa. I valori seguenti provengono dalle pubblicazioni dei rispettivi autori e sono misurati rispetto al modello 1017 nativo. Top-1 indica quanto spesso il quant sceglie lo stesso token successivo dell'originale. La KLD misura lo scostamento tra le distribuzioni di probabilità; più è bassa, meglio è.

I metodi di misura variano da autore ad autore, quindi i numeri non sono confrontabili al decimale. Tre risultati restano comunque solidi:

1. Il formato conta più del numero di bit. I build EXL3 intorno ai 2,8 bpw sono praticamente al livello dell'originale. Per il build sudoingx, HumanEval+, MBPP+ e IFEval sono rimasti entro il rumore di misura del modello nativo. I quant MLX semplici di dimensioni comparabili se ne discostano di un ordine di grandezza in più.
2. I testi non inglesi soffrono per primi. Nel build Rapid-MLX lo scostamento resta basso per il codice (KLD 0,055) e la matematica (0,063), ma sale a 0,14-0,18 per la chat generica. I testi non inglesi e le conoscenze di nicchia derivano di più. Nel build REAP la concordanza sui testi multilingue scende al 52 %. Se lavorate in italiano, testate i quant con i vostri prompt in italiano.
3. I numeri Mac più veloci vengono da un pacchetto senza metriche di qualità pubblicate. Come EXL3, il formato Sushi-STQ memorizza gli esperti con l'efficiente metodo a traliccio, il che fa sperare in una buona qualità per bit. Ma 1,75 bpw sono davvero pochi. Finché non vengono pubblicati valori di KLD, conviene misurare da sé.

I motori: stato a fine ottobre 2026

Il ritmo è notevole. DeepSeek ha pubblicato 1017 il 17 ottobre. Cinque giorni dopo girava distribuito su due Mac in mlx-serve, e il 28 ottobre è arrivato il sistema di plugin con il kernel Sushi. Nel giro di pochi giorni, il repository dei plugin ha aggiunto diverse ottimizzazioni che hanno accelerato ciascuna la lettura dei prompt lunghi del 4-16 %. Importante per valutare il rischio: la base, cioè l'RDMA in macOS e jaccl in MLX, proviene ufficialmente da Apple. I progetti della community vi si appoggiano.

Misurato: un M5 Ultra contro il cluster

Un singolo M5 Ultra da 256 GB

I numeri più solidi provengono dalle pull request del repository dei plugin. Condizioni: M5 Ultra da 256 GB, macOS 27.2, pacchetto Sushi-STQ 1,75 bpw, tutti i 384 esperti per strato in RAM, una richiesta alla volta.

Per gli esperti sono disponibili circa 198 GB, abbastanza per tutti i 384 esperti di ogni strato. Con un pacchetto da 3,0 bpw nel codice nativo del modello di mlx-serve, misurazioni precedenti indicavano 56,8 tok/s senza e 48-82 tok/s con decodifica speculativa, a seconda del tipo di testo. Gli sviluppatori di mlx-serve hanno poi pubblicato su X un benchmark con il pacchetto DeepSeek-V4.1-Flash-1017-iQ-MLX-3.0bpw su un M5 Ultra da 256 GB. Condizioni secondo lo screenshot: decodifica greedy, una richiesta, mediana di tre esecuzioni dopo un riscaldamento.

Lo screenshot non indica la lunghezza del contesto della misura di prefill. Per il lavoro con agenti e per i testi non inglesi, il valore per il testo nuovo è il più realistico.

In modo indipendente, un build della community basato su TensorFold conferma l'ordine di grandezza: su un singolo M5 Ultra da 256 GB misura 67,5-94,4 tok/s con decodifica speculativa e 1.093-1.392 tok/s di prefill a prompt freddo, con input di immagini, chiamate a strumenti e 1 mln di token di contesto.

Cosa mostrano finora le misurazioni di cluster con DeepSeek V4.1

Alla data di pubblicazione non abbiamo trovato alcuna misurazione pubblicata per due M5 Ultra con RDMA funzionante. Ci sono però tre dati significativi:

• 2× M5 Ultra 256 GB, oMLX (segnalazione di bug del 20 ottobre): inizialmente 1 tok/s, poi 16,7 tok/s dopo le correzioni della versione 0.7.2. Questo valore però non è rappresentativo: secondo il maintainer, la connessione passava per un normale anello TCP anziché per RDMA, perché l'indirizzo era sul bridge Thunderbolt invece che sulla porta Thunderbolt. Con 256 GB per Mac, per questo pacchetto entrava solo il parallelismo tensoriale, e le tabelle Engram restano sull'SSD.
• 2× M3 Ultra via Thunderbolt, oMLX 0.7.3rc1 (note di rilascio, pacchetto oQ4e): pipeline 32,4-34,3 tok/s, parallelismo tensoriale 24,3-25,4 tok/s. Secondo le stesse note, un singolo M3 Ultra raggiunge 34,3 tok/s con lo stesso pacchetto. Qui il cluster è quindi al massimo altrettanto veloce, e con il parallelismo tensoriale addirittura più lento.
• 3× M5 Max da 128 GB ciascuno, pesi nativi, RDMA (configurazione sperimentale): 35,6 tok/s per una singola richiesta.

Secondo la descrizione del codice, mlx-serve distribuisce DeepSeek V4.1 nel cluster per strati, quindi a pipeline. Secondo le misurazioni di Apple, questo non porta alcun guadagno di velocità in generazione.

La valutazione: per DeepSeek V4.1 non esiste finora alcuna prova pubblica che un cluster sia più veloce di una singola macchina. Una ragione plausibile: con soli 16 miliardi di parametri attivi per token, il calcolo per strato è ridotto, mentre il costo di sincronizzazione tra le macchine resta lo stesso. Apple osserva lo stesso effetto nelle sue misurazioni: i modelli densi scalano meglio su più macchine. Nuove misurazioni escono quasi ogni giorno. Davanti a numeri di cluster conviene sempre verificare tre dettagli: il collegamento passava per RDMA, quale pacchetto è stato usato, e a quale lunghezza di contesto è stata fatta la misura? Per 1017 la conclusione resta: il modello entra in una macchina, ed è lì che oggi gira più veloce.

Per confronto sul lato NVIDIA: due DGX Spark eseguono 1017 con il build EXL3 a 2,8 bpw, con qualità quasi pari all'originale, a circa 104 tok/s per il codice, 58 per la prosa e 144 per l'output strutturato. Abbiamo misurato le prestazioni di un cluster di 4 DGX Spark in self-hosting qui (in tedesco).

512 GB o due volte 256 GB?

Apple ha aperto gli ordini della configurazione da 512 GB il 28 ottobre, con tempi di consegna di 7-8 settimane. Negli Stati Uniti costa 22.299 dollari, esattamente 11.500 dollari in più della stessa configurazione da 256 GB. In Germania un M5 Ultra con CPU a 36 core, GPU a 80 core, 256 GB e SSD da 1 TB costa 12.429 euro in base ai sovrapprezzi indicati da Macwelt. Alla data di pubblicazione non abbiamo potuto verificare un prezzo in euro per la versione da 512 GB.

Una macchina da 512 GB costa quindi più o meno quanto due da 256 GB.

Il grafico «Two 256GB M5 Ultras beat one 512GB»

Su X circola un grafico secondo cui due macchine da 256 GB battono nettamente una da 512 GB: circa 215-245 invece di 135 TFLOPS, 1,9-2,2 invece di 1,2 TB/s, 75-100 invece di 45-60 tok/s per DeepSeek V4.1 Flash e 55-70 invece di 33-40 tok/s per GLM-5.3. Condividiamo l'orientamento generale: per i modelli che hanno davvero bisogno di 512 GB e il cui motore padroneggia il parallelismo tensoriale via RDMA, due macchine da 256 GB sono la scelta migliore. Come misurazione, però, il grafico non regge:

• Nessun dettaglio di misura: mancano motore, quantizzazione e lunghezza del contesto. I valori sono indicati con la tilde e come intervalli, e i valori di cluster sono sistematicamente circa 1,7 volte quelli della singola macchina. È esattamente il fattore che Apple misura per i modelli densi. Si tratta quindi evidentemente di una proiezione.
• Il valore della singola macchina per DeepSeek V4.1 non corrisponde alle misurazioni: un M5 Ultra da 256 GB, cioè lo stesso chip della macchina da 512 GB, raggiunge 92 tok/s con un pacchetto a 3 bit. Una macchina da 512 GB sarebbe altrettanto veloce con lo stesso pacchetto. I 45-60 tok/s hanno senso solo se sulla macchina da 512 GB gira una variante più precisa e quindi più lenta. Ma allora il grafico confronta quantizzazioni diverse.
• Il valore del cluster corrisponde a una sola macchina da 256 GB: un singolo M5 Ultra da 256 GB misura già oggi i 75-100 tok/s attribuiti a due macchine. Per DeepSeek V4.1 la seconda macchina quindi al momento non porta velocità, ma solo spazio per una precisione maggiore.

Un errore di ragionamento diffuso

Una macchina da 512 GB non rende più veloce lo stesso modello. Chip e larghezza di banda della memoria sono identici a quelli del modello da 256 GB. Chi usa la memoria in più per una precisione maggiore rallenta addirittura la generazione, perché per ogni token vanno letti più byte. 1017 a 4 bit gira quindi più lentamente sulla macchina da 512 GB che a poco meno di 3 bit su quella da 256 GB.

Cosa resta alla macchina da 512 GB

Chi è disposto a usare modelli della classe 750B a 3-3,5 bit ottiene con due macchine da 256 GB la stessa capacità. L'unico vero vantaggio che resta alla macchina da 512 GB è l'indipendenza dal supporto al cluster: esegue ogni modello che il motore supporta. A questo si aggiunge l'espansione a 1 TB con due macchine da 512 GB, per esempio per Muse Spark Open a 4 bit.

I motori miglioreranno? Sì, ma non ovunque

I progressi del software aiutano le due opzioni in modo diverso.

Cosa i motori possono migliorare:

• Quant migliori: la stessa qualità con meno bit rende 256 GB sufficienti per modelli sempre più grandi. Questo va contro il sovrapprezzo per i 512 GB.
• Streaming da SSD: i motori leggono su richiesta dall'SSD le parti del modello troppo grandi. È così che mlx-serve fa girare GLM-5.3, con 744 miliardi di parametri, su un singolo Mac da 256 GB.
• Supporto al cluster per più modelli: ogni estensione rende più utili due macchine da 256 GB.
• Parallelismo tensoriale più efficiente: più guadagno per ogni macchina aggiuntiva.

Cosa i motori non possono cambiare:

• La larghezza di banda della memoria per Mac: la generazione è limitata da essa, e 1,2 TB/s restano 1,2 TB/s.
• Il collegamento Thunderbolt: la latenza e un throughput pratico di 50-60 Gbit/s limitano quanto bene scala il parallelismo tensoriale.
• Il numero di macchine: motori diffusi come exo richiedono potenze di due per il parallelismo tensoriale, cioè 2 o 4 macchine. Un full mesh è limitato dalle porte Thunderbolt.
• La crescita dei modelli: Muse Spark Open ha 816 miliardi di parametri, DeepSeek V4 Pro ne aveva 1.600 miliardi, e DeepSeek ha prospettato un V4.1 Pro.

In sintesi, i progressi del software favoriscono più l'acquisto graduale di macchine da 256 GB che la macchina da 512 GB.

Streaming da SSD e usura

Chi usa i modelli in streaming dall'SSD si chiede giustamente se questo lo consumi. La risposta breve: lo streaming in sé no. Le celle flash si usurano con le scritture, non con le letture. Letture frequenti possono influenzare in minima parte le celle vicine. Il controller rinfresca allora i blocchi interessati in background, cosa trascurabile rispetto all'uso normale.

Si scrive in tre situazioni: quando la memoria viene spostata nello swap, quando si salvano gli stati delle conversazioni nella cache dei prompt e quando si scaricano modelli. Apple non pubblica dati di durata. Assumiamo quindi un valore tipico per gli SSD TLC di circa 600 TB scritti per TB di capacità, cioè circa 2.400 TB per un SSD da 4 TB. È un'ipotesi, non una specifica del produttore.

I valori della cache sono calcoli di esempio approssimativi. Per DeepSeek V4.1, 128.000 token di stato di conversazione occupano solo circa 110 MB grazie alla piccola cache KV.

Il vero rischio è lo swap causato da un budget di memoria troppo stretto. Poiché l'SSD del Mac Studio non si sostituisce semplicemente da soli, conviene controllare:

1. Dopo l'installazione eseguire brew install smartmontools e smartctl -a disk0 e annotare «Percentage Used» e «Data Units Written».
2. Misurare di nuovo dopo quattro settimane. Se «Percentage Used» cresce di oltre l'1 % al mese, la causa è di solito lo swap.
3. Durante l'inferenza tenere d'occhio sysctl vm.swapusage e, se il valore continua a crescere, ridurre il budget di memoria del motore.

Lo svantaggio maggiore dello streaming resta comunque la velocità. La velocità di generazione dipende allora dal throughput di lettura dell'SSD. Con 1017 Sushi raggiunge in streaming 76,6 tok/s per il codice e 49,3 per la prosa su un M5 Max da 128 GB; un M5 Ultra con l'intero modello in RAM è nettamente più veloce.

La nostra raccomandazione

1. Comprare subito un M5 Ultra da 256 GB (CPU a 36 core, GPU a 80 core, SSD da almeno 4 TB per più pacchetti di modelli). Basta pienamente per DeepSeek V4.1 Flash 1017, con mlx-serve e il plugin sushi_ds41 oppure direttamente con Sushi.
2. Verificare da sé la qualità dei quant, soprattutto nelle lingue diverse dall'inglese. Finché per i pacchetti STQ veloci non vengono pubblicati valori di KLD, confrontare con l'API di DeepSeek usando i propri prompt.
3. Comprare la seconda macchina da 256 GB solo quando si verificano due condizioni: un modello di cui avete bisogno non entra più in una macchina, e il vostro motore supporta in modo dimostrato il parallelismo tensoriale via RDMA per quel modello.
4. Scegliere la macchina da 512 GB solo come assicurazione: se non volete alcuna dipendenza dal supporto al cluster, o se pianificate fin dall'inizio due macchine da 512 GB per 1 TB.
5. Impostare bene l'esercizio: funzionamento senza monitor, limite della GPU alzato, bridge Thunderbolt disattivato, indirizzi IP fissi sulla porta Thunderbolt e swap sotto controllo.

Domande frequenti

Si possono combinare due Mac Studio da 256 GB in una macchina da 512 GB? Non nel senso di una memoria condivisa per qualsiasi programma. I motori di inferenza come MLX, mlx-serve o oMLX possono però distribuire un modello su entrambe le macchine, via Thunderbolt 5 con RDMA a partire da macOS 26.2. In pratica sono utilizzabili circa 2 × 250 GB. Se funziona dipende dal fatto che il motore supporti quel modello specifico in cluster.

Un cluster di due Mac è più veloce di un singolo Mac? Solo con il parallelismo tensoriale tramite un vero RDMA. In quel caso Apple misura sul M5 Ultra un fattore di circa 1,6-1,8. Con il parallelismo a pipeline la velocità di generazione resta praticamente la stessa. Per DeepSeek V4.1 le misurazioni di cluster pubblicate finora non mostrano alcun vantaggio rispetto a una singola macchina. Un singolo M5 Ultra esegue il modello a circa 90-100 tok/s.

DeepSeek V4.1 Flash 1017 gira su un singolo Mac Studio da 256 GB? Sì. Con un pacchetto a 3 bit gli sviluppatori di mlx-serve misurano su un M5 Ultra da 256 GB 92 tok/s in generazione e quasi 3.900 tok/s in lettura. Il pacchetto Sushi-STQ a 1,75 bpw arriva a circa 100 tok/s. Le tabelle Engram restano sull'SSD. Per i pacchetti Sushi-STQ non sono ancora state pubblicate metriche di qualità.

Vale la pena il sovrapprezzo per 512 GB? Per la maggior parte no. Il sovrapprezzo corrisponde più o meno a una seconda macchina da 256 GB, e la macchina da 512 GB non rende più veloce lo stesso modello. Conviene se volete far girare modelli della classe 750B a precisione più alta senza alcuna dipendenza dal supporto al cluster, o se pianificate di espandervi a 1 TB con due macchine da 512 GB.

Lo streaming rovina l'SSD? No. Lo streaming si limita a leggere, e la lettura non usura praticamente la memoria flash. Il problema è lo swap continuo dovuto a un budget di memoria troppo stretto. Con smartctl e sysctl vm.swapusage si può tenere sotto controllo facilmente.

Quanto peggiora la qualità con la quantizzazione? Dipende soprattutto dal formato. I build EXL3 intorno ai 2,8 bpw concordano con l'originale DeepSeek V4.1 Flash 1017 in circa il 96 % dei casi, i quant MLX semplici a 2 bit solo in circa l'80 %. Le lingue diverse dall'inglese perdono qualità per prime.

Fonti

• Apple Machine Learning Research: Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio (15/10/2026) – https://machinelearning.apple.com/research/mlx-distributed-inference
• computingforgeeks: Cluster Local LLMs – Mac Studio vs Strix Halo vs Two DGX Sparks – https://computingforgeeks.com/?p=178136
• mlx-serve, release v26.10.3 (22/10/2026) – https://github.com/ddalcu/mlx-serve/releases/tag/v26.10.3
• mlx-serve PR #895: DeepSeek-V4.1 su una coppia Thunderbolt – https://github.com/ddalcu/mlx-serve/pull/895
• mlx-serve PR #911: decodifica DeepSeek-V4.1 su M5 Ultra – https://github.com/ddalcu/mlx-serve/pull/911
• mlx-serve PR #1002: Outside model plugins (28/10/2026) – https://github.com/ddalcu/mlx-serve/pull/1002
• CommunityServe/plugins (sushi_ds41) – https://github.com/CommunityServe/plugins
• CommunityServe/plugins PR #10 e #11: misurazioni di prefill e decodifica, M5 Ultra 256 GB – https://github.com/CommunityServe/plugins/pull/10 e https://github.com/CommunityServe/plugins/pull/11
• Sushi v1.4.0 – https://newreleases.io/project/github/beamivalice/sushi/release/v1.4.0
• oMLX issue #4720: cluster DeepSeek V4.1-1017 su 2× M5 Ultra 256 GB – https://github.com/jundot/omlx/issues/4720
• Release di oMLX (0.7.3rc1, misurazioni di cluster 2× M3 Ultra) – https://github.com/jundot/omlx/releases
• Discussione MLX #4491: DeepSeek V4.1 Flash su tre Mac M5 Max – https://github.com/ml-explore/mlx/discussions/4491
• BobClawblaw/deepseek-v41-flash-mlx-m5-ultra (build TensorFold per un M5 Ultra) – https://github.com/BobClawblaw/deepseek-v41-flash-mlx-m5-ultra
• sudoingX/dgx-spark-deepseek-v41, release (qualità EXL3 e velocità DGX Spark) – https://github.com/sudoingX/dgx-spark-deepseek-v41/releases
• rapid-mlx/DeepSeek-V4.1-Flash-1017-MLX (misurazione della qualità) – https://huggingface.co/rapid-mlx/DeepSeek-V4.1-Flash-1017-MLX
• patrickbdevaney/DeepSeek-V4.1-Flash-1017-REAP192-MXFP4 – https://huggingface.co/patrickbdevaney/DeepSeek-V4.1-Flash-1017-REAP192-MXFP4
• LibertAIDAI/DeepSeek-V4.1-Flash-NVFP4 (esperti FP4 nativi) – https://huggingface.co/LibertAIDAI/DeepSeek-V4.1-Flash-NVFP4
• aiweekly: DeepSeek posts V4.1-Flash: 552B MoE, 8B active, 1M context – https://aiweekly.co/alerts/deepseek-posts-v41-flash-552b-moe-8b-active-1m-context
• TensorFold – https://github.com/ashhart/TensorFold e fork con branch DGX Spark https://github.com/Elevatormusic/TensorFold
• Macworld: The Mac Studio with 512GB of RAM is shipping – https://macworld.com/article/3271691/the-mac-studio-with-512gb-of-ram-is-shipping-and-it-costs-new-car-money.html
• Appleosophy: tempi di consegna del Mac Studio da 512 GB – https://appleosophy.com/2026/10/28/mac-studio-with-512gb-of-ram-now-available-starts-at-22299/
• Macwelt: Mac Studio M5 Max e M5 Ultra, prezzi in Germania – https://www.macwelt.de/article/3220005/mac-studio-m5-max-m5-ultra.html
• iThinkDiff: Mac Studio da 512 GB e Muse Spark Open – https://www.ithinkdiff.com/512gb-mac-studio-m5-ultra-price-22299/
• Sviluppatori di mlx-serve: screenshot del benchmark DeepSeek-V4.1-Flash-1017-iQ-MLX-3.0bpw su M5 Ultra 256 GB, pubblicato su X (ottobre 2026)
• Grafico «Two 256GB M5 Ultras beat one 512GB», diffuso su X (ottobre 2026, autore sconosciuto)