How can IT teams use peak and off peak electricity pricing to reduce infrastructure operating costs?

IT teams can reduce infrastructure operating costs by matching flexible workload schedules to time-of-use electricity prices. The source v3.2 energy-management design explicitly tracks peak and off-peak tariffs, identifies interruptible tasks that can move to lower-price periods, and calculates the saving for each shift. Its example contains four price periods with a fourfold difference between the lowest and highest tariff.

The important boundary is workload flexibility. Electricity price should influence when suitable work runs. It should not override service SLOs, deadlines, capacity limits, or business priority.

What is peak and off-peak electricity pricing?

Peak and off-peak pricing means the electricity price changes by time period.

The exact tariff can include:

Peak
Shoulder
Off-peak
Other utility-defined periods

The source v3.2 example uses four pricing periods.

That is an example from the platform design, not a universal market structure.

The enterprise should load the actual electricity contract or tariff applicable to each site.

The platform can then calculate energy cost using the correct price for the time the energy was consumed.

Why does time-of-use pricing matter for AI infrastructure?

AI workloads can be energy intensive and some of them are flexible in time.

A large training task may run for hours.

A model evaluation may not need to start immediately.

A batch inference workload may have a completion deadline rather than a real-time latency requirement.

If the electricity price varies significantly during the day, moving these workloads can reduce cost without changing the hardware.

The source energy model connects electricity price with scheduling precisely for this reason.

Which workloads are good candidates for shifting?

Good candidates are workloads whose start time can move without violating service requirements.

Examples can include:

Batch training
Model evaluation
Nonurgent fine tuning
Backfill tasks
Data processing
Some maintenance jobs

The source specifically refers to interruptible tasks.

That is an important word.

A task that can be delayed or interrupted is easier to shift.

The organization should define the flexibility when the workload is submitted.

Do not decide it after the resource is already running.

Which workloads should usually stay where they are?

Online or time-sensitive services should generally be governed by their service requirement first.

Examples include:

Production inference
Customer-facing API
Urgent incident recovery
Deadline-critical training
Critical batch with fixed completion window

A high electricity price does not justify missing an SLO.

The source wider operations model includes service quality, priority, quotas, and SRE.

Energy optimization must remain inside those rules.

How should the tariff be represented?

Store the actual price by site and time period.

Useful fields include:

Data center
Effective date
Time period
Electricity price per kWh
Weekend or holiday rule where applicable
Contract version

The source does not define a tariff data schema.

The practical requirement is that the cost calculation knows which rate applies to each energy interval.

If the electricity contract changes, the new tariff should be versioned rather than rewriting historical cost.

How should workload energy be measured?

Use measured device or allocated workload energy where available.

The source energy model includes:

GPU power
Device-level energy
Project attribution
Unit Token energy

For a workload, integrate the relevant power over its execution period.

Then map that energy to the tariff periods it crossed.

If a job spans peak and off-peak time, the energy should be divided across those periods rather than applying one price to the whole job.

The exact granularity depends on the telemetry.

How should the potential saving be calculated?

Compare the estimated cost at the current schedule with the estimated cost at the proposed schedule.

Conceptually:

Current schedule energy by tariff period.

Proposed schedule energy by tariff period.

Difference equals projected saving.

The source v3.2 design says each shifted workload's saving is calculated individually.

That is useful because not every move saves the same amount.

A short job with low power may not justify operational complexity.

A long high-power job can have material savings.

What assumptions should be shown?

Show the assumptions behind the savings estimate.

Examples:

Workload energy remains similar.

Job duration remains similar.

The same accelerator type is available.

No higher-priority task displaces it.

The target off-peak window has enough capacity.

The job still finishes before its deadline.

The source does not provide one universal forecasting method.

Transparent assumptions make the recommendation reviewable.

How should queue and capacity be considered?

Moving work to off-peak periods can create a new capacity peak.

Suppose many teams shift training jobs to midnight.

Electricity becomes cheaper.

The GPU pool becomes oversubscribed.

Jobs queue and miss deadlines.

The source scheduler already tracks:

Quota
Priority
Queue
Resource availability
Fragmentation

Energy-aware scheduling should therefore check whether the lower-price window has deployable capacity.

Cheap electricity is not useful if the workload cannot start.

How should deadlines be handled?

