---
title: "Leaderboards de energía de LLM: cómo comparar modelos por Wh/token y elegir por eficiencia"
url: https://blog.lo0.es/posts/leaderboards-energia-llm/
markdown: https://blog.lo0.es/posts/leaderboards-energia-llm/index.md
lang: es
date: 2026-06-16
lastmod: 2026-06-17
author: "José Manuel Román"
description: "Ficha técnica de los tres leaderboards OSS de eficiencia energética de LLMs: HF AI Energy Score (166 modelos, Wh/query, 1–5 estrellas sobre H100), ML.ENERGY Leaderboard v3 (J/token por tarea, Zeus como medidor), y MLPerf Power (samples/J certificado a la pared). Tabla comparativa de familias de modelos, efecto de la cuantización (hasta −79 % en energía con INT4) y tabla de decisión para elegir modelo por eficiencia."
tags: ["energia","leaderboards","ai-energy-score","ml-energy","eficiencia-energetica","wh-por-token","serie-datos"]
translations:
  en: https://blog.lo0.es/en/posts/llm-energy-leaderboards-wh-per-token/index.md
---

# Leaderboards de energía de LLM: cómo comparar modelos por Wh/token y elegir por eficiencia


> Notación: importes en **euros (N €)**, decimales con coma. No se usa el símbolo de dólar
> (en este sitio es delimitador de fórmula). Hardware de ejemplo genérico; sin infra real.

## TL;DR

Existen tres leaderboards OSS con datos públicos y metodología documentada para comparar la eficiencia energética de LLMs en inferencia: **Hugging Face AI Energy Score** (166 modelos, Wh/query sobre H100, escala de 1–5 estrellas, lanzado febrero 2025), **ML.ENERGY Leaderboard v3** (Universidad de Michigan, J/token por tarea, herramienta Zeus, diciembre 2025) y **MLPerf Power** (samples/joule certificado con vatímetro físico Yokogawa WT310E). Los tres miden dimensiones distintas y no son directamente intercambiables. Los datos disponibles muestran que los modelos razonadores consumen hasta **700× más energía** que sus equivalentes sin razonamiento; que los modelos MoE consumen aprox. **3× menos J/token** que un denso de parámetros activos equivalentes; y que la cuantización INT4 reduce el consumo hasta un **79 %** respecto a FP16 en condiciones favorables. El motor de inferencia (vLLM vs Transformers) puede mover el resultado otro **25–40 %**. Sin fijar hardware, motor, batch size y tarea, ninguna comparativa entre leaderboards es válida.

---

## Contexto del track

Este artículo es el **C5** del pilar de energía. El contexto base:

- [C1 — Estado del arte: benchmarking de energía de frameworks LLM](https://blog.lo0.es/posts/benchmarking-energia-llm-frameworks-estado-del-arte/index.md)
- [C2 — Energía por token: metodología](https://blog.lo0.es/posts/energia-por-token-metodologia/index.md)
- [C3 — Herramientas de medición en deploy](https://blog.lo0.es/posts/herramientas-energia-deploy-precision-overhead/index.md)
- [C4 — MLPerf Power](https://blog.lo0.es/posts/mlperf-power-eficiencia-energetica/index.md)

Los [fundamentos de cuantización](https://blog.lo0.es/posts/quantization-fundamentos-inferencia/index.md) son un requisito previo para la sección de cuantización de este artículo.

---

## Los tres leaderboards: ficha técnica

### 1 · Hugging Face AI Energy Score

| Campo | Detalle |
|---|---|
| **URL** | huggingface.co/AIEnergyScore · huggingface.co/spaces/AIEnergyScore/Leaderboard |
| **Organización** | Hugging Face (Sasha Luccioni et al.), con Salesforce y Cohere como socios iniciales |
| **Lanzamiento** | Febrero 2025 (AI Action Summit, París); v2 diciembre 2025 |
| **Modelos indexados** | 166 (v1 feb. 2025); +39 nuevos en v2 (dic. 2025) |
| **Tareas medidas** | 10 tareas: generación de texto, resumen, clasificación, generación de imagen, ASR, generación de audio, traducción, respuesta a preguntas, razonamiento (añadido en v2) |
| **Unidad de medición** | **Wh (vatio-hora) por cada 1.000 queries** de la tarea |
| **Hardware de referencia** | **NVIDIA H100** exclusivamente (GPU única para modelos clase A/B; múltiples para clase C) |
| **Herramienta de medición** | CodeCarbon (energía GPU) + paquete `ai-energy-benchmarks` (OSS, PyPI) |
| **Sistema de rating** | 1–5 estrellas por tarea: quintiles del rango de energía; ⭐⭐⭐⭐⭐ = 20 % más eficiente |
| **Batch size de referencia** | Batch size = 1 (no refleja producción con batching agresivo) |
| **Acceso a modelos propietarios** | Sí, vía contenedor Docker auditado |
| **Frecuencia de actualización** | Sin cadencia fija; v1 feb. 2025, v2 dic. 2025 |
| **Licencia del proyecto** | Apache 2.0 (repositorio github.com/huggingface/AIEnergyScore) |

**Alcance de la métrica.** El AI Energy Score mide exclusivamente la energía de la GPU (CodeCarbon); no captura CPU, DRAM ni overhead del sistema. La unidad Wh/1k-queries incluye todo el tiempo de ejecución (prefill + decode + overhead del framework), pero a batch = 1. Los resultados son, por tanto, comparables entre modelos bajo las mismas condiciones de test, pero no extrapolables a un entorno de producción con concurrencia real sin corrección.

**Clase de modelo** (clasificación interna del proyecto):

| Clase | Definición |
|---|---|
| A | Cabe en una GPU de consumidor (≤ ~24 GB VRAM) |
| B | Requiere una GPU de cloud (≥ 40 GB VRAM) |
| C | Requiere múltiples GPUs |

---

### 2 · ML.ENERGY Leaderboard

| Campo | Detalle |
|---|---|
| **URL** | ml.energy/leaderboard |
| **Organización** | Symbiotic Lab, Universidad de Michigan (Mosharaf Chowdhury, Jae-Won Chung et al.) |
| **Paper de referencia** | arXiv 2505.06371 — «The ML.ENERGY Benchmark: Toward Automated Inference Energy Measurement and Optimization» (NeurIPS 2025 D&B, Spotlight) |
| **Versión actual** | v3.0 (diciembre 2025) |
| **Herramienta de medición** | **Zeus** (github.com/ml-energy/zeus) vía NVML + RAPL; overhead de medición en single-digit ms |
| **Unidad de medición** | **J/token** (energía por token de salida generado) y energía total por respuesta completa |
| **Hardware de referencia** | NVIDIA A100 80 GB y H100 SXM (declarado por submission; varía entre modelos) |
| **Tareas medidas** | 6 tareas: chat (conversación texto), razonamiento, generación de código, resumen, preguntas sobre imagen, generación de vídeo |
| **Normalización** | Energía media por respuesta completa (prefill + decode). Se reporta también J/token de salida. Distingue explícitamente la tarea porque la longitud de salida la determina |
| **Alcance de la medición** | GPU vía NVML + CPU/DRAM vía RAPL; no es vatímetro a la pared |
| **Modelos cubiertos** | ~40 arquitecturas en la versión de NeurIPS 2025; leaderboard web actualizado con más |
| **Licencia** | Apache 2.0 (zeus: github.com/ml-energy/zeus); MIT (benchmark: github.com/ml-energy/benchmark) |
| **Frecuencia de actualización** | Continua en el leaderboard web; el paper es snapshot puntual |

**Zeus como herramienta.** Zeus es el motor de medición del ML.ENERGY Leaderboard y también un paquete independiente (`pip install zeus-ml`). Soporta NVIDIA GPU (NVML), AMD GPU (ROCm), CPU (RAPL), DRAM (RAPL), Apple Silicon y NVIDIA Jetson. El `ZeusMonitor` añade overhead de medición en single-digit milisegundos. Desde mayo 2025 es proyecto del ecosistema PyTorch. Licencia MIT.

---

### 3 · MLPerf Power

La ficha completa está en el [artículo C4](https://blog.lo0.es/posts/mlperf-power-eficiencia-energetica/index.md). Resumen de los puntos relevantes para comparar con los anteriores:

| Campo | Detalle |
|---|---|
| **URL** | mlcommons.org/benchmarks/inference-datacenter/ |
| **Organización** | MLCommons Power Working Group (>20 orgs) |
| **Unidad de medición** | **samples/joule** (throughput/potencia media) = inverso de J/sample |
| **Hardware** | Nodo completo medido a la pared (AC); analizador Yokogawa WT310E (±0,1 % de lectura) |
| **Tareas LLM** | GPT-J 6B, Llama 2 70B, Mixtral 8×7B (desde v5.0) |
| **Granularidad** | Nodo completo (GPU + CPU + RAM + fans + PSU losses); no atribuye por carga individual |
| **Overhead de nodo sobre GPU** | 25–45 % del consumo total en submissions con analizador físico |
| **Licencia del corpus** | Resultados públicos en GitHub (mlcommons/inference\_results\_vX.Y); PTDaemon requiere membresía MLCommons |

---

## Comparativa de los tres leaderboards

| Dimensión | HF AI Energy Score | ML.ENERGY Leaderboard | MLPerf Power |
|---|---|---|---|
| **Unidad** | Wh/1k-queries | J/token de salida | samples/J (nodo completo) |
| **Hardware fijo** | H100 (todos los modelos) | A100/H100 (varía) | Depende del submitter |
| **Medición** | CodeCarbon (GPU) | Zeus NVML+RAPL | Vatímetro físico AC (Yokogawa) |
| **Cobertura del sistema** | Solo GPU | GPU + CPU + DRAM | Nodo completo incluyendo fans y PSU |
| **Batch size** | 1 | Varía por tarea | Según escenario LoadGen |
| **Modelos cubiertos** | 166+ (texto, imagen, audio) | ~40 LLMs generativos | Pocos (GPT-J, Llama 2, Mixtral) |
| **Propietarios** | Sí (Docker auditado) | No (solo OSS) | Sí (miembros MLCommons) |
| **Certificación externa** | No | No | Sí (SPEC PTDaemon) |
| **Frecuencia** | Puntual (v1, v2) | Continua | Semestral (rondas MLPerf) |
| **Licencia** | Apache 2.0 | Apache 2.0 / MIT | Resultados públicos; PTDaemon: membresía |

**Incompatibilidad entre leaderboards.** Los tres miden dimensiones distintas: Wh/query ≠ J/token ≠ samples/J nodo. Una comparativa directa exige convertir unidades y asumir que el hardware, el motor y la tarea son equivalentes —lo que rara vez se cumple entre leaderboards—.

---

## Cómo se mide y normaliza la energía por token

La identidad base se desarrolla en el [artículo C2](https://blog.lo0.es/posts/energia-por-token-metodologia/index.md):

$$E_{\text{token}} \,[\text{J/tok}] = \frac{\bar{P} \,[\text{W}]}{\text{throughput} \,[\text{tok/s}]}$$

Para comparar modelos entre sí, todos los factores distintos del modelo deben estar fijos:

| Factor | Efecto si varía | Cómo fijarlo |
|---|---|---|
| **Hardware** | H100 vs A100 vs L40S cambia el resultado 2–4× | Declarar el hardware exacto; comparar solo dentro del mismo HW |
| **Motor de inferencia** | vLLM vs Transformers: 25–40 % de diferencia en J/token | Fijar el motor y la versión |
| **Batch size / concurrencia** | Batch 1 vs batch 32: el throughput sube pero la potencia también; el ratio varía | Declarar el batch size; comparar dentro del mismo régimen |
| **Precisión del modelo** | FP16 vs INT8 vs INT4: hasta −79 % de energía | Declarar la precisión; no mezclar |
| **Longitud de la respuesta** | Una query con 50 tokens ≠ una con 500 | Usar dataset fijo o normalizar por token |
| **Ventana de medición** | Incluir warm-up o idle infla el numerador | Alinear la ventana de potencia con la de tokens (ver C2) |

**Fórmula de conversión Wh/query ↔ J/token:**

$$E_{\text{J/tok}} = \frac{E_{\text{Wh/query}} \times 3600}{\bar{n}_{\text{tokens/query}}}$$

Ejemplo: si un modelo consume 0,05 Wh/query (= 180 J/query) y genera una media de 200 tokens por query:

$$E_{\text{J/tok}} = \frac{0{,}05 \times 3600}{200} = \frac{180}{200} = 0{,}9 \,\text{J/tok}$$

---

## Datos del AI Energy Score: ejemplos concretos

Los datos de v2 (diciembre 2025, hardware H100, batch = 1, tarea de generación de texto con razonamiento activado/desactivado):

| Modelo | Params activos | Razonamiento | GPU Wh/1k queries | Estrellas (text-gen) |
|---|---|---|---|---|
| DistilGPT-2 | 82 M | — | **1,31** | ⭐⭐⭐⭐⭐ |
| SmolLM3-3B | 3 B | Off | 18,35 | ⭐⭐⭐⭐ |
| SmolLM3-3B | 3 B | On | 12.791,22 | ⭐ |
| Phi-4-reasoning-plus | 15 B | Off | 18,42 | ⭐⭐⭐⭐ |
| Phi-4-reasoning-plus | 15 B | On | 9.461,61 | ⭐ |
| DeepSeek-R1-Distill-Llama-70B | 70 B | Off | 49,53 | ⭐⭐⭐ |
| DeepSeek-R1-Distill-Llama-70B | 70 B | On | 7.626,53 | ⭐ |

Fuente: Hugging Face AI Energy Score v2 (dic. 2025).

**Multiplicador del razonamiento.** El aumento de energía al activar el razonamiento va de ×154 (DeepSeek-R1-Distill-Llama-70B) a ×697 (SmolLM3-3B). La causa directa: los modelos razonadores generan entre 300 y 800 veces más tokens que sus equivalentes sin razonamiento (cadenas de pensamiento internas). La media del corpus v2 es ×30 de energía adicional por razonamiento.

**Nuevos modelos no son siempre más eficientes.** De los 14 modelos comparables (sin razonamiento, sin MoE, tamaño similar) entre la cohorte de feb. 2025 y dic. 2025: 8 de 14 tenían igual o mayor energía. El rango va desde el 3 % de la energía del modelo de referencia hasta casi 2×. La escala de parámetros ya no es suficiente para estimar la eficiencia.

---

## Datos del ML.ENERGY Leaderboard: J/token por familia

Los datos del paper arXiv 2505.06371 y del leaderboard v3 (hardware A100/H100, vLLM como motor de referencia):

**Escala dentro de una familia (Llama 3):**

| Tamaño | Params | J/token relativo (base = 1B) | Ratio params/energía |
|---|---|---|---|
| Llama 3 · 1B | 1 B | 1,0× | — |
| Llama 3 · 8B | 8 B | ~2,1× | 8× params → 2,1× energía |
| Llama 3 · 70B | 70 B | ~7,3× | 70× params → 7,3× energía |

La sublinealidad (70× params → 7,3× energía, no 70×) refleja que la energía en inferencia está dominada por el ancho de banda de memoria (memory-bandwidth bound), no por los FLOPs en bruto.

**Denso vs MoE:**

| Modelo | Tipo | Params totales | Params activos/token | J/token relativo |
|---|---|---|---|---|
| Llama 3 · 8B | Denso | 8 B | 8 B | 1,0× |
| Mixtral 8×7B | MoE (top-2) | 47 B | ~13 B | ~0,33× |
| Llama 3 · 70B | Denso | 70 B | 70 B | ~3,5× |

El MoE activa solo 2 de 8 expertos por token. Mixtral 8×7B consume aproximadamente ⅓ de los J/token de un modelo denso de 8B activos con calidad comparable a un modelo denso de mayor escala. El overhead de routing y de carga de todos los expertos en memoria contrarresta parte de la ganancia teórica.

**Efecto de la tarea (ML.ENERGY v3, mismo modelo):**

| Tarea | Multiplicador de energía por respuesta (vs chat) |
|---|---|
| Chat (conversación texto) | 1× (referencia) |
| Resumen | ~2–4× |
| Generación de código | ~3–6× |
| Razonamiento | **~25×** |
| Imagen + texto | 1,1–5,2× |
| Vídeo + texto | 1,3–15,0× |

El razonamiento usa ~10× más tokens por respuesta y la memoria adicional de la cadena de pensamiento reduce el batch size efectivo, aumentando la energía por token por presión de memoria.

---

## Efecto de la cuantización sobre la energía por token

Datos de hardware NVIDIA H100, Llama 3 familia (arXiv 2508.16712 y arXiv 2504.03360):

| Precisión | Reducción de energía vs FP16 | Condición |
|---|---|---|
| FP16 | referencia (0 %) | — |
| BF16 | ~0 % (iso-energía) | Mismo hardware y motor |
| FP8 | −25 a −35 % | H100/H200 con soporte hardware nativo |
| INT8 | −23 a −44 % (mediana ~39 %) | Depende del batch size; más a batches bajos |
| INT4 (AWQ / GPTQ) | −50 a −79 % | Requiere hardware con soporte de baja precisión eficiente |

**Advertencia.** En GPUs sin soporte hardware nativo de INT4 (o con kernels de dequantización subóptimos), la cuantización puede **aumentar** la latencia y la energía por token en vez de reducirla, debido al overhead de dequantización en tiempo de ejecución. El beneficio de la cuantización es real en H100/A100 con TensorRT-LLM o llama.cpp bien configurado, pero no garantizado con cualquier motor.

**Cuantización y throughput:** la reducción de memoria por modelo libera VRAM, lo que permite batch sizes mayores. A batch mayor, el throughput sube más que la potencia, reduciendo aún más el J/token. El efecto neto puede superar la reducción directa de energía por operación.

> **Diagrama:** Reduccion de J/token segun precision: FP16 referencia, FP8 menos 30 porciento, INT8 menos 40 porciento, INT4 menos 70 porciento, con advertencia de overhead de dequantizacion si el hardware no tiene soporte nativo — [verlo en la versión HTML](https://blog.lo0.es/posts/leaderboards-energia-llm/)

---

## Efecto del motor de inferencia

El motor es una variable que los leaderboards de nivel de modelo tienden a fijar pero que en producción es una decisión propia. Datos de comparativas publicadas (vLLM, TensorRT-LLM, Transformers Naive, A100):

| Motor | J/token relativo vs Transformers base |
|---|---|
| Transformers (naive, no optimizado) | 1,0× (referencia) |
| vLLM (PagedAttention, continuous batching) | −25 a −35 % |
| TensorRT-LLM (kernels NVIDIA optimizados, FP8) | −35 a −45 % |
| llama.cpp (CPU/GPU híbrido, INT4) | Variable; −30 a −60 % según hardware |

Cambiar de Transformers naive a TensorRT-LLM puede reducir la energía por token más que pasar de un modelo de 70B a uno de 8B del mismo origen. La elección del motor es una palanca de eficiencia energética de primer orden.

---

## Límites de los leaderboards de energía

| Límite | Descripción |
|---|---|
| **Hardware-dependencia** | Un ranking sobre H100 no es válido sobre A100 o L40S sin corrección. La jerarquía de modelos puede cambiar de hardware en hardware. |
| **Motor-dependencia** | Los resultados son válidos solo para el motor con que se midió. Un modelo ×2 más eficiente en el leaderboard puede quedar detrás si se usa un motor más lento. |
| **Batch size artificial** | AI Energy Score usa batch = 1. En producción con batching agresivo, la relación de eficiencia entre modelos grandes y pequeños cambia: los grandes escalan mejor con el batch. |
| **No captura entrenamiento** | Todos los leaderboards miden solo inferencia. El coste energético del entrenamiento (que puede superar 1.000× el de la inferencia durante la vida del modelo) está fuera del scope. |
| **Incompatibilidad entre leaderboards** | Wh/query, J/token y samples/J miden cosas distintas. Convertir entre ellas requiere conocer la longitud media de output, que varía por tarea y dataset. |
| **Cobertura parcial del sistema** | AI Energy Score y ML.ENERGY miden GPU (+CPU/DRAM con Zeus); no capturan el overhead del sistema completo (PSU losses, fans, interconexión). MLPerf Power sí lo hace, pero cubre pocos modelos. |
| **Latencia de datos** | Los leaderboards publican resultados meses después de los tests. Hardware nuevo (H200, B100, B200) puede no tener datos disponibles en el momento de la decisión. |
| **Ausencia de PUE** | Ninguno de los tres incluye el PUE del datacenter. Para el TCO real, el J/token del leaderboard debe multiplicarse por el PUE propio. |

---

## Tabla de decisión: elegir modelo por eficiencia energética

Los criterios de selección en orden, sin prosa de recomendación:

| Criterio | Pregunta | Acción |
|---|---|---|
| **Tarea con razonamiento** | ¿La tarea requiere razonamiento paso a paso? | Sí → multiplicar la energía base del modelo ×30–700 antes de comparar. Si hay alternativa sin razonamiento con calidad suficiente, preferirla. |
| **Tamaño vs calidad mínima** | ¿Cuál es la calidad mínima aceptable para la tarea? | Consultar benchmarks de calidad (ver [B7](https://blog.lo0.es/posts/benchmarks-de-calidad-llm/index.md) cuando disponible). Elegir el modelo más pequeño que supera el umbral de calidad; la energía crece sublinealmente con el tamaño. |
| **Denso vs MoE** | ¿El hardware tiene memoria suficiente para el MoE completo? | Si sí: el MoE activo-equivalente consume ~3× menos J/token que el denso equivalente. Si no: la paginación o el offload comen la ganancia. |
| **Precisión** | ¿El hardware tiene soporte nativo de FP8/INT4? | H100/H200: FP8 nativo (−30 %). Con TensorRT-LLM: INT4 AWQ (−50 a −79 %). Sin soporte nativo: mantener FP16 o BF16 hasta validar con benchmark propio. |
| **Motor de inferencia** | ¿Se está usando el motor óptimo para el hardware? | Medir con [C3](https://blog.lo0.es/posts/herramientas-energia-deploy-precision-overhead/index.md). Si el motor no está optimizado, el cambio de motor puede reducir más la energía que el cambio de modelo. |
| **Consultar leaderboard** | ¿La tarea está cubierta por AI Energy Score o ML.ENERGY? | Filtrar por: misma tarea, misma clase de hardware, razonamiento off/on explícito. No comparar modelos de distinta clase de hardware ni distinto motor. |
| **Validar en hardware propio** | ¿Los resultados del leaderboard son sobre el mismo HW que el propio? | Siempre validar con Zeus o DCGM en el hardware propio antes de tomar la decisión final. El leaderboard es referencia, no predicción. |

**Tabla de señales rápidas:**

| Señal | Efecto en energía | Fuente del dato |
|---|---|---|
| Activar razonamiento | ×30–700 | AI Energy Score v2 |
| Pasar de 8B denso a 70B denso | ~×3,5 | ML.ENERGY Leaderboard v3 |
| Pasar de denso 8B a MoE activo-equiv. 8B | ~×0,33 (−67 %) | ML.ENERGY v3 |
| FP16 → INT4 (hardware compatible) | −50 a −79 % | arXiv 2508.16712, 2504.03360 |
| Transformers naive → TensorRT-LLM FP8 | −35 a −45 % | TokenPowerBench, ML.ENERGY |
| PUE 1,0 → PUE 1,5 | +50 % en energía real del datacenter | MLPerf Power (scope) |

---

## Datos de referencia: energía en un nodo genérico (4×H100 SXM)

Hardware de ejemplo genérico para anclar los valores de leaderboard a un nodo real:

| Parámetro | Valor orientativo |
|---|---|
| TDP 4×H100 SXM 80 GB | 4 × 700 W = 2.800 W (solo GPU) |
| System power nodo completo (pared) | ~3.500–5.000 W según carga |
| Overhead no-GPU sobre GPU | 25–45 % |
| J/token Llama 3 70B FP16, vLLM, batch 8 | ~1–3 J/tok (orientativo, A100/H100) |
| J/token Llama 3 8B FP16, vLLM, batch 8 | ~0,3–0,7 J/tok (orientativo) |
| J/token Mixtral 8×7B FP16, vLLM, batch 8 | ~0,4–0,8 J/tok (orientativo) |
| Energía por 1M tokens (Llama 3 70B, PUE 1,4) | ~0,5–1,2 kWh |

Los valores J/token son orientativos y dependen fuertemente del batch size, longitud del prompt, ratio prefill/decode y versión del motor. Para valores certificados, consultar las submissions de MLPerf Power ([mlcommons.org](https://mlcommons.org/benchmarks/inference-datacenter/)).

Para el nodo de referencia alternativo (4×A100 PCIe 80 GB, TDP ~300 W c/u):

| Parámetro | Valor orientativo |
|---|---|
| TDP 4×A100 PCIe | 4 × 300 W = 1.200 W (solo GPU) |
| System power nodo completo | ~1.500–2.000 W |
| J/token Llama 3 70B FP16, vLLM | ~2–5 J/tok (orientativo; mayor por menor bandwidth HBM vs SXM) |

---

## Cómo usar los leaderboards en la práctica

Flujo de decisión basado en datos públicos disponibles:

| Paso | Acción | Recurso |
|---|---|---|
| 1 | Identificar la tarea dominante del workload | — |
| 2 | Consultar AI Energy Score filtrado por tarea y clase de hardware | huggingface.co/spaces/AIEnergyScore/Leaderboard |
| 3 | Anotar los modelos con ⭐⭐⭐⭐ o ⭐⭐⭐⭐⭐ en la tarea | Wh/1k-queries como referencia relativa |
| 4 | Cruzar con ML.ENERGY para el J/token de cada candidato | ml.energy/leaderboard |
| 5 | Si algún modelo está en MLPerf Power (Llama 2, GPT-J, Mixtral), consultar samples/J certificado | mlcommons.org/benchmarks/inference-datacenter/ |
| 6 | Seleccionar los 2–3 candidatos con mejor ratio energía/calidad | — |
| 7 | Medir en el hardware propio con Zeus o DCGM | github.com/ml-energy/zeus |
| 8 | Multiplicar el J/token medido por el PUE del datacenter | J/token × PUE = J/token efectivo en el datacenter |
| 9 | Calcular el coste eléctrico por token con el precio contratado | Ver [C2](https://blog.lo0.es/posts/energia-por-token-metodologia/index.md) |

---

## Ver también

- [C1 — Benchmarking de energía de frameworks LLM: estado del arte](https://blog.lo0.es/posts/benchmarking-energia-llm-frameworks-estado-del-arte/index.md)
- [C2 — Energía por token: metodología y mercado eléctrico](https://blog.lo0.es/posts/energia-por-token-metodologia/index.md)
- [C3 — Herramientas de medición en deploy: precisión y overhead](https://blog.lo0.es/posts/herramientas-energia-deploy-precision-overhead/index.md)
- [C4 — MLPerf Power: el benchmark estándar certificado](https://blog.lo0.es/posts/mlperf-power-eficiencia-energetica/index.md)
- [Fundamentos de cuantización para inferencia](https://blog.lo0.es/posts/quantization-fundamentos-inferencia/index.md)

---

## Fuentes

- Hugging Face · AI Energy Score · organización y leaderboard — https://huggingface.co/AIEnergyScore
- Hugging Face · Announcing AI Energy Score Ratings (Luccioni et al., feb. 2025) — https://huggingface.co/blog/sasha/announcing-ai-energy-score
- Hugging Face · AI Energy Score v2: Refreshed Leaderboard, now with Reasoning (Luccioni, Gamazaychikov, dic. 2025) — https://huggingface.co/blog/sasha/ai-energy-score-v2
- Hugging Face · AIEnergyScore GitHub (Apache 2.0) — https://github.com/huggingface/AIEnergyScore
- ML.ENERGY Initiative · Leaderboard — https://ml.energy/leaderboard
- ML.ENERGY Initiative · Blog: Diagnosing Inference Energy Consumption with the ML.ENERGY Leaderboard v3.0 (dic. 2025) — https://ml.energy/blog/measurement/energy/diagnosing-inference-energy-consumption-with-the-mlenergy-leaderboard-v30/
- arXiv 2505.06371 · The ML.ENERGY Benchmark: Toward Automated Inference Energy Measurement and Optimization (Chung et al., NeurIPS 2025 D&B Spotlight) — https://arxiv.org/abs/2505.06371
- ML.ENERGY Initiative · Zeus: Deep Learning Energy Measurement and Optimization — https://ml.energy/zeus/
- GitHub ml-energy/zeus (MIT) — https://github.com/ml-energy/zeus
- PyTorch Blog · Zeus: Deep Learning Energy Measurement and Optimization — https://pytorch.org/blog/zeus/
- University of Michigan CSE · Power-hungry AI: Researchers evaluate energy consumption across models — https://cse.engin.umich.edu/stories/power-hungry-ai-researchers-evaluate-energy-consumption-across-models
- arXiv 2512.03024 · TokenPowerBench: Benchmarking the Power Consumption of LLM Inference (dic. 2024) — https://arxiv.org/abs/2512.03024
- arXiv 2508.16712 · Systematic Characterization of LLM Quantization: A Performance, Energy, and Quality Perspective — https://arxiv.org/abs/2508.16712
- arXiv 2504.03360 · Sustainable LLM Inference for Edge AI: Evaluating Quantized LLMs for Energy Efficiency, Output Accuracy, and Inference Latency — https://arxiv.org/abs/2504.03360
- Epoch AI · AI Energy Use: Data & Research — https://epoch.ai/topics/energy
- MLCommons · MLPerf Inference Datacenter benchmark results — https://mlcommons.org/benchmarks/inference-datacenter/
- arXiv 2410.12032 · MLPerf Power: Benchmarking the Energy Efficiency of Machine Learning Systems (Tschand et al., 2024) — https://arxiv.org/abs/2410.12032
- Coalition for Sustainable AI · AI Energy Score as best practice in benchmarking — https://www.sustainableaicoalition.org/ai-energy-score-a-standardized-approach-to-evaluating-ai-model-energy-efficiency/