Cómo los desarrolladores de videojuegos pueden estimar el coste de los diálogos largos con IA

1. Defina la unidad que va a estimar

Elija primero una unidad clara: por ejemplo, el coste de inferencia del modelo por sesión de diálogo, por jugador activo diario o por cada 1.000 sesiones. Para estimar por sesión, defina cuándo comienza y termina dicha sesión. Una regla práctica podría ser «desde la primera solicitud de diálogo hasta que transcurran 30 minutos sin solicitudes», pero ese tiempo de espera (timeout) es una decisión de medición, no un estándar universal. Regístrelo para que otro desarrollador pueda reproducir la estimación.

Cuente las solicitudes al modelo, no solo los mensajes de los jugadores. Una única interacción puede desencadenar varias llamadas —por ejemplo, una respuesta seguida de una llamada independiente para gestionar herramientas—, y los reintentos pueden añadir más. Si el juego utiliza voz, entrada de imágenes, recuperación de información (retrieval) o herramientas, mantenga esos costes en campos independientes además de registrar sus tokens de modelo asociados. Los precios de los proveedores pueden incluir tarifas por uso de herramientas o precios específicos por modalidad además de los cargos habituales por tokens de texto; OpenAI, por ejemplo, desglosa cargos específicos para herramientas e indica que los tokens de modelo utilizados para herramientas integradas se facturan a las tarifas del modelo elegido (OpenAI API pricing).

2. Mida los tokens reales por solicitud

Para cada llamada, registre el proveedor, el identificador del modelo, la marca de tiempo, el identificador de sesión, el propósito de la solicitud, el recuento de tokens de entrada, el recuento de tokens de salida y cualquier desglose disponible de tokens en caché o de razonamiento. Registre reintentos, errores, llamadas a herramientas y si la llamada se completó. Evite almacenar el contenido del diálogo a menos que sea necesario para un propósito del producto justificado por separado; los totales de tokens y los metadatos operativos suelen ser suficientes para una estimación de costes.

Utilice como medición principal el uso reportado por el proveedor a partir de las llamadas completadas. El recuento previo (preflight) resulta útil para probar la construcción de prompts, pero puede no coincidir con los campos de facturación finales. OpenAI documenta que la salida reportada incluye tokens más allá del texto visible, como ciertos tokens de formato y de estructura de herramientas, y recomienda no estimar la salida basándose únicamente en lo que ve el jugador (OpenAI token-counting guide). La documentación de Gemini de Google distingue de manera similar los recuentos de tokens de prompt, contenido en caché, salida candidata y razonamiento en sus metadatos de uso (Gemini token guide).

Cree una muestra representativa que incluya jugadores nuevos, jugadores recurrentes, conversaciones cortas y largas, así como la configuración de herramientas y prompts de producción. Mantenga las sesiones como unidad de muestreo: un diálogo de 40 turnos debe seguir siendo una única observación con su coste acumulado, en lugar de tratarse como 40 sesiones de jugador independientes. Durante la fase de prototipo, un conjunto fijo de conversaciones con guion ayuda a comparar cambios en los prompts; tras el lanzamiento, las sesiones observadas deben orientar la previsión.

3. Tenga en cuenta el crecimiento del historial y la reutilización del contexto

En muchos sistemas de diálogo, cada solicitud incluye el turno actual del usuario más parte o la totalidad del historial de la conversación. Si el historial se reenvía repetidamente, los tokens de entrada pueden aumentar con cada turno, incluso cuando los mensajes de los jugadores sean breves. Mida la carga útil (payload) real enviada al modelo; no multiplique el tamaño del prompt de un solo turno por el número de turnos a menos que la implementación envíe exactamente la misma cantidad cada vez.

El almacenamiento en caché modifica la tarifa que se aplica a la entrada repetida apta; no significa que todo el diálogo pase a ser gratuito ni que una sesión persistente garantice un acierto de caché (cache hit). OpenAI describe el almacenamiento en caché de prompts como la reutilización de un prefijo de prompt sin cambios y señala que las nuevas entradas aún deben procesarse. Sus diagnósticos de caché pueden ayudar a medir las lecturas y los fallos de caché (OpenAI prompt-caching guide). Anthropic distingue de forma similar entre escrituras y lecturas en caché, y publica tarifas y duraciones de caché independientes (Anthropic pricing and prompt caching).

En su telemetría, separe los tokens de entrada no almacenados en caché, los tokens de entrada en caché y los tokens de escritura en caché cuando el proveedor los desglose. Registre los aciertos de caché divididos entre las solicitudes aptas, así como la proporción de tokens de entrada facturados efectivamente como almacenados en caché. Estas métricas responden a cuestiones distintas: una tasa alta de aciertos en todas las solicitudes puede seguir implicando una proporción modesta de tokens totales almacenados en caché si el prefijo repetido es pequeño. Los requisitos para la caché, los tamaños mínimos, la caducidad, la estabilidad del prefijo del prompt y la compatibilidad del modelo dependen de cada proveedor; contabilice únicamente los ahorros confirmados por los datos de uso.

