Caso de estudio
Arquitectura multiagente para medir el consumo energético de LLMs según las técnicas de prompting y la longitud de contexto
El prompt engineering optimiza la calidad de la respuesta e ignora la factura energética. Este arnés multiagente midió 2.700 inferencias de LLM para ponerle un número al compromiso.
Problema
Todas las guías de prompt engineering optimizan la misma variable: la calidad de la respuesta. Añade ejemplos, pide al modelo que piense paso a paso, dale más contexto. Ninguna informa del otro lado del balance. La cadena de pensamiento produce respuestas más largas y, con ellas, inferencias más largas, y la inferencia es donde los LLMs gastan la mayor parte de su energía a escala.
La pregunta que este proyecto se propuso responder es lo bastante estrecha como para ser medible: ¿cuánta energía extra cuesta una técnica de prompting, y la calidad que compra lo justifica? Responder eso con honestidad implica medir energía y calidad en las mismas ejecuciones, sobre modelos que no se parecen en nada, desde un modelo de 3B en una GPU local hasta un endpoint API de frontera cuyas tripas son invisibles.
Este fue mi Trabajo de Fin de Máster en Ciencia de Datos en la Universitat Oberta de Catalunya (tutor: Josep-Anton Mir Tutusaus), defendido en junio de 2026.
Arquitectura
El sistema es un arnés multiagente orquestado con LangGraph y dividido en tres fases. Esa división sostiene todo el diseño: el no determinismo del LLM queda confinado a una fase de preprocesado que se ejecuta una sola vez y escribe su salida a disco, de modo que el bucle experimental reproduce prompts idénticos en todas las repeticiones.
La rejilla experimental: tres tareas (resumen con XSum, generación de código con HumanEval, razonamiento aritmético con GSM8K) × 5 instancias × 12 celdas (3 técnicas × 2 longitudes de contexto × 2 formatos sintácticos) × 5 modelos × 3 repeticiones = 2.700 inferencias evaluadas.
La medición hubo que dividirla por tipo de modelo, porque ninguna herramienta ve
las dos cosas. Los modelos locales corren a través de Ollama como proceso
externo, así que CodeCarbon se ejecuta en tracking_mode='machine' alrededor de
la llamada. Los modelos remotos son opacos, así que EcoLogits estima a partir del
recuento de tokens y de las características publicadas del modelo. Ambas medidas
no son intercambiables y nunca se comparan directamente: todos los modelos
estadísticos se ajustan por separado para API y para local.
El juez puntúa cada respuesta contra la rúbrica de su instancia, ciego a qué
técnica la produjo, con salida estructurada vía tool_use.
Decisiones y compromisos
- El Router es un LLM en tiempo de preprocesado y una búsqueda en diccionario en tiempo de ejecución. Generar variantes de prompt sobre la marcha habría sido una demo de agentes más vistosa, pero entonces las tres repeticiones de cada celda habrían recibido tres prompts ligeramente distintos y la varianza no habría sido atribuible. El grafo en tiempo de ejecución es, por tanto, menos agéntico de lo que sugiere el diagrama de arquitectura, y es deliberado.
- Las rúbricas son semidinámicas: una estructura fija por tarea con huecos contextuales rellenados por un LLM. Rúbricas totalmente generadas puntuarían cada instancia en una escala distinta; unas totalmente estáticas puntuarían un resumen sin saber qué hechos importaban. Eso significa más piezas móviles que una única rúbrica global, a cambio de puntuaciones comparables entre celdas.
- El juez viene de una familia de modelos ausente del experimento. Anthropic juzga a OpenAI, a Google y a los modelos locales de pesos abiertos, así que ningún modelo puede preferir su propia salida, y un 13,3% de las ejecuciones se repuntuaron con un juez más potente para validar al barato. Funcionó, y salió caro: el metasistema acabó quemando más energía que todo lo que estaba midiendo.
- Sin enfriamientos térmicos entre ejecuciones; la temperatura de la GPU es una covariable en su lugar. Esperar a que la GPU volviera a su línea base entre inferencias habría añadido unas 13 horas a la ejecución. La temperatura hubo que modelarla en vez de controlarla, y el modelo le puso precio: +6,9% de energía por cada grado adicional, lo que convirtió un atajo operativo en un resultado.
Métricas
Todas las cifras salen de la ejecución consolidada (f3fb12ab-8bab-…, 2.700
ejecuciones a lo largo de ~11 horas) y de los modelos estadísticos de la memoria,
capítulo 4.
| Métrica | Valor |
|---|---|
| Inferencias evaluadas | 2.700 · 100% juzgadas · 0 fallos no recuperados (182 reintentadas) |
| Energía: zero-shot vs CoT (API) | zero-shot consume el 33,5% de CoT |
| Energía: few-shot vs CoT (API) | few-shot consume el 31,4% de CoT |
| Energía: zero-shot vs CoT (local) | zero-shot consume el 50%; few-shot, el 64,6% |
| Tamaño del efecto, zero-shot vs CoT | d de Cohen = −0,485 (pequeño a medio), p < 1e−63 |
| Tamaño del efecto, zero-shot vs few-shot | d de Cohen = −0,071 (despreciable) |
| Calidad (juez, 0 a 100) | zero-shot 49,0 · few-shot 52,4 · CoT 53,1 |
| XML vs texto plano, contexto largo | −29,8% de energía |
| Dispersión entre modelos | gpt-5-mini ≈ 26% de gemini-2.5-flash para la misma celda |
| Temperatura de la GPU | +6,9% de energía por grado adicional |
| Acuerdo entre jueces (n = 359) | ρ de Spearman = 0,948 |
| Juez vs métrica objetiva | ρ = 0,868 (GSM8K) · 0,600 (HumanEval) · 0,467 (XSum) |
| Energía total contabilizada | 826,47 Wh · 143,16 g CO₂ |
| Parte del metasistema en ese total | 59,4% |
Lecciones aprendidas
Few-shot es el valor por defecto honesto. Iguala a la cadena de pensamiento en calidad para los modelos de API, donde la diferencia no es estadísticamente significativa, y cuesta lo que cuesta zero-shot. La cadena de pensamiento compra su calidad con un sobrecoste energético real y medible, y en los modelos locales ese sobrecoste duplica el consumo. El consejo habitual de «añade razonamiento paso a paso» no sale gratis, y ahora tiene un número al lado.
Medir costó más energía que lo medido. El juez y su pasada de validación supusieron el 59,4% del consumo total. Es un resultado incómodo de publicar en una tesis de Green AI, y contarlo es más útil que esconderlo: cualquier pipeline de LLM-as-a-judge necesita su propio presupuesto de eficiencia, y el juez de validación en particular merece una estrategia más barata.
Validar al juez es la mayor parte del trabajo. Tres capas independientes (acuerdo
entre jueces, correlación con métricas objetivas y una comprobación de sesgo por
verbosidad) pasaron todas salvo una: la kappa ponderada cuadrática para
gsm8k.conciseness se quedó en 0,187, muy por debajo del umbral de 0,4. Falló un
criterio de quince, y fingir lo contrario habría invalidado el resto. Resulta que
la concisión en respuestas aritméticas cortas es algo en lo que dos jueces
sencillamente no se ponen de acuerdo.
Qué haría distinto: cinco instancias por tarea son pocas para generalizar a nivel de instancia, y entre diez y quince habrían sido mejores, escalando el coste proporcionalmente. También añadiría TOON como tercer formato sintáctico. Si XML ya recorta un 29,8% en contextos largos, una notación orientada a tokens es la siguiente palanca evidente.
Enlaces
- Código fuente, artefactos y datos: github.com/lepablito/TFM_UOC_PabloMarcosParra
- Memoria completa (67 pp., PDF): Arquitectura multiagente para la medición del impacto energético de las técnicas de prompting y la longitud de contexto en LLMs heterogéneos