Relier deux Mac Studio ou acheter 512 Go ? Les LLM locaux sur M5 Ultra à l'épreuve des faits

La réponse courte d'abord : Oui. Depuis macOS 26.2, deux Mac Studio de 256 Go chacun peuvent être reliés via Thunderbolt 5 avec RDMA et héberger ensemble un modèle qui ne tiendrait pas sur un seul. Mais fin octobre 2026, un cluster sert surtout à gagner de la capacité, pas de la vitesse. Pour le modèle ouvert le plus intéressant du moment, DeepSeek V4.1 Flash 1017, un seul M5 Ultra de 256 Go suffit. Selon les mesures des développeurs, il génère environ 90 à 100 tokens par seconde et lit les longs prompts à 3 000 à près de 3 900 tokens par seconde. Les mesures de cluster publiées jusqu'ici pour ce modèle se situent entre 16 et 36 tokens par seconde, et il n'existe encore aucune mesure publiée pour deux M5 Ultra avec un RDMA fonctionnel. Notre recommandation : acheter une machine de 256 Go et n'ajouter la seconde que lorsqu'un modèle en a réellement besoin. La configuration 512 Go n'est plus qu'une assurance.

État de cette analyse : 31 octobre 2026. Le paysage des moteurs pour Apple Silicon évolue de semaine en semaine. Pour chaque chiffre, nous indiquons le matériel, le paquet de modèle et la source, et nous séparons clairement le mesuré, le rapporté et l'estimé.

La technologie : le RDMA via Thunderbolt 5

Jusqu'à fin 2025, relier des Mac en cluster relevait plutôt de l'expérience. La liaison passait par TCP, et chaque saut entre deux machines coûtait environ 300 microsecondes de latence. Pour les méthodes où les machines échangent des données des dizaines de fois par token, c'était trop lent.

Avec macOS 26.2, Apple a introduit un pilote RDMA pour Thunderbolt 5. RDMA signifie Remote Direct Memory Access : une machine peut écrire directement dans la mémoire de l'autre sans passer par la pile réseau. Selon Jeff Geerling, la latence descend sous les 50 microsecondes, pour un débit pratique de 50 à 60 Gbit/s. Le framework d'apprentissage automatique d'Apple, MLX, utilise ce pilote à partir de la version 0.30.1 via le backend de communication jaccl.

Deux façons de répartir un modèle

• Parallélisme de pipeline : le modèle est découpé en profondeur. Le Mac 1 calcule les premières couches, le Mac 2 les suivantes. Seul un petit résultat intermédiaire transite entre les machines à chaque token. C'est robuste, même sur des liaisons lentes, mais cela n'apporte pratiquement aucun gain de vitesse en génération, car les couches s'exécutent toujours l'une après l'autre. Le bénéfice n'apparaît qu'à la lecture de prompts très longs, car les segments peuvent se chevaucher. Apple mesure jusqu'à 1,8 fois plus rapide à 64 000 tokens.
• Parallélisme de tenseurs : chaque couche est répartie en largeur sur les deux machines. Les deux calculent en même temps, mais doivent se synchroniser à chaque token et à chaque couche. Sans RDMA, la communication annule le gain. Avec RDMA, c'est la voie vers une véritable accélération.

Ce que mesure Apple

Le 15 octobre 2026, Apple a publié ses propres mesures sur le M5 Ultra. Vitesse de décodage en tokens par seconde :

La lecture est claire : le pipeline apporte de la capacité, le parallélisme de tenseurs apporte capacité et vitesse, soit environ un facteur 1,6 à 1,8 avec deux machines. C'est cette distinction qui décide ensuite si un cluster vaut la peine.

Ce qu'il faut pour l'installation

