Analiza kosztów LLM: trafienia w cache promptów i twarde limity wydatku

Kto skorzysta z tego przewodnika.

• CTO i wiceprezesi ds. inżynierii, którzy dostali rachunek, którego nie umieli wyjaśnić z panelu użycia
• Zespoły platformowe prowadzące bramę albo proxy do LLM (LiteLLM, własny router, Bedrock za warstwą zgodną z OpenAI)
• Zespoły wdrażające pętle agentów, w których każda tura wysyła ponownie całą rozmowę
• Partnerzy z działu finansów, którzy potrzebują kosztu LLM w podziale na funkcje produktu i na klientów, a nie na klucze API

Rachunek czytany jak faktura

Raport użycia dostawcy odpowiada na jedno pytanie: ile tokenów każdego rodzaju przeszło przez każdy klucz API, na model, na dzień. Usage and Cost API Anthropic grupuje po kluczu API, workspace, modelu i poziomie usługi oraz dzieli wejście na tokeny bez cache, zapis do cache i odczyt z cache; Usage API OpenAI i Cloud Billing Google dają podobny podział, z własnymi polami i zasadami rozliczeń. Żaden z nich nie wie, czym jest funkcja ani sesja, bo ta informacja żyje w waszym kodzie.

Faktura potrzebuje trzech złączeń, których panel nie ma. Po pierwsze, każde żądanie niesie nazwę funkcji, identyfikator sesji i klienta (tenant) jako metadane, logowane w bramie obok identyfikatora żądania od dostawcy. Po drugie, blok usage z każdej odpowiedzi jest zapisywany dla każdego wywołania, a nie sumowany na dzień: Anthropic zwraca cache_creation_input_tokens i cache_read_input_tokens, OpenAI zwraca input_tokens_details.cached_tokens i cache_write_tokens, Converse API w Bedrocku zwraca cacheReadInputTokens i cacheWriteInputTokens. Po trzecie, cennik z mnożnikami za zapis i odczyt jest stosowany do każdego wywołania, więc każde żądanie ma własny koszt.

Z tymi złączeniami pytanie zmienia się z: dlaczego rachunek jest wysoki, na: która funkcja, w których sesjach, zapłaciła pełną cenę wejścia za prefiks, który powinien był być w cache. Na takie pytanie istnieje odpowiedź w postaci rankingu.

Jak trzej dostawcy rozliczają pamięć podręczną promptów

Mechanika różni się na tyle, że ogólna zasada od jednego dostawcy daje chybienia u drugiego. Tabela poniżej pochodzi z dokumentacji dostawców sprawdzonej we wrześniu 2026; odnośniki do źródeł, po jednym na dostawcę, są na końcu strony.

Co po cichu psuje prefiks

Analiza sprawdza trzy rzeczy: zmiany prefiksu między żądaniami, wygaśnięcie wpisu i moment wysłania żądań; nie zawsze pozwala ustalić przyczynę, bo dostawcy nie gwarantują trafienia. Katalog poniżej to przyczyny, które diff w analizie potrafi potwierdzić.

• Warstwa oszczędzająca tokeny, która przepisuje historię. Kompresja albo przycinanie starszych wiadomości zmienia bajty przed punktem podziału w każdej turze, więc każda tura zapisuje nowy wpis po 1,25x zamiast czytać po 0,1x. Praktycy na forach programistów opisali dokładnie to: wtyczka sprzedawana jako oszczędzająca tokeny podniosła rachunek w Anthropic. Mniej tokenów po pełnej cenie kosztuje więcej niż więcej tokenów po jednej dziesiątej.
• Definicje narzędzi, które się zmieniają albo zmieniają kolejność. Narzędzia leżą na początku prefiksu, więc dodane narzędzie, zmieniony opis albo lista renderowana z nieuporządkowanego zbioru unieważnia wszystko za sobą.
• Dynamiczna treść na górze promptu systemowego: znacznik czasu, nazwa użytkownika, identyfikator żądania. Jeden bajt przed punktem podziału i to już inny prefiks.
• Proxy, które nie przenosi znacznika. Warstwa zgodna z OpenAI przed Bedrockiem musi przetłumaczyć cache_control na blok cachePoint; jeśli go gubi, każda warstwa nadal deklaruje obsługę cache, a nic nie jest buforowane. Jeden publicznie opisany przypadek: Droid przez LiteLLM do Bedrocka, koniec na 37 901,73 USD i około 6,47 mld tokenów wejścia bez cache.
• Serie równoległych żądań. Anthropic dokumentuje, że wpis staje się dostępny dopiero po rozpoczęciu pierwszej odpowiedzi, więc żądania wysłane naraz mogą zwiększyć liczbę płatnych zapisów tego samego prefiksu; analiza sprawdza to w danych użycia.
• Przełączniki parametrów. Parametry extended thinking i effort, tool_choice, schematy wyjścia i ustawienia rozumowania są częścią tożsamości prefiksu w Anthropic i OpenAI; flaga funkcji, która przełącza jeden z nich, przełącza cache.
• Wygasły czas życia. Zadanie wsadowe, które wysyła jedno żądanie na dokument co dwadzieścia minut, nigdy nie użyje ponownie wpisu pięciominutowego; Anthropic oferuje na taki kształt opcję godzinną, a domyślne okno OpenAI w GPT-5.6 to 30 minut.
• Arytmetyka pętli agentów. Przy przesyłaniu pełnej historii i podobnej długości kolejnych tur łączna liczba tokenów wejścia w sesji rośnie w przybliżeniu kwadratowo z liczbą tur. Z trafieniami większość tych tokenów jest rozliczana po 0,1x; bez nich całość po pełnej cenie.

