Comment les développeurs de jeux peuvent estimer le coût des longs dialogues IA

1. Définir l'unité que vous estimez

Choisissez d'abord une unité claire : par exemple, le coût d'inférence du modèle par session de dialogue, par jour de joueur actif ou pour 1 000 sessions. Pour une estimation par session, définissez le moment où la session commence et se termine. Une règle pratique pourrait être « de la première requête de dialogue jusqu'à 30 minutes sans requête », mais ce délai d'inactivité est un choix de mesure, et non une norme universelle. Consignez-le pour qu'un autre développeur puisse reproduire l'estimation.

Comptez les requêtes adressées au modèle, et pas seulement les messages du joueur. Une seule interaction peut déclencher plusieurs appels — par exemple, une réponse suivie d'un appel distinct de gestion d'outils — et les nouvelles tentatives peuvent en ajouter d'autres. Si le jeu utilise la voix, l'entrée d'images, la recherche d'informations (retrieval) ou des outils, isolez-les dans des champs de coûts distincts tout en enregistrant les tokens de modèle associés. Les tarifs des fournisseurs peuvent inclure des frais liés aux outils ou des prix spécifiques à la modalité en plus des frais ordinaires de tokens de texte ; OpenAI, par exemple, répertorie des frais d'outils distincts et indique que les tokens de modèle utilisés pour les outils intégrés sont facturés aux tarifs du modèle choisi (OpenAI API pricing).

2. Mesurer les tokens réels par requête

Pour chaque appel, enregistrez le fournisseur, l'identifiant du modèle, l'horodatage, l'identifiant de la session, l'objectif de la requête, le nombre de tokens d'entrée, le nombre de tokens de sortie, ainsi que toute ventilation signalée pour les tokens en cache ou de raisonnement. Consignez les nouvelles tentatives, les erreurs, les appels d'outils et le statut d'achèvement de l'appel. Évitez de stocker le contenu du dialogue, sauf si cela est justifié par un besoin fonctionnel distinct ; le nombre total de tokens et les métadonnées opérationnelles suffisent généralement à estimer les coûts.

Utilisez l'utilisation rapportée par le fournisseur pour les appels terminés comme mesure principale. Le pré-comptage est utile pour tester la construction des prompts, mais il peut ne pas correspondre aux champs de facturation finaux. OpenAI indique que la sortie rapportée inclut des tokens au-delà du texte visible, tels que certains tokens de mise en forme et de structure d'outils, et recommande de ne pas estimer la sortie uniquement à partir de ce que voit le joueur (OpenAI token-counting guide). La documentation de Gemini de Google distingue de même les comptes de tokens de prompt, de contenu mis en cache, de sortie candidate et de réflexion dans les métadonnées d'utilisation (Gemini token guide).

Constituez un échantillon représentatif comprenant de nouveaux joueurs, des joueurs qui reviennent, des conversations courtes et longues, ainsi que la configuration des prompts et des outils en production. Conservez les sessions comme unité d'échantillonnage : un dialogue de 40 tours doit rester une seule observation avec son coût cumulé, plutôt que d'être traité comme 40 sessions de joueur indépendantes. Lors d'un prototype, un ensemble fixe de conversations scénarisées aide à comparer les modifications de prompts ; après le lancement, ce sont les sessions observées qui doivent guider les prévisions.

3. Prendre en compte la croissance de l'historique et la réutilisation du contexte

Dans de nombreux systèmes de dialogue, chaque requête comprend le tour actuel de l'utilisateur plus une partie ou la totalité de l'historique de la conversation. Si l'historique est renvoyé à chaque tour, les tokens d'entrée peuvent augmenter à chaque échange, même lorsque chaque message du joueur est court. Mesurez la charge utile réelle de la requête envoyée au modèle ; ne multipliez pas la taille du prompt d'un seul tour par le nombre de tours, sauf si l'implémentation envoie réellement la même quantité à chaque fois.

La mise en cache modifie le tarif appliqué aux entrées répétées éligibles ; cela ne signifie pas que l'intégralité du dialogue devient gratuite ou qu'une session persistante garantit un accès réussi au cache (cache hit). OpenAI décrit la mise en cache de prompts comme la réutilisation d'un préfixe de prompt inchangé et souligne que la nouvelle entrée doit toujours être traitée. Ses diagnostics de cache peuvent aider à mesurer les lectures et les échecs de cache (OpenAI prompt-caching guide). Anthropic distingue de la même manière les écritures en cache des lectures en cache et publie des tarifs et des durées de cache distincts (Anthropic pricing and prompt caching).

Dans votre télémétrie, séparez les tokens d'entrée non mis en cache, les tokens d'entrée mis en cache et les tokens d'écriture de cache lorsque le fournisseur les signale. Enregistrez les accès réussis au cache divisés par les requêtes éligibles, ainsi que la part des tokens d'entrée réellement facturés comme étant mis en cache. Ces éléments répondent à des questions différentes : un taux de réussite élevé sur les requêtes peut tout de même signifier qu'une part modeste du total des tokens a été mise en cache si le préfixe répété est de petite taille. L'éligibilité au cache, les tailles minimales, l'expiration, la stabilité du préfixe de prompt et la prise en charge par le modèle dépendent des fournisseurs ; ne comptez que les économies confirmées par les données d'utilisation.

