En pocas palabras: Mesh LLM es un proyecto open source que reparte la inferencia de un LLM entre varias máquinas en red P2P sobre iroh, sin nube ni servidor central. Expone un endpoint compatible con OpenAI en localhost:9337/v1, corre más de 40 modelos (500M a 235B parámetros) y pesa 18 MB.
Mesh LLM lleva la computación distribuida a los modelos de lenguaje: conecta varias máquinas en una red P2P sobre iroh para correr LLMs grandes sin depender de una sola GPU ni de APIs en la nube. Reparte la inferencia entre nodos y expone un endpoint compatible con OpenAI en tu propia red, en localhost:9337/v1.
Mesh LLM es un proyecto de código abierto que junta el hardware que ya tenés (tu notebook, la workstation del compañero, el servidor de la oficina) en una sola malla para servir modelos de lenguaje. Usa iroh, una librería P2P sobre QUIC, para armar las conexiones directas entre nodos sin servidor central. El binario pesa alrededor de 18 MB y habla el protocolo de OpenAI, así que tu código no cambia.
En 30 segundos
- Qué es: Mesh LLM reparte la inferencia de un modelo entre varias máquinas conectadas en red P2P sobre iroh, sin nube ni servidor central.
- Cuántos modelos: más de 40, desde 500M hasta 235B de parámetros (incluye Llama, Mistral y arquitecturas MoE).
- Cómo se integra: endpoint compatible con OpenAI en
localhost:9337/v1, así que reusás tu SDK actual sin tocar código. - Tres modos: ejecución local, ruteo a un peer que ya tiene el modelo cargado, o pipeline splitting por capas del modelo.
- Para quién: equipos chicos, oficinas y startups que golpean el techo de VRAM o que necesitan que los datos no salgan de su red.
¿Qué es Mesh LLM y para qué sirve?
Ponele que querés correr un modelo de 70B de parámetros y tu placa se queda corta de VRAM. Las opciones de siempre son dos: pagás una API por token y mandás tus datos a un tercero, o te comprás una GPU carísima que va a estar ociosa el 90% del día. Mesh LLM propone una tercera vía.
La idea es simple. En vez de que una máquina cargue todo el modelo, varias máquinas se reparten el trabajo. Una tiene 12 GB de VRAM, otra 16, otra corre en CPU. Sumadas, alcanzan para un modelo que ninguna podría cargar sola. Ese es el punto de Mesh LLM y la computación distribuida aplicada a inferencia: aprovechar el hardware que ya está prendido en tu red.
La diferencia con una API en la nube es de fondo. Con una API, tus prompts salen de tu red y viajan a un datacenter que no controlás. Con Mesh LLM, todo queda entre tus nodos. Para un estudio jurídico o una fintech que maneja datos sensibles, esa distinción no es un detalle. Complementá tu análisis con nuestra guía sobre proteger infraestructuras de IA distribuidas.
¿Cómo funciona la computación distribuida en iroh?
iroh es la parte que hace el trabajo sucio de la red. Es una librería de conectividad P2P construida sobre QUIC, el protocolo de transporte que también usa HTTP/3. Su gracia: conecta dos máquinas de forma directa aunque estén detrás de routers con NAT, sin que tengas que abrir puertos ni configurar un servidor intermedio.
¿Cómo logra eso? Con hole punching. Los dos nodos usan un servidor de coordinación liviano solo para descubrirse, después negocian una ruta directa y “perforan” el NAT para hablar entre ellos sin pasarela. Si el hole punching falla (pasa, sobre todo con NAT simétricos de operadores móviles), iroh cae a un relay como respaldo. La conexión no se corta, aunque ahí sí perdés algo de latencia.
Lo interesante es que esto saca del medio la parte más molesta de armar un cluster casero: la red. No necesitás VPN, ni IPs fijas, ni tocar el firewall de la oficina. Los nodos se encuentran por su identidad criptográfica y arman el túnel solos.
Tres métodos de distribución de requests en Mesh LLM
Mesh LLM no reparte todo de una sola manera. Según lo que tengas cargado y dónde, elige entre tres estrategias.
- Ejecución local: si tu propia máquina ya tiene el modelo cargado y le da la VRAM, el request se resuelve ahí mismo. Cero red, latencia mínima. Es el caso ideal cuando cabe.
- Peer routing: si el modelo no está en tu nodo pero sí en otro de la malla que lo tiene cargado, Mesh LLM rutea el pedido a ese peer. Evitás recargar pesos y aprovechás una máquina que ya está caliente.
- Pipeline splitting: acá está lo bueno. El modelo se parte por capas y cada nodo procesa un tramo. Los tensores intermedios viajan de una máquina a la siguiente por el túnel de iroh. Así corrés modelos que no entran completos en ningún nodo individual.
El pipeline splitting es la razón de existir del proyecto. Subís el modelo, se reparte por capas entre tus tres máquinas, cada una guarda su porción de pesos en VRAM, el primer nodo procesa hasta la capa 20, pasa el estado al segundo que sigue hasta la 40, y el tercero cierra y devuelve el token, todo por conexiones directas que se armaron solas sin que vos toques un solo puerto del router. Revisá nuestra cobertura sobre ChatGPT y modelos alternativos.
Más de 40 modelos: desde 500M hasta 235B de parámetros
El catálogo soportado arranca en modelos chicos de 500M, ideales para tareas de clasificación o para probar el setup, y llega hasta arquitecturas de 235B parámetros del tipo Mixture of Experts (MoE). En el medio están los sospechosos de siempre: familias Llama, Mistral y compañía.
El rango importa por una razón práctica. Un modelo de 7B te corre en una notebook decente sin distribuir nada. Uno de 70B ya te pide sumar máquinas. Y un MoE de 235B es, directamente, territorio de pipeline splitting o nube. Tener los tres extremos bajo el mismo endpoint te deja escalar sin cambiar de herramienta según crece la necesidad.
Eso sí: los MoE grandes reparten mejor que los modelos densos, porque no todos los expertos se activan en cada token. Habría que ver caso por caso cuánta VRAM real necesitás según cuántos expertos mantengas en memoria.
¿Para quién sirve? Equipos chicos, oficinas y startups
Mesh LLM no es para todo el mundo. Apunta a un perfil concreto.
- Power users con techo de VRAM: el que ya corre modelos en local con Ollama o llama.cpp y choca con el límite de su placa. Sumar una segunda máquina sale más barato que cambiar la GPU.
- Equipos tech chicos: tres o cuatro personas con sus workstations. En vez de una GPU compartida por SSH, arman una malla y usan el hardware ocioso de todos.
- Startups legales o fintech: necesitan que los datos del cliente no toquen un servidor de terceros. Con Mesh LLM la inferencia queda dentro de la red y controlan qué versión del modelo corre.
El común denominador es el control. Vos decidís qué modelo, qué versión y dónde vive el dato. Con una API cerrada, el proveedor puede cambiar el modelo abajo tuyo un martes cualquiera y tu output cambia sin aviso.
Comparativa: Mesh LLM vs API en la nube vs LLM local tradicional
| Criterio | Mesh LLM | API en la nube | LLM local tradicional |
|---|---|---|---|
| Costo | Hardware propio, cero por token | Pago por token, escala con el uso | Hardware propio, cero por token |
| Privacidad de datos | Alta (todo en tu red) | Baja (datos salen a un tercero) | Alta (una sola máquina) |
| Modelos grandes (70B+) | Sí, vía pipeline splitting | Sí | Limitado por la VRAM de un equipo |
| Latencia | Media (depende de la red entre nodos) | Baja a media | Baja (sin salto de red) |
| Setup de red | Automático (iroh + hole punching) | Ninguno | Ninguno |
| Requisitos técnicos | Medios (varios nodos coordinados) | Bajos (solo una API key) | Bajos (un binario) |

