Eficiencia-Energetica on lo0 — Blog Técnico

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/

MLPerf Power: el benchmark estándar de eficiencia energética para sistemas ML on-premise

Mon, 15 Jun 2026 06: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).

TL;DR

MLPerf Power es el único benchmark estandarizado para medir la eficiencia energética de sistemas ML completos, gestionado por el MLCommons Power Working Group y respaldado por más de 20 organizaciones. Mide potencia a la pared (AC wall power) de todo el System Under Test —GPUs, CPUs, memoria, interconexión, ventiladores— con un analizador de potencia certificado SPEC PTDaemon (Yokogawa WT310/WT5000) y las herramientas públicas de mlcommons/power-dev. La métrica central para inferencia en datacenter es samples/joule (o tokens/joule para LLMs); para latencia, energía por stream. El corpus público acumula 1.841 mediciones reproducibles de 60 sistemas (590 datacenter, 792 edge, 447 tiny, 12 training). GPT-J y Llama 2 muestran mejoras de más de 100× en samples/joule entre las primeras y últimas rondas disponibles. La comparación directa con la medición por software del post C3 (DCGM/NVML/RAPL/Kepler) revela que MLPerf Power ofrece máxima precisión y reproducibilidad al coste de hardware dedicado (~3.000 USD el Yokogawa 310E) y de la obligatoriedad de ser miembro de MLCommons para acceder a PTDaemon; la medición por software es continua, sin hardware extra, pero con barra de error mayor y sin validación externa.

Qué es MLPerf Power y cómo encaja en el ecosistema MLCommons

MLCommons es el consorcio de más de 100 organizaciones (NVIDIA, Google, Intel, Dell, AMD, Meta…) que mantiene los benchmarks MLPerf: Training, Inference (Datacenter y Edge), Tiny, HPC, Storage, Client y Automotive. El Power Working Group es el grupo específico que extiende cada uno de esos benchmarks añadiendo la dimensión energética (MLCommons Power Working Group).

MLPerf Power no es un benchmark independiente: es una capa de medición energética que se superpone a los benchmarks de rendimiento existentes. Para que una submission sea válida con power, debe cumplir primero las reglas de rendimiento (MLPerf Inference, Training o Tiny) y además las reglas adicionales de medición de potencia.

Acoplamiento con MLPerf Inference

La integración más relevante para inferencia on-premise es con MLPerf Inference Datacenter, que define:

Scenarios: Server (latencia, queries por segundo con cola de peticiones) y Offline (throughput puro, batch sin restricción de latencia). Power se mide en ambos.
Benchmarks: ResNet-50, BERT, RNN-T, 3D-UNET, RetinaNet, DLRM, GPT-J 6B, Llama 2 70B (desde v4.0), Mixtral 8×7B (desde v5.0).
Divisions: closed (modelo y preprocesado fijados, solo se permite optimizar el runtime) y open (modificaciones permitidas al modelo).

Power se mide durante la fase de performance, no durante la de accuracy ni compliance. El mismo run que genera el performance log genera el power log: está prohibido reportar el rendimiento más alto de tres runs y la potencia más baja de otros tres (MLPerf Inference Power Measurement Rules, §5.9).

Acoplamiento con MLPerf Training y Tiny

MLPerf Training: la medición de potencia a gran escala (multi-nodo, 10K+ GPUs) no usa analizador externo —es impracticable—. En su lugar se usa telemetría de nodo (IPMI/Redfish) + estimación de la red de interconexión. La métrica es energía para entrenar (J o kWh). En las submissions de v4.0 con power, los sistemas con Llama 2 70B Training van de nodos individuales hasta cientos, revelando el escalado no lineal de la energía (arXiv 2410.12032).
MLPerf Tiny: sistemas microcontrolador (desde 5,64 mW). Se usa instrumentación de micro-potencia especializada con pines hardware para demarcar el inicio y fin de la inferencia. La métrica es energía por inferencia (J), no samples/joule.

Metodología de medición: wall power certificada