4. Appliquer les tarifs avec un calcul transparent

Pour un modèle tarifé par million de tokens, calculez chaque session comme suit :

coût de la session = (entrée non mise en cache × tarif d'entrée + entrée en cache × tarif d'entrée en cache + écritures en cache × tarif d'écriture en cache + sortie × tarif de sortie) ÷ 1 000 000 + autres frais applicables

Utilisez les tarifs correspondant exactement au modèle, au point de terminaison (endpoint), à la modalité, à la région et au niveau de service de la configuration déployée. Vérifiez-les de manière indépendante sur la page de tarification du fournisseur juste avant de préparer un budget ; les tarifs et les catalogues de modèles évoluent. Incluez les frais de stockage lorsqu'un cache facture les tokens stockés et la durée. Par exemple, la tarification publiée de Gemini répertorie les catégories de tokens pour l'utilisation payante et une tarification par heure de stockage pour certaines configurations de mise en cache de contexte, tandis que sa documentation de facturation identifie l'entrée, la sortie, les tokens mis en cache et la durée de stockage en cache comme des facteurs facturables (Gemini pricing; Gemini billing).

Un exemple de calcul chiffré rend les hypothèses visibles. Supposons, à titre purement indicatif, que les appels mesurés attribués à une session contiennent 18 000 tokens d'entrée non mis en cache, 12 000 tokens d'entrée mis en cache et 6 000 tokens de sortie. L'application des tarifs de l'offre payante de Gemini 3.8 Flash publiés pour une utilisation jusqu'au 31 décembre 2026 — 0,75 $ par million de tokens d'entrée, 0,075 $ par million de tokens mis en cache et 3,75 $ par million de tokens de sortie — donne 0,0135 $ + 0,0009 $ + 0,0225 $, soit 0,0369 $ avant tout frais éventuel de stockage de cache ou autres frais applicables. Cet exemple suppose que les tokens mis en cache listés sont facturés au tarif du cache et n'inclut aucun coût initial de création de cache en dehors des totaux mesurés. Les tarifs sont limités dans le temps et doivent être revérifiés lors de l'estimation pour une période ultérieure (Gemini pricing).

5. Utiliser la distribution des durées de session

Ne multipliez pas une session « typique » choisie arbitrairement par le nombre total de joueurs pour obtenir une prévision. Regroupez les sessions observées par nombre de tours ou par une autre tranche de longueur pertinente, calculez le coût moyen au sein de chaque tranche, puis pondérez chaque tranche par sa part dans le total des sessions. Conservez la médiane et les percentiles supérieurs aux côtés de la moyenne : la moyenne permet d'estimer l'utilisation totale lorsqu'elle est multipliée par le volume de sessions, tandis que les percentiles aident à décrire le coût d'une session plus courte ou exceptionnellement longue.

Par exemple, si un échantillon contient de nombreuses sessions courtes et un petit nombre de sessions très longues, rapportez à la fois la part des sessions dans chaque tranche et le coût de chaque tranche. Une prévision pour 10 000 sessions peut alors être calculée comme la somme de (sessions dans la tranche × coût moyen dans la tranche), plutôt que de supposer que chaque session ressemble à la médiane globale. Si l'utilisation diffère considérablement selon le mode de jeu, la langue, la plateforme ou le statut du joueur (nouveau ou récurrent), stratifiez ces groupes avant de les combiner. Le choix de segmenter est une décision d'analyse ; expliquez en quoi chaque segment pourrait modifier l'utilisation des tokens ou le comportement des requêtes.

6. Documenter l'incertitude et actualiser l'estimation

Conservez un registre concis des hypothèses comprenant les dates de l'échantillon, la règle de délimitation des sessions, les modèles et les points de terminaison, la version du prompt, le nombre de sessions observées, la définition du succès de cache (cache hit), la date de consultation de la page des tarifs, les frais inclus et les composants exclus. Présentez un scénario bas, moyen et haut en faisant varier des variables observables — par exemple, la répartition de la durée des sessions, la taille des sorties ou la part mesurée de succès de cache — plutôt qu'en appliquant une marge de sécurité inexpliquée. Traitez tout comportement projeté au-delà des sessions observées comme un scénario explicite, et non comme un fait mesuré.

L'estimation n'est complète qu'à la hauteur de ses outils de mesure et de ses catégories facturables. Elle peut omettre des appels acheminés en dehors du système de journalisation, des nouvelles tentatives, des catégories de tokens en cache non exposées par l'API, des tokens de raisonnement côté modèle, la durée de stockage, le traitement multimédia ou des frais de fournisseur dépassant les simples tarifs des tokens. Rapprochez l'utilisation échantillonnée des rapports de facturation du fournisseur lorsqu'ils sont disponibles, analysez les écarts significatifs et réexécutez le calcul après toute modification des modèles, des prompts, du comportement de mise en cache ou des fonctionnalités visibles par les joueurs. Le résultat est une estimation documentée des coûts d'exploitation pour la charge de travail observée, et non une promesse que les sessions ou factures futures y correspondront fidèlement.

Continuer sur ce thème