Héberger LiteLLM sur un VPS : votre passerelle d'API LLM privée

Pourquoi LiteLLM est la couche manquante des stacks d'IA auto-hébergées

Ce que LiteLLM vous apporte d'emblée

• API unifiée et compatible OpenAI — fonctionne avec tous les SDK, bibliothèques et outils qui ciblent l'API d'OpenAI.
• Plus de 100 intégrations de fournisseurs : Ollama, Anthropic, OpenAI, Azure OpenAI, Mistral, Cohere, Bedrock et bien d'autres.
• Clés d'API virtuelles avec limites de dépenses et de débit par clé — distribuez des clés aux équipes et plafonnez les coûts mensuels.
• Tableau de bord intégré sur /ui avec analyse des dépenses en temps réel, ventilation par modèle et journaux des requêtes.
• Répartition de charge et bascule automatique entre plusieurs endpoints de fournisseurs ou réplicas de modèles.
• Licence Apache 2.0 — aucune télémétrie, aucune remontée d'informations vers l'extérieur, entièrement compatible air-gap une fois associée à Ollama.

Prérequis

Déployer LiteLLM sur un VPS

1. 01

   Provisionner le VPS

   Commandez un VPS Solo (2 vCPU, 4 GB, Ubuntu 22.04) : LiteLLM se contente d'un gigaoctet, le plus petit plan du catalogue en sert le double. Connectez-vous en SSH et installez Docker : curl -fsSL https://get.docker.com | sh. Le plugin Compose est inclus.

2. 02

   Générer les secrets

   Lancez openssl rand -hex 32 pour générer LITELLM_MASTER_KEY — elle déverrouille le tableau de bord et tous les endpoints d'API d'administration. Créez /opt/litellm/.env avec : LITELLM_MASTER_KEY, UI_USERNAME, UI_PASSWORD, DB_NAME=litellm, DB_USER=litellm, DB_PASSWORD=<strong-password>.

3. 03

   Rédiger docker-compose.yml

   Créez /opt/litellm/docker-compose.yml avec deux services : db (postgres:16-alpine, variables d'environnement issues du .env, volume litellm_db) et litellm (image ghcr.io/berriai/litellm épinglée sur une version explicite et son condensat @sha256:, jamais sur main-latest — voir « Chaîne d'approvisionnement » plus bas —, port 4000:4000, depends_on db, DATABASE_URL + LITELLM_MASTER_KEY + UI_USERNAME + UI_PASSWORD, volume litellm_config:/app/data). Lancez docker compose up -d.

4. 04

   Ouvrir le tableau de bord

   Rendez-vous sur http://<vps-ip>:4000/ui et connectez-vous avec vos UI_USERNAME / UI_PASSWORD. Vous arrivez sur le tableau de bord de LiteLLM. Allez dans Models pour ajouter votre premier fournisseur. Pour une instance Ollama locale sur le même VPS, définissez le nom du modèle sur ollama/llama3.1 et l'API base sur http://host.docker.internal:11434. Pour Anthropic, collez votre clé d'API et ajoutez anthropic/claude-3-5-haiku-20241022.

5. 05

   Tester la passerelle

   Depuis votre poste de travail, testez : curl http://<vps-ip>:4000/v1/chat/completions -H "Authorization: Bearer <LITELLM_MASTER_KEY>" -H 'Content-Type: application/json' -d '{"model": "ollama/llama3.1", "messages": [{"role": "user", "content": "Hello"}]}'. Vous devriez recevoir une réponse en streaming — acheminée par LiteLLM vers votre Ollama.

6. 06

   Distribuer des clés d'API aux équipes

   Dans le tableau de bord, sous API Keys, cliquez sur New Key. Donnez-lui une description (par exemple « frontend-team »), définissez max_budget: 50 (USD/mois) et un tpm_limit facultatif. Partagez cette clé avec l'équipe — elle pointe son SDK OpenAI vers http://<vps-ip>:4000 et utilise cette clé. Les dépenses sont suivies par clé dans le tableau de bord.