• Le RDMA doit être activé une fois sur chaque Mac en mode de récupération avec rdma_ctl enable.
• Les Mac sont reliés directement par des câbles Thunderbolt 5, et au-delà de deux machines, chacune avec toutes les autres. Le port Thunderbolt 5 à côté du port Ethernet ne convient pas. Dans ses tests, Apple utilise deux câbles par liaison pour doubler la bande passante.
• Toutes les machines doivent avoir exactement la même version de macOS. Les mises à jour doivent donc toujours être installées ensemble.
• Un piège fréquent en pratique : si la liaison Thunderbolt n'a qu'une adresse 169.254 attribuée automatiquement, la connexion bascule discrètement sur le LAN, voire le Wi-Fi. La solution : une adresse IPv4 manuelle sur le port Thunderbolt des deux Mac, par exemple 10.10.0.1 et 10.10.0.2.

Le calcul de mémoire : que tient-il dans 2 × 256 Go ?

Un Mac de 256 Go ne met pas la totalité des 256 Go à disposition du GPU. macOS a besoin de mémoire, et la limite GPU doit être relevée avec sudo sysctl iogpu.wired_limit_mb. Un utilisateur fait tourner deux M5 Ultra sans écran avec 250 Go réglés manuellement par machine. De manière réaliste, un cluster laisse donc environ 450 à 500 Go pour les poids, le cache KV et les tampons de travail. Il s'agit de notre estimation, pas d'une valeur constructeur.

La règle empirique pour les poids : nombre de paramètres multiplié par les bits par poids, divisé par huit.

* Avec les facteurs d'échelle du format NVFP4, Apple estime Muse Spark Open à environ 493 Go.

Le résultat : à 3 à 3,5 bits par poids, toute la classe de modèles de 750 à 820 milliards de paramètres tient dans deux machines de 256 Go. Les modèles de plus d'un billion de paramètres ne tiennent pas. Pour la version 4 bits de Muse Spark Open, Meta indique deux Mac Studio de 512 Go chacun.

Étude de cas : DeepSeek V4.1 Flash 1017

Le 17 octobre 2026, DeepSeek a publié une mise à jour de son modèle Flash, avec des poids ouverts sous licence MIT. Le modèle est particulier pour le matériel local à plusieurs titres :

• Architecture : c'est le premier modèle DeepSeek doté d'une architecture encodeur-décodeur causale. Ses 40 couches se répartissent en 20 couches d'encodeur et 20 de décodeur. Le backbone compte 552 milliards de paramètres, dont seulement 8 milliards actifs par token en lecture et 16 milliards en génération.
• Cache KV minuscule : selon la fiche du modèle, le cache KV n'occupe que 890 octets par token. Même un million de tokens de contexte occupe moins d'un gigaoctet. Pour ce modèle, le goulot d'étranglement n'est pas le contexte mais uniquement les poids.
• Taille totale : Hugging Face compte 763 milliards de paramètres. L'écart avec le backbone provient probablement de composants supplémentaires comme les tables Engram, l'encodeur de vision et les couches de décodage spéculatif. Les deux fichiers Engram pèsent ensemble un peu plus de 200 Go et peuvent rester sur le SSD.
• Déjà nativement en 4 bits : DeepSeek livre les experts en FP4 et le reste en FP8. Le gain habituel d'une quantification en 4 bits ne s'applique donc pas à ce modèle.

Que valent les quants ?

Pour faire tenir un modèle de 552B sur une seule machine de 256 Go, il faut descendre sous les 3 bits par poids. La question est de savoir combien de qualité cela coûte. Les valeurs suivantes proviennent des publications de leurs auteurs respectifs et sont mesurées par rapport au modèle 1017 natif. Top-1 indique à quelle fréquence le quant choisit le même token suivant que l'original. La KLD mesure l'écart entre les distributions de probabilité ; plus elle est basse, mieux c'est.

Les méthodes de mesure diffèrent selon les auteurs ; les chiffres ne sont donc pas comparables à la décimale près. Trois constats restent néanmoins solides :

