Hay una conversación que tengo repetidamente con equipos de producto en España. Empieza más o menos así: "Hemos hecho una prueba de concepto con GPT-4 y funciona genial. Ahora queremos llevarlo a producción". Y cuando pregunto cuánto han presupuestado para los costes de API, la respuesta suele ser un silencio incómodo seguido de una cifra que está entre tres y diez veces por debajo de lo que acabará costando.
No es que los equipos sean descuidados. Es que los costes de los modelos de lenguaje en producción real tienen una estructura que no es obvia hasta que la has vivido. Y los artículos que explican "cómo usar la API de OpenAI" raramente entran en este territorio.
El problema de los tokens que nadie cuenta
Cuando haces una prueba de concepto, sueles enviar prompts cortos y bien diseñados. En producción, los prompts se vuelven más largos porque incluyen contexto del usuario, historial de conversación, instrucciones del sistema, ejemplos de few-shot learning... La longitud media de un prompt en producción puede ser fácilmente cinco o diez veces mayor que en el prototipo.
Además, en producción aparecen los usuarios que escriben mucho. El 20% de los usuarios que más interactúan suele generar el 60-70% del consumo de tokens. Si no has modelado esta distribución, tu estimación de costes puede estar muy lejos de la realidad.
"Calculamos el coste por usuario basándonos en nuestras pruebas internas. Cuando lanzamos, descubrimos que los usuarios reales escribían el doble que nosotros en las pruebas. El presupuesto se agotó en tres semanas."
— CTO de una startup de atención al cliente en Madrid
Los costes que no aparecen en la calculadora de precios
El precio por token es solo el principio. Hay otros costes que aparecen en producción y que raramente se mencionan en las guías de inicio rápido:
Latencia y reintentos
Las APIs de LLM tienen tiempos de respuesta variables. En producción, necesitas implementar lógica de reintentos para manejar errores y timeouts. Cada reintento tiene coste. Y si tu aplicación tiene requisitos de latencia estrictos, puede que necesites usar modelos más caros o arquitecturas más complejas.
Caché y deduplicación
Muchas consultas en producción son similares o idénticas. Implementar una capa de caché puede reducir los costes de API entre un 20% y un 40%, pero requiere tiempo de ingeniería y una infraestructura adicional que también tiene coste.
Evaluación y monitorización
En producción necesitas saber si el modelo está respondiendo bien. Eso significa implementar sistemas de evaluación automática, que a su vez consumen tokens. Y necesitas revisar manualmente una muestra de respuestas, lo que tiene coste de tiempo humano.
| Componente de coste | Estimación prototipo | Realidad producción |
|---|---|---|
| Tokens de entrada (API) | Base 100% | 300-500% del prototipo |
| Tokens de salida (API) | Base 100% | 150-250% del prototipo |
| Reintentos y errores | No considerado | +5-15% del total |
| Evaluación automática | No considerado | +10-20% del total |
| Infraestructura de caché | No considerado | Coste fijo mensual |
Cuándo tiene sentido usar modelos propios
A partir de cierto volumen, la ecuación cambia. Si estás gastando más de 10.000 euros al mes en APIs de LLM, probablemente vale la pena evaluar si tiene sentido entrenar o afinar un modelo propio, o usar modelos open-source desplegados en tu propia infraestructura.
Pero esta transición tiene sus propios costes ocultos: ingenieros especializados, tiempo de entrenamiento, infraestructura de GPU, mantenimiento... No es una solución mágica. Es un intercambio de un tipo de coste por otro.
La regla general que uso: si el caso de uso es suficientemente específico y el volumen es suficientemente alto, los modelos propios pueden ser más baratos a largo plazo. Si el caso de uso es general o el volumen es bajo o variable, las APIs de terceros suelen ser más eficientes.
Cómo estimar mejor antes de lanzar
Algunas cosas que recomiendo hacer antes de comprometer un presupuesto de producción: medir la longitud real de los prompts en un piloto con usuarios reales, no con el equipo interno; modelar la distribución de uso (no el usuario medio, sino los percentiles 90 y 99); incluir un factor de seguridad del 3x sobre la estimación inicial; y planificar desde el principio la arquitectura de caché.
Nada de esto es complicado. Pero requiere hacerlo antes de lanzar, no después de que la factura llegue.