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.
Vier Routen, ein Token
| Route | Was sie beantwortet |
|---|---|
/api/controllers | welche Modelle geladen sind und den Zustand jeder Stage |
/api/runtime | die Betreiber-Wallet und die Maschinen dahinter |
/api/contributions | Zeilen, Einheiten, Anfragen und Durchsatz je Node |
/c/<model>/v1/chat/completions | Inferenz |
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.
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_formatbenannt. 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_contentzurück, getrennt voncontent, und respektiertenable_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.
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“.