¿Menos cómputo significa realmente menos coste?

Invocar un modelo con menos frecuencia parece una buena noticia. Esperamos menos operaciones, menos espera y un menor consumo de recursos.

Pero el mecanismo que reduce esas llamadas también tiene trabajo. Prepara posibilidades, evalúa opciones y decide cuál aplicar. A veces, el sistema que rodea al modelo asume el trabajo que este deja de hacer.

Así, una parte del cómputo puede reducirse mientras otra crece.

Un experimento de ADL hizo visible esta distinción. Disminuyó el número de pasadas hacia delante del modelo, pero no se verificó un ahorro en el tiempo total medido. El resultado planteó una pregunta: cuando consideramos más barato un método, ¿qué parte del sistema estamos mirando?

Elegir también tiene un coste

ADL distingue entre el modelo que aprende y el mecanismo que selecciona las intervenciones sobre él. En el experimento F2-041, el método candidato evaluaba dos cambios propuestos y elegía el que reducía más el error de entrenamiento.

Esto permitía obtener más información antes de decidir. Sin embargo, preparar y evaluar ambas propuestas también requería tiempo.

Frente al método de referencia fuerte, las pasadas hacia delante del modelo disminuyeron aproximadamente un 36 %. En cambio, el tiempo del Controller, encargado de preparar y gestionar las intervenciones, aumentó aproximadamente un 10,5 %.

No podemos restar esos porcentajes para calcular el ahorro total. Uno describe un número de operaciones; el otro, el tiempo de un componente concreto. Sin conocer su peso dentro del mismo presupuesto y cómo se midieron, no se convierten en una única tasa de mejora.

El experimento no verificó un ahorro en el tiempo total medido. Tampoco se midió el consumo energético. Por tanto, menos pasadas hacia delante no demuestran un menor consumo de energía.

¿El coste de qué tarea comparamos?

Mirar únicamente los recursos que consume un sistema deja incompleta la comparación. También necesitamos saber qué obtiene con ellos.

Un método que hace menos operaciones puede producir un resultado de menor calidad. Otro con mayor exactitud puede necesitar más tiempo para completar la misma tarea. Para compararlos, primero hay que definir el criterio de éxito.

En el experimento de ADL, el objetivo era mejorar al menos tres puntos porcentuales la exactitud final frente a cada uno de cuatro métodos de referencia, dentro del mismo presupuesto de un segundo de CPU. La diferencia observada frente al método fuerte fue de unos 0,09 puntos porcentuales. No se cumplió el criterio de calidad predefinido.

La reducción de pasadas hacia delante no cambió esa decisión. Fue una observación interesante sobre el número de operaciones, pero no constituyó por sí sola un éxito de calidad o coste total.

Por eso, «más eficiente» necesita una precisión: ¿para qué resultado, con qué presupuesto y frente a qué comparación?

El trabajo que queda fuera del cálculo

Alrededor de una llamada al modelo puede haber otras operaciones: recuperar información, generar opciones, verificar, registrar o reintentar un paso fallido.

Varían según el sistema, pero plantean una pregunta común. ¿El coste comunicado cubre solo la ejecución del modelo o también las demás etapas necesarias para completar la tarea?

Ambas mediciones tienen utilidad. Conocer el coste del modelo ayuda a mejorar ese componente. Conocer el coste del resultado entregado al usuario ayuda a evaluar el flujo de trabajo completo.

Lo importante es no sustituir el alcance de una medición por el de la otra.

Los registros de ADL no identificaron qué suboperación causaba la diferencia de coste del Controller. Por ello, no era posible atribuir el aumento únicamente a copiar, preparar propuestas o comparar. Observar la diferencia total no significaba conocer su causa.

Mantener visibles las mediciones ausentes

Es fácil excluir un valor del informe cuando no podemos medirlo. Pero ese valor ausente también forma parte de la decisión.

Si no medimos la energía, no debemos concluir que hubo ahorro energético. Si no medimos el coste de extremo a extremo, no debemos extender la reducción de un componente al sistema completo. Si no se cumplió el criterio de calidad, una mejora en el número de operaciones no debe sustituirlo.

El enfoque del white paper de Nage AI OS y SEDIM sobre recursos y costes responde a la misma necesidad de claridad: indicar el método, el alcance y la información no disponible junto al valor medido.

A veces empezamos a mejorar un sistema haciendo que ejecute menos operaciones. Para continuar, necesitamos ver dónde produce un efecto esa reducción.

Medir lo suficiente para la siguiente decisión

El registro de ADL no demuestra que los mecanismos de selección sean innecesarios. Muestra por qué también debemos evaluar el coste de obtener información para decidir.

Elegir una intervención mejor en una ronda puede ser valioso. Sin embargo, el tiempo invertido en preparar esa ronda puede limitar el progreso conseguido. Para entenderlo, hay que examinar la mejora por intervención junto con la mejora por unidad de tiempo.

Esa distinción determina la siguiente pregunta:

¿Las operaciones que hacemos con menos frecuencia permiten realmente obtener un resultado de la misma calidad con menos recursos totales?

Nota sobre las fuentes: Este artículo se basa en los registros F2-041 y F2-042 utilizados en el artículo anterior sobre ADL, con el alcance documental fechado el 15 de octubre de 2026. No presenta un experimento nuevo. Los hallazgos se limitan a una pequeña tarea sintética en CPU.

Investigación ADL · El artículo sobre el experimento ADL · Sobre Nage AI OS y SEDIM