Blog – Future Processing
Strona główna Blog Sztuczna inteligencja/uczenie maszynowe Koszt tokenów AI: za co płacisz i dlaczego rachunek wciąż rośnie?
Sztuczna inteligencja/uczenie maszynowe

Koszt tokenów AI: za co płacisz i dlaczego rachunek wciąż rośnie?

Demo nie kosztowało prawie nic. Pierwszy miesiąc produkcji kosztował więcej, niż zakładano. Drugi miesiąc kosztował więcej niż pierwszy. Zanim ktoś eskaluje rozmowę o budżecie na Twoje biurko, Ty sam już gonisz strukturę kosztów, której nie zaprojektowałeś.

Udostępnij:

Spis treści

Udostępnij na:

Ten wzorzec widzimy regularnie. Model, który w testach działał bez zarzutu, w warunkach produkcyjnych po cichu zwielokrotnia swoje zużycie: przez dłuższą historię rozmowy, pobierane dokumenty, ponowienia oraz agentowe przepływy pracy, które do wykonania czegoś, co wyglądało na pojedynczą operację, wykorzystują osiem wywołań modelu. Wydatek na tokeny nie jest pozycją w budżecie, która stoi w miejscu. On się kumuluje.

Celem tego artykułu nie jest przekonanie Cię, że AI jest drogie albo że jest tanie. Oba te ujęcia są mylące. Prawdziwe pytanie brzmi, czy Twoja organizacja ma wgląd i kontrolę pozwalające wydawać świadomie, a obecnie większość ich nie ma.

Najważniejsze wnioski

  • Tokeny wejściowe i wyjściowe są wyceniane inaczej z powodów architektonicznych, nie przypadkowo: generowanie odpowiedzi jest sekwencyjne i wymaga dużej mocy obliczeniowej, kosztuje zwykle trzy do pięciu razy więcej niż tokeny wejściowe, a często więcej, dlatego systemy generujące długie odpowiedzi mają zupełnie inny profil kosztowy niż te, które czytają długie prompty.

  • Nie każde zadanie wymaga najnowszego, najbardziej zaawansowanego modelu; kierowanie 70–80 procent zapytań do tańszych modeli i rezerwowanie modeli klasy frontier dla naprawdę złożonych zadań to decyzja inżynierska o wymiernych konsekwencjach finansowych, a nie kompromis jakościowy..

  • Najbardziej opłacalny sposób na obniżenie kosztów to zwykle ten najprostszy do wdrożenia: sam prompt caching potrafi obniżyć koszt stałego system promptu o około 90%, a mimo to wciąż jest rzadko wykorzystywany.

Tokeny wejściowe vs tokeny wyjściowe: dlaczego ta asymetria liczy się bardziej niż cena z tabeli

Dostawcy publikują cenniki w parach: stawka za tokeny wejściowe i stawka za tokeny wyjściowe, podawane za milion tokenów. Stawka za tokeny wyjściowe jest konsekwentnie wyższa: zwykle trzy do pięciu razy wyższa niż za tokeny wejściowe, czasem więcej. Każdy model Anthropic w tabeli poniżej ma stosunek dokładnie 5x, a modele budżetowe jeszcze więcej. Większość zespołów to zauważa i wzrusza ramionami. Nie powinna.

Powód tej asymetrii jest architektoniczny. Tokeny wejściowe są przetwarzane równolegle na rdzeniach GPU. Model czyta Twój prompt, instrukcje systemowe i pobrany kontekst jednocześnie, w jednym przebiegu w przód. To jest efektywne obliczeniowo. Tokeny wyjściowe są generowane pojedynczo: każde nowe słowo wymaga pełnego przebiegu przez cały model, zanim powstanie kolejne. Ta sekwencyjna zależność jest kosztowna, a koszt narasta z każdym znakiem, który model zapisuje.

Praktyczną konsekwencją jest to, że ta sama cena modelu z nagłówka zachowuje się zupełnie inaczej w zależności od tego, co budujesz. System, który czyta długie dokumenty i odpowiada krótko, ma zasadniczo inny profil kosztowy niż taki, który generuje długie, szczegółowe odpowiedzi. Pipeline do podsumowań, usługa klasyfikująca, agent kierujący ruchem: to zadania intensywne po stronie wejścia, więc stosunkowo tanie w eksploatacji. Asystent do generowania kodu, narzędzie do pisania długich tekstów albo dowolny proces produkujący rozbudowane, ustrukturyzowane odpowiedzi: to zadania intensywne po stronie wyjścia i odpowiednio wycenione.

