Hoe gameontwikkelaars de kosten van lange AI-dialogen kunnen schatten

Kies eerst een duidelijke eenheid, bijvoorbeeld de inferentiekosten van het model per dialoogsessie, per actieve spelersdag of per 1.000 sessies. Bepaal voor een sessieschatting wanneer een sessie begint en eindigt. Een praktische regel kan bijvoorbeeld zijn: „vanaf het eerste dialoogverzoek tot 30 minuten zonder verzoek”, maar die time-out is een meetkeuze en geen universele standaard. Leg deze vast, zodat een andere ontwikkelaar de schatting kan reproduceren.

Tel modelverzoeken, niet alleen spelersberichten. Eén interactie kan meerdere aanroepen activeren, bijvoorbeeld een antwoord gevolgd door een afzonderlijke aanroep voor toolafhandeling, en nieuwe pogingen kunnen daar nog bijkomen. Als de game spraak, afbeeldingsinvoer, retrieval of tools gebruikt, houd die dan in afzonderlijke kostenvelden bij en registreer ook de bijbehorende modeltokens. De prijzen van aanbieders kunnen naast gewone teksttokentarieven ook toolkosten of modaliteitsspecifieke tarieven omvatten; OpenAI vermeldt bijvoorbeeld afzonderlijke toolkosten en stelt dat modeltokens voor ingebouwde tools tegen de tarieven van het gekozen model worden berekend (OpenAI API-prijzen).

Registreer voor elke aanroep de aanbieder, model-ID, tijdstempel, sessie-ID, het doel van het verzoek, het aantal invoer- en uitvoertokens en eventuele gerapporteerde uitsplitsingen van gecachete tokens of redeneertokens. Registreer nieuwe pogingen, fouten, toolaanroepen en of de aanroep is voltooid. Sla dialooginhoud niet op, tenzij dat nodig is voor een afzonderlijk gerechtvaardigd productdoel; tokenaantallen en operationele metadata volstaan doorgaans voor een kostenraming.

Gebruik het door de aanbieder gerapporteerde gebruik van voltooide aanroepen als primaire meting. Vooraf tellen is nuttig om de opbouw van prompts te testen, maar komt mogelijk niet overeen met de uiteindelijke factureringsvelden. OpenAI documenteert dat de gerapporteerde uitvoer ook tokens omvat die niet zichtbaar zijn in de tekst, zoals bepaalde opmaak- en toolstructuurtokens, en raadt af om de uitvoer uitsluitend te schatten op basis van wat een speler ziet (OpenAI-gids voor het tellen van tokens). Ook de Gemini-documentatie van Google maakt in de gebruiksmetadata onderscheid tussen prompt-, gecachete inhouds-, kandidaatuitvoer- en redeneertokens (Gemini-tokengids).

Stel een representatieve steekproef samen met nieuwe spelers, terugkerende spelers, korte en lange gesprekken en de productieprompt en toolconfiguratie. Gebruik sessies als steekproefeenheid: een dialoog van 40 beurten blijft één observatie met de bijbehorende opgetelde kosten, in plaats van 40 onafhankelijke spelerssessies te vormen. Tijdens een prototype helpt een vaste set gescripte gesprekken om promptwijzigingen te vergelijken; na de lancering moeten waargenomen sessies de prognose bepalen.

In veel dialoogsystemen bevat elk verzoek de huidige gebruikersbeurt plus een deel of de volledige gesprekgeschiedenis. Als de geschiedenis herhaaldelijk wordt meegestuurd, kunnen de invoertokens per beurt toenemen, zelfs wanneer elk spelersbericht kort is. Meet de daadwerkelijke verzoekpayload die naar het model wordt gestuurd; vermenigvuldig de promptgrootte van één beurt niet met het aantal beurten, tenzij de implementatie elke keer werkelijk dezelfde hoeveelheid verstuurt.

Caching verandert het tarief dat geldt voor in aanmerking komende herhaalde invoer; het betekent niet dat het hele dialoog gratis wordt of dat een persistente sessie een cachetreffer garandeert. OpenAI beschrijft promptcaching als hergebruik van een ongewijzigd promptvoorvoegsel en merkt op dat nieuwe invoer nog steeds moet worden verwerkt. De cachediagnostiek kan helpen om cachelezingen en -missers te meten (OpenAI-gids voor promptcaching). Anthropic maakt eveneens onderscheid tussen cachewrites en cachelezingen en publiceert afzonderlijke tarieven en cacheduur (Anthropic-prijzen en promptcaching).

Splits in je telemetrie niet-gecachete invoertokens, gecachete invoertokens en cachewritetokens uit wanneer de aanbieder die rapporteert. Registreer cachetreffers gedeeld door het aantal in aanmerking komende verzoeken, evenals het aandeel invoertokens dat daadwerkelijk als gecachet wordt gefactureerd. Dit beantwoordt verschillende vragen: een hoog trefferpercentage over verzoeken kan nog steeds betekenen dat slechts een bescheiden deel van alle tokens is gecachet als het herhaalde voorvoegsel klein is. Of iets voor caching in aanmerking komt, minimale groottes, vervaltijd, stabiliteit van het promptvoorvoegsel en modelondersteuning verschillen per aanbieder; tel alleen besparingen mee die met gebruiksgegevens zijn bevestigd.

