AI Gateway
LiteLLM — Open-source LLM Proxy for 100+ Providers logo

LiteLLM — Proxy LLM open source pour plus de 100 fournisseurs

LiteLLM est un proxy open source qui normalise plus de 100 API LLM derrière le SDK OpenAI. Placez-le devant Claude, Gemini, Ollama, Bedrock, Vertex ou Azure — un seul client, des appels unifiés.

Why LiteLLM

LiteLLM est la réponse « un seul SDK pour tous les LLM », plus un serveur Proxy complet pour les équipes qui veulent un gateway hébergé qu'elles contrôlent. Le SDK seul normalise les entrées et sorties : completion(model="claude-3-5-sonnet", messages=[...]) fonctionne à l'identique de l'appel OpenAI. Le Proxy ajoute le routage, les budgets, la gestion des clés, le logging et une UI Swagger.

C'est le gateway OSS le plus populaire (25K+ étoiles GitHub) et la référence standard pour un accès multi-modèles indépendant du framework. LangChain, LlamaIndex et CrewAI supportent tous LiteLLM comme model provider d'entrée de jeu. Si vous avez lu « pointez-le sur n'importe quel endpoint compatible OpenAI » dans une douzaine de READMEs, LiteLLM est ce qui fait tourner la plupart de ces setups.

Ce que vous abandonnez : le polish. Le dashboard existe mais reste fonctionnel, pas magnifique. L'observabilité est présente mais pas profonde — la plupart des équipes associent LiteLLM Proxy à Langfuse ou Helicone pour les traces. Pour un produit libre et gratuit, vous échangez l'UX contre du contrôle.

Quick Start — SDK or Proxy

Le SDK est le chemin le plus rapide vers le support multi-fournisseurs — aucun serveur à faire tourner. Le Proxy est un petit serveur FastAPI qui expose des endpoints compatibles OpenAI ; pointez n'importe quel SDK OpenAI dessus. Le routage piloté par config permet de changer de fournisseur ou de stratégie de load-balancing sans toucher au code applicatif.

# Option A: SDK only (no server needed)
# pip install litellm
from litellm import completion

resp = completion(
    model="anthropic/claude-3-5-sonnet-20241022",
    messages=[{"role": "user", "content": "Hello from LiteLLM"}],
)
print(resp.choices[0].message.content)

# Option B: Run the Proxy for team use
# pip install 'litellm[proxy]'
# litellm --config config.yaml --port 4000
#
# config.yaml:
# model_list:
#   - model_name: fast
#     litellm_params:
#       model: gpt-4o-mini
#       api_key: os.environ/OPENAI_KEY
#   - model_name: fast
#     litellm_params:
#       model: claude-3-5-haiku-20241022
#       api_key: os.environ/ANTHROPIC_KEY
# router_settings:
#   routing_strategy: usage-based-routing-v2

# Now call the proxy as if it were OpenAI
from openai import OpenAI
client = OpenAI(base_url="http://localhost:4000", api_key="sk-proxy-token")
r = client.chat.completions.create(model="fast", messages=[{"role":"user","content":"hi"}])
# Proxy load-balances between gpt-4o-mini and claude-3-5-haiku based on usage.

Fonctionnalités clés

100+ fournisseurs

OpenAI, Anthropic, Gemini, Bedrock, Azure, Vertex, Ollama, Together, Fireworks, Anyscale, Groq, Mistral, Cohere, HuggingFace et bien d'autres. Tous via la même signature completion().

Serveur Proxy

Serveur FastAPI de niveau production : routage, load-balancing, retries, cache, gestion des clés et budgets utilisateurs. Déploiement Docker ; exposez-le comme endpoint interne compatible OpenAI.

Budgets et rate limits

Budgets par utilisateur, par équipe et par clé appliqués au niveau du Proxy. Alertes à 80 % / 100 % de dépense. Essentiel pour les setups multi-tenant ou platform-as-a-service interne.

Hooks Langfuse / Helicone / Sentry

Intégrations callback natives. Couplez LiteLLM Proxy avec Langfuse pour les traces, Helicone pour l'observabilité, Sentry pour les erreurs. Configurable dans le YAML du proxy.

Fallback et retry

Listes de fallback déclaratives : tentez Claude, basculez sur GPT-4o, puis sur gpt-4o-mini. Backoff exponentiel intégré. Configurable par route.

