Carbon-Aware Scheduling for AI Datacenters

Q: What is carbon-aware scheduling?

Carbon-aware scheduling is the practice of using a live signal about the electricity grid — how carbon-intensive and how expensive power is, right now and in the forecast — as an input to decisions about when and where computing workloads run. Instead of running every job the moment it is submitted in whatever region is default, a carbon-aware system defers flexible work to a cleaner, cheaper hour within its deadline, or places it in a region whose grid is currently greener. The core idea is that a large fraction of data-center work is not latency-sensitive: model training, ETL pipelines, batch evaluation, and reindexing can tolerate being delayed by hours or moved between regions, and if you move that flexible load to when the grid is running on wind and solar rather than gas peakers, you cut both emissions and cost without buying any additional capacity. It is deliberately unglamorous engineering — a signal wired into schedulers you already run, such as Kubernetes CronJobs, Spark, or Airflow — rather than a new platform, and it works because the cleanest hour on the grid is usually also the cheapest.

Q: Why use marginal carbon intensity instead of the grid average?

Because shifting load only changes what happens at the margin, and the grid average does not describe the margin. The average carbon intensity tells you how clean the overall generation mix was over some period — a backward-looking descriptive number. The marginal carbon intensity tells you the emissions of the specific generator that will ramp up (or down) to serve your next unit of demand, which is exactly what your decision to run a job now actually causes. If you optimise against the average, you can move a job to an hour that looks clean on paper but in reality triggers a gas peaker to spin up, so your "green" schedule increases emissions. Optimising against the marginal signal aligns the decision with its real-world effect. WattTime publishes a marginal operating emissions rate designed precisely for load-shifting decisions, and Electricity Maps provides both real-time and forecast carbon intensity by grid zone. The forecast is essential: to defer a job to the cleanest hour in the next 24 to 48, a scheduler has to predict the curve, not merely read the current value, so it can decide whether waiting will actually help before the deadline.

Q: Which workloads can be carbon-aware scheduled and which cannot?

The dividing line is flexibility. Deferrable batch workloads — model training, ETL jobs, offline evaluation sweeps, search reindexing, report generation — can be time-shifted, because they have a deadline that is hours or days away rather than milliseconds, so a scheduler can wait for a cleaner hour. Relocatable workloads that are region-agnostic and whose data is already available in multiple regions can be spatially shifted to a greener grid. Best-effort or speculative work, such as pre-computing recommendations, can be demand-shaped — throttled or paused when the grid is dirty and expensive. What cannot be carbon-aware scheduled is interactive, latency-bound load: a user waiting for a chatbot response or a search result cannot have their request deferred to 3am, and applying carbon-aware delay to serving traffic simply breaks the service-level objective. That served load must instead be handled on the supply side, by procuring firm clean power, rather than by shifting. Being honest about this boundary is what keeps a carbon-aware program credible; the mistake that discredits these initiatives is trying to shift inference that fundamentally cannot move.

Q: Do carbon-aware scheduling and cost optimisation conflict?

Usually they align, which is what makes carbon-aware scheduling attractive rather than a sacrifice. The reason is structural: when the grid is rich in wind and solar, wholesale electricity prices fall because that generation has near-zero marginal cost, and those same hours are the low-carbon hours. Conversely, at demand peaks the grid dispatches carbon-heavy peaker plants that are both the most expensive and the dirtiest generators, setting a high price and a high emissions rate simultaneously. So for the large class of deferrable and relocatable workloads, moving to the cleanest hour is typically moving to the cheapest hour, and carbon-aware scheduling is the same optimisation as reducing your energy bill rather than a tax you pay for sustainability. They are correlated, not identical, however, so a mature system feeds both a carbon signal and a price signal into the scheduler, and when the two diverge it lets the workload deadline and the service-level objective break the tie rather than blindly optimising a single metric. Tracking carbon per token alongside cost per token keeps both visible as first-class KPIs.

Q: How do PPAs and SMRs fit into a carbon-aware architecture?

