Mesh LLM: computación de IA distribuida basada en iroh

• Agrupa GPU y memoria repartidas en varias máquinas como un único recurso de cómputo, y ofrece ejecución local, reenvío a pares y ejecución dividida mediante una sola API compatible con OpenAI
• Las solicitudes se procesan en la GPU local o en un par que ya tenga cargado el modelo; los modelos que no caben en una sola máquina pueden ejecutarse divididos en etapas de pipeline entre varios nodos
• El catálogo basado en plugins incluye más de 40 modelos, desde modelos de 500 millones de parámetros para laptops hasta modelos MoE de 235B, y el cliente solo llama a localhost:9337/v1 sin importar el procesamiento por lotes interno
• Cada nodo ejecuta un endpoint iroh que usa una clave pública como ID y como única superficie de red, y establece conexiones QUIC autenticadas sin servidor central, mediante atravesamiento de NAT, hole punching y rutas alternativas por relay
• Con software de unos 18 MB se puede armar una mesh pública o un despliegue privado; a futuro planean reducir la dependencia de servidores cerrados mediante apps móviles con soporte para iroh Swift SDK y ACP

---

Aprovechar el hardware existente en lugar de datacenters externos

• La forma habitual de usar LLM depende de datacenters de GPU de proveedores externos y de API basadas en uso, por lo que el costo aumenta a medida que crece el uso
• Al enviar prompts a un servicio externo, al usuario le resulta difícil controlar directamente estos aspectos
  • Cuándo se actualiza el modelo
  • A dónde se transfieren los datos
  • La memoria y el hardware base que usa el modelo
  • Cambios en precios y políticas de tratamiento de datos personales
• Las empresas y servicios que ya tienen GPU en oficinas, almacenes o debajo de escritorios necesitan una forma de usar varias máquinas como si fueran un único recurso de cómputo
• Mesh LLM está diseñado para agrupar las GPU y la memoria propias a través de la cantidad de máquinas que se desee, ejecutar modelos más grandes y compartir recursos de cómputo dentro del equipo de forma privada o públicamente con terceros

Tres rutas para procesar solicitudes

• Cuando un cliente estándar de OpenAI llama a http://localhost:9337/v1, la mesh decide dónde se ejecuta realmente la solicitud
• Las solicitudes se procesan por una de estas tres rutas
  • Ejecutar el modelo en la GPU local de la máquina actual
  • Reenviar la solicitud a un par que ya tenga cargado el modelo necesario
  • Dividir en modo pipeline un modelo que no cabe en una sola máquina a través de varias máquinas
• El usuario puede empezar con un solo nodo y agregar más cuando lo necesite; el cliente de OpenAI no necesita conocer el enrutamiento interno ni el modo de ejecución dividida

Estructura de plugins y catálogo de modelos

• Los plugins declaran en un manifiesto las capacidades que ofrecen, y el runtime los inicia y enruta las llamadas
• Las capacidades de cada plugin se exponen mediante MCP, HTTP, inferencia y eventos de la mesh
• El catálogo predeterminado incluye más de 40 modelos
  • Modelos de unos 500 millones de parámetros que pueden ejecutarse en una laptop
  • Modelos Mixture-of-Experts de hasta 235B

Ejecución dividida Skippy

• El modo dividido para modelos grandes se llama internamente Skippy
• El rango de capas del modelo se divide por etapas y se asigna a cada nodo
  • Un nodo se encarga de las capas 0 a 15
  • El siguiente nodo se encarga de las capas 16 a 31
  • Las capas restantes se distribuyen del mismo modo hasta el final del pipeline
• Como los valores de activación (activation) generados en una etapa se pasan a la siguiente, también pueden ejecutarse modelos que no caben en máquinas individuales combinando varias máquinas de gama media
• El proceso de división no queda expuesto al cliente de OpenAI; el cliente sigue llamando únicamente al endpoint local

Red P2P basada en iroh

