Powszechny i rozsadny self-hosted stos laczy bramke LLM (na przyklad LiteLLM) z platforma obserwowalnosci LLM (na przyklad Langfuse). Jesli taki posiadasz, mozesz zasadnie pytac, czy w ogole potrzebujesz planu kontroli. Ta strona odpowiada na to uczciwie — lacznie z przypadkami, gdy odpowiedz brzmi nie.
TL;DR: LiteLLM i Langfuse dotycza wywolan modeli, ktore Twoja aplikacja wykonuje: kieruj je, sledz, zarzadzaj promptami, monitoruj koszty na wywolanie. Olivares AI dotyczy kazdego agenta w Twoim srodowisku i wszystkiego, co czyta lub zapisuje — bazy danych, magazyny obiektow, serwery MCP, narzedzia, pliki — oraz tego, czy to sie zgadza z tym, na co pozwala polityka. Inna wysokosc. Komponuja sie; ingestujemy ten sam sygnal OpenTelemetry gen-ai, ktory one emituja.
Co ten stos robi dobrze (do tego nalezy go uzywac)
- LiteLLM — ujednolicona, kompatybilna z OpenAI bramka przed wieloma dostawcami: routing, fallbacki, ponowne proby, klucze wirtualne, budzety i limity per klucz oraz rozliczanie kosztow na wywolaniach modeli, ktore przez nia przechodza.
- Langfuse — inzynieria i obserwowalnosc LLM: trasy request/response, zarzadzanie promptami i wersjonowanie, ewaluacje, datasety i interfejs uzytkownika dla debugowania lancuchow.
Jesli Twoj problem to “oprzyrz wywolania LLM mojej aplikacji, debuguj prompty i zarzadzaj dostepem do modeli z jednego endpointu”, ten stos jest doskonaly i self-hosted. Nie potrzebujesz planu kontroli, aby to zrobic, i nie bedziemy udawac, ze jest inaczej.
Gdzie Olivares AI jest strukturalnie inny
| Wymiar | Bramka LLM + obserwowalnosc | Olivares AI |
|---|---|---|
| Jednostka zainteresowania | Wywolanie modelu (prompt -> completion) | Agent i kazdy zasob, ktory czyta/zapisuje — bazy danych, magazyny obiektow, MCP, narzedzia, pliki |
| Punkt obserwacji | W sciezce zadania (proxy/SDK); widzi, co aplikacja wysyla | Poza pasmem, read-first; obserwuje telemetrie, natywny audyt i backstop kernelowy — nigdy w sciezce danych |
| Zrodlo prawdy | Co aplikacja/proxy raportuje | Telemetria samoraportowana potwierdzona przez wlasny ledger systemu — pgAudit (odczyt vs zapis), CloudTrail (dostep do obiektow), backstop eBPF |
| Kluczowe pytanie | ”Co ten prompt zrobil i ile kosztowal?" | "Czy ten agent uzywa dostepu, ktorego nikt nie przyznal?” — dryf Permitted-vs-Observed |
| Egzekucja | Bramka moze kontrolowac wywolania modeli (klucze, budzety) | Bramy deny-closed na akcjach i dostepie do zasobow: zatwierdzenia, PEP Claude Code hooks, kontrola narzedzi MCP, kill switche |
| Artefakt audytu | Trasy / logi do debugowania | Ledger append-only, lancuchowy hash, podpisany Ed25519, weryfikowalny off-box, eksportowalny jako pakiety dowodow OSCAL |
| Model wdrozenia | Self-hosted | Self-hosted lub air-gapped; warstwa danych nigdy nie opuszcza Twojego perymetru; AGPL, source-available |
Nosna roznica to ground truth. Trasa obserwowalnosci mowi, co aplikacja twierdzila, ze zrobila. Nie jest w stanie powiedziec, ze agent dotarl do tabeli, o ktorej trasa nigdy nie wspomnila. Olivares AI sprawdza krzyzowo kooperacyjny sygnal z warstwa danych, wiec “czego agent dotarl” to potwierdzony fakt, a nie samoraport.
To “i”, nie “albo” — ingestujemy Twoja telemetrie
Olivares AI nie zastepuje Twojej bramki ani narzedzia do sledzenia i nie chce znajdowac sie w sciezce zadan, ktora zajmuja. Konsumuje ten sam sygnal: plan kontroli ingestuje spany OpenTelemetry GenAI semantic-convention, te sama telemetrie gen-ai, ktora te narzedzia emituja i konsumuja. Zatem zdrowy uklad to:
- Zachowaj LiteLLM jako bramke modeli i Langfuse do sledzenia i pracy z promptami od strony dewelopera.
- Skieruj strumien OTel gen-ai do Olivares AI jako jedno zrodlo potwierdzenia i pozwol mapie dostepu, detekcji dryftu i ledgerowi wykonac warstwa zarzadzania w calym srodowisku ponad tym.
Kiedy nie powinienes siegac po Olivares AI
Uczciwosc dziala w obie strony. Prawdopodobnie nie potrzebujesz tego planu kontroli, jesli:
- Twoim jedynym celem jest sledzenie i debugowanie wywolan LLM w jednej lub dwoch aplikacjach, z playgroundem promptow — sam Langfuse jest lepszym dopasowaniem.
- Potrzebujesz jedynie bramki wielodostawcowej z budzetami i failoverem — to zadanie LiteLLM i integrujemy sie z tym wzorcem zamiast go reimplementowac.
- Nie masz srodowiska do zarzadzania: jeden serwis, jeden model, brak agentow dotykajacych baz danych / magazynow obiektow / MCP i brak obowiazku audytu czy regulacyjnego.
Olivares AI zdobywa swoje miejsce, gdy pytania staja sie przekrojowe w calym srodowisku i adversarialne: jacy agenci istnieja, do czego kazdy faktycznie moze dotrzec, gdzie dostep dryftuje od polityki, czy moge to udowodnic audytorowi i czy moge zatrzymac zla akcje deny-closed — wszystko bez wysylania tego obrazu do czyjejs chmury.