Every query, batch job and model call runs on hardware that draws power. For most of the history of enterprise software that cost was small enough to ignore. AI workloads, always-on pipelines and growing cloud estates have changed that, and sustainability reporting increasingly asks technology teams to account for it.
Green software is not a separate discipline. It is efficiency, measured in a unit the business has started to care about.
You cannot reduce what you do not measure
Start with visibility. Useful sources include:
- Cloud provider carbon and energy reporting for your accounts
- Utilisation metrics for compute, storage and GPUs
- Request volumes and token counts for AI workloads
- Grid carbon intensity data for the regions you run in
None of these is perfect. Provider reports are often delayed and aggregated. Estimates for model inference depend on assumptions. That is fine for a start: consistent, approximate measurement is far more useful than precise measurement nobody does.
The Software Carbon Intensity specification from the Green Software Foundation offers a way to express emissions per unit of work — per transaction, per user, per document processed. A rate is easier to improve than a total.
Where the waste usually is
In most estates the biggest gains are unglamorous:
- Idle resources — development environments, clusters and databases running around the clock
- Over-provisioning — instances sized for a peak that rarely arrives
- Unused data — stored, replicated and backed up long after anyone reads it
- Chatty pipelines — full reprocessing where incremental loads would do
- Unread outputs — reports and streams produced on schedule for nobody
Fixing these lowers carbon and cost at the same time. That alignment makes the case easier to win.
AI-specific levers
Model workloads have their own options:
- Right-size the model — a smaller model that passes your evaluation uses less compute per request than a larger one that also passes
- Route by difficulty — send simple requests to small models and escalate only when needed
- Cache — repeated questions and stable context do not need fresh inference every time
- Trim context — retrieval that sends fewer, better passages cuts tokens and often improves answers
- Batch where latency allows — offline jobs can run on efficient schedules
- Question retraining frequency — fine-tuning on a fixed calendar may not be needed
Each of these needs an evaluation suite behind it. Efficiency that quietly lowers quality is not a saving.
Location and timing
The same workload emits differently depending on where and when it runs. Regions with cleaner grids, and flexible jobs scheduled for times of lower carbon intensity, can reduce emissions without changing code. This has to be weighed against residency rules and latency needs, which come first.
Hardware and lifecycle
Embodied carbon — the emissions from manufacturing hardware — matters too. Higher utilisation of existing machines, longer hardware lifecycles on-premise and avoiding unnecessary duplication all help. In the cloud, choosing efficient instance types and keeping utilisation high is the practical equivalent.
Make it part of normal engineering
Green software works best as a non-functional requirement alongside performance and cost:
- Include efficiency in architecture reviews
- Show energy or carbon estimates next to cost in dashboards
- Set a target per unit of work for major services
- Review the largest workloads quarterly
Avoid claims you cannot support. Report what you measured, how, and what changed.
Where to start
- Turn on the carbon and utilisation reporting your cloud providers offer
- Pick the five largest workloads and find their idle and over-provisioned resources
- Define one unit-of-work metric for an AI system and track it
- Test a smaller model or a routing approach against your evaluation set
- Add efficiency to the architecture review checklist
Incubics builds systems with cost and efficiency measured from the start, which is where most carbon reduction begins.