Gdzie kończy się alert, a zaczyna twardy stop

Alert to e-mail z opóźnieniem liczonym w godzinach; rozpędzona pętla liczy się w żądaniach na sekundę. Kontrole u dostawców, które naprawdę zatrzymują ruch, różnią się między sobą, a te różnice decydują o projekcie.

• Limity na funkcję i na klienta nie istnieją u żadnego dostawcy. Żyją w waszej bramie: licznik na funkcję i na klienta, budżet i kontrolowany błąd po jego osiągnięciu.
• Limit to decyzja produktowa. Zanim zostanie włączony, każda funkcja dostaje spisaną odpowiedź na pytanie, co widzi użytkownik, gdy to się zatrzyma. Po wyczerpaniu budżetu funkcji w bramie: tryb ograniczony, kolejka albo mniejszy model. Po blokadzie u dostawcy: czytelny komunikat, bo wtedy tańszy model też nie odpowie.
• Limit, który nigdy nie zadziałał, jest domysłem. Próba to syntetyczna pętla na projekcie testowym, która dochodzi do limitu, z zapisem, ile trwało egzekwowanie i kto został wezwany.

Jak wygląda raport z analizy i co zespół z nim robi

Rdzeniem raportu jest jedna tabela z jednym wierszem na wywołanie. Wszystko inne w raporcie jest agregatem tej tabeli, więc każdą liczbę ze streszczenia da się prześledzić do żądań, które ją wytworzyły.

• Przyczyny chybień szeregujcie według pieniędzy, które za nimi stoją, a nie według częstości. Ranking pokazuje, ile kosztu niesie każda przyczyna.
• Najdroższe przyczyny naprawiajcie u źródła: zmieńcie kolejność promptu, przypnijcie listę narzędzi, przenieście dynamiczną treść pod punkt podziału, wysyłajcie pierwsze żądanie na prefiks pojedynczo, naprawcie tłumaczenie w proxy.
• Po zmianie uruchomcie tę samą tabelę na raporcie użycia dostawcy jeszcze raz przy porównywalnym obciążeniu i zapiszcie warunki pomiaru: ruch, modele, ceny, długość odpowiedzi. Stan przed i po pochodzi wtedy z tego samego źródła.
• Limit awaryjny u dostawcy ustawcie przed analizą, a budżety funkcji dopasujcie po pomiarze, żeby były ustawione wobec prawdziwego zużycia, a nie wobec błędu.

Co może pójść nie tak i co z tym robimy.

1. 1
   Warstwa oszczędzająca tokeny przepisuje prefiks w każdej turze

   Wtyczka kompresująca albo przycinająca historię siedzi między aplikacją a dostawcą i edytuje starsze wiadomości, żeby wysłać mniej tokenów. Edycja zmienia bajty przed punktem podziału cache, więc każda tura tworzy nowy wpis po cenie zapisu i nic nie czyta. Panel pokazuje mniej tokenów wejścia i wyższy rachunek, a zespół czyta to jako model, który zdrożał.

   Co z tym robimy

   Logujemy kolejne żądania z sesji w bramie i porównujemy je bajt po bajcie, żeby znaleźć pierwszą rozbieżność. Tam, gdzie leży ona wewnątrz rzekomo statycznego prefiksu, przenosimy dynamiczną edycję pod punkt podziału albo usuwamy warstwę. Potem porównujemy cache_read_input_tokens z całym wejściem na raporcie użycia dostawcy dla tej samej funkcji przed zmianą i po niej.

   Co zostaje u was: raport diffu dla każdej sesji z pozycją rozbieżności dla każdego wywołania oraz udział odczytów z cache przed zmianą i po niej
