Por Canuto  

El costo de un modelo de inteligencia artificial no depende únicamente de cuánto cobra por token. Un análisis de Databricks muestra que la tasa de finalización, el consumo total y las herramientas que conectan al modelo pueden cambiar por completo el precio real de una tarea.
***

  • GLM 5.2 de Z.ai empató estadísticamente con Opus 4.8 en calidad, pero costó menos por tarea.
  • Sonnet 5 fue más barato por token que Opus 4.8, aunque terminó costando más por tarea y alcanzó una menor tasa de éxito.
  • Los harnesses o arneses pueden modificar de forma significativa el consumo de contexto, el costo y el rendimiento de los agentes de IA.

El precio real de la IA no está en los tokens, sino en completar las tareas

El costo por token ofrece una visión incompleta

El precio publicado por los servicios de inteligencia artificial puede llevar a conclusiones equivocadas. Un modelo con tokens costosos puede resultar más económico que otro con tokens baratos cuando se calcula el gasto necesario para completar una tarea.

La diferencia aparece porque una tarea no termina cuando el modelo consume una cantidad determinada de tokens. También importa si logra entregar el resultado solicitado, cuántos intentos necesita y qué volumen total de información procesa.

La discusión afecta especialmente a los agentes de IA dedicados a la programación. Estas herramientas reciben instrucciones, consultan archivos, ejecutan comandos, revisan errores y repiten operaciones antes de producir una respuesta útil.

Por esa razón, una comparación basada únicamente en el precio de entrada y salida puede ocultar gastos adicionales. Un modelo barato puede necesitar más contexto, más iteraciones o más tokens para alcanzar una solución aceptable.

La conclusión central es directa: el indicador relevante debería ser el costo por tarea completada. Esta métrica combina el precio del modelo con su capacidad para resolver el trabajo solicitado.

La evaluación interna de Databricks

The Register informó el 13 de julio de 2026 que Databricks creó un estándar interno para estudiar la relación entre precio y rendimiento de varios modelos de IA.

La compañía de software y servicios de análisis de datos utilizó tareas reales de ingeniería realizadas por su propio personal. El objetivo consistió en evaluar el desempeño de agentes dentro de un entorno de programación más cercano al uso cotidiano.

Matei Zaharia, director de tecnología de Databricks y profesor asociado de ciencias de la computación en la Universidad de California en Berkeley, explicó el motivo de la evaluación.

Según Zaharia, muchos modelos se adaptan a pruebas de referencia existentes, como SWE-Bench. OpenAI ha descrito esas pruebas como defectuosas, lo que impulsó a Databricks a diseñar una medición basada en su propio código y sus tareas internas.

El ejecutivo señaló que los resultados reflejan la base de código de Databricks. Sin embargo, otras empresas podrían construir evaluaciones semejantes utilizando sus propios repositorios y flujos de trabajo.

GLM 5.2 compite con Opus 4.8

Uno de los hallazgos más relevantes fue el desempeño de los modelos de peso abierto. Databricks encontró que GLM 5.2, desarrollado por Z.ai, puede competir con modelos líderes como Opus 4.8 de Anthropic.

De acuerdo con el informe de la compañía, GLM 5.2 alcanzó el nivel superior de capacidad y empató estadísticamente con Opus 4.8 en calidad. La diferencia apareció al calcular el costo de cada tarea completada.

GLM 5.2 registró un costo de USD $1,28 por tarea. Opus 4.8, en cambio, alcanzó un costo de USD $1,94 por tarea.

El resultado no significa que ambos modelos sean idénticos en todos los escenarios. La evaluación corresponde a las tareas y al código utilizados por Databricks, por lo que cada empresa tendría que comprobar si el patrón se repite en sus propios proyectos.

Aun con esa cautela, la comparación muestra que el precio nominal del modelo no basta para definir al ganador. Un sistema de peso abierto puede ofrecer una relación competitiva entre calidad, disponibilidad y costo operativo.

Sonnet 5 demuestra el límite de la métrica nominal

La comparación entre Sonnet 5 y Opus 4.8 refuerza la misma conclusión. Sonnet 5 cuesta menos por token, pero consumió una cantidad mayor de tokens para llegar al resultado necesario.

Calculado por tokens, Sonnet 5 fue aproximadamente 1,7 veces más barato que Opus 4.8. Sin embargo, el costo final por tarea alcanzó USD $2,09 para Sonnet 5, frente a USD $1,94 para Opus 4.8.

La tasa de finalización también cambió la ecuación. Sonnet 5 completó el 81 % de las tareas, mientras que Opus 4.8 logró completar el 87 %.

Una menor tasa de éxito obliga a considerar el precio de los intentos que no producen una solución. Para una empresa, esos fallos pueden representar tiempo adicional de supervisión, nuevas solicitudes y consumo extra de recursos.

El ejemplo no convierte automáticamente a Opus 4.8 en la mejor alternativa para todas las organizaciones. Sí demuestra que la evaluación debe observar el resultado final, la cantidad de tokens utilizados y la probabilidad de completar el trabajo.

La evidencia académica apunta en la misma dirección