Większość biznesowych uzasadnień dla wdrożenia AI powstaje na bazie szacunku „na kolanie”, który tę różnicę całkowicie pomija. Zespoły, które budują prawidłowo wycenione uzasadnienia, mierzą rzeczywisty stosunek tokenów wejściowych do wyjściowych dla poszczególnych typów zapytań, na środowisku staging, zanim zobowiążą się do konkretnej architektury. Reszta dowiaduje się o tym z faktury.

Co decyduje o cenie tokenu AI? Kluczowe czynniki

Cena tokena to dopiero punkt wyjścia. Rzeczywisty koszt uruchomienia modelu na produkcji kształtuje kilka zmiennych, które wchodzą ze sobą w interakcje w sposób nie zawsze oczywisty.

Poziom modelu i dostawca wyznaczają dolny próg. Modele frontier, czyli najbardziej zaawansowane i najnowsze wydania od Anthropic, OpenAI czy Google, mają najwyższe stawki za token. Modele średniej klasy i modele destylowane są tańsze o rząd wielkości. Wybór modelu nie jest więc wyłącznie decyzją jakościową: to decyzja o architekturze finansowej, i obie te decyzje powinny zapadać razem.

Rozmiar okna kontekstu to jeden z najbardziej niedocenianych czynników kosztowych. Każdy token w Twoim oknie kontekstu, system prompt, historia rozmowy, pobrane dokumenty i definicje narzędzi, jest rozliczany jako wejście przy każdym pojedynczym zapytaniu. System prompt liczący 4000 tokenów, wysyłany przy 10 000 zapytań dziennie, dodaje 40 milionów tokenów wejściowych dziennie, czyli około 1,2 miliarda miesięcznie, zanim jeszcze doliczysz jakiekolwiek zapytanie użytkownika. Organizacje, które nie zmierzyły narzutu swoich promptów, regularnie odkrywają z zaskoczeniem, że 30–40 procent ich budżetu tokenów pochłania strukturalny „rusztowaniowy” narzut, a nie realna treść od użytkowników.

Typ zadania ma znaczenie w sposób, który nie zawsze przekłada się wprost na możliwości modelu. Zadania wymagające rozbudowanego rozumowania krok po kroku (chain-of-thought) zużywają tokeny inaczej niż czysta generacja czy klasyfikacja. Niektóre rodziny modeli nakładają dodatkową opłatę za tryby rozszerzonego rozumowania; inne wliczają ją domyślnie. Jeśli włączasz funkcje rozumowania bez zrozumienia ich profilu kosztowego w tokenach, działasz po omacku.

Metoda wdrożenia tworzy rozwidlenie w strukturze kosztów. Dostęp przez API od dostawcy takiego jak Anthropic, OpenAI czy Google jest rozwiązaniem domyślnym: płacisz za token, według opublikowanych stawek, a infrastrukturą zarządza dostawca. Modele hostowane samodzielnie przenoszą koszt na moc obliczeniową: godziny instancji GPU, pamięć i infrastrukturę serwującą. Self-hosting niemal nigdy nie jest tańszy przy niskim lub umiarkowanym wolumenie, ale ekonomika może się odwrócić przy bardzo wysokiej przepustowości albo gdy wymogi rezydencji danych uniemożliwiają dostęp do API zewnętrznego dostawcy.

Możliwość korzystania z cache to dźwignia, o której wiele zespołów po prostu zapomina, mimo że to jedno z najszybszych dostępnych usprawnień. Wrócimy do niej szczegółowo za chwilę.

AI Readiness Assessment

Sprawdź, jak przygotowane są Twoje dane, by wspierać i skalować inicjatywy AI w Twojej organizacji.

Jak zbudowany jest cennik modeli AI

