Dlaczego narzędzia do śledzenia LLM budują teraz bramy AI

W 2026 roku LangSmith, Langfuse, Opik i Braintrust dodali bramę pośredniczącą między aplikacjami a dostawcami modeli. Głównym powodem jest możliwość sprawowania kontroli: narzędzie do śledzenia może jedynie rejestrować wywołania modelu, a brama może je zatrzymać.

Dwa narzędzia do odrębnych zadań

Przez ostatnie dwa lata wiele zespołów korzystało w aplikacjach opartych na dużych modelach językowych (LLM) z dwóch oddzielnych narzędzi. Między aplikacją a dostawcami modeli znajdowała się brama. Przechowywała klucze API dostawców, tłumaczyła wywołania między interfejsami API poszczególnych dostawców i ponawiała nieudane żądania. LiteLLM, otwartoźródłowe oprogramowanie pośredniczące, stało się popularnym rozwiązaniem do tego celu. Obok aplikacji działało narzędzie do śledzenia, takie jak LangSmith lub Langfuse, które rejestrowało każde wywołanie modelu i narzędzia oraz każdy etap pobierania danych, dzięki czemu inżynierowie mogli sprawdzić, co zrobił agent.

Podział miał sens: brama musi działać szybko i obsługiwać interfejsy API wszystkich dostawców, natomiast narzędzie do śledzenia potrzebuje dobrego interfejsu, miejsca na duże zasoby danych oraz pakietu SDK, który opakowuje kod aplikacji. Langfuse nadal opisuje konfigurację z dwoma narzędziami i integracją oprogramowania pośredniczącego LiteLLM Proxy, która kieruje każde wywołanie przez to oprogramowanie, a następnie do Langfuse. W 2026 roku dostawcy narzędzi do śledzenia zaczęli samodzielnie budować bramy.

Cztery premiery w ciągu sześciu miesięcy

W maju 2026 roku LangChain ogłosił prywatną wersję beta bramy LLM LangSmith, a 30 lipca udostępnił ją w publicznej wersji beta. Później włączył ją również do wdrożeń LangSmith w modelu własnej chmury. Braintrust wycofał swoje wcześniejsze oprogramowanie pośredniczące AI i skierował użytkowników do nowej bramy, dostępnej w wersji zapoznawczej i bezpłatnej do czasu ogólnej dostępności. Comet udostępnił bramę LLM Opik jako punkt końcowy w wersji beta, który przyjmuje żądania w formacie OpenAI. 4 listopada Langfuse udostępnił swoją bramę AI w publicznej wersji beta, zarówno w Langfuse Cloud, jak i w przypadku wdrożeń na własnej infrastrukturze. Brama jest objęta licencją MIT i napisana w języku Rust.

MLflow, który powstał jako narzędzie do zarządzania cyklem życia uczenia maszynowego, a nie do śledzenia, oferuje bramę AI już od dłuższego czasu, wraz z alertami i limitami budżetowymi.

Bramy istnieją od lat, a ryzyko związane z ich uruchamianiem zostało dobrze opisane. Nowe bramy powstają w firmach, których działalność polegała na rejestrowaniu wywołań modeli; teraz firmy te chcą, aby każde wywołanie najpierw przechodziło przez ich bramę.

Dlaczego kontrola budżetu wymaga obsługi żądań

Narzędzie do śledzenia rejestruje wywołanie modelu dopiero po odpowiedzi dostawcy i opłaceniu tokenów. Taki zapis wystarcza do sporządzenia wykresu wydatków, ale narzędzie do śledzenia nie może ich powstrzymać. Egzekwowanie budżetu zespołu, blokowanie modelu lub usuwanie sekretu z promptu wymaga sprawdzenia żądania, zanim dotrze ono do dostawcy. Może to zrobić tylko komponent, przez który przechodzi żądanie.

LangChain przedstawia ten argument w wpisie zapowiadającym premierę. Opisuje zespoły łączące oddzielną bramę, narzędzie do wdrażania zabezpieczeń i narzędzie do monitorowania, a także podkreśla, że zapobieganie problemom wymaga egzekwowania zasad na poziomie żądań. Gdy żądanie przekroczyłoby budżet, brama zwraca kod statusu HTTP 402 zamiast przekazywać je dostawcy.

Jeden punkt dostępu rejestruje każde wywołanie

Drugim powodem jest pełny zakres rejestrowania. Pakiet SDK rejestruje tylko te ścieżki w kodzie, które ktoś objął instrumentacją. To właśnie poza nimi niepowodzenia agentów często pozostają niezauważone. Skrypt uruchomiony na laptopie, notatnik lub agent programistyczny korzystający ze skopiowanego klucza API nie pozostawia śladu. Brama przechowująca klucze dostawców widzi każde wywołanie, ponieważ nie ma innej drogi do dostawcy.

