Wie Spieleentwickler die Kosten langer KI-Dialoge schätzen können

1. Definieren Sie die Einheit, die Sie schätzen

Wählen Sie zuerst eine klare Einheit: zum Beispiel Modell-Inferenzkosten pro Dialogsitzung, pro aktivem Spielertag oder pro 1.000 Sitzungen. Definieren Sie für eine Sitzungsschätzung, wann die Sitzung beginnt und endet. Eine praktische Regel könnte lauten: „von der ersten Dialoganfrage bis zu 30 Minuten ohne Anfrage“, aber dieses Timeout ist eine messtechnische Entscheidung, kein universeller Standard. Dokumentieren Sie sie, damit ein anderer Entwickler die Schätzung reproduzieren kann.

Zählen Sie Modellanfragen, nicht nur Spielernachrichten. Eine einzelne Interaktion kann mehrere Aufrufe auslösen – beispielsweise eine Antwort gefolgt von einem separaten Tool-Aufruf –, und Wiederholungsversuche (Retries) können weitere hinzufügen. Wenn das Spiel Sprache, Bildeingaben, Retrieval oder Tools verwendet, erfassen Sie diese sowohl in separaten Kostenfeldern als auch über die damit verbundenen Modell-Tokens. Die Preise der Anbieter können neben den regulären Gebühren für Text-Tokens auch Tool-Gebühren oder modalitätsspezifische Tarife enthalten; OpenAI listet beispielsweise separate Tool-Gebühren auf und gibt an, dass Modell-Tokens, die für integrierte Tools verwendet werden, zu den Tarifen des gewählten Modells abgerechnet werden (OpenAI API pricing).

2. Messen Sie die tatsächlichen Tokens pro Anfrage

Protokollieren Sie für jeden Aufruf den Anbieter, die Modellkennung, den Zeitstempel, die Sitzungskennung, den Zweck der Anfrage, die Anzahl der Input-Tokens, die Anzahl der Output-Tokens und jede gemeldete Aufschlüsselung nach zwischengespeicherten Tokens (Cached Tokens) oder Reasoning-Tokens. Erfassen Sie Wiederholungsversuche, Fehler, Tool-Aufrufe und ob der Aufruf erfolgreich abgeschlossen wurde. Vermeiden Sie es, Dialoginhalte zu speichern, es sei denn, dies ist für einen separat begründeten Produktzweck erforderlich; Gesamttokanzahlen und Betriebsmetadaten reichen für eine Kostenschätzung in der Regel aus.

Verwenden Sie die vom Anbieter gemeldete Nutzung aus abgeschlossenen Aufrufen als primäre Messgrundlage. Eine Zählung im Vorfeld (Preflight) ist hilfreich, um den Aufbau von Prompts zu testen, stimmt jedoch möglicherweise nicht mit den endgültigen Abrechnungsfeldern überein. OpenAI dokumentiert, dass der gemeldete Output auch Tokens jenseits des sichtbaren Textes umfasst, wie z. B. bestimmte Formatierungs- und Tool-Struktur-Tokens, und empfiehlt, den Output nicht allein anhand dessen zu schätzen, was ein Spieler sieht (OpenAI token-counting guide). Die Gemini-Dokumentation von Google unterscheidet in den Nutzungsmetadaten ebenfalls zwischen Prompt-, zwischengespeicherten Inhalts-, Kandidaten-Output- und Thinking-Token-Zahlen (Gemini token guide).

Erstellen Sie eine repräsentative Stichprobe, die neue Spieler, wiederkehrende Spieler, kurze und lange Konversationen sowie die produktive Prompt- und Tool-Konfiguration umfasst. Behalten Sie Sitzungen als Stichprobeneinheit bei: Ein Dialog über 40 Spielzüge sollte eine einzige Beobachtung mit den kumulierten Kosten bleiben, anstatt wie 40 unabhängige Spielersitzungen behandelt zu werden. Während eines Prototyps hilft ein fester Satz vordefinierter Konversationen beim Vergleich von Prompt-Änderungen; nach dem Launch sollten beobachtete Sitzungen die Prognose bestimmen.

3. Berücksichtigen Sie das Verlaufswachstum und die Kontextwiederverwendung

