La première fonctionnalité LLM part en production sous la forme d'un appel direct d'un service vers Bedrock. La dixième part de la même façon, depuis dix services, avec dix jeux d'identifiants, dix politiques de retry, et aucun endroit unique pour voir qui dépense quoi. C'est le moment où une équipe plateforme découvre qu'elle a besoin d'une passerelle LLM, généralement un trimestre après le moment où il aurait été bon marché d'en construire une. Une passerelle est la porte d'entrée partagée par laquelle passe chaque appel de modèle, et elle existe pour posséder les quatre choses que les équipes individuelles réinventent mal chacune de leur côté : authentification, quota, routage et audit.

Le recadrage utile, c'est qu'une passerelle n'est pas une fonctionnalité IA. C'est le même plan de contrôle que vous mettez déjà devant toute dépendance partagée, mesurée et coûteuse. Vous ne laisseriez pas chaque service porter son propre mot de passe admin de base de données et choisir sa propre limite de connexions. L'accès aux modèles n'est pas différent, sauf que la facture grimpe plus vite et que les modes de panne sont plus bruyants.

Ce que la passerelle centralise réellement

La valeur n'est pas dans le fait de proxifier la requête. Elle est dans le fait de posséder les quatre préoccupations transversales qui n'ont pas leur place dans le code applicatif :

  • Authentification. Les appelants présentent une identité de service à la passerelle. La passerelle détient l'identifiant unique qui parle à Bedrock. Aucune application ne voit jamais une clé de modèle à longue durée de vie, et faire tourner cette clé devient un seul changement, pas vingt.
  • Quota. Les budgets de tokens par équipe et par modèle vivent à un seul endroit. Une boucle incontrôlée dans un service atteint son propre plafond au lieu de consommer la limite partagée de tokens par minute et de throttler tout le monde d'autre.
  • Routage. La passerelle fait correspondre un nom de modèle logique à un déploiement concret : quelle région, quel fournisseur, quel repli quand le principal throttle. Les applications demandent « le résumeur », pas un ID de modèle précis dans une région précise.
  • Audit. Chaque requête et chaque réponse passent par un seul point de passage obligé, ce qui donne une seule couture sur laquelle accrocher l'attribution des coûts, la journalisation des prompts et la détection d'abus. Sans ça, le coût par fonctionnalité devient un projet d'archéologie.

Remarquez qu'aucun de ces points n'est un problème de qualité de modèle. Ce sont des problèmes de plateforme qui n'ont l'air nouveaux que parce que la dépendance est un modèle.

Build vs LiteLLM vs API Gateway

Il existe trois approches honnêtes, et la bonne dépend de la quantité de ce qui précède dont vous avez réellement besoin dès le premier jour.

Adopter LiteLLM (ou un proxy similaire)

Un proxy open source comme LiteLLM vous donne une API unifiée entre fournisseurs, des budgets par clé et un routage basique dès la sortie de la boîte. C'est le moyen le plus rapide d'obtenir une vraie passerelle qui connaît déjà les quatre préoccupations. Le compromis, c'est que vous exploitez et corrigez désormais un service à état qui se trouve sur le chemin critique de chaque fonctionnalité IA, et que ses partis pris sur le routage et la journalisation deviennent les vôtres. Pour la plupart des équipes qui mettent en place leur deuxième ou troisième fonctionnalité LLM, c'est le bon choix par défaut. Vous achetez le plan de contrôle au lieu de le construire.

La poser sur API Gateway plus Lambda

Si vous êtes déjà bien installés dans AWS, Amazon API Gateway devant un petit Lambda authorizer et une fonction proxy vous donne l'auth, les usage plans, le throttling et les journaux d'accès à partir de primitives que vous exploitez déjà. Les usage plans gèrent les limites de débit par clé, l'authorizer gère l'identité, CloudWatch gère la piste d'audit. Le coût, c'est que la logique spécifique au modèle, le streaming, le comptage de tokens et le repli entre fournisseurs deviennent du code que vous écrivez et possédez. Cette approche gagne quand vos exigences de gouvernance sont façonnées par AWS et que vous préférez étendre une plateforme existante plutôt qu'introduire une nouvelle dépendance.

Construire un service sur mesure

Construire le sien n'est justifié que lorsque vos exigences de routage ou d'audit sont vraiment inhabituelles : politiques de sélection de modèle complexes, décisions de résidence des données par requête, ou journalisation qui doit satisfaire un régulateur dans une forme précise. La plupart des équipes qui partent de zéro reconstruisent en réalité LiteLLM, en plus lent. Réservez cette option pour la fin, et seulement quand vous pouvez nommer l'exigence que l'option prête à l'emploi ne peut pas satisfaire.

Le mode de panne qu'une passerelle évite

Sans passerelle, la panne n'est pas spectaculaire, elle est lente. Les identifiants se dispersent. Chaque équipe fixe son propre timeout et son propre retry, si bien qu'un incident chez un fournisseur devient une tempête de retries qui vous fait dépasser votre quota de tokens. Personne ne peut répondre à « combien la fonctionnalité résumeur-support a-t-elle coûté le mois dernier » sans grepper des logs à travers les services. Puis une revue de sécurité demande qui peut appeler quel modèle avec quelles données, et la réponse honnête est « on n'est pas sûrs », qui est la réponse qui bloque un lancement.

Une passerelle transforme tout ça en configuration. C'est tout l'argument : sortir les décisions transversales de vingt bases de code pour les mettre dans une seule sur laquelle vous pouvez raisonner.

Tracer la ligne au bon endroit

Gardez la passerelle fine. Elle doit gérer l'identité, le quota, le routage et la journalisation, et rester à l'écart de la construction des prompts et de la logique métier. Au moment où la passerelle commence à posséder les prompts, elle devient une bibliothèque partagée avec un saut réseau en plus, et chaque équipe se retrouve bloquée par son cycle de release. La conception durable est un proxy ennuyeux avec des partis pris forts sur la gouvernance et aucun parti pris sur ce que vous demandez au modèle.

À retenir

Toute équipe plateforme qui livre plus d'une fonctionnalité LLM finit par construire une passerelle. Le seul choix, c'est de la construire délibérément, tôt, quand c'est encore un petit proxy, ou accidentellement, tard, comme projet de nettoyage après que les identifiants se sont dispersés et que la facture est devenue un mystère. Adoptez un proxy si vous le pouvez, étendez API Gateway si vous êtes natif AWS, et construisez sur mesure seulement face à une exigence que vous pouvez nommer. La passerelle n'est pas là où l'IA se passe. C'est là où la gouvernance dont vous alliez avoir besoin de toute façon trouve enfin un foyer.

À lire ensuite

Pour le côté plateforme et infrastructure de l'exploitation d'un plan de contrôle partagé comme celui-ci, les notes de terrain cloud vivent sur ercan.cloud, et le hub est sur ercanermis.com.