Dostawcy grupują modele w trzy szerokie poziomy cenowe, a stawki zmieniają się co miesiąc pomiędzy dostawcami, więc konkretne liczby szybko się dezaktualizują.

  • Modele budżetowe, czyli wersje kompaktowe lub destylowane, znajdują się na dolnym końcu skali.
  • Modele średniej klasy oferują równowagę, której faktycznie potrzebuje większość obciążeń produkcyjnych.
  • Modele frontier, najbardziej zaawansowane i najnowsze, znajdują się na szczycie.

Różnica między najtańszym a najbardziej zaawansowanym poziomem to zwykle 20 do 30 razy, zarówno dla cen wejścia, jak i wyjścia, choć ta rozpiętość z czasem się zmniejsza wraz z rosnącą konkurencją między dostawcami. Obciążenie, które na modelu budżetowym kosztuje kilka dolarów miesięcznie, przy równoważnym wolumenie na modelu frontier może kosztować kilkaset dolarów. Decyzja o tym, który poziom obsługuje które zadanie, nie jest wyłącznie oceną jakościową. To decyzja kosztowa o realnych konsekwencjach finansowych.

Poziomy modeli a kompromis jakość–koszt: kiedy tańszy model to właściwa decyzja inżynierska?

W rozmowach o wdrażaniu AI powtarza się założenie, że najnowszy, najbardziej zaawansowany model jest właściwym wyborem domyślnym. Nie jest.

Każdy nowy model powstaje po to, by rozwiązywać problemy, z którymi poprzednie modele sobie nie radziły. To jego wyraźny cel projektowy, i właśnie dlatego założenie, że najnowsze wydanie jest właściwym narzędziem do każdego zadania, warto dokładnie przeanalizować. Nie każde zadanie jest trudne. Napisanie standardowego artykułu, przetworzenie dobrze ustrukturyzowanego formularza, sklasyfikowanie zgłoszenia do supportu: to nie są problemy wymagające najbardziej zaawansowanego dostępnego modelu. Wymagają modelu wystarczająco dobrego.

Wynikająca z tego zasada inżynierska jest prosta: kieruj zadania według złożoności, nie domyślnie. W organizacjach świadomych kosztowo systemy produkcyjne, które działają dobrze, kierują 70–80 procent zapytań do szybszych, tańszych modeli, a modele frontier rezerwują dla 10–20 procent zadań, które faktycznie wymagają ich możliwości: czy to złożonego rozumowania, wieloetapowej syntezy kodu, czy niejednoznacznych przypadków brzegowych, z którymi mniejsze modele wyraźnie sobie nie radzą.

To warstwowe kierowanie zapytań to nie tylko oszczędność budżetowa. Skraca też opóźnienie dla większości zapytań, bo lżejsze modele odpowiadają szybciej, a zespoły inżynierskie zmusza do jasnego myślenia o tym, o co faktycznie proszą dany model, a to dyscyplina, która procentuje zarówno jakością, jak i kosztem.

Jest tu jedno istotne zastrzeżenie. Dostępność modeli nie jest stała. Dostawcy wycofują starsze wersje w cyklach, zwykle utrzymując dostęp tylko do kilku ostatnich głównych wydań.

Strategie kierowania zapytań, które zależą od konkretnych, wycofywanych wersji, wprowadzają ryzyko. Logika kierowania musi uwzględniać cykl życia modelu, nie tylko aktualną cenę.

Kierowanie zapytań między wieloma dostawcami staje się coraz bardziej praktyczne. Zarówno AWS Bedrock, jak i Azure AI Studio dają dostęp do modeli od wielu dostawców przez jeden interfejs API. Kierowanie partii prostych zadań klasyfikacyjnych do budżetowego modelu jednego dostawcy, przy jednoczesnym wysyłaniu złożonych zadań wymagających rozumowania do modelu frontier innego dostawcy, jest dziś architektonicznie wykonalne, a optymalizacja kosztów jest realna.

Rosnąca konkurencja, nie tylko ze strony ugruntowanych amerykańskich dostawców, ale coraz bardziej ze strony chińskich i europejskich twórców modeli, ten trend przyspiesza. Liczba realnych, wiarygodnych opcji modeli dostępnych na zarządzanych marketplace’ach rośnie.

Jak kontrolować koszt tokenów AI?