1. Le format compte plus que le nombre de bits. Les builds EXL3 autour de 2,8 bpw sont pratiquement au niveau de l'original. Pour le build sudoingx, HumanEval+, MBPP+ et IFEval sont restés dans la marge de bruit du modèle natif. Les quants MLX simples de taille comparable s'en écartent d'un ordre de grandeur de plus.
2. Les textes non anglais souffrent en premier. Dans le build Rapid-MLX, l'écart reste faible pour le code (KLD 0,055) et les mathématiques (0,063), mais monte à 0,14 à 0,18 pour la conversation générale. Les textes non anglais et les connaissances de niche dérivent le plus. Dans le build REAP, la concordance sur les textes multilingues tombe à 52 %. Si vous travaillez en français, testez les quants avec vos propres prompts en français.
3. Les chiffres Mac les plus rapides proviennent d'un paquet sans métriques de qualité publiées. Comme EXL3, le format Sushi-STQ stocke les experts selon la méthode treillis efficace, ce qui laisse espérer une bonne qualité par bit. Mais 1,75 bpw, c'est très peu. Tant qu'aucune valeur de KLD n'est publiée, mesurez par vous-même.

Les moteurs : état fin octobre 2026

Le rythme est remarquable. DeepSeek a publié 1017 le 17 octobre. Cinq jours plus tard, il tournait réparti sur deux Mac dans mlx-serve, et le 28 octobre est arrivé le système de plugins avec le noyau Sushi. En quelques jours, le dépôt de plugins a ajouté plusieurs optimisations qui ont chacune accéléré la lecture des longs prompts de 4 à 16 %. Point important pour évaluer le risque : la base, à savoir le RDMA dans macOS et jaccl dans MLX, provient officiellement d'Apple. Les projets communautaires s'appuient dessus.

Mesuré : un M5 Ultra face au cluster

Un seul M5 Ultra de 256 Go

Les chiffres les plus solides proviennent des pull requests du dépôt de plugins. Conditions : M5 Ultra de 256 Go, macOS 27.2, paquet Sushi-STQ 1,75 bpw, les 384 experts de chaque couche en RAM, une requête à la fois.

Environ 198 Go sont disponibles pour les experts, assez pour les 384 experts de chaque couche. Avec un paquet de 3,0 bpw dans le code de modèle natif de mlx-serve, des mesures antérieures donnaient 56,8 tok/s sans et 48 à 82 tok/s avec décodage spéculatif, selon le type de texte. Les développeurs de mlx-serve ont depuis publié sur X un benchmark avec le paquet DeepSeek-V4.1-Flash-1017-iQ-MLX-3.0bpw sur un M5 Ultra de 256 Go. Conditions selon la capture d'écran : décodage glouton, une requête, médiane de trois exécutions après un échauffement.

La capture ne précise pas la longueur de contexte de la mesure de prefill. Pour le travail d'agent et les textes non anglais, la valeur pour un texte nouveau est la plus réaliste.

De manière indépendante, un build communautaire basé sur TensorFold confirme l'ordre de grandeur : sur un seul M5 Ultra de 256 Go, il mesure 67,5 à 94,4 tok/s avec décodage spéculatif et 1 093 à 1 392 tok/s de prefill sur un prompt à froid, avec entrée image, appels d'outils et 1 M tokens de contexte.

Ce que montrent jusqu'ici les mesures de cluster avec DeepSeek V4.1

À la date de publication, nous n'avons trouvé aucune mesure publiée pour deux M5 Ultra avec un RDMA fonctionnel. Trois points de données sont toutefois instructifs :

