Architektura systemów z OpenAI i Anthropic: dlaczego gigantyczne rachunki za LLM to błąd projektowy i jak zmniejszyć je o 70 procent

Wdrażanie zaawansowanych modeli od OpenAI czy Anthropic w środowiskach produkcyjnych często kończy się drastycznym wzrostem kosztów, których nie da się rozwiązać drobną korektą promptów. Prawdziwym winowajcą jest entropia operacyjna oraz bezrefleksyjne przesyłanie gigantycznych kontekstów przez niekontrolowane pętle agentów. Przejście na architekturę typu router-first pozwala zredukować wydatki na API nawet o 70 procent, przekształcając nieprzewidywalne systemy w stabilne i ekonomicznie uzasadnione aplikacje biznesowe.

Ukryte koszty i pojęcie entropii operacyjnej

Tradycyjne podejście do optymalizacji kosztów chmurowych zawodzi w zderzeniu z systemami opartymi o modele językowe, gdzie głównym obciążeniem finansowym nie jest cena pojedynczego tokenu, lecz entropia operacyjna. Niezbędny czas pracy inżynierów poświęcony na debugowanie niedeterministycznych zachowań modeli oraz obsługa kaskadowych błędów w wieloetapowych łańcuchach drastycznie podnoszą całkowity koszt posiadania systemu.

W rzeczywistości produkcyjnej całkowity koszt posiadania (TCO) to nie tylko opłaty za tokeny, ale przede wszystkim nakłady inżynieryjne i operacyjne. Połączenie z API o wartości 0,01 USD, które wywołuje dwugodzinne debugowanie przez starszego programistę w celu naprawy błędu, generuje faktyczny koszt rzędu 300 USD. Zjawisko to określa się jako podatek od zawodności (Unreliability Tax): wraz ze wzrostem liczby kroków wnioskowania w pętli agenta, niezawodność systemu spada multiplikatywnie. Jeśli każdy krok ma 97% skuteczności, to 10-stopniowy łańcuch osiąga całkowitą skuteczność na poziomie zaledwie ~74%.

Przypadek firmy Klarna ilustruje te zależności. Jej asystent obsługi klienta przejął dwie trzecie czatów (około 2,3 miliona konwersacji w pierwszej fazie), skracając czas rozpatrywania zgłoszeń z ~11 minut do poniżej 2 minut, co odpowiadało pracy ~700 pełnoetatowych konsultantów. Jednak dyrektor generalny firmy przyznał później, że organizacja mogła zbyt mocno zorientować się na redukcję kosztów kosztem jakości obsługi. W efekcie Klarna musiała zmodyfikować strategię i przebudować swój stos technologiczny w kierunku bardziej kontrolowanej architektury, wykorzystującej jawne routowanie i zaawansowaną obserwowalność. Miesięczny rachunek zależy od liczby żądań, średniej liczby tokenów oraz ceny za token. Zamiast analizować fakturę globalnie, poważne zespoły monitorują koszty w rozbiciu na pojedyncze funkcje (Cost per Feature), co pozwala na realną ocenę, czy wartość biznesowa pokrywa wydatki.

Architektura router-first i specjalizacja modeli

Kierowanie każdego zapytania użytkownika bezpośrednio do najdroższego modelu klasy frontier to marnotrawstwo wynikające z braku analizy złożoności zadań. Wdrożenie wzorca router-first pozwala na automatyczne klasyfikowanie zapytań i delegowanie 80% powtarzalnego ruchu do mniejszych, wyspecjalizowanych modeli lokalnych, drastycznie obniżając rachunki przy zachowaniu pełnej kontroli jakości.

Większość zapytań produkcyjnych to rutynowe zadania, takie jak klasyfikacja, ekstrakcja danych, formatowanie czy synteza prostych informacji z bazy RAG. Tylko nieliczne wymagają głębokiego wnioskowania, obsługi niejednoznaczności czy wysokiej odpowiedzialności. Zamiast traktować model klasy frontier jako domyślny punkt wejścia, należy zastosować podejście, w którym model ten jest wyłącznie ścieżką eskalacji (escalation path). Lekki komponent klasyfikujący (oparty o proste reguły lub mały model SLM) analizuje zapytanie na wejściu:

1. Zapytania proste/znane: trafiają do wyspecjalizowanych, szybkich modeli lokalnych (SLM).
2. Zapytania złożone/niejednoznaczne: są eskalowane do dużego modelu wnioskowania (Reasoning Model).

Dzięki temu 80% ruchu obsługiwane jest ułamkiem dotychczasowych kosztów, eliminując dryf kreatywny modelu. System staje się odporny na awarie poprzez mechanizm bezpiecznej eskalacji. Jeśli tani model SLM nie przejdzie walidacji schematu JSON lub wykaże niski poziom pewności, żądanie jest natychmiast przekierowywane wyżej – do modelu standardowego lub klasy frontier. Kosztem tego rozwiązania jest nieznaczne opóźnienie w przypadku eskalacji, co zapobiega jednak pokazaniu błędu użytkownikowi.

