Benchmarking de energía en IA: frameworks, métricas y estado del arte (ficha a ficha)

Notación: importes en euros (N €), decimales con coma. Las referencias de energía y carbono son europeas (Francia, Alemania, España), por tratarse de una propuesta soberana. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula).

Qué cubre esta introducción

Cuarto artículo de la serie de datos y deep dive del eje de energía. Medir los vatios de una carga de IA parece un detalle de sostenibilidad, pero es a la vez una palanca de coste (la electricidad es el 30–50 % del TCO), un eje de soberanía (el carbono por token depende del país) y, cada vez más, una obligación regulatoria (reporte de emisiones). Este artículo inventaría las métricas, de dónde sale físicamente cada dato, la ficha de cada framework de medición, y cómo se pasa del vatio al carbono con datos europeos. Sin recomendaciones; solo datos y metodología, porque en energía —más aún que en rendimiento— el método de medida cambia el resultado.

Por qué medir energía importa (con números)

Tres razones cuantificadas, que conectan con el artículo de apertura:

A 700 W por H100, un nodo de 8 tarjetas consume del orden de 5,6 kW solo de placa, ~49.000 kWh al año. Aplicando el PUE 1,4 son ~68.700 kWh/año, y ahí el país decide la factura: a precio mayorista francés (~0,058 €/kWh) eso son ~3.980 €/año de electricidad por nodo; en Alemania (~0,091 €/kWh), ~6.250 €/año — un 57 % más por el mismo hierro y el mismo trabajo. Multiplicado por una flota, es una partida de coste de primer orden, y una huella de carbono que, en Europa, hay que medir y reportar. La energía dejó de ser un detalle de ingeniería para ser una variable de negocio y de cumplimiento.

Las métricas de energía

Las dos identidades base de todo el eje:

$$\text{energía por token (J)} = \frac{\text{potencia media (W)}}{\text{throughput (tok/s)}}$$

$$\text{carbono} = \text{energía (kWh)} \times \text{PUE} \times \text{intensidad de red (gCO}_2\text{/kWh)}$$

La primera es la misma forma que el coste por token: comparte el denominador del throughput, así que subir tokens/s baja la energía por token. La segunda introduce los dos multiplicadores externos al cómputo —el PUE del datacenter y la intensidad de red del país— que pueden cambiar el carbono por token en un orden de magnitud sin tocar el stack.

Ejemplo trabajado: energía por token de un nodo 8×H100

Para anclar las identidades con números, el cálculo de extremo a extremo sobre el nodo de ejemplo (8×H100, Llama 3.1 70B FP16, vLLM a 2.800 tok/s):

De ahí salen el coste eléctrico y el carbono, por país:

Y el enlace con el rendimiento: si una optimización (p. ej. FP8) subiera el throughput a 4.200 tok/s, la energía por token bajaría a ~1,33 J/token (placa) y todo lo de abajo en la misma proporción — el coste eléctrico y el carbono por token caen con el throughput, por la identidad. Nota: estas son cifras de placa + PUE; el nodo completo (CPU, NICs, fuentes) consume algo más, y la energía medida con un vatímetro puede diferir de la estimada con nvidia-smi.

De dónde sale el dato: las capas de medición

No toda cifra de energía es igual de fiable. El dato puede venir de cuatro capas, con precisión creciente y contexto decreciente:

La GPU es la fuente dominante en inferencia LLM, y su potencia se lee por contador de hardware (NVML/nvidia-smi, agregado por DCGM — la misma base que la observabilidad GPU). RAPL da la de CPU y DRAM. La capa de eBPF + modelo (Kepler) reparte el vatio total entre contenedores y pods sin instrumentar la aplicación. Y el vatímetro físico es la verdad-terreno contra la que se calibran las estimaciones: ninguna estimación software es mejor que el vatímetro, solo más cómoda.

Cómo se instrumenta (y dónde se cuela el error)

Cuatro decisiones de instrumentación explican la mayoría de las discrepancias entre mediciones de energía:

• Frecuencia de muestreo. nvidia-smi/DCGM leen la potencia a intervalos; un muestreo demasiado grueso se pierde los picos y subestima la energía. Hay que muestrear lo bastante fino para capturar la variación de potencia entre prefill (alta) y decode (más baja).
• Placa vs nodo. La potencia de la GPU (placa) no incluye CPU, NICs, ventiladores ni pérdidas de las fuentes (típicamente un 10–20 % extra). Comparar una energía de placa con una de nodo completo es comparar cosas distintas.
• Baseline de idle. Una GPU encendida sin trabajo ya consume potencia. ¿Se atribuye ese idle a la carga o se descuenta? La decisión cambia la energía por token, y el idle importa: es energía real que alguien paga.
• Ventana temporal. La energía es la integral de la potencia en el tiempo; la ventana de medición tiene que alinearse exactamente con la carga (sin contar el warm-up ni el apagado), o el número no corresponde al trabajo medido.

