Del vatio al carbono, honestamente: PUE, intensidad del grid y gCO₂ por token
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 (4×H100 SXM 80 GB); sin infra real. Cifras de emisiones en gCO₂eq/kWh (equivalentes de CO₂).
TL;DR
Un modelo que consume 2 J/token en placa (4×H100 SXM, PUE 1,45) emite entre (0{,}08) y (1{,}05) gCO₂ por cada 1.000 tokens según la región y la hora: (0{,}08) en Francia nuclear de madrugada, (0{,}22) en España solar al mediodía, (0{,}72) en España con gas nocturno, y (1{,}05) en Alemania con carbón. La diferencia —factor ×13— la determinan tres variables externas al hardware: el PUE del datacenter (Uptime Institute 2025: media global 1,54; hiperscale 1,10–1,15), la intensidad de carbono del grid (varía en tiempo real, de 5 a 600+ gCO₂/kWh según zona y hora), y el tipo de emisiones que se contabiliza (location-based, market-based, marginal). Mover carga batch a horas de menor intensidad de carbono —carbon-aware shifting temporal— reduce entre un 20 % y un 65 % las emisiones del trabajo diferible sin tocar el hardware. La especificación SCI (Software Carbon Intensity, Green Software Foundation, ISO/IEC 21031:2022) formaliza la métrica como (\text{SCI} = (E \times I + M) / R), donde (M) captura el carbono embebido del hardware —la parte que casi ningún análisis de inferencia LLM incluye hoy—.
Contexto del track
Este artículo es el C6 del pilar de energía. Los anteriores:
- C1 — Estado del arte: benchmarking de energía de frameworks LLM
- 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
- C5 — Leaderboards de energía de LLM
El punto de partida es el J/token ya medido (metodología en C2 y herramientas en C3). Este artículo convierte ese número en gCO₂/token.
PUE: el primer multiplicador
Definición
El PUE (Power Usage Effectiveness) mide qué fracción de la energía total consumida por un datacenter llega realmente al equipamiento IT:
$$\text{PUE} = \frac{\text{energía total del datacenter (W)}}{\text{energía del equipamiento IT (W)}}$$
Un PUE de 1,0 sería perfecto (toda la energía al cómputo). Un PUE de 2,0 significa que por cada vatio que consume la GPU, otro vatio se consume en refrigeración, distribución eléctrica, iluminación y pérdidas de conversión. El PUE convierte la potencia de placa —la que miden DCGM o NVML— en la potencia total del datacenter que se extrae de la red.
Valores actuales
El Uptime Institute Global Data Center Survey 2025 (15.ª edición anual) reporta:
| Segmento | PUE típico | Fuente |
|---|---|---|
| Media global | 1,54 (6.º año consecutivo sin cambio) | Uptime Institute 2025 |
| Hiperscale (Google, Meta, Microsoft, Amazon) | 1,10–1,15 | Uptime Institute 2025 |
| Colocación / enterprise | 1,58–1,80 | Uptime Institute 2025 |
| On-premise sin optimizar | 1,6–2,0 | sector, varios |
| Límite teórico (aire frío, clima favorable) | 1,10–1,20 | ASHRAE / sector |
La estagnación del PUE medio en 1,54 refleja que las instalaciones legacy —con refrigeración ineficiente— siguen operando junto a las nuevas. Para una plataforma on-premise típica sin inversión específica en eficiencia, asumir PUE entre 1,4 y 1,6 es razonable. Las instalaciones con refrigeración líquida directa pueden llegar a 1,10–1,20.
Cómo infla el J/token
Si el nodo de referencia (4×H100 SXM) consume 3.200 W a carga máxima (GPU + CPU + DRAM + fans):
| PUE | Potencia total datacenter | Factor de inflación sobre placa |
|---|---|---|
| 1,10 | 3.520 W | +10 % |
| 1,40 | 4.480 W | +40 % |
| 1,54 (media global) | 4.928 W | +54 % |
| 1,80 (enterprise legacy) | 5.760 W | +80 % |
La energía por token del leaderboard —medida a nivel de GPU o de nodo— no incluye PUE. El impacto: pasar de PUE 1,10 (hiperscale) a PUE 1,54 (media global) multiplica el consumo energético efectivo por 1,40×. Es la misma GPU, el mismo modelo, el mismo throughput; la diferencia la pone la instalación.
Intensidad de carbono del grid
Qué mide y por qué varía
La intensidad de carbono de la red eléctrica expresa cuántos gramos de CO₂eq se emiten por cada kilovatio-hora generado, en función del mix de fuentes (nuclear, eólica, solar, gas, carbón, hidráulica). Es la variable más heterogénea del cálculo: varía por país, por región dentro del país, y por hora del día.
Las herramientas OSS de referencia son:
| Herramienta | Tipo de señal | Cobertura | Acceso |
|---|---|---|---|
| ElectricityMaps | Media horaria (production-based y flow-traced) | 60+ países en tiempo real | API (plan gratuito limitado); OSS en GitHub |
| WattTime | Marginal horaria (MOER) | EE.UU. + cobertura global creciente | API; datos gratuitos desde 2025 (alianza REsurety-WattTime) |
| Carbon Aware SDK (Green Software Foundation) | Wrapper sobre ElectricityMaps y WattTime | Idem fuentes | OSS, Apache 2.0; github.com/Green-Software-Foundation/carbon-aware-sdk |
ElectricityMaps (anteriormente electricityMap) publica la intensidad de carbono en gCO₂eq/kWh hora a hora vía API y en su mapa interactivo (app.electricitymaps.com). WattTime publica la tasa marginal de emisiones (MOER, Marginal Operating Emissions Rate), útil para calcular el impacto causal de añadir o quitar carga. El Carbon Aware SDK de la GSF integra ambas señales como backends intercambiables.
Datos por país (medias anuales 2024–2025)
| País | Intensidad media 2024 (gCO₂eq/kWh) | Rango horario aproximado | Fuente |
|---|---|---|---|
| España | ~108 | 30–250 | Nowtricity / REE 2025 |
| Francia | ~21,7 (2024); ~19,6 (2025) | 5–80 | RTE Bilan Électrique 2025 |
| Alemania | ~363 (2024); ~328 (2025) | 100–600 | Fraunhofer ISE 2025 |
| UE media | ~213 | — | Ember European Electricity Review 2025 |
Francia tiene la intensidad más baja de Europa continental gracias a su parque nuclear (>90 % de generación baja en carbono en 2025, según RTE). España cerró 2024 con un récord histórico: 56,8 % de generación renovable, con una intensidad media de 108 gCO₂/kWh —entre las más bajas de la UE no nuclear—. Alemania, en transición acelerada pero todavía dependiente del lignito y el gas, triplica a España en intensidad media.
Variación horaria: el dato que más importa para el scheduling
Dentro de un mismo país, la variación horaria de la intensidad de carbono es enorme. Datos del grid review 2025 de ElectricityMaps para España:
| Momento del día | Condición típica | Intensidad estimada (gCO₂eq/kWh) |
|---|---|---|
| Mediodía solar (11:00–15:00, verano) | Solar cubre >40 % demanda | 30–80 |
| Valle nocturno (02:00–06:00, verano) | Solar cero; eólica variable | 80–180 |
| Pico demanda (19:00–21:00, invierno) | Gas como marginal | 180–280 |
| Madrugada fría sin viento (invierno) | Gas + ciclo combinado dominan | 220–300 |
La correlación precio-carbono en España es fuerte y negativa (coeficiente −0,70 en 2025 según ElectricityMaps): las horas baratas son también las más limpias, porque ambas están marcadas por la penetración de renovables. Las 477 horas con precios negativos en 2025 fueron también las horas de menor intensidad de carbono.
España vs Francia vs Alemania: impacto en gCO₂/token
Para anclar la diferencia en términos operativos, con el nodo de referencia (4×H100 SXM, throughput orientativo 1.000 tok/s a carga, PUE 1,45):
Energía por token en el datacenter:
$$E_{\text{DC}} = \frac{3{.}200\ \text{W} \times 1{,}45}{1{.}000\ \text{tok/s}} = 4{,}64\ \text{J/tok} = 1{,}29 \times 10^{-3}\ \text{Wh/tok}$$
| País / hora | Intensidad (gCO₂/kWh) | gCO₂ por 1.000 tokens | gCO₂ por 1M tokens |
|---|---|---|---|
| Francia (media 2025) | 19,6 | 0,025 | 25,3 |
| España solar (mediodía verano) | ~50 | 0,064 | 64,5 |
| España media 2024 | ~108 | 0,140 | 139,3 |
| España gas nocturno (invierno) | ~220 | 0,284 | 283,8 |
| Alemania media 2025 | ~328 | 0,423 | 423,0 |
| Alemania pico carbón | ~550 | 0,709 | 709,0 |
El rango es de ×28 entre Francia media y Alemania pico. Entre los dos extremos horarios de España (solar vs. gas nocturno invierno) la diferencia es ×4,4. La elección del país y de la hora de ejecución mueve el carbono por token más que cualquier optimización de hardware o motor en ese rango.
Scope 2 y Scope 3: qué se contabiliza y qué no
Scopes del GHG Protocol
El GHG Protocol define tres alcances para las emisiones corporativas:
| Scope | Definición | Ejemplo en datacenter |
|---|---|---|
| Scope 1 | Emisiones directas de fuentes propias o controladas | Generadores diésel de emergencia |
| Scope 2 | Emisiones indirectas por consumo de electricidad comprada | Consumo eléctrico del cluster |
| Scope 3 | Otras emisiones indirectas en la cadena de valor | Fabricación del hardware (embodied carbon) |
Para una plataforma de inferencia on-premise, el Scope 2 es la partida dominante en operación; el Scope 3 upstream (fabricación de servidores y GPUs) es típicamente la segunda partida más grande en el ciclo de vida del hardware.
Scope 2: location-based vs market-based
El GHG Protocol Scope 2 Guidance (2015, en revisión pública 2025–2027) establece dos métodos de contabilización, ambos obligatorios en el reporte corporativo:
| Método | Qué mide | Cómo se obtiene |
|---|---|---|
| Location-based | Intensidad real de la red eléctrica donde se ubica la instalación | Factor de emisión de la red nacional o regional (publicado por operadores como REE, RTE) |
| Market-based | Intensidad según los instrumentos contractuales de compra de energía | Garantías de Origen (GdO), PPAs o tarifas con atributo renovable |
La revisión en consulta pública (octubre 2025) propone exigir por primera vez la correspondencia horaria (hourly matching) para el método market-based: comprar 100 MWh de solar en un año no basta si se consumen en horas sin sol. El objetivo es que el market-based refleje la electricidad física y no solo los certificados contables.
Para un cluster de inferencia, el método location-based con intensidad horaria (no media anual) es el más informativo para operación carbon-aware: permite ver en tiempo real qué emisiones genera cada token.
Emisiones marginales vs medias
Esta distinción —documentada por ElectricityMaps y WattTime— es fundamental para evaluar el impacto real de decisiones de scheduling:
| Tipo | Definición | Cuándo usar |
|---|---|---|
| Media (average) | Proporción de todas las emisiones del grid que corresponde al consumidor según su cuota | Reporte de carbono Scope 2 location-based |
| Marginal (MOER) | Emisiones del generador que respondería a un incremento marginal de carga | Evaluar el impacto causal de añadir o mover carga |
Ejemplo doctrinal de ElectricityMaps: en un grid con 50 % eólica (0 gCO₂/kWh) y 50 % gas (500 gCO₂/kWh), la intensidad media es 250 gCO₂/kWh, pero el factor marginal es ~500 gCO₂/kWh (el gas es la planta que responde al incremento de demanda). Reducir carga evita 500 gCO₂/kWh, aunque el reporte Scope 2 registre solo 250 gCO₂/kWh.
Marginal y media nunca deben mezclarse en la misma contabilidad: representan paradigmas de atribución distintos (GHG Protocol y ElectricityMaps lo explicitan).
Scope 3: el carbono embebido del hardware
El carbono embebido (embodied carbon) es la huella de CO₂eq generada durante la fabricación, transporte y fin de vida del hardware. Para GPUs y servidores de alto rendimiento, esta partida es significativa:
| Concepto | Valor orientativo | Fuente |
|---|---|---|
| Vida útil de un servidor en datacenter | 3–5 años | AWS / sector |
| Vida útil de la instalación datacenter | 15–20 años | sector |
| Metodología de amortización | Embodied carbon / años de vida útil | GHG Protocol / AWS methodology 2025 |
| Embodied carbon de un servidor AI (orientativo) | 1.000–3.000 kgCO₂eq (cradle-to-gate) | AWS Embodied Carbon methodology |
El carbono embebido se amortiza sobre la vida útil del hardware: un servidor con 1.500 kgCO₂eq de embodied carbon y 4 años de vida útil aporta 375 kgCO₂eq/año de Scope 3, independientemente de cuánto se use. La tasa de utilización alta reduce el carbono embebido por token (el mismo hardware produce más valor funcional).
Ninguno de los leaderboards públicos de energía de LLM (HF AI Energy Score, ML.ENERGY, MLPerf Power) incluye el Scope 3 en sus métricas. La especificación SCI lo incorpora explícitamente.
La conversión completa: de J/token a gCO₂/token
La ecuación
$$\text{gCO}{2}\text{/token} = \frac{E{\text{placa}}\ [\text{Wh/tok}] \times \text{PUE} \times I_{\text{grid}}\ [\text{gCO}_{2}\text{/kWh}]}{1{.}000}$$
donde:
- (E_{\text{placa}}) es la energía por token medida a nivel de GPU/nodo (sin PUE)
- (\text{PUE}) multiplica por el overhead del datacenter
- (I_{\text{grid}}) es la intensidad de carbono del grid en el momento de ejecución
- La división por 1.000 convierte Wh a kWh
Para el nodo de referencia (4×H100 SXM, throughput 1.000 tok/s, consumo GPU+CPU+RAM 3.200 W, PUE 1,45):
$$E_{\text{placa}} = \frac{3{.}200\ \text{W}}{1{.}000\ \text{tok/s}} = 3{,}2\ \text{J/tok} = 8{,}9 \times 10^{-4}\ \text{kWh/tok}$$
Luego, aplicando PUE 1,45:
$$E_{\text{DC}} = 8{,}9 \times 10^{-4} \times 1{,}45 = 1{,}29 \times 10^{-3}\ \text{kWh/tok}$$
Y las emisiones:
$$\text{gCO}{2}/\text{tok} = 1{,}29 \times 10^{-3} \times I{\text{grid}}$$
Tabla completa por región y hora
| Escenario | PUE | Intensidad grid (gCO₂/kWh) | gCO₂/1.000 tok | gCO₂/1M tok |
|---|---|---|---|---|
| Francia media 2025 | 1,45 | 19,6 | 0,025 | 25,3 |
| España solar (mediodía verano) | 1,45 | 50 | 0,064 | 64,5 |
| España media 2024 | 1,45 | 108 | 0,139 | 139,3 |
| España gas nocturno (invierno) | 1,45 | 220 | 0,284 | 283,8 |
| Alemania media 2025 | 1,45 | 328 | 0,423 | 423,0 |
| Alemania pico carbón | 1,45 | 550 | 0,709 | 709,0 |
| España solar + PUE hiperscale | 1,12 | 50 | 0,050 | 50,0 |
| España gas nocturno + PUE legacy | 1,80 | 220 | 0,354 | 354,0 |
El factor PUE importa más en los escenarios de alta intensidad: pasar de PUE 1,12 a 1,80 en Alemania pico carbón mueve el resultado de ~617 a ~860 gCO₂/1M tok (+39 %). En España solar, el mismo cambio de PUE mueve de 50 a 79 gCO₂/1M tok; la intensidad baja del grid amortigua el impacto del PUE deficiente.
Carbon-aware shifting: temporal y espacial
Principio y herramientas
El carbon-aware computing consiste en ejecutar carga flexible —batch, entrenamiento, fine-tuning, ingestión documental— cuando y donde la intensidad de carbono del grid es menor. La herramienta OSS de referencia es el Carbon Aware SDK (Green Software Foundation, Apache 2.0): un wrapper que consulta ElectricityMaps o WattTime y devuelve la intensidad actual y prevista para una zona y ventana temporal.
El SDK distingue dos tipos de shifting:
| Tipo | Descripción | Aplicable a |
|---|---|---|
| Temporal | Retrasar o adelantar la ejecución dentro del mismo datacenter hasta una hora de menor carbono | Batch, entrenamiento, tareas diferibles con deadline holgado |
| Espacial | Mover la carga a una región geográfica con menor intensidad en ese momento | Multi-cloud o multi-datacenter; requiere replicación de modelo/datos |
Para una plataforma on-premise en un único datacenter, solo el shifting temporal es inmediatamente aplicable. El shifting espacial requiere infraestructura multi-sitio.
Cuantificación del ahorro temporal
La investigación reciente (arXiv 2512.07799, 2512.08725; Microsoft Carbon-Aware Computing Whitepaper) cuantifica el ahorro de shifting temporal de carga batch:
| Estudio / caso | Ahorro de emisiones | Condiciones |
|---|---|---|
| Carga batch con shifting 24 h (simulación, varios grids) | 20–40 % de reducción de emisiones | Ventana de 24 h, grid con mezcla renovables-fósil |
| Entrenamiento ML con shifting contra previsión grid (Microsoft) | ~30 % | Azure, shifting contra intensidad prevista |
| Heurísticas greedy vs óptimo (arXiv 2512.07799) | ≥ 90 % del óptimo | Simple one-migration o greedy deferral |
| UBS + Microsoft, Azure Batch, ventana 24 h | Validado con Carbon Aware SDK | Shifting temporal real en producción |
Para España, donde la correlación precio-carbono es −0,70, el shifting a horas solares reduce simultáneamente el coste eléctrico y las emisiones por token. En los 477 horas con precio negativo registradas en 2025 (ElectricityMaps / REE), la intensidad de carbono era también mínima. La coincidencia entre hora limpia y hora barata hace que el scheduling carbon-aware no tenga coste de oportunidad económico en España: optimizar carbono y coste apuntan a la misma ventana horaria.
Cuantificación para el nodo de referencia
Para una tarea batch de 1 hora en el nodo de referencia (4×H100 SXM, 4.640 W totales con PUE 1,45), generando ~3.600 millones de tokens por hora:
| Escenario | Intensidad (gCO₂/kWh) | Emisiones por hora de batch | Ahorro vs ejecución no diferida |
|---|---|---|---|
| Sin shifting (España media) | 108 | 501 gCO₂ | — |
| Con shifting a hora solar (50 gCO₂/kWh) | 50 | 232 gCO₂ | −54 % |
| Con shifting a hora gas nocturno (220 gCO₂/kWh) | 220 | 1.021 gCO₂ | +104 % (peor momento) |
El rango entre el peor y el mejor momento para ejecutar ese batch es ×4,4 en emisiones. El shifting a la hora más limpia disponible en una ventana de 24 horas en España evita típicamente entre el 40 % y el 60 % de las emisiones del trabajo diferible.
El estándar SCI: Software Carbon Intensity
Especificación
La Software Carbon Intensity (SCI) es una especificación de la Green Software Foundation, publicada como estándar ISO/IEC 21031:2022 y mantenida en GitHub (github.com/Green-Software-Foundation/sci). Define una tasa de emisiones de carbono por unidad funcional de software:
$$\text{SCI} = \frac{(E \times I) + M}{R}$$
donde:
| Símbolo | Significado | Unidades |
|---|---|---|
| (E) | Energía consumida por el sistema software (servidores, red, dispositivos de usuario) | kWh |
| (I) | Intensidad de carbono de la energía consumida (location-based u otra declarada) | gCO₂eq/kWh |
| (M) | Carbono embebido del hardware, amortizado por tiempo de uso y porcentaje de utilización | gCO₂eq |
| (R) | Unidad funcional (el denominador que normaliza la tasa) | por API call, por token, por usuario, etc. |
Para una plataforma de inferencia LLM, (R) es naturalmente el token de salida o la query. El SCI en gCO₂eq/token incluye así los tres componentes que la mayoría de los análisis actuales omiten: PUE implícito en (E), intensidad horaria en (I), y embodied carbon en (M).
Diferencia clave respecto al cálculo simple
El cálculo (E \times I) (energía × intensidad de grid) es el Scope 2 operacional. El SCI añade (M), el Scope 3 del hardware, que tiene una estructura diferente:
$$M = \frac{\text{embodied carbon total (gCO2eq)}}{\text{vida útil (horas)}} \times \frac{\text{horas de uso}}{1} \times \frac{\text{recursos asignados}}{\text{recursos totales del servidor}}$$
Para un servidor AI con 1.500 kgCO₂eq de embodied carbon, 4 años de vida útil (~35.040 horas) y utilización del 80 %:
$$M_{\text{hora}} = \frac{1{.}500{.}000\ \text{gCO2eq}}{35{.}040\ \text{h}} \times 0{,}80 \approx 34\ \text{gCO2eq/h}$$
Con 3.600 millones de tokens por hora:
$$M_{\text{por token}} \approx \frac{34}{3{,}6 \times 10^{9}} \approx 9{,}4 \times 10^{-9}\ \text{gCO2eq/tok}$$
A esta escala, el embodied carbon por token es despreciable frente al Scope 2 operacional durante la operación. Sin embargo, (M) se vuelve dominante en dos casos: hardware subutilizado (baja utilización amplifica el coste por token) y hardware con ciclo de vida muy corto (chips reemplazados cada 2 años en vez de 4).
El SCI como métrica de referencia para el track
La especificación SCI y su extensión para IA (github.com/Green-Software-Foundation/sci-ai) están siendo adoptadas como métrica de referencia para reportar la huella de carbono de sistemas de IA en empresas sujetas a CSRD. Proporciona un denominador común —gCO₂eq por unidad funcional— que permite comparar arquitecturas, regiones y estrategias de scheduling sobre la misma base.
Límites del cálculo y honestidad
Ningún cálculo de gCO₂/token captura la realidad completa. Los límites del modelo expuesto en este artículo:
| Límite | Descripción |
|---|---|
| Intensidad media anual vs horaria | Usar la media anual del país como factor de emisión da un resultado estable pero ficticio. La intensidad varía ×4–10× intradía. Para reporting Scope 2 location-based con datos horarios, la diferencia puede ser del 30–50 % respecto a la media. |
| PUE estático | El PUE varía con la temperatura exterior (la refrigeración trabaja más en verano) y con la carga IT. El PUE declarado es una media; en días calurosos puede ser 10–20 % peor. |
| Throughput constante | El cálculo usa throughput a carga máxima. En producción con variabilidad de demanda, el consumo no escala linealmente con el throughput; la eficiencia por token empeora con baja carga. |
| Scope 3 parcial | El carbono embebido aquí cubre solo el hardware IT. No incluye la construcción del edificio del datacenter, la fabricación de equipos de refrigeración, ni la cadena de suministro de la energía. |
| Factores de emisión nacionales | Los valores por país son medias anuales. Francia tiene variación intradiaria baja (nuclear domina); España y Alemania tienen variación alta. El factor nacional es útil para comparaciones de orden de magnitud, no para scheduling operativo. |
| Carbono embebido de las GPUs | Los datos de lifecycle assessment de chips AI como H100 no son públicos. Las estimaciones se basan en modelos de área de die, que tienen incertidumbre ±30–50 %. |
| Shifting espacial omitido | Este artículo cubre solo shifting temporal. El shifting espacial (mover carga entre regiones) puede añadir otro 20–40 % de reducción pero requiere infraestructura multi-sitio. |
| Cooling water y otros impactos | El gCO₂eq no captura el consumo de agua de refrigeración (WUE, Water Usage Effectiveness), otro indicador de impacto ambiental relevante para zonas áridas como el sur de España. |
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
- C5 — Leaderboards de energía de LLM
Fuentes
- Uptime Institute · Global Data Center Survey 2025 (PUE medio global 1,54, 15.ª edición) — https://uptimeinstitute.com/resources/research-and-reports/uptime-institute-global-data-center-survey-results-2025
- Uptime Institute Blog · Global PUEs — are they going anywhere? — https://journal.uptimeinstitute.com/global-pues-are-they-going-anywhere/
- Uptime Institute Blog · Large data centers are mostly more efficient — https://journal.uptimeinstitute.com/large-data-centers-are-mostly-more-efficient-analysis-confirms/
- ElectricityMaps · Electricity Grid Review 2025: Spain (precio, intensidad, correlación precio-carbono −0,70) — https://www.electricitymaps.com/grid-in-review-2025/spain
- ElectricityMaps · Marginal emissions — what they are, and when to use them (actualizado enero 2025) — https://www.electricitymaps.com/resources/publications/marginal-emissions-introduction
- ElectricityMaps · Interactive map and API — https://app.electricitymaps.com
- WattTime · Average vs marginal emissions — https://watttime.org/data-science/data-signals/average-vs-marginal/
- WattTime · REsurety-WattTime free global marginal emissions platform (marzo 2025) — https://watttime.org/news-and-insights/resurety-and-watttime-announce-release-of-free-electricity-marginal-carbon-platform/
- Red Eléctrica de España (REE) · Renewable energies generated 56 % of Spain’s electricity mix in 2024 — https://www.ree.es/en/press-office/press-release/news/press-release/2025/01/renewable-energies-generated-56-per-cent-spains-electricity-mix-2024
- Nowtricity · CO₂ emissions per kWh in Spain (media 2024: 108 gCO₂eq/kWh) — https://www.nowtricity.com/country/spain/
- RTE · Bilan électrique 2025 — GHG Emissions (Francia 2025: 19,6 gCO₂eq/kWh) — https://analysesetdonnees.rte-france.com/en/annual-review-2025/ghg-emissions
- RTE · Bilan électrique 2024 key findings (Francia 2024: 21,7 gCO₂eq/kWh) — https://assets.rte-france.com/analyse-et-donnees/2025-11/RTE%20-%20Annual%20electricity%20review%202024%20-%20Key%20findings.pdf
- Fraunhofer ISE · German Public Electricity Generation in 2025 (Alemania 2025: ~328 gCO₂/kWh) — https://www.ise.fraunhofer.de/en/press-media/press-releases/2026/german-public-electricity-generation-in-2025-wind-and-solar-power-take-the-lead.html
- Ember · European Electricity Review 2025 (intensidad UE media: 213 gCO₂/kWh) — https://ember-energy.org/latest-insights/european-electricity-review-2025/five-years-of-progress/
- GHG Protocol · Scope 2 Standard Advances (consulta pública 2025, hourly matching, market-based revisions) — https://ghgprotocol.org/blog/scope-2-standard-advances-isb-approves-consultation-market-and-location-based-revisions
- GHG Protocol · Public Consultation Scope 2 (octubre 2025) — https://ghgprotocol.org/sites/default/files/2025-10/GHG-Protocol-Scope2-Public-Consultation.pdf
- Green Software Foundation · Software Carbon Intensity (SCI) Specification — https://sci.greensoftware.foundation/
- Green Software Foundation · SCI GitHub (ISO/IEC 21031:2022) — https://github.com/Green-Software-Foundation/sci
- Green Software Foundation · SCI for AI — https://github.com/Green-Software-Foundation/sci-ai
- Green Software Foundation · Carbon Aware SDK (Apache 2.0) — https://github.com/Green-Software-Foundation/carbon-aware-sdk
- Green Software Foundation · Carbon-Aware Computing Whitepaper — UBS/Microsoft Azure Batch case — https://greensoftware.foundation/articles/carbon-aware-computing-whitepaper-how-ubs-succeeded-in-measuring-and-reducing-car/
- arXiv 2512.07799 · Quantifying the Carbon Reduction of DAG Workloads: A Job Shop Scheduling Perspective — https://arxiv.org/abs/2512.07799
- arXiv 2512.08725 · Spatio-Temporal Shifting to Reduce Carbon, Water, and Land-Use Footprints of Cloud Workloads — https://arxiv.org/abs/2512.08725
- AWS · How AWS estimates embodied emissions of IT hardware (Scope 3 methodology, 2025) — https://aws.amazon.com/blogs/infrastructure-sustainability/how-aws-estimates-embodied-emissions-of-it-hardware-the-science-and-technology-behind-the-latest-customer-carbon-footprint-methodology/
- CodeCarbon · Track and reduce CO₂ emissions from your local computing — https://codecarbon.io/