💻 computer science

Measure Once, Model Everywhere: Model-Based Per-Request Resource Consumption for HTTP

Este artículo presenta un enfoque basado en modelos implementado como una extensión de nginx que estima el consumo de recursos y las emisiones de carbono por cada solicitud para servicios HTTP mediante la derivación de modelos de energía fuera de línea a partir de características observables de las solicitudes, permitiendo así divulgaciones de sostenibilidad prácticas sin requerir telemetría de potencia detallada en producción.

Autores originales: Geerd-Dietger Hoffmann, Verena Majuntke

Publicado 2026-07-03

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Geerd-Dietger Hoffmann, Verena Majuntke

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que entras en un restaurante. Pides una comida y el camarero te trae la cuenta. Normalmente, esa cuenta te indica el precio y quizás las calorías. Pero, ¿y si también te dijera exactamente cuánta electricidad y contaminación por carbono se crearon solo para cocinar tu plato específico?

Ese es el problema que este artículo intenta resolver para el internet.

El Problema: El "Menú Invisible"

En este momento, cuando haces clic en un botón de un sitio web (como "Iniciar sesión" o "Enviar un mensaje"), el servidor que hay detrás de escena realiza algún trabajo. Utiliza electricidad para pensar, almacenar datos y enviar una respuesta. Pero la persona que hace clic en el botón no tiene idea de cuánto le costó de energía ese clic específico.

Es como pedir una comida y que te digan: "Usamos mucha electricidad para hacer funcionar esta cocina", pero sin saber nunca si tu ensalada consumió menos energía que tu filete. Como no podemos ver el costo, no podemos tomar mejores decisiones para salvar el planeta.

La Solución: "Medir una vez, modelar en todas partes"

Los autores se dieron cuenta de que intentar medir la electricidad de cada uno de los clics en tiempo real es demasiado difícil y costoso (como intentar pesar cada grano de arroz en un cubo mientras lo viertes).

En su lugar, idearon una receta ingeniosa de dos pasos:

La "Cocina de Pruebas" (Medición Offline):
Primero, toman una función específica de un sitio web (como "Iniciar sesión") y la prueban en un laboratorio controlado. Ejecutan el botón de "Iniciar sesión" 100 veces con diferentes entradas (contraseñas cortas, contraseñas largas, archivos grandes) y miden exactamente cuánta energía utiliza.
- Analogía: Es como un chef probando una receta en una cocina tranquila para ver exactamente cuánto gas se necesita para hervir una olla de agua.
La "Tarjeta de Receta" (El Modelo):
A partir de esas pruebas, escriben una "tarjeta de receta" simple (un modelo matemático) para esa función.
- Funciones simples: "Cerrar sesión" siempre consume la misma cantidad mínima de energía. La tarjeta simplemente dice: Costo Fijo: 0.006 mWh.
- Funciones variables: "Subir un archivo" cuesta más si el archivo es más grande. La tarjeta dice: Costo base + (Tamaño del archivo × Energía por byte).
- Funciones de IA: Para un chat de IA, el costo depende de cuántas palabras (tokens) escribes tú y cuántas escribe la IA de vuelta. La tarjeta dice: Costo = (Tus palabras × Pequeña tarifa) + (Palabras de la IA × Gran tarifa).

Cómo funciona en la vida real

Una vez que tienen estas "tarjetas de receta", las colocan en un registro digital (un archivo JSON). Instalan un plugin especial en el servidor web (como un policía de tráfico inteligente en la entrada).

Cada vez que realizas una solicitud:

El servidor analiza tu solicitud (por ejemplo, "Estás subiendo un archivo de 5MB").
Consulta la "tarjeta de receta" para esa acción específica.
Realiza un cálculo matemático rápido basado en el tamaño de tu archivo.
Calcula instantáneamente el costo de energía y la huella de carbono.
Te envía esta información de vuelta en los encabezados de la respuesta (como un recibo digital), diciendo: "Esta solicitud utilizó 0.989 mWh de energía y creó 0.633 mg de CO2".

Lo que encontraron

Los autores probaron esto en una aplicación sencilla de "Lista de tareas" y en un chatbot de IA.

