O SwarmLLM publicou a versão 0.2.0, um projeto de código aberto que reparte um único modelo de linguagem por vários navegadores em dispositivos diferentes. A versão inclui uma demonstração de 7 de setembro com o Qwen 3.8 27B distribuído entre um MacBook e um iPhone, além do motor WebGPU, transporte por WebRTC, registos de medições, testes e um modelo de ameaça explícito.
O aspeto mais relevante não é a velocidade anunciada pelo próprio projeto, que ainda não foi reproduzida de forma independente. A novidade arquitetural é mais concreta: cada dispositivo descarrega apenas uma sequência de camadas do modelo e envia o estado intermédio diretamente para o navegador seguinte. Assim, memória e capacidade de processamento disponíveis em várias máquinas podem ser usadas em conjunto sem instalar um ambiente de inferência nativo em cada participante.
O modelo pode ser maior do que a memória de cada dispositivo
No SwarmLLM, a tokenização, os embeddings, a cabeça final do modelo e a amostragem ficam no navegador anfitrião. Os blocos do modelo são repartidos por intervalos contíguos de camadas. Depois de processar o seu intervalo, cada dispositivo converte o estado oculto para f16 e envia-o ao participante seguinte através de um canal WebRTC.
Para o Qwen 3.8 27B, a documentação descreve um vetor com 5 120 valores, cerca de 10 KB por passagem. Cada dispositivo obtém apenas os pesos das camadas que lhe foram atribuídas e guarda-os na cache do navegador. Na prática, o sistema agrega capacidade de memória e algum processamento; não transforma vários equipamentos num único GPU.
A versão 0.2.0 empacota esta organização numa sala aberta no navegador. Face a soluções que exigem Python, um serviço RPC ou um binário nativo em cada nó, a barreira operacional é bastante menor. Isso torna a abordagem interessante para laboratórios, formação e pequenas equipas que já dispõem de hardware heterogéneo.
Os números de desempenho ainda são medições do projeto
O SwarmLLM afirma ter medido 9,0 tokens por segundo em descodificação simples e 16,1 com descodificação especulativa num NVIDIA GB10. O mesmo registo compara esses resultados com 8,0 tokens por segundo numa versão específica do llama.cpp, usando o mesmo ficheiro GGUF e a mesma máquina. O projeto também regista 7,7 tokens por segundo quando o modelo de 27B é repartido entre um MacBook e um iPhone na mesma rede Wi-Fi, enquanto o vídeo da versão 0.2.0 mostra 10,7 tokens por segundo numa geração de 400 tokens.
Estas medições não foram validadas por terceiros e não sustentam uma conclusão geral de que o navegador é mais rápido do que uma execução nativa. O próprio registo mostra uma limitação importante: no GB10, o llama.cpp atingiu 377 tokens por segundo no processamento inicial do pedido, enquanto o SwarmLLM reportou 44. Há também perdas claras quando aumenta o número de passagens entre navegadores.
Por isso, a conclusão útil é sobre distribuição de memória e facilidade de disponibilização, não sobre uma vantagem universal de velocidade.
A previsão de vários tokens reduz o custo das viagens pela rede
A inferência autorregressiva distribuída sofre com a latência: se cada token tiver de atravessar vários dispositivos, a rede pode dominar o tempo total. O SwarmLLM usa a cabeça de previsão de vários tokens do Qwen para propor vários candidatos e, depois, faz a verificação em lote pelo corpo principal do modelo.
Segundo a documentação, só são aceites as previsões confirmadas pelo modelo principal. No primeiro desacordo, prevalece o token produzido pelo modelo principal e os estados recorrentes são repostos a partir de uma cópia. Os testes do projeto exigem que a sequência final seja igual à da descodificação simples quando é usado o mesmo método de amostragem.
A escolha ataca diretamente o custo da rede. Num sistema repartido por navegadores, acelerar apenas o cálculo local não basta; cada ida e volta entre dispositivos tem de transportar mais trabalho útil.
A fronteira de confiança passa a incluir todos os participantes
A documentação de segurança é invulgarmente clara. O serviço de sinalização não recebe o tráfego do modelo e o WebRTC cifra a comunicação entre navegadores. Ainda assim, todos os membros da sala veem a conversa e os estados intermédios não devem ser tratados como um mecanismo de confidencialidade.
Há ainda uma limitação mais séria: a versão atual não verifica se um participante remoto executou corretamente as camadas que lhe foram atribuídas. Um dispositivo malicioso pode devolver ativações manipuladas. O projeto coloca a auditoria desse cálculo no trabalho futuro e não apresenta salas abertas a desconhecidos como uma utilização segura.
Retirar um fornecedor central não elimina, portanto, a necessidade de confiança. Apenas desloca essa fronteira para os navegadores que entram na sala. Com dados sensíveis, é preciso controlar não só onde o modelo é executado, mas também quem pode participar no cálculo.
O caso de uso mais convincente é um conjunto local temporário
A análise da Aipolix é que o SwarmLLM faz mais sentido, nesta fase, como forma temporária de juntar recursos locais do que como substituto de uma infraestrutura de nuvem. Uma equipa pode reunir dispositivos já disponíveis, executar um modelo que não caberia numa só máquina e desfazer o conjunto no fim, sem preparar software específico em cada equipamento.
Isso torna três controlos particularmente importantes: fixar o artefacto exato do modelo, limitar a sala a participantes de confiança e registar a topologia e as condições de teste quando o desempenho for relevante. A versão 0.2.0 ainda não valida o cálculo remoto nem confirma por hash o conteúdo dos ficheiros do modelo.
O projeto é pequeno e está numa fase inicial, pelo que os resultados de desempenho precisam de reprodução independente. Ainda assim, o código publicado demonstra uma opção de implementação concreta: repartir inferência local ao nível do navegador, trocando o limite de memória de uma única máquina por restrições de latência de rede e confiança entre participantes.