Leaderboards de energía de LLM: cómo comparar modelos por Wh/token y elegir por eficiencia
Notación: importes en euros (N €), decimales con coma. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula). Hardware de ejemplo genérico; sin infra real.
TL;DR
Existen tres leaderboards OSS con datos públicos y metodología documentada para comparar la eficiencia energética de LLMs en inferencia: Hugging Face AI Energy Score (166 modelos, Wh/query sobre H100, escala de 1–5 estrellas, lanzado febrero 2025), ML.ENERGY Leaderboard v3 (Universidad de Michigan, J/token por tarea, herramienta Zeus, diciembre 2025) y MLPerf Power (samples/joule certificado con vatímetro físico Yokogawa WT310E). Los tres miden dimensiones distintas y no son directamente intercambiables. Los datos disponibles muestran que los modelos razonadores consumen hasta 700× más energía que sus equivalentes sin razonamiento; que los modelos MoE consumen aprox. 3× menos J/token que un denso de parámetros activos equivalentes; y que la cuantización INT4 reduce el consumo hasta un 79 % respecto a FP16 en condiciones favorables. El motor de inferencia (vLLM vs Transformers) puede mover el resultado otro 25–40 %. Sin fijar hardware, motor, batch size y tarea, ninguna comparativa entre leaderboards es válida.
Contexto del track
Este artículo es el C5 del pilar de energía. El contexto base:
- C1 — Estado del arte: benchmarking de energía de frameworks LLM
- C2 — Energía por token: metodología
- C3 — Herramientas de medición en deploy
- C4 — MLPerf Power
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
- C1 — Benchmarking de energía de frameworks LLM: estado del arte
- C2 — Energía por token: metodología y mercado eléctrico
- C3 — Herramientas de medición en deploy: precisión y overhead
- C4 — MLPerf Power: el benchmark estándar certificado
- Fundamentos de cuantización para inferencia
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/