Kiedy jeden provider LLM zaczyna kosztować więcej niż cały zespół

Agent przestaje odpowiadać o 3 w nocy. Rachunek za tokeny jest cztery razy wyższy niż zakładałeś. Zamiana modelu wymaga przepisania połowy kodu. Każdy z tych trzech scenariuszy to osobny problem — ale wszystkie mają jedno źródło: brak warstwy między twoją aplikacją a providerem.

Trzy momenty, w których jeden provider przestaje wystarczać

Awaria o 3 w nocy i agent, który po prostu przestał działać

Wyobraź sobie agenta HR wdrożonego w firmie produkcyjnej. Pracownicy nocnej zmiany pytają o saldo urlopu, harmonogram, dane payrollowe. Agent działa — dopóki nie przestaje, bo provider ma outage. Nie ma fallbacku, nie ma alertu, jest tylko cisza i błąd 503. [2]

To nie jest scenariusz hipotetyczny. W środowiskach enterprise, gdzie agenci AI zastępują dawne systemy samoobsługi, każda minuta niedostępności ma wymierny koszt operacyjny. Jeśli twój agent obsługuje procesy krytyczne i jest podpięty bezpośrednio pod jeden endpoint, jesteś tak samo dostępny jak ten endpoint — ani o sekundę lepiej.

Rachunek 4x wyższy niż prognoza — skąd się bierze ta różnica

Budujesz agenta, testujesz na małym ruchu, szacujesz koszt. Potem wchodzisz w produkcję i na koniec miesiąca rachunek jest cztery razy wyższy niż prognoza. [1]

Skąd ta różnica? Najczęściej z trzech miejsc: dłuższe konteksty niż w testach, brak cachowania powtarzalnych zapytań i brak widoczności per-team — nie wiesz, który projekt generuje koszty. Bez warstwy pośredniej nie masz narzędzi, żeby to zobaczyć zanim będzie za późno.

Zamiana modelu jako projekt na tydzień

Trzeci scenariusz jest mniej dramatyczny, ale równie kosztowny. Chcesz podmienić model — powiedzmy, przejść z droższego wariantu na tańszy, bo zadanie nie wymaga pełnej mocy. Okazuje się, że każdy provider ma inny format API, inne nazewnictwo parametrów, inne zachowanie przy błędach. Zamiana modelu wymaga przepisania połowy kodu. [1]

To jest moment, w którym architektura zaczyna hamować produkt.

Czym właściwie jest LLM gateway i co robi za kulisami

Proxy, router, cache — trzy warstwy w jednym narzędziu

Gateway to proxy między twoją aplikacją a providerami LLM. Zamiast wywoływać bezpośrednio API OpenAI, Anthropica czy Google — wywołujesz jeden endpoint. Gateway tłumaczy żądanie na format właściwy dla wybranego modelu, obsługuje błędy i zwraca odpowiedź w ujednoliconym formacie. [1]

W praktyce gateway robi co najmniej trzy rzeczy:

• Unified API — jeden interfejs niezależnie od providera. Zamiana modelu to zmiana konfiguracji, nie przepisywanie kodu.
• Automatic fallback — jeśli primary provider nie odpowiada, żądanie trafia do kolejnego na liście. Agent działa dalej.
• Semantic caching — identyczne lub podobne zapytania są serwowane z cache'u. Nie płacisz za tokeny, które już raz kupiłeś.

Do tego dochodzą per-team i per-project klucze API z osobnym śledzeniem kosztów oraz centralny cost tracking. [1]

Jak wygląda request flow z gateway'em vs bez niego

Bez gateway'a: aplikacja → API providera. Jeden punkt awarii, brak widoczności, brak fallbacku.

Z gateway'em: aplikacja → gateway → (routing logic) → provider A lub B lub C. Gateway loguje każde żądanie, przypisuje koszt do projektu, wykrywa błąd i automatycznie przełącza na alternatywę. Twoja aplikacja nie wie, że cokolwiek się zmieniło.

To nie jest skomplikowana architektura. To warstwa, która oddziela "co chcę zrobić" od "kto to wykona i za ile".

Krajobraz modeli w 2024–2025: co faktycznie routujesz i po ile

GPT-4o, GPT-4.1-mini, Claude 3 Haiku — kiedy który model do jakiego zadania

Routing ma sens tylko wtedy, gdy modele różnią się ceną lub jakością na konkretnych zadaniach. W 2024–2025 ta różnica jest realna.

GPT-4o sprawdza się przy zadaniach wymagających rozumowania i długiego kontekstu. GPT-4.1-mini to tańsza opcja do klasyfikacji, ekstrakcji danych i zadań, gdzie nie potrzebujesz pełnej mocy. Claude 3 Haiku jest szybki i tani — dobrze sprawdza się przy krótkich, powtarzalnych zapytaniach, gdzie liczy się latencja i koszt per request.

Inteligentny routing oznacza, że proste zadanie trafia do taniego modelu, a złożone — do droższego. Bez gateway'a wszystko trafia do jednego modelu, bo tak jest najprościej zakodować.

Ceny tokenów jako argument architektoniczny: input vs output asymetria

Jeden szczegół, który często umyka przy kalkulacjach: tokeny wyjściowe są droższe niż wejściowe. Jeśli twój agent generuje długie odpowiedzi, koszt rośnie szybciej niż wskazuje prosta arytmetyka z długości promptu.

