Ein gängiger, sinnvoller self-hosted Stack kombiniert ein LLM-Gateway (zum Beispiel LiteLLM) mit einer LLM-Observabilitätsplattform (zum Beispiel Langfuse). Wenn Sie einen haben, könnten Sie berechtigterweise fragen, ob Sie überhaupt ein Control Plane brauchen. Diese Seite beantwortet das ehrlich — einschließlich der Fälle, in denen die Antwort nein lautet.
TL;DR: LiteLLM und Langfuse drehen sich um die Modellaufrufe, die Ihre Anwendung macht: sie routen, tracen, Prompts verwalten, Kosten pro Aufruf verfolgen. Olivares AI dreht sich um jeden Agenten in Ihrer Infrastruktur und alles, was er liest oder schreibt — Datenbanken, Object Stores, MCP-Server, Tools, Dateien — und ob das mit dem übereinstimmt, was die Richtlinie erlaubt. Andere Flughöhe. Sie ergänzen sich; wir ingestieren dasselbe OpenTelemetry-GenAI-Signal, das sie emittieren und konsumieren.
Was dieser Stack gut kann (nutzen Sie ihn dafür)
- LiteLLM — ein einheitliches, OpenAI-kompatibles Gateway vor mehreren Anbietern: Routing, Fallbacks, Retries, virtuelle Schlüssel, Budgets und Rate Limits pro Schlüssel und Kostenabrechnung der Modellaufrufe, die durch es hindurchgehen.
- Langfuse — LLM-Engineering und Observabilität: Anfrage-/Antwort-Traces, Prompt-Management und -Versionierung, Evaluierungen, Datasets und eine entwicklerorientierte Oberfläche zum Debuggen von Chains.
Wenn Ihr Problem lautet „die LLM-Aufrufe meiner Anwendung instrumentieren, Prompts debuggen und Modellzugriff über einen einzigen Endpoint verwalten”, ist dieser Stack hervorragend und self-hostbar. Sie brauchen dafür kein Control Plane, und wir werden nicht das Gegenteil behaupten.
Wo Olivares AI strukturell anders ist
| Dimension | LLM-Gateway + Observabilität | Olivares AI |
|---|---|---|
| Betrachtungseinheit | Ein Modellaufruf (Prompt → Completion) | Ein Agent und jede Ressource, die er liest/schreibt — Datenbanken, Object Stores, MCP, Tools, Dateien |
| Beobachtungspunkt | Im Anfragepfad (Proxy/SDK); sieht, was die Anwendung sendet | Out of Band, read-first; beobachtet Telemetrie, native Auditierung und einen Kernel-Backstop — nie im Datenpfad |
| Quelle der Wahrheit | Was die Anwendung/der Proxy reportet | Selbst-reportete Telemetrie korroboriert gegen das eigene Protokoll des Systems — pgAudit (Lesen vs. Schreiben), CloudTrail (Objektzugriff), eBPF-Backstop |
| Die Schlüsselfrage | „Was hat dieser Prompt gemacht, und was hat er gekostet?” | „Nutzt dieser Agent Zugriffe, die ihm niemand gewährt hat?” — Permitted-vs-Observed-Drift |
| Enforcement | Gateway kann Modellaufrufe sperren (Schlüssel, Budgets) | Deny-closed Gates auf Aktionen und Ressourcenzugriff: Genehmigungen, der Claude Code Hooks PEP, MCP-Tool-Gating, Kill Switches |
| Audit-Artefakt | Traces / Logs zum Debuggen | Append-only, hash-verkettetes, Ed25519-signiertes Ledger, off-box verifizierbar, exportierbar als OSCAL-Evidenzpakete |
| Deployment-Haltung | Self-hostbar | Self-hosted oder air-gapped; Data Plane verlässt nie Ihren Perimeter; AGPL, Source-Available |
Der tragende Unterschied ist die Ground Truth. Ein Observability-Trace sagt Ihnen, was die Anwendung behauptet hat getan zu haben. Er kann Ihnen nicht sagen, dass ein Agent auf eine Tabelle zugegriffen hat, die der Trace nie erwähnt hat. Olivares AI gleicht das kooperative Signal gegen das Data Plane ab, sodass „was der Agent berührt hat” eine korroborierte Tatsache ist, kein Selbst-Report.
Es ist „und”, nicht „oder” — wir ingestieren Ihre Telemetrie
Olivares AI ist kein Ersatz für Ihr Gateway oder Ihr Tracing-Tool und möchte nicht im Anfragepfad sein, den diese besetzen. Es konsumiert dasselbe Signal: Das Control Plane ingestiert OpenTelemetry-GenAI-Semantic-Convention-Spans, dieselbe Gen-AI-Telemetrie, die diese Tools emittieren und konsumieren. Eine gesunde Anordnung ist also:
- Behalten Sie LiteLLM als Ihr Modell-Gateway und Langfuse für entwicklerorientiertes Tracing und Prompt-Arbeit.
- Richten Sie den OTel-Gen-AI-Stream auf Olivares AI als eine korroborierende Quelle und lassen Sie die Access Map, die Drift-Erkennung und das Ledger die infrastrukturweite Governance-Schicht darüber bilden.
Wann Sie nicht zu Olivares AI greifen sollten
Ehrlichkeit wirkt in beide Richtungen. Sie brauchen dieses Control Plane wahrscheinlich nicht, wenn:
- Ihr einziges Ziel Tracing und Debugging von LLM-Aufrufen in ein oder zwei Anwendungen ist, mit einem Prompt-Playground — Langfuse allein passt besser.
- Sie lediglich ein Multi-Provider-Gateway mit Budgets und Failover brauchen — das ist LiteLLMs Aufgabe, und wir integrieren uns mit diesem Muster, statt es zu reimplementieren.
- Sie keine Infrastruktur zu regieren haben: ein einzelner Service, ein einzelnes Modell, keine Agenten, die auf Datenbanken/Object Stores/MCP zugreifen, und keine Audit- oder regulatorische Verpflichtung.
Olivares AI verdient seinen Platz, wenn die Fragen infrastrukturweit und adversarial werden: Welche Agenten existieren, worauf kann jeder tatsächlich zugreifen, wo driftet der Zugriff von der Richtlinie ab, kann ich es einem Auditor beweisen, und kann ich eine schädliche Aktion deny-closed stoppen — all das, ohne dieses Bild in die Cloud eines Dritten zu senden.