Del vatio al carbono, honestamente: PUE, intensidad del grid y gCO₂ por token

Tue, 16 Jun 2026 08:00:00 +0200

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:

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

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/

Scope-2 on lo0 — Blog Técnico