Token en kosten: schatten, lezen, budget en voorbeelden

Wat zijn tokens en hoe betaal je daarvoor

Een token is de kleinste eenheid die het model gebruikt om tekst te verwerken; het is geen karakter en geen woord, maar een 'fragment' ertussen. Je kunt het zien als een schaalverdeling op een watermeter: hoe meer je verbruikt, hoe sneller de schaal verandert. De facturatie is in twee delen opgedeeld:

Let op: de prijs per token voor output is vier keer zo hoog als voor input. Het is daarom vaak goedkoper om het model 'minder te laten praten' dan om 'minder context te sturen', maar in gesprekken kan de input groeien door de opbouw van de geschiedenis, dus je moet beide kanten in de gaten houden. Je betaalt met een prepaid tegoed, geen abonnement; het tegoed verloopt niet. Nieuwe accounts krijgen $0,50 testtegoed dat 7 dagen geldig is.

Belangrijk: output tokens zijn wat het model echt genereert, niet je max_tokens. Bij schattingen reken je op het maximum om verrassingen te voorkomen.

Schatten vooraf: hoe inschatten voor Chinees en Engels

Vooraf is schatten nodig. Dit zijn benaderingen die kunnen variëren:

De juiste manier om te schatten is een 'orde-van-grootte-bepaling': is dit artikel ongeveer tienduizend of honderdduizend tokens? Zal het contextvenster van 100.000 tokens vollopen? Wat kost één aanroep ongeveer? Voor nauwkeurigheid lees je het usage-veld. Een goede gewoonte is om in elke bedrijfscontext tientallen samples uit te voeren, de gemiddelde usage te berekenen en die te gebruiken in plaats van een ruwe schatting.

Hier is een voorbeeld dat schatten en meten combineert. Stel dat je een batch van ongeveer 2000 Chinese karakter feedback van klanten moet verwerken. Op basis van 1,3 tokens per karakter schat je één verzoek op ongeveer 2600 tokens. Voeg je prompt van 200 tokens toe, dan is de input ongeveer 2800 tokens. Voer eerst 30 voorbeelden uit, lees de usage en neem het gemiddelde. Als het gemiddelde uit de meting 2500 is, pas je je factor aan naar ongeveer 1,15. Bereken daarna het budget voor de hele batch met deze aangepaste factor; de foutmarge is veel kleiner. Dit gemeten getal is slechts een aanname voor de methode; jouw data heeft zijn eigen waarden.

Usage lezen: de echte meterstand

Elke succesvolle response bevat usage met de velden prompt_tokens, completion_tokens en total_tokens. Voor streaming-responses hoef je geen extra parameters in te stellen; er wordt automatisch een data-blok met usage aan het einde toegevoegd. De onderstaande code toont beide manieren om de data te lezen en converteert de waarden naar dollars:

复制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}")

Let bij streaming op: alleen het laatste blok bevat usage; in de eerdere blokken is het leeg, dus gebruik if chunk.usage om dit te controleren. Log elke meting in je logboek of database. Voor de maandafrekening, het opsporen van afwijkingen en het berekenen van de kosten per gebruiker is deze registratie essentieel.

Een andere aanbevolen gewoonte is om elke bedrijfsfunctie een label te geven en de kosten samen met dat label bij te houden. Houd bijvoorbeeld 'samenvatting', 'klantenservice' en 'vertaling' apart bij. Als je aan het eind van de maand de rekeningen vergelijkt, zie je direct welke functie het meest verbruikt en of je de prompt moet optimaliseren, de geschiedenis moet inkorten of max_tokens moet verlagen. Zonder labels heb je slechts één totaalbedrag en kun je moeilijk optimaliseren.

Drie voorbeelden (aannames zijn vermeld)

Voorbeeld 1: klantenservice

Aanname: elk verzoek heeft een input van 800 tokens (inclusief system en kennisfragmenten) en een output van 200 tokens; 10.000 keer per dag.

