Exo: transformar varias máquinas en un clúster de LLM maison

#Lo que hace Exo en la práctica

Sus creadores presentan Exo (repositorio exo-explore/exo, cerca de 48.000 estrellas en GitHub a fecha del 28 de septiembre de 2026) como una herramienta para «ejecutar IA de vanguardia en local». Los dispositivos que ejecutan Exo se descubren automáticamente en la red, sin configuración manual, y ofrecen un panel de control y una API en la dirección http://localhost:52415 en cada nodo.

El proyecto destaca un paralelismo tensorial «topology-aware»: Exo evalúa en tiempo real la topología de red (latencia, ancho de banda entre cada par de máquinas) y los recursos de cada dispositivo para decidir cómo distribuir un modelo, en lugar de aplicar una partición fija idéntica independientemente del hardware disponible.

#Memoria acumulada: el aporte real

El beneficio más tangible de un clúster Exo es la suma de la memoria disponible. Una configuración ilustrada por el propio proyecto combina 4 Mac Studio M3 Ultra de 512 GB cada uno para cargar DeepSeek v3.1 en 8 bits y Kimi-K2-Thinking en 4 bits simultáneamente: modelos que ninguna de estas máquinas podría cargar por sí sola, ni siquiera con 512 GB.

En cuanto al cálculo, Exo afirma que el paralelismo tensorial permite aumentar la velocidad hasta 1,8 veces con 2 dispositivos y hasta 3,2 veces con 4 dispositivos. Se trata de factores de aceleración del cálculo distribuido, no de tasas de generación de tokens por segundo: el número real de tokens generados por segundo sigue dependiendo del modelo, de la cuantización y, como veremos más abajo, de la red entre las máquinas.

#El costo de red: qué cambia el RDMA

Conectar máquinas en red introduce una latencia que no tiene una GPU única. Exo aborda este problema con soporte RDMA (acceso directo a la memoria remota) sobre Thunderbolt 5, anunciado desde el lanzamiento de esta funcionalidad, y afirma que reduce un 99 % la latencia entre dispositivos respecto a una conexión de red convencional.

Esta capacidad RDMA no es universal: se basa en una funcionalidad añadida a macOS 26.2 y solo funciona en equipos Mac con Thunderbolt 5: Mac mini M4 Pro, Mac Studio M4 Max o M3 Ultra y MacBook Pro M4 Max, según la lista oficial. El proyecto exige además que todos los dispositivos del clúster RDMA estén interconectados entre sí mediante cables certificados TB5 y que la versión de macOS, incluidas las versiones beta, sea exactamente la misma en todas las máquinas; de lo contrario, los puertos RDMA podrían no descubrirse mutuamente.

#Matriz de plataformas realmente compatibles

Esta tabla contradice una hipótesis extendida: Exo no es una herramienta que haga funcionar un clúster heterogéneo de Mac y PC a plena velocidad. El backend de inferencia MLX es específico de Apple Silicon; en Linux, el README oficial indica claramente que Exo funciona actualmente en CPU, sin aceleración GPU, con soporte de GPU anunciado como «en desarrollo», sin una fecha de lanzamiento especificada.

#Instalar un clúster en la práctica

1. 01
   Preparar cada máquina macOS

   Instalar Xcode (para la cadena de herramientas de Metal), Homebrew, uv y Node, requisitos documentados para compilar y ejecutar Exo desde el código fuente en macOS.
2. 02
   Clonar y lanzar Exo

   git clone du dépôt, construction du tableau de bord (npm install && npm run build), puis uv sync --extra mlx et uv run exo sur chaque machine.
3. 03
   Verificar la detección automática

   Los dispositivos en la misma red se descubren sin configuración; el panel accesible en http://localhost:52415 debe listar cada nodo activo del clúster.
4. 04
   Activar el RDMA si el hardware lo permite

   En equipos Mac con Thunderbolt 5 y macOS 26.2+, activar rdma_ctl enable desde el modo Recovery en cada máquina y luego conectar todos los dispositivos entre sí con cables certificados TB5.
