Bridge

Das HTTP-Gesicht der Inferenz-Engine: was geladen ist, wer beigetragen hat, und Completions — und sonst nichts.

Die Bridge ist das Einzige, womit das Abrechnungs-Gateway für Inferenz spricht. Sie ist ein OUTER in p4-Begriffen: Sie installiert eine Session über die Stages des Modells, reicht eine Anfrage an die Kopf-Stage ein, sammelt den Token-Strom ein und meldet, was jeder Node beigetragen hat. Sie besitzt keine Platzierung, kein Scheduling und keinen Zustand über einen Katalog des Geladenen hinaus — bewusst klein, denn alles, was sie nicht entscheidet, kann auch nicht auseinanderdriften.

Der Vertrag

Vier Routen, ein Token

RouteWas sie beantwortet
/api/controllerswelche Modelle geladen sind und den Zustand jeder Stage
/api/runtimedie Betreiber-Wallet und die Maschinen dahinter
/api/contributionsZeilen, Einheiten, Anfragen und Durchsatz je Node
/c/<model>/v1/chat/completionsInferenz

Jede Route außer /api/health verlangt ein geteiltes Service-Token, gesendet als X-Kvasir-Service-Token. Dieses Token ist das Einzige, was zwischen dem offenen Internet und der kostenlosen Nutzung des Rings steht — deshalb bindet die Bridge auf Loopback und wird über einen Tunnel erreicht, statt veröffentlicht zu werden.

Was p4 ihr überlässt

Zwei Aufgaben, die die Engine nicht übernimmt

  • Das Chat-Template. p4 reicht dem Stage-Server einen opaken Prompt weiter und wendet kein eigenes Turn-Format an. Die Bridge rendert das des Modells — aus dem GGUF gelesen und im Katalog als prompt_format benannt. Lässt man es weg, setzt ein Instruct-Modell deinen Text fort, statt ihn zu beantworten, gibt nie sein End-of-Turn-Token aus und läuft jedes Mal ins Token-Limit.
  • Der Reasoning-Block. Ein Reasoning-Modell beginnt seine Antwort mit Denken. Die Bridge gibt das als reasoning_content zurück, getrennt von content, und respektiert enable_thinking: false, indem sie den Block schon im Prompt schließt — sonst kann ein langer Denk-Durchlauf das ganze Budget verbrauchen und dem Aufrufer eine leere Antwort liefern, für die er bereits bezahlt hat.
Platzierung ist nicht ihre Aufgabe

Warum sie mit 409 antwortet

Die Bridge aufzufordern, ein Modell zu bedienen, ergibt 409. Welche Layer auf welcher GPU liegen und unter welcher Load-Generation, kommt aus einem Platzierungsplan, den ein Betreiber geschrieben und geladen hat; es gibt kein Remote-Reload durchzuführen. Der Ring-Watchdog des Gateways lernt das einmal und hört auf zu fragen, statt etwas zu wiederholen, das nicht funktionieren kann.

Beitragszähler leben im Speicher. Ein Neustart der Bridge verliert, was das Gateway noch nicht abgeholt hatte — es pollt alle 30 Sekunden — und das Gateway baselined neu, statt doppelt zu zählen, wenn ein Zähler zurückspringt. Ein Node, dessen Besitzer die Bridge nicht kennt, wird still übersprungen; eine nicht gesetzte Betreiber-Wallet liest sich also als „diese Maschinen haben nichts verdient“.