Wydatkowanie tokenów bez mechanizmów zarządzania nie jest problemem technicznym. Jest to problem organizacyjny. Zanim zaczniemy optymalizować poszczególne wywołania API, należy zadać ważniejsze pytanie: kto zarządza budżetem tokenów, jaki ma wgląd w dane i w jaki sposób limity są egzekwowane w czasie rzeczywistym, a nie dopiero na koniec miesiąca?

Organizacje, które dobrze kontrolują wydatki na sztuczną inteligencję, stosują kilka wspólnych praktyk:

  • Instrumentują każdy istotny proces w momencie jego wykonania: logują liczbę tokenów w podziale na typ zapytania, agenta i zespół, zanim zmusi ich do tego kryzys kosztowy.
  • Ustawiają limity zużycia na poziomie aplikacji i zespołu: uruchamiają alerty lub throttling zanim rachunki wymkną się spod kontroli, zamiast prowadzić śledztwo w sprawie zeszłomiesięcznych opłat.
  • Rozróżniają koszt zapytania, które przebiega prawidłowo, od kosztu zapytania, które idzie źle: ponowienia, kaskady wywołane halucynacjami modelu oraz ścieżki obsługi błędów często odpowiadają za zaskakująco dużą część wydatków produkcyjnych.

Nawet najbardziej zaawansowany model na świecie nie zrekompensuje danych wejściowych słabej jakości. Zacznij od fundamentów, warstwa analityczna wynika z nich naturalnie.

Drugim elementem, który często brakuje, jest jasno wskazany właściciel. Koszt inferencji AI zwykle wpada w lukę między zespołem danych, zespołem produktowym a finansami. Żaden z nich nie bierze za niego pełnej odpowiedzialności. Efekt jest taki, że wydatek na tokeny jest przeglądany kwartalnie, reaktywnie i zwykle za późno, by wpłynąć na decyzje architektoniczne, które go spowodowały.

Usprawnienie planowania festiwali dzięki narzędziu AI generującemu propozycje line-upu w mniej niż 20 sekund, przy niemal zerowym koszcie operacyjnym

Zobacz case study

Pięć narzędzi optymalizacji kosztów, z których mogą korzystać zespoły produkcyjne

Prompt caching. Powtarzalną część promptu, zwykle instrukcje systemowe, statyczny kontekst lub definicje narzędzi, można zapisać po stronie serwera, dzięki czemu kolejne wywołania odczytują ją z cache za ułamek standardowej stawki za tokeny wejściowe. Anthropic nalicza 10 procent normalnej stawki wejściowej przy trafieniach w cache; OpenAI nalicza 50 procent.

Dla aplikacji produkcyjnej ze stałym system promptem liczącym 4000 tokenów, obsługującej 10 000 zapytań dziennie przy 90-procentowym współczynniku trafień w cache, włączenie cache obniża dzienny koszt tego promptu z około 120 do około 25 dolarów. Odczyty z cache kosztują jedną dziesiątą standardowej stawki, natomiast pozostałe 10 procent, czyli chybienia cache, nadal płaci pełną cenę plus niewielką premię za zapis. To oszczędność blisko 3000 dolarów miesięcznie wynikająca z jednej zmiany konfiguracyjnej. To jedna z konsekwentnie najbardziej opłacalnych dostępnych dźwigni, i konsekwentnie niewykorzystywana.

Warstwowe kierowanie modeli. Jak opisano powyżej: klasyfikuj zadania według złożoności przed wywołaniem modelu i kieruj je odpowiednio. Koszt inżynierski zbudowania logiki kierowania zwykle zwraca się w ciągu kilku tygodni od wdrożenia produkcyjnego na znaczącą skalę.

Dyscyplina okna kontekstu. Każdy token w kontekście jest rozliczany. Utrzymywanie ściśle zakresowanych rozmów, z mniejszą liczbą fragmentów RAG, skompresowanymi system promptami i czyszczoną historią rozmowy po zakończeniu zadania, bezpośrednio obniża wydatek na tokeny wejściowe. Ustawienie rozmowy tak, by odpowiedzi były zwięzłe i celowe, bez obniżenia ich jakości. Chodzi o wyeliminowanie nieodpowiedniego wykorzystania zasobów. Jeśli model produkuje 800 tokenów, gdy 200 wystarczyłoby użytkownikowi równie dobrze, płacisz za 600 tokenów niczego. Przy większych projektach hierarchiczne strukturyzowanie instrukcji, z regułami globalnymi obowiązującymi we wszystkich zadaniach oraz instrukcjami lokalnymi aktywowanymi tylko dla konkretnych procesów, to jeden z najskuteczniejszych sposobów ograniczenia zbędnego kontekstu bez utraty możliwości.