• Tanto los nodos que ofrecen modelos como los nodos que solo envían solicitudes inician un endpoint iroh
• El endpoint cumple tres funciones
  • ID del nodo
  • Clave pública
  • Única superficie de red que el nodo expone al exterior
• Sin un servidor central, iroh se encarga del hole punching, el atravesamiento de NAT y las rutas alternativas por relay para establecer conexiones QUIC directas y autenticadas entre nodos ubicados en distintos lugares
• Para nodos que no pueden conectarse directamente, operan 2 relays iroh en regiones distintas y ofrecen una ruta alternativa cercana
• Al poder especificar máquinas mediante claves públicas y usar QUIC autenticado con atravesamiento de NAT, tanto reenviar una solicitud a un par como enviar valores de activación a la siguiente etapa del pipeline se procesan con el mismo elemento básico de comunicación, cambiando solo el ID del endpoint

Separación de protocolos con QUIC ALPN

• Todo el protocolo usa la negociación ALPN de QUIC y se divide en tres tipos según el uso
  • mesh-llm/1: mesh principal, que incluye gossip, enrutamiento, túnel HTTP y canales de plugins
  • mesh-llm-control/1: plano de control del propietario, encargado de la sincronización de configuración y la prueba de propiedad
  • skippy-stage/2: transferencia de valores de activación sensible a la latencia en modelos divididos
• En las conexiones mesh-llm/1, todas las operaciones se transmiten por streams QUIC bidireccionales, y el primer byte del stream identifica el tipo
  • 0x01 GOSSIP: anuncios de pares que incluyen modelo, GPU, RTT y capacidades
  • 0x04 TUNNEL_HTTP: solicitudes de inferencia proxificadas a un par
  • 0x05 ROUTE_REQUEST: consulta de un modelo alojado por un par
  • 0x06 PEER_DOWN: aviso de un par desconectado
  • 0x07 PEER_LEAVING: aviso de cierre normal
  • 0x08 PLUGIN_CHANNEL: RPC de plugins
  • 0x0e DIRECT_PATH_REQUEST: intercambio de direcciones directas para atravesamiento de NAT
• En una sola conexión se procesan gossip, inferencia, consultas de ruta y eventos del ciclo de vida de pares, y cada stream se demultiplexa mediante un byte inicial

Separación entre transporte seguro y control de la mesh

• iroh proporciona la capa de transporte segura entre máquinas
• Encima de ella, Mesh LLM construye su propia capa de gossip para controlar directamente estas políticas
  • A quién se le permite participar en la mesh
  • Versiones compatibles
  • Pares confiables

Instalación y soporte futuro

• Al instalar software liviano de unos 18 MB, se puede participar en una mesh pública o configurar un despliegue privado
• Para clientes estándar de OpenAI, se expone como el endpoint localhost:9337/v1
• Planean desarrollar apps móviles con iroh Swift SDK y preparan soporte para ACP, un nuevo estándar de agentes, para que otros clientes también puedan participar en la mesh
• El proyecto apunta a aumentar el uso de P2P y reducir la dependencia de servidores cerrados y sus ataduras
• El proyecto puede consultarse en el código fuente y el sitio web de Mesh LLM

Biblioteca de networking iroh

• iroh es una biblioteca de networking open source que ofrece conectividad entre dispositivos, y permite combinar protocolos listos para usar o construir protocolos personalizados sobre una abstracción simple de comunicación
• Ya se ejecuta en cientos de miles de dispositivos en entornos de producción
• Ofrece documentación, código fuente y un canal de Discord

[GN⁺]

Opiniones en Hacker News

• Al ver en la primera imagen los equipos con GPU, laptops, servidores, nodos en la nube, etc., me di cuenta de lo pocos recursos de cómputo que tengo. No tengo una laptop con 24 GB de VRAM ni una workstation de 96 GB, y aunque juntara todas las PC gamer de mis amigos para ejecutar un LLM, creo que no llegaría al total de VRAM de la foto.
  El artículo también presentaba una red mesh pública, pero no pude encontrar información detallada.

  • La dirección del mesh público es https://public.meshllm.cloud/.