To ma bezpośrednie przełożenie na routing. Zadania, gdzie output jest krótki (klasyfikacja, ekstrakcja, tak/nie), można spokojnie kierować do najtańszego modelu. Zadania z długim outputem (generowanie treści, analiza dokumentów) wymagają osobnej kalkulacji — tani model z dużym outputem może wyjść drożej niż drogi model z outputem skróconym przez lepsze rozumowanie instrukcji.

Gateway daje ci narzędzie do testowania tych hipotez w produkcji, nie tylko w arkuszu kalkulacyjnym.

Jak wygląda wybór gateway'a w praktyce: kryteria, które mają znaczenie

Open-source vs managed: co tracisz, co zyskujesz

Managed gateway (np. jako SaaS) daje ci szybki start, wsparcie i brak infrastruktury do utrzymania. Płacisz za wygodę — i oddajesz kontrolę nad danymi, które przechodzą przez cudzy serwer. Dla polskich firm działających pod RODO i przetwarzających dane osobowe to nie jest kwestia techniczna, to kwestia prawna.

Open-source gateway (np. LiteLLM, Portkey w trybie self-hosted) daje pełną kontrolę. Płacisz infrastrukturą i czasem inżynierskim. Dla zespołu poniżej 5 osób to może być za dużo — dla większych projektów to często jedyna akceptowalna opcja.

Nie ma tu jednej odpowiedzi. Jest pytanie: kto przetwarza twoje dane i na jakiej podstawie prawnej?

Observability i cost attribution — dlaczego to ważniejsze niż routing

Routing to funkcja, którą doceniasz przy awarii. Observability to funkcja, którą doceniasz codziennie.

Możliwość zobaczenia, który agent, który projekt i który zespół generuje ile kosztów — to jest argument, który przekonuje CFO do dalszego finansowania. Bez cost attribution masz jeden rachunek za tokeny i zero wiedzy, co go generuje. Z attribution możesz optymalizować, negocjować budżety i uzasadniać decyzje architektoniczne liczbami.

Przy wyborze gateway'a sprawdź najpierw dashboardy kosztów, a dopiero potem listę wspieranych providerów.

Kiedy gateway to over-engineering — uczciwy werdykt

Sygnały, że jesteś za wcześnie na tę decyzję

Gateway dodaje warstwę. Warstwa dodaje latencję, złożoność i kolejny punkt awarii do utrzymania. Jeśli twój projekt jest na etapie prototypu, obsługujesz jeden use case i masz jednego providera — gateway to przedwczesna optymalizacja.

Konkretne sygnały, że jeszcze nie potrzebujesz gateway'a:

• Twój agent działa w jednym środowisku, na jednym modelu, bez SLA.
• Nie masz jeszcze produkcyjnego ruchu — testujesz założenia.
• Cały projekt to jedna osoba lub dwuosobowy zespół bez podziału na projekty/klientów.
• Koszt tokenów jest poniżej progu, który wymaga raportowania.

W takim przypadku bezpośrednie API jest właściwą decyzją. Prościej, szybciej, mniej do utrzymania. [3]

Minimalny viable setup dla zespołu poniżej 5 osób

Jeśli jesteś na etapie, gdzie gateway jeszcze nie ma sensu, ale chcesz się zabezpieczyć na przyszłość — jedno działanie ma sens od razu: abstrahuj wywołania LLM za własną funkcją lub klasą w kodzie. Jeden wrapper, który dziś wywołuje OpenAI bezpośrednio, jutro możesz podmienić na gateway bez ruszania reszty aplikacji.

To nie jest architektura gateway'a. To jest higiena kodu, która kosztuje godzinę i oszczędza tydzień przy pierwszej migracji.

Następny krok: jak przeprowadzić własny gateway audit w jeden dzień roboczy

Zanim zmienisz architekturę, odpowiedz na trzy pytania diagnostyczne:

Pierwsze: Ile razy w ostatnich 30 dniach twój agent był niedostępny z powodu problemów po stronie providera? Jeśli zero — outage nie jest twoim aktualnym problemem. Jeśli raz lub więcej — fallback ma konkretną wartość operacyjną.

Drugie: Czy wiesz, który projekt lub funkcja generuje największy koszt tokenów? Jeśli nie — cost attribution jest ważniejsza niż routing.

Trzecie: Ile czasu zajęłoby ci dziś podmienienie modelu na inny provider? Jeśli odpowiedź to "kilka godzin lub więcej" — unified API ma sens.

Jeśli na dwa z trzech pytań odpowiedź wskazuje na realny problem — gateway przestaje być over-engineeringiem, a staje się zaległym długiem technicznym.

Minimalny checklist wdrożeniowy sprowadza się do czterech kroków: wybierz gateway z obsługą twoich providerów, ustaw fallback na co najmniej dwa modele, włącz cost attribution per projekt od pierwszego dnia i zweryfikuj, gdzie fizycznie przetwarzane są dane — szczególnie jeśli działasz jako sp. z o.o. przetwarzająca dane osobowe pod polskim prawem.

Jeden dzień roboczy wystarczy na decyzję. Wdrożenie to osobna rozmowa — ale decyzja nie powinna czekać na kolejny rachunek cztery razy wyższy niż prognoza. [1]

Ź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/1sxxrt1/field_notes_from_8_months_of_building_agents_the/

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

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