exo Review: inferencia de IA distribuida en múltiples dispositivos

Compilar desde el código fuente (macOS)

Requiere Xcode (para la cadena de herramientas Metal), Homebrew, uv, Node.js y una cadena de herramientas Rust nightly, según la propia lista de requisitos de exo. Ejecute lo siguiente en una terminal:

Descubrimiento automático de dispositivos

Los dispositivos que ejecutan exo en la misma red se encuentran sin configuración manual, mediante una capa de descubrimiento entre pares — la propia documentación de configuración de exo hace referencia a una base libp2p, expuesta a través de la variable de entorno EXO_LIBP2P_NAMESPACE para aislar varios clústeres en una misma red.

Modo auto-paralelo consciente de la topología

exo construye una vista en tiempo real de la topología del clúster — memoria disponible de cada dispositivo, más latencia y ancho de banda de los enlaces de red entre ellos — y usa esa vista para decidir cómo repartir un modelo entre los dispositivos, según el propio README de exo.

Paralelismo tensorial

Además de repartir las capas de un modelo entre dispositivos, exo aplica paralelismo tensorial dentro de ese reparto, al que el propio README de exo atribuye una aceleración de hasta 1,8x en 2 dispositivos y 3,2x en 4 dispositivos, en comparación con un reparto simple por capas sin esta técnica.

RDMA sobre Thunderbolt 5

En Mac con Thunderbolt 5 (Mac Mini M4 Pro, Mac Studio/MacBook Pro M4 Max, Mac Studio M3 Ultra) bajo macOS 26.2 o posterior, exo admite Remote Direct Memory Access sobre Thunderbolt, que su propia documentación describe como una reducción del 99 % en la latencia entre dispositivos. Activarlo requiere entrar en el modo de recuperación de macOS y ejecutar rdma_ctl enable desde la terminal de recuperación, según los propios pasos de configuración de exo.

Carga de modelos

El propio README de exo documenta la carga de modelos personalizados directamente desde Hugging Face Hub, además de soporte para fichas de modelo locales personalizadas almacenadas en ~/.local/share/exo/custom_model_cards/ en Linux (o el equivalente en macOS). La propia documentación de configuración de exo cita EXO_ENABLE_IMAGE_MODELS como indicador para activar el soporte de modelos de imagen, desactivado por defecto.

Niveles de plataforma en macOS

El propio PLATFORMS.md de exo clasifica los Mac Apple Silicon como soporte "Tier 1" (probado y mantenido), nombrando específicamente el Mac Studio M3 Ultra, el Mac Mini M4 Pro y el MacBook Pro M5/M4 Max como hardware probado. Apple ha lanzado desde entonces el Mac mini (M6/M5 Pro) y el Mac Studio (M5 Max/M5 Ultra); consulta directamente el PLATFORMS.md de exo para su lista actual de hardware probado.

Soporte de Linux

El propio README y PLATFORMS.md de exo son explícitos en que Linux actualmente funciona solo con CPU; el soporte de GPU (CUDA y Vulkan figuran ambos como planificados, no entregados) se describe como "en desarrollo", con el soporte de Linux CUDA y CPU figurando ambos bajo la sección propia de hoja de ruta "Planificado — Tier 1" de exo en el momento de esta review.

Soporte de Windows

El propio PLATFORMS.md de exo solo lista el soporte de Windows CUDA y Windows CPU bajo un encabezado "Longer term!", separado de los elementos de hoja de ruta de Linux a corto plazo y posterior a ellos — Windows no es compatible actualmente.

Ejecutar un modelo demasiado grande para un solo Mac

Instale exo en dos o más Mac Apple Silicon en la misma red, inicie uv run exo (o la app de macOS) en cada uno, y cargue un modelo cuyos pesos completos superen la memoria unificada de un solo dispositivo — el descubrimiento automático y el sharding consciente de la topología de exo lo reparten por el clúster sin asignación manual de capas.

Apuntar una herramienta compatible con OpenAI existente a un clúster local

