LLM Proxy ou AI Gateway : architecture, contrôle et compromis

Un proxy LLM et une AI gateway peuvent se trouver au même endroit entre une application et les fournisseurs de modèles, sans assumer les mêmes responsabilités. Le proxy transporte avant tout les requêtes et les réponses. L’AI gateway ajoute généralement des contrôles sensibles au modèle : politique de routage, fallback, suivi d’usage, attribution des coûts et règles d’accès par workload.

Ces termes ne constituent pas des normes. Certains produits appellent « proxy » une véritable couche de contrôle des modèles, tandis que d’autres utilisent « gateway » pour désigner un simple endpoint managé. Il faut donc comparer des responsabilités vérifiables, pas des étiquettes.

Commencer par les responsabilités, pas par le nom

Les deux couches occupent souvent la même position réseau :

Application ou agent de code
        ↓
Proxy LLM ou AI gateway
        ↓
Fournisseur et modèle sélectionné

Ce schéma ne montre pas ce que fait réellement la couche intermédiaire. Une matrice de responsabilités est plus informative.

Responsabilité	Proxy LLM orienté transport	AI gateway sensible au modèle
Terminaison TLS et transfert HTTP	Courant	Courant
Gestion des URL et headers upstream	Courant	Courant
Transfert des réponses en streaming	Fréquent	Généralement, mais le contrat d’événements reste à vérifier
Isolation des credentials fournisseur	Parfois	Courante, avec des limites de stockage et d’accès à contrôler
Interface OpenAI-compatible	Parfois	Courante, mais variable selon le modèle et la fonction
Routage par modèle ou fournisseur	Limité ou géré par l’application	Courant
Retry et fallback ordonné	Au mieux, retry upstream basique	Souvent adapté au modèle et au type d’erreur
Rate limit ou quota par workload	Généralement externe	Courant
Données de tokens, usage et coût	Généralement externes	Courantes
Diagnostic de latence par requête	Généralement externe	Courant
Politiques et audit	Généralement externes	Dépend du produit

« Courant » ne signifie pas garanti. Pour chaque responsabilité critique, exigez le contrat exact, le comportement en cas d’échec, les données enregistrées et les contrôles offerts aux opérateurs.

Ce que prend normalement en charge un proxy LLM

Un proxy orienté transport peut suffire lorsque l’objectif principal est de placer un endpoint stable devant une API upstream. Il peut centraliser TLS, hostname, headers, limites de taille, timeouts et logs de base. S’il comprend Server-Sent Events, il peut également transférer le streaming sans bufferiser la réponse complète.

Cette infrastructure crée un chemin réseau contrôlé et peut empêcher l’exposition des clés fournisseur dans certains clients. Elle fournit aussi un emplacement logique pour l’authentification classique et les règles réseau.

La frontière change dès que le proxy traduit les formats, choisit les fournisseurs, compte les tokens ou calcule les coûts. Ces comportements sont liés au modèle. Il faut alors l’évaluer comme une gateway, même si son nom commercial reste « proxy ».

Un proxy simple est adapté lorsque :

• une application utilise un fournisseur et quelques modèles fixes ;
• l’application gère déjà les retries, l’usage et le diagnostic d’incident ;
• les fonctions natives du fournisseur doivent traverser la couche sans traduction ;
• aucune politique par équipe ou workload n’est nécessaire ;
• l’équipe recherche la plus petite couche opérationnelle possible.

Ce qu’ajoute une AI gateway

Une AI gateway ne traite pas une requête de modèle comme du simple trafic HTTP. Elle peut intégrer le modèle demandé, le protocole, la politique de la clé, la disponibilité des groupes, les limites et les résultats des tentatives précédentes dans la décision de routage. Elle peut ensuite relier la tentative finale aux tokens, timings, statuts et coûts.

Les fonctionnalités diffèrent selon les produits. La documentation Cloudflare AI Gateway réunit analytics, logging, cache, rate limiting, retries et fallback. La documentation des métriques Kong AI Gateway décrit les métriques de modèle, tokens, coût, cache, latence et erreur. Ce sont des exemples, pas une définition universelle.

Une gateway devient utile lorsque plusieurs besoins apparaissent ensemble :

