Rachunek 4x wyższy niż zakładałeś: kiedy bezpośrednie SDK przestaje wystarczać w agentach AI

Przyszedł mail od AWS o 6 rano. Rachunek za OpenAI API — czterokrotnie wyższy niż miesiąc wcześniej. Agent działał, nikt nie zgłaszał błędów, ale coś gdzieś poszło nie tak z cachowaniem i każde powtórzone zapytanie szło do modelu od nowa. To był moment, w którym zaczęliśmy poważnie rozmawiać o LLM gateway.

Rachunek przyszedł 4x wyższy niż zakładałeś — i to był dopiero pierwszy problem

Budując agenta na bezpośrednim SDK, masz złudzenie kontroli. Wywołujesz openai.chat.completions.create(), dostajesz odpowiedź, wszystko działa. Problem pojawia się w produkcji, kiedy skala rośnie, a z nią — nieoczekiwane koszty i zależności, których wcześniej nie widziałeś.

Trzy momenty, w których bezpośrednie SDK przestaje wystarczać

Pierwszy: rachunek przychodzi 4x wyższy niż prognoza. Nie dlatego, że źle szacowałeś — dlatego, że nie miałeś żadnego mechanizmu, który zatrzymałby identyczne zapytania przed ponownym trafieniem do modelu [1].

Drugi: chcesz zamienić model. Może GPT-4 Turbo okazał się za drogi na proste klasyfikacje, a GPT-4.1-mini robi to samo za ułamek ceny. Przy bezpośrednim SDK taka zamiana to przepisanie połowy kodu — inne formaty odpowiedzi, inne parametry, inne obsługi błędów [1].

Trzeci: musisz rozliczyć, który zespół ile wydał. W firmie z kilkoma projektami korzystającymi z tego samego klucza API nie masz żadnej granularności. Jeden klucz, jeden rachunek, zero wglądu — co jest realnym problemem operacyjnym przy skalowaniu agentów w środowiskach korporacyjnych [3].

Outage u dostawcy o 2 w nocy: co się dzieje z Twoim agentem?

OpenAI miało w 2024 roku kilka incydentów z dostępnością. Jeśli Twój agent opiera się wyłącznie na jednym dostawcy i nie ma żadnego fallbacku, outage = przestój. Przy bezpośrednim SDK nie masz automatycznego przełączenia — musisz to obsłużyć ręcznie albo czekać, aż dostawca wróci do życia [1].

Tydzień przestoju w projekcie produkcyjnym to nie abstrakcja. To opóźnione procesy, niezadowoleni klienci i rozmowa z zarządem, której wolałbyś uniknąć.

Czym właściwie jest LLM gateway i dlaczego brzmi nudniej niż jest

Gateway to proxy. Stoi między Twoim kodem a dostawcami modeli — OpenAI, Anthropic, Google — i wystawia jeden endpoint. Twoja aplikacja nie wie, czy odpowiedź przyszła z GPT-4.1-mini czy z Claude 3 Haiku. Wie tylko, że przyszła [1].

Proxy między Twoim kodem a OpenAI/Anthropic/Google — jeden endpoint, wiele modeli

Zamiast utrzymywać osobne integracje z każdym dostawcą, masz jedną warstwę, która tłumaczy, routuje i zarządza. Zmiana modelu nie wymaga przepisania kodu aplikacji — zmienia się konfiguracja gatewaya.

Cztery funkcje, które zmieniają rachunek: fallback, cache, routing, per-team keys

Fallback — jeśli OpenAI zwróci błąd lub przekroczy limit, gateway automatycznie kieruje zapytanie do Anthropic albo innego skonfigurowanego dostawcy. Bez interwencji człowieka, bez przestoju [1].

Cache — identyczne zapytania nie trafiają do modelu ponownie. Odpowiedź jest serwowana z pamięci podręcznej. Koszt: zero opłat za powtórzone zapytania. Przy agentach, które wielokrotnie zadają te same pytania systemowe lub przetwarzają podobne dane wejściowe, oszczędności są natychmiastowe [1].

