Mesh LLM: ¿Puede un LLM ejecutarse en varios ordenadores?

Sí. Mesh LLM puede ejecutar un modelo grande compatible entre varios ordenadores cuando ninguno tiene memoria suficiente por sí solo. Skippy asigna rangos contiguos de capas a distintos peers. Cada uno descarga los fragmentos GGUF de su etapa y las activaciones cruzan la cadena por cada token generado. La aplicación sigue llamando a un único endpoint compatible con OpenAI en http://localhost:9337/v1.

La respuesta de compra necesita una precisión: sumar capacidad no garantiza sumar velocidad. Cada etapa añade comunicación al decode secuencial y el peer más lento puede limitar toda la ruta. Mesh LLM tiene más sentido cuando el modelo no cabe en ninguna máquina. Si ya cabe, ejecutarlo localmente suele ser más rápido y fiable.

Este análisis refleja el repositorio y su documentación primaria a 2 de septiembre de 2026. La última versión estable era v0.75.1, y ese día se publicó v0.76.0-rc9 como prerelease. Mesh LLM es experimental y cambia deprisa. Separamos funciones documentadas, benchmarks publicados y lo que aún debes demostrar en tu hardware.

¿Qué es Mesh LLM?

Mesh LLM es un runtime Apache 2.0 para inferencia distribuida. Cada nodo ofrece la misma API. El sistema puede ejecutar el modelo localmente, enviar la petición completa a un peer que ya lo sirve o dividir un solo modelo entre peers mediante Skippy.

1. Local: la máquina actual ejecuta todo el modelo cuando cabe.
2. Routing: la petición completa va al host que tiene el modelo.
3. Split por etapas: varios equipos ejecutan rangos distintos de capas para la misma petición.

La app solo ve modelo, petición y respuesta. Placement, descargas, readiness, recuperación y seguridad siguen siendo trabajo de infraestructura.

¿Cómo divide Skippy un modelo entre varios PCs?

El flujo documentado de Skippy funciona como pipeline:

1. El coordinador resuelve el modelo o paquete.
2. El planner elige peers y rangos contiguos.
3. La etapa final carga primero.
4. Cada peer descarga metadatos comunes y solo sus capas.
5. La etapa 0 no se publica hasta que todas están listas.
6. El prompt entra por la etapa 0, las activaciones avanzan y el token vuelve al stream.

En un modelo de 48 capas, A podría ejecutar 0 a 15, B 16 a 31 y C 32 a 47 más la salida. No son tres modelos independientes. Es una única ruta con dos fronteras de red.

Los paquetes incluyen manifest, hashes, artefactos comunes y fragmentos GGUF. Para entornos serios, el proyecto recomienda revisiones inmutables y comandos que validan tamaño, SHA, archivos, manifest y respuestas reales de /v1. Un GGUF cualquiera no se convierte automáticamente en un split seguro.

¿Es solo balanceo de carga?

No. El balanceo envía peticiones completas a réplicas completas. Skippy envía una petición por varios equipos porque cada uno ejecuta capas diferentes.

Si cada modelo ya cabe en una máquina y las llamadas independientes de agentes forman cola, consulta nuestro análisis de NVIDIA PAIR y AMD ROCm. PAIR coloca cada petición completa en un nodo local elegible, un problema distinto al pipeline de capas de Mesh LLM.

Tres GPU de 24 GB no se convierten literalmente en una GPU de 72 GB. El software aprovecha la capacidad combinada, pero no fusiona ancho de banda, compute ni dominios de fallo.

¿Cuánta velocidad pierde la inferencia multinodo?

Depende. La página de benchmarks lo llama un control de realidad, no una promesa. Para GLM-4.7-Flash Q4 de 17 GB en un M4 Max y un Mac mini M4 por Wi-Fi publica:

El modelo ya cabía en una máquina. La prueba mide overhead sin aportar la ventaja principal de capacidad. Tampoco ofrece suficiente contexto para convertirla en ratio universal del Skippy actual. Sirve para descartar una expectativa: no hay speedup lineal.

El modelo del planner es más útil. Con una hipótesis de 10 ms por transferencia, dos etapas ya tienen un suelo de red de 20 ms/token, tres de 30 y cuatro de 40, antes del compute. El planner prefiere menos saltos físicos cuando la memoria lo permite. La colocación actual puntúa la latencia entre coordinador y nodo, pero la ruta productiva aún no recibe una matriz RTT peer-to-peer. Por ello no puede optimizar por completo qué etapas remotas están más cerca entre sí.

¿Qué controla el rendimiento real?

