---
title: Carbon-Aware Scheduler
url: https://www.emergentmind.com/topics/carbon-aware-scheduler
type: topic
---

# Carbon-Aware Scheduler

A carbon-aware scheduler is a scheduling mechanism that incorporates time-varying electricity carbon conditions, renewable availability, or both into decisions about when, where, and at what intensity computation or communication should run. Across the literature, the term covers several distinct control regimes: temporal deferral of delay-tolerant work, geographic shifting across regions, cluster-capacity shaping, per-task placement on heterogeneous resources, autoscaling of warm containers in serverless systems, and transfer-rate allocation for inter-datacenter data movement [2507.08725]. In all cases, the common purpose is to reduce operational emissions while respecting domain-specific constraints such as deadlines, precedence relations, latency SLOs, queueing stability, or fixed workflow mappings [2106.11750].

## 1. Conceptual scope and formal definitions

In workflow scheduling, carbon awareness can mean shifting task and communication start times within a fixed mapping and fixed per-resource execution order so that more work runs during intervals with more available renewable power and less work runs when the platform would need carbon-emitting “brown” power [2507.08725]. In that setting, the workflow is a DAG \(G=(V,E,\omega,c)\), communication can be converted into fictional tasks on fictional communication processors, and the scheduler chooses only start times \(\sigma(u)\) subject to precedence constraints, fixed order constraints, and a global deadline \(T\) [2507.08725].

The same concept is formulated differently in federated learning. There, the scheduler decides which geographically distributed clients train and at which time slots under a carbon budget \(k\), with per-client per-slot carbon cost
\[
g_c^{(t)} = E_c \times \mathrm{CI}_c^{(t)},
\]
where \(E_c\) is the client energy and \(\mathrm{CI}_c^{(t)}\) is regional carbon intensity [2509.08980]. In geo-distributed web services, carbon-aware scheduling instead means jointly deciding request routing \(x_{ij}\) and server provisioning \(s_j\) across cloud regions while respecting latency SLOs [2403.14792]. In serverless platforms, it can mean choosing the region with the best current carbon efficiency for each new function pod, using marginal operating emission rate rather than average carbon intensity [2310.20375].

A broader implication is that “carbon-aware scheduler” is not a single algorithmic object but a family of schedulers whose decision variables depend on system structure. Some papers optimize task start times with mapping held fixed [2507.08725]; some optimize mapping and scheduling jointly [2605.27652]; some regulate cluster-visible capacity through Virtual Capacity Curves rather than placing individual jobs directly [2106.11750]; some co-optimize autoscaling and warm-container retention in serverless systems [2409.00550]. This suggests that the term is best understood as an objective class layered onto existing scheduling domains rather than as one canonical mechanism.

## 2. Carbon signals, accounting models, and objective functions

A central technical distinction in this literature is the carbon signal being optimized. One line of work models a mixed energy supply with interval-specific green power budgets \(G_j\). In that model, if total platform power at time \(t\) is \(\mathcal P_t\), instantaneous carbon cost in interval \(I_j\) is
\[
\mathcal{CC}_t = \max(\mathcal P_t - G_j, 0),
\]
and total cost is the time integral or discrete-time sum of power consumed above the renewable budget [2507.08725]. This formulation does not use a separate time-varying carbon-intensity multiplier; carbon awareness is defined directly as minimizing brown-power usage [2507.08725].

Another line uses time- and location-dependent grid carbon intensity. In FL, total emissions are
\[
\sum_{c=1}^{K}\sum_t g_c^{(t)} a_c^{(t)} \le k,
\]
under a global carbon budget \(k\) [2509.08980]. In geo-distributed services, the carbon term can be expressed as
\[
\alpha \sum_j I_j \sum_i x_{ij},
\]
where \(I_j\) is regional carbon intensity and \(x_{ij}\) is routed workload [2403.14792]. In serverless inference at the edge, CarbonEdge uses estimated energy and node carbon intensity to form a carbon-efficiency score
\[
S_C = \frac{1}{1 + I_{carbon} \times E_{estimated}},
\]
which is then combined with resource, load, performance, and fairness scores in a weighted node-ranking function [2603.27420].

The literature also differs on whether average or marginal carbon is the correct operational signal. GreenCourier explicitly prefers marginal carbon information, using MOER from WattTime or the Carbon-Aware SDK for runtime placement of serverless functions [2310.20375]. By contrast, CASPER for web services uses average regional carbon intensity from Electricity Maps at hourly granularity [2403.14792]. Carbon-aware CI/CD scheduling likewise prefers marginal carbon intensity forecasts when the objective is to reduce the emissions impact of incremental demand [2310.18718].

