Tokeny i rozliczenia API: szacowanie, odczyt, budżet i przykłady

Czym są tokeny i jak naliczane są koszty

Token to najmniejsza jednostka tekstu przetwarzana przez model. Nie jest to ani znak, ani słowo. Traktuj go jak podziałkę na liczniku: im więcej tokenów, tym szybciej rośnie rachunek. Koszty dzielą się na:

Pamiętaj, że cena wyjścia jest czterokrotnie wyższa niż wejścia, więc często opłaca się skłonić model do „mówienia mniej” niż do „wysyłania mniejszego kontekstu”, choć w scenariuszach konwersacyjnych kontekst wejściowy rośnie wraz z historią, więc trzeba pilnować obu stron. Płatność odbywa się z salda przedpłaconego kredytu, nie z subskrypcji; saldo nie wygasa; nowe konto otrzymuje darmowy kredyt próbny w wysokości $0.50, ważny przez 7 dni.

Tokeny wyjściowe to liczba wygenerowanych tokenów, nie max_tokens. max_tokens to tylko limit. Jeśli model odpowie krótko, zapłacisz mniej. Przy szacowaniu budżetu użyj max_tokens, by zabezpieczyć się przed długimi odpowiedziami.

Szacowanie wstępne: jak szacować tokeny PL i EN

Przed wysłaniem zapytania można tylko oszacować. Poniższe wartości są przybliżone i mogą się różnić w zależności od treści:

Poprawne użycie szacowania to „określenie rzędu wielkości”: czy ten artykuł to około 10 000, czy 100 000 tokenów, czy nie przekroczy okna kontekstu 100 000 tokenów, ile kosztuje jedno zapytanie. Aby uzyskać precyzję, przeczytaj usage. Dobrą praktyką jest przeprowadzenie dziesiątek próbnych zapytań dla każdego scenariusza biznesowego, obliczenie średniej z usage i użycie jej zamiast wartości z doświadczenia.

Przykład łączący szacowanie z pomiarem: przetwarzasz partię 2000 znaków chińskiego tekstu. Szacujesz 1.3 tokena na znak, co daje 2600 tokenów + 200 tokenów na prompt = 2800 tokenów wejściowych. Uruchom 30 zapytań i odczytaj uśrednione usage. Jeśli średnia to 2500, zaktualizuj współczynnik do 1.15. Następnie oblicz budżet na partię z użyciem tego współczynnika. Podane wartości są przykładowe.

Odczyt usage: prawdziwy „licznik”

Każda udana odpowiedź zawiera usage z prompt_tokens, completion_tokens i total_tokens. W strumieniowaniu nie potrzebujesz dodatkowych parametrów – usage pojawi się w ostatnim bloku. Poniższy kod pokazuje, jak odczytać oba tryby i przeliczyć koszt na USD:

复制import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])
PRICE_IN, PRICE_OUT = 0.25, 1.00     # 美元 / 百万 token

