Bridge

La cara HTTP del motor de inferencia: qué está cargado, quién contribuyó y completions — y nada más.

El bridge es lo único con lo que el gateway de liquidación habla para inferir. Es un OUTER en términos de p4: instala una sesión a través de los stages del modelo, envía una petición al stage de cabeza, recoge el stream de tokens y reporta lo que aportó cada nodo. No posee colocación, ni planificación, ni más estado que un catálogo de lo que está cargado — deliberadamente pequeño, porque todo lo que no decide es algo que no puede derivar.

Todas las rutas salvo /api/health exigen un token de servicio compartido, enviado como X-Kvasir-Service-Token. Ese token es lo único que hay entre la internet abierta y el uso gratuito del anillo, y por eso el bridge escucha en loopback y se alcanza a través de un túnel en vez de publicarse.

• La plantilla de chat. p4 le entrega al stage server un prompt opaco y no aplica ningún formato de turno propio. El bridge renderiza el del modelo — leído del GGUF y nombrado en el catálogo como prompt_format. Sáltatelo y un modelo instruct continúa tu texto en vez de responderlo, nunca emite su token de fin de turno y llega al límite de tokens siempre.
• El bloque de razonamiento. Un modelo de razonamiento abre su respuesta pensando. El bridge devuelve eso como reasoning_content, separado de content, y respeta enable_thinking: false cerrando el bloque dentro del prompt — si no, una pasada larga de pensamiento puede consumir todo el presupuesto y entregarle a quien llama una respuesta vacía que ya ha pagado.

Pedirle al bridge que sirva un modelo devuelve 409. Qué capas van en qué GPU, y bajo qué load generation, sale de un plan de colocación que un operador escribió y cargó; no hay ninguna recarga remota que hacer. El watchdog de anillo del gateway lo aprende una vez y deja de preguntar, en vez de reintentar algo que no puede funcionar.