Energy-Proportional Serverless Computing on SBC Clusters

arXiv:2611.14026v1 [cs.DC] 10 Nov 2026

Energy-Proportional Serverless Computing on SBC Clusters Yuliya Sasinskaya∗

Natalie Carl∗

Technische Universität Berlin Berlin, Germany yus@3s.tu-berlin.de

Technische Universität Berlin Berlin, Germany nc@3s.tu-berlin.de

Niklas Kowallik

David Bermbach

Technische Universität Berlin Berlin, Germany nk@3s.tu-berlin.de

Technische Universität Berlin Berlin, Germany db@3s.tu-berlin.de

Abstract Serverless computing promises to run code only on demand, yet the servers beneath it draw most of their power while idle, so energy consumption does not scale to zero with the workload. We show that the statelessness of serverless functions makes it possible to extend scale-to-zero from function instances to physical nodes, enabling energy proportionality. Our platform, built on tinyFaaS for clusters of single-board computers, treats node power state as part of worker selection, powering workers off when idle and back on under load. On a physical cluster, our approach reduces mean power draw by 39.6 % on a bursty, trace-based workload and by 46.7 % on a sparse one, without a detectable change in median latency on the bursty workload. The cost lands in the tail, where invocations that arrive while all workers are off wait about a minute for a node to boot. Under continuous load, the platform behaves like an always-on cluster.

CCS Concepts • Hardware → Impact on the environment; • Computer systems organization → Cloud computing.

Keywords serverless computing, energy proportionality, sustainability ACM Reference Format: Yuliya Sasinskaya, Natalie Carl, Niklas Kowallik, and David Bermbach. 2026. Energy-Proportional Serverless Computing on SBC Clusters. In 4th International Workshop on Middleware for the Computing Continuum (Mid4CC ’26), December 14–18, 2026, Tarragona, Spain. ACM, New York, NY, USA, 6 pages. https://doi.org/10.1145/3861040.3862557

1

Introduction

Serverless computing is a cloud computing model where developers deploy applications as small, stateless functions that the cloud runs only when an event calls for them.1 The platform takes care of ∗ Both authors contributed equally to this research. 1 Strictly speaking, serverless computing also encompasses other managed backend

services; for readability, we use the term to refer to Function-as-a-Service only.

This work is licensed under a Creative Commons Attribution-NonCommercialNoDerivatives 4.0 International License. Mid4CC ’26, Tarragona, Spain © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-3105-1/2026/12 https://doi.org/10.1145/3861040.3862557

everything else, from provisioning and scheduling to autoscaling and isolation [12]. Arguably, scale-to-zero is among the model’s most compelling properties: when there is no work, no function instances run. The workloads platforms must serve are, in turn, far more granular and bursty than the long-running services that characterise previous cloud programming models. How efficiently platforms handle this matters more than ever, as the electricity demand of the data centres they run on is surging, with growing consequences for carbon emissions and grid capacity [11]. The International Energy Agency projects this demand to more than double, from 415 TWh in 2024 to 945 TWh by 2030 [11]. In principle, serverless computing should be ideally placed here. A model that runs code only on demand ought to consume energy only on demand, too. Whether it does comes down to energy proportionality, power consumption that scales with useful work [2]. In practice, however, it does not. Invocations are short and highly bursty, so platforms overprovision capacity and keep instances warm to meet latency objectives [1, 21, 26]. Even allocated resources sit largely idle. In production traces from Huawei’s public cloud, roughly two thirds of requests leave more than half of their CPU allocation unused, and about three quarters do the same with memory [14, 18]. As a result, servers spend most of their time well below peak utilisation, where they are least efficient, or idle between requests [2]. At such low utilisation, the fixed, load-independent share of server power dominates. Across SPECpower submissions since 2023, even modern servers draw a median 22.5 % of their peak power when idle, and at 10 % load, this idle baseline still makes up 64 % of their power draw [27]. A function’s energy footprint is thus shaped less by the work performed during invocations than by the baseline power drawn in anticipation of future ones. This runs counter to the promise of scale-to-zero; function instances scale to zero, but energy consumption does not. Existing power management acts within the server: idle and performance states, DVFS, and power gating reduce dynamic power but leave a substantial static floor for as long as the server remains on [3, 15, 23]. Switching servers off entirely would remove this floor, but is generally avoided. Servers hold state that must be migrated, and waking them takes too long to absorb load spikes [2]. Moreover, these mechanisms react to local signals, decoupled from the serverless platform, which has the best view of when capacity will be needed. On IBM’s serverless platform, for example, nearly 60 % of workloads keep at least one instance permanently warm [21], pinning memory that the hardware cannot know is idle.

