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

Tue, 16 Jun 2026 04:00:00 +0200

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:

Los fundamentos de cuantización 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. 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:

$$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.

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

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

Ver también

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/

Ml-Energy on lo0 — Blog Técnico