7. 07

   Ajouter le HTTPS avec Caddy

   Installez Caddy : apt install -y caddy. Éditez /etc/caddy/Caddyfile : llm.votre-domaine.com { reverse_proxy localhost:4000 }. Rechargez : systemctl reload caddy. Fermez le port 4000 dans votre pare-feu — tout le trafic passe désormais par le 443 avec TLS automatique.

8. 08

   Se connecter la première fois

   Ouvrez l'interface d'administration sur /ui : LiteLLM affiche un formulaire identifiant/mot de passe. Saisissez admin et le mot de passe fourni, puis créez vos clés virtuelles depuis le tableau de bord.

Chaîne d'approvisionnement : épingler, vérifier, faire tourner les clés

Savoir ce qui tourne réellement chez vous

1. 09

   Relever le condensat de l'image

   Un tag comme main-latest ne dit rien de ce qui s'exécute. Lancez docker compose images puis docker image inspect --format '{{index .RepoDigests 0}}' ghcr.io/berriai/litellm:main-latest (remplacez par la référence de votre fichier compose). Notez le sha256: obtenu et comparez-le à celui d'une version dont vous avez vérifié la provenance.

2. 10

   Chercher les fichiers cités, sans lancer Python

   Dans un environnement suspect, tout démarrage de Python rejoue le code malveillant, pip compris. Cherchez donc avec un outil qui n'en lance pas : docker compose exec litellm find / -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' -o -name 'litellm-1.107.0.dist-info' 2>/dev/null (si l'image fournit find). Un sitecustomize.py isolé ailleurs sur le système peut être légitime ; ce qui alerte, c'est un cook.pth à côté dans site-packages, ou un dossier litellm-1.107.0.dist-info. Trouver ces fichiers confirme l'exposition ; ne rien trouver ne prouve pas que l'environnement est sain.

3. 11

   Lire la version installée

   Hors de tout soupçon, pip show litellm (dans l'environnement virtuel d'une installation directe) ou docker compose exec litellm pip show litellm indique la version. Si c'est la 1.107.0, ou si vous avez un doute sur une image tirée à cette période, passez à la rotation des clés plus bas sans attendre.

4. 12

   Chercher les traces d'exécution

   Le rapport signale un verrou /tmp/remote_code_loader.lock, un processus python orphelin dont le répertoire courant est /, et un fichier témoin /tmp/.pc_once_* écrit seulement après un envoi réussi. Son absence ne prouve rien : un conteneur recréé efface /tmp. Servez-vous-en comme d'un indice, pas comme d'un verdict.

Épingler par condensat plutôt que par tag

Mettre à jour sans se faire surprendre

• Lisez les notes de version et l'état du fil de sécurité avant de changer de version, plutôt que de laisser docker compose pull suivre un tag.
• Récupérez le nouveau condensat depuis une machine de test, lancez la passerelle sans clés réelles, vérifiez-en le comportement, puis seulement reportez le condensat en production.
• Quand l'éditeur publie des attestations de provenance, vérifiez-les : elles disent d'où vient l'image, ce qu'un simple condensat ne dit pas.
• Conservez l'ancien condensat dans votre dépôt de configuration : revenir en arrière devient un changement d'une ligne.
• Après toute alerte de sécurité, reconstruisez les conteneurs et les environnements virtuels à neuf plutôt que de nettoyer sur place.

Si la 1.107.0 a tourné chez vous : faire tourner toutes les clés

Ce qu'il faut renouveler

• Toutes les clés de fournisseurs enregistrées dans la passerelle : Anthropic, OpenAI, Azure, Mistral, Bedrock et chacune des autres.
• LITELLM_MASTER_KEY et toutes les clés virtuelles distribuées aux équipes.
• Le mot de passe de la base (DB_PASSWORD et le DATABASE_URL qui l'embarque), ainsi que UI_PASSWORD.
• Tout secret présent dans l'environnement d'un processus de l'hôte : jetons d'API, mots de passe de services voisins, fichiers .env.
• Les clés SSH, jetons Git et identifiants cloud accessibles depuis le VPS, si l'hôte en portait.
• Après rotation, reconstruisez le VPS ou au minimum les conteneurs depuis une image vérifiée : copier de nouveaux secrets dans un hôte compromis les expose à nouveau.