Measure the Energy Intensity of Your Software
Every software system consumes energy through the hardware it runs on. The Software Energy Intensity (SEI) specification provides a methodology for calculating the energy consumption rate of a software system — a score where lower is better and reaching zero is impossible.
What is SEI?
SEI is a rate — energy consumption (kWh) per one functional unit of work. It gives developers and organisations a clear, comparable number that captures how efficiently their software uses energy. Reducing an SEI score is only possible through actions that genuinely reduce energy consumption: modifying software to use less hardware, use hardware more efficiently, or shift computation to more energy-efficient infrastructure.
Why Energy Intensity Matters
The SCI specification measures carbon intensity — combining energy, grid carbon intensity, and embodied emissions. By focusing solely on energy, SEI isolates the signal to just energy consumption without the variability of grid carbon intensity in the mix. This is what's needed to truly focus on energy efficiency rather than carbon efficiency — giving teams a clear, undiluted measure of how much electricity their software consumes.
The SEI Formula
SEI calculates energy consumption per functional unit. The formula accounts for facility overhead through PUE (Power Usage Effectiveness), ensuring that cooling, power conversion, and other infrastructure costs are captured.
SEI = E per R
E — Energy
The total energy the software causes to be consumed, calculated as the sum of each component's energy multiplied by the PUE of its facility. Measured in kilowatt hours (kWh).
R — Functional Unit
A quantified performance characteristic that describes how the application scales — per API call, per user, per transaction, per device, or per data volume.
The Software Boundary
The first step in generating an SEI score is deciding what to include in the measurement. The boundary should include all components that significantly contribute to the software's energy consumption.
Compute Resources
All computational hardware — processors, GPUs, TPUs, AI accelerators — performing work within the software boundary.
Host Systems & Idle Capacity
Energy consumed by host machines, memory, and reserved capacity that is idle but provisioned for availability and failover.
Facility Overhead & Networking
Cooling, power conversion, and other facility overhead (captured via PUE), plus networking equipment including routers, switches, and load balancers.
Software Sustainability Actions
All actions that reduce an SEI score fit into two categories: energy efficiency (making software use less electricity for the same function) and hardware efficiency (making software use fewer physical resources for the same function). The specification is designed to encourage more of these actions during the design, development, and maintenance of software.
Quantification Methods
There are three approaches to quantifying energy consumption. Each component in the boundary can use whichever approach is most appropriate.
Measurement
Real-world energy data from power monitoring equipment, smart PDUs, hardware sensors (RAPL, NVML), cloud provider energy APIs, or device-level power measurement.
Calculation
Modelled energy consumption using hardware specifications, TDP ratings, utilisation metrics combined with power curves, or vendor estimation tools.
Coefficients
Published energy values such as cloud provider data per instance type, industry-standard coefficients for hardware, or third-party SEI scores for subcomponents.
Reducing an SEI score is only possible through actions that reduce energy consumption. This can be achieved by modifying a software system to use less physical hardware, use hardware more efficiently, or shift computation to more energy-efficient infrastructure.
Project Leadership
Get Involved
The Software Standards Working Group meets every Thursday at 15:00 UTC. We welcome all GSF members to join the call, share their perspectives, and help shape our standards together.