Mid4CC ’26, December 14–18, 2026, Tarragona, Spain

Serverless computing removes the first obstacle and exposes the information needed to manage the second. Because functions are stateless, a node can be drained and powered down without migrating state, and because the platform already decides where functions run, it can equally decide which nodes are powered. Only granularity remains; aggregate static power changes only in steps of one node’s static power. A cluster of many small, independently switchable nodes, such as single-board computers (SBCs), makes these steps fine enough for cluster power to follow demand, extending scale-to-zero from function instances to physical nodes, down to the residual floor of the network fabric and control plane. Powering down whole nodes is not new in itself [5, 16, 20]; what serverless changes is that statelessness, the property defining its workloads, is precisely the one node-level switching requires. In this paper, we ask: to what extent can platform-controlled node-level power switching make a serverless cluster’s power consumption proportional to offered load, and at what cost in latency? To answer this, we present a serverless platform for SBC clusters that treats per-node power state as a first-class scheduling decision. The central challenge is that switching is not free. Nodes take seconds to boot and draw power while doing so, so the platform must keep enough capacity powered to meet latency objectives as load changes. We make the following contributions. • We argue that statelessness lets scale-to-zero extend from function instances to physical nodes (section 2). • We design a platform for SBC clusters whose worker selection also decides which nodes are powered (section 3). • We evaluate it on a physical SBC cluster, where it draws 39.6 % to 46.7 % less power under bursty and sparse load (section 4).

2

Background

Two questions determine whether node-level power switching can make serverless platforms energy-proportional: which power management mechanisms the underlying hardware already provides, and whether serverless load varies in a way that makes powering off entire nodes feasible.

2.1

Server power management

Servers provide power management mechanisms at two levels. At the component level, idle and performance states, DVFS, and clock and power gating reduce the power drawn by processors, memory, and interconnects when they are underutilised [3, 15]. Three issues prevent them from reaching their potential with serverless workloads. First, their main target is the CPU, while power supply losses, fans, chipset, network interface, storage, and memory refresh keep drawing power for as long as the server is powered on. Second, deeper idle states save more power but take longer to exit; with sub-second, bursty arrivals, idle periods are too short for them to pay off, so hardware mostly remains in shallow states [2, 20]. Third, idle does not mean unallocated: DRAM can enter low-power modes when idle [17], but memory holding the state of warm but inactive instances must be retained and refreshed; only the platform knows that this state could be discarded [8, 21, 26]. At the system level, firmware interfaces such as ACPI define sleep and soft-off states, and wake-on-LAN can bring a powered-down server back [22]. The capability to switch a server off thus exists,

Yuliya Sasinskaya, Natalie Carl, Niklas Kowallik, and David Bermbach

yet operators tend to avoid it, as servers hold state and waking them is slow [2, 19]. What is missing is a decision-maker with the right information. Hardware and OS governors observe only local, past utilisation [31] and cannot tell whether an idle instance’s memory is still needed, nor move work elsewhere to free a node. The serverless platform can: it knows which instances are idle and when their keep-alive expires, which functions have latency objectives, how aggregate load develops, and where functions could be placed instead. The responsibility for managing node power state therefore belongs to the platform, while component-level mechanisms remain useful within the nodes it keeps powered.

2.2

Short bursts, long cycles

For the functions that receive the bulk of the traffic, most interarrival times lie below one second [21, 26]. A node that takes seconds to boot cannot follow fluctuations at this scale. Across many functions, however, these bursts largely average out, while daily and weekly patterns persist, as they affect most applications at the same time [13, 21, 26]. Nasiri et al. observe this in production data from IBM’s serverless platform, where the difference between daily maximum and minimum traffic amounts to about 60 % of peak traffic on weekdays and 40 % on weekends [21]. The load a node-level power manager faces is thus far smoother at the scale of seconds than that of any single function, yet cyclical at the scale of hours, and boot times of less than a minute are small against variation of this kind. This separates two decisions that operate at different timescales. At the instance level, platforms predict when the next request for a given function will arrive to decide which instances to keep warm, at timescales from milliseconds to minutes [8, 21, 26]. At the node level, the question is how much hardware must be powered for the aggregate load, which changes over hours. The two decisions are complementary: instance management determines what runs on the powered nodes, node management determines how many nodes are powered. Short-term fluctuations are absorbed by powered headroom, spare capacity that stays on, so that node switching only has to follow the slow, cyclical component of the load. Our evaluation deliberately omits this headroom and replays a single bursty function, exposing the full switching cost rather than this smoothed case.