def cost(u):
    return (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1_000_000

# 非流式：usage 在响应对象上
r = client.chat.completions.create(
    model="uncensored", max_tokens=200,
    messages=[{"role": "user", "content": "用三句话解释什么是通货膨胀。"}],
)
print(r.usage.prompt_tokens, r.usage.completion_tokens, f"${cost(r.usage):.6f}")

# 流式：最后一个数据块带 usage，其余块的 usage 为空
usage_last = None
stream = client.chat.completions.create(
    model="uncensored", max_tokens=200, stream=True,
    messages=[{"role": "user", "content": "再用三句话解释什么是通货紧缩。"}],
)
for chunk in stream:
    if chunk.usage:
        usage_last = chunk.usage
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()
if usage_last:
    print(usage_last.prompt_tokens, usage_last.completion_tokens, f"${cost(usage_last):.6f}")

W strumieniowaniu usage jest tylko w ostatnim bloku. Użyj if chunk.usage, by sprawdzić. Zapisuj wyniki w logach lub bazie danych. Dzięki temu będziesz mógł rozliczać się na koniec miesiąca, wykrywać anomalie i liczyć koszt na użytkownika.

Dodatkowa rada: oznaczaj funkcje w kodzie. Zapisuj koszty osobno dla „podsumowań”, „obsługi klienta” czy „tłumaczeń”. Na koniec miesiąca zobaczysz, która funkcja generuje największe koszty. Dzięki temu podejmiesz decyzję: zoptymalizować prompt, skrócić historię czy zmniejszyć max_tokens. Bez etykiet nie wiesz, co optymalizować.

Trzy przykłady (założenia podano wprost)

Przykład 1: Obsługa klienta

Założenie: każde zapytanie ma 800 tokenów wejściowych (w tym system i fragmenty wiedzy) i 200 tokenów wyjściowych; 10 000 zapytań dziennie.

Koszt pojedynczego zapytania: 800 × 0,25 ÷ 1 000 000 = $0,0002; wyjście 200 × 1,00 ÷ 1 000 000 = $0,0002; razem $0,0004. Dziennie $4,00, 30 dni to $120. Przy takim tempie darmowy kredyt próbny $0,50 wystarczy na około 1250 takich wywołań.

Przykład 2: Streszczenie długich artykułów

Założenie: każdy artykuł ma 20 000 tokenów wejściowych, a streszczenie 600 tokenów wyjściowych; łącznie 500 artykułów.

Pojedynczy artykuł: 20 000 × 0.25 / 1 000 000 = $0.005 + 600 × 1.00 / 1 000 000 = $0.0006, razem $0.0056. Za 500 artykułów zapłacisz łącznie $2.80. Zadania z długim wejściem i krótkim wyjściem są bardzo tanie.

Przykład 3: Czaty wieloetapowe i przycinanie historii

Założenie: system 100 tokenów; każda tura ma 60 tokenów wejściowych od użytkownika i 150 tokenów wyjściowych; jedna rozmowa ma 20 tur.

Wejście dla pełnej historii: 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3 200 + 39 900 = 43 100. Przy cięciu: 160, 370, 580 w pierwszych trzech rundach, a 790 w rundach 4–20, razem 14 540. Koszty różnią się około dwukrotnie; im więcej rund, tym większa różnica, bo pełna historia rośnie kwadratowo.

Z tych trzech przykładów można wyprowadzić wzór: koszt zależy głównie od „liczby zapytań × wielkości wejścia i wyjścia na zapytanie”, a w wielkości wejścia największy wpływ mają historia i dołączone materiały. W obsłudze klienta skracasz fragmenty wiedzy, w czacie przycinasz historię, a przy streszczeniach dzielisz zadania i wykonujesz je równolegle — to ten sam schemat: nie płać za zbędne tokeny. Warto podkreślić, że liczby w tych przykładach pochodzą wyłącznie z podanych wyżej założeń; Twoje rzeczywiste zużycie sprawdź w polu usage.

Spójrzmy na odwrót: jeśli Twój miesięczny budżet to $30, a chcesz wiedzieć, ile 20-turowych rozmów obsłuży Twój produkt czatowy w miesiącu. Przy rozwiązaniu „tylko ostatnie 3 tury” z przykładu 3 koszt jednej rozmowy to około $0,0066, więc $30 ÷ 0,0066 daje około 4545 rozmów. Przy tym samym budżencie, ale przy rozwiązaniu z pełną historią (koszt $0,0138 za rozmowę), starczy Ci tylko na około 2174 rozmów. To realna różnica, jaką daje przycinanie historii.

Kontrola budżetu: zainstaluj zawór w swoim programie

Szacunki to tylko prognoza, zawór to ubezpieczenie. Poniżej przedstawiamy klasę do rozliczania dziennego budżetu w dolarach: przed zapytaniem przewiduj „najgorszy przypadek” (wyjście wykorzystuje max_tokens w pełni), a po zapytaniu rozliczaj się na podstawie rzeczywistego usage.

复制class Budget:
    """按美元计的日预算。超出时拒绝新请求。"""
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def check(self, est_prompt_tokens, max_tokens):
        # 最坏情况：输出用满 max_tokens
        worst = (est_prompt_tokens * 0.25 + max_tokens * 1.00) / 1_000_000
        if self.spent + worst > self.limit:
            raise RuntimeError(f"预算不足：已用 ${self.spent:.4f}，本次最坏 ${worst:.4f}，上限 ${self.limit}")

    def record(self, usage):
        self.spent += (usage.prompt_tokens * 0.25 + usage.completion_tokens * 1.00) / 1_000_000

budget = Budget(daily_usd=5.0)
budget.check(est_prompt_tokens=1200, max_tokens=500)   # 请求前
# ……发请求……
# budget.record(response.usage)                        # 请求后

Poza zaworem w kodzie masz trzy narzędzia na poziomie konfiguracji:

1. Ustaw max_tokens adekwatnie do zadania, nie zawsze na maksimum; domyślnie 2048, maksymalnie 32 000;
2. Ustaw limit długości historii czatu, zgodnie z praktykami opisanymi w Budowanie bota czatu;
3. Doładuj na koncie tylko kwotę, którą planujesz zużyć; doładowuj po wyczerpaniu. Model prepaid to naturalny, twardy limit górny.

Ceny i zasady dotyczące salda są zgodne z Stroną cen, szczegóły interfejsu znajdziesz w Szczegóły parametrów.

Podsumowujemy wszystko na liście kontrolnej: przed — oszacuj skalę, ustaw max_tokens, sprawdź długość historii; w trakcie — przy strumieniowaniu zwracaj uwagę na usage w ostatnim bloku; po — rozlicz się i pogrupuj koszty według funkcji, porównaj z budżetem. Po tych trzech krokach Twoje wydatki będą jasne.