Odchudzanie kontekstu i budżetowanie zapytań

Niekontrolowane puchnięcie okna kontekstowego poprzez bezrefleksyjne dołączanie pełnej historii czatów, nadmiarowych dokumentów RAG oraz schematów wszystkich dostępnych narzędzi generuje ukryte koszty przy każdym zapytaniu. Systemy produkcyjne wymagają rygorystycznej polityki zarządzania kontekstem, aby ograniczyć przesyłanie niepotrzebnych tokenów, które bezpośrednio przekładają się na gigantyczne faktury.

Gdy użytkownik zadaje proste pytanie (np. „co zmieniło się w tym projekcie umowy?”), systemy bez kontroli kontekstu wysyłają do API gigantyczny ładunek składający się z instrukcji systemowych, reguł nadzoru, historii czatu, całych dokumentów z bazy wiedzy oraz definicji wszystkich narzędzi. Każde kolejne zapytanie w tej samej sesji zmusza do ponownego opłacania całej tej bazy danych. Rozwiązaniem tego problemu jest ścisłe budżetowanie kontekstu:

• Zarządzanie historią konwersacji: Zamiast przesyłania pełnej historii, należy stosować ustrukturyzowany stan konwersacji połączony z semantyczną kompresją starszych wątków i zachowaniem verbatim jedynie kilku ostatnich wypowiedzi. Należy pamiętać, że podsumowanie wiąże się z ryzykiem utraty szczegółów.
• Selektywne dołączanie narzędzi (Tools): Agenci nie mogą otrzymywać schematów wszystkich funkcji systemu. Na podstawie intencji zapytania należy udostępniać wyłącznie minimalny, niezbędny zestaw narzędzi (np. zapytania o rozliczenia nie potrzebują schematu bazy danych administratora).
• Rygorystyczny budżet RAG: Stałe przesyłanie np. dziesięciu dużych fragmentów tekstu (`topK = 10`) niepotrzebnie obciąża budżet. Właściwa architektura RAG powinna wykorzystywać szersze pobieranie kandydatów, deduplikację, ponowne ocenianie (reranking) oraz progi istotności w celu zminimalizowania liczby przesyłanych tokenów bez utraty jakości odpowiedzi.

Dodatkowo krytyczna jest kontrola generowanych tokenów wyjściowych, które są znacznie droższe od wejściowych. Na przykład cennik modelu GPT-5.6 Sol zakłada 5 USD za milion tokenów wejściowych i aż 30 USD za milion tokenów wyjściowych (dla Opus 4.8 jest to odpowiednio 5 USD i 25 USD). Jeśli aplikacja potrzebuje tylko krótkiego oznaczenia kategorii (np. JSON z jedną etykietą), model nie może generować wieloakapitowych uzasadnień. Wymuszanie ustrukturyzowanych formatów wyjściowych (Structured Outputs) oraz stosowanie twardych limitów długości generowania zapobiega zbędnemu marnowaniu budżetu.

Caching, batching i optymalizacja ekonomiczna dostawców

Wykorzystanie mechanizmów pamięci podręcznej oraz przetwarzania wsadowego to podstawowe narzędzia optymalizacji kosztów na poziomie interakcji z dostawcami API. Zrozumienie różnic w raportowaniu i cennikach tokenów u gigantów takich jak OpenAI, Anthropic czy Google jest niezbędne do poprawnego wdrożenia prompt i semantic cachingu.

Koncepcja Prompt Caching polega na tym, że powtarzalne, statyczne elementy zapytania (stałe instrukcje systemowe, definicje narzędzi czy konteksty referencyjne) nie powinny być wyceniane tak samo jak unikalne dane wejściowe. Należy jednak pamiętać, że zapisanie kontekstu w pamięci podręcznej (cache write) niesie ze sobą koszt początkowy, który musi zostać zamortyzowany przez odpowiednią liczbę kolejnych odczytów (cache reads). Modele od Anthropic oraz OpenAI realizują i raportują te operacje w odmienny sposób:

