La ejecución de Large Language Models (LLMs) a gran escala presenta desafíos significativos en términos de costos operativos, dependencia de infraestructura centralizada y control sobre los datos y el ciclo de vida del modelo. La arquitectura predominante de LLMs como monolitos, servidos a través de APIs propietarias, impone una barrera de entrada y un costo recurrente que escala linealmente con el uso, limitando la innovación y la soberanía de datos para muchas organizaciones.

Mesh LLM aborda este problema fundamental de la computación distribuida: cómo orquestar recursos heterogéneos y geográficamente dispersos para ejecutar cargas de trabajo intensivas en cómputo que exceden la capacidad de una única máquina. La solución se basa en un modelo peer-to-peer, aprovechando recursos de cómputo existentes (GPUs, memoria) que de otro modo estarían infrautilizados, y ofreciendo una alternativa a la infraestructura centralizada de hyperscalers. Esto se alinea con la visión de sistemas distribuidos más resilientes y controlados por el usuario, donde la computación se acerca al borde y se desacopla de proveedores específicos.

Arquitectura del Sistema

Mesh LLM se construye sobre iroh, una plataforma para la construcción de aplicaciones peer-to-peer que proporciona conectividad segura y autenticada entre nodos. Cada nodo en el mesh arranca un endpoint de iroh, que actúa como su identidad (clave pública) y su interfaz de red. iroh facilita la conectividad directa entre pares a través de NAT traversal y hole-punching, con relays como fallback para escenarios complejos de red. La comunicación entre nodos se realiza sobre QUIC, utilizando negociación ALPN para multiplexar diferentes tipos de tráfico.

El protocolo QUIC se utiliza con tres ALPNs específicos: mesh-llm/1 para el mesh principal (gossip, routing, túneles HTTP, canales de plugins), mesh-llm-control/1 para el plano de control (sincronización de configuración, atestación de propiedad) y skippy-stage/2 para el transporte de activaciones de baja latencia en modelos particionados. Dentro de la conexión mesh-llm/1, los streams bidireccionales de QUIC se demultiplexan por un byte inicial que indica el tipo de stream (GOSSIP, TUNNEL_HTTP, ROUTE_REQUEST, etc.).

Mesh LLM implementa una capa de gossip sobre iroh para la detección de pares, el anuncio de capacidades (modelos alojados, GPUs disponibles, RTT) y la gestión del ciclo de vida de los pares. Las solicitudes de inferencia se pueden servir de tres maneras: ejecución local, enrutamiento a un par que ya tiene el modelo cargado, o partición del modelo ('Skippy') a través de múltiples máquinas. En el modo 'Skippy', el modelo se divide por rangos de capas, y las activaciones fluyen como un pipeline entre los nodos, permitiendo ejecutar modelos que exceden la memoria de cualquier máquina individual. La API expuesta es compatible con OpenAI, lo que permite a los clientes existentes interactuar con el mesh sin modificaciones.

Flujo de Solicitud de Inferencia en Mesh LLM

  1. 1 Cliente OpenAI Envía solicitud de inferencia a localhost:9337/v1
  2. 2 Nodo Mesh LLM (Local) Recibe la solicitud, consulta el estado del mesh y capacidades
  3. 3 Decisión de Enrutamiento Evalúa: ¿ejecutar localmente? ¿enrutar a un par? ¿dividir el modelo?
  4. 4 Opción 1: Ejecución Local Procesa la inferencia en la GPU local
  5. 5 Opción 2: Enrutamiento a Par Envía solicitud vía TUNNEL_HTTP (QUIC) a un par con el modelo cargado
  6. 6 Opción 3: Modelo Dividido (Skippy) Envía activaciones iniciales al primer nodo del pipeline (skippy-stage/2)
  7. 7 Pipeline Skippy Activaciones fluyen secuencialmente entre nodos del pipeline
  8. 8 Nodo Final/Local Recopila resultados y los envía de vuelta al cliente
CapaTecnologíaJustificación
networking iroh Provee conectividad peer-to-peer segura, autenticada y con NAT traversal usando QUIC. Abstrae la complejidad de la red.
networking QUIC Protocolo de transporte subyacente para todas las comunicaciones entre nodos, permitiendo multiplexación de streams y baja latencia. vs TCP/TLS (mayor latencia, head-of-line blocking), WebRTC (mayor complejidad, enfoque en tiempo real) Uso de ALPN para diferenciar tipos de tráfico (mesh-llm/1, mesh-llm-control/1, skippy-stage/2).
data-processing Gossip Protocol Mecanismo de descubrimiento de pares, anuncio de capacidades (modelos, GPUs, RTT) y gestión de estado del mesh. vs Centralized service discovery (mayor SPOF, latencia), DHT (mayor complejidad para este caso de uso)
compute GPU Unidad de procesamiento principal para la inferencia de LLMs, utilizada localmente o distribuida.

Fundamentos Teóricos

La arquitectura de Mesh LLM, al distribuir cargas de trabajo y recursos en una red peer-to-peer, se conecta con principios fundamentales de la computación distribuida y la tolerancia a fallos. El uso de un protocolo de gossip para la propagación de información de estado y capacidades entre nodos remite a trabajos clásicos sobre sistemas distribuidos a gran escala, donde la consistencia eventual y la resiliencia son prioritarias. Algoritmos de gossip, como los descritos en "Epidemic Algorithms for Replicated Database Maintenance" (Demers et al., 1987) o "Gossip-based membership management in large-scale distributed systems" (Van Renesse et al., 1998), son fundamentales para la auto-organización y descubrimiento de servicios en entornos descentralizados.

La partición de modelos y el enrutamiento de activaciones en un pipeline distribuido, como el modo 'Skippy', se relaciona con técnicas de paralelización de modelos y datos en el ámbito del Machine Learning distribuido. Conceptos como el paralelismo de tubería (pipeline parallelism) han sido explorados en la literatura académica para entrenar y servir modelos de gran escala que no caben en una sola GPU, como se discute en trabajos sobre sistemas como GPipe (Huang et al., 2019). La abstracción de la complejidad de red y la provisión de conectividad segura entre pares, habilitada por iroh, se alinea con la investigación en redes overlay y NAT traversal, un problema bien conocido en la construcción de sistemas P2P robustos y accesibles globalmente.