A major accounting controversy concerns embodied carbon. “The Sunk Carbon Fallacy” argues that embodied emissions of already-procured servers are a sunk cost and should not be included as a runtime scheduling signal for placement decisions on a fixed fleet; runtime scheduling should optimize operational emissions, while embodied carbon belongs in procurement, hardware replacement, and long-horizon planning [2410.15087]. By contrast, EcoLife explicitly includes both embodied and operational carbon in serverless scheduling over multi-generation hardware because keep-alive decisions alter how embodied carbon is amortized over warm retention and service time [2409.02085]. This suggests that embodied carbon is scheduling-relevant only when the scheduling action changes which physical resources remain active or retained over time, not merely which already-procured server executes a job at a given instant.

## 3. Core algorithmic patterns

A prominent pattern is temporal shifting. Google’s Carbon-Intelligent Compute Management computes next-day hourly Virtual Capacity Curves (VCCs) that reduce flexible compute admission during hours when grid carbon intensity is forecast to be high and re-enable more capacity in cleaner hours, while preserving overall daily capacity for flexible work [2106.11750]. Carbon-aware CI/CD scheduling applies the same basic idea at job level: choose the time-region pair minimizing estimated carbon impact over the feasible window, using runtime estimates and optional user-provided deadlines [2310.18718]. LinTS extends temporal shifting to inter-datacenter transfers by solving a linear program over per-job per-slot throughput variables \(\rho_{i,j}\), minimizing
\[
\sum_{i=1}^{n}\sum_{j=1}^{D_i} c_{i,j}\rho_{i,j}
\]
subject to completion and bandwidth constraints [2506.04117].

A second pattern is spatial shifting. CASPER periodically re-optimizes routing and provisioning across regions, exploiting geo-distributed load balancing rather than deferring interactive work in time [2403.14792]. GreenCourier makes region selection a scheduling problem for each new serverless pod and uses a custom Kubernetes scoring plugin to select the node with the highest carbon-efficiency score among feasible nodes [2310.20375]. Carbon-aware end-to-end data movement extends spatial shifting to file-source selection and overlay transfer-node choice, arguing that transfer carbon depends on path geography and on end systems as well as compute sites [2406.09650].

A third pattern is precedence-aware or workflow-aware scheduling. PCAPS wraps a probabilistic DAG scheduler and uses the base scheduler’s probability distribution over ready tasks to derive a relative-importance measure
\[
r_{v,t} = \frac{p_{v,t}}{\max_{u \in \mathcal A_t} p_{u,t}},
\]
then compares current carbon intensity against an importance-dependent threshold \(\Psi_\gamma(r)\) to decide whether a task should run now or be deferred [2502.09717]. In workflow scheduling with fixed mappings, CaWoSched instead searches over temporal placement while leaving mapping and resource order unchanged [2507.08725]. CWM generalizes this by jointly choosing mapping and timing under renewable constraints, processor heterogeneity, and deadlines [2605.27652].

A fourth pattern is co-optimization of provisioning and scheduling. CarbonFlex learns near-oracle cluster-level actions from historical traces and applies them online through two coupled policies: a provisioning policy \(\phi(\cdot)\) that chooses cluster capacity and a scheduling policy \(\psi(\cdot)\) that decides which parallel jobs run and at what scale [2505.18357]. CASA uses a different but related architecture in serverless clusters: an SLO optimizer adds or redistributes containers when predicted violation exceeds a constraint, while a carbon optimizer removes or consolidates containers when SLO is acceptable [2409.00550]. In both cases, carbon awareness acts not only on placement but also on the amount of active infrastructure.

## 4. Computational complexity and exact optimization

