LiteLLM Proxy : la couche d'abstraction API pour gouverner vos LLM souverains

Pourquoi LiteLLM Proxy dans une architecture LLM souveraine ?

Imaginons la situation classique d'une DSI qui commence à déployer des LLM locaux — situation que nous rencontrons régulièrement chez nos clients. L'équipe IT installe Ollama sur un serveur GPU. L'équipe développement intègre directement http://gpu-server:11434/v1/chat/completions dans ses applications. L'équipe RH utilise AnythingLLM configuré lui aussi directement sur Ollama. Les commerciaux ont configuré leur IDE Continue.dev avec Ollama. Quelques semaines plus tard, la situation dérape :

• Impossible de savoir quelle application utilise quel modèle et avec quelle fréquence
• Aucun logging centralisé des prompts — impossible d'auditer en cas d'incident ou de demande DPO
• Le serveur GPU est saturé par l'équipe développement qui monopolise les ressources pendant les heures de bureau, au détriment des autres
• Changer de modèle principal (passer de Mistral 7B à Mistral 22B ou Llama 3.1 70B) exige de modifier les configurations dans 12 endroits différents
• Pas de fallback automatique si le serveur GPU tombe en panne un vendredi soir
• Impossible de calculer le coût réel par équipe pour la facturation interne ou les budgets projets

LiteLLM résout tous ces problèmes en centralisant tout le trafic LLM derrière un proxy unique. C'est le pattern bien connu de l'API Gateway, appliqué aux modèles de langage. C'est aussi le moyen de traiter les LLM comme n'importe quelle autre infrastructure managée : avec de la gouvernance, de la traçabilité et du contrôle.

LiteLLM vs Ollama seul : pourquoi ajouter cette couche ?

Une question revient souvent en atelier DSI : « Si Ollama expose déjà une API compatible OpenAI, pourquoi ajouter LiteLLM ? » La réponse tient en quatre points fondamentaux.

Premièrement, Ollama n'a pas d'authentification. Son API est accessible à quiconque peut joindre le port 11434. Dans un réseau d'entreprise, cela signifie que n'importe quel collaborateur (ou processus malveillant) peut interroger vos modèles sans contrôle, consommant toutes les ressources GPU sans traçabilité. LiteLLM ajoute une couche de clés API obligatoires.

Deuxièmement, Ollama ne gère qu'un seul backend. Si vous avez deux serveurs GPU et voulez répartir la charge entre eux, Ollama ne peut pas le faire nativement. LiteLLM gère cette répartition de manière transparente pour les applications clientes.

Troisièmement, Ollama ne journalise pas les requêtes de manière structurée et exploitable. Pour un DPO ou un RSSI qui doit pouvoir répondre à la question « quelles données ont été envoyées à l'IA et par qui ? », l'absence de logging est un problème de conformité majeur. LiteLLM journalise chaque requête avec ses métadonnées complètes.

Quatrièmement, Ollama ne peut pas faire de fallback cloud. Si votre modèle local ne peut pas traiter une requête (contexte trop long, modèle en surcharge), il n'y a pas de filet. LiteLLM permet de configurer un fallback automatique vers un modèle cloud avec un budget limité et contrôlé.

Architecture proxy : le schéma de flux

LiteLLM Proxy s'intercale entre vos applications et vos modèles LLM. Il joue le rôle d'un gateway intelligent avec routage dynamique :

Applications utilisateur
┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│  Open WebUI  │  │  LangChain   │  │ Continue.dev │  │ AnythingLLM  │
│  (chat)      │  │  (RAG app)   │  │  (IDE)       │  │  (docuRAG)   │
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       │                 │                 │                 │
       └─────────────────┴─────────────────┴─────────────────┘
                                   │
                    API OpenAI-compatible
                   (port 4000, clé par équipe)
                                   │
                                   ▼
                    ┌──────────────────────────┐
                    │      LiteLLM Proxy       │
                    │                          │
                    │  ✓ Authentification       │
                    │  ✓ Routage intelligent    │
                    │  ✓ Load balancing         │
                    │  ✓ Fallback automatique   │
                    │  ✓ Rate limiting          │
                    │  ✓ Budget control         │
                    │  ✓ Logging centralisé     │
                    └──────────┬───────────────┘
                               │
            ┌──────────────────┼──────────────────┐
            ▼                  ▼                  ▼
  ┌──────────────────┐ ┌──────────────┐ ┌───────────────────┐
  │  Ollama          │ │  Ollama      │ │  OpenAI / Mistral │
  │  Serveur GPU 1   │ │  Serveur GPU2│ │  API (fallback)   │
  │  (mistral, llama)│ │  (code model)│ │                   │
  └──────────────────┘ └──────────────┘ └───────────────────┘

