Un clúster de 1000 Mac Mini M4 construido en China: hacemos cuentas para encontrar la trampa

En los canales de Telegram circula una historia: en China han construido un clúster de unos 1000 Mac Mini M4 y ejecutan IA de forma totalmente local, sin recurrir a la nube. Los argumentos resultan atractivos: desde $599 por unidad y un consumo de 10–30 W por dispositivo, frente a los 300–500 W de un servidor con GPU. La idea central de esta tendencia es convertir la IA de una suscripción mensual en un activo propio.

No es posible verificar la historia: la publicación no identifica la empresa ni el modelo, no aporta la velocidad de generación y su único enlace lleva al canal del propio autor. Por eso analizaremos qué podría haber detrás de la propuesta, en lugar del supuesto caso en sí.

Qué problema resuelve

La inferencia en la nube funciona de forma sencilla: se paga por tokens o por una suscripción, y los datos se envían al proveedor. Para la sanidad, las finanzas, el sector público y cualquier equipo que maneje documentos sensibles, esto suele ser un impedimento decisivo. Además, la factura aumenta con la carga de trabajo y resulta difícil de prever. Un clúster local cambia el planteamiento: los datos permanecen dentro de la infraestructura y el gasto pasa a ser una inversión de capital. El hardware se compra una vez y, a partir de ahí, se paga principalmente por electricidad y mantenimiento.

Dónde fallan las cuentas

La comparación de «10–30 W frente a 300–500 W» es incorrecta. Hay que comparar la energía y el dinero necesarios por cada token generado, no los vatios por dispositivo. La velocidad de inferencia de los modelos de lenguaje casi siempre está limitada por el ancho de banda de la memoria. El Mac Mini M4 básico ofrece unos 120 GB/s con 16 GB de memoria unificada; la versión M4 Pro alcanza aproximadamente 273 GB/s. Una H100 para servidores ofrece unos 3,35 TB/s, es decir, entre uno y dos órdenes de magnitud más. Un equipo pequeño genera tokens bastante más despacio, y mil equipos de este tipo no se convierten en uno grande.

El motivo es que un modelo grande debe repartirse entre los nodos, mientras que las conexiones Ethernet o Thunderbolt son mucho más lentas que la memoria. En cambio, mil equipos encajan bien en otro escenario: cada uno aloja su propia copia de un modelo pequeño y cuantizado de 7–14 mil millones de parámetros, y las solicitudes se distribuyen entre ellos. Así se escala el número de solicitudes simultáneas, no el tamaño del modelo.

Por ejemplo, un servicio interno que resume miles de documentos al día o un chatbot de soporte basado en un modelo de 8B encajan perfectamente en este esquema: las tareas son independientes, la calidad de un modelo pequeño es suficiente y los datos no salen de la oficina. En cambio, ejecutar en un clúster así un modelo de cientos de miles de millones de parámetros con una latencia aceptable no será posible.

Qué hacer en la práctica

Primero, calcule el coste real por token: amortización del hardware durante 2–3 años, electricidad y tiempo del administrador, divididos por el número real de tokens generados durante ese periodo. Compare el resultado con el precio de la API de un modelo en la nube de calidad comparable. Para cargas pequeñas y medianas, lo más probable es que la nube resulte más barata. La opción local gana con una utilización elevada y constante o con requisitos estrictos de privacidad.

Tenga en cuenta también la operación. Mil ordenadores de sobremesa con macOS requieren un sistema propio de monitorización, actualizaciones, sustitución de nodos averiados, racks y refrigeración. Ni el sistema operativo ni el formato están diseñados para servidores, por lo que los costes ocultos absorben rápidamente parte del ahorro.

Si la idea le interesa, no empiece con mil equipos. Utilice 2–4 Mac Mini, configure MLX, llama.cpp o frameworks para clústeres como exo, ejecute su modelo con sus propias solicitudes y mida los tokens por segundo, la latencia y el consumo. Solo entonces amplíe la instalación.

En definitiva, la idea de un clúster privado con hardware económico y de bajo consumo es viable, pero para casos de uso específicos. Mientras esta historia no aporte cifras, considérela una invitación a calcular sus propios costes, no una prueba de que la nube vaya a quedar obsoleta.