El modelo más barato es el que tiene errores que usted puede permitirse detectar
Tres formas de recortar el coste de inferencia: especializar un modelo pequeño, servir mejor los pesos abiertos, terminar tareas de agentes en menos pasos. Ninguna pone precio a los errores.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.

“¿Qué modelo es el más barato para este flujo de trabajo?” no tiene respuesta hasta que alguien diga dónde caerán los errores del modelo.
Los últimos días han producido tres buenos ejemplos de cómo bajar lo que cuesta ejecutar IA. Microsoft entrenó un modelo abierto pequeño con 17 documentos y elevó su F1 de extracción de 0.44 a 0.81, con un precio por token de alrededor de una trigésima parte del modelo frontera de referencia más barato. Google mostró que los mismos pesos de Beam pueden servir varias veces más tráfico con enrutamiento consciente de caché. DeepSeek afirma que su actualización termina las tareas de agentes con menos pasos y salidas más cortas. Las tres son palancas reales. Ninguna dice cuánto cuesta una respuesta incorrecta, y para la mayoría de los workloads empresariales ese es el número más grande del cálculo.
El término que falta en la mayoría de los casos de negocio
Ya hemos defendido antes poner precio a la inferencia por tarea completada en lugar de por token. Eso es necesario y no suficiente, porque “completada” esconde una distinción: completada correctamente, completada mal y detectada, completada mal y no detectada.
Una unidad más completa es el coste por salida aceptada: lo que usted paga por inferencia, más lo que paga por verificar, más lo que le cuestan los errores que escapan, dividido por las salidas que realmente usa. El modelo pequeño ajustado en la prueba de Microsoft y las referencias de frontera difieren en unas 29 veces en precio de entrada y en unas ocho veces en tasa de error. Cuál es más barato depende del precio del tercer término, y ese precio lo fija dónde se detecta un error en su proceso.
Dónde se detecta un error se fija su precio
Detectado por códigoNunca detectado
- Chequeo deterministaEsquema, totales, datos maestros: fracciones de céntimo
- Revisor en el flujo de trabajoMinutos de una persona que iba a mirar de todos modos
- Sistema posterior o clienteRetrabajo, notas de crédito, un caso de soporte
- Auditor o reguladorHallazgos, programas de remediación, solicitudes de evidencia
- NadieDecisiones tomadas con datos incorrectos
Cinco reglas para poner precio a un workload
1. Ponga precio al error que escapa antes de comparar tokens. Para cada flujo de trabajo, anote cuánto cuesta una salida incorrecta si llega al paso siguiente, y quién paga: un revisor, un cliente, un equipo de cumplimiento normativo. Si nadie puede nombrar la cifra, la elección de modelo no está lista para tomarse.
2. Compre verificación antes que capacidad cuando los chequeos son baratos. Un modelo con F1 de 0.81 y validez de JSON casi perfecta es una mala respuesta final y una buena primera pasada, si los chequeos deterministas detectan la mayoría de sus fallos: totales que deben cuadrar, IDs que deben existir, fechas que deben parsearse. Los agentes de ventas de AWS muestran el mismo patrón en producción: chequeos deterministas para cada respuesta conocida, jueces de modelo solo para el resto. La verificación mueve los errores a la izquierda del espectro, donde son baratos.
3. Gaste tokens de modelos frontera donde los errores escapan lejos. Las salidas que van directas a clientes, contrapartes o reguladores se sitúan a la derecha del espectro. Ahí, un precio por token más alto suele ser el control más barato que usted puede comprar. Enrute por consecuencia, no por tipo de tarea.
4. Mida la tasa de salidas aceptadas, no el benchmark. Los benchmarks miden un modelo en el harness de otra persona. Lo que usted paga es la proporción de salidas que su proceso acepta sin corrección, medida sobre sus documentos, sus herramientas y su configuración de servicio, que, como muestran las recetas de Beam, puede cambiar la economía tanto como el modelo.
5. Vuelva a poner precio cuando algo cambie. Un modelo nuevo detrás de un alias, una precisión nueva, un prompt nuevo o una fuente de datos nueva mueven la tasa de error. El precio por salida aceptada es una medición con fecha, no una propiedad de un proveedor.
En el trabajo regulado, el lado derecho del espectro es más largo
Para un banco o una farmacéutica, el extremo derecho del espectro incluye hallazgos, programas de remediación y, en el peor caso, decisiones tomadas sobre datos que estaban mal de una forma que nadie detectó. Eso cambia la aritmética más que cualquier precio por token. También cambia lo que cuenta como verificación: un chequeo documentado y versionado que produce evidencia vale más que la mirada no registrada de un revisor. Esto es coherente con lo que hemos llamado capacidad de verificación, el nuevo cuello de botella.
Nuestra opinión, y es una opinión y no un hecho medido: la mayoría de los sobrecostes de IA empresarial que se achacan a los precios de los modelos resultarán, al examinarlos, ser costes de verificación y de errores que nunca se pusieron en precio. Los equipos que controlen el gasto en IA no serán los que tengan el modelo más barato. Serán los que sepan, para cada flujo de trabajo, dónde caen sus errores y cuánto cuesta detectarlos.