• plusieurs applications ou agents nécessitent des API Keys et un usage attribuables séparément ;
• plusieurs routes éligibles peuvent servir le même modèle demandé ;
• les limites doivent s’appliquer avant le travail et le coût upstream ;
• il faut distinguer authentification, routage, attente upstream, première sortie effective et génération ;
• chaque charge doit être explicable au niveau de la requête ;
• une politique de fallback explicite et ordonnée est requise ;
• plusieurs groupes de modèles doivent partager une vue opérationnelle.

Une gateway ne rend pas tous les fournisseurs interchangeables. Elle ne remplace ni la validation des sorties, ni l’idempotence des outils, ni la protection des secrets dans l’application, ni les tests des fonctions natives.

Utiliser une matrice par workload

Workload	Besoin principal	Couche de départ raisonnable	Pourquoi
Service interne avec un fournisseur et un modèle	Chemin réseau stable	API directe ou petit proxy	Une politique avancée peut ajouter plus de complexité que de valeur
Application client avec plusieurs routes pour le même modèle	Disponibilité et preuve des tentatives	AI gateway	Routage, fallback borné et diagnostic nécessitent un propriétaire commun
Agents de code pour toute une équipe	Keys, quotas, attribution et offboarding	AI gateway	Une clé partagée et des dépenses non attribuées créent un risque opérationnel
Application utilisant une nouvelle fonction native	Wire Contract exact	Endpoint natif, puis couche vérifiée	Une API normalisée peut omettre ou prendre du retard sur de nouveaux champs
Traitement batch avec queue et retries propres	Débit et reprise par l’application	Proxy/gateway avec retries désactivés ou bornés	Plusieurs couches de retry amplifient les pannes et dupliquent le travail
Workload réglementé ou sensible	Preuve du chemin, de la rétention et des accès	Selon les contrôles démontrés	Le mot « gateway » n’est pas une preuve de sécurité ou de conformité

Le choix peut évoluer. Commencer avec un fournisseur puis introduire une gateway est raisonnable si le client de modèles reste derrière une interface interne claire et si le contrat de migration est testé.

Prendre en compte les compromis cachés

Mesurer le saut supplémentaire

Un proxy ou une gateway ajoute du réseau et du traitement. Une moyenne de latence est insuffisante : mesurez l’arrivée des headers upstream, la première sortie effective, le premier texte visible, la durée totale et la vitesse de sortie à une concurrence réaliste. Un faible coût fixe peut être compensé par une meilleure reprise opérationnelle, mais cela dépend du workload.

La compatibilité est propre à chaque fonction

« OpenAI-compatible » peut ne couvrir que la Base URL, le header d’authentification et un appel Chat Completions. Responses Events, Structured Outputs, Tool Calls, champs d’usage et erreurs peuvent différer. Testez chaque fonction utilisée. Le guide OpenAI-Compatible API fournit une base de migration et Responses API vs Chat Completions explique pourquoi l’endpoint ne suffit pas à prouver la compatibilité.

La centralisation crée un domaine de panne

Centraliser Keys, routage, limites et logs simplifie la responsabilité, mais rend cette couche critique. Vérifiez le versioning et le rollback de la configuration, le comportement lors d’une indisponibilité du control plane et la terminaison des requêtes en cours pendant un changement.

Le coût exige une source de vérité

Certaines gateways utilisent les tarifs publics, d’autres des prix configurés, des multiplicateurs de groupe ou des Billing Expressions versionnées. Il faut savoir quand le prix est choisi et figé, comment sont représentés les Cached Tokens et les outils, et si le montant final peut être rapproché de l’usage. Voir AI API Cost Tracking.

Le coût de sortie compte aussi

Avant d’adopter une interface normalisée, repérez les dépendances aux headers exclusifs, alias de modèles, noms de routes et APIs de logs. La couche doit faciliter les opérations sans empêcher un retour au protocole natif.

Trois exemples pratiques

Assistant interne avec un fournisseur

Un assistant interne envoie des requêtes non streaming à un modèle fixe. L’application conserve ses propres Job IDs et une clé fournisseur côté serveur. Un proxy conventionnel peut suffire : le routage multi-fournisseur ne résout pas encore de problème concret. Une interface interne pour le client modèle préservera la possibilité d’ajouter une gateway plus tard.

Application de production à plusieurs routes

