Jak twórcy gier mogą oszacować koszt długich dialogów z AI

Najpierw wybierz jasną jednostkę, na przykład koszt wnioskowania modelu na sesję dialogową, na aktywnego gracza dziennie lub na 1000 sesji. W przypadku szacunków dla sesji określ, kiedy sesja się zaczyna i kończy. Praktyczna reguła może brzmieć: „od pierwszego żądania dialogowego do 30 minut bez kolejnego żądania”, ale taki limit czasu jest wyborem pomiarowym, a nie uniwersalnym standardem. Zapisz go, aby inny twórca mógł odtworzyć szacunek.

Zliczaj żądania do modelu, a nie tylko wiadomości gracza. Jedna interakcja może wywołać kilka połączeń — na przykład odpowiedź, a następnie osobne wywołanie do obsługi narzędzia — a ponowne próby mogą ich dodać więcej. Jeśli gra korzysta z głosu, obrazów, wyszukiwania lub narzędzi, rejestruj je w osobnych polach kosztów, a także zapisuj powiązane z nimi tokeny modelu. Cenniki dostawców mogą obejmować opłaty za narzędzia lub stawki zależne od użytej funkcji oprócz standardowych opłat za tokeny tekstowe; na przykład OpenAI podaje osobne opłaty za narzędzia i informuje, że tokeny modelu używane przez wbudowane narzędzia są rozliczane według stawek wybranego modelu (cennik API OpenAI).

Przy każdym wywołaniu rejestruj dostawcę, identyfikator modelu, znacznik czasu, identyfikator sesji, cel żądania, liczbę tokenów wejściowych i wyjściowych oraz wszelkie raportowane zestawienia tokenów objętych pamięcią podręczną lub tokenów rozumowania. Zapisuj ponowne próby, błędy, wywołania narzędzi i informację, czy wywołanie zostało zakończone. Nie przechowuj treści dialogu, chyba że jest to potrzebne do osobnego, uzasadnionego celu produktu; do oszacowania kosztów zwykle wystarczą sumy tokenów i metadane operacyjne.

Jako podstawowy pomiar wykorzystuj dane o użyciu raportowane przez dostawcę dla zakończonych wywołań. Wstępne zliczanie jest przydatne do testowania konstrukcji promptów, ale może nie odpowiadać końcowym pozycjom na rachunku. OpenAI podaje, że raportowane tokeny wyjściowe obejmują też tokeny niewidoczne w tekście, na przykład niektóre tokeny formatowania i struktury narzędzi, oraz zaleca, by nie szacować liczby tokenów wyjściowych wyłącznie na podstawie tego, co widzi gracz (przewodnik OpenAI po zliczaniu tokenów). Dokumentacja Gemini firmy Google również rozróżnia liczbę tokenów promptu, pamięci podręcznej treści, odpowiedzi i tokenów myślenia w metadanych użycia (przewodnik Gemini po tokenach).

Zbuduj reprezentatywną próbę obejmującą nowych i powracających graczy, krótkie i długie rozmowy oraz produkcyjną konfigurację promptów i narzędzi. Jednostką próbkowania powinna być sesja: 40-turowy dialog powinien pozostać jedną obserwacją z łącznym kosztem, a nie być traktowany jako 40 niezależnych sesji graczy. Na etapie prototypu stały zestaw scenariuszy rozmów ułatwia porównywanie zmian promptów; po premierze prognozę powinny wyznaczać zaobserwowane sesje.

W wielu systemach dialogowych każde żądanie zawiera bieżącą wypowiedź użytkownika oraz część lub całość historii rozmowy. Jeśli historia jest przesyłana ponownie, liczba tokenów wejściowych może rosnąć z każdą turą, nawet gdy każda wiadomość gracza jest krótka. Mierz rzeczywisty ładunek żądania wysyłany do modelu; nie mnoż rozmiaru promptu dla jednej tury przez liczbę tur, chyba że implementacja rzeczywiście za każdym razem wysyła taką samą ilość danych.

Pamięć podręczna zmienia stawkę stosowaną do kwalifikujących się, powtarzających się danych wejściowych; nie oznacza to, że cały dialog staje się bezpłatny ani że trwała sesja gwarantuje trafienie w pamięci podręcznej. OpenAI opisuje buforowanie promptów jako ponowne wykorzystywanie niezmienionego prefiksu promptu i zaznacza, że nowe dane wejściowe nadal muszą zostać przetworzone. Diagnostyka pamięci podręcznej może pomóc mierzyć odczyty i braki trafień (przewodnik OpenAI po buforowaniu promptów). Anthropic również rozróżnia zapisy i odczyty pamięci podręcznej oraz publikuje osobne stawki i okresy przechowywania (cennik Anthropic i buforowanie promptów).

W telemetrii rozdziel tokeny wejściowe nieobjęte pamięcią podręczną, tokeny wejściowe z niej korzystające oraz tokeny zapisu do pamięci podręcznej, jeśli dostawca je raportuje. Zapisuj liczbę trafień w pamięci podręcznej podzieloną przez liczbę kwalifikujących się żądań oraz udział tokenów wejściowych faktycznie rozliczanych po stawce dla pamięci podręcznej. Te wskaźniki odpowiadają na różne pytania: wysoki odsetek trafień w żądaniach nadal może oznaczać niewielki udział wszystkich tokenów objętych pamięcią podręczną, jeśli powtarzający się prefiks jest krótki. Kwalifikacja do pamięci podręcznej, minimalne rozmiary, wygaśnięcie, stabilność prefiksu promptu i obsługa modelu zależą od dostawcy; uwzględniaj tylko oszczędności potwierdzone danymi o użyciu.

