Vos modèles derrière une seule surface, avec un budget qui tient.

La passerelle sert /v1/* sans contrat à écrire : les opérations intégrées ai.chatCompletions, ai.listModels et ai.embeddings répondent sous la section ai de flexway.yaml, avec la même identité, les mêmes politiques et la même trace que le reste du trafic. Les erreurs de /v1/* sont rendues dans l'enveloppe d'erreur OpenAI, refus de la passerelle compris, et en RFC 9457 partout ailleurs. Le streaming est relayé ligne à ligne, sans retenue, et le budget est réconcilié sur l'usage final.

Un backend se déclare par son genre : openai pour toute API compatible OpenAI (le défaut), relay pour une autre Flexway, grpc pour l'amont d'un modèle spécialisé. Aucun fournisseur n'est nommé dans le produit : un backend, c'est une URL, une authentification et un prix. L'authentification est générique - none, bearer par référence, header au nom déclaré, token_file relu à chaque appel comme le projette une identité de charge de travail - et un TLS client peut s'ajouter pour un relais en mTLS.

Le modèle demandé est servi s'il figure dans la liste models du backend, sinon c'est son default_model ; l'audit garde le modèle effectivement servi. Les configurations antérieures se chargent sans changement.

Un quota en requêtes par seconde ne dit rien du coût d'un appel à un modèle. Flexway compte en jetons par jour et par mois, et en euros par mois, par tenant : chaque backend déclare son prix (euros par million de jetons en entrée et en sortie), et le premier budget atteint décide. Chaque appel est pré-réservé puis réconcilié au prix du backend qui a réellement servi.

Au plafond souple (ai.budget.soft), la réponse porte l'en-tête Flexway-Budget: soft et le trafic bascule vers le backend déclaré, plus économique ; au plafond dur, la requête est refusée en 429 budget_exceeded. Un appel en échec ou refusé rend sa réservation, jetons et euros : un backend en panne n'épuise pas le budget d'un tenant. Des dérogations par tenant et par agent fixent un autre backend et d'autres budgets.

Derrière un relais vers une autre Flexway qui mesure elle-même (metering: upstream), le plafond local reste appliqué, le refus 429 de l'amont est relayé tel quel et les séries portent metered_by="upstream", pour qu'une consommation ne soit comptée qu'une fois là où elle est payée. flexway validate avertit d'un relais mesuré localement, qui compterait deux fois.

Une requête marquée sensible par l'en-tête déclaré (ai.sensitive_header) est épinglée sur le backend interne désigné (ai.sensitive_backend). Ce backend doit être interne : en déclarer un externe est refusé au chargement. S'il n'existe pas de backend interne capable de servir, la requête est refusée plutôt qu'envoyée dehors. L'en-tête ne peut que resserrer le routage, jamais l'élargir.

Un relais vers une autre Flexway est considéré comme externe sauf déclaration contraire (external: false) : seul l'exploitant décide qu'une autre passerelle peut recevoir le sensible. L'identité de l'appel lui est transmise sous les seuls noms déclarés (identity_headers : tenant, agent, sensible) ; rien de la requête de l'appelant n'est recopié. La bascule du plafond souple et les replis ne mènent jamais une requête sensible vers un externe.

Le choix du backend est déclaratif : défaut, puis dérogation du tenant et de l'agent, puis dérogation de capacité, puis sensibilité ; ni la latence, ni le contenu, ni le modèle demandé ne choisissent. Déclarer quel backend sert quels tenants vous aide à répondre à vos exigences de résidence des données ; le routage automatique par latence ou par juridiction est à venir.

Chaque backend déclare une liste de replis (fallback), essayée dans l'ordre sur erreur de connexion, 5xx, délai dépassé ou circuit ouvert. Le repli a lieu avant tout octet envoyé au client, chaque backend une seule fois. Il n'a jamais lieu sur un 4xx, y compris le 429 d'un fournisseur, et jamais vers un externe pour une requête sensible. La réponse servie par un repli porte Flexway-Degraded: backend-fallback.

Un coupe-circuit par backend évite d'insister sur un modèle qui ne répond plus. Le repli vaut pour les genres openai et relay et ne retient que les backends qui servent la capacité demandée : une requête avec image ne se replie que vers un backend vision. Le repli sur budget épuisé est le plafond souple, décrit plus haut.

Le routage conscient de l'inférence - selon le modèle, la criticité de la requête, la charge réelle du serveur de modèle ou l'affinité de cache de contexte, en s'interfaçant avec la Gateway API Inference Extension sur Kubernetes - est à venir. Le cache sémantique, opt-in par opération, est également à venir.

Chaque appel d'inférence produit une ligne d'audit en métadonnées : tenant, agent, modèle servi, backend, jetons, coût. L'invite et la réponse ne sont jamais collectées, et les identifiants sont hachés dans les journaux. La restitution par tenant, pour la facturation interne ou la refacturation, sort de cet audit sans outillage à côté.

Les mêmes faits alimentent les métriques flexway.inference.cost et flexway.inference.calls, avec les dimensions metered_by et capability, que la console lit pour ses jauges par tenant et par backend. Garder une trace exploitable de qui a appelé quel modèle, à quel coût, sans conserver le contenu, vous aide à répondre aux exigences de journalisation et de gouvernance des données qui s'appliquent aux usages de l'IA.

Le contenu d'un message peut être une chaîne ou des parties text et image_url, au format OpenAI. L'image est mesurée dans le corps sans être décodée (ai.vision.max_image_bytes, 8 Mio par défaut ; corps borné par ai.vision.max_body_bytes, 24 Mio par défaut) ; les URI data: sont admises par défaut, une URL distante seulement depuis une origine https déclarée (ai.vision.allowed_origins), et toute autre partie est refusée. Une image ne va qu'à un backend de capacité vision, sinon 400 capability_unavailable ; elle est pré-réservée à 2 048 jetons, réconciliés sur l'usage rendu.

POST /v1/embeddings suit le même chemin qu'une complétion : identité, budget sur prompt_tokens, repli avant tout octet, audit des métadonnées, et un backend de capacité embeddings. Une méthode gRPC d'un modèle spécialisé est mesurée quand elle porte l'option ai de (flexway.v1.operation), l'équivalent gRPC de x-flexway-ai : par appel (corps jamais lu) ou par octet, avec un prix pour mille et une fonctionnalité.

Pour ces modèles, le budget en euros du tenant est réservé avant l'appel et rendu si l'amont n'a pas servi ; les refus sont RESOURCE_EXHAUSTED budget_exceeded et PERMISSION_DENIED sensitive_no_internal_backend. Leur amont doit être nommé par un backend kind: grpc, sinon la configuration est refusée au chargement.