Langfuse buduje swoją bramę wokół tej koncepcji. Jak podaje dokumentacja bramy, każdy klucz bramy jest przypisany do użytkownika lub konta usługi i może zawierać metadane, takie jak zespół lub centrum kosztów. Tylko brama przechowuje dane uwierzytelniające dostawcy, a administratorzy zatwierdzają, z których modeli można korzystać za pomocą poszczególnych danych uwierzytelniających. LangSmith udostępnia strony konfiguracji opisujące kierowanie Claude Code, Codex i Gemini CLI przez swoją bramę. Agenci ci wywołują modele z komputera programisty, poza kodem śledzącym aplikacji.

Co daje brama zintegrowana z narzędziem do śledzenia

Dostawcy narzędzi do śledzenia przedstawiają też odwrotny argument: samodzielna brama nie wystarczy. We wpisie zapowiadającym premierę Langfuse stwierdza, że samodzielna brama może jedynie zliczać tokeny i koszty, podczas gdy ich własna brama sprawia, że każde wywołanie staje się częścią pełnego śladu. Brama Langfuse akceptuje nagłówek W3C traceparent, dzięki czemu wywołanie przechodzące przez tę bramę zostaje włączone do śladu rozpoczętego już przez aplikację. Domyślnie rejestrowane są wykorzystanie i koszt, a nie treść promptu ani odpowiedzi.

To najmocniejszy argument techniczny za zintegrowaniem bramy z narzędziem do śledzenia. Samodzielna brama widzi płaską listę odpowiedzi modelu. Narzędzie do śledzenia ma już dzięki pakietowi SDK informacje o wywołaniach narzędzi i etapach pobierania danych przez agenta, więc może umieścić każde wywołanie przechodzące przez bramę w tej strukturze.

Jest też aspekt komercyjny, którego sami dostawcy nie podkreślają. Kto zarządza bramą, ten ma klucze dostawców i raport wydatków, z którego korzystają zespoły finansowe i platformowe. To sprawia, że bramę trudniej zastąpić niż przeglądarkę śladów. LangSmith i Langfuse już teraz wykorzystują tę pozycję na różne sposoby: LangSmith sprzedaje Gateway Credits, które pozwalają klientom wywoływać hostowane modele, takie jak Kimi, bez używania własnego klucza dostawcy, a w FAQ Langfuse informuje, że nie odsprzedaje tokenów.

Czego bramy w wersji beta jeszcze nie potrafią

Te bramy są nowe, a dostawcy sami opisują ich ograniczenia. Obecnie brama Langfuse obsługuje tylko OpenAI i Anthropic; Amazon Bedrock, Google Vertex AI i Google AI Studio znajdują się na jej planie rozwoju. Mechanizmy awaryjnego przełączania między dostawcami oraz twarde limity wydatków dla zespołu, użytkownika lub klucza są planowane, ale jeszcze ich nie wdrożono. Na razie brama udostępnia panel wydatków i alerty. Dokumentacja nie wspomina o limitach liczby żądań ani buforowaniu odpowiedzi.

Brama Langfuse nie konwertuje między formatami API, dlatego klient OpenAI może wywoływać tylko modele OpenAI. Wersja hostowana samodzielnie łączy się wyłącznie z oficjalnymi adresami URL dostawców, co na razie wyklucza Azure OpenAI, Bedrock i wewnętrzne serwery proxy. Comet opisuje bramę Opik jako przeznaczoną do programowania i testowania. Braintrust nie ogłosił cen swojej bramy.

Brama LangSmith oferuje już więcej niż pozostałe. W dokumentacji wymieniono mechanizmy awaryjnego przełączania, limity wydatków, limity liczby żądań i zasady dotyczące danych jako dostępne funkcje; obsługiwane są też formaty OpenAI Chat Completions, OpenAI Responses i Anthropic Messages. W maju mechanizmy awaryjnego przełączania i limity liczby żądań były wymienione jako planowane funkcje, więc pojawiły się w trakcie testów beta. Cały produkt nadal jest oznaczony jako beta.

Testy obciążeniowe ujawniają inny rodzaj ograniczeń. Test porównawczy hostowanych samodzielnie bramy Langfuse, LiteLLM i AcruxCore wykazał, że brama Langfuse zwiększała opóźnienie każdego wywołania mniej niż LiteLLM. Jednak przy domyślnych ustawieniach Dockera nie obsłużyła 739 z 1000 jednoczesnych strumieni, ponieważ jej proces zachował domyślny limit Dockera wynoszący 1024 otwarte pliki. Wystarczyła jedna linijka w pliku Compose Langfuse, by rozwiązać ten problem.