W przypadku modelu rozliczanego za milion tokenów oblicz koszt każdej sesji według wzoru:

koszt sesji = (tokeny wejściowe nieobjęte pamięcią podręczną × stawka wejściowa + tokeny wejściowe objęte pamięcią podręczną × stawka dla pamięci podręcznej + tokeny zapisu do pamięci podręcznej × stawka za zapis do pamięci podręcznej + tokeny wyjściowe × stawka wyjściowa) ÷ 1 000 000 + inne obowiązujące opłaty

Użyj stawek dla dokładnego modelu, punktu końcowego, trybu, regionu i poziomu usługi w konfiguracji wdrożonej w produkcji. Bezpośrednio przed przygotowaniem budżetu sprawdź je na stronie cennika dostawcy; stawki i katalogi modeli się zmieniają. Uwzględnij opłaty za przechowywanie, jeśli pamięć podręczna rozlicza przechowywane tokeny i czas ich przechowywania. Na przykład opublikowany cennik Gemini podaje kategorie tokenów dla płatnego użycia i stawki za godzinę przechowywania dla niektórych konfiguracji buforowania kontekstu, a dokumentacja rozliczeń wskazuje dane wejściowe, wyjściowe, tokeny objęte pamięcią podręczną i czas przechowywania w pamięci podręcznej jako czynniki podlegające opłatom (cennik Gemini; rozliczenia Gemini).

Przykładowe obliczenie pozwala jasno pokazać przyjęte założenia. Załóżmy wyłącznie na potrzeby ilustracji, że zmierzone wywołania przypisane do jednej sesji zawierają 18 000 tokenów wejściowych nieobjętych pamięcią podręczną, 12 000 tokenów wejściowych objętych pamięcią podręczną i 6000 tokenów wyjściowych. Zastosowanie stawek dla płatnego poziomu Gemini 3.8 Flash opublikowanych dla użycia do 31 grudnia 2026 r. — 0,75 USD za milion tokenów wejściowych, 0,075 USD za milion tokenów objętych pamięcią podręczną i 3,75 USD za milion tokenów wyjściowych — daje 0,0135 USD + 0,0009 USD + 0,0225 USD, czyli 0,0369 USD przed doliczeniem ewentualnych opłat za przechowywanie w pamięci podręcznej lub innych opłat. W tym przykładzie zakłada się, że wymienione tokeny objęte pamięcią podręczną są rozliczane według właściwej dla nich stawki; nie uwzględnia się kosztu początkowego utworzenia pamięci podręcznej, jeśli nie został ujęty w zmierzonych wartościach. Stawki obowiązują przez określony czas, więc przy szacowaniu dla późniejszego okresu należy sprawdzić je ponownie (cennik Gemini).

Nie mnoż kosztu jednej wybranej „typowej” sesji przez liczbę graczy, nazywając wynik prognozą. Podziel zaobserwowane sesje na przedziały według liczby tur lub innego przydatnego kryterium, oblicz średni koszt w każdym przedziale, a następnie uwzględnij udział sesji przypadający na dany przedział. Oprócz średniej podawaj medianę i wyższe percentyle: po przemnożeniu przez liczbę sesji średnia szacuje łączne użycie, a percentyle pomagają określić koszt krótszej lub wyjątkowo długiej sesji.

Jeśli na przykład w próbie jest wiele krótkich sesji i niewielka liczba bardzo długich, podaj zarówno udział sesji w każdym przedziale, jak i koszt dla każdego z nich. Prognozę dla 10 000 sesji można wtedy obliczyć jako sumę iloczynów liczby sesji w przedziale i średniego kosztu w tym przedziale, zamiast zakładać, że każda sesja przypomina ogólną medianę. Jeśli użycie znacznie różni się w zależności od trybu gry, języka, platformy lub tego, czy gracz jest nowy czy powracający, podziel dane na te grupy przed ich połączeniem. Decyzja o podziale na segmenty jest elementem analizy; wyjaśnij, dlaczego każdy segment może wpływać na zużycie tokenów lub sposób wysyłania żądań.

Prowadź zwięzły rejestr założeń obejmujący daty próby, regułę wyznaczania granic sesji, modele i punkty końcowe, wersję promptu, zaobserwowaną liczbę sesji, definicję trafienia w pamięci podręcznej, datę pobrania cennika, uwzględnione opłaty i pominięte składniki. Przedstaw niski, centralny i wysoki scenariusz, zmieniając obserwowalne dane wejściowe — na przykład rozkład długości sesji, rozmiar odpowiedzi lub zmierzony udział trafień w pamięci podręcznej — zamiast stosować niewyjaśniony bufor. Każde przewidywane zachowanie wykraczające poza zaobserwowane sesje przedstaw jako jawny scenariusz, a nie zmierzony fakt.

Kompletność szacunku zależy od zakresu monitorowania i kategorii podlegających opłatom. Może on nie uwzględniać wywołań kierowanych poza rejestratorem, ponownych prób, kategorii tokenów objętych pamięcią podręczną, których API nie udostępnia, tokenów rozumowania przetwarzanych po stronie modelu, czasu przechowywania, przetwarzania multimediów ani opłat dostawcy wykraczających poza stawki za tokeny. Jeśli są dostępne, uzgadniaj dane o użyciu z próbek z raportami rozliczeniowymi dostawcy, analizuj istotne rozbieżności i ponawiaj obliczenia po zmianie modeli, promptów, działania pamięci podręcznej lub funkcji dostępnych dla graczy. Wynik to udokumentowany szacunek kosztów operacyjnych dla zaobserwowanego obciążenia, a nie obietnica, że przyszłe sesje lub faktury będą z nim zgodne.