Routing — możesz kierować różne typy zadań do różnych modeli. Proste klasyfikacje idą do tańszego modelu, złożone analizy do droższego. Decyzja podejmowana jest na poziomie konfiguracji, nie kodu.

Per-team keys — każdy zespół lub projekt dostaje własny klucz z własnym limitem i własnym logiem wydatków. To wymóg, który pojawia się praktycznie w każdym wdrożeniu enterprise, gdy liczba projektów przekracza kilka [3].

Eksplozja modeli w 2024 sprawiła, że decyzja o gatewaycie stała się pilna

W marcu 2024 Anthropic wypuścił Claude 3. Kilka tygodni później Google ogłosił Gemini 1.5 Flash. LLaMA 3 od Meta dała firmom opcję lokalnego hostingu bez opłat za tokeny. Każdy z tych modeli jest tańszy lub szybszy w innym typie zadania.

GPT-4 Turbo vs GPT-4.1-mini: różnica kosztów rzędu 3-5x przy podobnej jakości na prostych taskach

Różnica w cenie między modelami tej samej rodziny wynosi 3–5x przy zadaniach, które nie wymagają pełnych możliwości dużego modelu [1]. Klasyfikacja intencji użytkownika, ekstrakcja danych ze strukturyzowanego tekstu, proste podsumowania — to wszystko zadania, gdzie mniejszy model radzi sobie porównywalnie, a kosztuje wielokrotnie mniej.

Przy agencie obsługującym kilkaset tysięcy zapytań miesięcznie ta różnica przekłada się na konkretne kwoty w PLN. Jeśli płacisz za GPT-4 Turbo to, co mógłbyś płacić za GPT-4.1-mini, przepłacasz — i to systematycznie.

Kiedy mieszanie modeli per-task zaczyna się opłacać finansowo

Mieszanie modeli ma sens, gdy możesz wyraźnie podzielić zadania agenta na "proste" i "złożone". Jeśli 70% zapytań to klasyfikacje i ekstrakcje, a 30% to generowanie złożonych odpowiedzi — routing tych 70% do tańszego modelu zmienia strukturę kosztów całego projektu. Bez gatewaya to przepisanie kodu. Z gatewayem to zmiana konfiguracji.

Mapa decyzji: budować własny routing, użyć open-source gatewaya czy kupić SaaS?

Nie ma jednej odpowiedzi. Jest kilka kryteriów, które pomagają podjąć decyzję bez żałowania jej po trzech miesiącach.

Własny proxy: kiedy ma sens i jaki jest rzeczywisty koszt utrzymania

Własny proxy ma sens, gdy masz specyficzne wymagania bezpieczeństwa — np. dane osobowe nie mogą opuszczać infrastruktury firmy, co w kontekście polskich firm podlegających RODO jest realnym ograniczeniem. Albo gdy Twoje wymagania routingowe są na tyle niestandardowe, że żadne gotowe rozwiązanie ich nie obsługuje.

Rzeczywisty koszt to nie tylko czas napisania proxy. To utrzymanie, aktualizacje przy zmianach API dostawców, obsługa nowych modeli, monitoring. Przy małym zespole to łatwo 3–5 godzin tygodniowo, które mogłyby pójść na budowanie produktu.

LiteLLM, Portkey, OpenRouter — co każde z nich robi inaczej

LiteLLM to open-source proxy z szerokim wsparciem dostawców. Możesz hostować go samodzielnie, co rozwiązuje problem danych wrażliwych. Konfiguracja jest prosta, społeczność aktywna. Działa dobrze jako warstwa routingu i fallbacku [1].

Portkey stawia mocniej na observability — logi, trace'y, analitykę kosztów per-projekt. Jeśli potrzebujesz wglądu w to, co robi agent w produkcji, to jest jego mocna strona [2].

OpenRouter to bardziej marketplace niż gateway — agreguje dostęp do dziesiątek modeli przez jeden endpoint. Przydatny, gdy chcesz szybko przetestować różne modele bez zakładania kont u każdego dostawcy osobno.

Czerwone flagi: kiedy gateway staje się kolejnym single point of failure

