Bridge

Het HTTP-gezicht van de inferentie-engine: wat er geladen is, wie heeft bijgedragen, en completions — en verder niets.

De bridge is het enige waar de verrekengateway voor inferentie mee praat. Hij is in p4-termen een OUTER: hij installeert een sessie over de stages van het model, dient een verzoek in bij de kopstage, verzamelt de tokenstroom en rapporteert wat elke node heeft bijgedragen. Hij bezit geen plaatsing, geen scheduling en geen staat behalve een catalogus van wat er geladen is — bewust klein, want alles wat hij niet beslist, kan ook niet afdrijven.

Elke route behalve /api/health vereist een gedeeld service-token, meegestuurd als X-Kvasir-Service-Token. Dat token is het enige dat tussen het open internet en gratis gebruik van de ring staat, en daarom bindt de bridge op loopback en wordt hij via een tunnel bereikt in plaats van gepubliceerd.

• Het chat-template. p4 geeft de stage-server een ondoorzichtige prompt en past geen eigen beurtformaat toe. De bridge rendert dat van het model — uit de GGUF gelezen en in de catalogus benoemd als prompt_format. Sla het over en een instruct-model zet je tekst voort in plaats van hem te beantwoorden, stuurt nooit zijn einde-beurt-token, en loopt elke keer tot de tokenlimiet.
• Het redeneerblok. Een redeneermodel opent zijn antwoord met denken. De bridge geeft dat terug als reasoning_content, los van content, en respecteert enable_thinking: false door het blok in de prompt te sluiten — anders kan een lange denkfase het hele budget opsouperen en de aanroeper een leeg antwoord geven waarvoor hij al heeft betaald.

De bridge vragen een model te serveren levert 409 op. Welke lagen op welke GPU zitten, onder welke load generation, komt uit een placement plan dat een operator heeft geschreven en geladen; er valt op afstand niets te herladen. De ring-watchdog van de gateway leert dat één keer en stopt met vragen in plaats van iets te blijven proberen dat niet kan werken.