Jak zmniejszyć koszt API AI o 60–90%: cache, małe modele, batch, krótsze prompty i routing modeli 

Rachunek za API AI da się obciąć o kilkadziesiąt procent, a w dobrze dobranych przypadkach nawet o 80% - ale nie jednym przełącznikiem. Realne źródła oszczędności są cztery: cache promptów, tańszy model do prostych zadań, tryb wsadowy (batch) do pracy, na którą nikt nie czeka, oraz stabilny prefiks zamiast przepisywanego kontekstu. Poniżej rozkładam to na konkretne kwoty i pokazuję, z jakich cenników pochodzą.

Zacznę od uczciwego zastrzeżenia. Tytuł obiecuje 60-90%, a żadne źródło nie podaje takiego jednego procentu dla „całej optymalizacji”. Procenty u providerów dotyczą pojedynczych mechanizmów: do 90% na cache, 50% na batch, 30-85% na routing, każdy przy innych założeniach. Dlatego niżej liczę to na własnym przykładzie, z jawnymi założeniami.

Z czego w ogóle składa się rachunek za API AI

Zanim zaczniesz cokolwiek zmieniać, warto zobaczyć, co dokładnie płacisz. Każde wywołanie modelu rozlicza się z kilku stron naraz, nie z jednej pozycji „cena za rozmowę”.

Jeśli dopiero zaczynasz liczyć, zajrzyj najpierw do cennika API AI z przeliczeniem na złotówki i do przeglądu kosztów AI w firmie. Tam są stawki i arkusz, tutaj zajmujemy się wyłącznie stroną techniczną: co dokładnie obciąża rachunek.

Licznik usage zwracany przez API pokazuje osobno tokeny wejściowe, tokeny wyjściowe, tokeny zapisane do cache i tokeny odczytane z cache. To cztery różne stawki w jednym zamówieniu. Przy Claude licznik wygląda tak: cache_creation_input_tokens to liczba tokenów zapisanych do pamięci podręcznej, cache_read_input_tokens to liczba tokenów odczytanych z niej, a reszta to zwykłe wejście i wyjście.

Druga część rachunku jest mniej oczywista: liczba wywołań. Agent, który czyta dokument i pisze odpowiedź, potrafi zrobić kilkanaście rund w jednym zadaniu. Każda runda to osobne wejście z całą historią rozmowy. Nie płacisz za jedną czynność, tylko za liczbę kroków, które wybrał model.

Prompt caching: największa pojedyncza dźwignia

Cache działa prosto: jeśli wysyłasz ten sam blok tekstu (instrukcje systemowe, definicje narzędzi, fragment bazy wiedzy) w kolejnych zapytaniach, provider nie liczy go drugi raz w pełnej cenie. Zapisujesz raz, czytasz wielokrotnie.

Ceny różnią się zależnie od wersji modelu. Dla GPT-5.6 i nowszych zapis do cache kosztuje 1,25 raza stawki za zwykłe wejście, a odczyt 0,1 raza tej stawki, czyli 90% rabatu. Dla GPT-6.1 Sol odczyt spada do 0,05 raza, czyli 95% rabatu. U Anthropica proporcje są podobne do ręki: zapis z ważnością 5 minut to 1,25 razy stawki bazowej, z ważnością 1 godzina to 2 razy, a odczyt 0,1 razy.

To zaksięgowane, konkretne liczby, nie obietnice marketingowe. Dokumentacja OpenAI podaje wprost rozliczenie dla dwóch scenariuszy. Przy stawce odczytu 0,1: jeden zapis i jeden pełny odczyt kosztują łącznie 1,35 raza zwykłego wejścia, wobec 2 razy bez cache. Przy dziesięciu zapytaniach: jeden zapis i dziewięć odczytów to 2,15 raza wobec 10 razy bez cache.

Z tego wynika próg, którego dokumentacja nie podaje wprost, a który warto policzyć samemu. Dwa zapytania to jeszcze oszczędność, choć niewielka. Przy dziesięciu oszczędność jest już wyraźna. Jeśli ten sam prefiks leci raz na tydzień, cache dla ciebie nie zadziała - i to nie jest błąd ustawień, tylko rachunek.