Gateway rozwiązuje problem zależności od jednego dostawcy modeli. Ale jeśli sam gateway padnie — masz ten sam problem, tylko na innej warstwie. To nie jest argument przeciwko gatewayowi, ale argument za tym, żeby traktować go jak krytyczną infrastrukturę: monitoring, alerty, plan B.

Pułapki, które znajdziesz dopiero po wdrożeniu

Latency overhead: ile milisekund kosztuje dodatkowa warstwa?

Dodatkowa warstwa sieciowa to dodatkowe milisekundy. W naszym teście z LiteLLM hostowanym w tej samej chmurze co aplikacja overhead wynosił poniżej 20 ms — akceptowalny dla większości zastosowań. Przy self-hosted w innym regionie lub przy SaaS gateway z odległą infrastrukturą może być inaczej. Zmierz to przed wdrożeniem produkcyjnym, nie po.

Vendor lock-in zamieniony miejscami — teraz zależysz od gatewaya

To jest realne ograniczenie, o którym mało kto mówi wprost. Zamiast zależności od OpenAI, budujesz zależność od LiteLLM albo Portkey. Jeśli projekt open-source zostanie porzucony albo SaaS zmieni cennik, masz problem podobny do tego, od którego uciekałeś. Wybierając gateway, sprawdź historię projektu, aktywność społeczności i — przy SaaS — warunki eksportu danych.

Observability: logi, trace'y i alerty, które musisz skonfigurować od razu

Praktyczne wdrożenia produkcyjne pokazują jedno: observability musi być od pierwszego dnia, nie "jak będzie czas" [2]. Gateway bez skonfigurowanych logów i alertów to czarna skrzynka. Gdy coś pójdzie nie tak — a pójdzie — będziesz debugował w ciemno. Minimum to: log każdego zapytania z modelem, dostawcą, latency i kosztem; alert przy przekroczeniu budżetu; alert przy wzroście błędów powyżej progu.

Werdykt po 8 miesiącach: co byśmy zrobili inaczej od pierwszego dnia

Wdrożylibyśmy gateway od razu. Nie po pierwszym wysokim rachunku, nie po pierwszym outage'u — od pierwszego dnia projektu produkcyjnego [1].

Minimalna konfiguracja gatewaya, którą warto mieć od razu przy starcie projektu

Nie potrzebujesz od razu pełnego routingu per-task i zaawansowanej analityki. Potrzebujesz trzech rzeczy: fallback na co najmniej dwóch dostawców, cache dla powtarzalnych zapytań i per-projekt klucze z logowaniem kosztów. To konfiguracja na kilka godzin z LiteLLM, która eliminuje trzy główne źródła bólu opisane na początku.

Jeden konkretny next step: jak przetestować fallback w 30 minut

Zainstaluj LiteLLM lokalnie (pip install litellm[proxy]), skonfiguruj dwa modele w pliku YAML — np. GPT-4.1-mini jako primary i Claude Haiku jako fallback — i wywołaj endpoint z błędnym kluczem dla primary. Jeśli odpowiedź przyszła z fallbacku, mechanizm działa. Cały test zajmuje mniej niż 30 minut i daje Ci pewność, że wiesz, co się stanie o 2 w nocy, gdy primary padnie.

Werdykt: gateway to nie fanaberia dla dużych projektów. To infrastruktura, którą warto mieć od pierwszego dnia w każdym projekcie, który trafi do produkcji. Koszt wdrożenia to kilka godzin. Koszt braku wdrożenia — jak pokazuje rachunek z początku tego tekstu — bywa czterokrotnie wyższy niż zakładałeś.

Źródła

[1] Field notes from 8 months of building agents: the gateway question (and what we actually picked) — https://www.reddit.com/r/LangChain/comments/1sxxs7x/field_notes_from_8_months_of_building_agents_the/

[2] Field notes on conversational AI — Perspective AI Blog — https://getperspective.ai/blog

[3] How are you guys using AI agents? — r/workday — https://www.reddit.com/r/workday/comments/1sp6kxy/how_are_you_guys_using_ai_agents/