LiteLLM comme AI Gateway distribué

Quand vous intégrez des LLMs dans votre produit, vous atteignez vite les rate limits du provider. Une seule clé OpenAI vous donne 1M TPM et 10K RPM. Si vous avez quelques utilisateurs intensifs qui traitent de gros documents, ce quota est parti en secondes.

La solution est le pooling. Vous provisionnez plusieurs clés API pour le même modèle et répartissez le trafic entre elles. Cinq clés vous donnent 5M TPM. Vous pouvez aussi mélanger les backends : OpenAI et Azure OpenAI sous le même alias gpt-5.2, pour qu'une requête vers gpt-5.2 atteigne le backend qui a de la capacité. C'est la raison principale pour laquelle les gens se tournent vers un gateway comme LiteLLM.

Mais le pooling introduit un problème d'état partagé. Si vous exécutez plusieurs nœuds de gateway derrière un load balancer, chaque nœud doit savoir combien de quota il reste à chaque clé. Si le Nœud A épuise une clé, le Nœud B doit le savoir immédiatement. Le tracking purement en mémoire locale ne fonctionne pas ici. Vous dépassez les limites du provider et vous obtenez des erreurs 429.

LiteLLM est écrit en Python. Cela porte l'overhead que le langage est connu pour avoir, mais son architecture est conçue pour l'état distribué. En séparant les données durables dans Postgres des compteurs chauds d'exécution dans Redis, LiteLLM réussit le test multi-nœuds là où d'autres échouent.

Configurer le pooling de clés en pratique

Configurer le pooling de clés dans LiteLLM est direct. Vous définissez une configuration de router qui regroupe plusieurs déploiements sous un seul nom de modèle, et vous leur assignez des limites.

Même provider, plusieurs clés :

model_list:
  - model_name: gpt-5.2
    litellm_params:
      model: openai/gpt-5.2
      api_key: sk-key-1
      tpm: 1000000
      rpm: 10000
  - model_name: gpt-5.2
    litellm_params:
      model: openai/gpt-5.2
      api_key: sk-key-2
      tpm: 1000000
      rpm: 10000

router_settings:
  routing_strategy: usage-based-routing-v2
  redis_host: os.environ/REDIS_HOST
  redis_port: os.environ/REDIS_PORT
  redis_password: os.environ/REDIS_PASSWORD
  enable_pre_call_check: true

Backends différents, même id de modèle. C'est utile quand vous avez OpenAI, Azure, OpenRouter et des déploiements Azure régionaux pour le même modèle et que vous voulez les traiter comme un seul pool :

model_list:
  - model_name: gpt-5.2
    litellm_params:
      model: openai/gpt-5.2
      api_key: sk-openai-key
      tpm: 1000000
      rpm: 10000
  - model_name: gpt-5.2
    litellm_params:
      model: azure/gpt-5.2
      api_base: https://my-deployment.openai.azure.com
      api_key: os.environ/AZURE_API_KEY
      tpm: 1000000
      rpm: 10000
  - model_name: gpt-5.2
    litellm_params:
      model: openrouter/openai/gpt-5.2
      api_key: os.environ/OPENROUTER_API_KEY
      tpm: 1000000
      rpm: 10000
  - model_name: gpt-5.2
    litellm_params:
      model: azure/gpt-5.2
      api_base: https://my-eu-deployment.openai.azure.com
      api_key: os.environ/AZURE_EU_API_KEY
      tpm: 1000000
      rpm: 10000

router_settings:
  routing_strategy: usage-based-routing-v2
  redis_host: os.environ/REDIS_HOST
  redis_port: os.environ/REDIS_PORT
  redis_password: os.environ/REDIS_PASSWORD
  enable_pre_call_check: true

Dans les deux setups, LiteLLM agit comme un load balancer intelligent. En configurant le router pour usage-based-routing-v2 et en donnant à router_settings accès à Redis, il utilise une implémentation asynchrone de Redis pour suivre l'usage global (redis.mget et redis.incr). Il évalue la capacité restante sur toutes les instances et route le trafic vers la clé API avec l'usage actuel le plus bas pour cette minute, en filtrant toute clé qui a dépassé ses limites de TPM/RPM.

Pourquoi le pooling se casse entre plusieurs nœuds

