El modelo de IA más barato casi nunca es el más barato

Hay una cifra que todo el mundo mira al elegir un modelo y que casi no explica nada: el precio por millón de tokens. Es la única que viene impresa, así que es la que acaba decidiendo. Y es un proxy malo.

Lo aprendí por la vía cara. Montamos un pipeline de generación con el modelo pequeño porque salía unas diez veces más barato por llamada. A las pocas semanas la factura de API era efectivamente ridícula y el proyecto era más caro que antes. La diferencia no estaba en el gasto de inferencia: estaba repartida en sitios que nadie había puesto en la hoja de cálculo.

Los cuatro términos que no están en la página de precios

Reintentos. JSON mal formado, salidas truncadas, restricciones del prompt ignoradas a la tercera instrucción. Cada reintento es una segunda llamada, un hueco más en la cola y un poco más de latencia acumulada. Si tu tasa de acierto al primer intento es del 70%, no estás pagando una generación por salida: estás pagando 1,4 o 1,5.

Latencia. Un modelo lento no es solo peor experiencia de usuario. Son timeouts que hay que gestionar, workers vivos más tiempo, más concurrencia para sostener el mismo throughput y, si lo tienes en un flujo síncrono, usuarios que abandonan. La latencia se convierte en infraestructura, y la infraestructura se factura.

Orquestación. Un modelo que falla mucho necesita andamiaje para ser utilizable: validadores de esquema, prompts de reparación, reglas de fallback, a veces un segundo modelo que revise al primero. Ese código lo escribe alguien una vez y lo mantiene para siempre. Es la parte que más se subestima porque no aparece como coste variable, aparece como "complejidad del sistema" y se paga en velocidad de equipo durante años.

QA e intervención humana. Los fallos que sobreviven al pipeline aterrizan en una persona. Y una persona revisando salidas es, con diferencia, el token más caro del sistema. Aquí es donde se evapora cualquier ahorro de inferencia, normalmente en un orden de magnitud.

La fórmula

coste real = generación + reintentos + orquestación + QA + intervención humana

Solo el primer término está en la página de precios. Los otros cuatro los descubres en producción.

Un ejemplo con números

Los números que siguen son un modelo ilustrativo, no una medición: sirven para enseñar la forma del cálculo, no para que copies las cifras. Pon las tuyas.

Supón 100.000 generaciones al mes de una ficha de producto que un usuario final va a leer.

Modelo A (barato): 0,002 € por generación. Acierto al primer intento del 72%. Con reintentos automáticos recuperas parte de los fallos, así que acabas gastando ~1,45 llamadas por salida válida.

• Inferencia: 100.000 × 1,45 × 0,002 = 290 €
• Fallos que llegan a revisión humana: 14% → 14.000 × 3 min ≈ 700 h × 25 €/h = 17.500 €
• Más una capa de validación y reparación que alguien tuvo que construir y mantiene.

Modelo B (caro): 0,012 € por generación, seis veces más. Acierto del 94%, ~1,08 llamadas por salida válida.

• Inferencia: 100.000 × 1,08 × 0,012 = 1.296 €
• Fallos a revisión: 6% → 6.000 × 3 min = 300 h × 25 €/h = 7.500 €
• Menos andamiaje, porque hay menos que reparar.

Total A: ~17.790 €. Total B: ~8.796 €.

La factura de API del modelo caro es 4,5 veces mayor. El coste total es la mitad. Y esto sin contar lo que no sé cuantificar bien: el tiempo de ingeniería que se va en mantener la capa de reparación, y lo que cuesta que la calidad media de tu producto sea peor.

Cuándo el modelo barato sí gana

No estoy defendiendo comprar siempre el modelo más grande. Eso es el mismo error con el signo cambiado.

Para clasificación, extracción de campos, routing, deduplicación, reescritura mecánica y cualquier tarea con una salida corta y verificable, los modelos pequeños ganan y no está ni cerca. La diferencia de calidad con un modelo de gama alta es de un par de puntos, y la de precio es de un orden de magnitud. Ahí el precio por generación sí es una buena aproximación al coste real, porque los otros cuatro términos son casi cero: hay un validador determinista, el fallo se detecta solo, y nadie tiene que leer la salida.

La regla que uso: si la salida es verificable por una máquina, optimiza precio. Si la verifica una persona, optimiza acierto al primer intento.

Un corolario incómodo de esto es que la arquitectura correcta casi nunca es un solo modelo. Es un modelo pequeño para el 80% del volumen y uno grande para el 20% que se ve, con un criterio explícito de enrutado. Lo que sale caro es usar el pequeño para todo y compensar con código.

Cómo medirlo de verdad

Deja de mirar coste por generación y mide coste por salida aceptada. Es la única métrica que incorpora los cinco términos:

1. Instrumenta la tasa de acierto al primer intento por tarea, no global. La media te miente: normalmente hay dos o tres tipos de input que concentran casi todos los fallos.
2. Cuenta reintentos como llamadas. Si tu dashboard de costes divide el gasto entre generaciones solicitadas y no entre llamadas realizadas, tienes el número mal.
3. Pon precio al minuto de revisión. Aunque sea aproximado. En cuanto ese término entra en la hoja de cálculo, las decisiones cambian solas.
4. Antes de comprar, prueba con 200 casos reales, no con cinco. Un modelo pequeño acierta los cinco ejemplos bonitos que se te ocurren; falla en la cola larga, que es donde vive tu producto.

Y antes de subir de modelo, agota las palancas que abaratan el término de generación sin tocar la calidad: caché de prompts para el contexto que se repite entre llamadas, procesamiento por lotes para lo que no es interactivo, y recortar el contexto que arrastras por inercia. En muchos pipelines eso ya cierra buena parte de la diferencia de precio entre gamas.

Lo que cambié

Ahora cuando alguien propone bajar de modelo para ahorrar, la pregunta no es cuánto cuesta la llamada. Es: ¿quién mira esta salida antes de que llegue al usuario? Si la respuesta es "una persona", el ahorro es contable, no real. Estás moviendo coste de una línea de la que eres responsable a otra de la que no lo eres, y encima con intereses.

El precio por generación no es el coste. Es el único sumando que alguien se molestó en publicar.