3

Design

Our design turns the two conclusions of section 2 into mechanisms: deciding where an invocation runs also decides which workers must be powered, and powered headroom can spare invocations the wait for a boot, at the cost of idle power. We keep the policies governing both deliberately simple and reactive so as to separate the effect of the mechanism from that of any specific prediction strategy, which our platform could incorporate.

3.1

Architecture and node lifecycle

Our platform consists of a leader and a set of workers. The leader runs the control plane. It receives all invocations, load-balances between workers, and decides which nodes are powered. Moreover, it is never powered down, as no component would then remain to power the others back on. The leader is dispatch-only and does not

Energy-Proportional Serverless Computing on SBC Clusters

Mid4CC ’26, December 14–18, 2026, Tarragona, Spain

execute requests itself. This keeps the residual floor constant and explicit; a leader that also executed functions would absorb light load indefinitely and introduce additional variance in the size of the residual floor. Workers, in turn, are the unit of power switching. As a powered-off worker cannot wake itself, the leader must be able to control each worker’s power supply from the outside. Such capabilities are widely available: servers expose them through baseboard management controllers, for example via IPMI or the more recent Redfish [6, 10], and switched power distribution units provide them per outlet. For our SBC test bed, we use simple relays. As workers hold no state, the leader cuts their power directly, without shutting down the operating system first. Each worker moves through three states. (1) A sleeping worker is powered off entirely. (2) When the leader wakes it, the worker is waking: it is powered on, boots, and reports as healthy, after which the leader deploys all functions to it. Waking thus amounts to a cold start at node level, and statelessness keeps it cheap in all but time, as the worker needs function code but no state. (3) Once deployment succeeds, the worker is active and serves invocations until the leader powers it down again. A worker that fails to wake is excluded from the pool of workers but retried periodically. Workers hold no functions across power cycles. Instead, the leader keeps the definition of every function and replicates all of them to every worker it wakes, so that every active worker can serve every function. We expect the set of deployed functions to remain small in the context of SBC clusters. Should it outgrow a worker’s capacity, however, the leader can replace this replicate-everywhere strategy with explicit decisions about which functions to place on which worker.

Raspberry Pi 4B

3.2

Power-aware worker selection

The leader selects a worker for each invocation individually, falling back through three options. It first chooses the least-loaded active worker with fewer than 𝐿 invocations in flight. If no such worker exists, it wakes a sleeping worker and forwards the invocation once that worker is active. Only when no worker is left to wake does it fall back to the least-loaded but saturated worker. Workers are thus woken only under pressure, so the number of powered workers follows load rather than anticipating it. The invocation that triggers a wake pays the price of this reactive approach, as it waits for the entire boot. We accept this wait deliberately, as it exposes the full cost of switching.

3.3

Releasing workers and powered headroom

A controller on the leader periodically checks every active worker and powers it down once it has served no invocation for an idle timeout 𝜏 and has none in flight. Because functions are stateless, powering down requires no migration, as a worker without invocations in flight holds nothing that must be preserved. Choosing 𝜏 above the boot time protects against oscillation, as a worker released during a brief lull would otherwise be woken again shortly after, paying the full switching cost for little saving. Deployed functions stay warm until their worker is powered down, so an active worker never incurs a function-level cold start; node-level power management replaces scale-to-zero for individual function instances.

Raspberry Pi 4B

~

Raspberry Pi 4B Raspberry Pi 4B

Master Brick 3.2

Isolator Bricklet ×3

Voltage/Current Bricklet 2.0 ×4 Isolator Bricklet ×4 Benchmark client

Master Brick 3.2

power requests control measurements

Figure 1: Test bed wiring. A Master Brick on the leader switches each worker’s power through a relay; a separate Master Brick on the benchmark client collects voltage and current of all four nodes. Isolator Bricklets separate both paths electrically.

The controller never powers down workers below a floor of 𝐻 active workers. This floor is the powered headroom described in section 2.2, capacity kept on to absorb short-term fluctuations at the cost of its idle power. Here, the right value depends on the workload. As the leader executes no invocations itself, choosing 𝐻 = 0 leaves no powered capacity once load ceases, so the first invocation after an idle period waits for a full boot. For workloads with long idle periods and latency-tolerant invocations, this maximises savings at an acceptable cost; a larger 𝐻 trades idle power for latency.

4

Evaluation

