Le pooling de clés API avec Bifrost

Bifrost est un AI Gateway rapide basé sur Go. Si vous atteignez les rate limits de votre provider LLM et avez besoin de regrouper plusieurs clés API pour augmenter votre throughput, Bifrost fournit un moteur de routing natif et performant pour gérer l'équilibrage de charge.

Cependant, configurer le pooling de clés sur un seul nœud Bifrost est facile ; scaler cette configuration sur plusieurs nœuds en production nécessite une planification architecturale soignée pour éviter de dépasser les quotas du provider.

Voici exactement comment regrouper des clés API dans Bifrost et comment scaler cette configuration en toute sécurité.

1. Configurer le pooling de clés dans Bifrost

Bifrost permet de définir plusieurs clés API pour un seul provider et de leur assigner des poids. Le moteur de routing distribuera automatiquement les requêtes entrantes entre ces clés en fonction de leurs poids et de leur état de santé.

Pour un déploiement GitOps-friendly et stateless, on configure cela avec un fichier config.json monté dans le conteneur Bifrost.

{
  "$schema": "https://www.getbifrost.ai/schema",
  "providers": {
    "openai": {
      "keys": [
        {
          "name": "openai-key-primary",
          "value": "env.OPENAI_API_KEY_1",
          "models": ["gpt-4o", "gpt-4o-mini"],
          "weight": 0.7
        },
        {
          "name": "openai-key-secondary",
          "value": "env.OPENAI_API_KEY_2",
          "models": ["gpt-4o", "gpt-4o-mini"],
          "weight": 0.3
        }
      ]
    }
  }
}

Dans cette configuration, Bifrost agit comme un router intelligent. Il enverra environ 70 % du trafic à la clé primaire et 30 % à la clé secondaire. Si la clé primaire reçoit un 429 Too Many Requests d'OpenAI, la logique interne de Bifrost la marquera temporairement comme dégradée et routera le trafic vers la clé secondaire.

2. Exécuter la requête

Depuis votre code applicatif, vous traitez Bifrost exactement comme l'API OpenAI standard. Vous n'avez pas besoin de construire de logique de routing dans votre app.

Pointez simplement le baseURL de votre SDK vers votre instance Bifrost et fournissez une clé API factice (ou une Virtual Key si vous avez activé la gouvernance).

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: "vk-my-bifrost-key", // The gateway authenticates this
  baseURL: "http://localhost:8080/v1" // Pointing to Bifrost
});

const response = await client.chat.completions.create({
  model: "openai/gpt-4o",
  messages: [{ role: "user", content: "Analyze this dataset..." }]
});

Bifrost intercepte cette requête, sélectionne la clé API physique appropriée selon les poids dans config.json, l'attache aux headers et proxy la requête vers OpenAI.

3. Le piège du scaling multi-nœuds

Cette configuration fonctionne pour un seul nœud Bifrost massif. Le problème apparaît quand vous avez besoin de haute disponibilité et devez scaler vers plusieurs instances derrière un load balancer.

Dans Bifrost open-source (OSS), chaque nœud agit comme un moteur de décision indépendant.

• Le Nœud A charge le config.json et suit l'utilisation TPM/RPM de openai-key-primary dans sa mémoire locale.
• Le Nœud B charge le même config.json et suit sa propre utilisation locale.

Comme Bifrost OSS ne synchronise pas l'état d'exécution (comme les rate limits en direct ou les token buckets) entre les nœuds en temps réel, le Nœud A ne sait pas combien de tokens le Nœud B vient d'envoyer à OpenAI. Sous un trafic concurrent lourd, les nœuds dépasseront collectivement les limites physiques du provider, entraînant des erreurs 429 en amont et des requêtes abandonnées.

(Note : Bifrost propose un tier Enterprise payant qui utilise un protocole de consensus RAFT modifié pour synchroniser cet état, mais nous nous concentrons ici sur l'architecture OSS.)

4. Comment vraiment le scaler : Externaliser le Control Plane

Si vous voulez utiliser Bifrost OSS sur plusieurs nœuds sans dépasser les limites, vous devez adopter l'architecture à 3 couches. Vous devez retirer l'application "intelligente" des quotas de Bifrost et l'externaliser vers un Control Plane globalement coordonné.

Dans cette architecture, Bifrost est purement un moteur de routing et d'exécution. Il choisit la clé et fait l'appel réseau.

Pour appliquer les rate limits globaux, vous placez un système de quotas dédié (comme OpenMeter ou un Kong API Gateway avec rate limiting basé sur Redis) devant Bifrost.

Le flux :

1. Votre app envoie une requête à la couche Kong/Redis.
2. Le Control Plane vérifie Redis : Cet utilisateur/cette équipe a-t-il assez de capacité TPM globale sur toute notre infrastructure ?
3. Si oui, il décrémente le compteur global et transfère la requête au load balancer Bifrost.
4. Bifrost reçoit la requête, utilise ses poids internes pour choisir une clé API physique et exécute l'appel.

En séparant l'application globale des quotas dans Redis et le routing des clés physiques dans Bifrost, vous obtenez les performances du proxy Go de Bifrost tout en gardant vos rate limits solides à travers n'importe quel nombre de nœuds.

Dans le prochain post, nous verrons comment LiteLLM gère exactement ce problème, car il adopte une approche différente en intégrant Redis directement dans sa couche de proxy open-source.