Accueil / Articles / Phlox-GW : passerelle de LLM open source avec des budgets, des contraintes et une haute disponibilité

llm-gateway phlox openai anthropic observability self-hosted

Phlox-GW : passerelle de LLM open source avec des budgets, des contraintes et une haute disponibilité

Hébergez vous-même un gateway LLM avec des fonctionnalités de remboursement, des limites de débit, des mécanismes de protection des données personnelles, des journaux d’audit, des points d’accès OpenAI et Anthropic, ainsi que du clustering basé sur Postgres.

2581 mots

Les passerelles LLM open source proposent souvent des fonctionnalités « entreprise » — remboursements, budgets, SSO, mécanismes de contrôle, journaux d’audit, clustering haute disponibilité, limites de vitesse, routage — derrière une licence payante. Phlox-GW (Phlox Gateway) intègre ces fonctionnalités dans une passerelle entièrement open source conçue pour des infrastructures d’équipe auto-hébergées : une seule interface cohérente quel que soit le fournisseur, avec des points d’accès OpenAI et Anthropic ainsi que de la traduction de protocole, permettant à des outils comme Claude Code de communiquer avec des modèles provenant de différents systèmes d’exploitation.

Phlox-GW est un seul binaire en Go disponible pour macOS, Linux (y compris WSL) et Windows. Les déploiements de petite taille peuvent fonctionner avec une seule instance utilisant SQLite ; ceux de plus grande envergure s’adaptent à des clusters multi-nœuds utilisant PostgreSQL. Un projet associé, la Phlox AI Platform, peut être utilisé en complément de la passerelle lorsque l’on a besoin d’une interface de chat complète ; ce guide se concentre uniquement sur la passerelle elle-même.

Découverte de l’interface Phlox-GW

Panneau de contrôle des opérations

Les administrateurs consultent des chiffres globaux — utilisateurs, fournisseurs, clés API, événements, dépenses totales — ainsi que des graphiques sur trente jours concernant le coût quotidien, les tokens, les requêtes, les erreurs et la latence moyenne.

Surveillance des coûts et du budget

Des budgets mensuels sont associés aux personnes et aux départements. Les utilisateurs portent une étiquette de département afin que les dépenses soient regroupées. Dépasser un seuil d’alerte génère une notification ; atteindre la limite maximale bloque les modèles payants jusqu’au cycle suivant ou à une augmentation de la limite. Ce mécanisme de remboursement est l’une des principales raisons pour lesquelles les équipes préfèrent utiliser un passerelle plutôt que des clés de fournisseur brutes.

Limits de vitesse

Des limites s’appliquent au niveau de l’utilisateur, du département, du fournisseur ou du modèle, sous forme de requêtes par minute (RPM) et/ou de tokens par minute (TPM).

Disponibilité élevée et mise à l’échelle par clustering

Un seul processus Go sur PostgreSQL suffit déjà à grande échelle. Pour assurer la disponibilité ou gérer des milliers de sessions simultanées, ajoutez des instances partageant un même Postgres et placez un équilibreur de charge réseau en amont, équipé de vérifications d’état permettant d’éliminer les nœuds défectueux.

Audit

Les enregistrements d’audit captent les connexions et les actions de configuration : heure, auteur, action, cible, détails et adresse IP.

Journalisation respectueuse de la vie privée

Chaque appel au gateway enregistre des métadonnées — heure, identifiant de la demande, utilisateur, département, clé API, fournisseur, modèle, protocole, point de terminaison — sans conserver le contenu de la demande ni de sa réponse, ce qui permet de préserver la confidentialité des données tout en conservant un historique des incidents pour les équipes opérationnelles.

Règles de contrôle / Masquage et blocage des PII

Le middleware peut masquer ou bloquer les messages lorsqu’il détecte des motifs sensibles, que ce soit à l’entrée (pour empêcher les fuites vers les fournisseurs) ou à la sortie (pour éviter les fuites vers les clients), en fonction des paramètres de configuration.

Clés API en auto-service

Les utilisateurs connectés créent des clés nommées avec une date d’expiration optionnelle, les révoquent et consultent les dernières dates d’utilisation. Les administrateurs disposent d’une vue globale pour attribuer des budgets/limites et révoquer des clés. Tous les détails de la clé apparaissent une seule fois lors de sa création.

Surveillance de l’utilisation en auto-service

Chaque utilisateur peut consulter le nombre de ses requêtes, les tokens d’entrée/sortie, sa consommation ainsi que le détail des coûts par modèle, sans avoir à attendre une exportation financière.