Chaque application croit qu'elle parle à une API OpenAI standard. LiteLLM gère de manière transparente la traduction vers le bon backend, la répartition de charge entre instances, les basculements en cas de panne, et enregistre chaque appel avec ses métadonnées complètes.

Installation et configuration

Option recommandée : Docker Compose avec PostgreSQL

# /opt/litellm/docker-compose.yml
version: '3.8'

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    container_name: litellm
    restart: unless-stopped
    ports:
      - "127.0.0.1:4000:4000"  # Exposer localement, Nginx fera le proxy
    volumes:
      - /opt/litellm/config.yaml:/app/config.yaml
    environment:
      - LITELLM_MASTER_KEY=${LITELLM_MASTER_KEY}
      - DATABASE_URL=postgresql://litellm:${POSTGRES_PASSWORD}@postgres:5432/litellm
      - STORE_MODEL_IN_DB=True
    command: ["--config", "/app/config.yaml", "--port", "4000", "--detailed_debug"]
    networks:
      - llm-network
    extra_hosts:
      - "host.docker.internal:host-gateway"
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:15-alpine
    container_name: litellm-db
    restart: unless-stopped
    environment:
      - POSTGRES_DB=litellm
      - POSTGRES_USER=litellm
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - /opt/litellm/postgres:/var/lib/postgresql/data
    networks:
      - llm-network
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm"]
      interval: 5s
      timeout: 5s
      retries: 5

networks:
  llm-network:
    driver: bridge

# Créer le fichier d'environnement
mkdir -p /opt/litellm
cat > /opt/litellm/.env << 'EOF'
LITELLM_MASTER_KEY=sk-$(openssl rand -hex 20)
POSTGRES_PASSWORD=$(openssl rand -hex 16)
EOF

cat /opt/litellm/.env  # Notez ces valeurs précieusement

# Lancer la stack
cd /opt/litellm
docker compose up -d

# Vérifier que LiteLLM est opérationnel
curl http://localhost:4000/health
# Réponse : {"status": "healthy", ...}

Connecter vos modèles souverains

Fichier de configuration complet

# /opt/litellm/config.yaml

model_list:
  # ---- Modèles locaux via Ollama ----

  # Mistral 7B sur serveur GPU principal
  - model_name: mistral-souverain
    litellm_params:
      model: ollama/mistral
      api_base: http://host.docker.internal:11434
      timeout: 120

  # Mistral 7B sur serveur GPU secondaire (load balancing)
  - model_name: mistral-souverain
    litellm_params:
      model: ollama/mistral
      api_base: http://192.168.1.101:11434
      timeout: 120

  # Modèle de code dédié
  - model_name: code-souverain
    litellm_params:
      model: ollama/qwen2.5-coder:7b
      api_base: http://host.docker.internal:11434

  # Modèle puissant pour tâches complexes
  - model_name: llm-puissant
    litellm_params:
      model: ollama/llama3.1:70b
      api_base: http://192.168.1.100:11434
      timeout: 300

  # ---- Fallback cloud (optionnel, pour cas limites) ----
  - model_name: fallback-urgence
    litellm_params:
      model: mistral/mistral-large-latest  # Mistral AI, juridiction française
      api_key: os.environ/MISTRAL_API_KEY

