Carbon-Aware Scheduler

• Carbon-Aware Scheduling refers to mechanisms that integrate time-varying carbon signals to defer or shift compute tasks, aiming to reduce operational emissions.
• It employs strategies such as temporal deferral, geographic shifting, and co-optimization of provisioning with scheduling to balance green energy use and system constraints.
• Empirical evaluations report significant reductions in carbon emissions, sometimes up to 70%, while maintaining deadlines and service quality across diverse domains.

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 (Schweisgut et al., 11 Jul 2025). 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 (Radovanovic et al., 2021).

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 (Schweisgut et al., 11 Jul 2025). 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$ (Schweisgut et al., 11 Jul 2025).

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 (Arputharaj et al., 10 Sep 2025). 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 (Souza et al., 2024). 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 (Chadha et al., 2023).

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 (Schweisgut et al., 11 Jul 2025); some optimize mapping and scheduling jointly (Schweisgut et al., 26 May 2026); some regulate cluster-visible capacity through Virtual Capacity Curves rather than placing individual jobs directly (Radovanovic et al., 2021); some co-optimize autoscaling and warm-container retention in serverless systems (Qi et al., 2024). 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 $\sigma(u)$0 is $\sigma(u)$1, instantaneous carbon cost in interval $\sigma(u)$2 is

$\sigma(u)$3

and total cost is the time integral or discrete-time sum of power consumed above the renewable budget (Schweisgut et al., 11 Jul 2025). This formulation does not use a separate time-varying carbon-intensity multiplier; carbon awareness is defined directly as minimizing brown-power usage (Schweisgut et al., 11 Jul 2025).

Another line uses time- and location-dependent grid carbon intensity. In FL, total emissions are

$\sigma(u)$4

under a global carbon budget $\sigma(u)$5 (Arputharaj et al., 10 Sep 2025). In geo-distributed services, the carbon term can be expressed as

$\sigma(u)$6

where $\sigma(u)$7 is regional carbon intensity and $\sigma(u)$8 is routed workload (Souza et al., 2024). In serverless inference at the edge, CarbonEdge uses estimated energy and node carbon intensity to form a carbon-efficiency score

$\sigma(u)$9

which is then combined with resource, load, performance, and fairness scores in a weighted node-ranking function (Zhang et al., 28 Mar 2026).

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 (Chadha et al., 2023). By contrast, CASPER for web services uses average regional carbon intensity from Electricity Maps at hourly granularity (Souza et al., 2024). Carbon-aware CI/CD scheduling likewise prefers marginal carbon intensity forecasts when the objective is to reduce the emissions impact of incremental demand (Claßen et al., 2023).

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 (Bashir et al., 2024). 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 (Jiang et al., 2024). 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 (Radovanovic et al., 2021). 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 (Claßen et al., 2023). LinTS extends temporal shifting to inter-datacenter transfers by solving a linear program over per-job per-slot throughput variables $T$0, minimizing

$T$1

subject to completion and bandwidth constraints (Rodrigues et al., 4 Jun 2025).

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 (Souza et al., 2024). 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 (Chadha et al., 2023). 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 (Goldverg et al., 2024).

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

$T$2

then compares current carbon intensity against an importance-dependent threshold $T$3 to decide whether a task should run now or be deferred (Lechowicz et al., 13 Feb 2025). In workflow scheduling with fixed mappings, CaWoSched instead searches over temporal placement while leaving mapping and resource order unchanged (Schweisgut et al., 11 Jul 2025). CWM generalizes this by jointly choosing mapping and timing under renewable constraints, processor heterogeneity, and deadlines (Schweisgut et al., 26 May 2026).

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 $T$4 that chooses cluster capacity and a scheduling policy $T$5 that decides which parallel jobs run and at what scale (Hanafy et al., 23 May 2025). 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 (Qi et al., 2024). 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 $T$6-schedule whose contiguous no-idle blocks align with interval boundaries induced by renewable-availability changes (Schweisgut et al., 11 Jul 2025). The resulting dynamic program restricts task completion times to a polynomial-size refined set $T$7 of size $T$8 (Schweisgut et al., 11 Jul 2025).

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 (Schweisgut et al., 11 Jul 2025). The reduction uses alternating green and zero-green intervals and asks whether zero-carbon placement exists iff a 3-Partition instance is feasible (Schweisgut et al., 11 Jul 2025). 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 (Schweisgut et al., 26 May 2026).

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 (Schweisgut et al., 11 Jul 2025). LinTS uses a direct LP solved by SciPy’s linprog because its transfer-rate formulation remains linear (Rodrigues et al., 4 Jun 2025). 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 (Mencaroni et al., 3 Mar 2025). 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 (Bostandoost et al., 8 Dec 2025). 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 (Schweisgut et al., 11 Jul 2025). 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 (Lechowicz et al., 13 Feb 2025).

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 (Arputharaj et al., 10 Sep 2025). The paper formalizes selection heterogeneity through participation frequencies $T$9 and notes that convergence error is proportional to total variation distance between the desired uniform client distribution and the realized participation vector (Arputharaj et al., 10 Sep 2025). 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 (Jiang et al., 2024). CASA similarly shows that reducing idle containers can lower carbon but increase cold-start latency and queueing, driving SLO violations (Qi et al., 2024). 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 $k$0, which forbids routing requests over paths that exceed the latency target (Souza et al., 2024). CarbonEdge likewise filters overloaded or high-latency edge nodes before applying carbon-aware weighted scoring (Zhang et al., 28 Mar 2026). 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 (Doshi et al., 1 Jun 2026).

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 (Schweisgut et al., 11 Jul 2025). CarbonFlex reduces cluster-level emissions by about $k$1 versus a carbon-agnostic baseline and stays within $k$2 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 (Hanafy et al., 23 May 2025). PCAPS reduces carbon footprint by up to $k$3 in a Spark-on-Kubernetes prototype without significantly impacting total cluster efficiency as measured by end-to-end completion time (Lechowicz et al., 13 Feb 2025).

Geographic and temporal flexibility can both dominate. CASPER reports improvements of up to $k$4 over baseline methods with no latency performance degradation in its evaluation of geo-distributed web services (Souza et al., 2024). GreenCourier reports an average $k$5 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 (Chadha et al., 2023). LinTS lowers transfer emissions by up to $k$6 relative to the worst case and up to $k$7 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 (Rodrigues et al., 4 Jun 2025).

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 $k$8 of the carbon gap between urgency-only and $k$9 on an eight-GPU baseline while missing fewer urgent deadlines than either, and at $g_c^{(t)} = E_c \times \mathrm{CI}_c^{(t)},$0 jobs per hour the average carbon footprints nearly tie (Doshi et al., 1 Jun 2026). By contrast, carbon-only stress-test policies let about $g_c^{(t)} = E_c \times \mathrm{CI}_c^{(t)},$1 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 (Doshi et al., 1 Jun 2026).

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 (Chadha et al., 2023). The second is what “carbon-aware” should include: some work optimizes only operational emissions, whereas other work includes embodied effects or renewable matching targets (Bashir et al., 2024). 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.