Lernen

Lernen Sie Acurast kennen. Entdecken Sie die Geschichte, tauchen Sie in die technische Dokumentation ein und sehen Sie, mit wem Acurast im Ökosystem zusammenarbeitet.

Builder Spotlight: NodeGhost


Builder Spotlight: Ein privates LLM auf einem Smartphone, erreichbar als Standard-OpenAI-Endpunkt


Builder Spotlight

Was der Acurast-Tunnel und NodeGhost leisten und was passiert, wenn man beide kombiniert

Der übliche Weg, ein LLM in ein Produkt einzubauen: Man richtet einen OpenAI-kompatiblen Client auf eine gehostete API und schickt den Prompt an die Server eines Drittanbieters. Das Modell gehört nicht Ihnen, und die Maschine auch nicht. Selbst hosten verlagert den Workload meist nur auf gemietete Cloud-GPUs.
Dieses Beispiel aus der Acurast-App-Tunnel-Reihe lässt das Modell stattdessen auf einem einzigen attestierten Smartphone laufen. Der Acurast-Tunnel macht das lokal gebundene Modell über eine öffentliche HTTPS-URL erreichbar, und NodeGhost stellt es dank seiner Bring-Your-Own-Model-Unterstützung als direkt einsetzbaren OpenAI-kompatiblen Endpunkt bereit. Zwei Fähigkeiten, dazwischen ein einziger Registrierungsschritt.
Es ist ein ganz normaler OpenAI-Aufruf. Das Modell, das ihn beantwortet, läuft auf einem Smartphone.

Das Projekt auf einen Blick

01 /

Was es ist
Ein quantisiertes Qwen2.5-3B-Modell auf einem einzigen attestierten Acurast Processor, genutzt als ganz normaler OpenAI-kompatibler Endpunkt.

02 /

Was es möglich macht
Zwei Fähigkeiten: der Acurast-Tunnel für die Erreichbarkeit und das BYOM-Gateway von NodeGhost für eine Standard-API. Eine einzige Endpunkt-Registrierung verbindet beide.

03 /

Status
Ein funktionierendes Referenzbeispiel, schon heute auf Acurast Canary deploybar, und ehrlich, was den Durchsatz eines 3B-Modells auf einer mobilen CPU angeht.

01 / ABSCHNITT

Was der Acurast-Tunnel leistet

Einen lokal gebundenen Dienst auf einem Smartphone hinter NAT von überall erreichbar machen, ganz ohne eingehende Verbindung.

Ein Acurast Processor sitzt hinter dem NAT des Mobilfunkanbieters und hat keine öffentliche IP. Ein Dienst, der dort an 127.0.0.1 gebunden ist, ist von außen standardmäßig unsichtbar. Der Tunnel ändert das.
Erreichbar von außen, ohne eingehende Verbindung. Das Smartphone nimmt nie eine eingehende Verbindung an. Es baut selbst eine Verbindung zu einer Reihe von Relays auf und hält sie offen. Datenverkehr an die öffentliche URL des Tunnels läuft über dieselbe Leitung zurück zum lokalen Port. Das NAT des Mobilfunkanbieters und die fehlende öffentliche IP stören nicht, weil auf dem Smartphone nichts auf eingehenden Verkehr wartet.
Eine öffentliche HTTPS-URL mit automatischem TLS. Jeder Tunnel startet unter https://<clientId>.<your-domain>:8443, die Zertifikate werden automatisch über ACME ausgestellt. Der Aufrufer spricht ganz normales HTTPS mit einer gewöhnlichen Subdomain.
Eine neue Identität bei jedem Lauf. Jedes Deployment erzeugt einen neuen P-256-Schlüssel als Tunnel-Identität, und aus diesem Schlüssel wird eine neue Subdomain abgeleitet. Die URL gilt pro Deployment: Sie funktioniert nur, solange das Deployment läuft, und endet mit ihm. Beim Start meldet das Deployment seine tatsächliche URL über einen Callback zurück. Wenn Sie eine feste Adresse möchten, können Sie den Schlüssel im Bundle speichern (ein geleaktes Bundle trägt dann die Adresse mit sich) oder den Konsumenten sich neu registrieren lassen, sobald sich die URL ändert.
Er leitet einen Port weiter, kein Protokoll. Der Tunnel weiß nicht, dass er LLM-Verkehr transportiert; er leitet einen TCP-Port weiter. Das Schwesterbeispiel app-tunnel/cargo betreibt SSH über denselben Tunnel-Client. Das zeigt, dass der Tunnel ein universeller Baustein ist und der Dienst dahinter austauschbar.
Er läuft auf attestierten Smartphones. Das Deployment wird nur attestierten Acurast-Smartphones zugeordnet, und der Tunnel-Client läuft in der proot-Sandbox der Shell-Runtime neben dem Workload und stimmt sich über eine lokale JSON-RPC-Bridge mit dem Processor ab.