The computational tractability of carbon-aware scheduling depends sharply on the decision space. With fixed task order on a single processor, carbon-aware workflow scheduling can be solved in polynomial time because there always exists an optimal \(\mathcal E\)-schedule whose contiguous no-idle blocks align with interval boundaries induced by renewable-availability changes [2507.08725]. The resulting dynamic program restricts task completion times to a polynomial-size refined set \(\mathcal E'\) of size \(O(n^3J)\) [2507.08725].

For two or more processors, however, the same fixed-mapping workflow problem becomes strongly NP-complete, even for independent tasks, no communications, and homogeneous processors [2507.08725]. The reduction uses alternating green and zero-green intervals and asks whether zero-carbon placement exists iff a 3-Partition instance is feasible [2507.08725]. When mapping is also a decision variable, the hardness becomes even stronger: the joint mapping-and-scheduling problem admits no constant-factor approximation even for the uniprocessor case [2605.27652].

This hardness explains the prevalence of mixed approaches combining exact models for small instances and heuristics for realistic ones. CaWoSched is evaluated against a simple baseline algorithm and an exact ILP-based solution [2507.08725]. LinTS uses a direct LP solved by SciPy’s `linprog` because its transfer-rate formulation remains linear [2506.04117]. PFSP-based manufacturing scheduling is formulated as a mixed-integer linear program and then addressed with a dedicated memetic algorithm combining evolutionary strategy and local search [2503.01325]. Carbon-aware batch DAG scheduling has also been cast as a flexible job-shop scheduling variant and solved offline with OR-Tools CP-SAT to obtain upper bounds rather than production policies [2512.07799]. A plausible implication is that exact methods are primarily useful as evaluators, oracles, or small-instance solvers, while deployable schedulers rely on heuristics, learning, or aggregate control abstractions.

## 5. Workload domains and system-specific constraints

The domain dependence of carbon-aware scheduling is unusually strong. In datacenter workflows, precedence constraints, communication serialization, and machine heterogeneity are central because delaying an upstream task may block a critical path or move communication into different carbon intervals [2507.08725]. In data-processing clusters, the same issue appears at stage level: delaying a bottleneck task to a greener period can increase the end-to-end completion time of the entire job, which is why PCAPS preserves high-importance tasks during high-carbon periods and defers less consequential work [2502.09717].

In federated learning, the main challenge is not only carbon but statistical distortion. Repeatedly favoring low-carbon clients changes the effective training objective, introduces participation bias, and creates temporal correlation in update sequences [2509.08980]. The paper formalizes selection heterogeneity through participation frequencies \(\pi_c\) and notes that convergence error is proportional to total variation distance between the desired uniform client distribution and the realized participation vector [2509.08980]. Carbon awareness in FL therefore becomes a joint scheduling-and-learning problem rather than a pure systems optimization.

In serverless systems, warm retention and cold starts dominate the trade-off. EcoLife models three carbon-relevant phases—keep-alive, cold start, and execution—and shows that keep-alive can dominate total function carbon because warm durations are often minutes while execution lasts milliseconds to seconds [2409.02085]. CASA similarly shows that reducing idle containers can lower carbon but increase cold-start latency and queueing, driving SLO violations [2409.00550]. Carbon-aware scheduling in serverless environments is therefore tightly coupled to container lifetime management, autoscaling, and memory limits, not just dispatch.

In geo-distributed web services and edge inference, latency constraints remain hard feasibility conditions. CASPER’s latency admissibility is encoded through \(x_{ij}(\ell_{ij}-L)\le 0\), which forbids routing requests over paths that exceed the latency target [2403.14792]. CarbonEdge likewise filters overloaded or high-latency edge nodes before applying carbon-aware weighted scoring [2603.27420]. In clinical GPU scheduling, carbon is explicitly secondary to urgency and deadline compliance, and the paper warns that carbon-only presets such as CarbonShift and CarbonGreedy are useful only as stress tests because they can severely disrupt critical-tier deadlines [2606.01766].

## 6. Empirical results, trade-offs, and open debates

Across domains, empirical studies consistently report nontrivial operational carbon reductions, but the shape of the trade-off differs by workload flexibility. CaWoSched’s heuristics provide significant savings in carbon emissions compared to the baseline on deadline-constrained workflows with fixed mappings [2507.08725]. CarbonFlex reduces cluster-level emissions by about \(57\%\) versus a carbon-agnostic baseline and stays within \(2.1\%\) of an oracle scheduler with perfect knowledge in its headline GPU result, indicating that joint provisioning and scheduling matter more than single-job carbon shifting alone [2505.18357]. PCAPS reduces carbon footprint by up to \(32.9\%\) in a Spark-on-Kubernetes prototype without significantly impacting total cluster efficiency as measured by end-to-end completion time [2502.09717].

Geographic and temporal flexibility can both dominate. CASPER reports improvements of up to \(70\%\) over baseline methods with no latency performance degradation in its evaluation of geo-distributed web services [2403.14792]. GreenCourier reports an average \(13.25\%\) reduction in carbon emissions per function invocation compared to other approaches, but also a response-time slowdown because low-carbon regions were farther from the management cluster [2310.20375]. LinTS lowers transfer emissions by up to \(66\%\) relative to the worst case and up to \(15\%\) relative to other solutions while preserving deadlines, largely because it can share low-carbon slots among multiple transfers and vary throughput instead of making binary run-or-wait decisions [2506.04117].

A recurring empirical theme is that simple policies can capture much of the attainable gain when carbon signals are regular. In clinical GPU scheduling, a simple overnight batching rule closes about \(78\%\) of the carbon gap between urgency-only and \(\mathrm{CUCA}_{0.45}\) on an eight-GPU baseline while missing fewer urgent deadlines than either, and at \(48\) jobs per hour the average carbon footprints nearly tie [2606.01766]. By contrast, carbon-only stress-test policies let about \(46\%\) of the most urgent jobs miss their deadline in simulation, reinforcing that carbon-aware scheduling is only useful when bounded by domain-specific service rules [2606.01766].

Two debates remain central. The first is signal choice: average carbon intensity is easier to forecast and use operationally, while marginal signals may better reflect incremental impact [2310.20375]. The second is what “carbon-aware” should include: some work optimizes only operational emissions, whereas other work includes embodied effects or renewable matching targets [2410.15087]. A careful synthesis of these results suggests that carbon-aware scheduling is most effective when it treats carbon as an operational optimization variable constrained by workload semantics, rather than as a universal scalar objective detached from deadlines, precedence, fairness, or service guarantees.

Source: https://www.emergentmind.com/topics/carbon-aware-scheduler