A flexible workload still needs a completion requirement.

A scheduling rule can consider:

Earliest start
Latest finish
Estimated duration
Resource requirement
Priority
Electricity price

The source does not define a deadline-aware scheduler algorithm.

The source-supported principle is to shift interruptible work without violating the service or project requirement.

The platform should make the reason for the selected window visible.

For the scheduling controls around quotas, priorities, reservations, and preemption, what GPU quotas, reservations, priorities, and preemption mean and when each should be used explains how workload urgency and eligibility should remain separate from energy price.

How should preemption affect energy-aware scheduling?

Preemptible work is easier to move, but interruption can create wasted compute.

The source scheduler supports preemption and checkpoint protection.

If a training job has a recent checkpoint, the platform may be able to pause or reschedule it with limited lost work.

If the job cannot recover safely, interrupting it for a lower electricity rate can cost more than it saves.

Energy optimization should therefore consider checkpoint and restart cost.

How should idle power affect the decision?

A workload moved to off-peak time can still leave hardware powered and idle during peak time.

The source v3.2 energy model also tracks GPU idle power.

That means a scheduling decision should consider both:

Workload energy shifted
Idle energy that remains

If the infrastructure can enter a lower-power state safely during the unused period, the saving may be larger.

If the hardware stays at high idle power, the benefit may be smaller.

The exact power-management action depends on the infrastructure and service requirements.

How should cooling cost be considered?

Moving a large workload changes heat load as well as IT power.

The source energy model connects power and cooling at the facility level through PUE and zone energy.

A shift to off-peak electricity can also shift cooling demand.

That can affect total facility energy.

The source does not define a predictive cooling-cost model for each workload.

A practical calculation can begin with IT energy and then use the approved facility allocation method if the organization includes cooling overhead in the cost model.

For the underlying measurement hierarchy, how organizations can monitor and manage server power consumption at device, rack, and data center level explains how device energy, rack load, and facility energy stay connected.

How should different data centers be compared?

If the enterprise has multiple sites with different tariffs, energy-aware scheduling can become a site-selection question as well as a time-selection question.

The source supports multi-data-center resource views and energy data, but it does not define an automatic cross-site energy scheduler as a completed capability in every deployment.

The source-grounded approach is to compare:

Resource availability
Electricity price
Network requirement
Data location
Service latency
Capacity
Cooling efficiency

before moving work between sites.

Do not shift a workload to a cheaper site if data transfer or service constraints make the move impractical.

How should projects see electricity savings?

Attribute the shifted workload and saving to the project.

The source metering model already assigns compute and Token consumption by project and tenant.

The v3.2 energy view ranks idle power by project and calculates off-peak savings.

A project report can therefore show:

Original schedule cost
Shifted schedule cost
Estimated or realized saving
Energy consumed
Resource used

That gives teams evidence that schedule flexibility has financial value.

How should realized savings be verified?

Compare the forecast with the actual run.

After the task completes, measure:

Actual start and finish
Actual energy
Actual tariff periods
Actual cost
Actual service outcome

The source operations model emphasizes closing the loop by feeding execution results back into monitoring and analysis.

That is important here.

A planned saving should not be reported as a realized saving until actual usage confirms it.

How should energy-aware recommendations be governed?

Recommendations can be automated.

Execution should follow scheduling and authorization rules.

The source platform repeatedly separates analysis from production action.

A recommendation can say:

"Move Training Job A from the 18:00 peak window to the 23:00 off-peak window. Expected saving: X."

The project owner or policy can approve the change.

The scheduler then executes the approved plan.

This preserves accountability.

What should an energy-aware scheduling dashboard show?

A practical view can show:

Current tariff period
Next off-peak window
Electricity price
Flexible queued workloads
Estimated job duration
Required resources
Current and proposed cost
Expected saving
Deadline
Capacity in target window
Approval state
Realized saving

A platform example that connects tariff periods, GPU power, project attribution, and interruptible scheduling is Sensaka.

If I were implementing time-of-use optimization, I would start with jobs that are already flexible and easy to move. Measure their real energy first, load the actual tariff, calculate the saving transparently, and verify the result after execution. The useful target is not "run everything at night." It is "move the work whose timing is flexible enough that the lower electricity price produces a real saving without creating a new capacity or reliability problem."