To find out what node-level power switching saves and what it costs, we compare our platform against the same cluster held fully powered, under workloads that leave different amounts of idle time.

4.1

Experiment setup

We evaluate our platform on a physical cluster of single-board computers, which lets us measure the power of every node directly rather than estimate it. We will release the prototype, the benchmark client, all raw measurements, and our analysis scripts as open source. Prototype. We implement our design on tinyFaaS, a lightweight serverless platform for resource-constrained environments, which we extend with cluster support, node-level scale-to-zero, and relaybased power control [24]. We use an idle timeout of 𝜏 = 60 s, a load threshold of 𝐿 = 10, no powered headroom (𝐻 = 0), and a controller interval of 10 s. Workers run the operating system’s default CPU frequency and idle governors, so any savings come in addition to component-level power management. Test bed. Our cluster consists of four Raspberry Pi 4B boards, one leader and three workers. The leader switches each worker’s power supply through a relay. Voltage and current of every node, the leader included, are measured by the benchmark client at 50 Hz (fig. 1). Control and measurement use separate brick stacks, and the measurements are logged on the benchmark client, so recording

Mid4CC ’26, December 14–18, 2026, Tarragona, Spain

15 10

power-aware

sparse

bursty

−46.7 %

−39.6 %

always-on

leader continuous

Mean power (W)

Mean power (W)

always-on

Yuliya Sasinskaya, Natalie Carl, Niklas Kowallik, and David Bermbach

−0.6 %

5 0

power-aware

10

5

0 0

5

10

15

20

Offered load (req/min)

power does not load the cluster and power samples share a clock with the request log. Workloads. Each invocation runs Sobel edge detection on a 25 kB JPEG image, as a representative of CPU-bound serverless functions. We use three workloads that differ in how much idle time they leave. The sparse workload issues one request every two minutes for 20 min. The bursty workload replays one function from the Azure Functions trace [26], compressing 240 trace minutes into 30 min; its 77 invocations arrive in 23 bursts, separated by idle gaps of 67.5 s to 187.5 s that cover 55 % of the replay. We select a function whose idle gaps exceed the idle timeout, as the highest-volume functions in the trace are active every minute. The continuous workload issues 10 requests/s for 10 min, leaving no worker idle long enough to be released. Baseline and runs. We compare our platform against the same cluster with power switching disabled, which keeps all workers powered. We run each combination of workload and configuration four times, interleaving configurations to avoid drift, except under continuous load. We exclude one sparse power-aware run from the energy statistics, as its power trace ends before the run does. We measure latency at the leader; clients abandon requests waiting longer than 37.5 s, but the leader still records their completion. We treat each run as one replicate and report 95 % confidence intervals. As always-on runs vary far less than power-aware runs, we use Welch’s t-interval, which does not assume equal variance, and for relative changes Fieller’s method, which also accounts for uncertainty in the always-on reference.

4.2

Power savings

Figure 2 shows mean cluster power per workload. Under the sparse and bursty workloads, the power-aware configuration draws 46.7 % (95 % CI [42.1, 51.4], 𝑛 = 3) and 39.6 % (95 % CI [37.3, 41.9]) less power than always-on. Under continuous load, no worker is ever idle for 𝜏, so all three stay powered after the initial wake, and mean power differs by at most a few percent (−0.6 %, 95 % CI [−2.4, +1.3]). The savings stem from worker time. Workers are powered 82.9 % less of the time under the sparse workload and 77.3 % less under the bursty workload, yet mean power falls by less than half, as the leader never switches off. The leader’s draw rises linearly with the number of powered workers, from 2.80 W with all workers off by 0.36 W per worker (𝑅 2 = 0.99), consistent with the relays

Figure 3: Cluster power draw and offered load for the bursty workload. Runs are split into consecutive 60 s windows. The plot shows the number of requests and the cluster’s mean power draw for each window. Faint markers are individual windows; lines connect the median per load level (0, 1, 2–3, 4–7, 8–15, and 16–31 requests), with error bars showing the interquartile range. always-on

Fraction of invocations

Figure 2: Average cluster power per workload. The hatched segment shows the leader’s share, which varies far less than the workers’ share across workloads and configurations.

sparse

1

power-aware bursty

continuous

0.5 0 0.1

1

10

100 0.1

1

10

100 0.1

1

10

100

Latency (s)

