---
title: "Benchmarking de energía en IA: frameworks, métricas y estado del arte (ficha a ficha)"
url: https://blog.lo0.es/posts/benchmarking-energia-llm-frameworks-estado-del-arte/
markdown: https://blog.lo0.es/posts/benchmarking-energia-llm-frameworks-estado-del-arte/index.md
lang: es
date: 2026-06-13
lastmod: 2026-06-17
author: "José Manuel Román"
description: "Introducción de datos al tooling de medición de energía y carbono en IA: las métricas (J/token, Wh, gCO2), las capas de medición (NVML/DCGM, RAPL, eBPF), la ficha de Zeus, CodeCarbon, CarbonTracker, Scaphandre, Kepler y MLPerf Power, los leaderboards, y el carbono por país europeo (Francia, Alemania, España). Estado del arte 2026, con fuentes."
tags: ["energia","zeus","codecarbon","kepler","scaphandre","mlperf-power","carbono","dcgm","soberania","serie-datos"]
translations:
  en: https://blog.lo0.es/en/posts/ai-energy-benchmarking-frameworks-metrics-state-of-the-art/index.md
---

# 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](https://blog.lo0.es/posts/tres-ejes-coste-rendimiento-energia-inferencia-llm/index.md):

| Razón | Dato | Implicación |
|---|---|---|
| **Coste** | electricidad = 30–50 % del TCO | medir energía es medir casi la mitad del coste |
| **Soberanía/carbono** | Francia ~9× menos gCO₂/token que Alemania | el país del cluster es una palanca |
| **Escala/regulación** | datacenters ~460 TWh en 2025 (≈1,8 % mundial), >800 TWh proyectado 2028 | reporte de emisiones (CSRD) obligatorio |

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

| Métrica | Definición | Unidad |
|---|---|---|
| Potencia media | consumo instantáneo promedio | W |
| **Energía por token** | energía consumida por token generado | J/token |
| Energía por inferencia | energía por petición | µJ – Wh |
| Energía total | integral de potencia en el tiempo | Wh, kWh |
| **PUE** (Power Usage Effectiveness) | overhead del datacenter (refrigeración, pérdidas) | ratio ≥ 1 |
| Carbono | energía × intensidad de red | gCO₂eq |

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):

| Paso | Cálculo | Resultado |
|---|---|---|
| Potencia de placa | 8 × 700 W | 5.600 W |
| Energía por token (placa) | 5.600 ÷ 2.800 | 2,0 J/token |
| Energía por token (con PUE 1,4) | 2,0 × 1,4 | 2,8 J/token |
| Energía por 1M tokens (placa) | 2 × 10⁶ J | 0,56 kWh |
| Energía por 1M tokens (con PUE) | 0,56 × 1,4 | 0,78 kWh |

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

| País | Coste eléctrico / 1M tok | Carbono / 1M tok |
|---|---|---|
| Francia (0,058 €/kWh; ~40 gCO₂/kWh) | ~0,045 € | ~31 gCO₂ |
| España (0,054 €/kWh; ~160 gCO₂/kWh) | ~0,042 € | ~125 gCO₂ |
| Alemania (0,091 €/kWh; ~363 gCO₂/kWh) | ~0,071 € | ~283 gCO₂ |

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:

