Mesh LLM - computação de IA distribuída baseada em iroh

• Agrupa GPUs e memória espalhadas por várias máquinas em um único recurso computacional, oferecendo execução local, encaminhamento para pares e execução particionada por meio de uma única API compatível com OpenAI
• As requisições são processadas na GPU local ou em um par que já carregou o modelo, e modelos grandes demais para caber em uma única máquina podem ser executados divididos em estágios de pipeline entre vários nós
• O catálogo baseado em plugins inclui mais de 40 modelos, de modelos de 500 milhões de parâmetros para notebooks até modelos MoE de 235B, e o cliente só chama localhost:9337/v1, independentemente do particionamento interno
• Cada nó executa um endpoint iroh que usa a chave pública como ID e como a única superfície de rede exposta, estabelecendo conexões QUIC autenticadas sem servidor central por meio de travessia de NAT, hole punching e caminhos alternativos via relay
• Com cerca de 18 MB de software, é possível montar uma malha pública ou uma implantação privada, e no futuro o projeto planeja reduzir a dependência de servidores fechados com apps móveis compatíveis com iroh Swift SDK e ACP

---

Uso do hardware existente em vez de datacenters externos

• A forma mais comum de usar LLMs depende de datacenters de GPU de provedores externos e de APIs cobradas por uso, então o custo cresce conforme o uso aumenta
• Ao enviar prompts para serviços externos, o usuário tem dificuldade para controlar diretamente os seguintes fatores
  • quando o modelo é atualizado
  • para onde os dados são enviados
  • que memória e hardware de base o modelo utiliza
  • mudanças de preço e de políticas de privacidade
• Empresas e serviços que já têm GPUs no escritório, no depósito ou debaixo da mesa precisam de uma forma de usar várias máquinas como um único recurso computacional
• O Mesh LLM foi projetado para agrupar as GPUs e a memória já disponíveis em quantas máquinas você quiser, executar modelos maiores e compartilhar recursos computacionais de forma privada dentro da equipe ou publicamente com terceiros

Três caminhos para processar uma requisição

• Quando um cliente OpenAI padrão chama http://localhost:9337/v1, a malha decide onde a requisição será realmente executada
• A requisição é tratada por um destes três caminhos
  • execução do modelo na GPU local da máquina atual
  • encaminhamento da requisição para um par que já carregou o modelo necessário
  • particionamento do modelo em modo pipeline entre várias máquinas quando ele não cabe em uma só
• O usuário pode começar com um único nó e adicionar mais quando precisar, e o cliente OpenAI não precisa saber nada sobre o roteamento interno ou sobre como a execução particionada funciona

Estrutura de plugins e catálogo de modelos

• Os plugins declaram, em um manifesto, quais recursos oferecem, e o runtime os inicia e roteia as chamadas
• As funções de cada plugin são expostas por meio de MCP, HTTP, inferência e eventos da malha
• O catálogo padrão inclui mais de 40 modelos
  • modelos de cerca de 500 milhões de parâmetros que podem rodar em notebooks
  • modelos Mixture-of-Experts de até 235B

Execução particionada com Skippy

• O modo particionado para modelos grandes é chamado internamente de Skippy
• Os intervalos de camadas do modelo são divididos em estágios e distribuídos entre os nós
  • um nó cuida das camadas 0~15
  • o próximo nó cuida das camadas 16~31
  • as camadas seguintes são distribuídas da mesma forma até o fim do pipeline
• As ativações geradas em uma etapa são enviadas para a próxima, o que permite executar, com várias máquinas intermediárias combinadas, modelos que não caberiam em nenhuma máquina individualmente
• O processo de particionamento não aparece para o cliente OpenAI, que continua chamando apenas o endpoint local

Rede P2P baseada em iroh

• Tanto os nós que oferecem modelos quanto os nós que apenas enviam requisições iniciam um endpoint iroh
• O endpoint desempenha três papéis
  • ID do nó
  • chave pública
  • única superfície de rede exposta externamente pelo nó
• O iroh lida com hole punching, travessia de NAT e caminhos alternativos via relay sem servidor central, estabelecendo conexões QUIC diretas e autenticadas entre nós em locais diferentes
• Para nós que não conseguem se conectar diretamente, são operados dois relays iroh em regiões diferentes para fornecer o caminho alternativo mais próximo
• Como é possível indicar a máquina pela chave pública e usar QUIC autenticado com travessia de NAT, tanto o encaminhamento de requisições para pares quanto o envio de ativações para a próxima etapa do pipeline são tratados pelo mesmo elemento básico de comunicação, mudando apenas o ID do endpoint

Separação de protocolos com QUIC ALPN

• O protocolo completo usa negociação ALPN do QUIC e é dividido em três partes conforme a finalidade
  • mesh-llm/1: mensagens básicas, incluindo gossip, roteamento, túnel HTTP e canais de plugin
  • mesh-llm-control/1: plano de controle do proprietário, responsável por sincronização de configuração e prova de propriedade
  • skippy-stage/2: transmissão de ativações sensível à latência em modelos particionados
