Cómo se calcula realmente el precio de los modelos de IA: tokens, caché y lotes

El precio de la IA parece sencillo —una cifra por millón de tokens— hasta que llega la primera factura y nadie sabe explicarla. El modelo de precios no es complicado, pero tiene una forma que castiga la manera obvia de construir las cosas.

La unidad básica

Todos los grandes proveedores facturan por millón de tokens, con dos tarifas distintas:

• Tokens de entrada: todo lo que envías —prompt de sistema, definiciones de herramientas, historial de la conversación, documentos adjuntos.
• Tokens de salida: todo lo que el modelo genera.

La salida es la cara, habitualmente entre tres y cinco veces la tarifa de entrada. La razón es mecánica: la entrada se procesa en paralelo a lo largo de la secuencia, mientras que la salida se produce token a token, cada uno exigiendo una pasada completa por el modelo.

Primera consecuencia práctica: una respuesta prolija cuesta más que una pregunta larga. «Resume en tres puntos» es control de costes, no solo una preferencia de estilo.

Dónde se va el dinero

El historial de conversación. Esta es la que sorprende. La mayoría de las API de chat no tienen estado: para continuar una conversación hay que reenviarla. El turno 1 envía 500 tokens. El turno 10 envía todo lo de los turnos 1 a 9 más el mensaje nuevo. A lo largo de un hilo largo, la entrada acumulada crece aproximadamente con el cuadrado del número de turnos.

Sobrecarga fija por petición. Un prompt de sistema de 2.000 tokens y 3.000 de esquemas de herramientas cuestan 5.000 tokens de entrada en cada llamada, incluidas aquellas en las que el usuario escribió «gracias».

Tokens de razonamiento. Los modelos que piensan antes de responder emiten tokens internos que se facturan como salida. Una petición que devuelve tres líneas puede haber generado muchas más.

Reintentos y bucles de agente. Un agente que da quince pasos son quince peticiones facturables, cada una cargando todo el contexto acumulado. La lógica de reintentos multiplica esto en silencio.

Las cuatro palancas, por orden de efecto

1. Enruta a un modelo más pequeño. La diferencia de precio entre un modelo frontera y uno pequeño suele ser de 10 a 30 veces. La mayoría de las cargas de producción contienen una gran proporción de peticiones fáciles —clasificar, extraer, dar formato— que un modelo pequeño resuelve con la misma calidad. Mándalas ahí y escala solo por dificultad o baja confianza. Nada más en esta lista se acerca a ese ahorro.

2. Cachea el prefijo estable. La caché de prompt cobra una fracción de la tarifa de entrada por un prefijo que el proveedor ya ha visto. Exige prefijos idénticos byte a byte, lo que impone una disciplina:

[prompt de sistema]        ← estable, cachea esto
[definiciones de herramientas] ← estable
[documentos de referencia] ← estable por sesión
[historial de conversación] ← cambia
[mensaje actual]           ← cambia

Poner una marca de tiempo o el nombre del usuario al principio del prompt anula la caché por completo. Es un error frecuente y caro.

3. Procesa por lotes lo que no sea interactivo. Los endpoints por lotes cambian latencia por aproximadamente la mitad de precio. Clasificación nocturna, relleno de embeddings, suites de evaluación, traducción masiva: nada de eso necesita respuesta síncrona.

4. Acorta el bucle. Limita el historial a los últimos N turnos más un resumen. Recorta las definiciones de herramientas a las que esta tarea necesita. Fija límites explícitos de longitud de salida. Por separado son pequeños; juntos suelen ser un tercio de la factura.

Costes que no son tokens

• Los embeddings son baratos por llamada y fáciles de disparar al reindexar. Volver a embeber un corpus entero tras cambiar la estrategia de chunking es una partida real.
• El ajuste fino tiene un coste de entrenamiento y, en algunos casos, una tarifa de inferencia mayor o un cargo por alojar el modelo personalizado.
• La entrada de imagen y audio se convierte en equivalentes de tokens con fórmulas que varían por proveedor y resolución: consulta la fórmula concreta en lugar de suponer.
• Los niveles de límite de tasa. A veces más rendimiento exige gasto comprometido. Es una cuestión de compras, no de ingeniería, y conviene preguntarla pronto.

Una previsión que se sostenga

Primero instrumenta. Registra por petición: modelo, tokens de entrada, de salida, cacheados, funcionalidad y usuario. Sin ese desglose, optimizar costes es adivinar.

Después la aritmética es directa:

coste mensual ≈ peticiones/mes
              × (tokens_entrada × tarifa_entrada
               + tokens_cache × tarifa_cache
               + tokens_salida × tarifa_salida)

Modela tres escenarios —esperado, el doble y diez veces— y comprueba cuál rompe tu economía unitaria. Un producto con precio por puesto y una función de chat sin límites puede invertir su propio margen, y el momento de descubrirlo es antes del lanzamiento.

La verdad incómoda de casi cualquier revisión es que el mayor ahorro no es un prompt ingenioso. Es darse cuenta de que el 70% del tráfico nunca necesitó el modelo caro.