Definición
Los modelos de lenguaje se facturan por tokens, no por peticiones ni por tiempo. Un token es aproximadamente 4 caracteres en inglés y algo menos en español, donde las palabras se parten más. Como referencia práctica: unas 750 palabras por cada 1.000 tokens.
Lo que sorprende a casi todo el mundo la primera vez es que entrada y salida no cuestan igual. La salida suele costar entre tres y cinco veces más que la entrada, porque generar es secuencial —token a token— mientras que leer la entrada se procesa en paralelo.
Esa asimetría cambia por completo cómo se optimiza. La intuición de "escribo un prompt más corto y ahorro" suele ser la palanca menos rentable.
Cómo se calcula
Para cada llamada:
coste = (tokens de entrada × precio entrada) + (tokens de salida × precio salida)
Los tokens de entrada son todo lo que le mandas: el system prompt, el historial de la conversación entero, los fragmentos recuperados por RAG y la pregunta.
Aquí está la trampa que se lleva por delante a mucha gente: en un chat, el historial se reenvía completo en cada turno. La conversación número veinte no cuesta como la primera: cuesta como la primera más las diecinueve anteriores. El coste de una conversación larga crece de forma cuadrática, no lineal.
Ejemplo práctico
El asistente de la web de aeworks.tech es un endpoint público, y eso obliga a hacer las cuentas antes de encenderlo.
Por mensaje: el system prompt son unos 600 tokens, el historial va creciendo, y la respuesta ronda los 150. En una conversación de 14 mensajes —el tope que le pusimos— salen del orden de 25.000 tokens de entrada acumulados y 2.000 de salida.
Con eso ya se puede decidir. Y lo que decidimos fue poner topes por todos lados: 500 caracteres por mensaje, 14 mensajes por conversación, 25 por IP y hora, 60 por IP y día.
No son límites de calidad, son límites de factura. Sin ellos, un endpoint público con un modelo detrás es una tarjeta de crédito con la web de acceso. Un solo script dándole toda la noche te puede dejar una factura seria, y no hay ninguna barrera natural que lo impida.
El segundo caso, el clasificador de gastos del CRM, se decidió igual pero al revés: probamos tres modelos con el mismo eval. El caro sacó 91 %, el mediano 89 %. Dos puntos por seis veces el precio, multiplicado por miles de movimientos al mes. Se quedó el mediano.
Palancas para bajarlo, por rentabilidad
-
Caché de prompts. Si repites el mismo bloque de entrada en muchas llamadas —el system prompt, un manual, unos ejemplos—, se puede marcar para que el proveedor lo cachee. La parte cacheada cuesta una fracción. Es, con diferencia, el mayor ahorro disponible hoy en cualquier asistente con instrucciones largas.
-
Elegir el modelo por tarea. No todo necesita el modelo grande. Clasificar, extraer datos o enrutar lo hace bien uno pequeño. Reserva el caro para lo que de verdad lo pida.
-
Podar el historial. No mandes veinte turnos completos: manda los últimos cuatro y un resumen de lo anterior.
-
Recuperar menos y mejor. En un RAG, pasar 20 fragmentos por si acaso es caro y además empeora la respuesta. Con reranking pasas 5 buenos en vez de 20 regulares.
-
Limitar la salida. Fija un máximo de tokens de respuesta y pide brevedad en las instrucciones. Como la salida es lo caro, aquí cada token cuenta el triple.
-
Cachear respuestas repetidas. Si cien usuarios preguntan lo mismo, no hace falta preguntárselo cien veces al modelo.
Errores comunes
- Estimar el coste con un ejemplo suelto. Multiplica por el volumen real y por el peor caso, no por el medio.
- Olvidar que el historial se reenvía. Es el error de cálculo más frecuente y el que más se dispara.
- Optimizar el system prompt en vez de la salida. Recortar 100 tokens de entrada ahorra mucho menos que recortar 100 de salida.
- No poner tope de gasto. Todos los proveedores permiten fijar un límite mensual. Ponlo el primer día.
- Contar tokens "a ojo" en español. Nuestro idioma se tokeniza peor que el inglés: el mismo texto gasta más. Usa el contador del proveedor.
- No medir por función. Sin saber qué parte de tu producto se come la factura, optimizas a ciegas.
Cuándo mirarlo en serio
Antes de abrir nada al público, y antes de meter una llamada al modelo dentro de un proceso que se ejecuta muchas veces al día. Un asistente interno que usan cuatro personas no necesita optimización. Un endpoint abierto o un proceso automático sobre miles de registros, sí, y desde el primer día.