• Llama la atención la falta de información de rendimiento. Esperaba que fuera mucho más lento que cualquier otra forma de ejecutar modelos grandes, incluyendo streaming desde la RAM del sistema o desde disco. Las redes de consumo, incluso Ethernet de 10 Gbps, son muy lentas frente a la RAM local o el disco, así que me preguntaba si el modelo particionado alcanzaría 1 token por segundo o menos.
  Al ver la lista de modelos, Qwen 235B A22B aparecía como “MoE 235B/22B verificado a 16 tok/s en 2 nodos”. No publicaron las especificaciones de los nodos ni la conexión de red, pero es una velocidad bastante decente; aunque queda un poco por debajo de un nivel cómodo para conversación interactiva, se acerca bastante.

  • No necesariamente es más lento; de hecho, probablemente haya muchas configuraciones en las que no lo sea. Si descargás pesos a RAM o NVMe, en cada token y para cada capa hay que mover pesos enormes desde almacenamiento lento hacia la GPU, por lo que el ancho de banda de DRAM o la velocidad de lectura del disco se vuelven el cuello de botella.
    En una configuración distribuida, los pesos permanecen en la VRAM de cada equipo, aprovechando el ancho de banda mucho más rápido de la memoria de GPU. Lo que se pasa entre dispositivos son las salidas de las capas, de tamaño de kilobytes, no pesos de gigabytes, así que el throughput de la red no es el cuello de botella.
    La limitación real es la latencia de red. Si dividís el modelo entre 4 dispositivos, en cada token se incurre tres veces en latencia de red; si la latencia es de 1 ms, se agregan 3 ms por token. Incluso suponiendo tiempo de cómputo cero, la velocidad máxima teórica sin decodificación especulativa es de unos 30 tok/s.
    En Internet, la latencia probablemente sea demasiado alta para que resulte práctico, pero en redes locales o empresariales con decodificación especulativa es totalmente viable. En el prefill o procesamiento del prompt, la latencia no se acumula, así que una configuración distribuida casi con seguridad es más rápida.
  • En mi home lab hice pruebas simulando 5 ms de latencia y jitter entre equipos. La ejecución particionada funciona bastante bien con latencias WAN de nivel metropolitano, pero no es muy rápida en una WAN global.
    El objetivo es agrupar varios equipos sin RDMA dedicado ni fabric NVLink para servir modelos grandes con hardware propio y compartirlos con otras personas. Actualmente estoy trabajando en ejecutar GLM 5.2 a unos 10 tok/s con la misma configuración particionada.
  • El rendimiento se puede estimar de forma relativamente sencilla. En decodificación autorregresiva, por cada token hay que transmitir por la red aproximadamente 2 × hidden_size × num_shards bytes; en prefill, ese valor se divide por el tamaño del chunk.
  • Es similar a la velocidad que obtengo al ejecutar Qwen3.6-35B-A3B en una Framework 13 con AMD Ryzen AI 9 HX 370. Si se consigue la misma velocidad con modelos mucho más grandes, es impresionante.

• Me interesa más la inferencia distribuida de modelos de lenguaje pequeños hechos para un propósito específico que los LLM para programación. Usados en procesamiento de imágenes, radio definida por software (SDR), observación meteorológica local, etc., podrían ejecutarse en hardware común y aun así producir resultados confiables.

  • En lugar de un modelo con X expertos activos, parece adecuada una configuración con 10 modelos distintos, pequeños y densos, entrenados con información específica, montados en 10 servidores y conectados mediante un router.