Batch API dla obciążeń asynchronicznych. Większość dostawców oferuje warstwę przetwarzania wsadowego z 50-procentową redukcją kosztu dla zapytań niewymagających odpowiedzi w czasie rzeczywistym. Nocne generowanie raportów, masowe wzbogacanie danych, pipeline’y przetwarzania dokumentów i zadania ewaluacji offline: to wszystko dobrzy kandydaci. Jeśli Twoja architektura traktuje każde zapytanie jako interaktywne, płacisz stawki czasu rzeczywistego za pracę, która spokojnie mogłaby poczekać.

Ograniczenia długości odpowiedzi. Wyraźne instruowanie modelu, by był zwięzły, i określenie docelowego formatu, to najprostsza i najczęściej pomijana dostępna dźwignia. Modele językowe domyślnie generują wyczerpujące, obszerne odpowiedzi. W wielu kontekstach produkcyjnych to nie jest to, czego potrzebuje aplikacja. Ogranicz długość odpowiedzi przez system prompt, przez wymogi ustrukturyzowanego wyjścia albo przez przycinanie na etapie post-processingu. Redukcja kosztu może być znacząca, zwłaszcza w agentowych przepływach pracy, gdzie wyjście modelu zasila kolejne kroki.

Tworzenie budżetu tokenów: od przeglądu faktur do zarządzania wykonaniem

Istnieje zasadnicza różnica między monitorowaniem kosztów związanych z wykorzystaniem sztucznej inteligencji a regulowaniem tego, jakie koszty mogą być ponoszone w związku z jej wykorzystaniem. Większość organizacji zajmuje się dziś tym pierwszym: analizuje faktury, zapoznaje się z podziałem kosztów i wykorzystuje tę wiedzę w kolejnym cyklu planowania. Nie stosują jednak jeszcze budżetów tokenowych w czasie wykonywania, nie ustalają sztywnych lub elastycznych limitów dla poszczególnych aplikacji, agentów i zespołów, które byłyby sprawdzane przed wywołaniem wnioskowania.

To rozróżnienie ma znaczenie, ponieważ obciążenia związane ze sztuczną inteligencją, w przeciwieństwie do większości kosztów oprogramowania, mają charakter nieliniowy i trudno je przewidzieć na podstawie podstawowych zasad. Pojedynczy nieprawidłowo skonfigurowany potok agenta lub nagły wzrost aktywności użytkowników może wyczerpać miesięczny budżet w ciągu kilku godzin. Reaktywne monitorowanie wykrywa to dopiero po fakcie. Proaktywne zarządzanie zapobiega temu.

Powstająca w tym zakresie dyscyplina nazywana jest czasem AI FinOps: polega ona na zastosowaniu ram zarządzania, które Cloud FinOps opracowało dla wydatków na infrastrukturę, do specyficznych cech wydatków związanych z wnioskowaniem AI. Cloud FinOps dało nam instancje zarezerwowane, plany oszczędnościowe, zalecenia dotyczące optymalizacji rozmiaru oraz alokację kosztów według zespołów. Wnioskowanie AI potrzebuje swoich odpowiedników:

  • Limity budżetowe na model: limity wydatków ustalane na poziomie modelu, a nie tylko na poziomie konta
  • Zasady routingu według typu zadania: reguły określające, który poziom modelu obsługuje dany rodzaj żądania
  • Panele wydatków w czasie rzeczywistym z automatycznymi alertami: wgląd w sytuację przed wystawieniem faktury, a nie po
  • Okresowe przeglądy architektury wyzwalane progami kosztowymi: przeglądy przeprowadzane w momencie przekroczenia progu wydatków, a nie zgodnie ze stałym kalendarzem rozliczeniowym