El principio fundamental: todo el SUT, a la pared

La regla número uno es absoluta: la potencia debe medirse a nivel de sistema, es decir, incluyendo todos los componentes que el benchmark activa: procesadores host, aceleradores, memoria, discos, ventiladores, interconexión interna. No basta con medir solo las GPUs (MLPerf Inference Power Measurement Rules, §5.1):

“The power consumption must be measured at the system level, i.e. including all components that are sensitized by LoadGen e.g. the host processor on which LoadGen runs, accelerators, memory, fans, etc.”

La potencia se mide en AC (corriente alterna), a la entrada del SUT, antes de los PSUs. Está prohibida cualquier batería o almacenamiento de energía entre la toma de corriente y los PSUs del sistema.

Hardware de medición: analizador de potencia certificado SPEC

MLPerf Power exige un analizador de potencia certificado por SPEC PTDaemon (lista oficial SPEC). El más extendido en las submissions es el Yokogawa WT310E (~3.000 USD), que conecta al director vía USB (Linux) o Ethernet/serial (Windows). El voltaje se mide en paralelo y la corriente en serie con la línea de alimentación del SUT.

Especificaciones relevantes del Yokogawa WT310E:

Precisión de potencia: 0,1 % de lectura + 0,1 % del rango
Rango de medición: µW a MW (el WT5000 llega a instalaciones industriales)
Actualización: desde 50 ms

Para sistemas de más de un canal o nodos multi-PSU, se permiten configuraciones multi-analizador. La regla de ranging: primero se hace una ranging run con rango en modo Auto para determinar los valores máximos de corriente y voltaje; los runs de testing usan rangos fijos basados en esos picos, lo que maximiza la precisión dentro del rango. El modo Auto no está permitido en los runs de testing.

SPEC PTDaemon: el daemon que orquesta la medición

PTDaemon (Power Thermal Daemon) es la herramienta de SPEC que gestiona la comunicación con el analizador. MLCommons tiene licencia para usarlo dentro del flujo MLPerf Power. El acceso requiere ser miembro de MLCommons y firmar el EULA correspondiente (MLPerf Power FAQ).

El flujo de medición es el siguiente:

El proceso paso a paso (mlcommons/power-dev):

NTP sync entre Director y SUT para alinear timestamps.
Ranging run: potencia con rangos en Auto; el analizador determina los picos de corriente y voltaje.
Testing run: rangos fijos; LoadGen ejecuta el benchmark; Director registra potencia con timestamps; SUT registra performance log con timestamps de inicio/fin de la fase de ejecución.
Post-proceso: el resultado summarizer cruza power log y performance log por timestamps para calcular la potencia media en la ventana de ejecución.
Mínimo de 60 segundos de datos de potencia válidos. Si el workload termina antes de 60 s, se ejecuta en bucle hasta alcanzar ese umbral.

Qué entra y qué no entra en el SUT

El SUT incluye todo lo que el benchmark activa:

Dentro del SUT	Fuera del SUT
GPUs / aceleradores	PDU compartido con otros sistemas
CPU host y memoria RAM	Infraestructura de cooling del datacenter (PUE)
Discos / NVMe si el benchmark los usa	Red de gestión (BMC, fuera de banda)
Ventiladores y sistemas de refrigeración del nodo	Switches de red del datacenter (no del nodo)
Interconexión interna (NVLink, PCIe)
PSUs del nodo

El paper lo deja explícito: PUE está fuera del scope de MLPerf Power por diseño (arXiv 2410.12032, §III-C). MLPerf mide la eficiencia del sistema ML, no la del datacenter. Incluir PUE oscurecería las diferencias entre sistemas al mezclar la eficiencia del hardware con la del edificio.

Métricas: fórmulas y definiciones

Throughput benchmarks (Datacenter / Offline / Edge)

Para benchmarks de throughput —Offline y Server en datacenter, y algunos escenarios edge— la métrica de eficiencia energética es:

$$\eta = \frac{\text{throughput (samples/s)}}{\text{potencia media (W)}} \quad \Rightarrow \quad \left[\frac{\text{samples}}{\text{J}}\right]$$

donde la potencia media se calcula sobre la ventana de la fase de ejecución del run de performance. El reciproco da la energía por sample:

$$E_{\text{sample}} = \frac{\text{potencia media (W)}}{\text{throughput (samples/s)}} \quad \left[\text{J/sample}\right]$$

Para benchmarks LLM (GPT-J, Llama 2), donde la salida es variable en longitud, “sample” equivale a una query completa (prompt + respuesta). La energía por token de salida se obtiene dividiendo por el número de tokens generados, que varía por query y debe reportarse o estimarse.

Latency benchmarks (Single Stream / Tiny)

Para benchmarks de latencia —Single Stream en edge y tiny— donde se fija el tiempo de procesamiento, la métrica es la inversa de la energía por inferencia:

$$\eta_{\text{latency}} = \frac{1}{E_{\text{inference}}} \quad \left[\frac{1}{\text{J}}\right]$$

El paper trata ambas métricas (samples/J y 1/J) como comparables dentro de su categoría, aunque no son intercambiables entre categorías.

Potencia del sistema y energía del run

Las tres magnitudes que aparecen en toda submission de power:

Magnitud	Definición	Unidad
System power	media de las muestras de potencia AC en la ventana de ejecución	W
Energía del run	potencia media × duración de la ventana	J
Eficiencia energética	throughput / system power = samples/J	samples/J

La fórmula de la energía del run:

$$E_{\text{run}} = \bar{P} \times \Delta t = \frac{\sum_{i} P_i \cdot \Delta t_i}{\Delta t_{\text{total}}} \times \Delta t_{\text{total}} \quad [\text{J}]$$

donde ( P_i ) son las muestras del analizador y ( \Delta t_i ) los intervalos entre muestras, ambos dentro de la ventana demarcada por los timestamps de LoadGen.

Cómo leer una submission de MLPerf Power

Divisions y categorías de disponibilidad

Las submissions heredan las divisiones de MLPerf Inference:

División	Restricciones	Comparabilidad
Closed	Modelo fijo, preprocesado fijo, solo se optimiza el runtime y el hardware	Alta: submissions directamente comparables entre sí
Open	Modificaciones al modelo permitidas (cuantización agresiva, destilación, poda)	Baja: cada sistema puede usar un modelo distinto

Dentro de closed, hay categorías de disponibilidad del sistema:

Categoría	Definición
Available	Sistema comercialmente disponible en la fecha de cierre
Preview	Anunciado pero no disponible comercialmente
RDI (Research, Development, Internal)	Sistemas de uso interno o experimental

Solo los sistemas Available en closed son comparables sin restricciones. Un sistema Preview con mejor energía que uno Available de otra empresa no es una comparativa válida para decisiones de compra.

Qué comparabilidad da MLPerf Power y qué no

Da:

Comparación objetiva de la eficiencia energética de nodos completos (no solo GPU) bajo un workload ML estandarizado.
Reproducibilidad verificada: los logs se publican en GitHub y cualquiera puede revisarlos.
Tendencias temporales entre rondas: cuánto mejora la eficiencia de cada familia de hardware versión a versión.
Base para comparar sistemas heterogéneos que realizan el mismo workload bajo las mismas reglas.

No da:

Comparación GPU-a-GPU aislada (mide el nodo completo, no la tarjeta sola).
Cobertura amplia de hardware: el número de submissions con power es pequeño. En v4.0 solo cuatro empresas (Dell, Fujitsu, NVIDIA, Qualcomm) entregaron power numbers para datacenter. En v5.1 hubo dos power submissions (Lenovo datacenter + GATEOverflow edge).
Representatividad de workloads propios: los benchmarks son fijos y pueden no coincidir con la distribución de tu carga real (batch size, longitud de prompt, ratio prefill/decode).
Datos de cooling de datacenter: PUE, líquido vs aire, están fuera del scope.
Tiempo real de comparación: los resultados se publican meses después del cierre.