Auth et RBAC personnalisés

Le Proxy génère des clés virtuelles par utilisateur ; le contrôle d'accès par rôle décide quels modèles et budgets chaque utilisateur peut atteindre. S'intègre à votre SSO existant via OIDC.

Comparaison

 LicenseDeploymentDashboardBest For
LiteLLMcelui-ciMIT (SDK) + proxySelf-hostFunctionalTeams wanting OSS gateway + unified SDK
PortkeyGateway Apache 2.0; cloud proprietaryManaged + self-hostPolishedTeams wanting managed UX
OpenRouterProprietaryManaged onlyWeb UIQuick multi-model experiments
Cloudflare AI GatewayProprietaryManaged onlyWeb UIEdge caching, simple setup

Cas d'usage

01. Plateforme AI interne

L'équipe plateforme exploite LiteLLM Proxy ; les équipes produit tapent sur un seul endpoint compatible OpenAI. Contrôle central des fournisseurs, des clés et des budgets ; aucun déploiement central quand une équipe veut un nouveau modèle.

02. Applis multi-modèles

Des Agents qui arbitrent entre modèles rapides/peu chers et lents/puissants. La signature completion() unifiée de LiteLLM ramène la logique de routage à 10 lignes, plutôt qu'une intégration par fournisseur.

03. Hybride local + cloud

Ollama pour le dev et l'inférence pas chère, OpenAI/Claude pour la production. Même chemin de code — on bascule via le nom de modèle.

Tarification et licence

LiteLLM : licence MIT, gratuit. Pas de SKU de support entreprise — le projet est maintenu par BerriAI et une communauté grandissante. Pour du support commercial, litellm.ai propose des tiers hébergés et entreprise avec SLA.

Coût opérationnel : petite VM pour le Proxy (2 vCPU / 4 Go absorbent en pratique plusieurs milliers de RPS), plus votre dépense LLM sous-jacente. Aucun frais gateway par requête.

Ce que vous payez en complexité cachée : le self-hosting veut dire que vous possédez l'uptime, les upgrades et le debug. Pour les équipes qui veulent « payer et oublier », Portkey ou Cloudflare allègent la charge ops au prix de la liberté sans licence.

Assets associés sur TokRepo

Questions fréquentes

LiteLLM SDK ou LiteLLM Proxy — lequel me faut-il ?+

Le SDK pour les applis isolées : vous voulez des appels completion() unifiés, sans serveur. Le Proxy pour les équipes / plateforme interne : plusieurs applis partagent le gateway, clés et budgets centralisés, endpoint compatible OpenAI pour les outils qui en demandent un.

LiteLLM ajoute-t-il de la latence ?+

SDK : ~0 (in-process). Proxy : 3 à 10 ms de surcoût sur le hot-path. Le cache et le load-balancing économisent souvent bien plus qu'ils ne coûtent sur du trafic réaliste.

Comment LiteLLM se compare-t-il à OpenRouter ?+

OpenRouter est un SaaS managé en pay-per-token sur l'ensemble des fournisseurs. LiteLLM est self-hosted avec vos propres clés. OpenRouter pour l'expérimentation rapide ou quand vous voulez une seule facture ; LiteLLM quand vous voulez contrôler les clés, les budgets et le flux de données.

LiteLLM est-il prêt pour la production ?+

Oui — déployé en production par de nombreuses grandes organisations. Consultez le README GitHub pour la liste des adopters actifs. Précautions attendues : surveillez le changelog pour les ruptures occasionnelles dues au développement rapide ; upgradez en staging avant la production.

Fonctionne-t-il avec Claude Code / Cursor / Cline ?+

Oui. Tout outil qui accepte un endpoint compatible OpenAI (base URL + API key) fonctionne. Pointez Cursor ou Cline sur votre LiteLLM Proxy, et l'intégration « OpenAI » de l'outil route désormais par votre gateway multi-fournisseurs.

Comment ajouter un nouveau fournisseur ?+

La liste /providers de LiteLLM couvre la plupart des LLM mainstream. Pour des fournisseurs nouveaux ou custom, enregistrez un endpoint générique compatible OpenAI dans la config model_list — aucun changement de code nécessaire.

Comparer les alternatives