Builder Spotlight : NodeGhost
Builder Spotlight
Ce que font le tunnel Acurast et NodeGhost, et ce qui se passe quand on les combine
Pour ajouter un LLM à un produit, on pointe généralement un client compatible OpenAI vers une API hébergée et on envoie le prompt aux serveurs d’un fournisseur tiers. Le modèle ne vous appartient pas, la machine non plus. L’auto-hébergement, lui, ne fait d’ordinaire que déplacer la charge de travail vers des GPU cloud loués.
Cet exemple, issu de la famille app-tunnel d’Acurast, fait plutôt tourner le modèle sur un seul smartphone attesté. Le tunnel Acurast rend ce modèle, lié en local, accessible via une URL HTTPS publique, et NodeGhost le sert comme un endpoint compatible OpenAI prêt à l’emploi grâce à sa prise en charge de Bring Your Own Model. Deux capacités, et une seule étape d’enregistrement entre les deux.
C’est un appel OpenAI ordinaire. Le modèle qui y répond tourne sur un téléphone.
Le projet en bref
01 /
Ce que c’est
Un modèle Qwen2.5-3B quantifié qui tourne sur un seul Processor Acurast attesté, utilisé comme un endpoint ordinaire compatible OpenAI.
02 /
Ce qui le rend possible
Deux capacités : le tunnel Acurast pour l’accessibilité, et la passerelle BYOM de NodeGhost pour une surface d’API standard. Un seul enregistrement d’endpoint les relie.
03 /
Statut
Un exemple de référence fonctionnel, déployable dès aujourd’hui sur le canary d’Acurast, et honnête sur le débit d’un modèle 3B sur un CPU mobile.
01 / SECTION
Ce que fait le tunnel Acurast
Rendre accessible de partout un service lié en local sur un téléphone derrière un NAT, sans aucune connectivité entrante.
Un Processor Acurast se trouve derrière le NAT de l’opérateur mobile, sans IP publique. Un service lié à 127.0.0.1 sur ce Processor est, par défaut, invisible de l’extérieur. C’est ce que change le tunnel.
Une accessibilité entrante sans connexion entrante. Le téléphone n’accepte jamais de connexion entrante. Il se connecte vers l’extérieur à un ensemble de relais et maintient cette connexion ouverte, et le trafic envoyé à l’URL publique du tunnel redescend par cette même ligne jusqu’au port local. Le NAT de l’opérateur et l’absence d’IP publique ne posent aucun problème, puisque rien sur le téléphone n’attend de trafic entrant.
Une URL HTTPS publique avec TLS automatique. Chaque tunnel est accessible à l’adresse
https://<clientId>.<your-domain>:8443, avec des certificats émis automatiquement via ACME. L’appelant communique en HTTPS standard avec un sous-domaine ordinaire.Une nouvelle identité à chaque exécution. Chaque déploiement génère une nouvelle clé P-256 comme identité de tunnel, et cette clé dérive un nouveau sous-domaine. L’URL est propre à chaque déploiement : elle ne fonctionne que pendant l’exécution du déploiement et s’arrête à sa fin, et le déploiement communique son URL réelle via un callback au démarrage. Si vous voulez une adresse stable, vous pouvez conserver la clé dans le bundle (un bundle divulgué emporte alors l’adresse avec lui) ou faire en sorte que le consommateur se réenregistre lorsque l’URL change.
Il transfère un port, pas un protocole. Le tunnel ne sait pas qu’il transporte du trafic de LLM ; il transfère un port TCP. L’exemple voisin app-tunnel/cargo fait passer SSH par le même client de tunnel, ce qui montre que le tunnel est une primitive généraliste et que le service qui se trouve derrière est interchangeable.
Il tourne sur des téléphones attestés. Le déploiement n’est attribué qu’à des téléphones Acurast attestés, et le client de tunnel tourne dans le bac à sable proot du runtime Shell, à côté de la charge de travail, en se coordonnant avec le Processor via un pont JSON-RPC local.
02 / SECTION
Ce que fait NodeGhost, et le relais BYOM
Une API OpenAI prête à l’emploi devant un backend qui peut se trouver n’importe où, y compris sur un téléphone.
Le README décrit NodeGhost en termes précis, et c’est tout ce dont cet exemple a besoin : il achemine l’inférence via Pocket Network, expose une API compatible OpenAI et prend en charge Bring Your Own Model.
Une API compatible OpenAI prête à l’emploi. NodeGhost expose la même interface que l’API OpenAI : les clients, bibliothèques et outils existants continuent de fonctionner après un simple changement d’URL de base.
Acheminé via Pocket Network. Les requêtes passent par la couche décentralisée POKT au lieu d’atteindre directement l’endpoint d’un fournisseur unique.
Bring Your Own Model. Au lieu d’un modèle hébergé par NodeGhost, un opérateur associe une clé API à son propre backend compatible OpenAI. Dans cet exemple, ce backend est le llama-server du Processor Acurast, joint via le tunnel.
Le relais. Une fois que le tunnel a communiqué son URL, vous l’enregistrez auprès de NodeGhost comme endpoint BYOM. (L’appel d’enregistrement de l’exemple omet la clé d’endpoint, car llama-server fonctionne sans authentification par défaut.) Ensuite, une requête chat-completions standard passe par NodeGhost puis par le tunnel jusqu’au modèle sur le téléphone, et la réponse contient le nom du modèle, ce qui confirme d’où elle a été servie.
03 / SECTION
Comment les deux se combinent
Un seul enregistrement transforme l’accessibilité et une API standard en une requête qui aboutit sur un téléphone.
Pris séparément, les tunnels et les passerelles compatibles OpenAI n’ont rien d’extraordinaire. Tout l’intérêt de l’exemple est leur jonction : avec une seule étape supplémentaire, l’enregistrement de l’URL du tunnel comme backend BYOM, un modèle hébergé sur un téléphone devient un endpoint d’inférence prêt à l’emploi, et l’application appelante ne change en rien.
Téléphone · Acurast Processor (runtime Shell / proot)
llama-server :8080
Qwen2.5-3B-Instruct-Q4_K_M
Qwen2.5-3B-Instruct-Q4_K_M
↓
Tunnel · tunnel Acurast
connexion sortante vers les relais -> https://<clientId>.<your-domain>:8443
(identité P-256 éphémère, TLS ACME, URL communiquée par callback)
(identité P-256 éphémère, TLS ACME, URL communiquée par callback)
↓
Passerelle · NodeGhost (compatible OpenAI, acheminement POKT)
URL du tunnel enregistrée comme endpoint BYOM
POST https://<gateway>/v1/chat/completions
-> acheminée par le tunnel -> inférence sur le téléphone
POST https://<gateway>/v1/chat/completions
-> acheminée par le tunnel -> inférence sur le téléphone
04 / SECTION
Ce qui fonctionne aujourd’hui
Un exemple déployable qui fait aboutir une requête OpenAI sur un modèle hébergé sur un téléphone.
Au déploiement, le Processor met en place un environnement Ubuntu proot, compile un petit shim de loopback pour que le serveur local se lie correctement dans le bac à sable, télécharge llama.cpp et le modèle Qwen2.5-3B à l’exécution, puis démarre le serveur derrière une boucle de disponibilité conditionnée par un contrôle de santé. Le tunnel ne s’ouvre qu’une fois le modèle chargé.
Vous suivez la séquence via le récepteur de callbacks : mise en place de l’environnement, téléchargements, chargement du modèle, modèle prêt et, pour finir, un événement
started qui contient l’URL publique du tunnel. Enregistrez cette URL auprès de NodeGhost, envoyez une requête de chat normale, et la réponse revient du téléphone.Essayez dès maintenant.
Explorez l’exemple, déployez-le sur canary et regardez une requête aboutir sur un téléphone : github.com/Acurast/acurast-example-apps/tree/main/apps/app-tunnel/llm
05 / SECTION
Le plafond, en toute honnêteté
Toute capacité a ses limites, et celle-ci est facile à nommer.
Un modèle 3B quantifié en Q4, qui tourne sur un CPU ARM mobile, génère environ 3 tokens par seconde. Une réponse d’environ 120 tokens prend à peu près 45 secondes, et le modèle commet des erreurs de base sur le raisonnement en plusieurs étapes. C’est le plafond de ce modèle sur ce matériel, pas une limite du tunnel, du runtime ou du réseau.
En pratique, ce schéma convient aux tâches asynchrones, par lots ou à contexte court : synthèse en arrière-plan, classification, génération en file d’attente, étapes d’agent qui ne sont pas sur le chemin critique d’un humain. Il n’est pas conçu pour le chat interactif. Choisir un modèle plus petit pour gagner en débit, ou accepter la latence parce que vous voulez que le modèle tourne sur du matériel que vous contrôlez : les deux choix se défendent.
Où cela se généralise
Le tunnel se moque de ce qu’il transfère, et NodeGhost n’exige pas que le backend soit hébergé. L’exemple voisin cargo le prouve en faisant passer SSH par le même tunnel. N’importe quel service lié en local sur un téléphone attesté peut être joint de cette façon, et n’importe quelle charge de travail au format OpenAI peut s’y brancher sans modification. Le modèle n’est ici que ce qui se trouvait à l’autre bout.
À propos de la stack
NodeGhost est une passerelle d’inférence IA décentralisée qui achemine les requêtes via Pocket Network, expose une API compatible OpenAI et prend en charge Bring Your Own Model. En savoir plus sur nodeghost.ai.
Pocket Network est la couche décentralisée via laquelle NodeGhost achemine les requêtes. En savoir plus sur pocket.network.
Acurast est un réseau décentralisé de smartphones attestés qui fournit du calcul distribué en périphérie, les charges de travail étant déployées sur des téléphones attestés à travers le réseau. En savoir plus sur acurast.com.
Cet exemple est un build de référence d’Acurast, publié dans le dépôt acurast-example-apps.
Vous développez sur Acurast ?
Si vous faites tourner vos propres modèles, backends d’agents ou autres services sur des téléphones attestés, venez en parler avec l’équipe. Rejoignez le Discord.