Enkele kosten: 800 × 0,25 ÷ 1.000.000 = $0,0002, output 200 × 1,00 ÷ 1.000.000 = $0,0002, totaal $0,0004. Dagelijks $4,00, 30 dagen $120. Met dit tempo gaat je gratis proeftegoed van $0,50 ongeveer 1250 keer zo'n aanroep mee.

Voorbeeld 2: samenvatting van lange teksten

Aanname: elke tekst heeft een input van 20.000 tokens, de samenvatting is 600 tokens; in totaal 500 teksten.

Per artikel: 20.000 × 0,25 ÷ 1.000.000 = $0,005, plus 600 × 1,00 ÷ 1.000.000 = $0,0006, totaal $0,0056. Voor 500 artikelen is dat $2,80. Dit laat zien dat taken met lange invoer en korte output goedkoop zijn.

Voorbeeld 3: meerstapschat en bijsnijden van geschiedenis

Aanname: system 100 tokens; per ronde input van de gebruiker 60 tokens, antwoord 150 tokens; één gesprek heeft 20 ronden.

De invoer voor de volledige geschiedenis is: 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3.200 + 39.900 = 43.100. Voor de besnoeiingsoplossing zijn de eerste drie ronden respectievelijk 160, 370 en 580, en elke ronde van 4 tot en met 20 kost 790, totaal 14.540. De kosten verschillen ongeveer een factor twee, en hoe meer ronden, hoe groter het verschil, omdat de invoer voor de volledige geschiedenis kwadratisch groeit met het aantal ronden.

Uit deze drie voorbeelden kun je een vuistregel afleiden: de kosten worden vooral bepaald door het aantal verzoeken vermenigvuldigd met de input- en outputgrootte per verzoek. De geschiedenis en meegeleverde documenten zijn het grootste onderdeel van de input en daar kun je het meest op besparen. Bij klantenservice kun je de kennisfragmenten korter maken, bij chat kun je de geschiedenis bijsnijden en bij samenvattingen kun je parallel werken in chunks. Het principe is hetzelfde: betaal niet voor onnodige tokens. Belangrijk: de cijfers in deze voorbeelden zijn gebaseerd op de bovenstaande aannames; je werkelijke verbruik vind je in de usage-gegevens.

Laten we een omgekeerde berekening maken: als je maandbudget $30 is, hoeveel gesprekken van 20 ronden kun je dan per maand voeren? Met de oplossing van voorbeeld 3 (alleen de laatste 3 ronden meenemen) kost elk gesprek ongeveer $0,0066. Met $30 kun je dan ongeveer 4545 gesprekken voeren. Met hetzelfde budget en de oplossing met volledige geschiedenis (elk gesprek $0,0138) kun je maar ongeveer 2174 gesprekken voeren. Dat is het praktische verschil dat bijsnijden van de geschiedenis maakt.

Budgetbeheer: een limiet in je programma inbouwen

Schattingen zijn alleen een voorspelling; de limiet is de verzekering. Hieronder zie je een klasse voor een dagbudget in dollars: voor een verzoek voer je een 'slechtste-geval'-inschatting uit (output vult max_tokens volledig), en na het verzoek boek je de werkelijke 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)                        # 请求后

Naast een limiet in je code zijn er drie manieren om dit op configuratieniveau te regelen:

1. Stel max_tokens in per taak, niet overal op het maximum; de standaardwaarde is 2048, het maximum is 32.000;
2. Stel een maximale lengte in voor de chatgeschiedenis, zie de aanpak in Chatbot bouwen;
3. Laad alleen het bedrag op dat je van plan bent te gebruiken, en vul aan als het op is. Bij prepaid tegoed is dit van nature een harde limiet.

De tarieven en regels voor het tegoed zijn leidend zoals vermeld op de prijzenpagina. Details over de interface vind je in parameterdetails.

Tot slot een checklist: vooraf, schat de orde van grootte, stel max_tokens in en controleer de lengte van de geschiedenis; tijdens het proces, houd het usage-veld van het laatste blok bij tijdens streaming; achteraf, boek de kosten en groepeer ze per functie om ze te vergelijken met het budget. Na deze drie stappen is de balans duidelijk.