Si vous regroupez 5 clés API OpenAI sous un seul alias comme gpt-5.2, ces clés ont une contrainte de capacité combinée. Si le Nœud A épuise le quota d'une clé, le Nœud B doit le savoir immédiatement.

LiteLLM y parvient en se connectant directement à Redis pour créer des token buckets et des compteurs de requêtes centralisés. Quand une requête arrive :

1. Le Nœud A calcule les tokens requis et demande une réservation.
2. Redis incrémente le compteur global atomiquement.
3. Si le Nœud B traite une requête une milliseconde plus tard, il lit le compteur mis à jour depuis Redis avant d'envoyer son payload.

Cela résout le problème des requêtes chevauchantes. Bien qu'il reste une petite marge pour les race conditions (que LiteLLM reconnaît comme une dérive bornée), cette approche reposant sur Redis évite les explosions de budget massives qui se produisent avec un tracking purement en mémoire locale.

La philosophie d'architecture de LiteLLM

LiteLLM n'essaie pas d'être un nœud intelligent et isolé qui garde toute la vérité en mémoire locale. Il agit plutôt comme un « Distributed Executor ».

Il délègue la gestion d'état à des systèmes dédiés construits pour ce travail :

• Redis : Gère l'état rapide et éphémère (rate limits, cooldowns, compteurs de dépense en direct).
• Postgres : Gère l'état durable et relationnel (virtual keys, budgets, utilisateurs, équipes et logs permanents de dépense).

Cette philosophie signifie que vous pouvez déployer 10 instances de LiteLLM derrière un load balancer, et elles agiront comme un seul cluster proxy globalement coordonné, out of the box, sur le tier open-source. Pour l'activer, votre config.yaml pointe l'état durable vers Postgres et l'état du router vers Redis :

general_settings:
  master_key: sk-master-123
  database_url: "postgresql://user:pass@db:5432/litellm"

router_settings:
  redis_host: "redis-cluster.internal"
  redis_port: 6379
  redis_password: "redis-password"
  enable_pre_call_check: true

Partager les Virtual Keys en toute sécurité

Au-delà des clés de provider, LiteLLM permet de générer des Virtual Keys pour vos utilisateurs, équipes ou services internes.

Contrairement au piège multi-nœuds Postgres d'OSS Bifrost, plusieurs nœuds LiteLLM peuvent se connecter en toute sécurité à la même base de données Postgres. Quand une requête arrive avec une Virtual Key, LiteLLM authentifie la clé auprès de la base de données, vérifie le budget de l'utilisateur et met à jour le suivi de dépense comme un état durable partagé.

Comme la vérité vit à l'extérieur, vous pouvez créer par programme une Virtual Key via l'API, et chaque nœud LiteLLM de votre cluster la reconnaîtra instantanément. Voici un exemple de création d'une clé à portée dynamique pour une équipe spécifique avec un budget mensuel strict :

curl -X POST 'http://litellm-cluster:4000/key/generate' \
  -H 'Authorization: Bearer sk-master-123' \
  -H 'Content-Type: application/json' \
  -d '{
    "key_name": "marketing-team-prod",
    "models": ["gpt-5.2", "claude-3.5-sonnet"],
    "max_budget": 500.0,
    "budget_duration": "30d",
    "rpm_limit": 100,
    "metadata": {
      "team": "marketing",
      "environment": "production"
    }
  }'

Une fois générée, cette clé est instantanément valide sur tous les nœuds. L'API applique le max_budget en utilisant le grand livre durable de Postgres et applique le rpm_limit en utilisant les compteurs chauds de Redis.

Pourquoi ça compte pour votre architecture

LiteLLM n'est pas choisi simplement parce qu'il a une fonctionnalité de Virtual Key ; beaucoup de gateways l'ont. Il est choisi parce que son modèle d'état supporte nativement les Virtual Keys comme des sujets de budget globalement coordonnés dans des déploiements open-source multi-nœuds.

Quand la viabilité financière de votre application dépend du fait de ne jamais dépasser les rate limits d'un provider, et de ne jamais laisser un utilisateur dépasser son budget assigné, vous avez besoin d'un système qui respecte l'état partagé. LiteLLM fournit exactement cela.

Dans le prochain post, nous mettrons LiteLLM et Bifrost face à face pour vous aider à décider quelle philosophie d'architecture correspond le mieux à vos besoins d'infrastructure.