Jest jednak warunek, o którym potyka się większość wdrożeń: prompt musi być wystarczająco długi. Minimalna długość cache to 1024 tokeny dla GPT-5.6 i nowszych, a u Anthropica waha się od 512 do 4096 tokenów zależnie od modelu. Poniżej progu zapytanie jest po prostu przetwarzane bez cache i nie dostaniesz żadnego błędu, więc źle skonfigurowany cache wygląda jak działający, tylko nic nie oszczędza.

Co psuje cache najczęściej

Najczęstsza przyczyna braku oszczędności to znacznik czasu w instrukcji systemowej. Jeśli w treści, którą wysyłasz zawsze, jest aktualna data albo identyfikator uruchomienia, prefiks zmienia się przy każdym zapytaniu i nigdy nie trafia w cache. Dokumentacja AWS opisuje to wprost: rachunek rośnie, a licznik tokenów się nie zmienia. Sygnał jest jeden - odczyt z cache równy zero.

Drugi problem to kompresja historii rozmowy. Dokumentacja OpenAI ostrzega wprost: podsumowywanie, kompakcja i obcinanie kontekstu zmieniają prefiks i resetują wykorzystanie cache. Czyli najpopularniejszy trik „mniej kontekstu = taniej” działa przeciwko cache. Oba efekty nie występują jednocześnie.

Warto też wiedzieć, że cache nie pomaga w generowaniu odpowiedzi. Anthropic pisze to jednym zdaniem: prompt caching nie ma wpływu na generowanie tokenów wyjściowych, a odpowiedź jest identyczna jak bez cache. Oszczędzasz na wejściu. Jeśli twój prompt jest krótki, a odpowiedź długa, ten mechanizm da ci niewiele.

Batch API: połowa ceny za robotę, na którą nikt nie czeka

Tryb wsadowy to prosty układ: zamiast wysyłać zapytania jedno po drugim i czekać na każdą odpowiedź, wkładasz je do pliku i oddajesz całą paczkę. Cena spada o połowę, czas rośnie.

50% to nie marketing, tylko wspólna wartość u trzech providerów. OpenAI opisuje to jako 50% zniżki względem API synchronicznego, z osobną pulą limitów i 24-godzinnym terminem realizacji. Azure podaje tez 50% względem globalnej stawki standardowej, AWS mówi o do 50% oszczędności przy obciążeniach niebędących czasu rzeczywistego, a Gemini opisuje to jako „Batch API (50% cost reduction)”.

Jest jeden wyjątek, o którym warto wspomnieć, bo w cennikach bywa pomijany: xAI oferuje zniżkę 20%, nie 50%, i tylko dla czterech wskazanych modeli. Grok 4.6 nie ma zniżki wcale. Jeśli pracujesz na xAI, „batch = połowa ceny” jest błędne.

Po stronie ograniczeń: strumieniowanie jest odrzucane, a wyniki wracają plikiem, nie pojedynczymi odpowiedziami. Plik wejściowy ma limit 200 MB. W OpenAI zadanie, które nie zdąży w 24 godziny, dostaje status expired i płacisz tylko za to, co zdążyło się wykonać. Azure zachowuje się inaczej: zadania, które trwają dłużej, nie wygasają, a przy anulowaniu płacisz za każdą ukończoną pracę.

Ta różnica ma praktyczne znaczenie przy projektowaniu. Jeśli planujesz rozliczenia i potrzebujesz przewidywalnego wyniku, łatwiej zacząć od OpenAI, bo dostajesz twardą granicę. Jeśli zadanie jest duże i nie chcesz stracić wyniku na limicie czasu, Azure jest bezpieczniejszy.

Uwaga na składanie discountów. Zniżka batchowa mnoży się z cache u Anthropica. Ale na AWS Bedrock cache po prostu nie działa w trybie wsadowym, twardo i bez wyjątku, więc tam te dwie optymalizacje wykluczają się nawzajem.

Routing modeli: większość zapytań nie potrzebuje najdroższego modelu

To jest dźwignia, która w realnych wdrożeniach daje największe oszczędności, a jednocześnie największe ryzyko cichej degradacji jakości.

