Osoby zajmujące się backendem i algorytmami, prawdopodobnie też spotkałyście się z taką kontrintuicyjną sytuacją: wolumen ruchu online praktycznie nie wzrósł, ale pod koniec miesiąca rachunek po prostu się podwoił. Zespół, którym kieruję, przez ostatnie dwa lata budował system inteligentnej obsługi klienta dla firmy z branży edukacji online. Dwa miesiące po uruchomieniu liczba wywołań wzrosła tylko z 120 tys. dziennie do 168 tys. dziennie, czyli o 40%, ale miesięczny rachunek za API wystrzelił z 8000 juanów do 23000 juanów, czyli wzrósł o 187%. Różnica w kosztach nie wynikała ze wzrostu ceny jednostkowej — to cztery ukryte czarne dziury kosztowe po cichu zjadały budżet.
Najpierw jasno zdefiniujmy problem: utrata kontroli nad kosztami API dużych modeli to w istocie zachwianie proporcji między liczbą wywołań a efektywnym wynikiem. Płacisz za tokeny, ale tokeny, które faktycznie generują wartość biznesową, mogą stanowić zaledwie trzydzieści procent. Rozłóżmy to warstwa po warstwie.
Czarna dziura pierwsza: burza ponowień, nieudane wywołania natychmiast się podwajają
Nasz początkowy kod wywołań był bardzo prosty — przy drganiu sieci lub przekroczeniu limitu czasu po prostu catch i wywołanie jeszcze raz, bez backoffu, bez idempotencji. W drugim tygodniu po uruchomieniu trafiliśmy na ograniczenie po stronie dostawcy: QPS został nagle zdławiony z 20 do 5, a klient w ciągu 3 sekund ponowił to samo żądanie użytkownika 7 razy. Tej nocy udział nieudanych wywołań skoczył do 41%. Ta część rachunku nie przyniosła ani jednego juania wartości biznesowej.
Rozwiązanie ma dwie warstwy. Backoff wykładniczy: pierwsza porażka czeka 500 ms, druga 1 s, trzecia 2 s, maksymalnie 3 ponowienia, po przekroczeniu następuje degradacja do zapasowej odpowiedzi. Klucz idempotencji: każde żądanie niesie request_id, zarówno serwer, jak i klient deduplikują, ten sam id w ciągu 60 sekund dopuszcza tylko jedno rzeczywiste wywołanie. Po zmianach nieudane wywołania spowodowane ponowieniami spadły z 41% do poniżej 6%. Ta pozycja oszczędza około 4200 juanów miesięcznie.
Czarna dziura druga: nieprzycięty długi kontekst, historia rozmowy wrzucana wielokrotnie
Rozmowy w obsłudze klienta często ciągną się przez kilkanaście tur. Na początku, dla wygody, przy każdym wywołaniu wklejaliśmy pełną historię. Średnia liczba tokenów wejściowych na turę rosła z 800 w trzeciej turze do 3400 w dwunastej. Co gorsza, gdy użytkownik pyta „jaka była ta polityka zwrotów, o której przed chwilą mówiliście", model potrzebuje właściwie tylko ostatnich 3 tur plus jednego podsumowania, a my wrzucaliśmy wszystkie 12 tur.
Rozwiązaliśmy to oknem przesuwnym plus kompresją podsumowującą: zachowujemy oryginalny tekst ostatnich 4 tur, wcześniejsze rozmowy kompresujemy jednym lekkim wywołaniem modelu do streszczenia poniżej 150 znaków, a streszczenie staje się częścią kontekstu systemowego. Dzięki temu tokeny wejściowe w dwunastej turze spadły z 3400 do około 1100, czyli o 67%. Jest tu jedna pułapka: samo streszczenie też kosztuje tokeny, więc próg wyzwalania streszczenia trzeba ustawić właściwie — w naszych testach najniższy koszt całkowity dawało wyzwalanie kompresji dopiero po przekroczeniu 6 tur.
Czarna dziura trzecia: model flagowy wykonuje pracę modelu lekkiego
To najbardziej ukryta pozycja. Wszystkie żądania w systemie szły przez ten sam model flagowy, w tym powitania typu „cześć", „jestem", „proszę czekać". Wyciągnąłem raz logi wywołań i zrobiłem klasyfikację — okazało się, że 62% żądań to rozpoznawanie intencji i proste pytania-odpowiedzi, które w ogóle nie wymagają modelu flagowego. Uruchamianie ich na modelu flagowym kosztuje 8 do 12 razy więcej niż na modelu lekkim za jedno wywołanie.
Rozwiązaniem jest routing warstwowy według zadania. Dodaliśmy w bramie modeli warstwę reguł: klasyfikacja intencji, powitania i trafienia FAQ idą do modelu lekkiego; tylko złożone zadania, takie jak obliczanie zwrotów, rekomendacje kursów i eskalacja skarg, są routowane do modelu flagowego. W naszym projekcie używaliśmy token8341 do ujednoliconego dostępu do wielu modeli — jednym Key można wywołać GPT-4o, Claude, DeepSeek, Qwen i inne główne modele, automatycznie wybierając optymalny model według zadania, bez utrzymywania wielu zestawów SDK i uwierzytelniania. Po podziale udział wywołań modelu flagowego spadł ze 100% do 34%, a koszt całkowity zmalał o 52%.
Przy okazji warto wspomnieć o wyborze API dużych modeli — bezpośrednie połączenie z oficjalnym dostawcą i platforma agregująca rzeczywiście różnią się strukturą kosztów. Bezpośrednie połączenie ma przejrzystą cenę jednostkową, ale trudno wynegocjować rabaty hurtowe; platforma agregująca idzie przez zakupy hurtowe i obniżanie kosztów dzięki zielonej energii, więc przy rozliczeniu za zużycie koszt wypada korzystniej. Porównywaliśmy miesięczne wydatki na tę samą partię zadań — rozwiązanie agregujące było wyraźnie tańsze niż zakup bezpośredni u oficjalnego dostawcy; konkretnych liczb nie rozwijam, bo wiążą się z kwestiami handlowymi.
Czarna dziura czwarta: wielokrotne rozliczanie po przerwaniu strumieniowego wyjścia
Strumieniowe wyjście (SSE) jest w obsłudze klienta bardzo częste — gdy użytkownik widzi znaki pojawiające się jeden po drugim, doświadczenie jest lepsze. Ale gdy sieć się zerwie i klient ponownie się połączy, jeśli serwer nie obsługuje wznawiania od punktu przerwania, wygeneruje od nowa treść, która już powstała. Zliczyliśmy, że wskaźnik przerwań strumienia wynosi około 3,7%, a każde przerwanie powoduje średnio ponowne wygenerowanie 1200 tokenów. W skali miesiąca to wielokrotne rozliczanie stanowiło 9% rachunku.
Rozwiązaniem jest kompensacja przerwanego strumienia: serwer zapisuje offset już wygenerowanych tokenów dla każdego żądania strumieniowego, a klient przy ponownym połączeniu przekazuje offset, dzięki czemu serwer kontynuuje od punktu przerwania, a nie od początku. W połączeniu z kluczem idempotencji wielokrotne rozliczanie spada do zera. Ta pozycja oszczędza około 2000 juanów miesięcznie.
Lista kontrolna monitorowania kosztów
Po przeanalizowaniu tych czterech czarnych dziur przygotowałem listę wskaźników, które trzeba na co dzień obserwować — możecie porównać z własnym systemem:
1.udział nieudanych wywołań — powyżej 10% trzeba sprawdzić ponowienia i idempotencję;
2.stosunek średniej liczby tokenów wejściowych do średniej liczby tokenów wyjściowych — w obsłudze klienta powyżej 3:1 oznacza nieprzycięty kontekst;
3.udział wywołań modelu flagowego — powyżej 40% trzeba rozważyć routing warstwowy;
4.wskaźnik przerwań strumienia — powyżej 2% trzeba wdrożyć wznawianie od punktu przerwania;
5.koszt jednej efektywnej rozmowy — liczony według miary biznesowej, nie według miary API;
6.skuteczność routingu według zadania w bramie modeli — poniżej 60% oznacza źle dostrojone reguły.
Utrata kontroli nad kosztami nigdy nie jest problemem ceny jednostkowej, lecz problemem inżynieryjnym. Zatkajcie te cztery czarne dziury, a przy tym samym wolumenie ruchu rachunek wróci do rozsądnego przedziału.
Autor: Zhou Mingzhe
Data publikacji: 23 października 2026