router_settings:
  routing_strategy: least-busy
  num_retries: 3
  timeout: 120
  retry_after: 5
  allowed_fails: 2
  cooldown_time: 30
  fallbacks:
    - mistral-souverain: [llm-puissant, fallback-urgence]
    - code-souverain: [mistral-souverain]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL
  store_model_in_db: true
  # Interface admin activée
  ui_access_mode: all

litellm_settings:
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]
  drop_params: true  # Ignorer les paramètres non supportés par certains modèles
  request_timeout: 120

Connecter d'autres backends souverains

# vLLM — moteur haute performance pour production intensive
- model_name: mistral-vllm
  litellm_params:
    model: openai/mistralai/Mistral-7B-Instruct-v0.3
    api_base: http://vllm-server:8000
    api_key: token-fictif  # vLLM n'exige pas de clé par défaut

# HuggingFace Text Generation Inference
- model_name: llama-tgi
  litellm_params:
    model: huggingface/meta-llama/Llama-3.1-8B-Instruct
    api_base: http://tgi-server:8080

# Mistral AI (API cloud, hébergement français, faible cloud act)
- model_name: mistral-api-fr
  litellm_params:
    model: mistral/mistral-large-latest
    api_key: os.environ/MISTRAL_API_KEY

API OpenAI-compatible : migration transparente

Une fois LiteLLM démarré sur le port 4000, toute application conçue pour l'API OpenAI fonctionne sans modification de code. Il suffit de modifier deux variables d'environnement dans chaque application :

• OPENAI_API_BASE ou base_url : http://SERVEUR_LITELLM:4000
• OPENAI_API_KEY ou api_key : la clé API LiteLLM attribuée à cette équipe ou application

Exemples d'intégration dans différents langages

# Python — SDK OpenAI standard, sans modification
from openai import OpenAI

client = OpenAI(
    base_url="http://litellm-server:4000",
    api_key="sk-cle-equipe-juridique"
)

# Appel identique à l'API OpenAI — le modèle est le nom défini dans config.yaml
response = client.chat.completions.create(
    model="mistral-souverain",
    messages=[
        {"role": "system", "content": "Tu es un assistant juridique expert en droit français."},
        {"role": "user", "content": "Résume les obligations RGPD d'un sous-traitant en 5 points."}
    ],
    temperature=0.2,
    max_tokens=1000
)
print(response.choices[0].message.content)

// JavaScript / Node.js — zéro modification
const OpenAI = require('openai');

const client = new OpenAI({
  baseURL: 'http://litellm-server:4000',
  apiKey: 'sk-cle-equipe-dev'
});

// Streaming natif supporté
const stream = await client.chat.completions.create({
  model: 'code-souverain',
  messages: [{ role: 'user', content: 'Génère un script Python pour parser un CSV.' }],
  stream: true
});

for await (const chunk of stream) {
  process.stdout.write(chunk.choices[0]?.delta?.content || '');
}

# Test cURL rapide
curl http://litellm-server:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-cle-test" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral-souverain",
    "messages": [{"role": "user", "content": "Ping"}],
    "max_tokens": 50
  }'

# Lister les modèles disponibles (utile pour les outils qui interrogent /v1/models)
curl http://litellm-server:4000/v1/models \
  -H "Authorization: Bearer sk-cle-test"

Load balancing et fallback automatique

Le load balancing est l'une des fonctionnalités les plus stratégiques de LiteLLM pour les organisations avec plusieurs serveurs GPU. Quand plusieurs instances d'un même modèle sont définies dans la configuration, LiteLLM répartit automatiquement les requêtes selon la stratégie choisie.

Stratégies de routage disponibles

Stratégie	Comportement	Cas d'usage idéal
simple-shuffle	Distribution aléatoire uniforme entre les instances	Serveurs de capacité identique, charge prévisible
least-busy	Envoi vers l'instance avec le moins de requêtes actives	Instances avec capacités variables, charge en burst
latency-based-routing	Favorise l'instance avec la latence récente la plus faible	Optimisation de l'expérience utilisateur interactive
usage-based-routing	Distribue selon les tokens consommés récemment par instance	Équilibrage fin de la charge GPU
weighted-pick	Distribution pondérée selon des poids configurables	Instances GPU de puissance très différente