Logika jest prosta. Nie wszystkie pytania zasługują na najlepszy model. Klasyfikacja intencji, wyciąganie danych z dokumentu, napisanie tematu maila, wybór narzędzia - to zadania, w których mały model daje wynik porównywalny z dużym, przy kilkunastokrotnie niższej stawce. Rozpiętość cen między najtańszym użytecznym a najbardziej sprawnym modelem sięga około 100 razy.

Jak to wygląda na konkretnym wolumenie zadań, pokazuje porównanie kosztu 1000 zadań automatyzacji w n8n.

Skala zależy od tego, kogo zapytasz i jak sformułujesz pytanie. Dokumentacja AWS podaje ostrożną wartość: inteligentny routing promptów obniża koszty nawet o 30% bez utraty dokładności, a modele destylowane są nawet o 75% tańsze i ponad 500% szybsze przy stracie dokładności poniżej 2% dla zastosowań typu RAG. Przewodniki branżowe raportują szerokie widełki, od 40% do 85% obniżki rachunku po wdrożeniu dopracowanej warstwy routingu. Szerokość tych widełek sama w sobie jest informacją: to zależy od Twojego ruchu, nie od technologii.

Jest konkretne badanie, które warto znać, bo dobrze pokazuje mechanizm. Praca RouteLLM raportuje 85% oszczędności przy zachowaniu 95% jakości GPT-4 na zbiorze MT Bench, z macierzowym routerem wysyłającym tylko 14% zapytań do mocnego modelu. To wynik benchmarkowy, nie uniwersalna gwarancja, ale pokazuje mechanizm: największy zysk daje wysyłanie mocnego modelu tylko na pytania, które tego wymagają.

Składanie z dźwigni: przykładowy rachunek

Ponieważ nikt nie publikuje jednego procenta dla całej optymalizacji, policzę ją sam na jednym, w pełni jawnym przykładzie. Ceny pochodzą z tabel cen Anthropic dla Sonnet 5.5 i Haiku 4.5.

Założenia: 20 000 zapytań miesięcznie, każde ze stałym prefiksem 8 000 tokenów (instrukcje, definicje narzędzi, fragment bazy wiedzy), plus 1000 tokenów wejścia zmiennego i 500 tokenów odpowiedzi. Wszystko liczone na Sonnet 5.5, czyli 2 USD za milion tokenów wejścia i 10 USD za milion wyjścia.

Bez optymalizacji to 180 milionów tokenów wejścia i 10 milionów wyjścia, czyli 360 USD plus 100 USD, razem 460 USD miesięcznie.

Po włączeniu cache na stałym prefiksie: odczyt z cache 160 milionów tokenów po 0,20 USD, czyli 32 USD. Pozostałe 20 milionów wejścia zmiennego po pełnej stawce to 40 USD. Wyjście bez zmian, 100 USD. Razem 172 USD. To obniżka o 63%.

Teraz routing: 70% ruchu na Haiku 4.5, 30% na Sonnet 5.5. Odczyt z cache na tańszym modelu kosztuje 0,10 USD za milion, droższy odczyt 0,20 USD - łącznie 20,80 USD. Wejście zmienne 26 USD. Wyjście 65 USD. Razem 111,80 USD. Wobec 460 USD to 76% mniej.

Ostatni krok: przenoszę 40% ruchu na batch. Reszta zostaje synchroniczna, bo tam odpowiedź musi wrócić od razu. Wychodzi 89,44 USD miesięcznie, czyli 81% mniej niż na starcie. W skali roku to ponad 4 400 USD.

To jest podstawa, na której opiera się zakres z tytułu. Nie jeden cudowny mechanizm, tylko cztery zsumowane, z jawnymi założeniami, które możesz podstawić własne.

Krótsze prompty: działa, ale nie na ratchetę

Skracanie kontekstu kojarzy się z oszczędnością, ale w zebranych dokumentacjach i przewodnikach nie znalazłem dla tego procentowej twardej wartości. Nie będę jej zmyślał. To, co jest solidne, to reguła budowy promptu pod cache: wszystko stabilne na początku i identyczne co do bajtu, a każda zmienna (czas, identyfikator uruchomienia, treść od użytkownika) w części wiadomości użytkownika albo dalej w konwersacji.

