Una M4 Pro gasta 0,47 W corriendo LLMs open source, según un nuevo benchmark

Un paper publicado en arXiv el 24 de agosto, y listado como aceptado en IEEE ICCUBEA 2026, midió el consumo energético, el throughput y la huella de carbono de cinco LLMs open source corriendo en un MacBook Pro con chip M4 Pro y 48 GB de memoria unificada. Durante inference sostenida, el package CPU+GPU de la M4 Pro llegó a 0,47 W de pico, con un promedio de 0,41 W, según las lecturas directas de los autores. El paper se presenta como el primer benchmark energético sistemático de LLM inference sobre Apple Silicon.

Los autores son Rajeswari Kannan, Raj Firke, Shreya Bengle y Srushti Deshmukh. La comparación central es grande: la M4 Pro entrega 4 a 12 tokens por watt a nivel de sistema, un dato que el paper ubica 30 a 40 veces más eficiente por token que las GPUs de datacenter en un despliegue de usuario único.

Cómo funciona el test

Cinco familias de modelos cubren el rango de 3 a 9 mil millones de parámetros, y ninguna dos usa el mismo mecanismo de attention: Llama 3.2 (3B), Phi-3 (3,8B), Qwen 2.5 (7B), Mistral (7B) y Gemma 2 (9B). Todos corren en cuantización Q4_K_M, el default de Ollama, que los autores señalan como lo que la mayoría de los deployments de consumo usa de verdad. Tres tasks varían el workload: 100 preguntas de opción múltiple de MMLU, 50 artículos de CNN/DailyMail condensados en dos o tres frases, y los 164 problemas de code generation de HumanEval. El protocolo mantiene un solo modelo en memoria a la vez, fija temperature en 0 y genera más de 1.500 registros de inference.

La potencia se mide con powermetrics de macOS, muestreado cada dos segundos, así que la lectura de package no incluye DRAM ni periféricos. El timing sale de la API de Ollama, con precisión de nanosegundos. La potencia total de sistema de unos 10 W es una estimación basada en las especificaciones térmicas de Apple para la M4 Pro, no una medición a nivel de enchufe.

Lo que dicen los números

Los modelos chicos son los rápidos. Llama 3.2 (3B) gana en las tres tasks, con 175,9 tokens por segundo en MMLU y 91,3 en code generation, contra 42,0 de Gemma 2 (9B). Los modelos de 3-4B rinden 2,6 a 4,2 veces más que los de 7-9B, y el throughput sigue una ley de potencia que los autores ajustan en 340 veces la cantidad de parámetros elevada a menos 0,85, con R cuadrado de 0,94. Su lectura: el decoding está limitado por el ancho de banda de memoria, y los modelos grandes se pasan el tiempo leyendo pesos.

La energía escala igual. A nivel de package, Llama 3.2 gasta 4,4 milijoules por token contra 11,6 de Gemma 2, una brecha de 2,6 veces. A nivel de sistema el rango es de 0,09 a 0,25 joules por token, que en la grilla de la India equivale a 0,18-0,48 mg de CO2 por cada 1.000 tokens. La code generation es la que más energía come: el set de HumanEval es apenas 1,6 veces más grande que la muestra de MMLU, pero los runs consumieron de 5 a 8 veces más energía.

En el trade-off de precisión contra eficiencia, el análisis Pareto del paper aterriza en Qwen 2.5 (7B): 57% en MMLU a 59 tokens por segundo. Gemma 2 lidera en precisión con 61%, pero cuatro puntos no compran un golpe de 40% en throughput y 19% más de energía por token. Mistral (7B) sacó 24% en el subset de 100 preguntas de MMLU, pegado al piso de azar para un test de cuatro opciones; los autores sospechan que su instruction tuning no calza bien con el prompt zero-shot que usaron.

Lo que los autores señalan como caveat

La cifra de 0,47 W es un piso de package, porque powermetrics no ve la DRAM, y el LLM decoding es un workload limitado por memoria. La estimación de 10 W de sistema arrastra el mismo caveat. La comparación 30 a 40 veces contra los datacenters se apoya en figuras públicas de la H100, entre ellas unos 4 joules por token estimados a 400 W, y el paper aclara que las GPUs de datacenter diluyen ese consumo entre requests en batch, algo que una laptop de usuario único no puede hacer. Solo probaron Q4_K_M, solo inference de request único, el subset de MMLU tiene 100 preguntas de 14.042, y los resultados valen para la M4 Pro con 48 GB.

Para un developer que evalúe inference local sobre Apple Silicon, la guía del paper es concreta: Qwen 2.5 (7B) para la mejor precisión por joule, Llama 3.2 (3B) cuando la latencia manda, y la code generation es donde se concentra la factura energética. Los autores abrieron GreenBench en código abierto y dicen que los próximos objetivos son la M4 Max, un barrido completo de cuantización y workloads en batch.