Optymalizacja kosztów modeli językowych

Co może pójść nie tak i co z tym robimy.

1. ✕1. Oszczędzanie tokenów psuje cache i podnosi rachunek✓Co zostaje u was: udział trafień w cache przed i po dla każdej rodziny promptów, powiązany z danymi rozliczeniowymi w granicach tego, co udostępnia dostawca

   Co się dzieje

   Wtyczka albo przepisanie promptu przycina kontekst, żeby oszczędzić tokeny. Gdy zmiana dotyka stabilnego prefiksu, prefiks przestaje pasować, cache promptów przestaje trafiać, a ten sam ruch kosztuje więcej niż przed optymalizacją. Zmiana wygląda na oszczędność w każdym wskaźniku poza fakturą.

   Co z tym robimy

   Mierzymy udział trafień w cache, zanim czegokolwiek dotkniemy. Stabilny prefiks traktujemy jako strukturę do ochrony, a nie tekst do kompresji. Po każdej zmianie mierzymy ponownie, żeby regresja była widoczna w tym samym tygodniu.

2. ✕2. Koszt przypisany do modelu, a napędzany przez zachowanie✓Co zostaje u was: wydatki rozbite według przyczyny, a nie według modelu, z uszeregowanymi czynnikami i jednym z nich naprawionym

   Co się dzieje

   Zespoły negocjują cenę za token i porównują dostawców, a koszt rośnie przez ponowienia, dodatkowe wywołania i coraz dłuższy kontekst. W publicznie udokumentowanym przypadku opisanym w naszym przewodniku o cache promptów (Droid przez LiteLLM do Bedrock) rachunek doszedł do 37 901,73 USD przy około 6,47 mld nietrafionych tokenów wejściowych w jednym łańcuchu. Zmiana modelu trochę zmienia cenę jednostkową; zachowanie systemu zmienia całość.

   Co z tym robimy

   Rozbijamy wydatki według tego, co je powoduje: ponowienia, liczba dodatkowych wywołań, przyrost kontekstu na turę, dla każdej funkcji i segmentu użytkowników. Najpierw naprawiamy największy czynnik, niezależnie od tego, czy to reguła routingu, zasady ponowień, czy decyzja produktowa.

3. ✕3. Cache jest obsługiwany i nikt nie sprawdził, czy trafia✓Co zostaje u was: zmierzony udział trafień na każdej warstwie, w granicach liczników dostawcy, oraz limity budżetu z alertami i uzgodnionym zachowaniem po przekroczeniu

   Co się dzieje

   Dostawca dokumentuje cache promptów, więc zespół zakłada, że działa. Obsługa to co innego niż trafienie. Gdy któraś z warstw pośrednich przepisuje prefiks przy każdym wywołaniu, cache nigdy się nie włącza, a bez pomiaru widać to tylko jako rachunek rosnący szybciej niż użycie.

   Co z tym robimy

   Sprawdzamy trafienia na licznikach dostawcy, a nie w dokumentacji. Śledzimy żądanie przez każdą warstwę, która może je przepisać. Ustawiamy z wami limit wydatku: co system ogranicza po jego przekroczeniu i kto to zatwierdza, żeby następna regresja się zatrzymała, zamiast narastać.