Builder em destaque: NodeGhost
Builder em destaque
O que o túnel da Acurast e o NodeGhost fazem, e o que acontece quando você junta os dois
O jeito comum de adicionar um LLM a um produto é apontar um cliente compatível com a OpenAI para uma API hospedada e enviar o prompt para os servidores de um provedor terceiro. O modelo não é seu, e a máquina também não. Hospedar por conta própria normalmente só transfere a carga de trabalho para GPUs alugadas na nuvem.
Este exemplo, da família app-tunnel da Acurast, roda o modelo em um único smartphone atestado. O túnel da Acurast torna esse modelo, vinculado localmente, acessível em uma URL HTTPS pública, e o NodeGhost o serve como um endpoint compatível com a OpenAI, pronto para substituir o original, por meio do suporte a Bring Your Own Model. Duas capacidades e uma etapa de registro entre elas.
É uma chamada comum à OpenAI. O modelo que responde roda em um celular.
O projeto em resumo
01 /
O que é
Um modelo Qwen2.5-3B quantizado rodando em um único Processor atestado da Acurast, consumido como um endpoint comum compatível com a OpenAI.
02 /
O que torna isso possível
Duas capacidades: o túnel da Acurast, para a acessibilidade, e o gateway BYOM do NodeGhost, para uma superfície de API padrão. Um único registro de endpoint une os dois.
03 /
Situação
Um exemplo de referência funcional, que já pode receber deploy na canary da Acurast, e honesto sobre a velocidade de um modelo 3B em uma CPU móvel.
01 / SEÇÃO
O que o túnel da Acurast faz
Torna um serviço vinculado localmente, em um celular atrás de NAT, acessível de qualquer lugar, sem conectividade de entrada.
Um Processor da Acurast fica atrás do NAT da operadora, sem IP público. Um serviço vinculado a 127.0.0.1 nele fica, por padrão, invisível de fora. O túnel é o que muda isso.
Acessibilidade de entrada sem conexão de entrada. O celular nunca aceita uma conexão de entrada. Ele abre uma conexão de saída para um conjunto de relays e a mantém aberta, e o tráfego enviado à URL pública do túnel volta pela mesma linha até a porta local. O NAT da operadora e a falta de IP público não atrapalham, porque nada no celular fica esperando tráfego de entrada.
Uma URL HTTPS pública com TLS automático. Cada túnel sobe em
https://<clientId>.<your-domain>:8443, com certificados emitidos automaticamente via ACME. Quem faz a chamada fala HTTPS simples com um subdomínio comum.Uma identidade nova a cada execução. Cada deployment gera uma nova chave P-256 como identidade do túnel, e essa chave deriva um novo subdomínio. A URL é por deployment: só funciona enquanto o deployment roda e deixa de funcionar quando ele termina, e o deployment informa sua URL real por um callback durante a inicialização. Se você quiser um endereço estável, pode persistir a chave no bundle (um bundle vazado, então, carrega o endereço) ou fazer o consumidor se registrar de novo quando a URL mudar.
Ele encaminha uma porta, não um protocolo. O túnel não faz ideia de que está transportando tráfego de LLM; ele encaminha uma porta TCP. O exemplo irmão app-tunnel/cargo roda SSH pelo mesmo cliente de túnel, o que mostra que o túnel é uma primitiva de uso geral e que o serviço por trás dele é intercambiável.
Ele roda em celulares atestados. O deployment só é combinado com celulares atestados da Acurast, e o cliente do túnel roda no sandbox proot do runtime Shell, ao lado da carga de trabalho, coordenando-se com o Processor por meio de uma bridge JSON-RPC local.
02 / SEÇÃO
O que o NodeGhost faz, e a passagem via BYOM
Uma API da OpenAI pronta para uso na frente de um backend que pode estar em qualquer lugar, inclusive em um celular.
O README descreve o NodeGhost em termos restritos, e é só disso que este exemplo depende: ele roteia inferência pela Pocket Network, expõe uma API compatível com a OpenAI e oferece suporte a Bring Your Own Model.
Uma API compatível com a OpenAI, pronta para substituir. O NodeGhost expõe a mesma interface da API da OpenAI, então clientes, bibliotecas e ferramentas existentes continuam funcionando depois de uma troca da URL base.
Roteado pela Pocket Network. As requisições passam pela camada descentralizada POKT, em vez de ir diretamente ao endpoint de um único provedor.
Bring Your Own Model. Em vez de usar um modelo hospedado pelo NodeGhost, um operador aponta uma chave de API para seu próprio backend compatível com a OpenAI. Neste exemplo, esse backend é o llama-server no Processor da Acurast, acessado pelo túnel.
A passagem. Assim que o túnel informar sua URL, você a registra no NodeGhost como um endpoint BYOM. (A chamada de registro do exemplo omite a chave do endpoint, já que o llama-server roda sem autenticação por padrão.) Depois disso, uma requisição padrão de chat completions passa pelo NodeGhost e pelo túnel até o modelo no celular, e a resposta traz o nome do modelo, o que confirma onde ela foi servida.
03 / SEÇÃO
Como os dois se combinam
Um único registro transforma acessibilidade mais uma API padrão em uma requisição que chega a um celular.
Sozinhos, túneis e gateways compatíveis com a OpenAI são coisas comuns. O ponto do exemplo é a junção: com uma etapa extra, registrar a URL do túnel como backend BYOM, um modelo hospedado em um celular vira um endpoint de inferência pronto para uso, e a aplicação que faz a chamada não muda nada.
Celular · Acurast Processor (runtime Shell / proot)
llama-server :8080
Qwen2.5-3B-Instruct-Q4_K_M
Qwen2.5-3B-Instruct-Q4_K_M
↓
Túnel · Acurast Tunnel
conexão de saída para os relays -> https://<clientId>.<your-domain>:8443
(identidade P-256 efêmera, TLS via ACME, URL informada por callback)
(identidade P-256 efêmera, TLS via ACME, URL informada por callback)
↓
Gateway · NodeGhost (compatível com a OpenAI, roteado pela POKT)
URL do túnel registrada como endpoint BYOM
POST https://<gateway>/v1/chat/completions
-> roteado pelo túnel -> inferência no celular
POST https://<gateway>/v1/chat/completions
-> roteado pelo túnel -> inferência no celular
04 / SEÇÃO
O que já funciona hoje
Um exemplo pronto para deploy que leva uma requisição da OpenAI até um modelo hospedado em um celular.
No deploy, o Processor configura um ambiente Ubuntu com proot, compila um pequeno shim de loopback para que o servidor local faça o bind corretamente dentro do sandbox, baixa o llama.cpp e o modelo Qwen2.5-3B em tempo de execução e inicia o servidor atrás de um loop de prontidão controlado por health check. O túnel só abre depois que o modelo termina de carregar.
Você acompanha a sequência pelo receptor de callbacks: configuração do ambiente, os downloads, o carregamento do modelo, o modelo ficando pronto e, por fim, um evento
started com a URL pública do túnel. Registre essa URL no NodeGhost, envie uma requisição de chat normal, e a resposta volta do celular.Experimente agora.
Explore o exemplo, faça o deploy na canary e veja uma requisição chegar a um celular: github.com/Acurast/acurast-example-apps/tree/main/apps/app-tunnel/llm
05 / SEÇÃO
O limite, com honestidade
Toda capacidade tem limites, e este é fácil de apontar.
Um modelo 3B quantizado em Q4, rodando em uma CPU ARM móvel, gera cerca de 3 tokens por segundo. Uma resposta de uns 120 tokens leva cerca de 45 segundos, e o modelo comete erros básicos em raciocínios de várias etapas. Esse é o limite deste modelo neste hardware, não uma limitação do túnel, do runtime ou da rede.
Na prática, o padrão serve para trabalhos assíncronos, em lote ou de contexto curto: resumos em segundo plano, classificação, geração em fila, etapas de agentes que não estão no caminho crítico de um humano. Ele não foi feito para chat interativo. Escolher um modelo menor para ter mais velocidade, ou aceitar a latência porque você quer o modelo em um hardware que você controla, são escolhas igualmente válidas.
Onde isso se generaliza
O túnel não se importa com o que encaminha, e o NodeGhost não exige que o backend seja hospedado. O exemplo irmão cargo prova isso ao rodar SSH pelo mesmo túnel. Qualquer serviço vinculado localmente em um celular atestado pode ser acessado assim, e qualquer carga de trabalho no formato da OpenAI pode ficar na frente dele sem mudanças. O modelo aqui é só o que por acaso estava do outro lado.
Sobre a stack
NodeGhost é um gateway descentralizado de inferência de IA que roteia pela Pocket Network, expõe uma API compatível com a OpenAI e oferece suporte a Bring Your Own Model. Saiba mais em nodeghost.ai.
Pocket Network é a camada descentralizada pela qual o NodeGhost roteia as requisições. Saiba mais em pocket.network.
Acurast é uma rede descentralizada de smartphones atestados que fornece computação distribuída na borda, em que as cargas de trabalho recebem deploy em celulares atestados de toda a rede. Saiba mais em acurast.com.
Este exemplo é um build de referência da Acurast, publicado no repositório acurast-example-apps.
Está construindo na Acurast?
Se você roda seus próprios modelos, backends de agentes ou outros serviços em celulares atestados, venha conversar com a equipe da Acurast. Entre no Discord.
