La mayoría de los presupuestos de IA que revisamos se construyen con la calculadora de precios del proveedor: tokens estimados por consulta, consultas mensuales previstas, multiplicación. El número que sale de ahí suele ser tranquilizador, y suele ser también el motivo por el que el caso de uso se aprueba sin discusión. Doce meses después, la conversación con el comité de inversiones es distinta, porque el gasto real rara vez se parece a esa estimación inicial.
No se debe a que el proveedor haya subido precios. Ocurre justo lo contrario. El problema está en que la partida de inferencia es la única que se presupuesta, y en un caso de uso en producción no llega a ser la mayoritaria.
El precio baja, el consumo sube
La caída del coste de inferencia es real y está bien documentada en los precios de lista publicados. El modelo tope de gama disponible a comienzos de 2023 se facturaba en el orden de decenas de dólares por millón de tokens de entrada. Los modelos pequeños actuales, perfectamente capaces para tareas acotadas de clasificación, extracción o reescritura, se mueven dos órdenes de magnitud por debajo. Una organización que hubiera congelado su arquitectura en 2023 y solo hubiera ido migrando al modelo equivalente más barato habría visto su factura desplomarse.
Casi nadie ha hecho eso. Lo que ha pasado en paralelo es que los modelos de razonamiento generan tokens intermedios antes de responder, y esos tokens se facturan como salida aunque el usuario no los llegue a ver. Una consulta que antes consumía unos cientos de tokens de respuesta puede consumir varios miles cuando el modelo razona. A eso se suma el crecimiento de las ventanas de contexto: si el sistema recupera documentos y los inyecta en cada llamada, el coste de entrada por interacción se multiplica respecto al de una pregunta suelta.
La métrica útil, por tanto, no es el precio por millón de tokens sino el coste por tarea correctamente resuelta. Un modelo tres veces más caro por token que necesita la mitad de intentos y no requiere revisión humana sale más barato en la práctica.
Las partidas que nadie presupuesta
En los proyectos que hemos acompañado, el desglose real del coste total de propiedad incluye siempre estos bloques, y en ninguno de ellos aparece un token:
- Ingesta y preparación de datos. Conectar los sistemas de origen, normalizar formatos, resolver duplicados, decidir qué se indexa y con qué permisos. Es trabajo de ingeniería de datos convencional y suele ser la partida más grande del primer año.
- Evaluación continua. Un conjunto de casos de prueba con respuesta esperada, ejecutado cada vez que cambia el modelo, el prompt o el índice. Sin esto, cualquier actualización del proveedor es una lotería. Construirlo cuesta semanas de trabajo con personas del negocio, no solo técnicas, y mantenerlo es una tarea recurrente.
- Observabilidad. Trazas por interacción, coste imputado, latencias, tasas de error, detección de deriva. La instrumentación mínima para poder responder a la pregunta «por qué esta respuesta fue mala» exige almacenamiento y herramienta.
- Revisión humana. En casos de uso con impacto regulatorio, contractual o económico, alguien valida antes de que la salida llegue al cliente. Si un analista dedica dos minutos a revisar cada respuesta, el coste de esos dos minutos supera con holgura el de la llamada al modelo.
- Reintentos y fallos. Salidas que no cumplen el esquema esperado, límites de tasa, cortes del proveedor, llamadas duplicadas por lógica de agente. Cada reintento se factura.
Una plantilla de cálculo por interacción
Recomendamos a nuestros clientes construir la estimación de abajo arriba, sobre una única interacción, y solo después multiplicar por el volumen previsto. El esqueleto es este:
Coste por interacción = tokens de entrada efectivos × precio de entrada + (tokens de respuesta + tokens de razonamiento) × precio de salida, todo ello multiplicado por (1 + tasa de reintentos), más el coste de recuperación, más los minutos de revisión humana por su coste horario, más la amortización mensual de evaluación y observabilidad dividida entre el volumen de interacciones.
Tres matices sobre los términos. Los tokens de entrada efectivos no son los tokens brutos: si el sistema reutiliza un prefijo estable, las lecturas desde caché se facturan a una fracción del precio de entrada, y diseñar los prompts para maximizar ese reaprovechamiento tiene un efecto directo en la factura. Los tokens de razonamiento hay que medirlos, no estimarlos, porque varían mucho según la dificultad de la consulta. Y la tasa de reintentos se obtiene de los registros de un piloto, no del optimismo del equipo.
Al hacer este ejercicio, lo habitual es descubrir que la revisión humana y la amortización de la evaluación dominan el resultado cuando el volumen es bajo, y que la inferencia solo empieza a pesar cuando el volumen es alto.
El umbral del modelo pequeño o abierto
De ese comportamiento se deduce la regla de decisión. Con volúmenes bajos y variables, un modelo grande de proveedor es la opción sensata: se paga por uso, no hay coste fijo y el equipo dedica su tiempo al caso de uso y no a la infraestructura. Cambiar a un modelo pequeño para ahorrar unos euros al mes mientras se añaden semanas de ajuste y evaluación es una mala operación.
La ecuación se invierte cuando concurren tres condiciones: volumen alto y sostenido, tarea acotada y repetitiva, y un conjunto de evaluación ya construido que permita verificar que el modelo pequeño mantiene la calidad. Ahí, destilar la tarea a un modelo menor —del propio proveedor o abierto— cambia el orden de magnitud del gasto variable.
El autoalojamiento de un modelo abierto es un caso aparte y con un umbral más alto. Introduce un coste fijo que se paga aunque no haya tráfico, porque la infraestructura de aceleración se alquila por tiempo y no por petición, y añade responsabilidades de actualización, seguridad y disponibilidad que antes asumía el proveedor. Solo compensa con una utilización elevada y estable, o cuando existe una restricción de soberanía del dato que lo convierte en un requisito y no en una decisión económica.
Antes de aprobar el siguiente caso de uso, sugerimos exigir al equipo proponente el desglose completo por interacción, con la tasa de reintentos medida en el piloto y el coste de revisión humana explicitado. La cifra resultante será varias veces mayor que la de la calculadora del proveedor, y esa es exactamente la que permite comparar el proyecto con cualquier otra inversión que compita por el mismo presupuesto.