They are the supply-side complement to demand-side scheduling, aimed at the load that cannot be shifted. Because interactive inference and always-on serving must run whenever users arrive, you cannot make that load clean by timing it; you make it clean by procuring clean power for it. Power purchase agreements (PPAs) for wind and solar are the established mechanism, and the credible version is hourly-matched procurement — buying clean generation that matches your consumption hour by hour — rather than unbundled annual offsets that merely net out over a year. In 2026 hyperscalers have gone further, securing firm 24/7 carbon-free supply through nuclear: restarting existing reactors under long-term PPAs and committing to small modular reactors (SMRs), because unlike wind and solar, nuclear provides constant output that matches always-on load. The correct division of labour is that procurement makes the un-shiftable served load clean while scheduling makes the shiftable batch load clean, and neither substitutes for the other. Buying a nuclear PPA does not justify running batch jobs at the dirtiest hour, and wiring a carbon signal into a scheduler does not supply a gigawatt of serving demand. The mature answer does both, matching each lever to the workload it can actually move.

Q: What tools exist for carbon-aware scheduling?

The signal providers and an integration layer are the main pieces, and you attach them to schedulers you already run. For the grid signal, WattTime provides a marginal operating emissions rate API built for load-shifting decisions, and Electricity Maps provides real-time and forecast carbon intensity by grid zone. For integration, the Green Software Foundation publishes the open-source Carbon Aware SDK, which normalises those providers behind a single API so your systems can ask a simple question — "within my deadline window, when and where is the cleanest hour" — without coding against each data source separately. On the placement side, cloud providers expose their own metrics: Google Cloud publishes a per-region Carbon Free Energy percentage (CFE%) and grid carbon intensity in grams of CO2-equivalent per kilowatt-hour, and defines a low-carbon region as one with at least 75% CFE or at most 200 gCO2eq/kWh, which you can enforce with resource-location policies. The deliberate design principle is to avoid a bespoke carbon platform: wire the signal into your existing Kubernetes CronJobs, Spark scheduler, or Airflow DAGs, start with the single largest deferrable job, prove the carbon and cost delta, and then widen coverage across the flexible fleet.

Q: How much electricity do AI data centers actually use?

Enough that it now shapes national grids. The US Department of Energy's 2024 data center energy report found US data centers consumed about 176 terawatt-hours in 2023, which is 4.4% of total US electricity, and it projects that figure rising to between 325 and 580 TWh by 2028 — roughly 6.7% to 12% of national electricity — as data-center load, which the report notes has tripled over the past decade, doubles or triples again. That trajectory is why energy has become the binding constraint on AI expansion rather than chips or floor space: when a single class of facility is heading toward a tenth of a country's electricity, its consumption is no longer a rounding error the grid can absorb quietly, and both the price and the carbon content of that power become strategic variables. This scale is precisely what makes carbon-aware scheduling worth the engineering: a flexible workload that represents even a small slice of a very large and growing energy footprint is a meaningful lever on both emissions and cost, and choosing when and where it runs is a decision that, at fleet scale, moves real megawatts and real money.

Q: Is buying carbon offsets a substitute for carbon-aware scheduling?

No, and treating offsets as a substitute is one of the anti-patterns that undermines these programs. Unbundled carbon offsets are typically annual and geographically unrelated to your actual consumption: they let an organisation claim net-zero on paper by purchasing credits that do not correspond to the specific hours and locations where its load actually ran. That papered over the timing problem rather than solving it. The credible mechanisms are the ones that address consumption where and when it happens — real load-shifting that moves flexible work to genuinely cleaner hours, and hourly-matched procurement that buys clean generation aligned to your consumption profile hour by hour rather than netted out over a year. The industry shift toward 24/7 carbon-free energy accounting exists precisely because annual offset matching was too coarse to reflect real grid impact. Offsets may still have a limited role for residual emissions that cannot yet be addressed operationally, but they are not an alternative to the engineering: if you can shift a batch job to a clean hour or procure firm clean power for served load, doing so is a real reduction, whereas an offset is a financial instrument layered on top of unchanged consumption.

Satyam Kumar

Volver al Blog

ai-architecture

Carbon-Aware Scheduling: Energy as an Architecture Input for AI Datacenters (2026)

By Satyam KumarSeptember 20, 202610 min read

carbon-aware scheduling datacenter energy marginal carbon intensity watttime electricity maps carbon aware sdk ai energy consumption carbon free energy power purchase agreement small modular reactor green software sustainable ai workload scheduling grid carbon intensity ai datacenter power energy-aware architecture

Carbon-Aware Scheduling: Energy as an Architecture Input for AI Datacenters (2026)

Frequently Asked Questions

Compartir este artículo

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Arquitecto de IA y Cloud. Ayudando a equipos a construir sistemas que escalan a millones.

LinkedIn GitHub

Carbon-Aware Scheduling: Energy as an Architecture Input for AI Datacenters (2026)

Frequently Asked Questions

Compartir este artículo

Comments

Leave a comment