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 18 de julio de 2026. 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.

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.

¿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: f16 es el default conservador. q8 solo se acepta por familia y split cuando supera exactitud.
• Disponibilidad: si un portátil duerme o un peer reinicia, la ruta requerida se rompe.

La matriz de soporte registra artefactos, splits, wire types, 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.

El README documenta bundles para macOS y Linux con Metal, CPU, CUDA, ROCm y Vulkan. Windows puede compilarse desde fuente, pero la publicación de bundles de Windows figura desactivada. Comprueba los assets de la versión elegida.

¿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. Descubrir un peer no implica confiar en él.

La documentación de seguridad ofrece claves de owner, allowlists, tokens firmados y requisitos de release attestation. También reconoce su límite: una firma prueba procedencia del build, no que el proceso, sistema operativo o hardware remoto estén intactos.

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. 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. No reproducimos los benchmarks de hardware. Verificamos los hechos el 18 de julio de 2026 y omitimos cifras volátiles como estrellas, número de releases o total de familias.