Como exo expone una API compatible con OpenAI Chat Completions en http://localhost:52415 (o la dirección de un dispositivo del clúster), un cliente existente creado para la API de OpenAI, la API de Ollama o la API Claude Messages de Anthropic puede redirigirse a un clúster exo cambiando la URL base en lugar de reescribirlo.

Desarrollar sin conexión con modelos en caché

Establezca EXO_OFFLINE=true antes de iniciar exo para trabajar completamente con modelos ya descargados y almacenados en caché localmente, útil para probar una configuración de clúster sin depender del acceso de red a Hugging Face durante el desarrollo.

Use exo si

• Posee dos o más Mac Apple Silicon y quiere ejecutar modelos más grandes de lo que cabe en la memoria unificada de un solo Mac, en lugar de comprar un equipo con mucha memoria o alquilar tiempo de GPU en la nube
• Quiere descubrimiento automático de dispositivos y sharding consciente de la topología en lugar de decidir manualmente qué capas del modelo se ejecutan en qué dispositivo
• Tiene Mac compatibles con Thunderbolt 5 en macOS 26.2+ y quiere la opción de clustering de menor latencia que exo documenta actualmente (RDMA)
• Quiere una licencia de código abierto permisiva (Apache-2.0) sin dependencia de un proveedor
• Se siente cómodo compilando desde el código fuente con uv, o prefiere la app prediseñada de macOS si busca un servicio en segundo plano sin terminal

Espere, o busque otra opción, si

• Su hardware de clúster es exclusivamente Linux y necesita aceleración por GPU — el propio PLATFORMS.md de exo sigue listando el soporte de GPU en Linux como en desarrollo, con soporte solo de CPU entregado hoy
• Usa Windows — la propia hoja de ruta de exo solo lista el soporte de Windows como un elemento "a largo plazo", no disponible actualmente
• Necesita soporte de modelos en formato GGUF — la ruta documentada de carga de modelos de exo es MLX/Hugging Face Hub, no GGUF; vea en su lugar llama.cpp o GPUStack
• Solo tiene un dispositivo y no necesita clustering en absoluto — una herramienta de un solo equipo como Ollama o LM Studio es una opción más sencilla
• Necesita una organización de soporte empresarial establecida — exo lo desarrolla un equipo pequeño (exo labs), el soporte pasa por los issues de GitHub y los canales de la comunidad, no por un SLA formal

Error 1: esperar soporte de modelos GGUF

exo carga modelos mediante MLX desde Hugging Face Hub, según su propio README; no documenta importación de GGUF. Quien tenga ya una biblioteca de archivos GGUF debería en su lugar considerar una herramienta GGUF-first como llama.cpp, Ollama o GPUStack.

Error 2: suponer que Linux obtiene la misma aceleración por GPU que macOS

El propio PLATFORMS.md de exo deja claro que Linux actualmente funciona solo con CPU, con soporte de GPU (CUDA/Vulkan) listado como planificado, no entregado. Agrupar varios equipos Linux con GPU para inferencia acelerada por GPU no es todavía lo que documenta la ruta de Linux de exo.

Error 3: esperar una aceleración casi lineal con cualquier conexión de red

Las cifras de aceleración documentadas por exo (hasta 1,8x en 2 dispositivos, 3,2x en 4) y los benchmarks RDMA de terceros citados asumen ambos enlaces de clase Thunderbolt, en varios casos con RDMA explícitamente activado. Un clúster conectado por Wi-Fi normal o Ethernet gigabit no necesariamente alcanzará las mismas cifras — la propia documentación de exo no publica cifras para esa configuración.

Error 4: tratar exo como una app de escritorio de un solo dispositivo

exo es un framework de clustering que se instala y ejecuta en cada dispositivo que se une al clúster, no una aplicación de chat de un clic — aunque la app en segundo plano prediseñada de macOS reduce considerablemente la barrera de entrada en un solo Mac frente a compilar desde el código fuente.