Figure 4: Latency per workload, from the leader receiving an invocation to returning its response, including any wait for a wake. Distributions cover all successful invocations of all runs. drawing their holding current from the leader’s supply; the alwayson baseline pays this overhead for all three workers throughout. The leader and its switching hardware thus form the residual floor that node-level switching cannot remove. Figure 3 breaks the bursty workload into 60 s windows. Alwayson draws about 9.6 W regardless of offered load, whereas poweraware rises with it. Its windows cluster at levels that correspond to zero to three powered workers, and their spread at a given load reflects history, as workers woken by an earlier burst stay powered for up to 60 s after it. Offered load describes how requests arrive, not how busy the cluster is. Even the busiest minute, at 20 requests, stays far below the continuous workload, under which about one invocation is in flight on average at 30 times the rate. The highest load levels rest on only a few windows, each from a single minute of the trace, and hence carry less information than intervals with more data points.

4.3

Effects on latency

Figure 4 shows the latency distribution per workload. A worker takes 48 s to 58 s to wake, with a median of 53 s, and every invocation that arrives while no powered worker has capacity waits for it.

Energy-Proportional Serverless Computing on SBC Clusters

Under the sparse workload, which leaves every worker idle for longer than 60 s between requests, the leader wakes a worker 8 times per run on average, and about four in five invocations wait for a wake. As a result, median latency rises from 0.17 s to 49.5 s. This workload is adversarial by construction and marks an upper bound of the latency cost. Under the bursty workload, the leader wakes a worker 13 times per run, and each wake serves every invocation of the burst that triggered it. Both distributions coincide for about two thirds of invocations, and we detect no change in the median (−6.9 %, 95 % CI [−19.1, +5.4]). The remaining third arrives at the start of a burst and waits for a wake, which raises the 95th percentile by 51.9 s (95 % CI [50.2, 53.6]). Under continuous load, the power-aware cluster starts with all workers asleep and wakes each of them once at the start of the run. Requests that arrive during these wakes accumulate on the leader, and some fail with an error when the leader forwards them to a worker that reports ready before it can serve them. Once the backlog clears after about 56 s, no worker sleeps again and latency matches always-on; over the whole run, the 95th percentile rises by only 11.7 % (95 % CI [9.4, 14.0]). As the backlog occurs only once, at the start of a run, its share of invocations shrinks as a run gets longer. Requests waiting for a wake occupy the load generator’s concurrent clients, so we raise its limit from 50 to 800 for the poweraware configuration to keep the backlog from suppressing offered load; always-on never reaches the limit. At the same limit of 50, power-aware yields the same mean power (−0.7 %).

5

Discussion

Node-level switching makes cluster power follow offered load whenever idle gaps outlast the idle timeout, and it costs latency only where invocations meet a cluster without powered capacity. Both outcomes are shaped as much by the decisions surrounding the mechanism as by the mechanism itself, namely which worker receives an invocation, how much capacity stays powered, and which hardware must remain on regardless. Selection policy. Under continuous load, the power-aware configuration saves almost no power, which reflects the selection policy rather than the switching mechanism. With about one invocation in flight on average and 𝐿 = 10, a single worker could carry the load, but least-loaded selection spreads invocations so that no worker stays idle for 𝜏. Packing invocations onto the most loaded worker below 𝐿 would release the others, at the price of higher contention on that worker and of waits for a wake whenever a burst exceeds 𝐿. The policy also ignores invocations already waiting for a wake, so a cluster without capacity can wake several workers at once, as at the start of each continuous run. In future work, we plan to evaluate the impact of different worker selection policies on overall cluster power consumption. Hiding the boot. Invocations that arrive while no powered worker has capacity wait about 53 s for a boot, which accounts for the entire latency cost. Three extensions could reduce it, at different costs in power. First, the leader could execute waiting invocations itself while a worker boots, using capacity that the residual floor

Mid4CC ’26, December 14–18, 2026, Tarragona, Spain

