Llama 3.1 405B gasta 0,39 Wh por consulta, según el benchmark ML.ENERGY

⏱️ Lectura: 10 min

El consumo energético de la IA dejó de ser una estimación de servilleta. Investigadores de la Universidad de Michigan publicaron ML.ENERGY, un benchmark abierto que mide cuánta energía gasta realmente cada modelo de inteligencia artificial al responder, modelo por modelo y token por token.

📑 En este artículo

1. TL;DR
2. Qué pasó
3. Contexto e historia
4. Datos y cifras: el consumo energético de la IA medido por consulta
5. Impacto y análisis
6. Qué sigue
7. Preguntas frecuentes
   1. ¿Qué es ML.ENERGY?
   2. ¿Cuánta energía gasta una consulta a un modelo grande?
   3. ¿Por qué las estimaciones por TDP son inexactas?
   4. ¿Qué es Zeus?
   5. ¿Cómo se puede reducir el consumo energético de la IA al servir modelos?
   6. ¿Los modelos de mezcla de expertos consumen menos?
8. Referencias

El dato que rompe el consenso: las cifras que circulan, casi todas derivadas del TDP de la GPU, exageran el gasto real hasta 4,1 veces. La medición directa cuenta otra historia, y por primera vez está disponible en una tabla pública y reproducible.

TL;DR

• ML.ENERGY, de la Universidad de Michigan, mide el consumo energético real de más de 40 modelos de IA por consulta.
• Llama 3.1 405B gasta una mediana de 0,39 Wh por consulta; Mixtral 8x22B baja a 0,06 Wh y Llama 3.1 8B a 0,02 Wh.
• La herramienta Zeus mide la energía directa de la GPU, que supone el 50-70% de la potencia del centro de datos.
• Estimar por TDP exagera el consumo: hasta 4,1 veces más para CodeGemma 2B frente a la medición real.
• El batching amortiza energía: a mayor lote, menor gasto por consulta en la fase de generación de tokens.
• Optimizar sin cambiar el cómputo ahorra más del 40%: un 44% en Llama 3.1 8B al relajar la latencia.
• La generación de texto tiene baja intensidad de cómputo; la difusión de imágenes se acerca al tope de la GPU.

Qué pasó

Un equipo del grupo SymbioticLab de la Universidad de Michigan, liderado por el profesor Mosharaf Chowdhury y con Jae-Won Chung como primer autor, actualizó en febrero de 2026 el ML.ENERGY Leaderboard, una tabla clasificatoria que ordena modelos generativos según la energía que consumen al ejecutar inferencia. No es una proyección teórica: cada cifra proviene de medir el gasto eléctrico real de las GPU mientras los modelos responden.

El proyecto se apoya en Zeus, una biblioteca de código abierto desarrollada por el mismo grupo que lee los contadores de energía de la GPU por software, sin necesidad de instrumentación física. La tabla, su código y el conjunto de datos están publicados, de modo que cualquiera puede reproducir las mediciones o añadir modelos nuevos. El acompañamiento académico es el artículo The ML.ENERGY Benchmark, que detalla la metodología y los resultados sobre unas 40 arquitecturas distintas.

Contexto e historia

La pregunta “¿cuánta energía gasta una consulta a un modelo de IA?” se volvió central a medida que los centros de datos crecían. El problema es que casi todas las respuestas públicas se calculaban de la misma forma poco fiable: tomar el TDP (la potencia máxima de diseño) de la GPU, multiplicarlo por un tiempo estimado y repartirlo entre las consultas. Es cómodo, pero parte de un supuesto falso, que el chip trabaja siempre a tope.

En la práctica, generar texto rara vez exige el máximo de la GPU. La fase de decodificación —producir un token tras otro— es un proceso limitado por la memoria, no por el cálculo: el acelerador pasa buena parte del tiempo esperando datos en lugar de quemando vatios. Por eso el TDP es un mal estimador. ML.ENERGY nació justamente para sustituir ese atajo por una medición directa y comparable, y para mostrar que la conversación sobre el consumo energético de la IA estaba apoyada en números inflados.

💭 Clave: El TDP mide cuánto podría consumir una GPU, no cuánto consume de verdad al generar texto. Confundir ambos infla las estimaciones hasta varias veces.

Datos y cifras: el consumo energético de la IA medido por consulta

Las mediciones se hicieron sobre GPU NVIDIA A100 (40 GB) y H100 (80 GB) en instancias de AWS, midiendo en estado estacionario, es decir, cuando el servidor está saturado de peticiones tal como ocurre en producción. La energía por consulta se calcula como la energía total del lote dividida entre el número de peticiones, multiplicada por la longitud media de salida. Estos son algunos resultados representativos:

• Llama 3.1 405B — mediana de unos 0,39 Wh por consulta, de los más altos entre los modelos densos grandes.
• Mixtral 8x22B — alrededor de 0,06 Wh por consulta gracias a su arquitectura de mezcla de expertos (MoE), que solo activa una fracción de sus parámetros.
• Llama 3.1 8B — en torno a 0,02 Wh por consulta.
• Mistral 7B — cerca de 0,01 Wh en una tarea de chat típica.

La diferencia entre el modelo más pesado y el más ligero supera un factor de 30. También aparece el hallazgo que más matiza el discurso público: estimar por TDP exagera el gasto hasta 4,1 veces en el caso de CodeGemma 2B frente a la medición real. Otro contraste interesante es entre tareas: la generación de imágenes con modelos de difusión se acerca al límite de potencia de la GPU, mientras que la generación de texto se queda muy por debajo.

El flujo de medición es conceptualmente sencillo:

graph LR
  A["Consulta del usuario"] --> B["Servidor de inferencia (lote)"]
  B --> C["GPU genera tokens"]
  C --> D["Zeus mide la energia de la GPU"]
  D --> E["Energia por consulta = energia del lote / numero de consultas"]