• 2× M5 Ultra 256 Go, oMLX (rapport de bug du 20 octobre) : d'abord 1 tok/s, puis 16,7 tok/s après les corrections de la version 0.7.2. Cette valeur n'est toutefois pas représentative : selon le mainteneur, la connexion passait par un anneau TCP classique au lieu du RDMA, car l'adresse était sur le pont Thunderbolt au lieu du port Thunderbolt. Avec 256 Go par Mac, seul le parallélisme de tenseurs tenait pour ce paquet, et les tables Engram restent sur le SSD.
• 2× M3 Ultra via Thunderbolt, oMLX 0.7.3rc1 (notes de version, paquet oQ4e) : pipeline 32,4 à 34,3 tok/s, parallélisme de tenseurs 24,3 à 25,4 tok/s. Selon les mêmes notes, un seul M3 Ultra atteint 34,3 tok/s avec le même paquet. Le cluster est donc ici au mieux aussi rapide, et plus lent avec le parallélisme de tenseurs.
• 3× M5 Max de 128 Go chacun, poids natifs, RDMA (montage expérimental) : 35,6 tok/s pour une requête unique.

Selon la description de son code, mlx-serve répartit DeepSeek V4.1 en cluster par couches, donc en pipeline. D'après les mesures d'Apple, cela n'apporte aucun gain de vitesse en génération.

L'analyse : pour DeepSeek V4.1, il n'existe à ce jour aucune preuve publique qu'un cluster soit plus rapide qu'une seule machine. Une raison plausible : avec seulement 16 milliards de paramètres actifs par token, le calcul par couche est faible, tandis que le coût de synchronisation entre machines reste le même. Apple observe le même effet dans ses mesures : les modèles denses passent mieux à l'échelle sur plusieurs machines. De nouvelles mesures paraissent presque chaque jour. Face à des chiffres de cluster, vérifiez toujours trois détails : la liaison passait-elle par RDMA, quel paquet a été utilisé, et à quelle longueur de contexte la mesure a-t-elle été faite ? Pour 1017, la conclusion demeure : le modèle tient sur une machine, et c'est là qu'il tourne le plus vite aujourd'hui.

À titre de comparaison côté NVIDIA : deux DGX Spark font tourner 1017 avec le build EXL3 à 2,8 bpw, à une qualité proche de l'original, à environ 104 tok/s pour le code, 58 pour la prose et 144 pour les sorties structurées. Nous avons mesuré les performances d'un cluster de 4 DGX Spark en auto-hébergement ici (en allemand).

512 Go ou deux fois 256 Go ?

Apple a ouvert les commandes de la configuration 512 Go le 28 octobre, avec un délai de livraison de 7 à 8 semaines. Aux États-Unis, elle coûte 22 299 dollars, soit exactement 11 500 dollars de plus que la même configuration en 256 Go. En Allemagne, un M5 Ultra avec CPU 36 cœurs, GPU 80 cœurs, 256 Go et SSD de 1 To coûte 12 429 euros d'après les suppléments indiqués par Macwelt. Nous n'avons pas pu vérifier de prix en euros pour la version 512 Go à la date de publication.

Une machine de 512 Go coûte donc à peu près autant que deux machines de 256 Go.

Le visuel « Two 256GB M5 Ultras beat one 512GB »

Un visuel circule sur X selon lequel deux machines de 256 Go battent nettement une machine de 512 Go : environ 215 à 245 au lieu de 135 TFLOPS, 1,9 à 2,2 au lieu de 1,2 To/s, 75 à 100 au lieu de 45 à 60 tok/s pour DeepSeek V4.1 Flash et 55 à 70 au lieu de 33 à 40 tok/s pour GLM-5.3. Nous partageons l'orientation générale : pour les modèles qui ont vraiment besoin de 512 Go et dont le moteur maîtrise le parallélisme de tenseurs via RDMA, deux machines de 256 Go sont le meilleur choix. En tant que mesure, en revanche, le visuel ne tient pas :

