Kvasir-Architektur

Eine Karte des gesamten Systems: Wallets, das Gateway, das die Zahlung annimmt, die Bridge, die die Engine nach außen vertritt, und das p4-Netzwerk, das das Modell ausführt.

Kvasir besteht aus vier Schichten mit je einer Nahtstelle. Wallets halten die Schlüssel. Das Gateway nimmt die Zahlung an und führt das Ledger. Die Bridge gibt der Inferenz-Engine ein HTTP-Gesicht. Das p4-Netzwerk führt das Modell tatsächlich aus. Alles Weitere folgt daraus, wo diese Nähte liegen — und das Diagramm markiert, was heute läuft und was noch Entwurf ist.

iOS (Swift), Android (Kotlin) und Desktop (React + Electron) sind getrennte Builds derselben Wallet, und der Desktop-Build ist zugleich das, was das Gateway unter / als Browser-Wallet ausliefert — eine vollwertige Wallet mit Signieren in der Seite, keine reine Lesekonsole. Belohnungen gehen an die eigene Solana-Adresse jedes Besitzers; das Gateway hält nie einen Nutzerschlüssel.

solana/staking-service ist beides: das API-Gateway (ein OpenAI-kompatibles /v1/chat/completions plus der Pay-per-Request-Fluss von /api/pay/quote → /api/inference) und das Abrechnungs-Gateway (Staking, Node-Registry, Guthabenkonten, Beitragsgutschrift). Sie sind ein Prozess, weil sie ein Ledger teilen: Eine Anfrage wird erst bedient, nachdem ihr KVR-Transfer on-chain verifiziert ist, und dasselbe Ledger schreibt den Knoten gut, die sie bedient haben.

Die Bridge (p4bridge) ist ein OUTER in p4-Begriffen: Sie installiert eine Session über die Stages, reicht die Anfrage an die Kopf-Stage ein und sammelt den Token-Strom ein. Gegenüber dem Gateway ist sie ein kleiner, fester Vertrag — welche Modelle geladen sind, wer wie viel beigetragen hat, und Completions.

Zwei Aufgaben überlässt p4 bewusst der Bridge: das Chat-Template (p4 reicht dem Stage-Server einen opaken Prompt weiter und wendet keines an, ein Instruct-Modell würde deinen Text also fortsetzen, statt ihn zu beantworten) und den Reasoning-Block (als reasoning_content zurückgegeben, getrennt von content, damit ein Denk-Durchlauf nicht still das Token-Budget auffrisst und dem Zahler eine leere Antwort in Rechnung stellt).

Ein Agent besitzt die Nodes eines Hosts; ein Stage-Server ist ein Prozess, der eine Scheibe der Modell-Layer hält. Eine Stage reicht ihr Ergebnis an die nächste weiter, indem sie ihren eigenen Agent bittet, den Agent jener Stage unter der Adresse zu wählen, die dieser Agent bewirbt — die beworbene Adresse muss also von den anderen Hosts erreichbar sein und sollte das schnellste Netz sein, das sie teilen. Im MI250-Rack ist das die InfiniBand-Verbindung, nicht das Büro-LAN und niemals Loopback.

• `p4-agent` und `p4_staged_server` sind ein Release. Ein Agent aus einem neueren Baum scheitert bei READY an einer fehlenden HELLO-Capability — nachdem das ganze Modell geladen wurde.
• Die Platzierung ist ein Betreiber-Artefakt. Welche Layer auf welcher GPU liegen und unter welcher Load-Generation, kommt aus einem Platzierungsplan; die Bridge antwortet jedem mit 409, der sie zum Bedienen auffordert, und der Watchdog des Gateways sagt das einmal und hört auf zu fragen.
• Eine Pipeline braucht mindestens zwei Stages. Das Session-Kommando verweigert eine Pipeline mit nur einer Stage.

Edge-Nodes — eine Desktop-App, ein Smartphone — haben keine Adresse, die jemand wählen könnte. Das Relay gibt ihnen eine: Der Node verbindet sich nach außen, weist das Wallet-Schlüsselpaar über eine ed25519-Challenge nach und ist danach über das Relay erreichbar. Das Relay ist die Authentifizierungsgrenze und parst nie Nutzdaten. Der Desktop-Installer liefert den p4-Agent zusammen mit der App aus, der Beitritt ist also keine zweite Installation.

Jede Stage meldet die Token-Zeilen, die sie ausgeführt hat. Die Bridge summiert sie je Node, und das Gateway pollt /api/contributions alle 30 Sekunden und schreibt der Wallet, die die Bridge nennt, rows / 1000 Einheiten gut, skaliert mit der Leistungsstufe des Nodes. In einer Pipeline sieht jede Stage dieselben Zeilen, ein Vier-Stage-Ring bezahlt seine vier Stages also gleich, egal wie viele Layer jede hält — die Gutschrift folgt der Teilnahme, nicht dem Gewichtsanteil. Experten-Sharding, bei dem Nodes unterschiedliche Bruchteile einer Layer halten, ist der Fall, der das neu aufwerfen wird.

P4 Studio ist p4s eigene Betreiberkonsole. Der Beobachtbarkeits-Feed je Anfrage, den sie von den Agents haben will, ist ein Vorschlag im Upstream und läuft hier nicht — deshalb zeichnet ihn das Diagramm gestrichelt, neben den von Edge-Nodes bedienten Experten-Shards, die entworfen und noch nicht in Betrieb sind.