Dlaczego rachunek wystrzelił w górę

Kiedy zespół po raz pierwszy wprowadził generatywną AI, każde zapytanie użytkownika było kierowane do najnowszego i najbardziej zaawansowanego modelu. Wraz ze wzrostem natężenia ruchu, koszty przypadające na pojedyncze zapytanie rosły proporcjonalnie, a arkusz kalkulacyjny dyrektora finansowego (CFO) pokazywał, że wydatki rosną szybciej niż liczba użytkowników. Typowe szybkie rozwiązanie – „po prostu używaj tańszego modelu” – nie sprawdza się w środowisku produkcyjnym, ponieważ różne zapytania wymagają różnych poziomów rozumowania. Kluczowym mechanizmem jest to, jak wysyłane jest zapytanie, a nie to, który model jest zawsze używany.

Budowa warstwy routingu, która oszczędza pieniądze

Inżynier potraktował usługę wnioskowania (inference) jak każdy inny komponent produkcyjny: zdefiniował poziomy (tiers), ustalił standardy SLA i narzucił budżety opóźnień (latency budgets). Wynikowa architektura składa się z czterech elementów, które wspólnie pozwalają na 95-procentową redukcję kosztów.

Routing warstwowy

Lekki front-end klasyfikuje każde przychodzące zapytanie pod kątem trudności. Około 95% zapytań trafia do „taniej” warstwy, która korzysta z mniejszego modelu; tylko 5% najtrudniejszych zapytań jest eskalowanych do modelu premium. Klasyfikacja może opierać się na regułach (np. długość, obecność słów kluczowych specyficznych dla danej dziedziny) lub być wyuczona na podstawie historycznych danych o eskalacji. Dzięki ustawieniu domyślnej taniej warstwy, miesięczny koszt chatbota spadł z 420 USD do 28 USD.

Dopasowanie modelu do zadania

Dopasowanie możliwości modelu do złożoności zadania przynosi największe oszczędności:

  • Prosty czat – użycie lekkiego modelu zamiast flagowej oferty (97,5% oszczędności).
  • Klasyfikacja – zamiana modelu średniej wielkości na tańszą alternatywę (98,3% oszczędności).
  • Podsumowywanie – zastąpienie modelu najwyższej klasy modelem średniej klasy (97,2% oszczędności).

Dokładne nazwy modeli nie są kluczowe; zasada polega na zachowaniu najbardziej zaawansowanego modelu w rezerwie dla tych niewielu zapytań, które naprawdę go wymagają.

Inteligentne buforowanie (caching)

Każde trafienie w cache (cache hit) eliminuje wywołanie sieciowe i opłatę za API. Rozproszony cache Redis przechowuje zarówno udane odpowiedzi, jak i odpowiedzi „negatywne” („Nie wiem”). Gdy to samo pytanie bez odpowiedzi pojawi się ponownie, system zwraca zapamiętane „Nie wiem” zamiast ponownego wywoływania modelu. Przy tysiącach zapytań samo to rozwiązanie znacząco obniża rachunek.

Kompresja promptów

Długie prompty zwiększają zużycie tokenów, co bezpośrednio przekłada się na koszty. Zespół uruchamia tani mechanizm podsumowujący po stronie klienta lub w etapie preprocessingu, skracając kontekst z 2000 tokenów do około 400 tokenów, zanim trafi on do drogiego modelu. Redukcja liczby tokenów mnoży się przy wszystkich zapytaniach, przynosząc ogromne oszczędności bez zmiany doświadczenia użytkownika końcowego.

Strategiczne grupowanie (batching)

Batching grupuje wiele niezależnych zapytań w jedno wywołanie API. Ogólna zasada jest prosta: jeśli użytkownik czeka na odpowiedź, nie stosuj batchingu; jeśli zapytanie odbywa się w tle (raporty nocne, zaplanowane zadania), grupuj wszystko. Same nocne zadania batchowe obniżają wydatki o kolejne 10–20%.

Monitorowanie pętli optymalizacji

Nie można ulepszyć tego, czego nie można zmierzyć. Inżynier ustalił cztery tygodniowe metryki:

  1. Koszt na zapytanie z podziałem na warstwy.
  2. Współczynnik trafień w cache (cache-hit rate) dla każdej ścieżki routingu.
  3. Współczynnik eskalacji z warstw tanich do premium.
  4. Wydatki na segment klienta.

Liczby te pozwalają wykryć dryf – np. rosnący współczynnik eskalacji może sygnalizować, że logika klasyfikacji jest zbyt agresywna lub że jakość taniego modelu uległa pogorszeniu. Zespół co tydzień iteruje nad progami, przypisaniem modeli i politykami cache, zmieniając kontrolę kosztów w nawyk, a nie w reakcję na kryzys.

Wnioski

Dyscyplinowana warstwa routingu, która klasyfikuje zapytania, dopasowuje modele do zadań, agresywnie buforuje dane, kompresuje prompty i grupuje zadania działające w tle, może obniżyć wydatki na API AI nawet o 95%, zachowując przy tym wysoką niezawodność. Traktuj stos wnioskowania (inference stack) jak usługę produkcyjną: definiuj warstwy, mierz wyniki i wprowadzaj cotygodniowe usprawnienia.