• Aucun détail de mesure : moteur, quantification et longueur de contexte manquent. Les valeurs sont données avec un tilde et sous forme de fourchettes, et les valeurs de cluster valent systématiquement environ 1,7 fois les valeurs d'une seule machine. C'est exactement le facteur qu'Apple mesure pour les modèles denses. Il s'agit donc vraisemblablement d'une extrapolation.
• La valeur mono-machine pour DeepSeek V4.1 ne correspond pas aux mesures : un M5 Ultra de 256 Go, soit la même puce que dans la machine de 512 Go, atteint 92 tok/s avec un paquet 3 bits. Une machine de 512 Go serait tout aussi rapide avec le même paquet. Les 45 à 60 tok/s n'ont de sens que si une variante plus précise, et donc plus lente, tourne sur la machine de 512 Go. Mais le visuel compare alors des quantifications différentes.
• La valeur du cluster correspond à une seule machine de 256 Go : un seul M5 Ultra de 256 Go atteint déjà les 75 à 100 tok/s annoncés pour deux machines. Pour DeepSeek V4.1, la seconde machine n'apporte donc pour l'instant pas de vitesse, seulement de la place pour une précision plus élevée.

Une idée reçue répandue

Une machine de 512 Go ne rend pas le même modèle plus rapide. La puce et la bande passante mémoire sont identiques à celles du modèle 256 Go. Utiliser la mémoire supplémentaire pour une précision plus élevée ralentit même la génération, car davantage d'octets doivent être lus par token. 1017 en 4 bits tourne donc plus lentement sur la machine de 512 Go qu'en un peu moins de 3 bits sur celle de 256 Go.

Ce qui reste à la machine de 512 Go

Si vous acceptez de faire tourner des modèles de la classe 750B à 3 à 3,5 bits, deux machines de 256 Go offrent la même capacité. Le seul avantage réel restant à la machine de 512 Go est l'indépendance vis-à-vis de la prise en charge du cluster : elle exécute tout modèle que le moteur prend en charge. S'y ajoute l'évolution vers 1 To avec deux machines de 512 Go, par exemple pour Muse Spark Open en 4 bits.

Les moteurs vont-ils s'améliorer ? Oui, mais pas partout

Les progrès logiciels profitent aux deux options de manière différente.

Ce que les moteurs peuvent améliorer :

• De meilleurs quants : la même qualité avec moins de bits rend 256 Go suffisants pour des modèles toujours plus grands. Cela plaide contre le surcoût des 512 Go.
• Le streaming SSD : les moteurs lisent à la demande sur le SSD les parties du modèle trop volumineuses. C'est ainsi que mlx-serve fait tourner GLM-5.3, avec 744 milliards de paramètres, sur un seul Mac de 256 Go.
• La prise en charge du cluster pour davantage de modèles : chaque extension rend deux machines de 256 Go plus utiles.
• Un parallélisme de tenseurs plus efficace : plus de gain par machine supplémentaire.

Ce que les moteurs ne peuvent pas changer :

• La bande passante mémoire par Mac : la génération est limitée par elle, et 1,2 To/s restent 1,2 To/s.
• La liaison Thunderbolt : la latence et un débit pratique de 50 à 60 Gbit/s limitent le passage à l'échelle du parallélisme de tenseurs.
• Le nombre de machines : des moteurs courants comme exo exigent des puissances de deux pour le parallélisme de tenseurs, soit 2 ou 4 machines. Un maillage complet est limité par les ports Thunderbolt.
• La croissance des modèles : Muse Spark Open compte 816 milliards de paramètres, DeepSeek V4 Pro en avait 1,6 billion, et DeepSeek a laissé entrevoir un V4.1 Pro.

Au final, les progrès logiciels plaident plutôt pour l'achat progressif de machines de 256 Go que pour la machine de 512 Go.

Streaming SSD et usure

Qui fait tourner des modèles en streaming depuis le SSD se demande à juste titre si cela l'use. La réponse courte : le streaming lui-même, non. Les cellules flash s'usent à l'écriture, pas à la lecture. Des lectures fréquentes peuvent influencer très légèrement les cellules voisines. Le contrôleur rafraîchit alors les blocs concernés en arrière-plan, ce qui est négligeable par rapport à une utilisation normale.