Es lo suficientemente preciso: Cuando compararon sus estimaciones calculadas con las mediciones del mundo real, los números fueron muy cercanos (con una diferencia de aproximadamente el 2-3%). No es una medición de laboratorio de física perfecta, pero es suficiente para distinguir entre una solicitud "ligera" y una "pesada".
Es rápido: Añadir este cálculo al servidor apenas ralentizó el proceso (menos del 0.5% de sobrecarga). Es como añadir una pequeña pegatina a un paquete; el camión de reparto ni siquiera lo nota.
Maneja la complejidad: Demostraron que incluso para la IA, donde el costo depende de cosas invisibles (como cuántos tokens genera la IA), pueden lograr que la aplicación le diga al servidor los números para que el servidor pueda hacer la matemática.

Por qué esto es importante

El artículo argumenta que esto no se trata de obligar a la gente a dejar de usar internet. Se trata de hacer visible lo invisible.

Para los usuarios: Si pudieras ver que un prompt de IA específico cuesta 100 veces más energía que una búsqueda simple, podrías optar por ser más eficiente.
Para las empresas: Les ayuda a ver qué partes de su software son "devoradores de energía" para que puedan arreglarlas.
Para los diseñadores: Permite el "diseño dirigido por restricciones". Al igual que un sitio web alimentado por energía solar podría atenuar sus luces cuando el sol se pone, un sitio web podría mostrarte el "precio energético" de tus acciones, permitiéndote decidir si vale la pena.

El Problema (Limitaciones)

Los autores son honestos sobre los límites:

Es una estimación: Se basa en modelos, no en una báscula directa en cada solicitud.
Necesita actualizaciones: Si el hardware del servidor cambia o si la red eléctrica se vuelve más sucia o más limpia, las "tarjetas de receta" deben actualizarse.
No es una varita mágica: Saber el costo de carbono no detiene automáticamente la contaminación. Es una herramienta para ayudar a las personas a tomar mejores decisiones, no una solución en sí misma.

En resumen: Este artículo construye una "etiqueta nutricional" para cada uno de los clics en la web, para que finalmente sepamos el verdadero costo ambiental de nuestras interacciones digitales.

Resumen Técnico: Medir una vez, modelar en todas partes

Planteamiento del problema
Las propuestas actuales para la divulgación de sostenibilidad basada en HTTP se centran principalmente en qué información ambiental debe transmitirse (por ejemplo, a través de encabezados de respuesta), pero dejan abierta la cuestión práctica de cómo generar valores creíbles por solicitud en despliegues realistas. En los entornos nativos de la nube, los recursos se abstraen como elásticos y bajo demanda, ocultando los costes físicos y ecológicos de la infraestructura subyacente. Aunque los proveedores pueden desear la divulgación, la ejecución de las solicitudes suele abarcar múltiples sistemas y la telemetría de potencia de grano fino no suele estar disponible en el límite del protocolo. En consecuencia, los clientes y los operadores no pueden distinguir entre interacciones de alto y bajo coste, lo que impide que los costes ecológicos se factoricen en decisiones de diseño tales como el comportamiento de reintento, el agrupamiento (batching) o el diseño de prompts.

Metodología
El artículo propone un enfoque basado en modelos para estimar el consumo de recursos y el $CO_2e$ por cada solicitud HTTP sin requerir telemetría de potencia de grano fino en producción. El método separa la medición fuera de línea (offline) de la estimación en línea (online):

Benchmarking fuera de línea: Los endpoints se caracterizan bajo condiciones controladas utilizando la herramienta Green Metrics Tool (GMT) en una máquina dedicada. Los parámetros de la carga de trabajo (por ejemplo, tamaño de la carga útil, recuento de tokens) se varían sistemáticamente para aislar las señales de energía del ruido.
Derivación del modelo: A partir de estas mediciones, se derivan modelos de energía compactos y específicos para cada endpoint. El enfoque utiliza tres familias de modelos para equilibrar la expresividad y la interpretabilidad:
- Modelos constantes: Para endpoints donde la energía no varía apreciablemente con la entrada (por ejemplo, autenticación).
- Modelos lineales: Para endpoints donde la energía escala proporcionalmente con una característica observable (por ejemplo, recuentos de tokens en la inferencia de IA).
- Modelos de curva (por tramos): Para endpoints que exhiben regímenes de escalado distintos (por ejemplo, cargas de archivos), representados mediante puntos de soporte medidos con interpolación lineal.
Selección de características: Los modelos dependen de características observables en el límite del servidor HTTP (por ejemplo, duración de la solicitud, bytes transferidos, método HTTP, estado de la respuesta) o metadatos suministrados por la aplicación expuestos mediante encabezados internos (por ejemplo, recuento de tokens para inferencia).
Cálculo de emisiones: La energía predicha se convierte en emisiones distinguiendo entre:
- Emisiones operativas: Calculadas multiplicando la energía predicha por la intensidad de carbono de la red ( $I$ ), que puede ser estática o dinámica.
- Emisiones incorporadas: Calculadas amortizando el impacto de fabricación del hardware a lo largo de su vida útil operativa y asignando una parte basada en el tiempo de procesamiento de la solicitud.
Implementación en tiempo de ejecución: El mecanismo se implementa como una extensión de nginx (usando ngx_http_js_module). En tiempo de ejecución, el servidor carga un registro JSON que contiene los modelos y los parámetros. Para cada solicitud, la extensión extrae las características relevantes, evalúa el modelo apropiado y emite metadatos por solicitud a través de encabezados de respuesta.

