Najpierw wniosek: gwałtowny wzrost kosztów API dużych modeli w ośmiu przypadkach na dziesięć nie wynika z ataku, lecz z kilku niepozornych nawyków wywołań w kodzie, które po cichu spalają pieniądze. W pewnym projekcie inteligentnej obsługi klienta miesięczny rachunek wzrósł z 8000 do 30 000, a pierwszą reakcją szefa było "zostało wyczerpane". Spędziłem dwa dni na analizie i odkryłem, że liczba żądań wcale się nie zmieniła — zmieniła się liczba Tokenów przenoszonych w każdej rundzie rozmowy. Poniżej wyjaśniam kolejno te cztery pułapki, a do każdej podaję rozwiązanie, które można wdrożyć od razu.
I. Historia rozmowy wysyłana w całości w każdej rundzie, wejściowe Tokeny rosną liniowo
To jest najbardziej ukryta pułapka. Wiele zespołów pisząc wieloetapowe rozmowy ma zwyczaj wklejania kompletnej historii wiadomości do tablicy messages w każdym żądaniu. W pierwszej rundzie wysyła 100 Tokenów, w dziesiątej już 1000, a w trzydziestej być może trzy–cztery tysiące. Im dłużej użytkownik rozmawia, tym droższe pojedyncze wywołanie, a większość tej historii to takie puste frazy jak "dobrze" czy "przyjęto".
Działanie optymalizacyjne to przycinanie okna rozmowy plus kompresja przez streszczenie. Zachowujemy oryginalny tekst z ostatnich N rund, a wcześniejsze kompresujemy jednym tanim wywołaniem modelu do jednego akapitu streszczenia, które następnie wstawiamy do system prompt. W naszym projekcie, po zmianie z pełnej historii na "ostatnie 6 rund + streszczenie", wejściowe Tokeny spadły o 60% do 70%, a jakość odpowiedzi w scenariuszu obsługi klienta praktycznie się nie zmieniła. Pamiętaj też o deduplikacji historii wiadomości — powtarzające się powitania po prostu wyrzucamy.
II. Wykorzystywanie flagowego modelu do prostych zadań, nawet klasyfikacja intencji na najwyższej półce
Kolejny duży składnik rachunku to używanie GPT-4o lub Claude 4 Sonnet do zadań takich jak klasyfikacja intencji, ocena sentymentu czy ekstrakcja słów kluczowych. Te zadania są logicznie proste, a wyniki krótkie — używanie do nich flagowego modelu to strzelanie z armaty do wróbla. Wtedy policzyliśmy, że za jednym żądaniem obsługi klienta stoi średnio 3 wywołania klasyfikacji, wszystkie realizowane przez flagowy model.
Rozwiązaniem jest warstwowe routowanie modeli. Proste zadania powierzamy tanim modelom, takim jak DeepSeek-V3, lekka wersja Tongyi Qianwen czy API Doubao, a dopiero końcowe generowanie odpowiedzi idzie przez flagowy model. Właśnie tym powinna zajmować się bramka modeli: automatycznym wyborem modelu według typu zadania. W naszym projekcie porównywaliśmy zakup bezpośrednio od dostawcy z platformą agregującą AI API — SiCore TokenWorks (token8341) rozlicza według zużycia, a zakup hurtowy plus zielona energia obniżają koszty, więc ten sam zestaw wywołań jest tańszy; jednym kluczem można wywołać GPT-4o, Claude, DeepSeek, Tongyi, Doubao i inne popularne modele, co oszczędza kłopot integrowania pięciu SDK. Kluczowym pojęciem jest tutaj struktura kosztów API dużych modeli — to, czy jest drogo, zależy od tego, komu każesz wykonywać jaką pracę.
III. Ponawianie przy przekroczeniu limitu czasu w odpowiedzi strumieniowej bez kontroli idempotencji
Ta pułapka nie ujawnia się bezpośrednio w liczbie Tokenów, lecz w liczbie wywołań. Jeśli w interfejsie strumieniowym klient przekroczy limit czasu i zerwie połączenie, wiele implementacji bezmyślnie ponawia próbę, ale serwer zdążył już wygenerować część treści, a Tokeny są nadal odliczane. Trzy ponowienia to trzykrotny koszt, a użytkownik może zobaczyć tylko jedną odpowiedź. Gorzej, gdy odpytywanie po stronie frontendu łączy się z ponawianiem po stronie backendu — to samo żądanie może zostać wysłane pięć–sześć razy.
Są dwa działania do wdrożenia. Po pierwsze, każde żądanie powinno zawierać klucz idempotencji; serwer rozpoznaje duplikat i zwraca wynik z pamięci podręcznej, nie wykonując ponownego wnioskowania. Po drugie, strategię ponawiania zmieniamy z "stałe 3 próby" na "wykładniczy backoff + maksymalnie 1 próba", i tylko przy nieudanym nawiązaniu połączenia — gdy odebrano już pierwszy Token, nigdy nie wysyłamy ponownie. Po dodaniu tych dwóch zasad liczba nietypowych wywołań w naszym projekcie spadła o blisko połowę.
IV. Wspólny klucz dla testów i produkcji, koszty nie do rozdzielenia
Podczas analizy najbardziej bolała głowa właśnie od tego. Środowisko testowe przeprowadzało testy obciążeniowe i regresyjne, używając tego samego klucza API co produkcja, więc z rachunku nie dało się odróżnić, które opłaty pochodzą od rzeczywistych użytkowników. Gdy wykryto anomalie, minęło już kilka tygodni, a logi się nie zgadzały.
Rozwiązanie jest proste: rozdziel klucze API według środowiska i linii biznesowej, a zużycie każdego klucza śledź osobno. Platformy agregujące AI API zwykle obsługują zarządzanie wieloma kluczami i pulpity zużycia — gdy zarządzanie kluczami API jest dopracowane, od razu widać, kto przepala pieniądze. Przy okazji ustaw dzienny limit dla klucza testowego — sytuacja, w której skrypt testów obciążeniowych przez pomyłkę łączy się z kluczem produkcyjnym, zostanie wyeliminowana u źródła.
Podsumowanie w jednym zdaniu
Utrata kontroli nad rachunkiem za API dużych modeli to zwykle nie kwestia ceny jednostkowej, lecz sposobu wywołań. Przytnij okno rozmowy, zdegraduj proste zadania, opanuj ponawianie, rozdziel klucze — po wykonaniu tych czterech rzeczy powrót kosztów do rozsądnego przedziału nie jest trudny. Jeśli chcesz dowiedzieć się więcej o ujednoliconej integracji wielu modeli i rozliczaniu według zużycia, poszukaj materiałów w kierunkach "agregacja AI API" i "routowanie modeli".