Warto też inaczej liczyć skrócenie: jeśli skrócisz wejście o 30%, zaoszczędzisz 30% tego, co dotychczas płaciłeś za wejście. To nie jest 30% rachunku, bo wyjście i tak pozostaje pełne. Przy profilu z mojego przykładu wejście to 360 z 460 USD, więc 30% skrócenia wejścia daje 108 USD oszczędności, czyli 23% rachunku. Licz na tej pozycji.

Co psuje oszczędności najczęściej

Routing bez bramki jakości nie jest oszczędnością, tylko zakładem, którego nie widzisz. Gdy zapytanie trafi do tańszego modelu, który nie nadaje się do zadania, odpowiedź jest po cichu gorsza: przeoczony niuans, zmyślony szczegół, narzędzie wywołane bez efektu. Dashboard pokazuje sukces, bo odpowiedź przyszła i wygląda płynnie. Dowiadujesz się z tego z tickets klientów kilka dni później.

Przed wdrożeniem potrzebujesz bramki: zbiór kilkudziesięciu do kilkuset reprezentatywnych przypadków, sprawdzanych pod kątem poprawności, adherence do kontekstu i oceny modelowej, która blokuje każdą zmianę routingu, jeśli jakość spadnie poniżej progu. Zacznij od konserwatywnego podziału, obejdź oczywiście proste zadania, a potem zwiększaj udział taniego modelu o jeden stopień.

Warto też zapisać powód każdej decyzji. Log typu „tier=szybki, bo=format odpowiedzi to JSON” daje Ci dane, na których opierasz kolejną zmianę. Bez tego router jest czarną skrzynką, którą możesz tylko wyłączyć.

Czwarty, mniej oczywisty koszt: sam router zjada trochę czasu. Routing regułowy to ułamek milisekundy, oparty na wektorach około 5 ms, a semantyczny albo cięższy klasyfikator 50-100 ms. Przy typowych czasach odpowiedzi modelu rzędu 500-2000 ms to pomijalne, ale warto to znać, jeśli budujesz interakcję, w której liczy się każda dziesiąta milisekunda.

Kolejność, w której warto to wdrażać

Przewodnik, który trafiłem najbardziej praktyczny, układa te kroki tak: najpierw pomiar, potem przycięcie kontekstu, potem cache prefiksu, potem limit pętli, potem routing po klasach zadań, a na końcu zmiana modelu. Ta kolejność ma sens, bo każdy krok daje informację potrzebną do następnego. Bez pomiaru pierwszego dnia nie wiesz, który z nich da najwięcej.

Limit pętli jest tu wart osobnej wzmianki, bo w sumie kosztów agentów bywa największą pozycją. Agent, który zapętla się i ponawia to samo narzędzie, generuje koszt proporcjonalny do liczby iteracji, a nie do tego, jak trudne jest zadanie. Twardy limit kroków i eskalacja przy jego przekroczeniu są zwykle tańsze niż każda optymalizacja cennika razem wzięta.

Ten sam problem w praktyce opisuję osobno przy agentach AI w n8n: pamięć, narzędzia i human-in-the-loop, bo tam widać, skąd biorą się te powtarzane rundy.

Kiedy zrobić to samemu, a kiedy nie

Prompt cache i batch to dwa dni pracy z dokumentacją. Jeśli znasz się na API, zrób to sam, bo to jednorazowy koszt i potem działa zawsze.

Routing to inna kategoria. Żeby robić go dobrze, potrzebujesz zbioru testowego, bramki jakości i monitoringu, który powie, kiedy tani model zawiódł. Bez tego oszczędność jest realna, ale niewidoczna, a rachunek za nią przychodzi jako utrata klientów. Jeśli nie masz na to czasu, lepiej zostać przy jednym modelu i świadomie wybrać ten tańszy na cały ruch, niż budować router, którego nikt nie monitoruje.

Jeśli chcesz to przejrzeć na własnym ruchu, napisz do mnie. Odpowiadam zwykle tego samego dnia.