Bereken een sessie voor een model met prijzen per miljoen tokens als volgt:

sessiekosten = (niet-gecachete invoer × invoertarief + gecachete invoer × tarief voor gecachete invoer + cachewrites × cachewritetarief + uitvoer × uitvoertarief) ÷ 1.000.000 + overige toepasselijke kosten

Gebruik de tarieven voor het exacte model, endpoint, de modaliteit, regio en servicelaag in de geïmplementeerde configuratie. Controleer ze vlak vóór het opstellen van een budget op de prijspagina van de aanbieder; tarieven en modellencatalogi veranderen. Neem opslagkosten mee als een cache kosten rekent voor opgeslagen tokens en de opslagduur. De gepubliceerde prijzen van Gemini vermelden bijvoorbeeld tokencategorieën voor betaald gebruik en kosten per opslaguur voor bepaalde configuraties voor contextcaching, terwijl de factureringsdocumentatie invoer, uitvoer, gecachete tokens en de opslagduur van de cache als factureerbare factoren noemt (Gemini-prijzen; Gemini-facturering).

Een uitgewerkt voorbeeld maakt de aannames zichtbaar. Stel, uitsluitend ter illustratie, dat de gemeten aanroepen die aan één sessie zijn toegewezen 18.000 niet-gecachete invoertokens, 12.000 gecachete invoertokens en 6.000 uitvoertokens bevatten. Toepassing van de gepubliceerde tarieven voor de betaalde laag van Gemini 3.8 Flash, geldig tot en met 31 december 2026 — $0.75 per miljoen invoertokens, $0.075 per miljoen gecachete tokens en $3.75 per miljoen uitvoertokens — levert $0.0135 + $0.0009 + $0.0225 op, oftewel $0.0369 vóór eventuele toepasselijke kosten voor cacheopslag of andere kosten. Dit voorbeeld gaat ervan uit dat de genoemde gecachete tokens tegen het gecachete tarief worden gefactureerd en omvat geen initiële kosten voor het aanmaken van de cache buiten de gemeten totalen. De tarieven zijn tijdgebonden en moeten opnieuw worden gecontroleerd bij een schatting voor een latere periode (Gemini-prijzen).

Vermenigvuldig niet één zorgvuldig gekozen „typische” sessie met het totale aantal spelers en noem dat een prognose. Groepeer waargenomen sessies op basis van het aantal beurten of een andere bruikbare lengtecategorie, bereken de gemiddelde kosten binnen elke categorie en weeg die vervolgens naar het aandeel sessies in die categorie. Houd de mediaan en hogere percentielen naast het gemiddelde: het gemiddelde schat het totale gebruik wanneer je het met het aantal sessies vermenigvuldigt, terwijl percentielen helpen te beschrijven wat een kortere of ongewoon lange sessie kan kosten.

Als een steekproef bijvoorbeeld veel korte sessies en een klein aantal zeer lange sessies bevat, rapporteer dan zowel het aandeel sessies in elke categorie als de kosten per categorie. Een prognose voor 10.000 sessies kan dan worden berekend als de som van het aantal sessies per categorie × de gemiddelde kosten per categorie, in plaats van aan te nemen dat elke sessie lijkt op de algehele mediaan. Als het gebruik sterk verschilt per gamemodus, taal, platform of nieuwe versus terugkerende spelers, splits die groepen dan uit voordat je ze samenvoegt. De keuze om segmenten te gebruiken is een analysebeslissing; leg uit waarom elk segment het tokengebruik of het verzoekgedrag kan veranderen.

Houd een beknopt overzicht van aannames bij met de steekproefdatums, de regel voor sessiegrenzen, modellen en endpoints, promptversie, waargenomen aantallen sessies, definitie van cachetreffers, ophaaldatum van de prijspagina, opgenomen kosten en uitgesloten onderdelen. Toon een laag, centraal en hoog scenario door waarneembare invoerwaarden te wijzigen, bijvoorbeeld de verdeling van sessielengtes, uitvoergrootte of het gemeten aandeel cachetreffers, in plaats van een onverklaarde buffer toe te passen. Behandel elk geprojecteerd gedrag buiten de waargenomen sessies als een expliciet scenario, niet als een gemeten feit.

De schatting is slechts zo volledig als je instrumentatie en de factureerbare categorieën. Ze kan aanroepen missen die buiten de logger worden gerouteerd, nieuwe pogingen, categorieën voor gecachete tokens die de API niet beschikbaar stelt, redeneertokens aan de modelzijde, opslagduur, mediaverwerking of kosten van de aanbieder naast de tokentarieven. Vergelijk waar mogelijk steekproefgegevens over gebruik met factureringsoverzichten van de aanbieder, onderzoek wezenlijke verschillen en voer de berekening opnieuw uit na wijzigingen aan modellen, prompts, cachegedrag of functies voor spelers. Het resultaat is een gedocumenteerde schatting van de operationele kosten voor de waargenomen belasting, geen belofte dat toekomstige sessies of facturen ermee overeenkomen.