Day 14 — The Grid You Didn't Choose

June 23, 2026 View as markdown

Most production AI systems run in a region somebody picked years ago, on hardware procured for a different workload, and on schedules chosen for operational convenience rather than carbon performance. None of those choices were carbon-aware. Most of them are still in place.

The same inference call can carry very different carbon footprints depending on where and when it runs. A workload that is low-carbon in one region may be significantly more carbon-intensive in another. A job that runs at midnight on the local grid may be drawing largely from coal; the same job at 2pm may be drawing largely from solar. The model does not know. The bill is roughly the same. The atmosphere is not.

Efficient systems first eliminate unnecessary work through caching, batching, and loop discipline. Placement then determines how cleanly the remaining work runs. It is the part of the stack almost nobody owns — set by inertia, by the first region the platform team stood up, the accelerator generation the procurement contract specified, the cron schedule somebody typed in once and never revisited. It is also one of the most underused efficiency levers in AI systems today. This issue is about putting it to work.

A retail platform runs a nightly summarisation pipeline that processes the day’s customer interactions. The job takes about four hours and dispatches tens of millions of tokens. Nothing about it is time-sensitive — the output is read the next morning. A sustainability lead asks a simple question: where does this run, and when?

The answer is that it runs in the company’s default cloud region, chosen three years ago for proximity to a primary database, and it runs at 11pm local time because that was when the engineer who built it had a free window on the cluster. Neither decision considered grid carbon intensity. Both have been quietly compounding ever since.

The review surfaces three patterns that show up across most teams.

The default region. The cluster lives where it was first stood up. Migration is rarely revisited even when grid intensity data shows another region in the same provider operates at a fraction of the carbon per kilowatt-hour.

The default fleet. The job runs on whatever accelerator the team has standing capacity for. Newer accelerator generations deliver meaningfully more work per watt for the same workload, but the upgrade tends to get treated as a procurement question rather than an efficiency one.

The default clock. The schedule matches human working hours. The grid does not. The cleanest hour of the day on most grids is rarely 9 to 5, and rarely 11pm either.

Placement is the part of the bill the model never sees and the grid always pays.

The objection is reasonable. Data residency, latency commitments, and sovereignty rules constrain where some workloads can run. Many cannot be moved at all. The point is not to migrate everything — it is to identify the workloads that can move, and to stop treating placement as a setting that gets configured once and forgotten.

Four moves, applied in order. Each rung is independent — a team can pull one without committing to the others.

Map. Establish the carbon intensity profile of the regions, accelerators, and schedules currently in use. Public grid intensity data is available through several providers, and cloud platforms publish region-level sustainability disclosures. The map is the precondition for every move that follows.

Move. Shift latency-tolerant workloads to cleaner regions or cleaner windows. Batch jobs, evaluation runs, embedding refreshes, and overnight pipelines are the typical first candidates. The move can be spatial, temporal, or both.

Match. Route the workload to the accelerator generation that actually fits it. A small classification model on a frontier accelerator is overprovisioned. A large model on an older accelerator is underprovisioned. The goal is not the fastest accelerator. It is the lowest carbon per successful outcome.

Verify. Measure grams of CO₂e per request, not only cost per request. The two correlate but are not the same. A region that is cheap in dollars may be expensive in carbon, and the reverse is also true.

Placement looks different from each seat at the table, but the lever is the same.

Engineering. Region and schedule are deployment parameters, not defaults. Adding a carbon-intensity check to the deployment workflow is closer to a configuration change than a re-architecture.

Platform/Infrastructure. Carbon-aware scheduling belongs in the platform layer. Workloads tagged as latency-tolerant should be routed by the scheduler to the cleanest available region and window, the same way they are routed for cost or capacity today.

Architecture/CTO. Placement is a design parameter for new systems, not a deployment afterthought for existing ones. New services should be specified with a placement profile: where they may run, where they must not run, when they can be deferred, and what latency they can tolerate.

Sustainability/ESG. Grams of CO₂e per request is the metric that connects engineering choices to disclosure commitments. Tracking it makes the carbon impact of placement decisions legible to the people who report them.

Business/Product. Latency tolerance is a product offering. “Results available within the hour” is not a degraded experience. It is a class of service that costs less to deliver and carries a smaller footprint. Pricing and product surfaces can reflect that.

Five seats, one principle: placement is a decision the system makes whether or not anyone is making it.

The work begins with a single workload, not a portfolio review. The point is to make the carbon delta visible before scaling the practice.

Pick one latency-tolerant pipeline — a nightly batch, an embedding refresh, an evaluation suite. Pull grid intensity data for the current region and at least one alternative. Record the accelerator generation currently in use and evaluate at least one newer or more efficient alternative. Run the same job in the current placement and in the proposed placement. Compare grams of CO₂e per thousand requests, not only dollars per thousand requests. Publish the delta to the team that owns the workload.

Placement is not free of risk. Cross-region egress costs can be material. Data residency and sovereignty rules apply unevenly. A region that is clean today may be congested tomorrow, and capacity is not always available where the grid is cleanest. Start with the workload where constraints are loosest and volume is highest. Tune from there.

One workload, one map, one move. That is the work.

The cleanest watt is the one you chose. The dirtiest is the one you defaulted to.

The next chapter widens the lens beyond the call itself. Single-call efficiency, loop discipline, caching, batching, and placement all matter. The system around the model — the data path, the monitoring layer, the eval pipeline, the retraining cadence — has its own waste profile, and it is often larger than the call it supports.