Kosten en tokens

Kosten per taak is een releasemaat

Teams ontmoeten agentkosten meestal als verrassing op een factuur. Wij behandelen ze als een getal waarvoor je ontwerpt, dat je per taak meet en vóór elke release controleert. Het getal dat voor de business telt, zijn de kosten per taak: wat het kost om één werkeenheid af te ronden, zoals één afgehandeld verzoek of één verwerkt document.

In deze les zoeken we waar de tokens naartoe gaan, meten we ze en trekken we de hefbomen in een volgorde die de kwaliteit beschermt. Tarieflijsten van aanbieders bespreken we niet. Ze veranderen en jouw overeenkomst kan afwijken. Gebruik de cijfers uit je eigen contract.

Waar de tokens naartoe gaan

Eén agentverzoek draagt veel meer dan de vraag. Elk onderdeel heeft een eigen drijfveer.

Een agent roept het model per taak vaak aan en elke aanroep speelt de geschiedenis en de tooldefinities opnieuw af. Daarom kan een "goedkoop" model met een opgeblazen lus meer kosten dan een "duur" model met een strakke lus. De lus en de context bepalen de rekening minstens zo sterk als het model.

Ons artikel over wat kosten en latency van inference op Azure Databricks bepaalt legt de serveropties dieper uit: batch, pay-per-token, provisioned throughput en zelf gehost.

Stap 1: meet per taak, per stap

Je kunt niet verlagen wat je niet gemeten hebt. Leg voor elke taak vast:

• Tokens in en uit per modelaanroep, en per stap in de lus.
• Latency per stap en per taak.
• Het aantal rondes in de lus en het aantal herpogingen.
• Een kwaliteitsscore uit de evaluatieset, naast de kosten.

MLflow Tracing legt elke stap van een agentrun vast met invoer, uitvoer, latency en tokengebruik, dus de data bestaat zodra tracing aanstaat. Unity Gateway kan verzoeken en antwoorden naar Delta-tabellen loggen en gebruik bijhouden, inclusief tokengebruik en latency, in systeemtabellen, met kostenanalyse per service, model, principal en tag.

# Kosten per taak uit tokentellingen. Tarieven komen uit JOUW overeenkomst, per miljoen tokens.
RATE_IN_PER_M  = 1.0   # plaatshouder: vervang door jouw contracttarief voor invoertokens
RATE_OUT_PER_M = 4.0   # plaatshouder: vervang door jouw contracttarief voor uitvoertokens
 
def call_cost(tokens_in: int, tokens_out: int) -> float:
    return tokens_in / 1_000_000 * RATE_IN_PER_M + tokens_out / 1_000_000 * RATE_OUT_PER_M
 
def task_cost(calls: list[dict]) -> float:
    """calls: één dict per modelaanroep in de taak, met tokens_in en tokens_out."""
    return sum(call_cost(c["tokens_in"], c["tokens_out"]) for c in calls)
 
def heaviest_step(calls: list[dict]) -> dict:
    return max(calls, key=lambda c: call_cost(c["tokens_in"], c["tokens_out"]))

De tarieven zijn bewust plaatshouders. Houd geldbedragen in configuratie en houd de tokentellingen als primaire maat, want tokens veranderen niet als een aanbieder zijn tarieven wijzigt.

Stap 2: trek de hefbomen, in deze volgorde

Kies hefbomen op basis van wat de metingen laten zien. Test elke hefboom op je evaluatieset voor hij live gaat.

De eerste rijen zijn het goedkoopst te trekken en dragen het minste kwaliteitsrisico. Bij routing hoort een waarschuwing: het is een kwaliteitsbeheersingsprobleem en geen kostenschakelaar. Een router die moeilijke cases naar een zwak model stuurt, bespaart tokens en verliest antwoorden. Ons artikel over modelrouting als kwaliteitsbeheersing gaat dieper.

Stap 3: guardrails op uitgaven

Zet limieten waar een agent zich er niet langs kan praten.

• Limieten per taak in de harness: stappen, tijd en tokens, zoals in les 1.
• Limieten per team en per gebruiker bij de gateway. Unity Gateway ondersteunt rate limits op model- en MCP-services en budgetten met drempels per gebruiker en harde plafonds.
• Alerts op uitgaven per use case, zodat een agent die gaat lussen dezelfde dag opvalt.

Stap 4: maak kosten per taak een releasepoort

Voeg een regel toe aan de pipeline uit les 4: een nieuwe versie mag alleen live als de kwaliteit op de evaluatieset standhoudt en de kosten per taak binnen het afgesproken budget blijven. Een promptwijziging die de kwaliteit een punt verbetert en de tokens verdubbelt, moet een bewuste keuze zijn en geen ongeluk dat aan het eind van de maand opvalt.

Leg het resultaat per release vast, naast de kwaliteitsscore. Na een paar releases zie je welke wijzigingen liepen.

Veelgemaakte fouten

• Eerst het model optimaliseren. Repareer eerst de lus en de context.
• Alleen gemiddelden. Kijk naar de dure staart: de taken die lussen.
• Kwaliteit inruilen voor kosten zonder te meten. Elke hefboom heeft de evaluatieset nodig.
• Tarieven hard coderen. Houd ze in configuratie.

Samenvatting

Meet tokens per stap en kosten per taak. Trek eerst de goedkope hefbomen met weinig kwaliteitsrisico. Dwing limieten af bij de harness en de gateway. Bewaak releases op kwaliteit en kosten samen.

Volgende les: hoe je je eigen model meebrengt en modellen wisselt zonder herbouw.