# LiteLLM — une seule API pour tous vos providers LLM

LiteLLM : passerelle compatible OpenAI qui unifie Ollama, Mistral, Anthropic et d'autres providers. Clés virtuelles, budgets, sécurité et licence MIT.

URL canonique : https://www.osfria.fr/litellm.html

---

OSIALab · Providers / passerelles

## LiteLLM — une seule API pour tous vos modèles

LiteLLM unifie l'appel à des dizaines de providers — OpenAI, Anthropic, Mistral, Groq, Cohere, [Ollama](https://www.osfria.fr/ollama.html) en local… — derrière un **unique endpoint compatible OpenAI**. Vos applications cessent de connaître les particularités de chaque API : elles parlent à LiteLLM, qui traduit et route.

### Fiabilité & transparence

🟡 **Utilisable, avec points d'attention**

- **Maintenance** : v1.83.10+ (13 juin 2026) ; rythme rapide et régulier.
- **Adoption** : 50,2K étoiles GitHub, standard pour l'abstraction multi-providers.
- **Sécurité** : CVE-2026-42208 (injection SQL pre-auth, CVSS 9.8) — exploitée ~36h après divulgation, ✅ corrigée v1.83.7+. Point sensible.
- **Verdict** : Passerelle LLM indispensable. Mettez à jour avant tout déploiement en production (≥ 1.83.7). En proxy, sécurisez l'authentification et le stockage des clés API.

> Page informative, sans valeur de conseil. Téléchargez depuis la **source officielle**, vérifiez la **licence** (cœur MIT, mais un dossier « enterprise » est sous licence distincte — voir plus bas), et gardez en tête que LiteLLM en mode proxy **voit passer toutes vos requêtes et centralise vos clés API** : c'est un point sensible à sécuriser comme tel.

### À quoi ça sert

Chaque provider LLM a sa propre API, ses paramètres et ses formats de réponse. LiteLLM expose un **endpoint unique** au format OpenAI (`/chat/completions`) et se charge de traduire vers le provider visé. On change de modèle ou de fournisseur sans toucher au code des applications clientes. Deux usages :

- **Bibliothèque Python** — quelques lignes pour appeler n'importe quel provider avec la même interface, idéal dans un script ou un service.
- **Proxy (serveur)** — un service que vous hébergez, qui centralise les clés, gère des budgets et des quotas par équipe, journalise les appels et permet de basculer d'un provider à l'autre côté serveur. C'est le mode qui en fait une vraie *passerelle d'entreprise*.