Optymalizacja tokenów przestaje być kwestią drugorzędną, a staje się dedykowaną funkcją. Żyjemy już w świecie, w którym firmy aktywnie analizują strukturę swoich wydatków na sztuczną inteligencję, sprawdzając, które modele są wykorzystywane do poszczególnych zadań, z usług których dostawców korzystają oraz jak wygląda zarządzanie tymi procesami. Jest to po prostu AI FinOps pod inną nazwą i w ciągu najbliższych kilku lat stanie się jedną z najbardziej znaczących dyscyplin.

W Future Processing już teraz współpracujemy z klientami na styku architektury AI i zarządzania kosztami. Dyscypliny inżynieryjne, które tu wchodzą w grę – obejmujące oprzyrządowanie, alokację kosztów, egzekwowanie zasad oraz przegląd architektury – nie są niczym nowym. Nowością jest natomiast zastosowanie ich do struktury kosztów, która narasta w nieprzewidywalny sposób i opiera się intuicyjnym szacunkom.

Data-driven design

Wdrożenia oparte na AI
Case study

Skrócenie czasu przetwarzania ofert pracy o 66% dzięki rozwiązaniu opartemu na AI, zbudowanemu na AWS

Strategiczne wnioski dla decydentów

Najważniejszym działaniem w tej chwili jest wdrożenie narzędzi pomiarowych. Zanim zaczniesz cokolwiek optymalizować, zmierz, ile faktycznie wydajesz: w podziale na przepływy pracy, typy zgłoszeń i poszczególnych agentów. Większość zespołów opiera się na szacunkach. Różnica między szacunkami a rzeczywistością, po jej zmierzeniu, niemal zawsze uzasadnia włożony wysiłek.

Następnie istotna jest kolejność działań. Buforowanie zapytań zapewnia niemal natychmiastowy zwrot z inwestycji i wymaga minimalnych zmian architektonicznych. Wielopoziomowe kierowanie zapytań wymaga więcej pracy projektowej, ale zapewnia największe długoterminowe oszczędności. Dyscyplina w zakresie okien kontekstowych i ograniczenia wyjściowe to praktyki ciągłe, a nie jednorazowe rozwiązania.

Trudniejsze zadania, obejmujące zarządzanie, odpowiedzialność za budżet oraz limity wydatków na poszczególne zespoły, mają charakter raczej organizacyjny niż techniczny. Wymagają one, aby ktoś przejął odpowiedzialność za wydatki na tokeny, podobnie jak dział FinOps w chmurze bierze na siebie odpowiedzialność za infrastrukturę.

Ta rola oraz związane z nią praktyki wciąż dopiero się kształtują w większości organizacji.

Zespoły, które stworzą te ramy zarządzania już teraz, zanim ich obciążenia związane ze sztuczną inteligencją osiągną znaczącą skalę, będą miały znaczną przewagę nad tymi, które wdrożą je dopiero po fakcie. Koszt popełnienia błędu w tym zakresie to nie tylko przekroczenie budżetu. To skumulowane zniekształcenie wynikające z każdej decyzji architektonicznej podjętej bez dokładnych informacji o kosztach.

FAQ

W jaki sposób RAG, agenci i okna kontekstowe zawyżają rzeczywiste wydatki na tokeny?

RAG wprowadza pobrane dokumenty do każdego zapytania jako dodatkowy kontekst, zazwyczaj dodając od trzech do pięciu razy więcej tokenów na wywołanie niż w przypadku zwykłego podpowiedzi. Przebieg pracy agenta dodatkowo potęguje ten efekt, uruchamiając od pięciu do trzydziestu wywołań modelu na każde zadanie użytkownika, z których każde zawiera własną podpowiedź systemową, definicje narzędzi oraz zgromadzoną historię. W rezultacie interakcja użytkownika, która wydaje się obejmować jedno wywołanie modelu, może w rzeczywistości obejmować dziesiątki wywołań, z których każde jest rozliczane według pełnych stawek za tokeny.