> **Diagrama:** Capas de donde se obtiene el dato de energía: contadores de GPU NVML/DCGM, RAPL de CPU, eBPF con modelos, y vatímetro físico como referencia — [verlo en la versión HTML](https://blog.lo0.es/posts/benchmarking-energia-llm-frameworks-estado-del-arte/)

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](https://blog.lo0.es/posts/observabilidad-gpu-dcgm-llm/index.md)). **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](https://ml.energy/zeus/), [NSDI'23](https://www.usenix.org/system/files/nsdi23-you.pdf)).
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](https://medium.com/@prhmma/best-green-code-tools-july-2025-mainly-python-7ab415af0cd6)).
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](https://github.com/hubblo-org/scaphandre)). 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](https://github.com/sustainable-computing-io/kepler)).
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](https://arxiv.org/html/2410.12032v2)).
Es a la energía lo que MLPerf Inference es al rendimiento: el patrón de comparación entre
fabricantes.

### Tabla comparativa

| Herramienta | Método | Ámbito | Licencia | Precisión / nota |
|---|---|---|---|---|
| **Zeus** | NVML / contadores | GPU NV+AMD, CPU, DRAM, Apple, Jetson | OSS | mide **y optimiza** energía de DL |
| **CodeCarbon** | nvidia-smi + estimación | CPU+GPU+RAM, CO₂eq | OSS (Python) | el más **cercano al vatímetro** entre Python |
| **CarbonTracker** | runtime GPU | **solo GPU** | OSS | ligero; sin CPU/mem |
| **Scaphandre** | RAPL (/proc) | proceso/VM | OSS (Rust) | precisión cruda; sin contexto de carbono |
| **Kepler** | eBPF + modelo | contenedor/pod/nodo (K8s) | Apache 2.0 (CNCF) | cloud-native; estimación por modelo |
| **MLPerf Power** | medición estandarizada | de µW a MW | MLCommons | comparabilidad cross-vendor |

---

## 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](https://medium.com/@prhmma/best-green-code-tools-july-2025-mainly-python-7ab415af0cd6)).
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:

| Recurso | Qué aporta |
|---|---|
| **MLPerf Power** | medición estandarizada de eficiencia, de µW a MW |
| **HF AI Energy Score** | ratings comparables de eficiencia energética por modelo ([HF](https://huggingface.github.io/AIEnergyScore/)) |
| **ML.ENERGY Benchmark** | medición y optimización automatizada de energía de inferencia |
| **awesome-green-ai** | índice curado de recursos y herramientas Green AI ([repo](https://github.com/samuelrince/awesome-green-ai)) |

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:

| País | Mayorista (€/MWh, mar-2026) | Carbono red (gCO₂/kWh) | Perfil |
|---|---|---|---|
| **Francia** | ~58 | **~20–60** | nuclear: barata y muy limpia |
| **España** | ~54 | **~150–170** | renovable + gas: barata, carbono medio |
| **Alemania** | ~91 | **~363** (media 2024) | carbón/gas + renovables: cara y sucia |

Fuentes: precios mayoristas ([TradingEconomics](https://tradingeconomics.com/france/electricity-price)),
carbono de Alemania ~363 gCO₂/kWh (media 2024, [Wikipedia](https://en.wikipedia.org/wiki/Electricity_sector_in_Germany)),
nuclear ~17–35 gCO₂e/kWh ([EEA](https://www.eea.europa.eu/en/analysis/indicators/greenhouse-gas-emission-intensity-of-1)),
España ~167 gCO₂/kWh (2020). La intensidad horaria se obtiene de **ElectricityMaps**.

> **Diagrama:** Del vatio al carbono por país europeo: una misma energía por token se multiplica por la intensidad de red de Francia, España o Alemania dando carbono por token muy distinto — [verlo en la versión HTML](https://blog.lo0.es/posts/benchmarking-energia-llm-frameworks-estado-del-arte/)

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](https://blog.lo0.es/posts/eu-ai-act-mapeo-arquitectura-llm-on-premise/index.md),
[controles ENS × 42001 × EU AI Act](https://blog.lo0.es/posts/controles-tecnicos-ens-42001-eu-ai-act/index.md)).

---

## 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):

| Palanca | Mecanismo | Efecto |
|---|---|---|
| **Cuantización (FP8/INT4)** | más tokens por GPU-hora, menos VRAM/KV | sube throughput → baja J/token |
| **Batching / continuous batching** | amortiza el coste fijo de potencia | sube throughput → baja J/token |
| **Power capping** (Zeus) | limita la potencia de la GPU | baja W con poca pérdida de throughput |
| **Scheduling por eficiencia** | consolidar cargas, apagar GPU ociosa | elimina el consumo en idle |
| **Ubicación (país)** | red más limpia | baja el carbono por token |
| **Evitar el sobre-razonamiento** | menos tokens de razonamiento que no aportan | menos cómputo → menos energía |

La cuantización (ver [cuantización para inferencia](https://blog.lo0.es/posts/quantization-fundamentos-inferencia/index.md))
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:

| Momento | Herramienta | Qué da |
|---|---|---|
| **Diseño** | TDP × horas (datasheet) | estimación de techo para dimensionar |
| **Benchmark** | Zeus, MLPerf Power, vatímetro | energía por token medida en banco controlado |
| **Producción** | Kepler (eBPF), DCGM | consumo continuo por pod en el cluster |

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:

| Qué fijar | Por qué |
|---|---|
| Herramienta + versión | cada capa (RAPL, NVML, eBPF) y herramienta mide distinto |
| Frecuencia de muestreo | un muestreo grueso pierde picos |
| Frontera placa vs nodo | ±10–20 % según se incluya CPU/fuentes |
| PUE usado | multiplica toda la energía de cómputo |
| Fuente y hora de la intensidad de red | el carbono varía ~9× por país y por hora |
| Tratamiento del idle | atribuido o descontado cambia el J/token |
| Modelo, precisión y carga | la energía depende de qué y cómo se sirve |
| Calibración vs vatímetro | al menos una vez, para validar la estimación |

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](https://blog.lo0.es/posts/leaderboards-energia-llm/index.md) — 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](https://blog.lo0.es/posts/del-vatio-al-carbono-pue-grid/index.md) — 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](https://blog.lo0.es/posts/palancas-eficiencia-energetica-inferencia/index.md) — 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