Configuration détaillée du fallback

router_settings:
  routing_strategy: least-busy

  # Nombre de tentatives avant de passer au fallback
  num_retries: 2

  # Délai entre les tentatives (secondes)
  retry_after: 5

  # Nombre d'erreurs tolérées avant mise en cooldown d'un modèle
  allowed_fails: 3

  # Durée du cooldown (secondes) — le modèle en erreur est mis de côté
  cooldown_time: 60

  # Timeout par requête (secondes)
  timeout: 120

  # Chaîne de fallback par modèle
  fallbacks:
    # Si mistral-souverain échoue, essayer llm-puissant, puis fallback-urgence
    - mistral-souverain: [llm-puissant, fallback-urgence]
    # Si code-souverain échoue, replier sur mistral-souverain
    - code-souverain: [mistral-souverain]

  # Fallback sur latence excessive (ms) — si réponse > 30s, changer de backend
  latency_fallback_threshold: 30000

Monitoring de santé des backends

# Vérification de l'état de tous les modèles configurés
curl http://litellm-server:4000/health/readiness

# État détaillé de chaque backend
curl http://litellm-server:4000/health \
  -H "Authorization: Bearer sk-MASTER-KEY"

# Métriques Prometheus (pour Grafana)
curl http://litellm-server:4000/metrics
# Retourne : litellm_requests_total, litellm_tokens_total, litellm_request_duration_seconds...

Contrôle budgétaire par équipe

C'est la fonctionnalité la plus stratégique pour une DSI qui gère des LLM cloud et locaux mixtes. LiteLLM permet de créer des clés API par équipe avec des budgets mensuels en euros (pour les modèles cloud) et des quotas en tokens par minute (pour les modèles locaux, pour éviter la saturation du GPU).

La logique de gouvernance par clé API

Dans une organisation, les LLM locaux ont un coût nul en tokens (vous avez déjà acheté le GPU), mais ils ont un coût en ressources GPU — ressource rare et partagée. Une équipe de développeurs qui lance des benchmarks intensifs peut rendre le modèle inutilisable pour toutes les autres équipes pendant des heures. Le contrôle budgétaire de LiteLLM s'applique donc à deux dimensions distinctes selon les modèles :

• Pour les modèles cloud (OpenAI, Mistral API, Anthropic…) : le budget est en euros par mois. Quand le budget est épuisé, les requêtes vers ce modèle sont refusées avec un message d'erreur clair. La facturation interne est ainsi naturellement cloisonnée.
• Pour les modèles locaux Ollama : le budget s'exprime en tokens par minute (TPM) et requêtes par minute (RPM). Une équipe qui dépasse son quota se voit temporairement limitée, laissant la ressource disponible pour les autres. C'est du rate limiting de gouvernance, pas de la facturation.

Cette distinction est importante à expliquer aux équipes métier lors de la mise en place : utiliser les modèles locaux ne coûte pas d'argent, mais consomme de la capacité GPU partagée. Le respect des quotas RPM est donc une question de civisme organisationnel autant que de contrainte technique.

Créer des clés API par équipe

# Créer une clé pour l'équipe RH
# Budget : 20€/mois sur les appels cloud, 50k tokens/min max en local
curl -X POST http://litellm-server:4000/key/generate \
  -H "Authorization: Bearer sk-MASTER-KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "equipe-rh",
    "key_alias": "rh-production-2026",
    "max_budget": 20,
    "budget_duration": "1mo",
    "models": ["mistral-souverain", "fallback-urgence"],
    "tpm_limit": 50000,
    "rpm_limit": 30,
    "metadata": {
      "team": "Ressources Humaines",
      "owner": "drh@entreprise.fr",
      "created_at": "2026-05-17"
    }
  }'

# Réponse
# {"key": "sk-rh-xxxxxxxxxxxxxxxxxxxx", "max_budget": 20, "rpm_limit": 30, ...}