In vielen Dialogsystemen enthält jede Anfrage den aktuellen Benutzerzug sowie Teile oder die Gesamtheit des bisherigen Gesprächsverlaufs. Wenn der Verlauf wiederholt erneut gesendet wird, können die Input-Tokens mit jedem Zug anwachsen, selbst wenn die einzelnen Spielernachrichten kurz sind. Messen Sie die tatsächliche Nutzlast (Payload), die an das Modell gesendet wird; multiplizieren Sie nicht die Prompt-Größe eines einzelnen Zugs mit der Anzahl der Züge, es sei denn, die Implementierung sendet jedes Mal tatsächlich die gleiche Menge.

Caching ändert den Tarif, der auf berechtigte wiederholte Eingaben angewendet wird; es bedeutet nicht, dass der gesamte Dialog kostenlos wird oder dass eine fortlaufende Sitzung einen Cache-Treffer garantiert. OpenAI beschreibt Prompt-Caching als Wiederverwendung eines unveränderten Prompt-Präfixes und weist darauf hin, dass neue Eingaben dennoch verarbeitet werden müssen. Die Cache-Diagnosen des Anbieters können dabei helfen, Cache-Reads und Cache-Misses zu messen (OpenAI prompt-caching guide). Anthropic unterscheidet in ähnlicher Weise zwischen Cache-Writes und Cache-Reads und veröffentlicht separate Tarife sowie Cache-Dauern (Anthropic pricing and prompt caching).

Trennen Sie in Ihrer Telemetrie nicht zwischengespeicherte Input-Tokens, zwischengespeicherte Input-Tokens und Cache-Write-Tokens, sofern der Anbieter diese ausweist. Erfassen Sie Cache-Treffer geteilt durch berechtigte Anfragen sowie den Anteil der Input-Tokens, die tatsächlich als zwischengespeichert abgerechnet wurden. Diese Werte beantworten unterschiedliche Fragen: Eine hohe Trefferquote über die Anfragen hinweg kann dennoch bedeuten, dass nur ein bescheidener Anteil der Gesamttokens zwischengespeichert wurde, wenn das wiederholte Präfix klein ist. Cache-Berechtigung, Mindestgrößen, Ablaufzeiten, Stabilität des Prompt-Präfixes und Modellunterstützung sind anbieterspezifisch; berücksichtigen Sie nur Einsparungen, die durch Nutzungsdaten bestätigt sind.

4. Wenden Sie Tarife mit einer transparenten Berechnung an

Berechnen Sie für ein Modell mit Preisen pro Million Tokens jede Sitzung wie folgt:

Sitzungskosten = (nicht zwischengespeicherter Input × Input-Tarif + zwischengespeicherter Input × Tarif für zwischengespeicherten Input + Cache-Writes × Cache-Write-Tarif + Output × Output-Tarif) ÷ 1.000.000 + sonstige anfallende Gebühren

Verwenden Sie die Tarife für das genaue Modell, den Endpunkt, die Modalität, die Region und die Servicestufe in der bereitgestellten Konfiguration. Prüfen Sie diese unmittelbar vor der Budgeterstellung unabhängig auf der Preisseite des Anbieters; Tarife und Modellkataloge ändern sich. Beziehen Sie Speichergebühren mit ein, sofern ein Cache für gespeicherte Tokens und Dauer abrechnet. Die veröffentlichten Preise von Gemini listen beispielsweise Token-Kategorien für die kostenpflichtige Nutzung und Speicherstundenpreise für bestimmte Kontext-Caching-Konfigurationen auf, während die Abrechnungsdokumentation Input, Output, zwischengespeicherte Tokens und die Dauer der Cache-Speicherung als abrechenbare Faktoren ausweist (Gemini pricing; Gemini billing).

Eine Beispielrechnung macht Annahmen transparent. Angenommen – rein zur Veranschaulichung –, die gemessenen Aufrufe einer Sitzung enthalten 18.000 nicht zwischengespeicherte Input-Tokens, 12.000 zwischengespeicherte Input-Tokens und 6.000 Output-Tokens. Wendet man die für die Nutzung bis zum 31. Dezember 2026 veröffentlichten Tarife der kostenpflichtigen Stufe von Gemini 3.8 Flash an – 0,75 $ pro Million Input-Tokens, 0,075 $ pro Million zwischengespeicherter Tokens und 3,75 $ pro Million Output-Tokens –, ergibt sich 0,0135 $ + 0,0009 $ + 0,0225 $ oder 0,0369 $ vor eventuellen Cache-Speichergebühren oder sonstigen Kosten. Dieses Beispiel geht davon aus, dass die aufgeführten zwischengespeicherten Tokens zum Cache-Tarif abgerechnet werden, und enthält keine anfänglichen Kosten für die Cache-Erstellung außerhalb der gemessenen Gesamtsummen. Die Tarife sind zeitlich befristet und sollten bei einer Schätzung für einen späteren Zeitraum erneut überprüft werden (Gemini pricing).

