Builder Spotlight: NodeGhost
Builder Spotlight
Cosa fanno il tunnel di Acurast e NodeGhost, e cosa succede quando li metti insieme
Il modo abituale di aggiungere un LLM a un prodotto è puntare un client compatibile con OpenAI verso un’API ospitata e inviare il prompt ai server di un provider terzo. Il modello non è tuo, e nemmeno la macchina. Anche il self-hosting di solito sposta semplicemente il carico di lavoro su GPU cloud in affitto.
Questo esempio, della famiglia app-tunnel di Acurast, esegue invece il modello su un singolo smartphone attestato. Il tunnel di Acurast rende quel modello, vincolato in locale, raggiungibile da un URL HTTPS pubblico, e NodeGhost lo serve come endpoint compatibile con OpenAI, pronto all’uso, grazie al supporto Bring Your Own Model. Due funzionalità, e un solo passaggio di registrazione tra le due.
È una normale chiamata OpenAI. Il modello che risponde gira su uno smartphone.
Il progetto in breve
01 /
Che cos’è
Un modello Qwen2.5-3B quantizzato che gira su un singolo Processor Acurast attestato, usato come un normale endpoint compatibile con OpenAI.
02 /
Cosa lo rende possibile
Due funzionalità: il tunnel di Acurast per la raggiungibilità e il gateway BYOM di NodeGhost per un’interfaccia API standard. Una sola registrazione dell’endpoint le collega.
03 /
Stato
Un esempio di riferimento funzionante, su cui puoi fare il deploy già oggi su Acurast canary, e onesto sul throughput di un modello da 3B su una CPU mobile.
01 / SEZIONE
Cosa fa il tunnel di Acurast
Rende raggiungibile da qualsiasi luogo un servizio vincolato in locale su uno smartphone dietro NAT, senza connettività in ingresso.
Un Processor Acurast si trova dietro il NAT dell’operatore, senza IP pubblico. Un servizio vincolato a 127.0.0.1 su di esso è, per impostazione predefinita, invisibile dall’esterno. Il tunnel è ciò che cambia le cose.
Raggiungibile dall’esterno senza connessioni in ingresso. Lo smartphone non accetta mai una connessione in entrata. Si collega in uscita a un insieme di relay e mantiene aperta quella connessione, e il traffico inviato all’URL pubblico del tunnel torna indietro sulla stessa linea fino alla porta locale. Il NAT dell’operatore e la mancanza di un IP pubblico non sono un ostacolo, perché sullo smartphone niente è in attesa di traffico in ingresso.
Un URL HTTPS pubblico con TLS automatico. Ogni tunnel si attiva su
https://<clientId>.<your-domain>:8443, con certificati emessi automaticamente tramite ACME. Chi chiama parla normale HTTPS con un normale sottodominio.Una nuova identità a ogni esecuzione. Ogni deployment genera una nuova chiave P-256 come identità del tunnel, e da quella chiave deriva un nuovo sottodominio. L’URL è legato al singolo deployment: funziona solo mentre il deployment è in esecuzione e smette quando termina, e il deployment comunica il suo URL effettivo tramite un callback all’avvio. Se vuoi un indirizzo stabile, puoi salvare la chiave nel bundle (così però un bundle trapelato porta con sé l’indirizzo) oppure far registrare di nuovo il consumer quando l’URL cambia.
Inoltra una porta, non un protocollo. Il tunnel non ha idea di trasportare traffico LLM: inoltra una porta TCP. L’esempio gemello app-tunnel/cargo esegue SSH sullo stesso client del tunnel, a dimostrazione che il tunnel è una primitiva di uso generale e che il servizio dietro di esso è intercambiabile.
Funziona su smartphone attestati. Il deployment viene abbinato solo a smartphone Acurast attestati, e il client del tunnel gira nella sandbox proot del runtime Shell accanto al carico di lavoro, coordinandosi con il Processor tramite un bridge JSON-RPC locale.
02 / SEZIONE
Cosa fa NodeGhost, e il passaggio a BYOM
Un’API OpenAI pronta all’uso davanti a un backend che può trovarsi ovunque, anche su uno smartphone.
Il README descrive NodeGhost in termini essenziali, ed è tutto ciò su cui si basa questo esempio: instrada l’inferenza su Pocket Network, espone un’API compatibile con OpenAI e supporta Bring Your Own Model.
Un’API compatibile con OpenAI, pronta all’uso. NodeGhost espone la stessa interfaccia dell’API OpenAI, quindi client, librerie e strumenti esistenti continuano a funzionare dopo aver cambiato l’URL di base.
Instradato su Pocket Network. Le richieste passano attraverso il livello decentralizzato di POKT invece di arrivare direttamente all’endpoint di un singolo provider.
Bring Your Own Model. Invece di usare un modello ospitato da NodeGhost, un operatore punta una chiave API verso il proprio backend compatibile con OpenAI. In questo esempio quel backend è il llama-server sul Processor Acurast, raggiunto attraverso il tunnel.
Il passaggio. Quando il tunnel comunica il suo URL, lo registri su NodeGhost come endpoint BYOM. (La chiamata di registrazione dell’esempio omette la chiave dell’endpoint, perché llama-server per impostazione predefinita non richiede autenticazione.) Da quel momento una normale richiesta chat-completions passa per NodeGhost e attraverso il tunnel fino al modello sullo smartphone, e la risposta riporta il nome del modello, a conferma di dove è stata servita.
03 / SEZIONE
Come si combinano i due
Una sola registrazione trasforma raggiungibilità e API standard in una richiesta che arriva su uno smartphone.
Presi singolarmente, tunnel e gateway compatibili con OpenAI sono entrambi ordinari. Il punto dell’esempio è l’unione: con un passaggio in più, cioè registrare l’URL del tunnel come backend BYOM, un modello ospitato su uno smartphone diventa un endpoint di inferenza pronto all’uso, e l’applicazione che lo chiama non cambia affatto.
Smartphone · Acurast Processor (runtime Shell / proot)
llama-server :8080
Qwen2.5-3B-Instruct-Q4_K_M
Qwen2.5-3B-Instruct-Q4_K_M
↓
Tunnel · Tunnel di Acurast
connessione in uscita verso i relay -> https://<clientId>.<your-domain>:8443
(identità P-256 effimera, TLS ACME, URL comunicato tramite callback)
(identità P-256 effimera, TLS ACME, URL comunicato tramite callback)
↓
Gateway · NodeGhost (compatibile con OpenAI, instradato su POKT)
URL del tunnel registrato come endpoint BYOM
POST https://<gateway>/v1/chat/completions
-> instradata attraverso il tunnel -> inferenza sullo smartphone
POST https://<gateway>/v1/chat/completions
-> instradata attraverso il tunnel -> inferenza sullo smartphone
04 / SEZIONE
Cosa funziona oggi
Un esempio pronto per il deploy che porta una richiesta OpenAI a un modello ospitato su uno smartphone.
Al momento del deploy, il Processor configura un ambiente Ubuntu in proot, compila un piccolo shim di loopback affinché il server locale si colleghi correttamente dentro la sandbox, scarica llama.cpp e il modello Qwen2.5-3B in fase di esecuzione e avvia il server dietro un ciclo di verifica della disponibilità basato su health check. Il tunnel si apre solo dopo che il modello è stato caricato.
Segui la sequenza tramite il ricevitore dei callback: configurazione dell’ambiente, download, caricamento del modello, modello pronto e infine un evento
started con l’URL pubblico del tunnel. Registra quell’URL su NodeGhost, invia una normale richiesta di chat e la risposta arriva dallo smartphone.Provalo ora.
Esplora l’esempio, fai il deploy su canary e guarda una richiesta arrivare su uno smartphone: github.com/Acurast/acurast-example-apps/tree/main/apps/app-tunnel/llm
05 / SEZIONE
Il limite, detto onestamente
Ogni funzionalità ha dei limiti, e questo è facile da indicare.
Un modello da 3B quantizzato a Q4, che gira su una CPU ARM mobile, genera circa 3 token al secondo. Una risposta di circa 120 token richiede circa 45 secondi, e il modello commette errori di base nel ragionamento in più passaggi. È il limite di questo modello su questo hardware, non del tunnel, del runtime o della rete.
In pratica lo schema si adatta a lavori asincroni, in batch o a contesto breve: riassunti in background, classificazione, generazione in coda, passaggi di agenti che non sono sul percorso critico di una persona. Non è pensato per la chat interattiva. Scegliere un modello più piccolo per avere più throughput, oppure accettare la latenza perché vuoi il modello su hardware che controlli tu, sono entrambe scelte legittime.
Dove si può generalizzare
Al tunnel non importa cosa inoltra, e NodeGhost non richiede che il backend sia ospitato. Il gemello cargo lo dimostra eseguendo SSH sullo stesso tunnel. Qualsiasi servizio vincolato in locale su uno smartphone attestato può essere raggiunto in questo modo, e qualsiasi carico di lavoro in stile OpenAI può starci davanti senza modifiche. Il modello, qui, è semplicemente ciò che si trovava dall’altra parte.
Lo stack
NodeGhost è un gateway decentralizzato di inferenza IA che instrada su Pocket Network, espone un’API compatibile con OpenAI e supporta Bring Your Own Model. Scopri di più su nodeghost.ai.
Pocket Network è il livello decentralizzato su cui NodeGhost instrada le richieste. Scopri di più su pocket.network.
Acurast è una rete decentralizzata di smartphone attestati che fornisce calcolo edge distribuito, in cui si fa il deploy dei carichi di lavoro su smartphone attestati in tutta la rete. Scopri di più su acurast.com.
Questo esempio è una build di riferimento di Acurast, pubblicata nel repository acurast-example-apps.
Sviluppi su Acurast?
Se esegui modelli, backend per agenti o altri servizi su smartphone attestati, parlane con il team Acurast. Unisciti a Discord.