• Em conexões mesh-llm/1, todas as operações são transportadas por streams QUIC bidirecionais, e o primeiro byte do stream identifica o tipo
  • 0x01 GOSSIP: anúncios de pares com modelo, GPU, RTT e recursos
  • 0x04 TUNNEL_HTTP: requisições de inferência encaminhadas por proxy para um par
  • 0x05 ROUTE_REQUEST: consulta de modelos hospedados por um par
  • 0x06 PEER_DOWN: aviso de par com conexão interrompida
  • 0x07 PEER_LEAVING: aviso de encerramento normal
  • 0x08 PLUGIN_CHANNEL: RPC de plugin
  • 0x0e DIRECT_PATH_REQUEST: compartilhamento de endereços diretos para travessia de NAT
• Uma única conexão trata gossip, inferência, consulta de rotas e eventos de ciclo de vida dos pares, e usa o byte inicial para desmultiplexar cada stream

Separação entre transporte seguro e controle da malha

• O iroh fornece a camada de transporte seguro entre as máquinas
• Sobre ela, o Mesh LLM constrói sua própria camada de gossip para controlar diretamente as seguintes políticas
  • quem pode participar da malha
  • quais versões são compatíveis
  • em quais pares confiar

Instalação e suporte futuro

• É possível instalar um software leve de cerca de 18 MB para participar de uma malha pública ou montar uma implantação privada
• Para clientes OpenAI padrão, ele é exposto pelo endpoint localhost:9337/v1
• Há planos de desenvolver apps móveis com o iroh Swift SDK e de adicionar suporte ao novo padrão de agentes ACP para que outros clientes também possam participar da malha
• O projeto busca ampliar o uso de P2P e reduzir a dependência de servidores fechados e de lock-in
• O projeto pode ser visto no código-fonte e no site do Mesh LLM

Biblioteca de rede iroh

• O iroh é uma biblioteca de rede open source que fornece conectividade entre dispositivos, permitindo combinar protocolos prontos ou construir protocolos personalizados sobre abstrações simples de comunicação
• Já roda em centenas de milhares de dispositivos em produção
• Disponibiliza documentação, código-fonte e canal no Discord

[GN⁺]

Opiniões do Hacker News

• Ao ver o equipamento com GPU, notebooks, servidores e nós na nuvem da primeira imagem, percebi como meus recursos de computação são limitados. Não tenho notebook com 24 GB de VRAM nem workstation com 96 GB, e mesmo reunindo todos os PCs gamer dos meus amigos para rodar um LLM ainda acho que não chegaria à VRAM total da foto
  O texto também apresentou uma rede mesh pública, mas não consegui encontrar muitos detalhes

  • O endereço da mesh pública é https://public.meshllm.cloud/

• Chama atenção a falta de informações de desempenho. Eu imaginava que seria muito mais lento do que qualquer outra forma de rodar modelos grandes, inclusive com RAM do sistema ou streaming em disco. Mesmo uma rede doméstica de consumidor é muito lenta em comparação com RAM local ou disco, nem que seja 10Gbps Ethernet, então fiquei curioso se um modelo particionado chegaria a 1 token/s ou menos
  Na lista de modelos, o Qwen 235B A22B aparecia como “MoE 235B/22B validado a 16 tok/s em 2 nós”. Eles não divulgaram as especificações dos nós nem a conexão de rede, mas ainda assim é uma velocidade bem razoável, talvez um pouco abaixo do nível confortável para uso conversacional, porém bastante próxima

  • Não é necessariamente mais lento; em muitas configurações pode até não ser. Se você faz offload dos pesos para RAM ou NVMe, a cada token e em cada camada é preciso mover pesos enormes do armazenamento lento para a GPU, então a largura de banda da DRAM ou a leitura em disco vira gargalo
    Em uma configuração distribuída, os pesos ficam na VRAM de cada máquina e aproveitam a largura de banda muito maior da memória da GPU. O que passa entre os dispositivos são saídas de camada em escala de quilobytes, não pesos em escala de gigabytes, então a vazão da rede não vira o gargalo
    A limitação real é a latência da rede. Se o modelo for dividido entre 4 dispositivos, há três atrasos de rede por token; se a latência for 1 ms, isso adiciona 3 ms por token. Mesmo assumindo custo computacional zero, sem decodificação especulativa o teto teórico fica em cerca de 30 tok/s
    Na internet, a latência provavelmente é alta demais para ser prática, mas em redes locais ou corporativas, com decodificação especulativa, isso parece bem viável. No prefill ou no processamento do prompt, a latência não se acumula, então a configuração distribuída quase certamente será mais rápida
  • Simulei 5 ms de latência e jitter entre as máquinas no meu home lab. A execução particionada funciona bem com latência de WAN em escala metropolitana, mas não é tão rápida em WAN global
    O objetivo é juntar várias máquinas sem fabric dedicado como RDMA ou NVLink para servir modelos grandes com hardware próprio e compartilhá-los com outras pessoas. No momento estou trabalhando para rodar GLM 5.2 a cerca de 10 tok/s nessa mesma configuração particionada
  • O desempenho dá para estimar de forma relativamente simples. Na decodificação autorregressiva, é preciso transmitir pela rede aproximadamente 2 × hidden_size × num_shards bytes por token; no prefill, basta dividir esse valor pelo tamanho do chunk
  • É parecido com a velocidade que obtenho ao rodar Qwen3.6-35B-A3B em um Framework 13 com AMD Ryzen AI 9 HX 370. Se a mesma velocidade sair com um modelo muito maior, isso é impressionante