Estas decisiones, igual que en el benchmarking de rendimiento, hacen que el método de medida importe tanto como el sistema medido. Un J/token sin especificar muestreo, frontera placa/nodo y tratamiento del idle no es comparable.

Frameworks, ficha a ficha

Zeus (ml.energy, Universidad de Michigan)

Qué hace: medir y optimizar la energía de cargas de deep learning. Método: contadores NVML. Ámbito: GPU NVIDIA y AMD, CPU, DRAM, Apple Silicon y NVIDIA Jetson. Licencia: OSS; respaldo académico (paper NSDI'23). Diferenciador: no solo mide, también optimiza (power capping, selección de frecuencia) para reducir energía sin perder rendimiento significativo (Zeus Project, NSDI'23). Es la herramienta de referencia cuando el objetivo es bajar los J/token, no solo medirlos.

CodeCarbon

Qué hace: estima la energía y el CO₂eq de procesos de cómputo. Método: lee la GPU con nvidia-smi y estima CPU/RAM. Ámbito: CPU + GPU + RAM. Licencia: OSS (Python). Diferenciador: integra en flujos de ML y pipelines de CI, y es el que más se aproxima al vatímetro entre las herramientas Python (comparación). Aporta contexto de carbono de serie. Límite: estimación de alto nivel, menos exacta que la medición directa por hardware.

CarbonTracker

Qué hace: rastrea energía y carbono en tiempo de ejecución de GPU. Ámbito: solo GPU —no mide CPU ni memoria—. Licencia: OSS. Diferenciador: ligero, fácil de añadir a un script de entrenamiento/inferencia. Límite: cobertura parcial (sin CPU/DRAM), así que infravalora la energía total del sistema.

Scaphandre

Qué hace: agente de metrología de potencia escrito en Rust. Método: RAPL (lee /proc, reparte julios por ticks de CPU). Ámbito: proceso o VM, con precisión cruda de la capa hardware. Licencia: OSS. Diferenciador: la mayor exactitud directa de las herramientas generalistas, a costa de no traer contexto de carbono (es metrología pura) (Scaphandre · GitHub). Límite: centrado en CPU/RAPL; para GPU hay que combinarlo con NVML.

Kepler (CNCF)

Qué hace: exporter de Prometheus que mide energía a nivel de contenedor, pod y nodo en Kubernetes. Método: eBPF + modelos de ML para estimar el consumo por carga. Lenguaje: Go + C. Licencia: Apache 2.0 (proyecto sustainable-computing-io) (Kepler · GitHub). Diferenciador: es la opción cloud-native para atribuir energía por pod sin instrumentar la app, igual que OpenCost atribuye el coste. Límite: la atribución por eBPF + modelo es estimación, no medición directa; su precisión depende del modelo.

MLPerf Power (MLCommons)

Qué hace: benchmark estandarizado de eficiencia energética, de µW a MW. Mantenedor: MLCommons. Diferenciador: comparabilidad cross-vendor de la eficiencia, con un dataset que abarca varios años y versiones de workload (MLPerf Power, arXiv 2410.12032). Es a la energía lo que MLPerf Inference es al rendimiento: el patrón de comparación entre fabricantes.

Tabla comparativa

Precisión: a quién creer

La diferencia entre herramientas no es de matiz: Scaphandre ofrece la precisión cruda de la capa hardware (RAPL), mientras que los Python como CodeCarbon dan estimaciones de más alto nivel y conscientes del carbono, con más contexto pero menos exactitud directa; entre los Python, CodeCarbon es el que más se acerca al vatímetro, seguido de CarbonTracker, con variabilidad entre infraestructuras (comparación). La regla: para dimensionar y diseñar, una estimación software vale; para defender una cifra ante un comité o un auditor, conviene calibrar contra un vatímetro al menos una vez, y usar la herramienta software como proxy continuo. El dato medido manda sobre el estimado; el resto es comodidad.

Leaderboards y benchmarks de energía

Para comparar eficiencia entre modelos sin montar un banco propio:

Estos recursos dan el orden de magnitud de la energía por token de cada modelo, útil para elegir modelo por eficiencia en la fase de diseño. Pero no sustituyen la medición en tu hardware y tu carga: un leaderboard mide en un banco concreto, no en tu nodo.

Del vatio al carbono: Francia, Alemania, España

Aquí el eje de energía se convierte en argumento de soberanía. El carbono por token sale de multiplicar la energía por la intensidad de red del país, que en Europa varía en casi dos órdenes de magnitud:

Fuentes: precios mayoristas (TradingEconomics), carbono de Alemania ~363 gCO₂/kWh (media 2024, Wikipedia), nuclear ~17–35 gCO₂e/kWh (EEA), España ~167 gCO₂/kWh (2020). La intensidad horaria se obtiene de ElectricityMaps.

El cálculo, sobre el nodo de ejemplo (0,78 kWh por millón de tokens, con PUE): en Francia (~40 gCO₂/kWh) son ~31 gCO₂ por millón de tokens; en Alemania (~363 gCO₂/kWh), ~283 gCO₂ — un factor de ~9×, sin tocar una línea del stack. Ubicar el cluster en Francia o España es, a la vez, una palanca de coste, de carbono y de cumplimiento (EU AI Act, controles ENS × 42001 × EU AI Act).

Palancas de eficiencia energética

Una vez que se mide, se puede bajar. Las palancas, ordenadas por la identidad J/token = W ÷ throughput (bajar el numerador o subir el denominador):

La cuantización (ver cuantización para inferencia) es la palanca de mayor retorno porque mueve los tres ejes a la vez: sube throughput, baja coste y baja energía por token. El power capping de Zeus es específico de energía: recorta la potencia de pico con poca pérdida de rendimiento, bajando los W del numerador. Y el idle —la GPU encendida sin trabajar— es energía pura tirada, que el scheduling recupera.

Del diseño a producción: dónde se mide la energía

Como con los otros ejes, la energía se mide en tres momentos, con herramientas distintas y precisión creciente:

La cifra de diseño (TDP) sirve para dimensionar la acometida eléctrica y la refrigeración, pero sobreestima (la GPU rara vez está al TDP el 100 % del tiempo). La de benchmark es la que se usa para el coste y el carbono por token de la propuesta, porque es medida y reproducible. Y la de producción (Kepler/DCGM) cierra el bucle: vigila que el consumo real coincide con lo presupuestado y alimenta el reporte de huella. Los tres tienen que ser trazables entre sí — es lo que hace el harness del artículo S4.

Energía en el TCO y la regulación europea

El cierre del eje: la energía no es solo sostenibilidad, es coste y cumplimiento.

• Coste: al ser el 30–50 % del TCO, cada mejora de J/token se traduce directamente en euros. En el ejemplo, pasar de Alemania (~0,091 €/kWh) a Francia (~0,058 €/kWh) baja la parte eléctrica ~37 % además del carbono.
• Regulación (CSRD): las empresas europeas deben reportar su huella de carbono (scope 2). Una red baja en carbono (Francia) mejora directamente ese dato reportado, y medir la energía por token deja de ser opcional para ser un requisito de reporte.
• EU AI Act: la eficiencia y el consumo energético forman parte de la documentación esperable de sistemas de IA, lo que convierte la medición de energía en parte del expediente técnico.

Un matiz de reporte que conviene conocer: la huella eléctrica es scope 2 (emisiones indirectas de la energía comprada), y se puede contabilizar por ubicación (la intensidad real de la red del país) o por mercado (según los certificados de origen contratados). La contabilidad por ubicación es la que premia de verdad poner el cluster en una red limpia como la francesa; la de mercado permite “comprar” energía verde por certificados. Saber cuál exige tu reporte CSRD cambia qué palanca (ubicación física vs contrato) baja el dato — y ambas parten de medir la energía por token, que es lo que da este eje.

Es decir: medir energía cubre a la vez una partida de coste de primer orden, el argumento de carbono/soberanía y una obligación regulatoria. Para una propuesta soberana europea, el eje de energía no es el “bonito de la sostenibilidad”: es una de las tres columnas con número.

Checklist de una medición energética reproducible

Para que una cifra de energía o carbono sea defendible ante un comité o un auditor, tiene que venir con su contexto. El mínimo a fijar y publicar:

La regla: si no puedes entregar esta tabla junto a la cifra de gCO₂/token, la cifra no es auditable. El harness reproducible del artículo S4 registra todos estos parámetros para que el dato de energía sea tan trazable como el de coste y el de rendimiento — y para que la huella reportada (CSRD) se sostenga ante una auditoría.

Estado del arte 2026

• Falta resolución específica de LLM: las herramientas generalistas miden bien a nivel de máquina/proceso, pero carecen de resolución específica para LLM (energía por token, por fase prefill/decode), y los simuladores carecen de modelado de emisiones — un hueco abierto del campo.
• eBPF como tendencia (Kepler) para atribuir energía por pod sin instrumentar la app, en paralelo a como OpenCost atribuye el coste.
• Estandarización de la comparación vía MLPerf Power y HF AI Energy Score.
• Optimización, no solo medición (Zeus): el campo pasa de “cuánto gasto” a “cómo gasto menos sin perder rendimiento”.

Límites y trampas (data-driven)

1. Estimación vs medición. Una cifra de nvidia-smi no es un vatímetro. Calibra al menos una vez contra hardware antes de defender un número.
2. Cobertura parcial. CarbonTracker mide solo GPU; Scaphandre, sobre todo CPU/RAPL. Suma las capas o infravaloras la energía total.
3. Olvidar el PUE. La energía de placa no incluye refrigeración ni pérdidas; sin el PUE subestimas el consumo y el carbono reales.
4. Carbono sin país. Un gCO₂/token sin especificar la red (y la hora) no significa nada: varía ~9× entre Francia y Alemania.
5. Confundir energía con sostenibilidad. Aquí es coste y cumplimiento, con número; tratarlo como un extra “verde” es perder una de las tres columnas de la propuesta.

Con esto cierra la tanda de introducciones: coste, rendimiento y energía, cada uno con sus frameworks y su metodología. El resto de la serie profundiza herramienta a herramienta hasta el cuadro de mando que sostiene la decisión de arquitectura soberana, con cifras europeas, medidas y reproducibles.

Cierre

La energía es el eje que más fácil es despachar como “el verde” y el que más esconde: es casi la mitad del coste, define la huella que Europa obliga a reportar, y su carbono por token cambia ~9× según el cluster esté en Francia o en Alemania. Medirla bien —con la capa adecuada, el muestreo correcto, el PUE incluido y la red del país— convierte un argumento blando de sostenibilidad en una columna dura de la propuesta, con número y fuente. Y la conclusión soberana se sostiene sola con los datos de este artículo: una plataforma de inferencia en Francia o España es, a la vez, más barata, más limpia y conforme con la jurisdicción europea que la misma plataforma en un hyperscaler estadounidense — y eso se demuestra con J/token medidos, gCO₂/kWh por país y euros, no con intenciones. El eje de energía no adorna la propuesta: la cierra.

Ver también

• Leaderboards de eficiencia energética de LLMs — los rankings de J/token donde aterrizan los números que miden estas herramientas: qué leaderboard usar, cómo leerlo y qué sesgos tiene.
• Del vatio al carbono: PUE, intensidad de la red y el coste real de un token — cómo convertir el J/token medido con Zeus o Kepler en gCO₂eq usando el PUE del datacenter y la intensidad de la red eléctrica del país.
• Palancas de eficiencia energética en inferencia LLM — qué cambios de configuración reducen los J/token que estas herramientas reportan: quantization, batching, motor, precisión del KV cache.

Fuentes

• Zeus Project (ml.energy, UMich) — https://ml.energy/zeus/
• Zeus · USENIX NSDI'23 — https://www.usenix.org/system/files/nsdi23-you.pdf
• Kepler (CNCF, eBPF) · GitHub — https://github.com/sustainable-computing-io/kepler
• Scaphandre · GitHub — https://github.com/hubblo-org/scaphandre
• CarbonTracker · GitHub — https://github.com/saintslab/carbontracker
• MLPerf Power (arXiv 2410.12032) — https://arxiv.org/html/2410.12032v2
• HF AI Energy Score — https://huggingface.github.io/AIEnergyScore/
• awesome-green-ai — https://github.com/samuelrince/awesome-green-ai
• TradingEconomics · precio electricidad Francia/Alemania/España — https://tradingeconomics.com/france/electricity-price
• EEA · intensidad de emisiones de la electricidad en Europa — https://www.eea.europa.eu/en/analysis/indicators/greenhouse-gas-emission-intensity-of-1
• Electricity sector in Germany (carbono ~363 gCO₂/kWh) — https://en.wikipedia.org/wiki/Electricity_sector_in_Germany