Installation de Phlox-GW

Pour une évaluation sur poste de travail, le binaire est autonome et crée une base de données SQLite à la première exécution. La compilation depuis le code source nécessite une chaîne d’outils Go à jour ainsi que npm pour les ressources graphiques. Un démarrage typique se fait comme suit :

curl \
  --proto '=https' \
  --tlsv1.2 \
  -fsSL \
  https://raw.githubusercontent.com/robert-mcdermott/phlox-gw/main/install.sh \
  | sh

Créer un répertoire de données et lancer le service :

  mkdir -p "/Users/<your-username>/.local/share/phlox-gw"
  cd "/Users/<your-username>/.local/share/phlox-gw"
  phlox-gw

Pointez un navigateur vers l’interface utilisateur locale, créez le premier administrateur et continuez la configuration là-bas. Les installations en production définissent généralement des variables d’environnement pour le DSN de Postgres, l’adresse d’écoute, la terminaison TLS au niveau du load balancer ainsi que des secrets de session — consultez la documentation du répertoire pour obtenir la liste complète des variables.

Configuration de Phlox-GW

Aucun fichier de configuration obligatoire : les variables d’environnement ainsi que l’interface web suffisent pour la mise en place.

Ajout/configuration d’un fournisseur

Enregistrez chaque source (compatible OpenAI, Anthropic ou d’autres sources prises en charge) avec son URL de base et ses identifiants, stockés par le gateway et non sur chaque ordinateur portable.

Ajout et configuration d’un modèle

Associez les IDs des modèles fournisseurs à des noms utilisés par le gateway, indiquez les prix en cas de remboursement, et choisissez les pairs de routage/failover lorsque plusieurs backends peuvent servir le même modèle logique.

Tester un fournisseur et un modèle dans l’envoyeur de tests

L’envoyeur de tests intégré envoie une conversation d’essai via le chemin du fournisseur/modèle sélectionné, afin que les problèmes de connexion apparaissent avant que les clients ne soient redirigés vers le passerelle.

Ajouter des utilisateurs

Créez des comptes (ou connectez-vous via SSO/OIDC si c’est activé), attribuez des rôles et des départements, puis associez des budgets/limites.

Créer des budgets

Définissez des plafonds mensuels et des seuils d’alerte pour les personnes et les départements ; les modèles tarifés respectent ces limites au moment de la demande.

Utiliser Phlox-GW

Créer une clé API

Dans le panneau d’auto-service, générez une clé, copiez-la une fois, puis stockez-la dans le magasin de secrets du client.

Tester les points d’entrée de la passerelle

Exportez la clé :

export PHLOX_API_KEY="pgw-sk-<rest-of-your-api-key>"

Complétions de conversation compatibles avec OpenAI via la passerelle locale :

curl -Ns http://127.0.0.1:8080/v1/chat/completions \
  -H "Authorization: Bearer $PHLOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-ollama/glm-5.2:cloud",
    "messages": [{"role": "user", "content": "What is the capital of France?"}],
    "stream": false
  }'

Messages de style Anthropic via le point d’entrée traduit :

curl -sS http://127.0.0.1:8080/anthropic/v1/messages \
  -H "x-api-key: $PHLOX_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "local-ollama/glm-5.2:cloud",
    "max_tokens": 64,
    "messages": [{ "role": "user", "content": "What is the capital of Texas?" }]
  }'|jq

Utilisation de Claude Code avec Phlox-GW

Pointez Claude Code (ou un outil similaire) vers l’URL de base compatible avec Anthropic ainsi que la clé du gateway :

env \
  ANTHROPIC_BASE_URL="http://127.0.0.1:8080/anthropic" \
  ANTHROPIC_API_KEY="$PHLOX_API_KEY" \
  ANTHROPIC_MODEL="azure/gpt-5.5" \
  claude

La traduction des protocoles permet aux clients conçus pour Anthropic d’accéder à tout ce vers quoi le gateway redirige les requêtes.

Vérification de votre utilisation

Les utilisateurs mettent à jour les tableaux d’affichage relatifs aux tokens et aux dépenses ; les pics devraient correspondre à des tâches par lots connues ou à des agents qui fonctionnent de manière incontrôlée.

Surveillance de l’utilisation et des dépenses en tant qu’administrateur

