# El consumo eléctrico de la IA varía hasta 300x entre tareas > Source: > Published: 2026-05-29 16:10:32+00:00 Durante años, la conversación sobre la huella eléctrica de la inteligencia artificial giró en torno al entrenamiento de modelos gigantes. Un equipo de la Universidad de Michigan acaba de mover el foco con datos: el **consumo energético de la IA** se concentra en la inferencia y varía de forma brutal según la tarea. La herramienta se llama ML.ENERGY, es de código abierto y publica un leaderboard que mide, GPU en mano, cuánta electricidad gasta cada modelo al responder. Un grupo de la facultad de Computer Science and Engineering de la Universidad de Michigan presentó un conjunto de herramientas abiertas para responder una pregunta que, hasta ahora, casi nadie podía contestar con precisión: ¿cuánta electricidad consume realmente un modelo de IA cada vez que responde? El proyecto se articula en torno a tres piezas: **ML.ENERGY Benchmark** (la metodología de medición), el **ML.ENERGY Leaderboard** (una tabla pública que compara modelos) y **Zeus** (la librería que toma las mediciones de potencia). El equipo lo lidera el profesor asociado Mosharaf Chowdhury, con el estudiante de doctorado Jae-Won Chung como primer autor del trabajo y colaboradores como Jeff J. Ma, Ruofan Wu, Jiachen Liu y Zhiyu Wu. Las mediciones se ejecutan en el Michigan Academic Computing Center, una instalación de dos megavatios en Ann Arbor. El artículo central, presentado como Spotlight en NeurIPS Datasets & Benchmarks 2025, evalúa 40 arquitecturas de modelos a lo largo de 6 tareas distintas. El mensaje de fondo del proyecto es simple y a la vez incómodo: los benchmarks populares miden exactitud, velocidad o calidad, pero ignoran la energía. Sin esa cifra, ni los desarrolladores ni los operadores de centros de datos pueden tomar decisiones informadas sobre el **consumo energético de la IA**. La inferencia concentra la mayor parte del gasto eléctrico de la IA. La idea instalada en el debate público era que entrenar un modelo grande es lo que devora la electricidad. Es cierto que un entrenamiento puede costar millones de kilovatios-hora, pero ocurre una sola vez. La inferencia, en cambio, sucede miles de millones de veces al día: cada consulta de chat, cada imagen generada, cada autocompletado de código pasa por una GPU que consume potencia en tiempo real. Por eso el dato más citado del trabajo de Michigan reordena prioridades: entre el **80% y el 90%** de la energía asociada a los modelos de IA en producción se gasta en inferencia, no en entrenamiento. Si se quiere reducir la huella del sector, el lugar para actuar es la operación diaria, no el evento puntual del entrenamiento. Históricamente esta cifra era difícil de obtener porque los proveedores comerciales no publican el consumo por consulta y porque medirlo bien exige instrumentación a nivel de hardware. Zeus ataca exactamente ese punto: en lugar de estimar la energía a partir del número de operaciones de punto flotante (FLOPs), *lee* la potencia directamente de los contadores de la GPU a intervalos regulares, mientras el modelo trabaja bajo condiciones de servicio realistas. 💭 Clave:Estimar energía desde FLOPs es como calcular el gasto de gasolina de un auto mirando solo el tamaño del motor. Zeus mide el consumo real al volante, batch incluido. Zeus es una librería de Python pensada para envolver una carga de trabajo de deep learning y reportar cuánta energía consumió. Define ventanas de medición: se marca el inicio, se ejecuta la generación del modelo y se cierra la ventana. El resultado entrega energía total en joules y tiempo transcurrido, leídos del hardware. ``` python from zeus.monitor import ZeusMonitor monitor = ZeusMonitor(gpu_indices=[0]) monitor.begin_window("inferencia") # ... ejecutar la generacion del modelo ... medida = monitor.end_window("inferencia") print(f"Energia: {medida.total_energy} J") print(f"Tiempo: {medida.time} s") ``` La gracia de medir en el hardware es que captura todo lo que la estimación teórica ignora: el tamaño del lote (batch), la estrategia de asignación de memoria, la cantidad de tokens generados y hasta el comportamiento térmico del acelerador. Estas variables de despliegue son, según el equipo, donde se esconde gran parte del desperdicio. El siguiente diagrama resume por dónde se van los joules en una respuesta típica: ``` php graph LR A["Consulta del usuario"] --> B["Prefill: procesa el prompt"] B --> C["Decode: genera tokens"] C --> D{"Modelo de razonamiento?"} D -->|"Si"| E["Cadena de pensamiento: 10-100x tokens"] D -->|"No"| F["Respuesta directa"] E --> G["Energia medida por Zeus"] F --> G ``` El paso de *decode* es el que más pesa: cada token generado implica una pasada completa por la red. Por eso un modelo que produce respuestas largas consume mucho más que uno que va al grano, aunque ambos tengan el mismo tamaño. Las cifras del trabajo dan escala al problema del **consumo energético de la IA**: 💡 Tip:Si operás un servicio de IA propio, antes de comprar más GPUs revisá el tamaño de batch y la asignación de memoria: ahí puede estar escondido un 40% de tu factura eléctrica. El leaderniboard público permite comparar modelos por tarea y energía. El valor práctico de ML.ENERGY no está solo en la curiosidad académica. Para quien despliega modelos, tener un número confiable de joules por consulta convierte la sostenibilidad en una métrica de ingeniería, comparable junto a latencia y costo. Hasta ahora, "la IA gasta mucha luz" era una afirmación cualitativa; ahora es una columna más en una tabla. El hallazgo sobre los modelos de razonamiento es especialmente relevante en 2026, cuando buena parte de la industria empuja modelos que "piensan" antes de responder. Esa capacidad mejora la exactitud en tareas difíciles, pero el dato de Michigan obliga a preguntarse si vale la pena activar el razonamiento extendido en consultas triviales. Usar un modelo de cadena de pensamiento para responder un saludo es, energéticamente, un derroche cuantificable. ⚠️ Ojo:Activar razonamiento extendido por defecto en todas las consultas puede multiplicar el consumo por diez o más. Reservalo para tareas que realmente lo necesiten. El segundo aporte es metodológico. Al medir en hardware en lugar de estimar, ML.ENERGY expone que la eficiencia no depende solo del modelo elegido, sino de cómo se sirve. Dos despliegues del mismo modelo pueden tener facturas muy distintas según el batching y la gestión de memoria. Esto traslada parte de la responsabilidad —y de la oportunidad de ahorro— al equipo de infraestructura, no solo a quienes diseñan los modelos. El equipo mantiene el leaderboard actualizado y el benchmark está pensado para extenderse a modelos y escenarios personalizados, de modo que una empresa pueda medir sus propios despliegues con la misma vara. La línea de investigación continúa con un segundo trabajo centrado en diagnosticar dónde se va exactamente cada joule durante la inferencia. La pregunta abierta es si los grandes proveedores comerciales adoptarán métricas comparables y públicas. Mientras el consumo por consulta de los servicios cerrados siga siendo opaco, herramientas abiertas como Zeus serán la mejor referencia disponible para entender, y reducir, el **consumo energético de la IA** a escala. 📖 Resumen en Telegram: Ver resumen Es un proyecto de código abierto de la Universidad de Michigan que mide el consumo eléctrico de los modelos de IA. Incluye un benchmark (metodología), un leaderboard público que compara modelos por tarea y energía, y la librería Zeus para tomar las mediciones. Zeus lee la potencia directamente de los contadores del hardware de la GPU a intervalos regulares mientras el modelo ejecuta la carga real. Así captura el efecto del batch, la memoria y los tokens generados, en lugar de calcular a partir de FLOPs teóricos. Porque el entrenamiento ocurre una vez, pero la inferencia se repite miles de millones de veces al día. Por eso entre el 80% y el 90% de la energía del sector se gasta respondiendo consultas, no entrenando. Generan cadenas de pensamiento, es decir, producen entre 10 y 100 veces más tokens por consulta que un modelo estándar. Como cada token implica una pasada por la red, el consumo crece de forma proporcional. Sí. Según el trabajo, ajustar el tamaño de lote y la asignación de memoria del servicio puede ahorrar más del 40% de energía sin alterar lo que el modelo computa ni la calidad de la respuesta. En el leaderboard público en ml.energy/leaderboard y en el repositorio de Zeus en GitHub. El artículo completo está disponible en arXiv (2505.06371). 📱 **¿Te gusta este contenido?** Únete a nuestro canal de Telegram [@programacion](https://t.me/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.