already pays for. Second, powered headroom of 𝐻 ≥ 1 keeps capacity available at all times, trading the idle draw of each headroom worker for latency. In our evaluation, we explicitly chose 𝐻 = 0 to quantify an upper bound for how much power node-level switching saves. Third, as daily and weekly cycles dominate aggregate load on public serverless platforms, the predictors they already use to keep instances warm could also be used to wake workers ahead of demand [8, 21, 26]. Our measurements also overstate the latency cost in one respect. Every power-aware run starts with all workers asleep, so its first invocations wait for a wake that a cluster in steady operation would rarely incur, while always-on starts fully powered. This start-up wake causes the entire latency cost under continuous load and adds to the tail of the bursty workload, but changes little under the sparse workload, in which most invocations wait regardless. It also lowers the power-aware configuration’s draw during the first minute of each run. Beyond our test bed. The residual floor of the leader and its switching hardware is partly avoidable, as our relays draw holding current from the leader’s supply, whereas latching relays need power only to switch. On servers, baseboard management controllers draw standby power while the server is off, and each server is a coarser step, so fine-grained nodes such as SBCs at the edge suit the approach best. Larger clusters would need a function registry with selective replication instead of replicate-everywhere. Cutting power without a shutdown loses no application state, but it stresses storage, and one SD card failed during our experiments; read-only root file systems or network boot would avoid this, and the idle timeout also bounds wear. Finally, AI accelerators are increasingly powerintensive yet often run well below peak; their functions, however, are stateless only nominally, as powering a node down discards model weights whose loading dominates cold starts [7]. Whether node-level switching extends to hardware-accelerated serverless computing, for example on SBC-sized edge accelerators, remains open.

6

Related work

Adjusting the number of powered servers to load is an established approach to energy proportionality. Muse concentrates the load of a hosting centre on fewer servers and powers down the rest [5], NapSAC does the same for web clusters [16], and Lin et al. derive online algorithms for right-sizing that account for the cost of switching [19]. PowerNap instead proposes hardware that enters a near-zero-power state within milliseconds, so that a single server can follow idle periods of seconds or less [20]. Cluster autoscalers in public clouds remove idle nodes as well, but release VMs to save cost rather than power down hardware. These cluster-level approaches depend on statelessness as a property of specific services and on a cluster manager separate from the application, whereas serverless computing makes every function stateless and leaves both worker selection and power control to the same platform. Our platform therefore needs no hardware support beyond external power control and, with powered headroom, has to follow only the slow component of the load. Within powered servers, EcoFaaS adapts CPU frequencies to the latency requirements of individual invocations [28], and GreenWhisk makes the platform itself emission-aware [25]. Other work

Mid4CC ’26, December 14–18, 2026, Tarragona, Spain

shifts workloads in time or across regions towards cleaner energy or better utilisation [9, 30], although the benefits of such shifting are still debated [29]. All of these act on the work or within powered hardware and leave the number of powered nodes unchanged, so they complement node-level switching. Carl et al. propose executing each invocation on a dedicated SoC that boots for it and shuts down afterwards, removing the need for software isolation as well as idle power [4]. At the edge, clusters of mobile SoCs already serve as servers [32, 33]. Our platform lies between conventional servers and per-invocation hardware, switching nodes with load rather than per invocation, so that a single boot can serve many invocations.

7

Conclusion

Our findings indicate that node-level power switching is a viable strategy for reducing the electricity consumption of SBC clusters running serverless workloads. Because serverless functions are stateless, the platform can extend scale-to-zero from function instances to physical nodes: on our cluster, this reduces mean power draw by 39.6 % on a bursty, trace-based workload and by 46.7 % on a sparse one, without a detectable change in median latency on the bursty workload. The cost is a boot of about a minute for invocations that find no capacity, which bridging boots at the leader, powered headroom, or prediction could hide. Edge sites, which already deploy clusters of small nodes, are a natural place to start.

Acknowledgments We thank Sripriya Srikant Adhatarao for her mentorship and many valuable discussions. This work was funded in part by the German Federal Ministry of Research, Technology, and Space under grant 16IS23068.

