Comment arrêter d'écrire des adaptateurs pour les réseaux de neurones et reprendre le contrôle des coûts de tokens

Récemment, je réécrivais l'intégration de Claude vers un client mis à jour et je me suis surpris à réfléchir. Un jour, les clients demandent de connecter GPT-4o, le lendemain ils exigent Anthropic, et une semaine plus tard, le département financier demande d'où vient une facture de plusieurs centaines de dollars pour des tests. Chaque fois, je dois ajouter de la logique de gestion des erreurs, gérer les clés et calculer manuellement les dépenses en tokens.

Cette routine est résolue par LLM Gateway de l'équipe The Open Co. Le projet sert de passerelle API unifiée qui accepte les appels au format OpenAI standard et les route vers les fournisseurs appropriés.

Une requête pour n'importe quel modèle

Le concept principal est simple. Au lieu d'intégrer plusieurs SDK, vous envoyez une seule requête HTTP vers une passerelle locale ou cloud. Le contrôleur identifie automatiquement le fournisseur cible, transforme le format et renvoie la réponse.

Actuellement, les principaux fournisseurs sont pris en charge :

• OpenAI
• Anthropic
• Google Vertex AI
• Autres services avec des API compatibles

Voici à quoi ressemble une requête standard vers la passerelle :

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LLM_GATEWAY_API_KEY" \
  -d '{
  "model": "gpt-4o",
  "messages": [
    {"role": "user", "content": "Hello, how are you?"}
  ]
}'

Si vous devez passer à Claude 3.5 Sonnet, la structure JSON dans votre application reste la même. Seul le nom du modèle dans le corps de la requête change.

Suivi des coûts et métriques de latence

Lorsque plusieurs services ou développeurs travaillent avec des réseaux de neurones, le contrôle des limites devient difficile. Parfois, quelqu'un exécute un script avec une invite incorrecte dans une boucle infinie et brûle le budget d'un mois en une heure.

La passerelle prend en charge le suivi. Chaque transaction est enregistrée dans la base de données et le système calcule automatiquement :

• Le nombre de tokens d'entrée et de sortie
• Le coût total de chaque appel
• Le temps de réponse du modèle
• Les statistiques globales par clés et projets

Grâce au panneau web, vous pouvez consulter des graphiques prêts à l'emploi et voir immédiatement quel modèle spécifique consomme l'essentiel du budget.

Structure du projet et exécution dans Docker

Les auteurs ont construit un monorepo en TypeScript. Sous le capot, des technologies éprouvées sont utilisées :

• Hono gère le proxying des requêtes API
• Next.js gère l'interface web et le playground
• Drizzle ORM fonctionne avec les bases de données PostgreSQL et Redis
• TypeScript assure le typage de bout en bout des composants

Vous pouvez déployer votre propre service en quelques minutes via Docker. Les auteurs ont assemblé une image prête à l'emploi combinant les composants principaux.

docker volume create llmgateway_postgres
docker volume create llmgateway_redis

docker run -d \
  --name llmgateway \
  --restart unless-stopped \
  -p 3002:3002 \
  -p 3003:3003 \
  -p 3005:3005 \
  -p 3006:3006 \
  -p 4001:4001 \
  -p 4002:4002 \
  -v llmgateway_postgres:/var/lib/postgresql/data \
  -v llmgateway_redis:/var/lib/redis \
  -e AUTH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  -e GATEWAY_API_KEY_HASH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  ghcr.io/theopenco/llmgateway-unified:latest

Un petit détail de la documentation : ne montez pas un dossier de la machine hôte directement dans /var/lib/postgresql/data. En raison des spécificités de l'initialisation des permissions PostgreSQL dans le conteneur, le processus peut planter. Les volumes nommés dans la commande ci-dessus éliminent ce problème.

Si vous souhaitez essayer le système d'abord sans déploiement, les développeurs proposent une version cloud sur llmgateway.io.

Limitations de la version gratuite

Le dépôt utilise une double licence. Le code principal est distribué sous AGPLv3, cependant certains dossiers du code source appartiennent à la version Enterprise.

Dans la version open source gratuite, l'historique des appels est stocké pendant 30 jours. Si vous avez besoin d'une conservation illimitée des logs, d'une facturation utilisateur avancée ou d'une séparation des équipes au sein de votre organisation, vous devrez acheter une licence commerciale.

Qui bénéficiera de cet outil

Si votre application fait trois requêtes par jour vers un seul modèle, il n'y a pas d'intérêt à configurer un proxy séparé. Vous ajouterez simplement un point de défaillance supplémentaire et une latence réseau négligeable.

La passerelle prouvera son utilité dans les situations suivantes :

• Le projet utilise des modèles de différents fournisseurs
• Un suivi transparent des coûts de tokens sur différents services est requis
• Un déploiement proxy dans votre propre environnement est nécessaire
• Un basculement rapide vers un modèle de secours en cas de défaillance est prévu

Vous pouvez essayer le projet sur GitHub. Le README y est assez minimal, mais le projet est compréhensible même sans instructions détaillées.