Qu'est-ce qu'une passerelle LLM ? Explication simple
Une passerelle LLM est un point d'entrée unique entre votre application et une ou plusieurs API de modèles de langage. Cette page explique ce qu'elle gère, quand il est utile de l'ajouter et où se situe ce service.
Mis à jour le
Points clés
Vérifiez que l'endpoint respecte strictement le schéma de complétion de chat OpenAI pour une compatibilité prêt à l’emploi.
Assurez-vous que la taille de la fenêtre de contexte correspond aux besoins de mémoire de votre application pour éviter les erreurs de troncature.
Mettez en place le support du streaming pour gérer la latence des longues générations et améliorer l'expérience utilisateur.
Confirmez que les politiques de confidentialité correspondent à vos besoins de rétention des données, en particulier concernant le stockage des prompts.
La définition courte
Qu'est-ce qu'une passerelle LLM ? C'est un service ou un morceau de code qui se situe entre votre application et les API de modèles de langage. Votre application envoie chaque requête à une seule adresse, et la passerelle décide quoi en faire : vérifier qui demande, choisir un modèle ou un fournisseur, appliquer des limites, transférer l'appel, enregistrer ce qui s'est passé et renvoyer la réponse. L'application parle à une seule interface et ne se soucie pas de ce qui se trouve derrière elle.
L'idée est empruntée à la passerelle API utilisée dans les services web depuis des années. La différence est que le trafic est constitué d'appels de modèles, qui sont lents, facturés au token et souvent en streaming, donc une passerelle pour modèles de langage a quelques tâches qu'une passerelle normale n'a pas.
La plupart des passerelles exposent le même format de requête que celui utilisé par les SDK OpenAI. Ce choix est pratique. Presque toutes les bibliothèques clientes, frameworks et outils le comprennent déjà, vous pouvez donc placer une passerelle devant une application existante en changeant une seule URL de base.
Ce que fait une passerelle
Différents produits offrent différentes fonctionnalités, mais l'ensemble commun ressemble à ceci.
| Fonction | Ce que cela signifie en pratique |
|---|---|
| Gestion des clés | Les clés du fournisseur sont stockées à un seul endroit. Les applications et les collègues reçoivent leurs propres clés, que vous pouvez révoquer sans toucher au fournisseur. |
| Routage | Les requêtes sont envoyées vers un modèle ou un fournisseur choisi par règle : par tâche, par utilisateur, par coût. |
| Fallback | Si un backend échoue ou est lent, la requête est envoyée à un autre. |
| Limite de débit | Des plafonds par utilisateur ou par application empêchent un client de consommer toute la capacité partagée. |
| Réessais et délais d'expiration | Les erreurs temporaires telles que HTTP 429 sont réessayées à un seul endroit plutôt que dans chaque service. |
| Journalisation et suivi des coûts | Chaque requête est enregistrée avec les tokens, la latence et la dépense, afin que vous puissiez voir qui coûte quoi. |
| Mise en cache | Les requêtes identiques peuvent renvoyer une réponse mise en cache au lieu de payer deux fois. |
| Contrôles | Vérifications d'entrée et de sortie, comme la suppression des données personnelles avant qu'elles ne quittent votre réseau. |
Tous les projets n'ont pas besoin de toutes ces fonctionnalités. La valeur d'une passerelle augmente avec le nombre d'applications, d'équipes et de fournisseurs derrière elle. Avec un seul script et un fournisseur, elle ajoute une pièce mobile et peu de choses d'autre.
Quand en avoir besoin, et quand non
Un test utile est de compter la douleur que vous avez déjà. Une passerelle se rentabilise lorsque vous pouvez répondre oui à deux ou trois de ces questions.
- Plusieurs applications ou collègues partagent-ils le même compte fournisseur, et vous ne savez pas qui dépense quoi ?
- Avez-vous codé en dur les clés du fournisseur dans plus d'un dépôt ?
- Voulez-vous changer de modèle sans redéployer tous les services ?
- Avez-vous besoin d'une solution de repli automatique lorsqu'un backend renvoie des erreurs ?
- Devez-vous conserver un journal d'audit des prompts et des réponses ?
Si les réponses sont toutes non, passez à autre chose. Un seul bot ou outil interne nécessite une URL de base, une clé, un délai d'attente et une boucle de réessai. Vous pouvez toujours ajouter une passerelle plus tard, et comme le format de la requête est le même, le changement est minime. Ajouter une passerelle tôt vous donne surtout quelque chose de supplémentaire à faire tourner et à déboguer.
Où le coût apparaît
Une passerelle peut elle-même être un centre de coûts. Un proxy auto-hébergé nécessite un serveur, des mises à jour et de la surveillance. Un produit géré facture généralement des frais ou une marge sur les tokens ; vérifiez la tarification actuelle du produit que vous considérez. Comptez cela contre les économies de la mise en cache, du routage vers des modèles moins chers et de moins pannes avant de décider.
Trois façons d'en obtenir une
Écrivez une couche légère vous-même
Pour une petite équipe, cela suffit souvent. Une fonction wrapper qui ajoute un délai d'attente, réessaie les réponses 429 et 5xx, journalise l'utilisation des tokens de la réponse et sélectionne un modèle depuis un fichier de configuration fait environ cinquante lignes. Vous gardez le contrôle total et aucun service supplémentaire. Le coût est que vous le maintenez, et chaque nouveau besoin devient votre code.
Exécutez un proxy open-source
Plusieurs projets open-source offrent un proxy compatible OpenAI avec clés, budgets et routage. Vous l'hébergez, donc les prompts restent dans votre infrastructure. Vous prenez également en charge les mises à jour, les correctifs de sécurité et la disponibilité. Consultez la documentation de chaque projet pour les fonctionnalités qu'il prend en charge.
Utilisez une passerelle gérée
Un produit hébergé vous donne le tableau de bord et les logs sans serveurs à gérer. En échange, vous envoyez le trafic via un tiers et acceptez sa tarification, lisez donc sa politique de données avant d'envoyer des prompts sensibles.
Où ce service s'insère
Open LLM Gateway n'est pas un routeur entre fournisseurs. C'est une API hébergée compatible OpenAI pour un seul modèle à poids ouverts, gérée par un fournisseur indépendant et ajustée pour répondre sans refus de contenu pour une utilisation adulte légale. Ce n'est pas l'API officielle d'aucun fournisseur de modèle. L'ID de modèle est uncensored, et l'endpoint accepte POST /v1/chat/completions et GET /v1/models.
Cela en fait un backend propre pour une passerelle de votre propre cru. Si votre passerelle détient une liste de fournisseurs en amont, ajoutez celui-ci comme fournisseur en amont compatible OpenAI avec l'URL de base ci-dessous et envoyez-lui les requêtes qui nécessitent un modèle sans refus. Si vous n'avez pas de passerelle, vous pouvez l'appeler directement depuis votre application. Dans les deux cas, la configuration est la même.
from openai import OpenAI
client = OpenAI(
base_url="https://api.openllmgateway.com/v1",
api_key="YOUR_KEY",
)
resp = client.chat.completions.create(
model="uncensored",
messages=[{"role": "user", "content": "Explain what a gateway does in two sentences."}],
)
print(resp.choices[0].message.content)Il prend en charge le streaming via SSE, l'appel de fonctions, le mode JSON et les paramètres d'échantillonnage habituels. Il ne fait que du texte : pas d'images, audio, embeddings ou fine-tuning. Les prompts ne sont pas utilisés pour l'entraînement.
Ce à quoi planifier autour quand il est derrière votre passerelle
Parce que les limites sont des nombres fixes, une passerelle devant cette API peut les respecter dès le départ. Une clé complète permet 8 requêtes simultanées et 300 requêtes par minute. Une clé d'essai en permet 2 et 60. Au-delà d'une limite, l'API renvoie HTTP 429 avec le code rate_limited ou concurrency, et une surcharge temporaire vient avec un en-tête Retry-After: 5. Définissez la concurrence par upstream de la passerelle à 8 ou moins, et faites-lui honorer Retry-After.
Les réponses contiennent X-Request-Id et X-Balance-USD. Journalisez le premier pour le débogage et surveillez le second pour vous alerter avant que le solde ne soit épuisé. Une requête en streaming occupe sa place jusqu'à la fin du stream, donc une passerelle qui met les streams en mémoire tampon ou les laisse partiellement lus gaspillera de la capacité.
La fenêtre de contexte est de 100 000 tokens, prompt plus complétion, et le corps maximum est de 8 Mo. Si votre gateway ajoute un prompt système ou injecte de l'historique, comptez également ces tokens.
Pour les tarifs, les tokens sont à 0,15 $ par 1M en entrée et 0,50 $ par 1M en sortie, prélevés sur le crédit prépayé sans abonnement. Une gateway qui journalise l'utilisation des tokens simplifie les calculs. Une journée avec 3M de tokens en entrée et 500 000 tokens en sortie coûte 0,45 $ + 0,25 $ = 0,70 $. Les recharges vont de 20 $ à 500 $, avec +5 % à partir de 50 $, +10 % à partir de 100 $ et +15 % à partir de 200 $, par carte ou crypto. Les détails sont sur la page tarifs, et les requêtes échouées ou refusées ne sont pas facturées.
Étapes suivantes
Si vous décidez d'ajouter une passerelle à votre pile technique, consultez la checklist de production pour les passerelles IA pour les points à vérifier avant la mise en production. Pour tester l'endpoint lui-même, le démarrage rapide propose une modification client en trois lignes, et obtenir une clé prend une minute : inscrivez-vous avec Google ou avec un e-mail et un mot de passe, puis réclamez le crédit d'essai de 0,50 $ en un clic. L'essai est valable 7 jours, ne nécessite pas de carte et est limité à un par personne.
Commencez sans gateway si votre projet est petit. Ajoutez-en une lorsque le deuxième applicatif, le deuxième fournisseur ou la première demande d'audit arrive, et gardez la même interface pour que le changement vous coûte presque rien.
Plus de guides
Questions et réponses
Votre clé est à un formulaire de vous
Créez un compte, copiez la clé, modifiez l'URL de base. C'est toute la configuration.
Une gateway LLM est-elle la même chose qu'une API gateway ?
C'est une idée apparentée. Une gateway LLM est conçue pour le trafic de modèles, elle suit les tokens, gère le streaming et peut router entre des modèles ou des fournisseurs.
Open LLM Gateway est-il un routeur pour plusieurs fournisseurs de modèles ?
Non. C'est une API compatible OpenAI hébergée pour un seul modèle à poids ouverts, model ID uncensored, gérée par un fournisseur indépendant. Il peut s'agir d'un seul upstream derrière votre propre gateway.
Ai-je besoin d'une gateway pour un petit projet ?
Généralement non. Une base URL, une clé, un timeout et une boucle de retry suffisent jusqu'à ce que plusieurs applicatifs, collègues ou fournisseurs partagent la configuration.
Quel format de requête utilisent les gateways ?
La plupart utilisent le format de complétions de chat OpenAI, donc les SDK existants fonctionnent après avoir modifié la base URL et la clé. Cette API utilise le même format.
Quelles limites ma gateway doit-elle respecter pour cette API ?
Une clé complète permet 8 requêtes simultanées et 300 par minute, et une clé d'essai en permet 2 et 60. Respectez l'en-tête Retry-After sur les réponses 429.