4. Aplique tarifas con un cálculo transparente

Para un modelo con precios por millón de tokens, calcule cada sesión de la siguiente forma:

coste de sesión = (entrada no en caché × tarifa de entrada + entrada en caché × tarifa de entrada en caché + escrituras en caché × tarifa de escritura en caché + salida × tarifa de salida) ÷ 1.000.000 + otros cargos aplicables

Utilice las tarifas correspondientes al modelo, endpoint, modalidad, región y nivel de servicio exactos de la configuración desplegada. Compruébelas de forma independiente en la página de precios del proveedor justo antes de elaborar un presupuesto; las tarifas y los catálogos de modelos cambian. Incluya los costes de almacenamiento cuando la caché facture por tokens almacenados y duración. Por ejemplo, los precios publicados de Gemini detallan categorías de tokens para uso de pago y precios por hora de almacenamiento para ciertas configuraciones de context caching, mientras que su documentación de facturación identifica la entrada, la salida, los tokens en caché y la duración del almacenamiento en caché como factores facturables (Gemini pricing; Gemini billing).

Un cálculo detallado ayuda a visibilizar los supuestos. Supongamos, a modo de ilustración, que las llamadas medidas asignadas a una sesión contienen 18.000 tokens de entrada no en caché, 12.000 tokens de entrada en caché y 6.000 tokens de salida. Aplicando las tarifas del nivel de pago de Gemini 3.8 Flash publicadas para su uso hasta el 31 de diciembre de 2026 —0,75 $ por millón de tokens de entrada, 0,075 $ por millón de tokens en caché y 3,75 $ por millón de tokens de salida— se obtiene: 0,0135 $ + 0,0009 $ + 0,0225 $, es decir, 0,0369 $ antes de cualquier almacenamiento en caché u otros cargos aplicables. Este ejemplo asume que los tokens en caché indicados se facturan a la tarifa de caché y no incluye ningún coste de creación inicial de caché fuera de los totales medidos. Las tarifas tienen un límite temporal y deben revisarse de nuevo al realizar estimaciones para un periodo posterior (Gemini pricing).

5. Utilice la distribución de la duración de las sesiones

No multiplique una única sesión «típica» elegida a dedo por el número total de jugadores para considerarlo una previsión. Agrupe las sesiones observadas por recuento de turnos u otro rango de duración útil, calcule el coste medio dentro de cada rango y luego pondere cada rango según su proporción del total de sesiones. Mantenga la mediana y los percentiles superiores junto a la media: la media estima el uso total al multiplicarse por el volumen de sesiones, mientras que los percentiles ayudan a describir lo que puede costar una sesión más corta o inusualmente larga.

Por ejemplo, si una muestra cuenta con muchas sesiones cortas y un número reducido de sesiones muy largas, informe tanto de la proporción de sesiones en cada rango como del coste de cada uno. La previsión para 10.000 sesiones podrá calcularse entonces como la suma de las sesiones del rango × coste medio del rango, en lugar de asumir que todas las sesiones se asemejan a la mediana general. Si el uso varía de forma considerable según el modo de juego, el idioma, la plataforma o entre jugadores nuevos y recurrentes, estratifique esos grupos antes de combinarlos. La decisión de segmentar es una elección analítica; explique los motivos por los que cada segmento podría alterar el uso de tokens o el comportamiento de las solicitudes.

6. Documente la incertidumbre y actualice la estimación

Mantenga un registro conciso de supuestos con las fechas de la muestra, la regla de delimitación de las sesiones, los modelos y endpoints, la versión del prompt, los recuentos de sesiones observados, la definición de acierto de caché, la fecha de consulta de la página de precios, las tarifas incluidas y los componentes excluidos. Plantee escenarios bajo, medio y alto modificando variables observables —por ejemplo, la distribución de la duración de las sesiones, el tamaño de la salida o la tasa medida de aciertos de caché— en lugar de aplicar un margen de seguridad sin justificar. Considere cualquier proyección de comportamiento que vaya más allá de las sesiones observadas como un escenario explícito, no como un hecho medido.

La estimación será tan completa como lo sean su instrumentación y sus categorías facturables. Puede pasar por alto llamadas enrutadas fuera del sistema de registro, reintentos, categorías de tokens en caché que la API no expone, tokens de razonamiento internos del modelo, duración del almacenamiento, procesamiento multimedia o cargos del proveedor ajenos a las tarifas por token. Concilie el uso muestreado con los informes de facturación del proveedor cuando estén disponibles, investigue discrepancias significativas y repita el cálculo tras modificar modelos, prompts, comportamientos de caché o funciones orientadas al jugador. El resultado es una estimación documentada de costes operativos para la carga de trabajo observada, no una garantía de que las futuras sesiones o facturas coincidirán con ella.

Sigue explorando este tema