La relación entre precio listado y costo real también apareció en un análisis académico publicado en marzo. Los investigadores observaron que el modelo con el precio anunciado más bajo terminó costando más en aproximadamente un tercio de las comparaciones.

Uno de los ejemplos citados enfrentó a Gemini 3 Flash con GPT-5.4. El precio listado de Gemini 3 Flash era un 80 % menor que el de GPT-5.4.

A pesar de esa diferencia inicial, Gemini 3 Flash registró un costo real un 38 % mayor al considerar todas las tareas. El resultado vuelve a mostrar que el consumo por operación puede superar la ventaja del precio unitario.

Estas mediciones son importantes para las empresas que proyectan presupuestos de automatización. Una tarifa por millón de tokens puede parecer atractiva, pero no revela cuántos intentos requiere cada proceso ni cuántas tareas terminan correctamente.

Para los compradores de tecnología, la métrica exige una revisión más amplia. El análisis debería incluir calidad, tasa de finalización, consumo total, costo de los errores y comportamiento dentro del entorno donde se utilizará el modelo.

Los harnesses también cambian el costo

Databricks identificó otro factor decisivo: el harness o arnés que conecta al usuario con el modelo. Estas capas de software pueden recibir la solicitud, invocar herramientas, administrar el contexto y devolver el resultado.

Entre los ejemplos se encuentran Claude Code, OpenAI Codex y el agente de programación Pi. Aunque empleen un mismo modelo, sus instrucciones y métodos de trabajo pueden producir consumos muy diferentes.

Zaharia afirmó que los harnesses generan una diferencia considerable en la relación entre costo y rendimiento. En la evaluación, el harness sencillo de Pi alcanzó la misma tasa de éxito que los harnesses de los proveedores con Opus y GPT-5.5.

La diferencia estuvo en el precio. Pi consiguió ese resultado con un costo dos veces menor, según los datos compartidos por Databricks.

El contexto enviado en cada turno ayuda a explicar la variación. Cuando Claude Code funcionó como harness para Opus 4.8, Databricks midió 742.000 tokens de contexto por tarea.

El contexto puede inflar la factura

El harness de Pi utilizó 236.999 tokens de contexto por tarea en la misma comparación. Esto representa aproximadamente 3,2 veces menos tokens totales que Claude Code.

La diferencia también apareció al comparar Codex con Pi. Codex utilizó 1.235.000 tokens de contexto por tarea, mientras que Pi empleó 665.000 tokens.

El contexto permite que un agente conserve información sobre archivos, instrucciones y pasos previos. No obstante, un contexto demasiado amplio puede elevar el consumo aunque el modelo tenga un precio unitario competitivo.

El hallazgo también modifica la forma de comparar productos de IA. El modelo, el harness, las herramientas y las instrucciones forman un sistema conjunto, no componentes independientes con costos fáciles de separar.

Para los usuarios empresariales, esto significa que cambiar de interfaz o de agente puede alterar la factura sin cambiar el modelo principal. La optimización puede depender tanto del diseño del flujo como de la elección del proveedor.

Omnigent y la búsqueda de una mejor combinación

Los resultados ayudan a explicar por qué Databricks desarrolló Omnigent. La herramienta funciona como una envoltura para combinar y alternar múltiples agentes de programación.

El sistema representa una estrategia de selección en la capa de interacción. En lugar de depender de un único agente, una empresa puede evaluar qué combinación de herramientas y modelos resuelve mejor cada tipo de tarea.

Zaharia comparó esta idea con el intercambio de modelos que permiten plataformas como OpenRouter. En ese caso, la selección ocurre principalmente en la parte posterior del sistema, mientras Omnigent opera como una capa frontal para coordinar agentes.

La propuesta puede resultar útil cuando las tareas tienen niveles distintos de dificultad. Un agente sencillo podría encargarse de operaciones rutinarias, mientras un modelo más capaz asumiría los problemas que requieren mayor razonamiento.

Sin embargo, la herramienta no elimina la necesidad de medir resultados. Cada combinación debe probarse con tareas reales, porque un flujo que funciona bien en un repositorio puede rendir peor en otro entorno.

Una nueva forma de comprar inteligencia artificial

La discusión sobre costos tiene consecuencias para las empresas que incorporan agentes de IA. Las áreas financieras pueden dejar de comparar solo tarifas por token y comenzar a revisar el costo de cada resultado útil.

Ese cambio también afecta a los desarrolladores. La selección de un modelo debería considerar su comportamiento dentro del harness elegido, el volumen de contexto y la frecuencia con que necesita repetir una operación.

Las pruebas de referencia siguen siendo útiles para establecer comparaciones generales. No obstante, los datos de Databricks sugieren que las evaluaciones internas pueden revelar diferencias que los benchmarks públicos no capturan.

La calidad tampoco debe analizarse separada del precio. Un sistema que cuesta menos, pero falla más veces, puede generar gastos operativos y retrasos que no aparecen en la factura del proveedor.

El principio final es sencillo: la inteligencia artificial debe medirse por el valor que entrega. Para conocer ese valor, las compañías necesitan observar la tarea completa, desde la primera instrucción hasta la solución verificada.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados