Observabilité IA : Pourquoi j’ai créé LiteRouter pour monitorer Ollama

Ollama est un outil exceptionnel pour faire tourner des LLM en local, mais il souffre d’un défaut majeur : il est silencieux.

Une fois le serveur lancé, vous interagissez avec vos modèles, mais vous n’avez aucune visibilité sur ce qui se passe réellement sous le capot. Combien de tokens sont consommés par heure ? Quel modèle est le plus sollicité ? Quelle application sature vos ressources ? Dans un environnement professionnel, naviguer à vue est un risque.

C’est pour répondre à ce manque de visibilité que j’ai développé LiteRouter.

Le concept : La Gateway comme couche d’observabilité

L’idée derrière LiteRouter est simple : ne plus laisser vos clients (interfaces, agents, scripts) parler directement à Ollama, mais insérer un proxy intelligent entre les deux.

L’architecture est la suivante :

Plutôt que de modifier le code source d’Ollama, j’ai choisi d’implémenter une passerelle externe. Ce choix offre deux avantages majeurs :

1. Indépendance : Vous pouvez mettre à jour Ollama sans casser votre système de monitoring.
2. Modularité : La gateway peut évoluer pour ajouter du rate limiting ou du routage dynamique sans toucher au moteur d’inférence.

Le cœur technique : L’interception et le stockage

Pour construire LiteRouter, j’ai utilisé FastAPI pour sa rapidité et sa gestion native de l’asynchronisme, SQLite3 pour un stockage léger et un fichier configs.ini pour la configuration.

Le workflow de traitement :

1. Interception : La gateway reçoit la requête du client et la transmet telle quelle à l’API d’Ollama.
2. Analyse : Au retour de la réponse, LiteRouter intercepte le flux de données.
3. Extraction : L’outil extrait les métriques de consommation (tokens d’entrée et tokens de sortie) fournies par Ollama.
4. Persistance : Ces données, ainsi que le nom du modèle utilisé et l’horodatage, sont enregistrées instantanément dans SQLite.

En isolant cette logique dans une application distincte, on transforme un flux de données éphémère en une base de connaissances exploitable. On ne se contente plus de générer du texte, on génère des métriques.

Du stockage SQLite à la vision stratégique : Le Dashboard

L’accumulation de données dans une base SQLite est utile pour l’audit, mais elle est inexploitable pour une décision rapide. C’est pourquoi j’ai ajouté une couche de visualisation pour transformer ces lignes de logs en indicateurs de performance.

L’analyse d’un coup d’œil Le dashboard de LiteRouter se concentre sur trois métriques essentielles :

1. Le Volume Total : Le nombre global de tokens traités. C’est l’indicateur de charge de l’infrastructure.
2. Le Parc de Modèles : Le nombre de modèles actifs. Cela permet de voir immédiatement si l’on diversifie les usages.
3. Le Top Consumer : Le modèle le plus sollicité.

Exemple concret : En observant le dashboard, on peut constater un total de 1 700 tokens répartis sur deux modèles. Le constat est immédiat : gemma domine largement avec 1 400 tokens, tandis que qwen n’est utilisé que marginalement (300 tokens).

Ce type de visualisation change la nature de la gestion du serveur. Au lieu de supposer quel modèle est le plus utile, on a une preuve empirique. Si je constate qu’un modèle est sous-utilisé, je peux libérer la VRAM qu’il occupe pour en allouer à un modèle plus performant.

Analyse Critique : Atouts et Limites

Aucun outil n’est parfait. LiteRouter a été conçu pour la légèreté, ce qui implique certains compromis.

Les points forts :

• Non-intrusif : S’installe comme un proxy sans modifier l’installation d’Ollama.
• Performance : Le duo FastAPI + SQLite garantit une latence quasi nulle.
• Souveraineté : Toutes les métriques restent en local, sans dépendance cloud.

Les points de vigilance :

• Single Point of Failure : Si la gateway tombe, l’accès aux LLM est coupé.
• Passage à l’échelle : SQLite est parfait pour un usage individuel ou une petite équipe, mais pour des millions de logs, un passage vers PostgreSQL serait nécessaire.

Ouverture : Vers un contrôle intelligent du flux

Le monitoring n’est que la première étape. Une fois que l’on possède la donnée, on peut passer de l’observation au contrôle.

L’évolution naturelle de LiteRouter est de devenir un véritable “pare-feu” pour LLM. On peut imaginer des fonctionnalités de Dynamic Routing, où la gateway analyse la complexité de la requête pour l’envoyer vers un modèle léger (8B) ou un modèle puissant (70B) afin d’optimiser les ressources.

L’étape suivante est le Quota Management. En identifiant qui consomme quoi (en ajoutant une API-Key dans le Header par exemple), on peut instaurer des limites de tokens par utilisateur ou par application, évitant ainsi qu’un script mal optimisé ne sature l’ensemble du serveur.

Verdict Final : L’importance de l’observabilité

Beaucoup d’utilisateurs de LLM locaux s’arrêtent à la mise en place du moteur. C’est une erreur. Sans monitoring, vous ne gérez pas une infrastructure, vous espérez qu’elle tienne.

LiteRouter prouve qu’avec une couche logicielle légère, on peut transformer un outil “boîte noire” comme Ollama en un système transparent et auditable. L’observabilité n’est pas un bonus, c’est la condition sine qua non pour passer d’un usage exploratoire à une mise en production fiable. En rendant la consommation de tokens visible, on ne gagne pas seulement en technique, on gagne en capacité de décision.

Le code et les explications sont disponibles sur le répo GitHub.

• LiteRouter