Bridge

Le visage HTTP du moteur d'inférence : ce qui est chargé, qui a contribué, et les complétions — et rien d'autre.

Le bridge est la seule chose à laquelle le gateway de règlement s'adresse pour l'inférence. C'est un OUTER au sens de p4 : il installe une session à travers les stages du modèle, soumet une requête au stage de tête, recueille le flux de tokens et rapporte ce que chaque nœud a contribué. Il ne possède ni placement, ni ordonnancement, ni autre état qu'un catalogue de ce qui est chargé — délibérément petit, car tout ce qu'il ne décide pas est autant qui ne peut pas dériver.

Toutes les routes sauf /api/health exigent un service token partagé, envoyé dans X-Kvasir-Service-Token. Ce jeton est la seule chose qui sépare l'Internet ouvert d'un usage gratuit de l'anneau : c'est pourquoi le bridge écoute sur la loopback et s'atteint par un tunnel plutôt qu'en étant publié.

• Le template de conversation. p4 transmet au stage server un prompt opaque et n'applique aucun format de tour qui lui soit propre. C'est le bridge qui rend celui du modèle — lu dans le GGUF et nommé prompt_format dans le catalogue. Sautez-le et un modèle instruct poursuit votre texte au lieu d'y répondre, n'émet jamais son token de fin de tour, et court jusqu'à la limite de tokens à chaque fois.
• Le bloc de raisonnement. Un modèle de raisonnement ouvre sa réponse en réfléchissant. Le bridge renvoie cela comme reasoning_content, séparé de content, et honore enable_thinking: false en fermant le bloc dans le prompt — sans quoi une longue passe de réflexion peut consommer tout le budget et rendre à l'appelant une réponse vide qu'il a déjà payée.

Demander au bridge de servir un modèle renvoie 409. Quelles couches se posent sur quel GPU, sous quelle load generation, vient d'un plan de placement qu'un opérateur a écrit et chargé ; il n'y a aucun rechargement à distance à effectuer. Le watchdog d'anneau du gateway l'apprend une fois et cesse de demander, plutôt que de réessayer une chose qui ne peut pas marcher.