Les écritures ont lieu à trois endroits : lors de la mise en swap de la mémoire, lors de l'enregistrement des états de conversation dans le cache de prompts et lors du téléchargement de modèles. Apple ne publie aucune donnée d'endurance. Nous retenons donc une valeur typique pour les SSD TLC d'environ 600 To écrits par To de capacité, soit environ 2 400 To pour un SSD de 4 To. Il s'agit d'une hypothèse, pas d'une spécification du fabricant.

Les valeurs de cache sont des exemples de calcul approximatifs. Pour DeepSeek V4.1, 128 000 tokens d'état de conversation ne pèsent qu'environ 110 Mo grâce au petit cache KV.

Le vrai risque est le swap causé par un budget mémoire trop serré. Comme le SSD du Mac Studio ne se remplace pas simplement soi-même, un contrôle s'impose :

1. Après l'installation, lancer brew install smartmontools et smartctl -a disk0 et noter « Percentage Used » et « Data Units Written ».
2. Mesurer à nouveau après quatre semaines. Si « Percentage Used » augmente de plus de 1 % par mois, le swap en est généralement la cause.
3. Surveiller sysctl vm.swapusage pendant l'inférence et réduire le budget mémoire du moteur si la valeur continue de croître.

Le plus gros inconvénient du streaming reste de toute façon la vitesse. La vitesse de génération dépend alors du débit de lecture du SSD. Avec 1017, Sushi atteint en streaming 76,6 tok/s pour le code et 49,3 pour la prose sur un M5 Max de 128 Go ; un M5 Ultra avec le modèle entier en RAM va nettement plus vite.

Notre recommandation