Medir con Zeus dentro del propio servicio de inferencia es directo. Un esquema simplificado del patrón:

from zeus.monitor import ZeusMonitor

monitor = ZeusMonitor(gpu_indices=[0])
monitor.begin_window("inferencia")

# El modelo genera la respuesta para todo el lote
salida = modelo.generate(lote_de_prompts)

medida = monitor.end_window("inferencia")
print(f"Energia del lote: {medida.total_energy} J")
print(f"Por consulta: {medida.total_energy / len(lote_de_prompts)} J")

El detalle decisivo es el batching. En producción, decenas de consultas se procesan juntas en un mismo lote, y la energía se reparte entre todas. Cuanto mayor es el lote, menor es el gasto por consulta, porque el coste fijo de cargar los pesos del modelo en memoria se amortiza entre más peticiones. Por eso medir un modelo respondiendo a un único prompt aislado sobreestima brutalmente el consumo: nadie sirve un modelo así.

💡 Tip: Si necesitás reducir el consumo energético de la IA en tu propio despliegue, lo primero no es cambiar de modelo, sino aumentar el tamaño de lote y relajar la latencia donde el caso de uso lo permita.

Impacto y análisis

La consecuencia práctica es doble. Por un lado, ML.ENERGY ofrece a quien despliega modelos una base empírica para elegir: un MoE como Mixtral puede dar calidad comparable a un denso grande con una fracción del gasto, y un modelo de 8B resuelve muchas tareas con la vigésima parte de la energía de uno de 405B. Por otro, el benchmark desmonta titulares alarmistas construidos sobre estimaciones de TDP: el consumo energético de la IA es real y crece, pero los números que circulaban estaban, en muchos casos, varias veces inflados.

El trabajo también muestra que se puede ahorrar mucho sin tocar el resultado del modelo. Aplicando recomendaciones de optimización automática —ajustar la frecuencia de la GPU, el tamaño de lote o los límites de latencia— el equipo logró reducciones de más del 40%, con un caso concreto del 44% en Llama 3.1 8B al relajar las restricciones de latencia. Es energía que hoy se desperdicia simplemente por servir los modelos con la configuración de fábrica.

Para periodistas, reguladores y responsables de sostenibilidad, el mensaje es que la medición importa: apoyar políticas o promesas de eficiencia en cifras de TDP produce conclusiones engañosas. Una tabla abierta y reproducible es una herramienta mucho más sólida para discutir el coste ambiental de esta tecnología con datos en la mano.

Qué sigue

El ML.ENERGY Leaderboard es un proyecto vivo: se actualiza con nuevos modelos y hardware, y su naturaleza abierta invita a que otros laboratorios contribuyan mediciones. La frontera más interesante por cubrir es la del razonamiento. Esta edición se centra en cargas de inferencia clásicas (chat, código, texto a imagen), pero los modelos que “piensan” mediante test-time scaling generan cadenas largas de tokens internos antes de responder, lo que puede multiplicar la energía por consulta. Medir ese coste con el mismo rigor será el siguiente capítulo.

A más largo plazo, la propuesta del grupo es que la eficiencia energética se trate como una métrica de primera clase, junto a la precisión y la latencia, en cada decisión de diseño del stack de IA. Si esa idea cuaja, el consumo energético de la IA dejará de ser una nota al pie para convertirse en un número que se reporta y se optimiza de serie.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es ML.ENERGY?

Es un benchmark y una tabla clasificatoria abiertos, creados por la Universidad de Michigan, que miden cuánta energía consumen los modelos generativos de IA al ejecutar inferencia. Ordena más de 40 arquitecturas por gasto energético por consulta.

¿Cuánta energía gasta una consulta a un modelo grande?

Según las mediciones, un modelo denso grande como Llama 3.1 405B consume una mediana cercana a 0,39 Wh por consulta. Modelos más pequeños como Llama 3.1 8B bajan a unos 0,02 Wh, una diferencia de más de un orden de magnitud.

¿Por qué las estimaciones por TDP son inexactas?

El TDP es la potencia máxima de diseño de la GPU, pero la generación de texto está limitada por la memoria y rara vez exige ese máximo. Calcular el gasto por TDP exagera el consumo: hasta 4,1 veces para CodeGemma 2B frente a la medición real.

¿Qué es Zeus?

Zeus es la biblioteca de código abierto que usa ML.ENERGY para medir la energía de la GPU directamente por software, leyendo sus contadores durante la inferencia. Es la base técnica que permite obtener cifras reales en lugar de estimadas.

¿Cómo se puede reducir el consumo energético de la IA al servir modelos?

El batching es clave: agrupar consultas en lotes grandes reparte el coste fijo y baja el gasto por consulta. Ajustar la frecuencia de la GPU y relajar la latencia logró ahorros de más del 40% sin cambiar el resultado del modelo.

¿Los modelos de mezcla de expertos consumen menos?

Tienden a ser más eficientes por consulta porque solo activan una fracción de sus parámetros. Mixtral 8x22B gasta unos 0,06 Wh, muy por debajo de un modelo denso de tamaño comparable en parámetros totales.

Referencias

• ML.ENERGY Leaderboard (GitHub) — código abierto del benchmark y la tabla de consumo energético.
• The ML.ENERGY Benchmark (arXiv) — artículo con la metodología, Zeus y resultados sobre 40 modelos.
• ML.ENERGY Leaderboard (Hugging Face) — tabla interactiva con la energía por consulta de cada modelo.
• Power-hungry AI (Michigan CSE) — nota oficial de la universidad sobre el estudio.
• Per-query energy consumption of LLMs (Muxup) — análisis independiente de las cifras por consulta.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.