Estructura de una submission

Cada submission de power publica en el repositorio de resultados de MLCommons:

<division>/<submitter>/measurements/<system>/
├── analyzer_table.md # Configuración del analizador (modelo, rangos)
├── power_settings.md # Configuración de gestión de energía del SUT
results/<system>/<benchmark>/<scenario>/
├── mlperf_log_summary.txt # Resultados de rendimiento (LoadGen)
├── spl.txt # Power log (potencia, corriente, voltaje, timestamps)
└── ...

Los ficheros spl.txt contienen las lecturas brutas del analizador con timestamps, lo que permite verificar la alineación con la ventana de LoadGen.

Datos: escala, trends y hardware de referencia

El corpus: 1.841 mediciones de 60 sistemas

La base de datos de submissions de MLPerf Power cubre (arXiv 2410.12032):

Categoría	Submissions	Rango de potencia
Datacenter (Inference)	590	~200 W – ~10 kW por nodo
Edge (Inference)	792	~10 W – varios kW
Tiny (Inference)	447	5,64 mW – centenares de mW
Training / HPC	12	hasta 500 kW (medido); ~10 MW estimado en HPC

El rango total va de microwatts a megawatts —9 órdenes de magnitud— lo que hace que no exista una metodología única aplicable a todos los segmentos.

Mejoras en eficiencia energética: LLMs lideran

La evolución de la métrica samples/joule entre rondas, normalizada a la primera submission de cada modelo (arXiv 2410.12032, §V-A):

Workload	Categoría	Mejora acumulada (samples/J)
GPT-J 6B	Datacenter	>100×
Llama 2 70B	Datacenter	>100×
RetinaNet	Datacenter	Mayor entre los modelos clásicos
BERT-99.0	Edge	~4×
RNN-T	Edge	~4×
ResNet-50	Edge	~1,5×
ResNet-50	Tiny	>1.000×
Otros Tiny	Tiny	79× – 596×

Las mejoras de >100× en LLMs de datacenter reflejan la atención industrial masiva en optimización de software (kernels FP8, FlashAttention, especulación) y hardware (arquitecturas tensor core, HBM3). Los modelos Tiny muestran ganancias aún mayores en términos relativos gracias al punto de partida bajo y al avance en chips especializados.

Hardware de referencia on-premise

Para un nodo de 4×H100 SXM 80 GB (el hardware genérico del track), los valores típicos en MLPerf Power:

Parámetro	Valor orientativo
TDP declarado 4×H100 SXM	4 × 700 W = 2.800 W (solo GPU)
System power (nodo completo) medido a la pared	~3.500 – 5.000 W según carga
Overhead CPU + RAM + fans sobre GPU	25 – 45 % del total
Eficiencia: Llama 2 70B offline (closed)	función del runtime; orden de magnitud ~0,1 – 1 tokens/J

El punto clave: el “overhead de nodo” —la diferencia entre lo que mide el analizador a la pared y lo que reporta NVML para las GPUs— es de un 25–45 % del consumo total. Una medición solo de GPU subestima el consumo real del sistema en ese margen.

Para el A100 PCIe 80 GB (4× por nodo), el consumo de sistema es menor (TDP GPU ~300 W c/u, nodo ~1.500–2.000 W), con mayor eficiencia por vatio pero menor throughput absoluto. El L40S (4× por nodo) tiene un perfil intermedio: TDP ~350 W c/u, buen rendimiento en inferencia FP8, consumo de nodo ~1.800–2.500 W.

Contraste con la medición por software del post C3

El post C3 de este track cubre el stack DCGM/NVML/RAPL/Kepler en producción. Aquí la comparativa data-driven frente a MLPerf Power:

Dimensión	Software (DCGM/NVML/RAPL/Kepler)	MLPerf Power (analizador + PTDaemon)
Qué mide	Sensores on-device (GPU, CPU, DRAM)	AC wall power (todo el nodo)
Cobertura	GPU + CPU + DRAM (≠ pared)	Nodo completo incluyendo fans, PSU overhead
Overhead de nodo	No capturado por defecto	Incluido en la medición
Precisión	±5–15 % vs vatímetro (estimación Kepler); NVML ~3–5 % de la GPU	±0,1 % lectura + ±0,1 % rango (Yokogawa WT310E)
Frecuencia / continuidad	Continua en producción (sub-segundo)	Solo durante el run de benchmark
Hardware extra	Ninguno (usa sensores del sistema)	Analizador certificado SPEC (~3.000 USD)
Atribución por carga	Por pod/MIG con Kepler	No: mide el sistema, no la carga individual
Certificación externa	No	Sí (SPEC PTDaemon + revisión MLCommons)
Acceso a los datos	En tiempo real en Prometheus	Logs públicos en GitHub post-ronda
Uso recomendado	Monitorización continua en producción	Benchmarking comparativo certificado

La conclusión operativa: las dos aproximaciones son complementarias, no competidoras. El stack DCGM/Kepler da la vista continua por pod para producción; MLPerf Power da la verdad-terreno certificada para comparativas de hardware con garantías de reproducibilidad.

El mito de medir solo la GPU: datos del paper

El paper arXiv 2410.12032 dedica la sección §III-C a desmontar los mitos de la medición de potencia en sistemas ML. El más relevante para inferencia on-premise es el Mito 1:

“A common misconception is that measuring the power consumption of specific ML components, such as accelerators or GPUs, is adequate to assess system efficiency. In reality, overall system power consumption is crucial. Different components are active at various stages of ML workloads with varying duty cycles.”

Los datos de submissions con analizador a la pared versus lecturas NVML confirman que el overhead de los componentes no-GPU del nodo (CPU, memoria, discos, ventiladores, PSU losses) oscila entre el 25 y el 45 % del consumo total según el sistema. Una comparativa de eficiencia basada solo en lecturas NVML sistemáticamente subestima el consumo y puede distorsionar la clasificación entre sistemas con distinta proporción CPU/GPU.

El mito 2 (TDP y PSU como proxies de potencia) también es relevante: el TDP de una H100 SXM es 700 W por tarjeta, pero el consumo real en inferencia con Llama 2 70B depende de la carga, la longitud del prompt y el batch size. Los datos de MLPerf Power muestran que los sistemas funcionan habitualmente muy por debajo del TDP en escenarios de inferencia online (server scenario), donde la latencia limita el throughput y la GPU no está al 100 % de utilización.

Limitaciones de las submissions actuales

Las limitaciones no son del método sino de la cobertura:

Pocas submissions con power en datacenter. En v4.0 solo 4 empresas entregaron power numbers para datacenter; en v5.1, una (Lenovo). El benchmarking de rendimiento tiene decenas de submitters; el de energía, pocos. Esto limita la representatividad del corpus para comparar hardware on-premise.
SUT heterogéneos. Cada submitter define su propio SUT: número de GPUs, servidor, interconexión, software stack. Un sistema Dell con 4×H100 no es directamente comparable a uno Supermicro con 8×H100, aunque ambos usen el mismo modelo. Las diferencias de plataforma (NVLink vs PCIe, servidor vs rack) están capturadas pero no separadas.
Workloads fijos. Los benchmarks MLPerf son representativos pero no son tu carga. La distribución de longitudes de prompt, el ratio prefill/decode y el batch size de tus usuarios pueden diferir significativamente de los datasets sintéticos de MLPerf. El resultado en samples/J del benchmark es una referencia, no una predicción de tu workload.
Latencia de publicación. Los resultados se publican meses después del cierre de submissions. Hardware nuevo (H200, B100, B200) puede no tener resultados power disponibles en el momento de la decisión de compra.
Ausencia de PUE. MLPerf Power no incluye la eficiencia del datacenter. Dos sistemas idénticos en dos datacenters con PUE 1,1 y 1,5 tienen el mismo resultado MLPerf Power pero un coste eléctrico muy distinto. Para el TCO, el J/sample de MLPerf debe multiplicarse por el PUE del datacenter propio.

