Une pile self-hosted courante et judicieuse associe un LLM gateway (par exemple LiteLLM) a une plateforme d’observabilite LLM (par exemple Langfuse). Si vous en disposez, vous pouvez raisonnablement vous demander si vous avez besoin d’un plan de controle. Cette page repond honnetement — y compris dans les cas ou la reponse est non.
TL;DR: LiteLLM et Langfuse concernent les appels aux modeles de votre application : les router, les tracer, gerer les prompts, suivre le cout par appel. Olivares AI concerne chaque agent de votre estate et tout ce qu’il lit ou ecrit — bases de donnees, object stores, serveurs MCP, outils, fichiers — et si cela correspond a ce que la politique autorise. Altitude differente. Ils se composent ; nous ingerons le meme signal OpenTelemetry gen-ai qu’ils emettent.
Ce que cette pile fait bien (utilisez-la pour cela)
- LiteLLM — un gateway unifie, compatible OpenAI, devant de nombreux fournisseurs : routage, fallbacks, retries, cles virtuelles, budgets et limites de debit par cle, et comptabilite des couts sur les appels aux modeles qui le traversent.
- Langfuse — ingenierie et observabilite LLM : traces requete/reponse, gestion et versionnage de prompts, evaluations, datasets et une interface developpeur pour le debogage des chaines.
Si votre probleme est “instrumenter les appels LLM de mon application, deboguer les prompts et gerer l’acces aux modeles depuis un point d’acces unique”, cette pile est excellente et auto-hebergeable. Vous n’avez pas besoin d’un plan de controle pour cela, et nous ne pretendrons pas le contraire.
La ou Olivares AI est structurellement different
| Dimension | LLM gateway + observabilite | Olivares AI |
|---|---|---|
| Unite de preoccupation | Un appel au modele (prompt puis completion) | Un agent et chaque ressource qu’il lit/ecrit — BDD, object stores, MCP, outils, fichiers |
| Point d’observation | Dans le chemin de requete (proxy/SDK) ; voit ce que l’application envoie | Hors bande, read-first ; observe la telemetrie, l’audit natif et un backstop noyau — jamais dans le chemin de donnees |
| Source de verite | Ce que l’application/proxy declare | Telemetrie auto-reportee corroboree avec le registre propre du systeme — pgAudit (lecture vs ecriture), CloudTrail (acces aux objets), backstop eBPF |
| La question cle | ”Qu’a fait ce prompt, et combien a-t-il coute ?" | "Cet agent utilise-t-il un acces que personne n’a accorde ?” — derive Permitted-vs-Observed |
| Enforcement | Le gateway peut bloquer les appels aux modeles (cles, budgets) | Portes deny-closed sur les actions et l’acces aux ressources : approbations, le PEP de hooks Claude Code, controle d’acces MCP, kill switches |
| Artefact d’audit | Traces / logs pour le debogage | Ledger append-only, chaine par hash, signe Ed25519, verifiable hors serveur, exportable en paquets de preuve OSCAL |
| Posture de deploiement | Auto-hebergeable | Auto-heberge ou air-gapped ; le plan de donnees ne quitte jamais votre perimetre ; AGPL, source-available |
La difference porteuse est la verite de base. Une trace d’observabilite vous dit ce que l’application a declare avoir fait. Elle ne peut pas vous dire qu’un agent a atteint une table que la trace n’a jamais mentionnee. Olivares AI croise le signal cooperatif avec le plan de donnees, de sorte que “ce que l’agent a touche” est un fait corrobore, pas une auto-declaration.
C’est “et”, pas “ou” — nous ingerons votre telemetrie
Olivares AI n’est pas un remplacement de votre gateway ou de votre outil de tracage, et ne souhaite pas etre dans le chemin de requete qu’ils occupent. Il consomme le meme signal : le plan de controle ingere les spans de convention semantique OpenTelemetry GenAI, la meme telemetrie gen-ai que ces outils emettent et consomment. Un agencement sain est donc :
- Conservez LiteLLM comme gateway de modeles et Langfuse pour le tracage cote developpeur et le travail sur les prompts.
- Dirigez le flux OTel gen-ai vers Olivares AI comme source de corroboration, et laissez la carte d’acces, la detection de derive et le ledger assurer la couche de gouvernance a l’echelle de l’estate par-dessus.
Quand vous ne devriez pas utiliser Olivares AI
L’honnetete fonctionne dans les deux sens. Vous n’avez probablement pas besoin de ce plan de controle si :
- Votre seul objectif est le tracage et le debogage des appels LLM dans une ou deux applications, avec un playground de prompts — Langfuse seul convient mieux.
- Vous avez simplement besoin d’un gateway multi-fournisseur avec budgets et failover — c’est le role de LiteLLM, et nous nous integrons a ce schema plutot que de le reimplementer.
- Vous n’avez pas d’estate a gouverner : un seul service, un seul modele, pas d’agents accedant a des bases de donnees/object stores/MCP, et aucune obligation d’audit ou reglementaire.
Olivares AI gagne sa place lorsque les questions deviennent transversales a l’infrastructure et adversariales : quels agents existent, qu’est-ce que chacun peut reellement atteindre, ou l’acces derive-t-il de la politique, puis-je le prouver a un auditeur, et puis-je arreter une mauvaise action deny-closed — le tout sans envoyer ce tableau dans le cloud d’un tiers.