Como desenvolvedores de jogos podem estimar o custo de diálogos longos com IA

1. Defina a unidade que você está estimando

Primeiro, escolha uma unidade clara: por exemplo, custo de inferência do modelo por sessão de diálogo, por jogador ativo por dia ou por 1.000 sessões. Para uma estimativa por sessão, defina quando ela começa e termina. Uma regra prática pode ser "do primeiro comando de diálogo até 30 minutos sem nenhuma requisição", mas esse tempo limite (timeout) é uma escolha métrica, não um padrão universal. Documente-o para que outro desenvolvedor possa reproduzir a estimativa.

Conte as requisições ao modelo, não apenas as mensagens do jogador. Uma única interação pode acionar várias chamadas — por exemplo, uma resposta seguida por uma chamada separada para uso de ferramenta — e novas tentativas (retries) podem adicionar ainda mais. Se o jogo utiliza voz, entrada de imagem, recuperação de dados (retrieval) ou ferramentas, mantenha esses itens em campos de custo separados, além de registrar os tokens associados no modelo. Os preços dos provedores podem incluir taxas para ferramentas ou tarifas específicas por modalidade, além dos custos normais de tokens de texto; a OpenAI, por exemplo, lista cobranças separadas para ferramentas e informa que os tokens do modelo usados para ferramentas integradas são faturados de acordo com as taxas do modelo escolhido (OpenAI API pricing).

2. Meça os tokens reais por requisição

Para cada chamada, registre o provedor, o identificador do modelo, o carimbo de data/hora (timestamp), o identificador da sessão, a finalidade da requisição, a contagem de tokens de entrada, a contagem de tokens de saída e qualquer detalhamento reportado de tokens em cache ou de raciocínio. Capture novas tentativas, erros, chamadas de ferramentas e se a chamada foi concluída com sucesso. Evite armazenar o conteúdo do diálogo, a menos que seja necessário para uma finalidade de produto justificável separadamente; os totais de tokens e os metadados operacionais geralmente são suficientes para uma estimativa de custos.

Use o consumo informado pelo provedor nas chamadas concluídas como a métrica principal. A contagem prévia (preflight) é útil para testar a construção de prompts, mas pode não coincidir com os campos finais de faturamento. A OpenAI documenta que a saída reportada inclui tokens além do texto visível, como formatações e tokens estruturais de ferramentas, recomendando não estimar a saída apenas com base no que o jogador vê (OpenAI token-counting guide). A documentação do Gemini do Google também distingue, nos metadados de uso, as contagens de tokens para prompt, conteúdo em cache, saída candidata e pensamento (Gemini token guide).

Crie uma amostra representativa que inclua novos jogadores, jogadores recorrentes, conversas curtas e longas, bem como o prompt de produção e a configuração de ferramentas. Mantenha as sessões como a unidade de amostragem: um diálogo de 40 turnos deve permanecer como uma única observação com seu custo acumulado, em vez de ser tratado como 40 sessões independentes de jogadores. Durante a fase de protótipo, um conjunto fixo de conversas roteirizadas ajuda a comparar alterações nos prompts; após o lançamento, as sessões reais observadas devem guiar a projeção.

3. Considere o crescimento do histórico e a reutilização de contexto

Em muitos sistemas de diálogo, cada requisição inclui o turno atual do usuário mais uma parte ou a totalidade do histórico da conversa. Se o histórico for reenviado repetidamente, os tokens de entrada podem crescer a cada turno, mesmo que as mensagens do jogador sejam breves. Meça o volume real de dados (payload) enviado ao modelo; não multiplique o tamanho do prompt de um turno pela quantidade de turnos, a menos que a implementação realmente envie a mesma quantidade a cada vez.

O cache altera a tarifa aplicada às entradas repetidas elegíveis; isso não significa que o diálogo inteiro se torne gratuito ou que uma sessão persistente garanta acerto de cache (cache hit). A OpenAI descreve o cache de prompt como a reutilização de um prefixo de prompt inalterado e ressalta que as novas entradas ainda precisam ser processadas. Seus diagnósticos de cache podem ajudar a medir leituras e falhas de cache (OpenAI prompt-caching guide). A Anthropic distingue de forma semelhante as gravações de cache das leituras de cache e publica tarifas separadas e durações de cache (Anthropic pricing and prompt caching).

Na sua telemetria, separe os tokens de entrada não armazenados em cache, os tokens de entrada em cache e os tokens de gravação de cache quando o provedor os informar. Registre os acertos de cache divididos pelas requisições elegíveis e a proporção de tokens de entrada faturados de fato como em cache. Essas métricas respondem a perguntas diferentes: uma alta taxa de acertos entre requisições ainda pode significar uma fração modesta do total de tokens em cache se o prefixo repetido for pequeno. Elegibilidade ao cache, tamanhos mínimos, expiração, estabilidade do prefixo do prompt e suporte do modelo são específicos de cada provedor; considere apenas as economias confirmadas pelos dados de uso.