Najbardziej pouczającym przykładem tego zjawiska jest automatyzacja przeglądarki realizowana przez agenta. Gdy model otrzymuje zadanie wypełnienia formularza internetowego, musi najpierw odczytać całą zawartość strony, zidentyfikować odpowiednie pola, określić prawidłowe wartości i wprowadzić każdą z nich, często w wielu etapach. Obserwowałem to bezpośrednio podczas testowania Claude’a w przeglądarce Chrome – agenta przeglądarkowego firmy Anthropic. Obserwowanie, jak tokeny znikają na jednej stronie internetowej, było pouczające. Agent musi przetworzyć całą stronę, aby ją zrozumieć, zidentyfikować pola i zdecydować, co wpisać. To zupełnie inna skala w porównaniu z zadaniem bezpośredniego pytania modelowi i uzyskaniem odpowiedzi. Ta sama wymiana informacji, zorganizowana w inny sposób, mogłaby kosztować ułamek tej ceny.

Buforowanie podpowiedzi polega na przechowywaniu po stronie serwera części podpowiedzi przeznaczonej do ponownego wykorzystania – zazwyczaj są to instrukcje systemowe lub kontekst statyczny – dzięki czemu kolejne wywołania odczytują ją z pamięci podręcznej za ułamek normalnej ceny za dane wejściowe. Firma Anthropic pobiera opłatę w wysokości 10 procent standardowej stawki za dane wejściowe w przypadku trafień w pamięci podręcznej; OpenAI pobiera opłatę w wysokości 50 procent.

W przypadku aplikacji produkcyjnej z stałym komunikatem systemowym o długości 4 000 tokenów, obsługującej 10 000 żądań dziennie, włączenie buforowania przy 90-procentowym współczynniku trafień obniża dzienny koszt tego komunikatu z około 120 dolarów do około 25 dolarów, co daje oszczędność prawie 3 000 dolarów miesięcznie dzięki jednej zmianie konfiguracji.

Skorzystaj z następującego wzoru: koszt miesięczny = (liczba żądań dziennych × średnia liczba tokenów wejściowych × cena wejściowa za milion + liczba żądań dziennych × średnia liczba tokenów wyjściowych × cena wyjściowa za milion) × 30.

Krokiem, który większość zespołów pomija, jest pomiar rzeczywistej liczby tokenów dla poszczególnych typów żądań w środowisku testowym, zamiast szacowania na podstawie liczby słów. Komunikaty systemowe, historia rozmów i kontekst RAG rutynowo powodują, że rzeczywiste zużycie tokenów jest od trzech do pięciu razy wyższe niż wynikałoby to z prostego szacunku. Dodaj bufor wynoszący 1,5–2 razy więcej niż wynik, aby uwzględnić ponowne próby, obsługę błędów oraz wzrost wolumenu w pierwszym kwartale produkcji.

Tokeny wejściowe są przetwarzane równolegle przez rdzenie procesora graficznego: szybko, wydajnie i przy niewielkim obciążeniu obliczeniowym. Tokeny wyjściowe muszą być generowane sekwencyjnie. Każde słowo wymaga pełnego przejścia przez cały model, zanim będzie można rozpocząć przetwarzanie następnego, co sprawia, że generowanie jest od trzech do pięciu razy bardziej obciążające obliczeniowo niż odczyt. System, który zwraca długie odpowiedzi, generuje zasadniczo większe obciążenie obliczeniowe niż ten, który odczytuje długie dokumenty i udziela krótkich odpowiedzi.

Tak, a efekt ten szybko się kumuluje. Komenda systemowa o długości 2 000 tokenów wysyłana wraz z każdą wiadomością w ramach 10 000 codziennych rozmów powoduje dodanie 20 milionów tokenów wejściowych dziennie, nie uwzględniając jeszcze treści generowanych przez użytkowników. Ponadto potoki RAG zazwyczaj dodają do tego od 1 000 do 5 000 tokenów na każde zapytanie.

Zespoły, które analizują długość podpowiedzi przed wdrożeniem do środowiska produkcyjnego, rutynowo stwierdzają, że 30–40 procent ich budżetu tokenów jest zużywane na obciążenia strukturalne, a nie na rzeczywiste zapytania użytkowników. Obciążenia te można wyeliminować, ale tylko wtedy, gdy najpierw je zmierzy się.

Wartość, jaką zapewniliśmy

72

obniżenie kosztów po płynnej migracji (w ciągu 20 dni)

Porozmawiajmy

Skontaktuj się z nami i zrewolucjonizuj swoją działalność dzięki naszym kompleksowym usługom.