Cas d'usage : standardiser les appels LLM d'une équipe, ajouter un *fallback* automatique, plafonner les dépenses par projet, ou donner à [n8n](https://www.osfria.fr/n8n.html), [Flowise](https://www.osfria.fr/flowise.html) et [Open WebUI](https://www.osfria.fr/open-webui.html) un endpoint unique vers tous les modèles.

### Ce qui fait sa force

- **Compatibilité OpenAI universelle.** Tout outil ou SDK prévu pour l'API d'OpenAI fonctionne en pointant sur LiteLLM, *sans réécriture*. C'est le standard de fait, réutilisé partout.
- **Clés virtuelles, budgets, quotas.** Le proxy émet des *virtual keys* par projet, chacune avec son budget mensuel, ses limites de débit (RPM/TPM) et ses modèles autorisés. Vous distribuez des clés LiteLLM, jamais vos vraies clés providers.
- **Routage et bascule.** Répartition de charge, *fallback* automatique d'un modèle vers un autre, gestion des erreurs : la couche réseau que l'on bricole sinon à la main.
- **Local et cloud sur le même endpoint.** Un modèle [Ollama](https://www.osfria.fr/ollama.html) local et un modèle cloud cohabitent dans la même configuration ; les clients ne voient qu'un nom de modèle.
- **Suivi des dépenses centralisé.** Les coûts estimés par clé, par modèle et par projet sont consolidés — un tableau de bord là où chaque provider a habituellement le sien.

### Pour qui

Pour des **développeurs et équipes techniques** qui consomment plusieurs providers et veulent réduire la complexité de maintenance. Le mode proxy brille quand plusieurs applications partagent les mêmes clés : LiteLLM centralise au lieu de disséminer. Les profils non techniques n'y touchent pas directement, mais en bénéficient si un administrateur y connecte leurs outils.

### Installation

#### Bibliothèque Python

```
pip install litellm
```

```
from litellm import completion

# Appel vers Ollama en local
response = completion(
    model="ollama/llama3.2",
    messages=[{"role": "user", "content": "Bonjour"}],
    api_base="http://localhost:11434"
)
print(response.choices[0].message.content)
```

#### Mode proxy (serveur)

```
# Installer le proxy
pip install 'litellm[proxy]'

# Démarrer avec un fichier de configuration (port 4000 par défaut)
litellm --config config.yaml --port 4000
```

Le proxy écoute sur **http://localhost:4000** et expose un endpoint `/chat/completions` compatible OpenAI. Une interface d'administration est disponible sur **/ui** (connexion avec la clé maître).

#### Avec Docker

```
docker run \
  -p 4000:4000 \
  -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml --port 4000
```

#### Exemple de config.yaml minimal

```
model_list:
  - model_name: llama3-local
    litellm_params:
      model: ollama/llama3.2
      api_base: http://host.docker.internal:11434

  - model_name: mistral-cloud
    litellm_params:
      model: mistral/mistral-small
      api_key: os.environ/MISTRAL_API_KEY
```

### Aller plus loin : clé maître et clés virtuelles

Deux niveaux de clés cohabitent, à ne pas confondre :

- **`LITELLM_MASTER_KEY`** — la clé racine du proxy. Elle authentifie les administrateurs et l'accès à l'interface `/ui`. Ce n'est *pas* une clé provider.
- **Clés providers** (OpenAI, Anthropic, Mistral…) — ajoutées par modèle, dans la configuration ou via l'UI. Avec une base PostgreSQL, elles sont **stockées chiffrées** et persistent entre les redémarrages.
- ***Virtual keys*** — émises par le proxy pour chaque application cliente, avec budget, quotas et modèles autorisés. Ce sont elles que vous distribuez. Leur gestion nécessite une base PostgreSQL (incluse dans la configuration Docker Compose officielle).

### Points de vigilance

En mode proxy, LiteLLM devient un **point central qui détient les clés et voit toutes les requêtes**. Les points ci-dessous découlent directement de ce rôle.

| Point d'attention | Niveau | Ce qu'il faut savoir |
| --- | --- | --- |
| Proxy exposé sans clé maître | 🔴 si accessible en réseau | Sans `LITELLM_MASTER_KEY` et clés virtuelles, le proxy peut être interrogé librement par quiconque l'atteint — et consommer vos clés providers. Définissez la clé maître, émettez des clés virtuelles par client, et placez le proxy derrière un reverse proxy HTTPS. |
| Centralisation des clés API providers | 🔴 réel par conception | Toutes vos clés providers sont réunies au même endroit (chiffrées en base). Si l'instance est compromise, l'impact est global. Isolez le service, restreignez l'accès, prévoyez une rotation des clés. |
| Requêtes et réponses dans les journaux | 🟡 selon configuration | LiteLLM peut journaliser le contenu des échanges à des fins d'observabilité. Avant de traiter des données personnelles ou confidentielles, vérifiez le niveau de log et désactivez la journalisation du contenu en production si nécessaire. |
| Emballement des coûts cloud | 🟡 réel | Le proxy facilite l'appel de providers payants par de nombreuses applications. Posez des budgets par clé virtuelle et des alertes côté provider pour éviter les dérives. |
| Licence : MIT, sauf le dossier « enterprise » | 🟡 avant usage commercial | Le cœur de LiteLLM est sous **licence MIT**. Le contenu du dossier `enterprise/` relève d'une **licence distincte** définie dans ce même dossier. Si vous utilisez ces fonctions, lisez leurs conditions avant un déploiement commercial. |
| Compromission de la chaîne de publication PyPI (mars 2026) | 🔴 si ces versions précises ont été installées | En mars 2026, deux versions piégées (**1.82.7** et **1.82.8**) ont brièvement circulé sur PyPI à la suite d'une compromission de la chaîne de publication, vite détectée et corrigée. Si vous avez installé l'une de ces deux versions précises, **tournez immédiatement toutes vos clés API** et mettez à jour vers une version stable récente. Dans tous les cas, **épinglez vos versions** (`litellm==x.y.z`) pour maîtriser ce que vous déployez. Source : Datadog Security Labs. |

### Sécurité

- **Définissez la clé maître.** `LITELLM_MASTER_KEY` pour protéger l'accès au proxy et à l'interface `/ui`.
- **Une clé virtuelle par application.** Avec budget et modèles autorisés ; ne distribuez jamais vos vraies clés providers.
- **HTTPS obligatoire.** Reverse proxy (Nginx, Caddy) avec TLS — les clés transitent dans les en-têtes HTTP.
- **Isolez et surveillez.** Accès réseau restreint à l'instance, audit régulier des journaux (modèles appelés, fréquence, coûts).
- **Tenez le proxy à jour.** LiteLLM évolue très vite ; suivez les releases.

### Aller plus loin

- [Ollama](https://www.osfria.fr/ollama.html) — le provider local à brancher en priorité pour les données sensibles.
- [Open WebUI](https://www.osfria.fr/open-webui.html) — une interface unique pour tous les modèles servis par LiteLLM.
- [n8n](https://www.osfria.fr/n8n.html) — pointer un endpoint LiteLLM unique dans vos workflows.
- [OSIALab](https://www.osfria.fr/osialab.html) — comparer les providers et passerelles.

### Sources

- Site officiel : **litellm.ai**
- Code source : [github.com/BerriAI/litellm](https://github.com/BerriAI/litellm)
- Documentation : [docs.litellm.ai](https://docs.litellm.ai)
- Licence : [MIT License](https://github.com/BerriAI/litellm/blob/main/LICENSE) pour le cœur ; dossier `enterprise/` sous licence distincte (voir `enterprise/LICENSE`).
- Compromission PyPI mars 2026 (versions 1.82.7 / 1.82.8) : [Datadog Security Labs](https://securitylabs.datadoghq.com/)