Ce que LiteLLM ne peut pas voir : le suivi du traitement par GPU via le gateway

Pas de passer d’un gateway FastAPI manuellement développé à LiteLLM, qui centralise les journaux des requêtes, la gestion des tokens et des clés virtuelles, tout en réduisant le code du gateway personnalisé. Un gateway ne voit toujours que le trafic qui traverse ses limites. Le déploiement en production a soulevé toute une série de questions auxquelles LiteLLM seul ne peut pas répondre : questions concernant les files d’attente, le mode de préremplissage par rapport au décodage, la redémarrage des conteneurs, ainsi que la saturation du hôte, éléments qui permettent de déterminer si une appel d’une durée de onze secondes s’est déroulé normalement ou est resté bloqué.

Contexte

LiteLLM se trouve au niveau des requêtes. Il enregistre l’arrivée d’un appel, le modèle qui l’a traité, le nombre de tokens utilisés, la clé virtuelle qui a payé, ainsi que le résultat réussi ou échoué. Pour un suivi quotidien des coûts, c’est presque tout ce dont les services financiers et les équipes de développement ont besoin.

Au-delà de cette limite, la situation change. Une requête d’une durée de onze secondes peut entraîner une attente dans la file d’attente sur une GPU saturée ou générer correctement une réponse longue. Vus depuis le gateway, ces cas semblent identiques ; en réalité, les solutions ne le sont pas. Les traiter comme une seule métrique oriente à tort les équipes de surveillance.

Trois niveaux en dessous du gateway nécessitent chacun leurs propres indicateurs fiables :

• Le temps d’exécution du modèle, où est déterminée la latence. Le temps nécessaire pour obtenir le premier token combine l’attente dans la file d’attente et le préremplissage, plus que la simple décodification. Les capacités de préremplissage et de décodification créent des goulots d’étranglement différents. Ces données proviennent du /metrics propre au moteur de service (par exemple vLLM), et non du gateway.
• Les conteneurs, via cAdvisor : quel processus consomme de la mémoire, quel conteneur a été redémarré pendant la nuit.
• Les hôtes, via node-exporter : consommation totale en CPU, mémoire et disque sur l’ordinateur qui héberge les GPU.

Quatre sources sont importantes car aucun collecteur ne peut voir toutes les couches. Les journaux du Gateway sans métriques en temps réel ne donnent qu’une vision partielle ; les métriques en temps réel sans contexte du hôte et du conteneur ignorent le « voisin bruyant » qui a redémarré à trois heures du matin.

Tout le stack

Sur un serveur GPU local, deux projets Docker Compose séparent délibérément les responsabilités.

Composé Gateway : LiteLLM, PostgreSQL pour les clés virtuelles et les dépenses, Redis pour le cache de limitation de fréquence.

Composé de surveillance : Prometheus, Grafana, node-exporter, cAdvisor. Les processus vLLM s’exécutent souvent sur le hôte, en dehors des deux stacks, un processus par modèle servi. Prometheus extrait les données des quatre cibles qui couvrent les métriques liées au Gateway et celles propres aux modèles. Cette séparation n’est pas esthétique — c’est ainsi que l’infrastructure optionnelle reste optionnelle.

Décisions clés

1. Deux fichiers compose, et non un seul. LiteLLM servait déjà d’autres équipes lorsque la fonction de surveillance a été ajoutée. Intégrer Prometheus dans le même fichier compose lierait chaque modification du fichier de configuration de collecte des données au fichier du gateway en production. La séparation permet l’isolation des pannes : on peut reconstruire la surveillance librement sans que LiteLLM ne s’en aperçoive. La dépendance s’effectue dans un seul sens. Le réseau entre les différentes couches représente un coût unique face au risque permanent de propagation des problèmes. Si la surveillance tombe en panne, les modèles continuent de fonctionner ; si le gateway tombe en panne, la surveillance continue d’enregistrer l’état du hôte pour les analyses post-mortem.

2. Aucun postgres-exporter ni redis-exporter par défaut. Le hôte pourrait les exécuter sans problème. Ils ont néanmoins été reportés :