• Latencia: cada token repite las transferencias. Ethernet y Wi-Fi congestionado no son equivalentes.
• Etapa más lenta: una GPU débil, offload a CPU, temperatura o procesos de fondo frenan toda la cadena.
• Contexto y caché: KV y estado recurrente crecen con contexto y concurrencia.
• Formato de activación: cada frontera usa actualmente f32 raw little-endian. Los resultados históricos de f16 y q8 son evidencia de investigación, no formatos productivos seleccionables.
• Disponibilidad: si un portátil duerme o un peer reinicia, la ruta requerida se rompe.

La matriz de soporte registra artefactos, splits, el wire type fijo, caché y restricciones. Que una arquitectura exista en llama.cpp no certifica cualquier split.

¿Qué modelos y hardware admite?

La matriz incluye artefactos revisados de Qwen, Llama, DeepSeek, GLM, Gemma, Phi, Granite, Hunyuan, Mamba, RWKV, Falcon y algunos modelos multimodales. El soporte cambia según cuantización, proyector, caché, wire type y frontera. Parte siempre del artefacto recomendado y certifica paquete y runtime.

Los releases etiquetados ya incluyen macOS Metal, Linux CPU/CUDA/ROCm/Vulkan y Windows x86-64 CPU/CUDA/ROCm/Vulkan. Los assets de v0.76.0-rc9 también incluyen Linux ARM64 para CPU y CUDA. Windows nativo ya no exige compilar desde fuente, pero la guía actual aún documenta workarounds de instalación/runtime y ejecutables sin firma. Trátalo como piloto y verifica asset, backend, driver e instalación.

¿Qué privacidad ofrece?

Una malla privada usa token de invitación. Las publicadas anuncian su presencia mediante Nostr. El modo LAN con mDNS evita relays Nostr, relays iroh públicos y sondeos STUN públicos raw. El tráfico entre nodos, incluidos prompts, respuestas y activaciones, va cifrado de extremo a extremo con QUIC. En modo Nostr, iroh puede usar un relay gestionado que reenvía paquetes cifrados si no existe ruta directa.

La documentación de seguridad ofrece claves de owner, allowlists, tokens bootstrap firmados para mallas con requisitos y release attestation. Las mallas privadas y legacy sin restricciones conservan el token de invitación antiguo sin firma. La attestation solo prueba procedencia del build, no integridad del proceso, sistema operativo o hardware remoto. El arranque por defecto acepta incluso una attestation inválida salvo que la política exija builds certificados.

Para datos confidenciales usa máquinas controladas, política de admisión, listeners restringidos, tokens protegidos y logs revisados. El descubrimiento público no es confidential computing.

Mesh LLM frente a Exo, llama.cpp RPC y vLLM

Este artículo responde a capacidad y topología. Para la economía usa nuestro break-even entre modelos locales y APIs. Si quieres acceder a Apple Silicon distribuido por API en lugar de operar una malla privada, consulta nuestro análisis de privacidad, precios e ingresos de Darkbloom AI. Para elegir pesos, consulta la comparativa de LLM open-weight. Así una runtime interesante no elige por ti la arquitectura comercial.

¿Quién debería probar Mesh LLM?

Piloto de Mesh LLM en siete pasos

1. Define 30 a 100 prompts reales, contexto, salida, concurrencia y rúbrica.
2. Mide el mejor host: TTFT, tok/s, memoria, éxito, potencia y fallos.
3. Elige un artefacto revisado, revisión inmutable y licencia válida.
4. Empieza con dos nodos por cable. Añade etapas solo por memoria.
5. Prueba contexto y concurrencia reales, no un único prompt.
6. Rompe un peer a propósito y verifica detección, retirada, recuperación y errores.
7. Compara coste por tarea exitosa con ingeniería, energía, depreciación, redundancia y fallback API.

La decisión final debe fijar modelo máximo, mínimo número de etapas, presupuesto de fallo, frontera de confianza y fallback. Nuestro caso Twinsoft AI y la guía para elegir stack aplican el mismo criterio: medir antes de comprometer arquitectura.

Fuentes y método

Arquitectura, comandos, API, artefactos, soporte, seguridad y benchmarks proceden del repositorio Mesh LLM y de sus documentos primarios enlazados sobre Skippy, planner, familias, seguridad, releases y benchmarks. También usamos la documentación oficial de llama.cpp RPC. No reproducimos los benchmarks de hardware. Verificamos los hechos el 2 de septiembre de 2026 y omitimos cifras volátiles como estrellas o total de familias.