Flujo de uso para una plataforma on-premise

Para quien quiere usar MLPerf Power como referencia de compra o como benchmark propio, el flujo práctico:

Paso	Acción	Recurso
1	Consultar submissions publicly disponibles	mlcommons.org/benchmarks/inference-datacenter
2	Filtrar por modelo (Llama 2 70B, GPT-J), escenario (Offline/Server) y división (Closed/Available)	GitHub mlcommons/inference_results_vX.Y
3	Comparar samples/J entre sistemas con hardware similar	power log + performance summary
4	Ajustar por PUE propio	samples/J × (1/PUE) para energía real en el datacenter
5	Si se quiere medir el propio hardware: adquirir Yokogawa WT310E, unirse a MLCommons, acceder a PTDaemon	docs.mlcommons.org/inference/power
6	Calibrar stack software (DCGM/Kepler) contra el analizador una vez	ver post C3

Cross-links del track de energía

Este artículo es el C4 del pilar de energía. Los artículos relacionados:

C1 — Estado del arte: benchmarking de energía de frameworks LLM: inventario de herramientas y panorama del campo.
C2 — Energía por token: metodología y mercado eléctrico español: la identidad J/token y cómo el precio eléctrico la multiplica.
C3 — Herramientas de medición en producción: Kepler, DCGM y stack práctico: el stack continuo para producción que MLPerf Power complementa.
Track de benchmarking — estado del arte de frameworks: contexto del benchmarking de rendimiento del que MLPerf Power es extensión energética.

Ver también

Leaderboards de eficiencia energética de LLMs — los rankings públicos de J/token donde aparecen los resultados MLPerf Power: cómo leerlos y qué sesgos tienen respecto a la metodología de esta ficha.
Del vatio al carbono: PUE, intensidad de la red y el coste real de un token — el paso de conversión del W medido en el AC meter PTDaemon a gCO₂eq y a euros, aplicando PUE y mix energético del país.

Fuentes

MLCommons Power Working Group — https://mlcommons.org/working-groups/benchmarks/power/
arXiv 2410.12032 · MLPerf Power: Benchmarking the Energy Efficiency of Machine Learning Systems from Microwatts to Megawatts for Sustainable AI (Tschand et al., 2024) — https://arxiv.org/abs/2410.12032
MLPerf Inference Power Measurement Rules v2.0 (power_measurement.adoc) — https://github.com/mlcommons/inference_policies/blob/master/power_measurement.adoc
MLCommons power-dev · repositorio público de herramientas de medición — https://github.com/mlcommons/power-dev
MLPerf Inference Power Measurement Documentation (MLCFlow) — https://docs.mlcommons.org/inference/power/
SPEC PTDaemon · lista de dispositivos certificados — https://open.spec.org/power/docs/specpower-device_list/
MLCommons · MLPerf Inference v1.0 con las primeras mediciones de potencia (abril 2021) — https://mlcommons.org/2021/04/mlperf-inference-v1-0-results-with-first-power-measurements/
MLCommons · MLPerf Inference v4.1 results (agosto 2024) — https://mlcommons.org/2024/08/mlperf-inference-v4-1-results/
MLCommons · MLPerf Inference v5.1 results (septiembre 2025) — https://mlcommons.org/2025/09/mlperf-inference-v5-1-results/
MLCommons · MLPerf Power benchmark presentado en IEEE HPCA 2025 — https://mlcommons.org/2025/03/ml-commons-power-hpca/
SPEC Updates PTDaemon Interface (GlobeNewswire, febrero 2024) — https://www.globenewswire.com/news-release/2024/02/22/2833367/0/en/SPEC-Updates-PTDaemon-Interface-to-Meet-Evolving-Industry-Requirements.html
Yokogawa WT310E Power Analyzer — https://tmi.yokogawa.com/us/solutions/products/power-analyzers/