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:

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

CampoDetalle
URLhuggingface.co/AIEnergyScore · huggingface.co/spaces/AIEnergyScore/Leaderboard
OrganizaciónHugging Face (Sasha Luccioni et al.), con Salesforce y Cohere como socios iniciales
LanzamientoFebrero 2025 (AI Action Summit, París); v2 diciembre 2025
Modelos indexados166 (v1 feb. 2025); +39 nuevos en v2 (dic. 2025)
Tareas medidas10 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ónWh (vatio-hora) por cada 1.000 queries de la tarea
Hardware de referenciaNVIDIA H100 exclusivamente (GPU única para modelos clase A/B; múltiples para clase C)
Herramienta de mediciónCodeCarbon (energía GPU) + paquete ai-energy-benchmarks (OSS, PyPI)
Sistema de rating1–5 estrellas por tarea: quintiles del rango de energía; ⭐⭐⭐⭐⭐ = 20 % más eficiente
Batch size de referenciaBatch size = 1 (no refleja producción con batching agresivo)
Acceso a modelos propietariosSí, vía contenedor Docker auditado
Frecuencia de actualizaciónSin cadencia fija; v1 feb. 2025, v2 dic. 2025
Licencia del proyectoApache 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):

ClaseDefinición
ACabe en una GPU de consumidor (≤ ~24 GB VRAM)
BRequiere una GPU de cloud (≥ 40 GB VRAM)
CRequiere múltiples GPUs

2 · ML.ENERGY Leaderboard

CampoDetalle
URLml.energy/leaderboard
OrganizaciónSymbiotic Lab, Universidad de Michigan (Mosharaf Chowdhury, Jae-Won Chung et al.)
Paper de referenciaarXiv 2505.06371 — «The ML.ENERGY Benchmark: Toward Automated Inference Energy Measurement and Optimization» (NeurIPS 2025 D&B, Spotlight)
Versión actualv3.0 (diciembre 2025)
Herramienta de mediciónZeus (github.com/ml-energy/zeus) vía NVML + RAPL; overhead de medición en single-digit ms
Unidad de mediciónJ/token (energía por token de salida generado) y energía total por respuesta completa
Hardware de referenciaNVIDIA A100 80 GB y H100 SXM (declarado por submission; varía entre modelos)
Tareas medidas6 tareas: chat (conversación texto), razonamiento, generación de código, resumen, preguntas sobre imagen, generación de vídeo
NormalizaciónEnergí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ónGPU 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
LicenciaApache 2.0 (zeus: github.com/ml-energy/zeus); MIT (benchmark: github.com/ml-energy/benchmark)
Frecuencia de actualizaciónContinua 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:

CampoDetalle
URLmlcommons.org/benchmarks/inference-datacenter/
OrganizaciónMLCommons Power Working Group (>20 orgs)
Unidad de mediciónsamples/joule (throughput/potencia media) = inverso de J/sample
HardwareNodo completo medido a la pared (AC); analizador Yokogawa WT310E (±0,1 % de lectura)
Tareas LLMGPT-J 6B, Llama 2 70B, Mixtral 8×7B (desde v5.0)
GranularidadNodo completo (GPU + CPU + RAM + fans + PSU losses); no atribuye por carga individual
Overhead de nodo sobre GPU25–45 % del consumo total en submissions con analizador físico
Licencia del corpusResultados públicos en GitHub (mlcommons/inference_results_vX.Y); PTDaemon requiere membresía MLCommons

Comparativa de los tres leaderboards

DimensiónHF AI Energy ScoreML.ENERGY LeaderboardMLPerf Power
UnidadWh/1k-queriesJ/token de salidasamples/J (nodo completo)
Hardware fijoH100 (todos los modelos)A100/H100 (varía)Depende del submitter
MediciónCodeCarbon (GPU)Zeus NVML+RAPLVatímetro físico AC (Yokogawa)
Cobertura del sistemaSolo GPUGPU + CPU + DRAMNodo completo incluyendo fans y PSU
Batch size1Varía por tareaSegún escenario LoadGen
Modelos cubiertos166+ (texto, imagen, audio)~40 LLMs generativosPocos (GPT-J, Llama 2, Mixtral)
PropietariosSí (Docker auditado)No (solo OSS)Sí (miembros MLCommons)
Certificación externaNoNoSí (SPEC PTDaemon)
FrecuenciaPuntual (v1, v2)ContinuaSemestral (rondas MLPerf)
LicenciaApache 2.0Apache 2.0 / MITResultados 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:

FactorEfecto si varíaCómo fijarlo
HardwareH100 vs A100 vs L40S cambia el resultado 2–4×Declarar el hardware exacto; comparar solo dentro del mismo HW
Motor de inferenciavLLM vs Transformers: 25–40 % de diferencia en J/tokenFijar el motor y la versión
Batch size / concurrenciaBatch 1 vs batch 32: el throughput sube pero la potencia también; el ratio varíaDeclarar el batch size; comparar dentro del mismo régimen
Precisión del modeloFP16 vs INT8 vs INT4: hasta −79 % de energíaDeclarar la precisión; no mezclar
Longitud de la respuestaUna query con 50 tokens ≠ una con 500Usar dataset fijo o normalizar por token
Ventana de mediciónIncluir warm-up o idle infla el numeradorAlinear 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):

ModeloParams activosRazonamientoGPU Wh/1k queriesEstrellas (text-gen)
DistilGPT-282 M1,31⭐⭐⭐⭐⭐
SmolLM3-3B3 BOff18,35⭐⭐⭐⭐
SmolLM3-3B3 BOn12.791,22
Phi-4-reasoning-plus15 BOff18,42⭐⭐⭐⭐
Phi-4-reasoning-plus15 BOn9.461,61
DeepSeek-R1-Distill-Llama-70B70 BOff49,53⭐⭐⭐
DeepSeek-R1-Distill-Llama-70B70 BOn7.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ñoParamsJ/token relativo (base = 1B)Ratio params/energía
Llama 3 · 1B1 B1,0×
Llama 3 · 8B8 B~2,1×8× params → 2,1× energía
Llama 3 · 70B70 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:

ModeloTipoParams totalesParams activos/tokenJ/token relativo
Llama 3 · 8BDenso8 B8 B1,0×
Mixtral 8×7BMoE (top-2)47 B~13 B~0,33×
Llama 3 · 70BDenso70 B70 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):

TareaMultiplicador 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 + texto1,1–5,2×
Vídeo + texto1,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ónReducción de energía vs FP16Condición
FP16referencia (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.

J/token relativoFP16100 %FP8~70 %INT8~61 %INT4~30 %Hardware: H100 SXM con soporte nativo. Sin soporte nativo, INT4 puede ser iso-energético o peor que FP16.

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

MotorJ/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ímiteDescripción
Hardware-dependenciaUn 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-dependenciaLos 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 artificialAI 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 entrenamientoTodos 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 leaderboardsWh/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 sistemaAI 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 datosLos 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 PUENinguno 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:

CriterioPreguntaAcció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ñalEfecto en energíaFuente del dato
Activar razonamiento×30–700AI Energy Score v2
Pasar de 8B denso a 70B denso~×3,5ML.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 datacenterMLPerf 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ámetroValor orientativo
TDP 4×H100 SXM 80 GB4 × 700 W = 2.800 W (solo GPU)
System power nodo completo (pared)~3.500–5.000 W según carga
Overhead no-GPU sobre GPU25–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ámetroValor orientativo
TDP 4×A100 PCIe4 × 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:

PasoAcciónRecurso
1Identificar la tarea dominante del workload
2Consultar AI Energy Score filtrado por tarea y clase de hardwarehuggingface.co/spaces/AIEnergyScore/Leaderboard
3Anotar los modelos con ⭐⭐⭐⭐ o ⭐⭐⭐⭐⭐ en la tareaWh/1k-queries como referencia relativa
4Cruzar con ML.ENERGY para el J/token de cada candidatoml.energy/leaderboard
5Si algún modelo está en MLPerf Power (Llama 2, GPT-J, Mixtral), consultar samples/J certificadomlcommons.org/benchmarks/inference-datacenter/
6Seleccionar los 2–3 candidatos con mejor ratio energía/calidad
7Medir en el hardware propio con Zeus o DCGMgithub.com/ml-energy/zeus
8Multiplicar el J/token medido por el PUE del datacenterJ/token × PUE = J/token efectivo en el datacenter
9Calcular el coste eléctrico por token con el precio contratadoVer C2

Ver también


Fuentes