La lectura rápida: si tenés un solo equipo potente, el LLM local tradicional te alcanza y es más simple. Si necesitás el modelo más grande sin comprar más hardware y sin mandar datos afuera, ahí Mesh LLM gana. Y si no querés administrar nada, la API en la nube zafa, pagando el precio de la privacidad. Esto se conecta con lo que analizamos en cómo razonan los modelos modernos.
Primeros pasos: instalación, configuración y despliegue
El binario ronda los 18 MB, así que la instalación es liviana. Una vez levantado, Mesh LLM expone un endpoint compatible con OpenAI en localhost:9337/v1. Eso significa que cualquier cliente que ya use el SDK de OpenAI (Python, JavaScript, lo que sea) apunta a esa URL y funciona sin reescribir la lógica.
Para un setup híbrido, podés mezclar nodos privados con uno público. Los nodos internos guardan los datos sensibles y el nodo público, con IP alcanzable, sirve de punto de entrada o de relay estable. Si necesitás ese nodo con dirección fija corriendo 24/7, un VPS en donweb.com te da la base para el nodo público mientras el resto de la malla queda en tu oficina.
La consideración clave es la red entre nodos. El pipeline splitting manda tensores intermedios de máquina en máquina, y si esos saltos van por internet en vez de una LAN, la latencia sube. Para producción seria, conviene que los nodos que comparten un pipeline estén en la misma red física o con buen ancho de banda entre ellos.
Qué está confirmado y qué no
Como todo proyecto joven de código abierto, conviene separar lo que el repo documenta de lo que todavía está verde.
- Confirmado: endpoint compatible con OpenAI en el puerto 9337, footprint de ~18 MB, transporte P2P sobre iroh con QUIC y hole punching, más de 40 modelos soportados y los tres modos de distribución.
- Confirmado: soporte de rango amplio, de 500M a 235B parámetros, incluyendo arquitecturas MoE.
- Pendiente de ver en producción: el rendimiento real del pipeline splitting cuando los nodos no comparten LAN. La latencia entre saltos es el gran signo de pregunta.
- Pendiente: qué tan estable es el hole punching en redes de operadores argentinos con NAT simétrico, donde iroh puede terminar cayendo al relay.
Errores comunes al armar una malla con Mesh LLM
- Repartir un modelo chico entre muchos nodos: si el modelo entra completo en una máquina, distribuirlo solo agrega latencia de red. El pipeline splitting es para lo que no entra, no para todo.
- Mezclar nodos por WiFi débil en el mismo pipeline: los tensores intermedios necesitan buen ancho de banda entre saltos. Un nodo colgado de un WiFi flojo hace de cuello de botella y arrastra a toda la cadena.
- Asumir que el hole punching siempre conecta directo: con ciertos NAT (típico en 4G/5G) iroh cae al relay. Si esperabas latencia de conexión directa y estás pasando por un relay, los números no van a cerrar. Verificá qué tipo de ruta armó cada par.
- Exponer el endpoint 9337 a internet sin control: es un endpoint de inferencia abierto. Si lo publicás sin autenticación ni firewall, cualquiera con la URL consume tu hardware.
Preguntas Frecuentes
¿Qué es Mesh LLM y cómo funciona?
Mesh LLM es un sistema de código abierto que reparte la inferencia de un modelo de lenguaje entre varias máquinas conectadas en una red P2P sobre iroh. Cada nodo aporta su VRAM o CPU, y el modelo se ejecuta de forma local, ruteada a un peer o partida por capas, según el caso.
¿Puedo ejecutar modelos grandes sin una GPU potente?
Sí, esa es la idea central del pipeline splitting. Mesh LLM parte el modelo por capas y reparte los pesos entre varios equipos, así que sumando la VRAM de tres máquinas modestas podés correr un modelo que ninguna cargaría sola. El límite deja de ser una sola placa. En la estrategia de Google en IA distribuida profundizamos sobre esto.
¿Cuál es la diferencia entre Mesh LLM y las APIs en la nube?
Con una API en la nube pagás por token y tus datos salen a un servidor de terceros. Con Mesh LLM la inferencia queda dentro de tu red, no pagás por uso y controlás qué versión del modelo corre. A cambio, administrás el hardware y la coordinación entre nodos.
¿Cómo se integra Mesh LLM con mi código actual?
Mesh LLM expone un endpoint compatible con OpenAI en localhost:9337/v1. Cualquier cliente que use el SDK de OpenAI apunta a esa URL y funciona sin cambios de lógica. No tenés que aprender una API nueva ni reescribir tus llamadas.
¿Necesito configurar la red o abrir puertos?
No en la mayoría de los casos. iroh arma las conexiones directas entre nodos con hole punching sobre QUIC, sin VPN ni puertos abiertos. Si el hole punching falla con un NAT difícil, cae a un relay como respaldo y la conexión se mantiene.
Conclusión
Mesh LLM ataca un problema concreto: correr modelos grandes sin GPU carísima y sin mandar datos a la nube. Lo hace apoyándose en iroh para resolver la parte más molesta, la red entre nodos, y en un endpoint compatible con OpenAI para no romper tu código. Para equipos chicos que golpean el techo de VRAM o que no pueden dejar salir sus datos, es una opción que hace un año no existía con esta simpleza.
El signo de pregunta sigue siendo el rendimiento del pipeline splitting fuera de una LAN. Si vas a probarlo, empezá con dos nodos en la misma red, medí la latencia real de tu caso y recién ahí decidí si escalás. Tomá los números de VRAM con pinzas hasta verlos en tu hardware.
Fuentes
- iroh.computer – Anuncio y explicación técnica de Mesh LLM sobre iroh
- GitHub Mesh-LLM/mesh-llm – Repositorio oficial, instalación y modelos soportados
- Hacker News – Discusión de la comunidad sobre Mesh LLM
- Starlog – Análisis de ingeniería sobre Mesh LLM
- Ecosistema Startup – Equipos de LLMs como sistemas distribuidos