5. Nutzen Sie die Verteilung der Sitzungslängen

Multiplizieren Sie nicht eine einzelne handverlesene „typische“ Sitzung mit der Gesamtzahl der Spieler, um dies als Prognose zu bezeichnen. Gruppieren Sie beobachtete Sitzungen nach der Anzahl der Züge oder einem anderen sinnvollen Längenbereich, berechnen Sie die durchschnittlichen Kosten innerhalb jedes Bereichs und gewichten Sie jeden Bereich anschließend mit seinem Anteil an den Gesamtsitzungen. Erfassen Sie neben dem Mittelwert auch den Median und höhere Perzentile: Der Mittelwert schätzt die Gesamtnutzung, wenn er mit dem Sitzungsvolumen multipliziert wird, während Perzentile dabei helfen zu beschreiben, was eine kürzere oder ungewöhnlich lange Sitzung kosten kann.

Wenn eine Stichprobe beispielsweise viele kurze Sitzungen und eine kleine Anzahl sehr langer Sitzungen enthält, weisen Sie sowohl den Anteil der Sitzungen in jedem Bereich als auch die Kosten jedes Bereichs aus. Eine Prognose für 10.000 Sitzungen lässt sich dann als Summe aus (Sitzungen im Bereich × durchschnittliche Kosten im Bereich) berechnen, anstatt anzunehmen, dass jede Sitzung dem Gesamtmedian entspricht. Wenn sich die Nutzung je nach Spielmodus, Sprache, Plattform oder zwischen neuen und wiederkehrenden Spielern erheblich unterscheidet, stratifizieren Sie diese Gruppen vor der Zusammenführung. Die Entscheidung zur Segmentierung ist eine analytische Entscheidung; begründen Sie, warum jedes Segment die Token-Nutzung oder das Anfrageverhalten verändern könnte.

6. Dokumentieren Sie Unsicherheiten und aktualisieren Sie die Schätzung

Führen Sie eine kompakte Annahmenübersicht mit den Stichprobendaten, der Regel für Sitzungsgrenzen, Modellen und Endpunkten, der Prompt-Version, den beobachteten Sitzungszahlen, der Definition von Cache-Treffern, dem Abrufdatum der Preisseite, den enthaltenen Gebühren und den ausgeschlossenen Komponenten. Stellen Sie ein niedriges, mittleres und hohes Szenario dar, indem Sie beobachtbare Eingabegrößen verändern – beispielsweise die Verteilung der Sitzungslängen, die Ausgabegröße oder den gemessenen Cache-Trefferanteil –, anstatt einen unerklärten Puffer anzusetzen. Behandeln Sie jedes prognostizierte Verhalten jenseits der beobachteten Sitzungen als explizites Szenario, nicht als gemessene Tatsache.

Die Schätzung ist nur so vollständig wie ihre Instrumentierung und die abrechenbaren Kategorien. Aufrufe, die am Logger vorbeigeleitet werden, Wiederholungsversuche, von der API nicht offengelegte Kategorien zwischengespeicherter Tokens, modellseitige Reasoning-Tokens, Speicherdauer, Medienverarbeitung oder über Token-Tarife hinausgehende Anbietergebühren können unberücksichtigt bleiben. Gleichen Sie stichprobenartige Nutzungsdaten nach Möglichkeit mit den Abrechnungsberichten des Anbieters ab, untersuchen Sie wesentliche Abweichungen und führen Sie die Berechnung nach Änderungen an Modellen, Prompts, Caching-Verhalten oder spielerbezogenen Features erneut durch. Das Ergebnis ist eine dokumentierte Betriebskostenschätzung für die beobachtete Arbeitslast, kein Versprechen, dass zukünftige Sitzungen oder Rechnungen exakt damit übereinstimmen werden.

Dieses Thema weiter erkunden