Contribuciones clave

Identificación de la brecha: El artículo separa la cuestión a nivel de protocolo de qué divulgar de la cuestión de sistemas de cómo generar valores por solicitud, identificando esta última como una brecha crítica en las discusiones actuales sobre sostenibilidad.
Pipeline de medición a modelo: Propone un pipeline que deriva modelos de energía compactos, interpretables y ejecutables a partir de benchmarks controlados fuera de línea, adecuados para endpoints heterogéneos, incluyendo aquellos que requieren características de la capa de aplicación.
Evaluación en el lado del servidor: Demuestra cómo estos modelos pueden evaluarse en el límite del servidor HTTP y exponerse como metadatos de sostenibilidad manteniendo explícitos los supuestos subyacentes (por ejemplo, la intensidad de la red, los métodos de asignación).
Evaluación de la viabilidad: El enfoque se evalúa en servicios web convencionales y en un endpoint de inferencia de IA, mostrando la viabilidad operativa y un bajo impacto en el tiempo de ejecución.

Resultados

Precisión del modelo: Los modelos ajustados capturan con éxito el comportamiento dependiente de la carga de trabajo. Para los endpoints CRUD, los modelos constantes fueron suficientes para la autenticación, mientras que los modelos de curva capturaron el escalado dependiente de la carga útil para las cargas de archivos y la recuperación de datos. Para el endpoint de IA, un modelo lineal utilizando el recuento de tokens de prompt y de generación explicó casi toda la variación observada, corrigiendo el comportamiento no monotónico visto al utilizar únicamente etiquetas de prompt gruesas.
Validación: Una ejecución de validación de ruta de clics (click-path), que simula un trayecto de usuario realista, mostró que la estimación basada en el modelo (611.1 mWh) se desvió solo un 2.33% de la energía medida a nivel de máquina (597.2 mWh), preservando el orden de magnitud correcto.
Sobrecarga: Habilitar el módulo de nginx introdujo una sobrecarga de tiempo de ejecución de aproximadamente el 0.46% en la energía total de la máquina, con variaciones por ruta dominadas por el ruido de ejecución a ejecución más que por el propio plugin.
Divulgación: El prototipo emite con éxito encabezados distintos para Request-Energy, Grid-Intensity, Request-Embodied-CO2e y Request-SCI, permitiendo a los consumidores descendentes reconstruir el cálculo.

Significación y afirmaciones
El artículo posiciona este trabajo no como una solución que reduzca inherentemente la demanda, sino como un sustrato necesario para las tradiciones de diseño basadas en restricciones (suficiencia, sobriedad, decrecimiento y diseño de servidores de bajo impacto). Los autores argumentan que, para que estas estrategias funcionen, el coste ambiental marginal de una interacción debe ser legible en la interfaz donde se emite la solicitud.

La significación reside en proporcionar un método reproducible e inspectable para hacer visibles las implicaciones ambientales donde se toman las decisiones, abordando la exclusión estructural de los costes ecológicos en el diseño de software actual. Los autores advierten explícitamente contra las sobrevaloraciones:

Los valores son abstracciones a nivel de interfaz, no atribuciones físicas de verdad absoluta.
El método no resuelve el greenwashing ni desplaza la responsabilidad de forma asimétrica; más bien, proporciona la capa de visibilidad necesaria para que tales críticas sean efectivas.
El enfoque está limitado por su dependencia del entorno de calibración (hardware, red, co-tenencia) y requiere una recalibración periódica.

En resumen, el artículo ofrece una vía de implementación práctica para la divulgación de la sostenibilidad por solicitud, transformando el objetivo abstracto de "medir una vez" en un sistema desplegable que "modela en todas partes".