• Tenho mais interesse em inferência distribuída de modelos de linguagem pequenos feitos para um propósito específico do que em LLMs para programação. Isso poderia ser útil para processamento de imagem, rádio definido por software (SDR), observação meteorológica local e coisas do tipo, com execução em hardware comum e saídas confiáveis

  • Em vez de um único modelo com X especialistas ativos, parece mais apropriado colocar 10 modelos diferentes, pequenos e densos, treinados com informação específica, em 10 servidores e conectá-los com um roteador

• Sou colaborador do Mesh LLM e criei o motor skippy, que permite particionar modelos grandes entre vários nós. Se tiverem perguntas, posso responder

  • Fico feliz em ver tecnologia relacionada a IPFS reaparecendo. Tenho duas dúvidas
    Primeiro: ao distribuir a computação dessa forma, todos os participantes do grafo de computação acabam sabendo qual sequência está sendo processada; como vocês lidam com privacidade? Segundo: existe alguma proteção para impedir que participantes maliciosos contaminem as ativações do modelo?
  • Gostaria de entender qual é o incentivo para participar da mesh pública. Existe alguma garantia de justiça, como fornecer 1/8 da VRAM necessária para rodar um certo modelo e receber pelo menos 1/16 do uso de inferência em troca?
  • Haveria alguma vantagem em integrar isso ao projeto Colibri, anunciado há poucos dias?
  • Nunca examinei a fundo a implementação de cache KV e fiquei curioso se vocês operam caches essencialmente independentes por camada
    Se for assim, parece algo que se particiona de forma bem limpa em termos de computação e volume de dados, e a única lentidão seria o tempo de espera de cada camada pela sua vez. Com um pipeline, também daria para executar várias consultas ao mesmo tempo
    Existe algum caso de implementação de best-of-N com um pipeline de N estágios, injetando consultas com um deslocamento de um estágio entre elas?
  • Administro um laboratório com muitos processadores EPYC e modelos diferentes, e é impressionante que isso possa ser unido dessa forma

• Procurando LLMs com computação distribuída parecida, encontrei o AI Horde, algumas tentativas pequenas do lado do Aphrodite e também o treinamento distribuído da Nous Research
  Dentre eles, o AI Horde parece ser o maior. A API usa o formato de conclusão de texto do KoboldCPP, não o de conclusão de chat. Como expõe mais variáveis de ajuste e tende a gerar resultados melhores para roleplay, parece que os membros mais ativos da comunidade preferem fortemente esse formato. Para outros usos, a maioria provavelmente exigirá chamada de ferramentas, então fora roleplay não sei muito bem onde isso se encaixaria
  Nesta semana, comecei a melhorar a bridge OpenAI para suportar templates de chat e parsing de respostas. Se eu conseguir incluir isso na distribuição oficial, talvez dê para usar em programação mesmo que seja necessário recorrer a modelos de roleplay
  Os mecanismos de prevenção de abuso também são mais robustos. Para evitar ataques coordenados, um worker precisa acumular 1 semana de tempo total de atividade para ser reconhecido como confiável, e usuários podem escolher apenas workers confiáveis. Ao operar um worker, você ganha kudos, que podem ser usados para gerações acima do limite de 512 tokens, e pedidos gratuitos vão para o fim da fila

• Fiquei pensando no que uma botnet polimórfica rodando um ou mais LLMs distribuídos poderia fazer. A ideia seria usar todos os hosts da botnet como recursos de cluster para rodar LLMs e conduzir a evolução dos métodos de propagação e dos payloads de cada cluster da botnet
  Variantes ruins seriam detectadas e removidas, métodos de propagação ineficazes não se espalhariam, mas as versões melhores sobreviveriam e continuariam crescendo. A arquitetura apresentada aqui é bem parecida com isso, e o QUIC funciona de forma tão dinâmica que talvez fosse mais difícil de detectar do que parece

• O projeto https://query.mt/ usa uma mesh baseada em iroh já faz algum tempo. Se você quiser usar um modelo em mesh até no celular, pode valer a pena testar

• Passei um tempo tentando rodar o mesh-llm, mas não encontrei nenhuma build instalável de llama.cpp que funcionasse na minha GPU antiga. Parecia haver suporte para fazer proxy para um serviço externo de llama.cpp, mas também não consegui acertar essa configuração
  É um projeto muito interessante, mas ainda tem bastante coisa sem polimento

  • Se você enviar um relatório de bug, eu gostaria de tentar resolver junto para fazer funcionar

• Achei que isso fosse possível e perguntei ao ChatGPT cerca de um ano atrás, mas ele respondeu que a latência seria alta demais e tornaria isso inviável. Na época eu já vinha estudando libp2p havia quase um ano procurando um projeto em que pudesse usar isso