• Soy colaborador de Mesh LLM y creé el motor skippy, que permite dividir modelos grandes entre varios nodos. Si tienen preguntas, las respondo.

  • Me alegra ver que vuelven a aparecer tecnologías relacionadas con IPFS. Tengo dos dudas.
    Primero, al distribuir el cómputo de esta forma, todos los participantes del grafo de cómputo conocen la secuencia que se está procesando; ¿cómo manejan la privacidad? Segundo, ¿hay algún mecanismo de protección para evitar que un participante malicioso contamine las activaciones del modelo?
  • Me intriga cuál es el incentivo para participar en el mesh público. Si aporto 1/8 de la VRAM necesaria para ejecutar un modelo determinado, ¿hay alguna garantía de equidad, por ejemplo recibir al menos 1/16 del uso de inferencia?
  • ¿Habría beneficios al integrarlo con el proyecto Colibri publicado hace unos días?
  • Nunca miré a fondo una implementación de caché KV, pero me pregunto si en la práctica cada capa mantiene una caché independiente.
    Si es así, la división parece limpia tanto en cómputo como en tamaño de datos, y lo único que se ralentizaría sería el tiempo que cada capa espera su turno. Con pipeline, incluso se podrían ejecutar varias consultas al mismo tiempo.
    ¿Existe algún caso de implementación de best-of-N usando un pipeline de N etapas que introduzca las consultas desfasadas una etapa?
  • Manejo un laboratorio con muchos procesadores EPYC y modelos distintos, y me impresiona que esto permita unirlos de esta manera.

• Buscando LLM con un enfoque similar de cómputo distribuido, encontré AI Horde, algunos intentos pequeños del lado de Aphrodite y el entrenamiento distribuido de Nous Research.
  De esos, AI Horde parece ser el más grande. Su API usa el formato de completado de texto de KoboldCPP, no completado de chat. Expone más variables de control, lo que da mejores resultados en roleplay, así que los miembros activos de la comunidad parecen preferir fuertemente este enfoque. Para otros usos, la mayoría probablemente requeriría llamadas a herramientas, así que no estoy seguro de para qué serviría fuera del roleplay.
  Esta semana empecé a mejorar el puente de OpenAI para que soporte plantillas de chat y parsing de respuestas. Si logro publicarlo oficialmente, podría usarse para programación incluso si hay que usar modelos de roleplay.
  También tiene mecanismos antiabuso más sólidos. Para evitar ataques coordinados, un trabajador debe acumular una semana de uptime antes de ser considerado confiable, y los usuarios pueden elegir solo trabajadores confiables. Al operar un trabajador se obtienen kudos, que se pueden usar para generaciones de más de 512 tokens, mientras que las solicitudes gratuitas se mandan al final de la cola.

• Me preguntaba qué podría hacer una botnet polimórfica que ejecute uno o más LLM distribuidos. La idea sería usar todos los hosts de la botnet como recursos de cómputo de un clúster para correr el LLM, y hacer que evolucionen tanto los métodos de propagación como los payloads de cada clúster de botnet.
  Las variantes malas serían detectadas y eliminadas, y los métodos de propagación ineficaces no se difundirían, pero las mejores versiones sobrevivirían y seguirían creciendo. Es bastante parecido a la arquitectura presentada aquí, y QUIC funciona de forma muy dinámica, por lo que podría ser más difícil de detectar de lo que uno pensaría.

• El proyecto https://query.mt/ lleva un tiempo usando un mesh basado en iroh. Si querés usar modelos mesh también en teléfonos, vale la pena probarlo.

• Estuve un buen rato peleándome para ejecutar mesh-llm, pero ninguna de las compilaciones instalables de llama.cpp funcionaba con mi GPU vieja. Parecía que se podía proxyear un servicio externo de llama.cpp, pero tampoco logré configurar eso.
  Es un proyecto muy interesante, pero todavía tiene bastantes partes sin pulir.

  • Si mandás un reporte de bug, me gustaría ayudarte a resolverlo para que funcione.

• Pensé que este enfoque sería posible y le pregunté a ChatGPT hace aproximadamente un año, pero me respondió que era imposible por la latencia demasiado alta. En ese entonces llevaba casi un año estudiando libp2p y buscando un proyecto donde usarlo.