1. Acheter dès maintenant un M5 Ultra de 256 Go (CPU 36 cœurs, GPU 80 cœurs, SSD d'au moins 4 To pour plusieurs paquets de modèles). Il suffit entièrement pour DeepSeek V4.1 Flash 1017, avec mlx-serve et le plugin sushi_ds41 ou directement avec Sushi.
2. Vérifier soi-même la qualité des quants, en particulier dans d'autres langues que l'anglais. Tant qu'aucune valeur de KLD n'est publiée pour les paquets STQ rapides, comparer avec l'API DeepSeek à l'aide de ses propres prompts.
3. N'acheter la seconde machine de 256 Go que si deux conditions sont réunies : un modèle dont vous avez besoin ne tient plus sur une machine, et votre moteur prend en charge de manière avérée le parallélisme de tenseurs via RDMA pour ce modèle.
4. Ne choisir la machine de 512 Go qu'en guise d'assurance : si vous ne voulez aucune dépendance à la prise en charge du cluster, ou si vous prévoyez d'emblée deux machines de 512 Go pour 1 To.
5. Soigner l'exploitation : fonctionner sans écran, relever la limite GPU, désactiver le pont Thunderbolt, attribuer des adresses IP fixes au port Thunderbolt et surveiller le swap.

Questions fréquentes

Peut-on combiner deux Mac Studio de 256 Go en une machine de 512 Go ? Pas au sens d'une mémoire partagée pour n'importe quel programme. Les moteurs d'inférence comme MLX, mlx-serve ou oMLX peuvent en revanche répartir un modèle sur les deux machines, via Thunderbolt 5 avec RDMA à partir de macOS 26.2. En pratique, environ 2 × 250 Go sont utilisables. Que cela fonctionne dépend de la prise en charge du modèle concerné en cluster par le moteur.

Un cluster de deux Mac est-il plus rapide qu'un seul Mac ? Seulement avec le parallélisme de tenseurs via un vrai RDMA. Apple mesure alors un facteur d'environ 1,6 à 1,8 sur le M5 Ultra. Avec le parallélisme de pipeline, la vitesse de génération reste pratiquement la même. Pour DeepSeek V4.1, les mesures de cluster publiées jusqu'ici ne montrent aucun avantage par rapport à une seule machine. Un seul M5 Ultra fait tourner le modèle à environ 90 à 100 tok/s.

DeepSeek V4.1 Flash 1017 tourne-t-il sur un seul Mac Studio de 256 Go ? Oui. Avec un paquet 3 bits, les développeurs de mlx-serve mesurent 92 tok/s en génération et près de 3 900 tok/s en lecture sur un M5 Ultra de 256 Go. Le paquet Sushi-STQ à 1,75 bpw atteint environ 100 tok/s. Les tables Engram restent sur le SSD. Aucune métrique de qualité n'a encore été publiée pour les paquets Sushi-STQ.

Le surcoût des 512 Go en vaut-il la peine ? Pour la plupart, non. Le surcoût équivaut à peu près à une seconde machine de 256 Go, et la machine de 512 Go ne rend pas le même modèle plus rapide. Il se justifie si vous voulez faire tourner des modèles de la classe 750B à une précision plus élevée sans aucune dépendance à la prise en charge du cluster, ou si vous prévoyez d'évoluer vers 1 To avec deux machines de 512 Go.

Le streaming détruit-il le SSD ? Non. Le streaming ne fait que lire, et la lecture n'use pratiquement pas la mémoire flash. Ce qui compte, c'est un swap permanent dû à un budget mémoire trop serré. smartctl et sysctl vm.swapusage permettent de le surveiller facilement.

Dans quelle mesure la quantification dégrade-t-elle la qualité ? Cela dépend surtout du format. Les builds EXL3 autour de 2,8 bpw concordent avec l'original DeepSeek V4.1 Flash 1017 dans environ 96 % des cas, les quants MLX 2 bits simples seulement dans environ 80 %. Les langues autres que l'anglais perdent en qualité en premier.

Sources

• 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, version v26.10.3 (22/10/2026) – https://github.com/ddalcu/mlx-serve/releases/tag/v26.10.3
• mlx-serve PR #895 : DeepSeek-V4.1 sur une paire Thunderbolt – https://github.com/ddalcu/mlx-serve/pull/895
• mlx-serve PR #911 : décodage DeepSeek-V4.1 sur 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 et #11 : mesures de prefill et de décodage, M5 Ultra 256 Go – https://github.com/CommunityServe/plugins/pull/10 et 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 sur 2× M5 Ultra 256 Go – https://github.com/jundot/omlx/issues/4720
• Versions oMLX (0.7.3rc1, mesures de cluster 2× M3 Ultra) – https://github.com/jundot/omlx/releases
• Discussion MLX #4491 : DeepSeek V4.1 Flash sur trois Mac M5 Max – https://github.com/ml-explore/mlx/discussions/4491
• BobClawblaw/deepseek-v41-flash-mlx-m5-ultra (build TensorFold pour un M5 Ultra) – https://github.com/BobClawblaw/deepseek-v41-flash-mlx-m5-ultra
• sudoingX/dgx-spark-deepseek-v41, versions (qualité EXL3 et vitesse DGX Spark) – https://github.com/sudoingX/dgx-spark-deepseek-v41/releases
• rapid-mlx/DeepSeek-V4.1-Flash-1017-MLX (mesure de 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 (experts FP4 natifs) – 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 et fork avec branche 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 : délai de livraison du Mac Studio 512 Go – https://appleosophy.com/2026/10/28/mac-studio-with-512gb-of-ram-now-available-starts-at-22299/
• Macwelt : Mac Studio M5 Max et M5 Ultra, prix en Allemagne – https://www.macwelt.de/article/3220005/mac-studio-m5-max-m5-ultra.html
• iThinkDiff : Mac Studio 512 Go et Muse Spark Open – https://www.ithinkdiff.com/512gb-mac-studio-m5-ultra-price-22299/
• Développeurs de mlx-serve : capture du benchmark DeepSeek-V4.1-Flash-1017-iQ-MLX-3.0bpw sur M5 Ultra 256 Go, publiée sur X (octobre 2026)
• Visuel « Two 256GB M5 Ultras beat one 512GB », diffusé sur X (octobre 2026, auteur inconnu)