• Anthropic Claude: Zwraca szczegółowe pola takie jak `input_tokens`, `output_tokens`, `cache_creation_input_tokens` (zapis) oraz `cache_read_input_tokens` (odczyt). Koszt zapisu do cache to zazwyczaj 1,25x stawki bazowej, natomiast odczyt to zaledwie 0,1x ceny bazowej. Co istotne, pole `input_tokens` u tego dostawcy pomija już tokeny obsłużone przez pamięć podręczną.
• OpenAI (ChatGPT): Raportuje całkowitą liczbę `prompt_tokens` (zawierającą już tokeny z cache) oraz oddzielną wartość `cached_tokens`. Aby precyzyjnie wyliczyć rzeczywisty koszt, należy odjąć tokeny skeszowane od sumy: `uncached_input = prompt_tokens – cached_tokens`.
• Google Gemini: W nowym pakiecie SDK `google-genai` wartość `cached_content_token_count` również stanowi podzbiór całkowitego parametru `prompt_token_count`. Dodatkowo tokeny wygenerowane w pętli myślenia (thoughts_token_count) są taryfikowane według droższej stawki wyjściowej. Dla modelu Gemini 3.1 Pro obowiązują stawki stopniowane po przekroczeniu progu 200 tysięcy tokenów wejściowych.

Kolejnym narzędziem jest Semantic Caching, które pozwala na całkowite pominięcie wysyłania zapytania do modelu, jeśli system wykryje semantycznie tożsame pytanie zadane wcześniej. Wdrożenie pamięci Redis z czasem życia (TTL) na poziomie 24 godzin w jednym z systemów fintechowych pozwoliło zredukować liczbę zapytań do LLM o 60% w pierwszym tygodniu. Kluczowym ryzykiem jest tu bezpieczeństwo danych – klucz pamięci podręcznej nie może opierać się wyłącznie na podobieństwie tekstu. Musi uwzględniać tożsamość użytkownika, uprawnienia, wersję modelu, wersję promptu oraz wymagania dotyczące świeżości danych, by uniknąć wycieku informacji między użytkownikami.

W przypadku zadań, które nie wymagają natychmiastowej reakcji w czasie rzeczywistym (np. analizy dokumentów, nocne raporty, audyty jakości), należy bezwzględnie wdrożyć kolejkowanie asynchroniczne i Batch API. Liderzy rynku (OpenAI, Anthropic, Google) oferują stałą 50% zniżkę na przetwarzanie wsadowe z gwarancją realizacji w określonym oknie czasowym.

Wnioski praktyczne i rekomendacje

• Wdróż aplikacyjny standard rejestrowania zdarzeń `LLMUsageEvent`, zbierając metryki takie jak identyfikator funkcji, wersja promptu, model, realna liczba tokenów wejściowych i wyjściowych (z rozbiciem na cache) oraz opóźnienie, aby precyzyjnie przypisać koszty do konkretnych funkcjonalności.
• Skonfiguruj deterministyczne reguły routingu (Router-First). Zaimplementuj wstępną walidację zapytań za pomocą tradycyjnego kodu, a rutynowe operacje, takie jak klasyfikacja czy proste wyciąganie cech, skieruj do mniejszych modeli SLM.
• Zmierz wskaźnik eskalacji (Escalation Rate), dążąc do utrzymania go poniżej docelowego poziomu 20%. W przypadku gdy wskaźnik ten trwale przekracza 30%, zoptymalizuj politykę klasyfikacji zapytań zamiast decydować o migracji całego potoku do droższych modeli.
• Zweryfikuj strukturę przesyłanych promptów pod kątem Prompt Caching. Uporządkuj szablony tak, aby najbardziej zmienne dane znajdowały się na samym dole, a stałe (instrukcje systemowe i definicje narzędzi) na samej górze zapytania.
• Wdróż twarde budżety i wyłączniki awaryjne (circuit breakers) dla pętli agentowych oraz procedur powtórzeń. Narzuć sztywne limity na maksymalną liczbę kroków, wywołań modeli oraz szacowany koszt pojedynczego zadania agenta.
• Zweryfikuj zadania przetwarzane w tle i przenieś procesy nieinteraktywne na ścieżkę Batch API, co pozwoli na natychmiastową oszczędność rzędu 50% opłat za tokeny.
• Zmierz koszt przypadający na pożyteczny wynik (Cost per Outcome), na przykład koszt na pomyślnie rozwiązane zgłoszenie, zamiast optymalizować jedynie cenę za milion tokenów.

Źródła

• 8 LLM Cost Optimization Techniques That Can Reduce AI Costs by 70% – YouTube
• Agent harness – Wikipedia
• LLM costs aren’t a pricing problem: it’s architecture | stAI tuned
• Machine Learning Tech Brief By HackerNoon – ポッドキャスト – Apple Podcasts
• Your LLM Bill Is Too High. Here’s How to Fix It (Part 1) – My Framer Site
• Your LLM Bill Is Your Own Fault – Law Zava
• Your LLM Has a Spending Problem – How Prompts, Context Windows, and Agent Loops Quietly Torch Your Budget – Cloudy Musings
• https://blog.devgenius.io/the-hidden-math-how-your-prompt-design-silently-6xs-your-llm-bill-f72a40702f6c