Un cluster de 1000 Mac Mini M4 assemblé en Chine : où est le piège ?

Une histoire circule sur les chaînes Telegram : en Chine, un cluster d’environ 1000 Mac Mini M4 aurait été assemblé pour faire tourner de l’IA entièrement en local, sans cloud. Les arguments sont séduisants : à partir de $599 pièce et 10–30 W par appareil, contre 300–500 W pour un serveur GPU. L’idée centrale de cette tendance consiste à transformer l’IA, aujourd’hui facturée sous forme d’abonnement mensuel, en un actif que l’on possède.

Impossible toutefois de vérifier cette histoire : la publication ne donne ni le nom de l’entreprise, ni le modèle utilisé, ni la vitesse de génération, et son unique lien renvoie à la chaîne de l’auteur. Examinons donc les possibilités techniques derrière cette affirmation, plutôt que ce cas lui-même.

Quel problème cela résout-il ?

Le principe de l’inférence dans le cloud est simple : vous payez au token ou par abonnement, et vos données sont envoyées au fournisseur. Pour la santé, la finance, le secteur public et toute équipe manipulant des documents sensibles, c’est souvent rédhibitoire. La facture augmente aussi avec la charge et devient difficile à prévoir. Un cluster local change la donne : les données restent dans le périmètre de l’organisation et les dépenses deviennent des investissements. Vous achetez le matériel une fois, puis payez essentiellement l’électricité et la maintenance.

Là où le calcul ne tient plus

La comparaison « 10–30 W contre 300–500 W » n’est pas pertinente. Ce qu’il faut comparer, ce ne sont pas les watts par appareil, mais l’énergie consommée et le coût pour chaque token généré. La vitesse d’inférence des modèles de langage est presque toujours limitée par la bande passante mémoire. Celle du Mac Mini M4 de base est d’environ 120 Go/s, avec 16 Go de mémoire unifiée ; la version M4 Pro atteint environ 273 Go/s. Une H100 destinée aux serveurs offre environ 3,35 To/s, soit un à deux ordres de grandeur de plus. Une petite machine génère les tokens nettement plus lentement, et mille petites machines ne deviennent pas une seule grosse machine.

La raison : un grand modèle doit être réparti entre les nœuds, alors que les liaisons Ethernet ou Thunderbolt sont beaucoup plus lentes que la mémoire. En revanche, mille machines conviennent bien à un autre scénario : chacune héberge sa propre copie d’un petit modèle quantifié de 7–14 milliards de paramètres, et les requêtes sont réparties entre elles. On augmente ainsi le nombre de requêtes traitées en parallèle, pas la taille du modèle.

Prenons un exemple. Un service interne résumant des milliers de documents par jour, ou un chatbot d’assistance reposant sur un modèle 8B, se prête très bien à cette architecture : les tâches sont indépendantes, la qualité d’un petit modèle suffit et les données ne quittent pas les bureaux. En revanche, faire tourner sur un tel cluster un modèle de plusieurs centaines de milliards de paramètres avec une latence acceptable ne sera pas possible.

Comment procéder en pratique

Commencez par calculer le coût réel d’un token : amortissement du matériel sur 2–3 ans, électricité et temps d’administration, le tout divisé par le nombre de tokens effectivement produits sur cette période. Comparez le résultat au tarif API d’un modèle cloud de qualité comparable. Pour une charge faible à moyenne, le cloud sera probablement moins cher. Le local devient avantageux lorsque la charge reste élevée et régulière, ou lorsque les exigences de confidentialité sont strictes.

Pensez aussi à l’exploitation. Mille ordinateurs de bureau sous macOS nécessitent leur propre dispositif de supervision, des mises à jour, le remplacement des nœuds défaillants, des baies et du refroidissement. Ni le système d’exploitation ni le format matériel ne sont conçus pour les serveurs : les coûts cachés absorbent donc rapidement une partie des économies.

Si l’idée vous intéresse, ne commencez pas par mille machines. Prenez 2–4 Mac Mini, installez MLX, llama.cpp ou des frameworks de clustering comme exo, faites tourner votre modèle avec vos propres requêtes et mesurez le débit en tokens par seconde, la latence et la consommation. Passez à l’échelle seulement ensuite.

Bilan : un cluster privé composé de matériel peu coûteux et peu énergivore est une idée tout à fait viable, mais pour des usages de niche. Tant que cette histoire ne s’accompagne pas de chiffres, voyez-y une invitation à calculer votre propre rentabilité, plutôt qu’une preuve que le cloud serait devenu inutile.