# Créer une clé pour l'équipe développement (modèles locaux illimités, code uniquement)
curl -X POST http://litellm-server:4000/key/generate \
  -H "Authorization: Bearer sk-MASTER-KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "equipe-dev",
    "key_alias": "dev-production-2026",
    "max_budget": 0,
    "models": ["code-souverain", "mistral-souverain"],
    "tpm_limit": 200000,
    "rpm_limit": 120,
    "metadata": {"team": "Développement", "owner": "cto@entreprise.fr"}
  }'

Tableau de gouvernance des accès recommandé

Équipe	Modèles autorisés	Budget cloud /mois	RPM max	TPM max
Développement	code-souverain, mistral-souverain	0 € (local uniquement)	120	200k
Juridique	mistral-souverain, llm-puissant	50 € (fallback)	30	80k
Commercial	mistral-souverain	20 € (fallback)	60	100k
RH	mistral-souverain	10 € (fallback)	30	50k
Direction	tous les modèles	200 € (tous)	120	300k
IT (admin)	tous les modèles	illimité	illimité	illimité

Consulter la consommation budgétaire

# Voir le budget consommé pour une clé
curl http://litellm-server:4000/key/info \
  -H "Authorization: Bearer sk-MASTER-KEY" \
  -d '{"key": "sk-rh-xxxxxxxxxxxxxxxxxxxx"}'

# Voir toutes les clés et leur consommation
curl http://litellm-server:4000/key/list \
  -H "Authorization: Bearer sk-MASTER-KEY"

# Rapport par équipe (via l'interface admin sur /ui)
# http://litellm-server:4000/ui

Logging et observabilité

LiteLLM enregistre nativement chaque requête LLM avec l'ensemble de ses métadonnées : modèle utilisé, clé API (et donc équipe), prompt complet, réponse complète, latence, tokens d'entrée et de sortie, coût estimé, code de retour. Ce niveau de traçabilité est indispensable pour une gouvernance sérieuse.

Pourquoi le logging LLM est-il différent du logging applicatif classique ?

Journaliser des appels à une API REST classique, c'est enregistrer des URLs, des codes HTTP et des durées. Journaliser des appels LLM, c'est enregistrer des conversations complètes en langage naturel — avec tout ce qu'elles peuvent contenir de données sensibles, de stratégie d'entreprise, de questions personnelles. Le logging LLM est une activité de traitement de données personnelles au sens du RGPD : il doit être encadré par une politique claire.

Dans LiteLLM, le paramètre log_raw_request_response: True active la journalisation complète des prompts et des réponses. Avant de l'activer, votre DPO doit valider que cette journalisation est proportionnée à l'objectif (audit, sécurité, débogage) et que les logs sont conservés de manière sécurisée, avec une durée de rétention définie et un accès restreint aux personnes habilitées. Sur Langfuse self-hosted, les traces sont stockées sur votre infrastructure — ce qui préserve la souveraineté des données. Sur un service SaaS externe, le logging devient un nouveau point de sortie des données.

Intégration Langfuse self-hosted (recommandé)

Langfuse est une plateforme d'observabilité LLM open-source déployable en self-hosted. Elle offre une interface web pour explorer les traces, filtrer par équipe, calculer les coûts, et détecter les anomalies.

# Dans /opt/litellm/config.yaml
litellm_settings:
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

# Dans /opt/litellm/.env
LANGFUSE_PUBLIC_KEY=pk-lf-votre-cle-publique
LANGFUSE_SECRET_KEY=sk-lf-votre-cle-secrete
LANGFUSE_HOST=http://langfuse-server:3000  # URL de votre Langfuse self-hosted

Intégration Prometheus + Grafana

# Dans config.yaml
litellm_settings:
  success_callback: ["prometheus"]

# Métriques disponibles sur /metrics :
# litellm_requests_total{model, team_id, status_code}
# litellm_tokens_total{model, team_id, token_type}
# litellm_request_duration_seconds{model, team_id} (histogram)
# litellm_budget_remaining{team_id}
# litellm_failed_requests_total{model, team_id, exception_type}