5. 05
   Cargar un modelo distribuido

   Desde el panel de control o la API, elegir un modelo cuyo tamaño supere la memoria de un solo dispositivo para comprobar de forma concreta que la distribución funciona antes de intentar ejecutar modelos aún más grandes.

#API compatibles y clientes existentes

Exo expone varias API compatibles: OpenAI Chat Completions, OpenAI Responses, Claude Messages y Ollama; un cliente ya escrito para uno de estos formatos puede conectarse al clúster Exo sin necesidad de reescribirlo. Es una elección pragmática que evita tener que adoptar un protocolo propietario para aprovechar el clúster.

Las variables de entorno completan la configuración para un uso avanzado: EXO_OFFLINE para funcionar sin conexión a internet una vez que los modelos ya estén en caché, EXO_MODELS_READ_ONLY_DIRS para compartir un almacenamiento de modelos de solo lectura entre máquinas (útil para un montaje NFS común) y EXO_LIBP2P_NAMESPACE para aislar varios clústeres Exo en la misma red física.

#Modelos personalizados desde Hugging Face

Exo no se limita a un catálogo cerrado de modelos: el proyecto admite modelos personalizados directamente desde Hugging Face Hub, más allá de los despliegues de demostración destacados por sus creadores (DeepSeek v3.1 con 671 mil millones de parámetros, Qwen3-235B, Kimi-K2-Thinking). Esto permite probar un modelo reciente en cuanto se publica en el Hub, sin esperar a que se añada a una lista de modelos oficialmente compatibles.

Esta apertura tiene una contrapartida documentada: los modelos personalizados que requieren trust_remote_code en su configuración deben activarse explícitamente, ya que este ajuste está desactivado por defecto por razones de seguridad. Ejecutar código arbitrario proporcionado por un repositorio de terceros de Hugging Face en todas las máquinas del clúster no es, por tanto, un comportamiento por defecto, sino una elección que debe hacerse conscientemente para los modelos que lo requieren.

• Explorar los modelos en Hugging Face Hub

#Seguridad: un clúster sin autenticación documentada

El README oficial y la documentación del panel no mencionan ningún mecanismo de autenticación, clave de API, token o cifrado TLS para la API y el panel de Exo: según el estado documentado a fecha de 28 de septiembre de 2026, cualquiera que pueda acceder al puerto 52415 de un nodo puede consultar la API o ver el panel, sin iniciar sesión.

Este punto merece aún más atención porque cada máquina del clúster expone su propia API en la red local: en una configuración con varios dispositivos, la superficie expuesta es la de cada nodo por separado, no solo la de un único punto de entrada que se podría proteger de forma aislada.

#Solución de problemas: síntomas, causa, corrección

#Limitaciones y dificultades que conviene prever

Sin soporte documentado para Windows

El repositorio oficial no menciona compatibilidad con Windows a fecha del 28 de septiembre de 2026; las opciones de instalación solo cubren macOS y Linux.

Linux limitado a la CPU

La inferencia acelerada por GPU en Linux está en desarrollo, sin fecha anunciada; un clúster formado únicamente por máquinas Linux será considerablemente más lento que un clúster Apple Silicon equivalente.

RDMA con requisitos de hardware exigentes

Thunderbolt 5, macOS 26.2 o posterior y versiones del sistema estrictamente idénticas en todas las máquinas: basta con que un dispositivo no cumpla estos requisitos para que vuelva a utilizar una red convencional, más lenta.

Velocidad no garantizada

Los factores de aceleración (1,8x, 3,2x) miden la aportación del paralelismo tensorial al cálculo distribuido, no una tasa de tokens por segundo que puedas trasladar tal cual a tu propio modelo y a tu propia red.

• LLM multi-GPU con llama.cpp: tensor-split 2× RTX 3090
• llama.cpp vs vLLM vs Exllama
• Desplegar un LLM en producción con Docker Compose
• Principios de seguridad de un servidor de inferencia expuesto
• Fuente: repositorio oficial de Exo en GitHub
• Fuente: README oficial del repositorio Exo