02 / ABSCHNITT

Was NodeGhost leistet und wie die BYOM-Übergabe funktioniert

Eine direkt einsetzbare OpenAI-API vor einem Backend, das überall laufen kann, auch auf einem Smartphone.

Die README beschreibt NodeGhost eng gefasst, und mehr braucht dieses Beispiel auch nicht: NodeGhost leitet Inferenz über Pocket Network, stellt eine OpenAI-kompatible API bereit und unterstützt Bring Your Own Model.
Eine direkt einsetzbare OpenAI-kompatible API. NodeGhost bietet dieselbe Schnittstelle wie die OpenAI-API, sodass bestehende Clients, Bibliotheken und Tools nach einer Änderung der Base-URL weiter funktionieren.
Über Pocket Network geleitet. Anfragen laufen über die dezentrale POKT-Ebene, statt direkt beim Endpunkt eines einzelnen Anbieters zu landen.
Bring Your Own Model. Statt eines von NodeGhost gehosteten Modells richtet ein Betreiber einen API-Schlüssel auf sein eigenes OpenAI-kompatibles Backend. In diesem Beispiel ist dieses Backend der llama-server auf dem Acurast Processor, erreichbar über den Tunnel.
Die Übergabe. Sobald der Tunnel seine URL meldet, registrieren Sie sie bei NodeGhost als BYOM-Endpunkt. (Der Register-Aufruf im Beispiel lässt den Endpunkt-Schlüssel weg, da llama-server standardmäßig ohne Authentifizierung läuft.) Danach läuft eine normale Chat-Completions-Anfrage über NodeGhost und durch den Tunnel zum Modell auf dem Smartphone, und die Antwort enthält den Modellnamen, was bestätigt, wo sie erzeugt wurde.

03 / ABSCHNITT

Wie beides zusammenspielt

Eine einzige Registrierung macht aus Erreichbarkeit und einer Standard-API eine Anfrage, die auf einem Smartphone landet.

Für sich genommen sind Tunnel und OpenAI-kompatible Gateways ganz gewöhnlich. Der Kern des Beispiels ist die Verbindung: Mit einem zusätzlichen Schritt, der Registrierung der Tunnel-URL als BYOM-Backend, wird ein auf dem Smartphone gehostetes Modell zum direkt einsetzbaren Inferenz-Endpunkt, und die aufrufende Anwendung ändert sich überhaupt nicht.

Smartphone · Acurast Processor (Shell-Runtime / proot)

llama-server :8080
Qwen2.5-3B-Instruct-Q4_K_M

↓
Tunnel · Acurast-Tunnel

ausgehende Verbindung zu Relays  ->  https://<clientId>.<your-domain>:8443
(kurzlebige P-256-Identität, ACME-TLS, per Callback gemeldete URL)

↓
Gateway · NodeGhost (OpenAI-kompatibel, über POKT geleitet)

Tunnel-URL als BYOM-Endpunkt registriert
POST https://<gateway>/v1/chat/completions
-> durch den Tunnel geleitet -> Inferenz auf dem Smartphone