# prometheus.yml — configuration du scrape LiteLLM
scrape_configs:
  - job_name: 'litellm'
    static_configs:
      - targets: ['litellm-server:4000']
    metrics_path: '/metrics'
    scrape_interval: 15s
    # En production, ajouter l'authentification
    bearer_token: 'sk-MASTER-KEY'

Alertes Grafana recommandées

• Alerte si un modèle accumule plus de 5 erreurs en 5 minutes (signe de panne backend)
• Alerte si la latence moyenne dépasse 30 secondes sur les 10 dernières minutes
• Alerte si une équipe dépasse 80% de son budget mensuel cloud
• Alerte si le taux d'erreur global dépasse 5% sur 15 minutes

Intégration avec les outils existants

Open WebUI — interface chat d'équipe

docker run -d \
  --name open-webui \
  --network host \
  --restart unless-stopped \
  -e OPENAI_API_BASE_URL=http://localhost:4000 \
  -e OPENAI_API_KEY=sk-cle-openwebui-global \
  -e WEBUI_AUTH=True \
  -v /opt/open-webui:/app/backend/data \
  ghcr.io/open-webui/open-webui:main

AnythingLLM — RAG documentaire d'équipe

# Dans AnythingLLM : Paramètres → LLM Provider → Generic OpenAI
# Base URL : http://litellm-server:4000
# API Key  : sk-cle-anythingllm
# Model    : mistral-souverain

Continue.dev — copilote IDE des développeurs

{
  "models": [
    {
      "title": "Code Souverain (Qwen 2.5 Coder)",
      "provider": "openai",
      "model": "code-souverain",
      "apiBase": "http://litellm-server:4000",
      "apiKey": "sk-cle-equipe-dev"
    },
    {
      "title": "Mistral Souverain (chat/review)",
      "provider": "openai",
      "model": "mistral-souverain",
      "apiBase": "http://litellm-server:4000",
      "apiKey": "sk-cle-equipe-dev"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Autocomplete",
    "provider": "openai",
    "model": "code-souverain",
    "apiBase": "http://litellm-server:4000",
    "apiKey": "sk-cle-equipe-dev"
  }
}

LangChain — applications RAG et agents

# LangChain avec LiteLLM — aucune modification du code métier
from langchain_openai import ChatOpenAI, OpenAIEmbeddings

# LLM pour la génération
llm = ChatOpenAI(
    openai_api_base="http://litellm-server:4000",
    openai_api_key="sk-cle-data-team",
    model_name="mistral-souverain",
    temperature=0.1
)

# Embeddings locaux via LiteLLM
embeddings = OpenAIEmbeddings(
    openai_api_base="http://litellm-server:4000",
    openai_api_key="sk-cle-data-team",
    model="nomic-embed-text"  # Modèle d'embedding défini dans LiteLLM
)

# Le reste du code LangChain est identique à une intégration OpenAI standard

Alternatives à LiteLLM

Outil	Points forts	Points faibles	Licence	Hébergement
LiteLLM	100+ providers, budget control, logging riche, très actif	Config YAML parfois complexe, UI basique	MIT	Self-hosted
Portkey	Interface très soignée, guardrails intégrés, prompt management	Fonctions avancées payantes, moins de providers locaux	MIT + SaaS	Self-hosted ou SaaS
OpenRouter	SaaS clé en main, grand nombre de modèles, zéro infra	SaaS non souverain, données cloud, coût par token	SaaS propriétaire	SaaS uniquement
LocalAI	Alternative à Ollama avec proxy intégré, modèles spécialisés	Moins performant qu'Ollama, communauté plus petite	MIT	Self-hosted
Helicone	Observabilité avancée, A/B testing de prompts	Orienté observabilité, pas proxy complet	MIT + SaaS	Self-hosted ou SaaS

LiteLLM reste le choix le plus solide pour une DSI souveraine en 2026 : communauté très active (30k+ étoiles GitHub), 100+ providers, fonctionnalités de gouvernance complètes en version open-source, et une licence MIT sans restriction commerciale. Pour les équipes qui veulent uniquement de l'observabilité sans proxy, Langfuse en self-hosted est l'excellent complément naturel.