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/

Mlcommons on lo0 — Blog Técnico