GPT-Load : une passerelle auto-hébergée pour empiler les clés et les comptes d'abonnement

Le problème : une clé par outil, un compte par quota

Un client qui parle à plusieurs fournisseurs finit par gérer autant de configurations que de services. Chaque outil garde sa propre URL de base, son propre jeton, ses propres règles de nouvelle tentative. Quand une clé atteint son quota, la bascule se fait à la main. GPT-Load prend le problème par l'autre bout : l'application ne connaît qu'une URL de base et une AccessKey, et tout le reste (fournisseurs, comptes, identifiants, modèles, politique de routage) se configure dans une interface d'administration. Le README résume la cible en une phrase : « One gateway, native protocols ». Les clients conservent leurs interfaces natives OpenAI, Anthropic ou Gemini, ce qui évite de réécrire du code côté appelant. Le projet vise donc les équipes qui ont déjà accumulé des clés API et des comptes d'abonnement, pas le développeur qui interroge un seul fournisseur avec un seul jeton.

Ce qui se passe entre l'AccessKey et le fournisseur

La chaîne de configuration compte trois objets, dans cet ordre : un canal, un groupe, une AccessKey. Un canal désigne un service amont et porte un ou plusieurs identifiants. Un groupe sélectionne un canal, puis fixe les modèles disponibles et la politique d'exécution. Une AccessKey déclare les groupes et les protocoles client qu'elle peut utiliser. C'est cette AccessKey, et non la clé du fournisseur, qui part dans l'application. Le README décrit une mécanique unique pour les clés API et les comptes d'abonnement : Codex, Claude, Antigravity, Grok et les canaux à clé partagent la gestion des identifiants, l'ordonnancement et le suivi de santé. Les identifiants sont chiffrés localement, et l'interface intégrée expose l'état de santé, les routes, les journaux, l'usage et une estimation de coût. Le routage s'appuie sur des pondérations configurables, des nouvelles tentatives, une mise en veille, une liste noire et une affinité de session. Cette dernière notion mérite attention : elle implique qu'une même session peut être ramenée vers le même identifiant, ce qui n'est pas anodin pour un fournisseur qui facture ou limite par compte.

Démarrage : trois commandes, puis trois étapes dans la console

Le README donne la séquence complète. Il faut Docker et Docker Compose, puis : git clone --depth 1 https://github.com/tbphp/gpt-load.git, cd gpt-load, cp .env.example .env, docker compose up -d. La vérification se fait avec curl --fail http://127.0.0.1:3001/health. Au premier démarrage, une clé d'administration est générée et se lit avec docker compose exec gpt-load sh -c 'cat /app/data/auth.key'. On peut aussi fixer AUTH_KEY dans .env avant le lancement. Par défaut, le service n'écoute que sur l'adresse de bouclage. Ensuite, trois étapes dans la console : ajouter un canal avec une ou plusieurs clés, créer un groupe en choisissant les modèles et la politique, puis générer une AccessKey. Les canaux à abonnement demandent un flux OAuth ou un import d'identifiants. Point pratique souvent découvert trop tard : les clients OAuth Codex, Claude et Antigravity utilisent des ports de rappel fixes, publiés par Compose sur l'adresse définie par HOST (127.0.0.1 par défaut). Comme ces ports sont imposés par les clients amont, une seule instance Compose par défaut peut tourner sur une machine à la fois. En SSH ou depuis un navigateur distant, le localhost du navigateur peut ne pas joindre GPT-Load, et il faut coller l'URL de rappel complète dans la boîte de dialogue d'autorisation.

La 2.0 ne reprend pas les données de la 1.x

L'avertissement en tête du guide de démarrage est explicite : si vous utilisez la 1.x, lisez d'abord la section de migration, car la 2.0 ne peut ni ouvrir, ni importer, ni migrer les données 1.x sur place. Ce n'est pas une réserve de forme, c'est une contrainte d'exploitation : une instance 1.x ne se met pas à niveau, elle se remplace. Les releases publiées au moment de la rédaction sont des candidates : v2.0.0-rc.11, rc.10, rc.9, étalées sur trois jours. Une série de RC qui avance à ce rythme signale un projet en stabilisation, pas une base figée. Autre point à trancher avant de s'engager : le README mentionne SQLite, MySQL et PostgreSQL comme backends, sans détailler dans le texte fourni les critères de choix ni les implications de bascule d'un moteur à l'autre. Pour un déploiement mono-instance, SQLite est le chemin le plus court ; pour plusieurs instances derrière un répartiteur, la question du moteur partagé devient structurante et la documentation disponible ici ne la traite pas.

