Connectez vos applications à plusieurs fournisseurs via une passerelle IA auto-hébergée ou le SDK Python. Gérez clés virtuelles, routage, utilisation et budgets, avec gouvernance Enterprise en option.
Vous avez utilisé cet outil ? Notez-le
Vous avez utilisé cet outil ? Notez-le
LiteLLM est une passerelle IA open source et un SDK Python pour connecter des applications à plusieurs fournisseurs de grands modèles de langage. Son proxy LLM fournit un point de terminaison commun compatible OpenAI ; le SDK intègre directement cette adaptation dans une application Python. Enterprise ajoute gouvernance, fonctions de sécurité et assistance au même code central.
La passerelle se place entre l'application et le fournisseur choisi : elle reçoit la requête, la transmet en amont et renvoie la réponse au format OpenAI. Cette distinction définit le produit. LiteLLM fournit la couche d'accès et de gestion ; le modèle derrière une route configurée assure l'inférence. Un point d'accès API compatible est une capacité d'intégration, pas une allocation incluse pour tous les modèles accessibles.
Le SDK adapte les fournisseurs dans une seule application. Une passerelle partagée centralise l'accès, l'attribution de l'utilisation et le routage pour plusieurs clients.
L'offre commerciale actuelle se concentre sur l'auto-hébergement. La passerelle gratuite et la licence Enterprise payante répondent à des besoins distincts d'administration et d'assistance. Ce sont des offres d'infrastructure, plutôt que des abonnements de chat grand public.
Le SDK expose la complétion, les embeddings et la génération d'images via une interface commune, avec un Router, des exceptions compatibles OpenAI et des callbacks d'observabilité.
stream=True renvoie les fragments à mesure de leur génération, permettant au client d'afficher progressivement une réponse.Le routage de modèles inclut délais de refroidissement, replis, délais d'expiration et nouvelles tentatives entre déploiements et fournisseurs. Les reprises peuvent utiliser une temporisation fixe ou exponentielle. Redis peut stocker l'état partagé des refroidissements et de l'utilisation en production. Ces mécanismes réagissent aux déploiements indisponibles ou limités en débit ; le succès d'un repli dépend encore de la disponibilité en amont.
Le Router propose sélection pondérée, routage tenant compte des limites de débit, routage vers le moins occupé, selon la latence ou selon le coût. Un pool pondéré, un pool choisi par latence et un pool choisi par prix se comportent différemment. Une stratégie ne permet pas d'optimiser tous les critères à la fois.
Le MCP Gateway fournit un point d'accès fixe aux outils MCP et contrôle l'accès par clé et équipe. Les opérations documentées comprennent la liste et l'appel des outils, prompts et ressources. Les transports pris en charge incluent Streamable HTTP, SSE et l'entrée/sortie standard. Plusieurs serveurs d'outils peuvent partager ce point d'accès.
L'AI Gateway gère aussi les agents A2A. Routes de modèles, appels d'outils et points d'accès d'agents restent des ressources amont distinctes, même s'ils partagent l'adresse d'une passerelle.
La gestion des clés virtuelles exige une base Postgres et une clé maître servant de clé d'administration du proxy. La configuration documentée utilise DATABASE_URL pour la connexion et LITELLM_MASTER_KEY pour l'administration ; les clés peuvent ensuite être générées via /key/generate.
model_list, la connexion Postgres et la clé maître sous general_settings.litellm --config /path/to/config.yaml, en utilisant le fichier de configuration enregistré./key/generate, avec la clé maître dans l'en-tête d'autorisation Bearer, un type de contenu JSON et une liste models définissant l'accès aux modèles de la clé générée.base_url du client OpenAI sur l'URL de la passerelle et son api_key sur la clé virtuelle générée.La clé maître administre le proxy ; une clé virtuelle y authentifie une application. Les identifiants du fournisseur autorisent la connexion amont configurée. Leurs portées sont différentes.
Le suivi des dépenses attribue les coûts des modèles aux clés, utilisateurs et équipes à travers les fournisseurs. LiteLLM calcule automatiquement le prix des modèles connus et applique les informations de paliers propres au fournisseur lorsque la réponse contient ces métadonnées. Cela distingue la consommation d'applications ou de services même avec des comptes amont partagés.
Le calcul dépend de la table des coûts des modèles et des tarifs actuels. Les dépenses de la passerelle sont un relevé opérationnel calculé, plutôt que la facture du fournisseur amont.
L'équilibrage de charge peut distribuer les appels entre Azure, Bedrock et d'autres déploiements de fournisseurs, y compris réessayer dans une autre région après un échec. Un alias de modèle commun peut ainsi représenter plusieurs déploiements configurés, sans exposer chaque point d'accès comme un choix distinct à chaque application.
Cela maintient un chemin de requête lors de défaillances de déploiement. Le modèle et le fournisseur choisis déterminent toujours la réponse ; un alias partagé ne rend pas leurs sorties identiques.
La documentation indique que le SSO est gratuit jusqu'à cinq utilisateurs, au-delà desquels une licence Enterprise est nécessaire. Ce seuil d'identité est distinct de la disponibilité de la passerelle gratuite.
Lors de la capture du 23 octobre 2026, une plateforme tierce de lancement de produits affichait une note de 5.0 sur 24 avis LiteLLM. Ce petit échantillon portant sur le produit ne mesure pas la latence, la sécurité ni le coût d'exploitation d'un déploiement.
Les clients compatibles OpenAI se connectent avec l'URL de base de la passerelle et une clé virtuelle. Chacun peut appeler cette API sans intégrer le SDK Python.
LiteLLM permet aussi de placer des modèles internes, affinés et auto-hébergés derrière la même clé. Les points d'accès internes et commerciaux peuvent partager un mode d'accès tout en conservant des hébergements, identifiants et comportements différents.
Les options de production incluent Helm sur Amazon EKS, Google GKE et Azure AKS. Des modules Terraform officiels sont documentés pour AWS et GCP ; le guide indique AKS avec Helm pour Azure et précise qu'il n'existe pas de module Terraform Azure officiel.
Deux architectures de service sont documentées. Une image monolithique dessert ensemble le trafic des modèles, les API de gestion et l'interface. Une architecture microservices sépare passerelle, backend et interface. PostgreSQL stocke clés, équipes, utilisateurs, journaux de dépenses et configuration ; il est requis pour l'authentification et le suivi du proxy. Redis partage l'état des limites de débit, du routage et du cache et est décrit comme nécessaire dès que plusieurs instances fonctionnent.
L'opérateur exploite les magasins d'état et le service de gestion en plus du composant de transmission des requêtes.
Les tarifs relevés le 23 octobre 2026 séparent un cœur gratuit auto-hébergé d'une licence Enterprise annuelle. Le prix Enterprise dépend de la capacité annuelle de requêtes de la passerelle, de l'architecture et des besoins d'assistance ; il est décrit comme n'étant jamais calculé par token. La page vérifiée ne publie aucun montant fixe d'abonnement Enterprise.
| Offre | Modèle d'accès publié | Périmètre inclus |
|---|---|---|
| Open Source | $0 ; gratuit à vie ; auto-hébergé | Clés virtuelles, utilisateurs et équipes, suivi des dépenses, budgets, limites de débit, replis, journaux des requêtes/réponses et métriques Prometheus |
| Enterprise | Devis annuel selon le déploiement et la capacité de requêtes | Passerelle centrale et fonctions supplémentaires d'identité, d'audit, de gestion des secrets, d'administration, multirégion et d'assistance |
Enterprise utilise une clé de licence sur la même image de passerelle, sans exiger une migration vers un produit hébergé distinct. Les ajouts énumérés incluent SSO et SCIM, journaux d'audit, administrateurs d'organisation et d'équipe, gestionnaires de secrets, listes d'IP autorisées, journaux par équipe, fonctions multirégion et SLA d'assistance.
Une clé d'essai Enterprise de 30 jours est disponible par e-mail. L'achat est proposé directement, via AWS Marketplace ou des revendeurs agréés. L'essai accorde un accès Enterprise limité dans le temps.
L'assistance Enterprise standard comprend un canal Slack ou Teams dédié avec les ingénieurs LiteLLM, aux horaires publiés de 9h à 21h PST en semaine, sans délai de réponse garanti. Les SLA garantissant une réponse 24/7 sont une option payante supplémentaire.
La licence amont place sous MIT le code hors du répertoire enterprise et des restrictions indiquées ; le contenu enterprise a une licence distincte. MIT autorise utilisation, modification, distribution, sous-licence et vente, sous conditions, dont la conservation des mentions de copyright et d'autorisation.
L'indication $0 couvre la licence du logiciel auto-hébergé. Infrastructure et inférence amont sont des éléments distincts de l'architecture ; la compatibilité d'un fournisseur n'établit pas de solde de tokens ou de quota de modèles inclus.
Portkey se présente comme une interface unifiée pour les applications d'IA générative, avec des outils de contrôle, de visibilité et de sécurité. Son périmètre déclaré associe accès aux modèles, surveillance et gouvernance.
La comparaison porte sur la couche opérationnelle autant que sur l'accès API. LiteLLM fournit passerelle auto-hébergée et SDK Python avec activation Enterprise facultative ; le recoupement des capacités n'établit pas l'équivalence des licences ou de l'assistance.
OpenRouter donne accès à des centaines de modèles via un point d'accès API unique, avec replis automatiques et sélection d'une option économique pour la requête. LiteLLM traite l'accès commun aux modèles via un logiciel exécuté dans le déploiement de l'organisation, avec ses propres fournisseurs et contrôles d'accès.
Ces choix se recoupent dans l'agrégation d'API. Leurs catalogues de modèles seuls ne décrivent pas la différence entre une bibliothèque Python, une passerelle exploitée et un point d'accès de service.
drop_params est activé. Ce réglage supprime ces paramètres OpenAI ; les autres sont traités comme des champs de requête propres au fournisseur. Un format commun ne garantit pas que chaque fournisseur implémente toutes les fonctions des modèles.LITELLM_SALT_KEY chiffre les identifiants des fournisseurs en base. Le guide précise qu'une modification après l'ajout de modèles les rend illisibles. Cela diffère d'une rotation de clé virtuelle ou de clé du fournisseur amont.hide_secrets et openai_moderations, exigent Enterprise.Désactiver les journaux de messages empêche l'envoi des messages et réponses au fournisseur de journalisation configuré, mais les métadonnées de requête comme les dépenses restent suivies. La suppression du contenu conserve les métadonnées opérationnelles. Fournisseurs d'inférence et destinations de journalisation configurées restent des éléments distincts du parcours des données.
À partir de v1.107.0, la télémétrie d'utilisation est documentée comme désactivée sauf activation, sans enregistrement avant le choix d'une destination. Elle n'a pas de point d'accès HTTP par défaut. Les groupes activés peuvent conserver des comptes agrégés dans la base du déploiement ou les envoyer au point d'accès HTTP configuré ; télémétrie ne signifie pas automatiquement rapport à LiteLLM.
Le schéma déclaré exclut prompts, complétions, clés API, identifiants d'utilisateurs et d'équipes, noms de modèles, adresses IP, valeurs d'en-têtes et corps de requêtes. Les tokens sont totalisés par ligne, pas conservés par requête. Ces exclusions concernent la télémétrie, pas tous les chemins de journalisation ou d'inférence.
Les connexions Enterprise ont une autre limite. Selon la documentation de conformité, le comptage des requêtes facturables transmet le nombre de requêtes réussies à un collecteur LiteLLM, tandis que les vérifications de licence peuvent utiliser le serveur de licence ou valider hors ligne une charge utile signée. Elle indique que prompts, réponses, clés virtuelles et clé de licence ne quittent pas le déploiement dans ce contexte de comptage. Ce mécanisme est distinct de la télémétrie facultative d'utilisation.
Les pages de sécurité, de télémétrie, de journalisation et de conformité vérifiées lors de cette capture ne précisent pas de politique générale d'entraînement des modèles pour tous les fournisseurs amont. Leurs déclarations sur l'auto-hébergement et les flux de données n'établissent pas le traitement des soumissions par chaque service de modèle choisi.
Le mainteneur décrit un incident de chaîne d'approvisionnement du 24 mars 2026 touchant les paquets PyPI v1.82.7 et v1.82.8. Sa mise à jour indique leur mise en quarantaine puis leur suppression. La déclaration vise ces paquets historiques, pas toutes les installations ni la version actuelle.
Séparément, des chercheurs indépendants en sécurité ont évalué v1.77.7 et signalé des problèmes d'accès à la configuration et d'identifiants de fournisseurs, suivis sous CVE-2026-35029 et CVE-2026-59823. Leur rapport indique qu'ils étaient résolus à partir de v1.83.9. Les effets décrits incluaient la prise de contrôle de configuration avec de faibles privilèges et le détournement d'appels fournisseurs pour exfiltrer des identifiants. Ces constats sont limités à des versions, sans affirmer que les mêmes failles persistent dans toutes les versions ultérieures.
LiteLLM fournit la passerelle et le SDK. Les fournisseurs amont configurés assurent l'inférence ; une intégration au catalogue n'établit pas d'allocation de modèle incluse.
Enterprise active des fonctions avec une clé sur la même image de passerelle auto-hébergée. La licence ajoute gouvernance et assistance.
Non. Ces journaux peuvent supprimer le contenu tout en conservant les métadonnées de dépenses. Télémétrie d'utilisation et comptage des requêtes Enterprise ont des contrôles distincts.