References [1] Ahmed Alquraan, Abdelrahman Baba, Rafael Mendes da Silva, Sameh Elnikety, Paul Batum, Yan Chen, Hamid Henry Safi, Seth Fine, and Samer Al-Kiswany. 2026. DROPS: Managing Serverless Resource Pools in Microsoft Azure Functions. In Proc. EuroSys ’26. 1281–1297. doi:10.1145/3767295.3769350 [2] Luiz André Barroso and Urs Hölzle. 2007. The Case for Energy-Proportional Computing. Computer 40, 12 (2007), 33–37. doi:10.1109/MC.2007.443 [3] Luiz André Barroso, Urs Hölzle, and Parthasarathy Ranganathan. 2026. The Datacenter as a Computer: Designing Warehouse-Scale Machines (4th ed.). Springer, Cham, Switzerland. doi:10.1007/978-3-031-99489-0 [4] Natalie Carl, Tobias Pfandzelter, and David Bermbach. 2025. Towards Energy-Efficient Serverless Computing with Hardware Isolation. arXiv:2510.08180 [cs.DC] [5] Jeffrey S. Chase, Darrell C. Anderson, Prachi N. Thakar, Amin M. Vahdat, and Ronald P. Doyle. 2001. Managing Energy and Server Resources in Hosting Centers. In Proc. SOSP ’01. 103–116. doi:10.1145/502034.502045 [6] DMTF. 2026. Redfish Specification, Version 1.25.0. https://www.dmtf.org/dsp/ DSP0266. [7] Yao Fu, Leyang Xue, Yeqi Huang, Andrei-Octavian Brabete, Dmitrii Ustiugov, Yuvraj Patel, and Luo Mai. 2024. ServerlessLLM: Low-Latency Serverless Inference for Large Language Models. In Proc. OSDI ’24. 135–153. [8] Alexander Fuerst and Prateek Sharma. 2021. FaasCache: Keeping Serverless Computing Alive With Greedy-Dual Caching. In Proc. ASPLOS ’21. 386–400. doi:10.1145/3445814.3446757 [9] Viktor Urban Gsteiger, Pin Hong (Daniel) Long, Yiran (Jerry) Sun, Parshan Javanrood, and Mohammad Shahrad. 2024. Caribou: Fine-Grained Geospatial Shifting of Serverless Applications for Sustainability. In Proc. SOSP ’24. 403–420. doi:10.1145/3694715.3695954 [10] Intel, Hewlett-Packard, NEC, and Dell. 2015. Intelligent Platform Management Interface Specification, v2.0, Rev. 1.1. [11] International Energy Agency. 2025. Energy and AI. Special Report. International Energy Agency. https://www.iea.org/reports/energy-and-ai

Yuliya Sasinskaya, Natalie Carl, Niklas Kowallik, and David Bermbach

