LangSmith czy Arize Phoenix? Darmowy self-hosting ma własny koszt

W projekcie opartym na LangGraph naturalnym wyborem jest LangSmith, którego natywne śledzenie agentów współpracuje z ekosystemem LangChain. Gdy aplikacja łączy różne biblioteki lub własny kod, Arize Phoenix daje większą swobodę instrumentacji: przyjmuje ślady przez OpenTelemetry (OTLP). LangSmith także obsługuje OpenTelemetry, więc sam protokół nie przesądza o wyborze; znaczenie ma sposób pracy zespołu ze śladami i ocenami.

Przy wymogu lokalnego przechowywania danych rachunek wygląda inaczej. Phoenix można uruchomić u siebie bez opłaty licencyjnej, lecz zespół utrzymuje wtedy usługę i jej dane. Cennik LangSmith przypisuje pełny self-hosting do planu Enterprise z indywidualną wyceną; chmurowy plan Developer obejmuje jedno bezpłatne miejsce i do 5 tys. podstawowych śladów miesięcznie, po czym naliczane jest dalsze użycie. Darmowa licencja Phoenix i bezpłatny plan LangSmith dotyczą zatem różnych modeli hostingu.

Integracja z LangGraph a przenośność śladów

LangSmith ma przewagę organizacyjną tam, gdzie przebieg aplikacji jest już opisany przez komponenty LangChain i graf agenta. Zespół może analizować kolejne kroki wykonania w narzędziu powiązanym z tym środowiskiem, bez projektowania całej warstwy obserwowalności od początku. To argument za wygodą, a nie dowód, że LangSmith będzie tańszy przy każdym wolumenie ruchu.

W aplikacji niezależnej od frameworka większą wartość może mieć wspólny format telemetrii. Phoenix odbiera ślady OTLP z różnych instrumentowanych usług, dzięki czemu miejsce ich wysyłania nie musi być zapisane w logice jednego frameworka. Zespół nadal musi jednak uzgodnić nazwy operacji, atrybuty oraz sposób łączenia kroków jednego żądania. Przeniesienie samych śladów do innego odbiornika nie przeniesie automatycznie zbiorów testowych, ocen ani filtrów używanych podczas analizy.

Oba produkty służą także do ewaluacji, ale potrzeba porównania dotyczy konkretnego sposobu jej wykonywania. Ocena wersji aplikacji na zapisanym zbiorze przykładów obciąża system inaczej niż ocenianie odpowiedzi z bieżącego ruchu. Jeśli oceniający używa płatnego modelu, jego wywołania trzeba uwzględnić niezależnie od kosztu platformy obserwacyjnej. Wybór narzędzia powinien więc obejmować zarówno ślady, jak i to, kto uruchamia oceny oraz gdzie trafiają ich wyniki.

Co składa się na koszt lokalnego Phoenix

Własne wdrożenie wymaga miejsca na aplikację i trwałe dane. Architektura Phoenix obejmuje kolektor śladów, interfejs i bazę SQL; domyślne SQLite jest przeznaczone do prostych wdrożeń lokalnych, a PostgreSQL jest zalecany do pracy produkcyjnej z wieloma użytkownikami. W drugim wariancie dochodzą utrzymanie bazy, kopie zapasowe i możliwość odtworzenia danych po awarii.

Miesięczny rachunek można zapisać jako sumę kosztu instancji aplikacji, bazy i przestrzeni, kopii zapasowych, czasu administratora oraz rozłożonego w czasie kosztu wdrożenia. Retencja wpływa na ilość przechowywanych danych, ale liczba śladów sama w sobie nie wystarcza do oszacowania pojemności. Jeden ślad może zawierać wiele kroków, a zapisywanie pełnych wejść i odpowiedzi zwiększa jego rozmiar. Polityka usuwania danych i zakres kopii powinny być częścią tego samego budżetu.

Poniższe kalkulacje są przykładami opartymi na jawnych założeniach, a nie ofertami dostawców. Przyjmują wewnętrzny koszt pracy administratora w wysokości 150 zł za godzinę. Nie obejmują wywołań modeli używanych do ocen ani pracy nad instrumentacją samej aplikacji, chyba że wskazano ją osobno. Dzięki temu widać, które składniki zmieniają wynik między trzema sytuacjami, bez przypisywania umownych kwot producentom.

Mały projekt LangGraph bez wymogu lokalnych danych

