LiteLLM en arrière-plan : plan de contrôle du guichet d’IA multi-locataires
Abstraction du fournisseur, hiérarchie des locataires, budgets, politique de modèle, comptes de service, routage, observabilité, agents/MCP, et pourquoi le gateway constitue la voie critique.
Sources: LiteLLM Under the Hood: How to Build a Multi-Tenant AI Gateway for LLMs, Agents and MCP
Une passerelle unique. De nombreux fournisseurs. De nombreux utilisateurs. Un plan de contrôle pour l’accès à l’IA au sein de l’organisation.
Une simple invocation d’un modèle semble facile :
Application → OpenAI
Mais mettre en œuvre l’IA en production est plus complexe. Différents groupes préfèrent des fournisseurs différents. Les environnements de production exigent des politiques strictes concernant les modèles. Le service financier a besoin d’attribution des responsabilités. La sécurité nécessite un point unique pour accorder et révoquer les accès. Les équipes de plateforme ont besoin de mécanismes de limitation, d’acheminement, de basculement en cas de panne et de télémesure.
Sans une porte d’entrée commune, les connexions se dispersent :
Application A ──► OpenAI
Application B ──► Anthropic
Application C ──► Azure OpenAI
Application D ──► Vertex AI
Application E ──► Bedrock
Chaque produit doit alors reconstruire les mêmes infrastructures. La question importante n’est plus comment invoquer un modèle, mais plutôt comment gérer l’accès à l’IA en tant qu’infrastructure partagée.
La couche de passerelle de LiteLLM centralise le masquage des fournisseurs, les connexions, l’isolation des utilisateurs, l’autorisation d’accès, les plafonds de dépenses, les restrictions de fréquence, la redirection du trafic, les compteurs de consommation et la télémétrie opérationnelle. L’idée principale est de considérer l’accès aux modèles comme une ressource gérée au sein d’une plateforme, et non comme une requête HTTP brute émise par chaque application.
1. De la bibliothèque client au passerelle
LiteLLM a commencé en fournissant aux développeurs une seule interface pour interagir avec différents fournisseurs, afin que les équipes n’aient pas à mémoriser chaque SDK. À mesure que son adoption s’étend, cette abstraction seule ne suffit plus.
En l’absence de passerelle, chaque application doit encore se connecter directement aux fournisseurs :
┌──► OpenAI
│
Application A ──────┼──► Anthropic
│
└──► Vertex AI
┌──► OpenAI
│
Application B ──────┼──► Azure
│
└──► Bedrock
Cela signifie que chaque base de code doit gérer les identifiants, la configuration des modèles, les tentatives de réinitialisation, les mécanismes de basculement en cas de panne, les restrictions de fréquence, les compteurs de coûts et les journaux d’activité.
Une passerelle regroupe toutes ces fonctionnalités :
Applications
│
▼
┌─────────────────┐
│ LiteLLM │
│ AI Gateway │
└────────┬────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
OpenAI Anthropic Vertex
Les applications disposent d’un seul point d’entrée ; les ingénieurs de plateforme sont responsables de ce qui se trouve derrière lui. Partager ce point d’entrée en toute sécurité entre des équipes indépendantes devient alors le prochain problème de conception.
2. Multi-tenancy sans propriété partagée
Imaginons une entreprise dont la structure est la suivante :
10,000 developers
500 applications
50 teams
Multiple departments
Multiple LLM providers
Ils partagent un portail d’accès. Ils ne doivent pas partager des droits de modèle identiques, ni des budgets, des limites de débit, des pouvoirs d’administration ou des secrets.
LiteLLM exprime le concept de multi-tenancy sous forme d’une hiérarchie :
Organization
│
Team
│
User
│
Key
L’organisation constitue la limite d’isolation externe — unités commerciales, clients, départements, régions. L’équipe représente le locataire au quotidien, disposant de ses propres collaborateurs, administrateurs, budgets, mécanismes de limitation, listes d’autorisation des modèles et clés de service. L’utilisateur est une personne physique. La clé sert à authentifier l’appel et à le lier à l’identité ainsi qu’au contexte du locataire. Cette structure permet au portail d’accès d’avoir le contexte nécessaire pour appliquer les politiques définies.
3. Contexte pris en compte à chaque demande
Une appel en direct n’est pas seulement :
Prompt → Model
Il contient des métadonnées relatives à la propriété :
Request
│
┌─────────────┼─────────────┐
▼ ▼ ▼
User Team Key
│ │ │
└─────────────┼─────────────┘
▼
Tenant Context
│
▼
Authorization
│
▼
Budget Check
│
▼
Rate Limit
│
▼
Model Policy
│
▼
Routing
│
▼
Provider
│
▼
Usage + Cost
Au préalable du redirigement, le gateway peut déterminer qui a appelé, quelle équipe est responsable du trafic, si le modèle est autorisé, s’il reste un budget disponible, si l’appelant est soumis à des limites de fréquence, et quel déploiement doit répondre. La demande est évaluée, et non simplement transférée.
4. Budgets imbriqués
Un arbre de dépenses simple pourrait ressembler à ceci :
Organization $1,000,000
│
Engineering $600,000
│
Platform $200,000
│
Alice $10,000
L’argent possède désormais une structure. Les vérifications s’effectuent en fonction de plafonds imbriqués plutôt qu’à l’aide d’un seul budget global. Cela permet de gérer les budgets par équipe, les remboursements ou restitutions par département, les alertes, les travaux d’optimisation et des plafonds par personne. Les services financiers peuvent savoir combien la Plateforme a dépensé pour un modèle de fournisseur spécifique — et non seulement quel est le coût total des « IA ».
5. Accès aux modèles en tant que politique
Different groups need different catalogs:
Engineering
├── GPT
├── Claude
└── Gemini
Finance
└── Approved modelsDevelopment
├── Experimental models
└── Open models
Lorsqu’elles sont laissées seules, chaque application crée ses propres règles d’autorisation. Derrière un passage sécurisé :
Application
│
▼
LiteLLM
│
├── Authentication
├── Authorization
├── Model Policy
├── Budget
└── Rate Limit
L’application demande une capacité ; la plateforme l’accepte ou la refuse. La politique quitte alors l’application pour résider dans l’infrastructure — le même schéma est utilisé pour d’autres plateformes partagées.
6. Comptes de service pour les charges de travail
Un moyen discret consiste à lier le trafic en production à la clé d’une personne :
Production → Alice's API key
Lorsque cette personne part, la production ne doit pas cesser de fonctionner. Préférez une identité de charge de travail stable :
Production Application
│
▼
Service Account
│
▼
Production Team
Ce schéma convient aux services en production, aux pipelines CI, aux travailleurs automatisés, aux planificateurs, aux agents et aux tâches partagées. Gardez l’identité humaine séparée de l’identité de la charge de travail.
7. Acheminement et basculement en cas de panne en tant que responsabilités de la plateforme
Avec tout le trafic regroupé en un seul endroit, le choix du fournisseur peut être centralisé :
LiteLLM
│
┌─────────┼─────────┐
▼ ▼ ▼
OpenAI Azure Anthropic
Primary Backup Fallback
Les décisions peuvent tenir compte du modèle, de la disponibilité, du fournisseur, de la charge, de la latence, du prix et des signaux d’erreur. Les applications expriment l’intention ; le gateway choisit la mise en œuvre. Si un déploiement échoue, un autre cible configuré peut prendre le relais, sans que chaque équipe de produit doive écrire du code de basculement spécifique au fournisseur.
8. Télémétrie centrale et coûts
Un gateway partagé constitue une frontière naturelle pour la télémétrie :
LiteLLM
│
┌─────────┼─────────┐
▼ ▼ ▼
Logs Metrics Cost
│ │ │
└─────────┼─────────┘
▼
Observability
Les propriétaires de plateforme peuvent voir quelles équipes consomment le plus de tokens, quels modèles représentent la majeure partie des dépenses, quelles applications sont lentes, quels fournisseurs commettent des erreurs, et quelles équipes approchent des limites de budget — sans avoir à analyser des centaines de flux de logs d’applications.
9. Multi-locataires pour les produits SaaS
Même structure pour les solutions AI SaaS disposant de nombreux clients :
Customer A
Customer B
Customer C
Chaque client a besoin d’un usage isolé, de budgets distincts, de droits d’accès aux modèles et de identifiants propres. Sur le plan architectural :
SaaS Application
│
▼
LiteLLM Gateway
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Customer A Customer B Customer C
│ │ │
Budget Budget Budget
Models Models Models
Usage Usage Usage
Keys Keys Keys
L’infrastructure reste partagée ; les limites entre utilisateurs restent strictes. Telle est la promesse du multi-tenancy.
10. Les agents et le MCP augmentent les enjeux
Les applications simples ressemblent toujours à ceci :
Application → LLM
Les systèmes modernes ressemblent plutôt à ceci :
Application
│
├──► LLM
├──► Agent
└──► MCP Tool
Les agents peuvent appeler plusieurs modèles, invoquer des outils, interagir avec des systèmes externes et fonctionner plus longtemps qu’un seul échange de chat. À mesure que l’autonomie augmente, une gouvernance centralisée devient plus importante :
AI Consumers
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Apps Agents MCP
│ │ │
└──────────────┼──────────────┘
▼
LiteLLM Gateway
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Identity Policy Routing
│ │ │
└──────────────┼──────────────┘
▼
AI Providers
Décrire LiteLLM comme « simplement un proxy » sous-estime son rôle. Il commence à ressembler à un plan de contrôle pour l’IA.
11. Équilibre : le gateway constitue l’élément clé
Dès que tout passe par là :
Application
│
▼
LiteLLM
│
▼
Provider
Le gateway fait partie de l’infrastructure de production. Il nécessite une haute disponibilité, une capacité d’échelle horizontale, un stockage fiable, une gestion sécurisée des clés, un suivi en temps réel, des mécanismes de récupération en cas de catastrophe, une configuration minutieuse, des limites de charge appropriées et des politiques cohérentes. La centralisation permet une meilleure gouvernance mais crée également des dépendances — il faut le traiter comme une plateforme, et non comme un simple microservice.
Perspective globale
L’infrastructure d’IA évolue généralement par étapes :
Calling models
↓
Routing models
↓
Managing models
↓
Governing AI consumption
C’est aux stades ultérieurs que les gateways deviennent essentiels. Une plateforme future gère bien plus que simplement des points d’accès aux modèles :
Models
Agents
Tools
Identities
Credentials
Budgets
Policies
Usage
C’est au niveau du gateway que ces ressources se rencontrent.
Considerations finales
La description succincte de LiteLLM est « communiquer avec de nombreux fournisseurs de modèles via une seule interface ». Sa description plus détaillée correspond à un plan de contrôle permettant un accès géré aux technologies d’IA :
Provider Abstraction
+
Multi-Tenancy
+
RBAC
+
Budgets
+
Rate Limits
+
Routing
+
Cost Tracking
+
Observability
L’abstraction des fournisseurs constitue le point de départ. La multi-locataire, les budgets hiérarchisés, les politiques de modèle, les comptes de service, le routage, la bascule en cas de panne et une visibilité centralisée des coûts sont ce qui transforme une bibliothèque pratique en infrastructure de plateforme partagée. Construisez plutôt un modèle d’accès géré dans ce sens, plutôt que de laisser chaque application réinventer les mêmes mécanismes de contrôle.