LiteLLM : un proxy unifie pour router ses requetes LLM entre Ollama, vLLM et le cloud

LiteLLM : un proxy unifié pour router ses requêtes LLM entre Ollama, vLLM et le cloud

Quand on auto-héberge plusieurs backends LLM : Ollama pour le prototypage : vLLM pour la production GPU, un accès Claude ou GPT pour les cas complexes, la multiplication des endpoints et formats d’API devient vite un cauchemar d’intégration. LiteLLM résout ce problème en exposant une API unique compatible OpenAI qui route intelligemment les requêtes vers plus de 100 fournisseurs. C’est la couche d’abstraction qui manque entre applications et modèles.

Pourquoi un proxy LLM ?

Dans une stack IA auto-hébergée typique, chaque backend a son propre format d’appel, sa propre gestion des tokens, ses propres limites de débit. Vos applications (Open WebUI, n8n, agents MCP, scripts Python) doivent connaître chaque endpoint. Ajouter un nouveau modèle signifie modifier chaque client. LiteLLM inverse cette logique : vos applications parlent à un seul endpoint, et le proxy se charge du reste : traduction de format, load balancing, fallback automatique, et suivi de consommation.

Architecture et fonctionnement

LiteLLM se déploie comme un serveur proxy léger (Python/Docker) qui intercepte les appels au format OpenAI /v1/chat/completions et les traduit vers le backend cible. La configuration se fait via un fichier YAML déclaratif :

model_list:
  - model_name: "mistral-local"
    litellm_params:
      model: "ollama/mistral:7b"
      api_base: "http://ollama:11434"

  - model_name: "llama-prod"
    litellm_params:
      model: "hosted_vllm/meta-llama/Llama-3.1-70B"
      api_base: "http://vllm:8000/v1"

  - model_name: "claude-fallback"
    litellm_params:
      model: "claude-sonnet-4-20250514"
      api_key: "os.environ/ANTHROPIC_API_KEY"

router_settings:
  routing_strategy: "least-busy"
  num_retries: 3
  fallbacks:
    - llama-prod: ["mistral-local", "claude-fallback"]

Avec cette configuration, une requête vers llama-prod est envoyée à vLLM. Si vLLM est indisponible, LiteLLM bascule automatiquement sur Ollama, puis sur Claude en dernier recours, le tout transparent pour l’application appelante.

Déploiement Docker dans une stack existante

# docker-compose.yml (extrait)
services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./litellm-config.yaml:/app/config.yaml
    environment:
      - LITELLM_MASTER_KEY=sk-votre-cle-admin
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - DATABASE_URL=postgresql://user:pass@db:5432/litellm
    command: ["--config", "/app/config.yaml", "--port", "4000"]
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: litellm
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
    volumes:
      - litellm-db:/var/lib/postgresql/data

LiteLLM utilise PostgreSQL pour persister la configuration des clés virtuelles, les logs de requêtes et les budgets. L’interface d’administration web (port 4000) permet de gérer les modèles, créer des clés API par utilisateur ou par équipe, et visualiser les métriques de consommation en temps réel.

Fonctionnalités clés pour une infrastructure auto-hébergée

Clés virtuelles et budgets — Créez des clés API par projet ou par utilisateur avec des limites de dépense mensuelles. Idéal pour partager l’accès à des modèles cloud sans exposer vos clés API réelles. Chaque clé peut être restreinte à certains modèles.

Load balancing et fallbacks — Répartissez la charge entre plusieurs instances d’un même modèle (round-robin, least-busy, latency-based). Définissez des chaînes de fallback pour garantir la disponibilité : si votre GPU locale est saturée, la requête bascule vers le cloud.

Guardrails et modération — Intégrez des filtres de contenu (Presidio pour la détection PII, LlamaGuard, règles personnalisées) directement dans le proxy. Les requêtes sont analysées avant d’atteindre le modèle, ce qui centralise la politique de sécurité indépendamment des applications clientes.

Observabilité native — LiteLLM expose des métriques Prometheus (latence, tokens, coûts, erreurs) et supporte l’envoi de logs vers Langfuse, OpenTelemetry ou un simple callback. Combiné avec Grafana (déjà en place si vous suivez le guide observabilité), vous obtenez un tableau de bord complet de votre consommation LLM.

Intégration dans la stack askem

Voici comment LiteLLM s’insère dans une architecture type déjà en place :

Applications (Open WebUI, n8n, agents MCP, scripts)
        │
        ▼
   ┌─────────────┐
   │  LiteLLM    │  ← API unique OpenAI-compatible (:4000)
   │  Proxy      │  ← Clés virtuelles, budgets, guardrails
   └──────┬──────┘
          │
    ┌─────┼──────────┐
    ▼     ▼          ▼
 Ollama  vLLM    Claude API
 (:11434) (:8000)  (cloud)
    │     │
    ▼     ▼
  CPU    GPU

Open WebUI n’a plus besoin de connaître Ollama directement — il pointe vers http://litellm:4000/v1 et voit tous les modèles disponibles. n8n utilise le même endpoint. Vos agents MCP aussi. Un seul point de configuration, un seul jeu de métriques, une seule politique de sécurité.

Cas d’usage concret : routage par complexité

Un pattern puissant rendu possible par LiteLLM est le routage conditionnel. En configurant plusieurs modèles sous le même alias avec des priorités différentes, vous pouvez diriger les requêtes simples vers un petit modèle local rapide (Mistral 7B sur Ollama) et réserver le modèle lourd (Llama 70B sur vLLM ou Claude en cloud) aux requêtes nécessitant un raisonnement complexe. Côté application, un simple header x-litellm-model ou un tag dans le prompt suffit à orienter le routage.

Pour aller plus loin

LiteLLM est un projet open source actif (licence MIT, plus de 18 000 étoiles sur GitHub). La documentation officielle couvre l’intégration avec Keycloak pour le SSO admin, le déploiement sur Kubernetes via Helm, et la configuration avancée des guardrails. Pour une stack auto-hébergée qui grandit, c’est la brique de routage qui transforme un ensemble de modèles disparates en une plateforme LLM unifiée et gouvernée.