• Tant que LiteLLM fonctionne correctement, les composants internes de la base de données et du cache n’ont que rarement besoin d’un tableau de bord ; les pannes apparaissent d’abord au niveau du gateway.

node-exporter, cAdvisor et les points de terminaison du modèle /metrics couvrent déjà les couches essentielles.

Les exporteurs supplémentaires représentent des versions additionnelles ainsi qu’une consommation mémoire opérationnelle supplémentaire.

Les tableaux de bord inutilisés entraînent des coûts d’entretien sans aucun avantage. Réexaminez la situation lorsque les erreurs de connexion à PostgreSQL deviennent fréquentes, que l’authentification par clé virtuelle ralentit en raison de la concurrence des requêtes, ou que la pression mémoire sur Redis devient une préoccupation réelle — ajoutez alors des exporteurs cette même semaine. Notez les critères permettant de revenir en arrière afin que l’option d’ignorer ces éléments reste une décision consciente et non le résultat de l’amnésie.

3. Maintenir Langfuse. LiteLLM permet de centraliser l’observabilité des requêtes, mais une seule action produit souvent de multiples appels au modèle : récupération, résumé, suivi. Les identifiants de session partagés peuvent regrouper ces appels dans LiteLLM, mais l’analyse de l’expérience utilisateur et du taux de rétention diffère. Les journaux du gateway ne sont pas conçus comme des archives indéfinies. Les traces plus anciennes alimentent les ensembles d’évaluation pour le remplacement des modèles et aident à déboguer les rapports des semaines précédentes. Les métriques permettent de faire des agrégations ; les traces, en revanche, permettent de reconstituer l’historique. Aucune quantité de métriques ne couvre pleinement l’historique des traces — c’est pourquoi les deux sont nécessaires.

L’utiliser en pratique

1. Déclarer les modèles uniquement dans config.yaml était problématique. Les modèles stockés dans des fichiers affichent un badge de configuration dans l’interface et ne peuvent être modifiés ou supprimés sans modifier le point de montage et recharger un proxy en cours d’utilisation. Les modèles enregistrés via l’API d’administration sont stockés dans PostgreSQL et survivent aux redémarrages :

curl -X POST <http://localhost:4000/model/new> \
  -H "Authorization: Bearer$LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model_name": "CHAT_MODEL",
    "litellm_params": {
      "model": "openai/CHAT_MODEL",
      "api_base": "<http://host.docker.internal:8001/v1>",
      "api_key": "dummy"
    }
  }'

Préférez la configuration pour les paramètres et la base de données pour le catalogue des modèles. Cette séparation permet aux opérateurs d’ajouter un modèle expérimental sans affecter le processus de passerelle utilisé par les autres équipes.

2. Le tableau de bord Node-Exporter a été peu utilisé. Une fois les charges de travail stabilisées et les déploiements ralentis, les totaux par hôte ont cessé de fournir des informations utiles. Conservez l’outil de collecte de données ; ne investissez pas excessivement dans des panneaux inutilisés. Les panneaux cAdvisor et vLLM ont reçu plus d’attention quotidienne car ils reflètent la latence visible par les utilisateurs.

3. Points de départ utiles pour Grafana

• Tableaux de bord communautaires vLLM (par exemple le tableau de bord public grafana.com numéro 23991)
• cAdvisor (14282)
• Node Exporter Full (1860)

Importez-les en tant que références de base, puis supprimez les panneaux qui ne sont jamais ouverts.

En résumé

La notification constitue évidemment une lacune : des métriques existent, mais aucune page n’est activée lorsque les seuils sont dépassés. L’intégration des API de messagerie des applications aux hôtes GPU mélange des problématiques différentes ; choisissez plutôt une méthode de notification plus sûre. Conceptuellement, Prometheus et Grafana répondent aux questions qui sont déjà connues ; Langfuse, quant à lui, reconstitue l’impact d’une action utilisateur à travers les appels déclenchés. L’agrégation et la reconstitution sont complémentaires. Une migration vers un gateway sans plan de surveillance ne fait que déplacer le point aveugle d’un niveau en bas.