Les administrateurs consultent les tableaux de bord du groupe, les résumés par département ainsi que les graphiques d’erreurs et de latence. Les dépassements de budget et les atteintes aux limites de vitesse constituent des événements opérationnels majeurs, et non simplement des surprises découvertes dans des tableurs.

Règles de sécurité – suppression des informations sensibles

Activez les modèles qui détectent des secrets, des identifiants personnels ou des noms de hôtes internes. Choisissez entre masquer ou bloquer les données pour chaque famille de modèles. Testez-les avec des échantillons synthétiques dans l’environnement de test avant de les appliquer au trafic en production.

Journalisation et audit

Journalisation des requêtes

Les journaux de requêtes ne contenant que des métadonnées permettent de gérer les incidents et les litiges liés aux remboursements sans conserver le texte des demandes privées.

Journalisation d’audit

Les événements de configuration et d’authentification répondent à la question « qui a modifié le routage hier ? » sans avoir besoin d’examiner les journaux de l’application.

Conclusion

Les paquets Phlox-GW regroupent les fonctionnalités de remboursement, de gestion des budgets, de limitations de débit, de contrôles, de traçabilité d’audit et de clustering en un seul fichier binaire ouvert, avec des interfaces pour OpenAI et Anthropic. Commencez par SQLite pour l’évaluation, passez à Postgres ainsi qu’à un NLB lorsque la disponibilité est cruciale, et conservez les identifiants du fournisseur ainsi que les politiques en un seul endroit, plutôt que dans des fichiers d’environnement dispersés sur des ordinateurs portables.

Checklist opérationnelle pour la première coupe de production : (1) tarifer chaque modèle généré afin que les budgets aient un sens, (2) attribuer aux utilisateurs des départements avant le premier cycle de facturation, (3) activer les journaux de demande de métadonnées et mener des audits dès le premier jour, (4) soumettre des échantillons de PII synthétiques aux mécanismes de contrôle intégrés, (5) mettre en place une paire de serveurs Postgres à deux nœuds avec un équilibrage de charge vérifié en continu avant d’assurer la haute disponibilité, et (6) documenter comment les clients Claude Code / SDK doivent définir l’URL de base et la clé afin que les solutions IT non officielles ne contournent pas le pare-feu avec des identifiants bruts du fournisseur. Réviser les limites RPM/TPM après une semaine d’activité réelle des agents — les premières valeurs sont presque toujours trop généreuses pour les cycles de travail intermittents et trop strictes pour les conversations interactives. Tenir un guide opérationnel pour la rotation des clés du pare-feu et des secrets des fournisseurs selon différents calendriers, afin qu’une seule fuite ne provoque pas deux pannes simultanées. Enfin, exporter les dépenses par département à intervalles réguliers, même si

Personne n’a encore demandé ; les services financiers interrogeront après la première facture surprenante, et le gateway dispose déjà des chiffres si les étiquettes ont été correctement définies.

Lorsque l’on passe à plus d’une équipe, il faut considérer le gateway comme une interface de produit : définir des politiques de routage par version, vérifier les pairs de secours en cas d’incident régional chez un fournisseur, et alerter en cas d’augmentation des erreurs 429 provenant de l’upstream, distinctement des limites imposées par le gateway. Le throttling de l’upstream et les plafonds définis localement exigent des réponses différentes — acheter de la capacité ou former un agent problématique. Associer les métriques Phlox-GW aux pages de statut des fournisseurs dans la même vue d’urgence permet aux opérateurs de ne pas diagnostiquer une « latence du gateway » qui est en réalité un problème de disponibilité dans une région spécifique. Avec ces bonnes pratiques, le gateway reste un plan de contrôle plutôt que simplement un proxy opaque supplémentaire.

Les SLO du service de passerelle de documents sont définis de la même manière que pour tout autre service périphérique : disponibilité des interfaces /v1 et /anthropic, latence p95 excluant le temps de traitement du modèle en amont lorsque c’est possible, ainsi que les taux d’utilisation par département. Ces trois graphiques permettent de détecter la plupart des signalements indiquant un problème avant qu’ils ne deviennent des discussions sur Slack.

Les objectifs de performance du gateway de documents sont définis de la même manière que pour tout autre service périphérique : disponibilité des interfaces /v1 et /anthropic, latence p95 excluant le temps de traitement du modèle en amont lorsque c’est possible, ainsi que des taux par département. Ces trois indicateurs permettent de détecter la plupart des signaux indiquant un problème avant qu’ils ne se transforment en discussions sur Slack.

Tous les articles Envoyer le brief