W porównaniu z tymi wersjami beta LiteLLM, samodzielna brama działająca od lat, obsługuje ponad 100 dostawców i już oferuje klucze wirtualne, śledzenie wydatków, mechanizmy ochronne, równoważenie obciążenia oraz panel administracyjny. LiteLLM przenosi też obsługę żądań z Pythona do języka Rust. Brama AI w Rust jest w wersji beta, a zespół LiteLLM spodziewa się, że żądania w stylu Anthropic /v1/messages będą w całości obsługiwane w Rust do 1 grudnia, przy około 20-krotnie mniejszym opóźnieniu. Niektóre platformy open source, takie jak MLflow i AcruxCore, już łączą bramę i śledzenie w jednym produkcie.

Argumenty za ich rozdzieleniem

Połączenie bramy z narzędziem śledzącym ma swoje koszty, a największym z nich jest ścisłe powiązanie obu komponentów. Gdy brama jest osobnym elementem, zespół może zmienić dostawcę narzędzia do śledzenia, modyfikując funkcję wywoływaną przy logowaniu. Jeśli narzędzie śledzące pełni też funkcję bramy, trzeba zmienić również podstawowy adres URL, klucze i identyfikatory modeli we wszystkich usługach. Na przykład Langfuse zapisuje identyfikatory modeli w postaci credential:model.

Narzędzie śledzące staje się też zależnością wymaganą w czasie działania. Jeśli przestanie działać zaplecze do śledzenia, zespół traci ślady. Jeśli przestanie działać brama, wywołania modeli kończą się niepowodzeniem. Dostawca narzędzia do śledzenia, który obsługuje bramę, musi teraz zapewnić jej dostępność na poziomie wymaganym od infrastruktury krytycznej.

Dostawcy rozwiązań bezpieczeństwa również chcą zająć to samo miejsce na ścieżce obsługi żądań. Palo Alto Networks sfinalizowało przejęcie Portkey, samodzielnej bramy, w maju 2026 roku i uczyniło ją bramą AI swojej platformy Prisma AIRS. Zespół ds. bezpieczeństwa może chcieć samodzielnie kontrolować bramę, zamiast umieszczać ją w narzędziu do obserwowalności. Bramy stały się też celem ataków, o czym świadczy naruszenie łańcucha dostaw LiteLLM w marcu.

Jak zespoły mogą dokonać wyboru

Zespoły mogą zacząć od sporządzenia listy czynności, które muszą być wykonane przed wywołaniem modelu. Jeśli potrzebują tylko wglądu, wystarczy narzędzie do śledzenia działające obok ścieżki obsługi żądań, które nie wprowadza zależności wymaganej w czasie działania. Jeśli potrzebują również budżetów, zasad dotyczących kluczy lub zatwierdzania modeli, konieczna jest brama.

Kolejnym kryterium jest zakres obsługiwanych dostawców. Zespół powinien spisać wszystkich dostawców i formaty API wykorzystywane w środowisku produkcyjnym, w tym Azure OpenAI i Bedrock, a następnie porównać tę listę z aktualnie obsługiwanymi rozwiązaniami każdej bramy, a nie z jej planem rozwoju.

Zespoły, które już korzystają z LiteLLM, mają niewiele powodów, by przechodzić na inne rozwiązanie, dopóki brama w wersji beta nie zaoferuje czegoś, czego im brakuje. Główną korzyścią, jaką daje brama wbudowana w narzędzie do śledzenia, jest umieszczenie wywołania bramy w śladzie działania agenta; taka korzyść musi uzasadniać migrację. Zespoły rozpoczynające pracę od zera mogą zachować bramę jako osobną warstwę, nawet jeśli oba rozwiązania dostarcza ten sam producent. Przechowywanie podstawowego adresu URL i kluczy w jednym module konfiguracyjnym sprawia, że późniejsza zmiana wymaga modyfikacji konfiguracji, a nie kodu.

Większość tych bram jest oznaczona jako beta lub wersja zapoznawcza, więc lista ich ograniczeń szybko się skróci. Otwarta pozostaje kwestia tego, kto będzie zarządzać ścieżką obsługi żądań w typowej firmie: zespół ds. obserwowalności, zespół platformowy obsługujący samodzielną bramę czy zespół ds. bezpieczeństwa. W tym roku LangSmith i Langfuse stworzyły własne bramy, a Palo Alto Networks kupiło jedną, jednak w wielu stosach technologicznych ścieżka obsługi żądań nadal prowadzi przez LiteLLM.