04 / ABSCHNITT

Was heute schon funktioniert

Ein deploybares Beispiel, das eine OpenAI-Anfrage bei einem auf dem Smartphone gehosteten Modell ankommen lässt.

Beim Deployment richtet der Processor eine proot-Ubuntu-Umgebung ein, baut einen kleinen Loopback-Shim, damit sich der lokale Server in der Sandbox korrekt bindet, lädt llama.cpp und das Qwen2.5-3B-Modell zur Laufzeit herunter und startet den Server hinter einer Bereitschaftsschleife mit Health-Check. Erst wenn das Modell geladen ist, öffnet sich der Tunnel.
Über den Callback-Empfänger verfolgen Sie den Ablauf: Einrichtung der Umgebung, die Downloads, das Laden des Modells, die Bereitschaft des Modells und schließlich ein started-Ereignis mit der öffentlichen Tunnel-URL. Registrieren Sie diese URL bei NodeGhost, senden Sie eine normale Chat-Anfrage, und die Antwort kommt vom Smartphone zurück.
Jetzt ausprobieren.
Sehen Sie sich das Beispiel an, deployen Sie es auf Canary und beobachten Sie, wie eine Anfrage auf einem Smartphone landet: github.com/Acurast/acurast-example-apps/tree/main/apps/app-tunnel/llm

05 / ABSCHNITT

Die ehrliche Obergrenze

Jede Fähigkeit hat Grenzen, und diese ist leicht zu benennen.

Ein auf Q4 quantisiertes 3B-Modell auf einer mobilen ARM-CPU erzeugt rund 3 Token pro Sekunde. Eine Antwort von etwa 120 Token dauert rund 45 Sekunden, und bei mehrstufigem Schlussfolgern macht das Modell einfache Fehler. Das ist die Obergrenze dieses Modells auf dieser Hardware, keine Grenze des Tunnels, der Runtime oder des Netzwerks.
In der Praxis passt das Muster zu asynchroner Arbeit, Batch-Verarbeitung oder Aufgaben mit kurzem Kontext: Zusammenfassungen im Hintergrund, Klassifizierung, Generierung aus einer Warteschlange, Agent-Schritte, auf die kein Mensch unmittelbar wartet. Für interaktiven Chat ist es nicht gebaut. Ein kleineres Modell für mehr Durchsatz zu wählen oder die Latenz in Kauf zu nehmen, weil das Modell auf Hardware unter eigener Kontrolle laufen soll, sind beides legitime Entscheidungen.

Wo sich das verallgemeinern lässt

Dem Tunnel ist egal, was er weiterleitet, und NodeGhost setzt kein gehostetes Backend voraus. Das Cargo-Schwesterbeispiel beweist es, indem es SSH über denselben Tunnel betreibt. Jeder lokal gebundene Dienst auf einem attestierten Smartphone lässt sich so erreichen, und jeder Workload im OpenAI-Format kann unverändert davorsitzen. Das Modell ist hier nur zufällig das, was am anderen Ende lief.

Über den Stack

NodeGhost ist ein dezentrales Gateway für KI-Inferenz, das über Pocket Network routet, eine OpenAI-kompatible API bereitstellt und Bring Your Own Model unterstützt. Mehr unter nodeghost.ai.
Pocket Network ist die dezentrale Ebene, über die NodeGhost Anfragen leitet. Mehr unter pocket.network.
Acurast ist ein dezentrales Netzwerk attestierter Smartphones, das verteilte Edge-Rechenleistung bereitstellt; Workloads werden auf attestierte Smartphones im gesamten Netzwerk deployt. Mehr unter acurast.com.
Dieses Beispiel ist ein Acurast-Referenz-Build, veröffentlicht im Repository acurast-example-apps.

Sie bauen auf Acurast?

Wenn Sie eigene Modelle, Agent-Backends oder andere Dienste auf attestierten Smartphones betreiben, melden Sie sich beim Acurast-Team. Treten Sie dem Discord bei.