Si le même modèle doit rester disponible lorsqu’un compte upstream est saturé et si l’équipe doit savoir quelle route et quelle tentative ont généré le coût, une gateway est adaptée. Fallback, facturation et diagnostic doivent partager la même identité de requête. Le remplacement par un autre modèle modifie qualité, latence, outils et prix ; il doit être explicite. Consultez le guide de routage fiable des AI API.

Agents de code dans une équipe

Les agents créent de longues sessions riches en outils depuis de nombreuses machines. Une clé fournisseur partagée complique quota, attribution, rotation et départ des collaborateurs. Une gateway peut émettre des clés par workload et associer l’usage à une équipe ou un projet. Les droits du repository, le sandbox, l’approbation des outils et la validation du code restent hors de la couche de routage.

Où se situe Modelflare

Modelflare vise une couche d’accès et de routage sensible à l’AI, et non un simple relay HTTP transparent. Une API Key classique peut choisir un groupe principal et des groupes de fallback ordonnés. Une Smart API Key peut évaluer les groupes éligibles selon sa stratégie. Dans les deux cas, le système cherche une route pour le modèle demandé, sans le remplacer silencieusement.

Le Group RPM est appliqué au groupe concret avant la facturation et avant l’appel upstream. Si le groupe est saturé, le groupe éligible suivant peut être examiné ; sans route restante, la réponse est 429. Les Usage Logs relient statut, tokens, coût et timings et distinguent authentification, choix du groupe, headers upstream, premier événement, première réponse effective, premier texte visible et durée totale.

La compatibilité a une limite claire : le trafic GPT, Codex et OpenAI est la cible entièrement adaptée. Les autres familles OpenAI-compatible doivent être considérées comme du Chat Completions pass-through tant que leurs comportements supplémentaires n’ont pas été vérifiés. Une Base URL partagée ne garantit pas le même contrat pour Responses, Tools ou Structured Outputs.

Consultez Models & Pricing pour les modèles et groupes proposés et la documentation Modelflare pour la configuration des clients.

Checklist d’évaluation en production

• Protocole : les formes de requête et de réponse utilisées sont-elles préservées ?
• Streaming : les événements et Tool Arguments sont-ils transmis sans buffer, perte ou réordonnancement ?
• Identité du modèle : un changement de route conserve-t-il le modèle demandé ?
• Fallback : quels échecs sont éligibles, combien d’essais ont lieu et où s’arrêtent-ils ?
• Limites : rate et quota sont-ils appliqués avant le travail upstream et la facturation ?
• Usage et coût : tokens et montant final sont-ils liés à la route et au prix réels ?
• Diagnostic : temps gateway, attente upstream, première sortie et génération sont-ils séparés ?
• Secrets : qui peut lire les credentials et le contenu des requêtes ?
• Change Control : les politiques peuvent-elles être revues et annulées ?
• Exit Path : peut-on revenir à un endpoint natif sans réécrire l’application ?

Testez avec le même modèle, la même classe de prompt, la même longueur, le même mode streaming, les mêmes outils, la même région et une concurrence réaliste. Un « Hello World » réussi ne prouve que la connectivité.

Questions fréquentes

Tout proxy OpenAI-compatible est-il une AI gateway ?

Non. La compatibilité décrit une partie de l’API ; une gateway décrit des responsabilités opérationnelles. Un proxy peut proposer le format sans contrôler routage, coût, limites ou diagnostic.

Une AI gateway supprime-t-elle les clés fournisseur ?

Pas nécessairement. Elle peut stocker les credentials, accepter le BYOK ou gérer sa propre facturation. Vérifiez leur emplacement et les droits d’usage ou d’export.

Une AI gateway accélère-t-elle les requêtes ?

Pas automatiquement. Elle ajoute un saut, mais peut améliorer disponibilité et diagnostic. Mesurez la timeline complète du workload.

Le fallback doit-il choisir un autre modèle ?

Uniquement si l’application accepte explicitement les changements de qualité, compatibilité, latence et prix. Par défaut, choisissez une autre route éligible pour le même modèle et le même protocole.

La distinction pratique est simple : utilisez un proxy pour contrôler principalement le transport ; utilisez une AI gateway quand routage, politique, usage, coût et preuves doivent avoir un responsable commun. Le nom du produit, à lui seul, ne constitue aucune preuve.