Załóżmy jednego użytkownika narzędzia i 3 tys. podstawowych śladów miesięcznie. Taki profil mieści się w opisanym wcześniej limicie planu Developer LangSmith, o ile zespołowi wystarcza chmurowy hosting i podstawowa retencja. Przy tym założeniu opłata za miejsce użytkownika wynosi zero. Potrzeba dłuższego przechowywania wybranych śladów lub dodatkowego płatnego użycia może zmienić rachunek, dlatego zerowy koszt miejsca nie jest obietnicą zerowego rachunku za wszystkie funkcje.

Dla porównania przyjmijmy hipotetyczne lokalne wdrożenie Phoenix: 160 zł miesięcznie za instancję, 40 zł za przestrzeń i kopie oraz 2 godziny obsługi po 150 zł. Suma wynosi 500 zł miesięcznie. W tak małym projekcie oszczędność czasu dzięki integracji LangSmith może być ważniejsza od możliwości samodzielnego hostingu. Kwota Phoenix pokazuje koszt utrzymania przy tych założeniach, a nie próg opłacalności obowiązujący inne zespoły.

Aplikacja korzystająca z różnych frameworków

Załóżmy kilka usług wysyłających ślady przez OpenTelemetry i zespół, który chce móc zmienić ich odbiornik. Phoenix pasuje do tej architektury, lecz wspólny protokół nie zwalnia z pracy nad spójnym opisem operacji. Jeżeli jedna usługa zapisuje wywołanie modelu jako osobny krok, a druga pomija tę informację, porównywanie przebiegów pozostanie trudne niezależnie od wybranego interfejsu.

Przykładowy miesięczny budżet Phoenix to 250 zł za instancję, 120 zł za bazę i kopie oraz 3 godziny obsługi, czyli 450 zł. Załóżmy dodatkowo 8 godzin jednorazowego przygotowania instrumentacji: przy przyjętej stawce daje to 1200 zł. Rozłożenie tej pracy na sześć miesięcy dodaje 200 zł miesięcznie, więc suma w tym okresie wynosi 1020 zł miesięcznie. Oferta LangSmith wymagałaby porównania przy tej samej liczbie użytkowników, wielkości ruchu, retencji i zakresie ocen; samo zestawienie kosztu licencji z kosztem serwera zaniżyłoby jedną stronę rachunku.

Gdy ślady muszą pozostać we własnym środowisku

Wymóg lokalnego przechowywania zawęża wybór modeli hostingu. Phoenix pozwala uniknąć opłaty licencyjnej za własne wdrożenie, ale odpowiedzialność za aktualizacje, dostępność i odtworzenie bazy pozostaje po stronie zespołu. Pełny LangSmith self-hosted wymaga oferty Enterprise; również w tym wariancie trzeba ustalić koszty infrastruktury i zakres prac operacyjnych. Indywidualna cena LangSmith nie pozwala rzetelnie wpisać jednej kwoty do porównania bez oferty dla tego samego obciążenia.

Przyjmijmy warunkowo 100 tys. śladów miesięcznie, po 5 fragmentów i 2 KB danych na fragment. To około 1 GB surowych danych na miesiąc, a przy retencji 90 dni około 3 GB. Jeśli na indeksy, narzut bazy i kopie zarezerwujemy trzykrotność tej przestrzeni, planowana pojemność wyniesie około 9 GB. To wyłącznie model pojemnościowy: ślady zawierające obszerne prompty lub odpowiedzi mogą zajmować znacznie więcej miejsca, a wymagania dotyczące kopii mogą wymagać osobnego zasobu.

W tym samym umownym scenariuszu 300 zł za instancję, 250 zł za bazę i przestrzeń, 100 zł za kopie oraz łącznie 6 godzin administracji i rezerwy na incydenty po 150 zł daje 1550 zł miesięcznie. Rezerwa czasu nie gwarantuje określonej dostępności ani czasu odtworzenia: takie wymagania mogą oznaczać dodatkowe instancje, monitoring i dyżury. Przy wysokiej dostępności także wybór sposobu wdrożenia staje się częścią kosztu. W tym przypadku o decyzji między Phoenix a LangSmith rozstrzyga pełna oferta dla lokalnego hostingu zestawiona z realnym obciążeniem zespołu utrzymującego Phoenix.

Przeczytaj także:

• Docker Compose czy Kubernetes? Wysoka dostępność ma koszt operacyjny
• Lokalny model czy API? Oszczędność znika przy złym wykorzystaniu
• Google Drive czy OneDrive? Darmowe 15 GB nie rozstrzyga wyboru