2. 2
   Proxy w łańcuchu gubi znacznik cache

   Aplikacja oznacza punkt podziału, proxy zgodne z OpenAI przekazuje żądanie do Bedrocka, a znacznik nigdy nie staje się blokiem cachePoint. Każda warstwa w łańcuchu dokumentuje obsługę pamięci podręcznej promptów i właśnie to zespół sprawdził. Nic w łańcuchu nie raportuje, że znacznik zginął; jedynym dowodem jest to, że tokeny odczytane z cache po stronie dostawcy zostają na zerze.

   Co z tym robimy

   Odtwarzamy jedno stałe żądanie przez każdy przeskok w łańcuchu i odczytujemy pola cache zwracane na każdym z nich, więc warstwa, która gubi znacznik, jest nazwana, a nie podejrzewana. Naprawiamy tłumaczenie albo konfigurację na tym przeskoku i powtarzamy odtworzenie, aż dostawca zaraportuje odczyty.

   Co zostaje u was: tabela śladu przeskok po przeskoku dla stałego żądania, z polami cache zwracanymi na każdej warstwie
3. 3
   Dynamiczna treść leży nad punktem podziału

   Prompt systemowy zaczyna się od bieżącej daty, nazwy użytkownika albo identyfikatora żądania, albo lista narzędzi jest renderowana ze zbioru bez stałej kolejności. Prefiks różni się w każdym wywołaniu o kilka bajtów, a dostawca słusznie traktuje go jako nowy. To częsta przyczyna i tania w naprawie, a bez diffu pozostaje niewidoczna.

   Co z tym robimy

   Spisujemy układ promptu jako uporządkowaną listę bloków ze stroną statyczną i dynamiczną, przypinamy kolejność narzędzi i przenosimy każdą wartość zależną od żądania za ostatni punkt podziału. Układ dostaje skrót, który brama sprawdza przy każdym żądaniu, więc test wykrywa zmianę statycznego prefiksu przed wdrożeniem.

   Co zostaje u was: specyfikacja układu promptu ze skrótem prefiksu i kontrola w bramie, która nie przechodzi przy zmianie części statycznej
4. 4
   Alert się odzywa i nic się nie zatrzymuje

   Alert budżetowy jest skonfigurowany u dostawcy, a pętla z błędem w warunku wyjścia rusza w nocy. E-mail przychodzi przy progu, dyżurny czyta go rano, a wydatek pomiędzy jest incydentem. Alert dostawcy zrobił to, do czego był zaprojektowany; projekt zakładał człowieka w pętli przy prędkości żądań.

   Co z tym robimy

   Ustawiamy u dostawcy kontrolę, która naprawdę zatrzymuje ruch: limit wydatku na workspace w Anthropic, twardy limit projektu w OpenAI, limit wydatku albo funkcję wyłączającą rozliczanie w Google Cloud. Nad tym dodajemy w waszej bramie budżety na funkcję i na klienta z kontrolowanym błędem i przeprowadzamy próbę, która dochodzi do każdego limitu na projekcie testowym, żeby zapisać opóźnienie egzekwowania.

   Co zostaje u was: rejestr limitów dla każdego dostawcy i każdej funkcji, z zachowaniem widocznym dla użytkownika po osiągnięciu każdego limitu i wynikami próby
5. 5
   Równoległe rozgałęzienie i ponowienia zapisują ten sam prefiks wiele razy

   Funkcja wysyła naraz dziesięć żądań z tym samym prefiksem albo polityka ponowień wysyła pełny prompt przy każdym 429. Anthropic dokumentuje, że wpis w cache staje się dostępny dopiero po rozpoczęciu pierwszej odpowiedzi, więc seria może zapisać wpis raz na żądanie i nie odczytać go ani razu; dane użycia to potwierdzają albo nie. Wskaźnik trafień wygląda akceptowalnie w średniej i fatalnie dokładnie w tych funkcjach, które się rozgałęziają.

   Co z tym robimy

   Wysyłamy pierwsze żądanie na prefiks pojedynczo i zwalniamy resztę, gdy wpis już istnieje, ograniczamy ponowienia i dodajemy losowy odstęp, a stosunek zapisów do odczytów mierzymy dla każdej funkcji, nie dla klucza. Funkcje, które się rozgałęziają, dostają własny wiersz w raporcie, żeby średnia nie mogła ich ukryć.

   Co zostaje u was: stosunek zapisów do odczytów dla każdej funkcji, przed zmianą i po niej, z raportu użycia dostawcy