[12] Eric Jonas, Johann Schleier-Smith, Vikram Sreekanti, Chia-Che Tsai, Anurag Khandelwal, Qifan Pu, Vaishaal Shankar, Joao Carreira, Karl Krauth, Neeraja Yadwadkar, Joseph E. Gonzalez, Raluca Ada Popa, Ion Stoica, and David A. Patterson. 2019. Cloud Programming Simplified: A Berkeley View on Serverless Computing. arXiv:1902.03383 [cs.OS] [13] Artjom Joosen, Ahmed Hassan, Martin Asenov, Rajkarn Singh, Luke Darlow, Jianfeng Wang, and Adam Barker. 2023. How Does It Function? Characterizing Long-term Trends in Production Serverless Workloads. In Proc. SoCC ’23. 443–458. doi:10.1145/3620678.3624783 [14] Artjom Joosen, Ahmed Hassan, Martin Asenov, Rajkarn Singh, Luke Darlow, Jianfeng Wang, Qiwen Deng, and Adam Barker. 2025. Serverless Cold Starts and Where to Find Them. In Proc. EuroSys ’25. 938–953. doi:10.1145/3689031.3696073 [15] Stefanos Kaxiras and Margaret Martonosi. 2008. Computer Architecture Techniques for Power-Efficiency. Number 4 in Synthesis Lectures on Computer Architecture. Morgan & Claypool, San Rafael, CA, USA. doi:10.2200/ S00119ED1V01Y200805CAC004 [16] Andrew Krioukov, Prashanth Mohan, Sara Alspaugh, Laura Keys, David Culler, and Randy H. Katz. 2010. NapSAC: Design and Implementation of a PowerProportional Web Cluster. In Proc. Green Networking ’10. 15–22. doi:10.1145/ 1851290.1851294 [17] Seunghak Lee, Ki-Dong Kang, Hwanjun Lee, Hyungwon Park, Younghoon Son, Nam Sung Kim, and Daehoon Kim. 2021. GreenDIMM: OS-Assisted DRAM Power Management for DRAM with a Sub-Array Granularity Power-Down State. In Proc. MICRO ’21. 131–142. doi:10.1145/3466752.3480089 [18] Changyuan Lin, Yuanzhi Ma, and Mohammad Shahrad. 2026. Demystifying Serverless Costs on Public Platforms: Bridging Billing, Architecture, and OS Scheduling. In Proc. EuroSys ’26. 1964–1981. doi:10.1145/3767295.3769374 [19] Minghong Lin, Adam Wierman, Lachlan L. H. Andrew, and Eno Thereska. 2013. Dynamic Right-Sizing for Power-Proportional Data Centers. IEEE/ACM Transactions on Networking 21, 5 (2013), 1378–1391. doi:10.1109/TNET.2012.2226216 [20] David Meisner, Brian T. Gold, and Thomas F. Wenisch. 2009. PowerNap: Eliminating Server Idle Power. In Proc. ASPLOS XIV. 205–216. doi:10.1145/1508244.1508269 [21] Nima Nasiri, Nalin Munshi, Simon Daniel Moser, Marius Pirvu, Vijay Sundaresan, Daryl Maier, Thatta Premnath, Norman Böwing, Sathish Gopalakrishnan, and Mohammad Shahrad. 2026. In-Production Characterization of an Open Source Serverless Platform and New Scaling Strategies. In Proc. EuroSys ’26. 2054–2072. doi:10.1145/3767295.3769377 [22] Sergiu Nedevschi, Jaideep Chandrashekar, Junda Liu, Bruce Nordman, Sylvia Ratnasamy, and Nina Taft. 2009. Skilled in the Art of Being Idle: Reducing Energy Waste in Networked Systems. In Proc. NSDI ’09. 381–394. [23] Anne-Cécile Orgerie, Marcos Dias de Assunção, and Laurent Lefèvre. 2014. A Survey on Techniques for Improving the Energy Efficiency of Large-Scale Distributed Systems. Comput. Surveys 46, 4, Article 47 (March 2014), 31 pages. doi:10.1145/2532637 [24] Tobias Pfandzelter and David Bermbach. 2020. tinyFaaS: A Lightweight FaaS Platform for Edge Environments. In Proc. ICFC ’20. 17–24. doi:10.1109/ICFC49376. 2020.00011 [25] Jayden Serenari, Sreekanth Sreekumar, Kaiwen Zhao, Saurabh Sarkar, and Stephen Lee. 2024. GreenWhisk: Emission-Aware Computing for Serverless Platform. In Proc. IC2E ’24. 44–54. doi:10.1109/IC2E61754.2024.00012 [26] Mohammad Shahrad, Rodrigo Fonseca, Íñigo Goiri, Gohar Chaudhry, Paul Batum, Jason Cooke, Eduardo Laureano, Colby Tresness, Mark Russinovich, and Ricardo Bianchini. 2020. Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider. In Proc. USENIX ATC ’20. 205– 218. [27] Standard Performance Evaluation Corporation. 2026. SPECpower_ssj2008 Results. https://www.spec.org/power_ssj2008/results/. (Accessed: September 27, 2026). [28] Jovan Stojkovic, Nikoleta Iliakopoulou, Tianyin Xu, Hubertus Franke, and Josep Torrellas. 2024. EcoFaaS: Rethinking the Design of Serverless Environments for Energy Efficiency. In Proc. ISCA ’24. 471–486. doi:10.1109/ISCA59077.2024.00042 [29] Thanathorn Sukprasert, Abel Souza, Noman Bashir, David Irwin, and Prashant Shenoy. 2024. On the Limitations of Carbon-Aware Temporal and Spatial Workload Shifting in the Cloud. In Proc. EuroSys ’24. 924–941. doi:10.1145/3627703. 3650079 [30] Philipp Wiesner, Ilja Behnke, Dominik Scheinert, Kordian Gontarska, and Lauritz Thamsen. 2021. Let’s Wait Awhile: How Temporal Workload Shifting Can Reduce Carbon Emissions in the Cloud. In Proc. Middleware ’21. 260–272. doi:10.1145/ 3464298.3493399 [31] Rafael J. Wysocki. 2026. CPU Idle Time Management. https://docs.kernel.org/ admin-guide/pm/cpuidle.html. Linux kernel documentation (Accessed: September 27, 2026). [32] Mengwei Xu, Li Zhang, and Shangguang Wang. 2022. Position Paper: Renovating Edge Servers with ARM SoCs. In Proc. SEC ’22. 216–223. doi:10.1109/SEC54971. 2022.00024 [33] Li Zhang, Zhe Fu, Boqing Shi, Xiang Li, Rujin Lai, Chenyang Yang, Ao Zhou, Xiao Ma, Shangguang Wang, and Mengwei Xu. 2024. More is Different: Prototyping and Analyzing a New Form of Edge Server with Massive Mobile SoCs. In Proc. USENIX ATC ’24. 285–302.

Related documents

• STORE: Self-Provisioning Storage-as-a-Service for Serverless Functions#972489
• SLFS: a Flexible, Low-Cost Distributed File System Using Serverless Designs#332500
• Priority-Aware Scheduler for Serverless Functions Provision and Load Balancing#1458543
• Priority-Aware Scheduler for Serverless Functions Provision and Load Balancing#1450741
• The Thermodynamic Complexity of Circuits#1455674