4. Aplique as tarifas com um cálculo transparente

Para um modelo precificado por milhão de tokens, calcule cada sessão como:

custo da sessão = (entrada sem cache × tarifa de entrada + entrada em cache × tarifa de entrada em cache + gravações de cache × tarifa de gravação de cache + saída × tarifa de saída) ÷ 1.000.000 + outras taxas aplicáveis

Utilize as tarifas exatas para o modelo, endpoint, modalidade, região e nível de serviço da configuração implantada. Verifique-as de forma independente na página de preços do provedor imediatamente antes de elaborar um orçamento; tarifas e catálogos de modelos mudam. Inclua cobranças de armazenamento onde o cache fatura por tokens armazenados e duração. Por exemplo, a tabela de preços do Gemini lista categorias de tokens para uso pago e preços de armazenamento por hora para determinadas configurações de cache de contexto, enquanto sua documentação de faturamento identifica entrada, saída, tokens em cache e duração do armazenamento em cache como fatores cobráveis (Gemini pricing; Gemini billing).

Um cálculo demonstrativo torna as premissas visíveis. Suponha, puramente para ilustração, que as chamadas medidas atribuídas a uma sessão contenham 18.000 tokens de entrada sem cache, 12.000 tokens de entrada em cache e 6.000 tokens de saída. Aplicando as tarifas do plano pago do Gemini 3.8 Flash publicadas para uso até 31 de dezembro de 2026 — US$ 0,75 por milhão de tokens de entrada, US$ 0,075 por milhão de tokens em cache e US$ 3,75 por milhão de tokens de saída — temos US$ 0,0135 + US$ 0,0009 + US$ 0,0225, ou US$ 0,0369 antes de qualquer armazenamento em cache aplicável ou outras cobranças. Este exemplo pressupõe que os tokens em cache listados sejam faturados na tarifa com cache e não inclui nenhum custo inicial de criação de cache fora dos totais medidos. As tarifas têm prazo de validade e devem ser checadas novamente ao fazer estimativas para um período posterior (Gemini pricing).

5. Use a distribuição da duração das sessões

Não multiplique uma sessão "típica" escolhida arbitrariamente pelo total de jogadores esperando obter uma projeção. Agrupe as sessões observadas por quantidade de turnos ou outra faixa de extensão conveniente, calcule o custo médio dentro de cada faixa e, em seguida, pondere cada faixa por sua fatia no total de sessões. Mantenha a mediana e os percentis superiores ao lado da média: a média estima o uso total quando multiplicada pelo volume de sessões, enquanto os percentis ajudam a ilustrar quanto uma sessão mais curta ou atipicamente longa pode custar.

Por exemplo, se uma amostra tiver muitas sessões curtas e um número pequeno de sessões muito longas, informe tanto a proporção de sessões em cada faixa quanto o custo de cada uma delas. Uma projeção para 10.000 sessões pode então ser calculada como a soma de (sessões na faixa × custo médio na faixa), em vez de presumir que todas as sessões se parecem com a mediana geral. Se o uso variar significativamente por modo de jogo, idioma, plataforma ou entre jogadores novos e recorrentes, estratifique esses grupos antes de combiná-los. A decisão de segmentar faz parte da análise; explique por que cada segmento poderia alterar o consumo de tokens ou o comportamento das requisições.

6. Documente as incertezas e atualize a estimativa

Mantenha um registro conciso de premissas com as datas da amostragem, a regra de delimitação da sessão, modelos e endpoints, versão do prompt, contagem de sessões observadas, definição de acertos de cache (cache hits), data de consulta à página de preços, taxas inclusas e componentes excluídos. Apresente cenários com valores baixos, centrais e altos alterando variáveis observáveis — por exemplo, a proporção de duração das sessões, o tamanho da saída ou a parcela medida de acertos de cache — em vez de aplicar uma margem de segurança arbitrária. Trate qualquer comportamento projetado que vá além das sessões observadas como um cenário explícito, não como um fato comprovado.

A estimativa é tão completa quanto forem a sua instrumentação e as categorias faturáveis consideradas. Ela pode deixar de fora chamadas roteadas fora do logger, novas tentativas, categorias de tokens em cache que a API não expõe, tokens de raciocínio internos do modelo, tempo de armazenamento, processamento de mídia ou tarifas do provedor que vão além do valor dos tokens. Compare o consumo da amostragem com os relatórios de faturamento do provedor sempre que disponíveis, investigue discrepâncias relevantes e recalcule os valores após alterar modelos, prompts, comportamento de cache ou recursos voltados aos jogadores. O resultado é uma estimativa documentada de custos operacionais para a carga de trabalho observada, e não uma promessa de que as faturas ou sessões futuras serão idênticas.

Continue explorando o tema