Ce que l'interface montre, et à qui elle s'adresse

Les captures listées dans le README couvrent quatre écrans : groupes, comptes d'abonnement, accueil AccessKey en lecture seule, usage et coût. Le troisième est le plus intéressant du point de vue de la délégation. Se connecter avec une AccessKey donne accès uniquement à ses propres groupes, modèles, requêtes, usage et enveloppe de coût. Autrement dit, on peut remettre une AccessKey à un utilisateur ou à un service sans lui donner la console d'administration. Le quatrième écran affiche les tendances de requêtes, le taux de succès du cache, les catégories de jetons et une estimation de coût. Cette estimation reste une estimation : le README ne décrit pas de table de tarifs ni de méthode de calcul, et une passerelle ne peut estimer un coût qu'à partir de ce qu'elle observe. Si votre facturation doit être exacte, elle ne peut pas reposer sur cet écran seul.

LiteLLM comme alternative, et la vraie différence

LiteLLM est l'alternative la plus directement comparable : une passerelle qui expose une API compatible OpenAI devant de nombreux fournisseurs, avec suivi de budget et de clés. La différence d'approche est nette. LiteLLM normalise vers un format unique, ce qui simplifie le code client mais impose une traduction à chaque requête. GPT-Load revendique l'inverse : garder les protocoles natifs OpenAI, Anthropic et Gemini côté client, et se placer en amont des fournisseurs sans reformater les échanges. Le README liste d'ailleurs les points d'entrée pris en charge, dont POST /v1/chat/completions, /v1/responses et ses chemins de ressources, POST /v1/images/..., POST /v1/embeddings et POST /v1/rerank. La liste fournie est tronquée après « A », donc je ne peux pas affirmer quels autres protocoles sont couverts. Le second écart tient à la gestion des abonnements : GPT-Load traite les comptes OAuth Codex, Claude et Antigravity avec les mêmes primitives que les clés API, là où un proxy de normalisation raisonne d'abord en termes de modèles et de budgets. Si votre besoin est de faire parler un seul format à dix fournisseurs, la normalisation est un avantage. Si vos clients utilisent déjà les SDK natifs, elle devient une couche de traduction à maintenir.

Coût de maintenance et licence

Le projet est écrit en Go, sous licence MIT. Cette licence autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de licence ; elle s'accompagne d'une clause de non-garantie. Ce n'est pas un avis juridique : si vous redistribuez GPT-Load dans un produit, faites relire les termes. Côté exploitation, la maintenance se concentre sur trois postes. Les identifiants chiffrés localement et la clé d'administration générée au premier démarrage doivent être sauvegardés : perdre /app/data/auth.key signifie perdre l'accès à la console. Les ports de rappel OAuth fixes limitent à une instance Compose par défaut par machine, ce qui complique les environnements de recette et de production sur un même hôte. Enfin, suivre une série de release candidates implique de relire les notes de version à chaque montée, puisque le README ne promet aucune compatibilité de données entre 1.x et 2.0. Le dépôt n'est pas archivé et la dernière poussée est datée du 9 septembre 2026, ce qui indique un projet actif, sans préjuger de la stabilité de l'API.

Conclusion éditoriale

GPT-Load convient aux équipes qui accumulent déjà plusieurs clés API ou comptes d'abonnement et veulent un point d'entrée unique avec journalisation et estimation de coût. Il ne convient pas à qui cherche une passerelle stable en production aujourd'hui : la branche publiée est une série de release candidates 2.0.0-rc.x et, comme l'indique l'avertissement du README, la 2.0 ne peut ni ouvrir, ni importer, ni migrer les données 1.x. Avant de vous engager, vérifiez le contenu de .env.example, les ports de callback OAuth publiés par Compose et le backend de base de données que vous comptez utiliser.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. tbphp/gpt-load on GitHub