Co zostaje u was.

• Raport z analizy z jednym wierszem na wywołanie: funkcja, sesja, skrót prefiksu, trafienie albo chybienie, tokeny według klas, koszt, przyczyna chybienia
• Przypisanie kosztu do funkcji, sesji i klienta, uzgodnione z raportem kosztów dostawcy za ten sam okres
• Specyfikacja układu promptu ze skrótem prefiksu i kontrola w bramie, która nie przechodzi przy zmianie części statycznej
• Rejestr limitów: dla każdego dostawcy i każdej funkcji, co zatrzymuje, co powiadamia, co widzi użytkownik i kto jest wzywany
• Zapis próby: każdy limit osiągnięty raz na projekcie testowym, ze zmierzonym opóźnieniem egzekwowania
• Pomiar przed i po na raporcie użycia dostawcy, przy porównywalnym obciążeniu i z zapisanymi warunkami, z użytym zapytaniem, żeby dział finansów mógł go powtórzyć

Jak pracujemy.

1. 1
   1. Zbieranie

   Ustawiamy limit awaryjny u dostawcy, dołączamy metadane funkcji, sesji i klienta w waszej bramie, zapisujemy blok usage z każdej odpowiedzi i pobieramy raporty użycia i kosztów dostawcy za to samo okno. Okres zbierania zależy od ruchu i musi objąć typowe zadania oraz okresy zwiększonego obciążenia.

   Tydzień 1-2
2. 2
   2. Analiza

   Budujemy tabelę dla każdego wywołania, porównujemy kolejne żądania w sesji, odtwarzamy stałe żądanie przez każdy przeskok łańcucha proxy i przypisujemy potwierdzoną przyczynę każdemu chybieniu, które da się wyjaśnić. Przyczyny szeregujemy według pieniędzy, które za nimi stoją.

   Tydzień 2-3
3. 3
   3. Poprawki i limity

   Najdroższe przyczyny naprawiamy u źródła razem z waszym zespołem, spisujemy układ promptu z jego skrótem, a potem dopasowujemy limit u dostawcy i ustawiamy budżety na funkcję ze zdefiniowanym zachowaniem dla każdego. Każdy limit osiągamy raz na projekcie testowym.

   Tydzień 3-5
4. 4
   4. Ponowny pomiar i przekazanie

   Uruchamiamy tę samą tabelę na raporcie użycia dostawcy po zmianie przy porównywalnym obciążeniu i przekazujemy raport, specyfikację układu, kontrolę w bramie i rejestr limitów. Kontrola zostaje w waszym potoku, żeby następna edycja promptu nie mogła po cichu otworzyć chybień na nowo.

   Tydzień 5-6

Pozostałe strony z tej serii.

Usługi, które to wdrażają.

Skąd pochodzą daty i liczby.

• Anthropic, Prompt caching: breakpointy, kolejność, czas życia, mnożniki cen, pola usage, uwaga o równoległości
• Anthropic, Workspaces: miesięczne limity wydatku i limity zapytań per workspace
• Anthropic, Usage and Cost API: grupowanie po kluczu API, workspace i modelu; klasy tokenów z cache i bez
• OpenAI, Prompt caching: dopasowanie prefiksu, minimalna długość, czas przechowywania, rabat za tokeny z cache, pola usage
• OpenAI, Spend limits: twarde limity per organizacja i projekt, kody błędów 429, alerty
• Google, Gemini API context caching: domyślny cache niejawny i minimalne liczby tokenów
• Google, Gemini API cache jawny: domyślny TTL 1 godzina i składniki rozliczenia
• Google, cennik Gemini API: context caching i opłata za przechowywanie na godzinę
• Google Cloud, budżety Cloud Billing: budżety alertowe nie ograniczają wydatku
• AWS, Amazon Bedrock prompt caching: cachePoint, kolejność sekcji, TTL, brak gwarancji trafienia
• Przypadek opisany przez autora na Hacker News: rachunek 37 901,73 USD na Bedrocku po chybieniach cache w łańcuchu proxy