Slasher: Power Flexibility for Cloud Datacenters
Liuzixuan Lin, Fiodar Kazhamiaka, Alok Gautam Kumbhare, Chaojie Zhang, Jaylen Wang, Hassan Khan, Rodrigo L. Assis, Mariana Rodrigues, Kyle Woolcock, Nithish Mahalingam, Brijesh Warrier, Rodrigo Fonseca, Ricardo Bianchini
cs.DC, cs.OS, eess.SY
2026-08-27
Azure Slasher sheds power with batteries and impact-aware shutdowns; the first 5% is idle machines, and re-scored picks keep high-priority impact near zero at 15%.
Cloud sites have long treated contracted power as a hard ceiling they are free to fill. That bargain is breaking. New campuses get delayed at the grid, and some regions already write demand response into interconnection rules. A cooling failure can require a 10% cut across a hall for 3-6 hours, with about 30 minutes of thermal inertia as notice. A multi-row fault can need a near-instant 5% cut in a local domain before breakers cascade.
Public cloud makes the control problem worse. Each server hosts VMs the platform barely understands. Application-cooperative power schemes from the literature do not transfer. Batteries sized for multi-hour events are expensive; diesel run-time is regulated. Operators need one system that covers rack-local faults and regional grid events without wrecking tenant SLOs.
Slasher is Azure's general power-flexibility system. The core path is in production; some levers and scenarios are still being wired in. Events collapse to five axes: frequency, lead time, duration, shed size, and blast radius. Sub-second low-voltage ride-through is out of scope because software cannot react in time.
Control is two-tier. A per-hall controller owns telemetry and actuation. Offline, it precomputes a playbook that maps incremental watts to an action sequence, plus an impact table. Online, concurrent scenarios take the tightest limit and execute from the table. Millisecond frequency events go to sidecar hardware controllers that discharge batteries or throttle processors; software then covers minutes-to-hours via shutdowns and migrations. A regional orchestrator reads hall impact tables and assigns shed budgets to the halls that hurt least.
Overlapping events are marked on the power-distribution tree. Turning off a server in the overlap of a transformer fault and a row fault counts toward both.
The algorithmic contribution is how to pick which allocated servers to kill. With no application SLO in view, Slasher treats a service (a set of cooperating VMs) as the unit of harm. Historical CPU use is fitted to a load distribution; shutting capacity is scored as expected shortfall, the probability-weighted load that would exceed the remaining cap, normalized by mean load. Priority is a product of platform-visible flags: 1000 for external customers, 100 for internal prod, 0 for Spot. A greedy loop picks the server with the lowest impact per watt, then refreshes scores for any remaining server that shares an affected service, so the same slack is not spent twice.
Stratosim, a Salabim discrete-event simulator, replays VM-granularity power traces so policies can be tested offline. The paper says it will be open-sourced; no repository is given in the text.
A live pilot mimics a multi-minute fast-frequency-response event: batteries take the first cut, internal racks shut down after the software path catches up, discharge rate falls as IT power falls, then slow recharge and restore.
Lever sizing uses nine days of data from 20 Microsoft datacenters.
CPU frequency capping is a poor watt-for-capacity trade. Vault holds 1300 RPS inside its p99 SLO at 3.7 GHz and only 600 RPS at 2.5 GHz, 46% of peak. Across ten request-serving apps, a 40% cut in dynamic power leaves the median app at 48% of peak serving capacity; a compute-bound Go HTTP service falls to 7%. Throughput usually falls faster than power.
Blocking new placements is gentler. Median traces gain about 2% unallocated servers and lose about 8% occupancy in two hours; by twelve hours unallocated servers are up 3-7% and occupancy is down 5-15%. Ideal live-migration consolidation frees 3% more servers in an hour and 8% in 24 hours. Mature clusters often have under 5% spare servers, recent ones over 20%, so idle shutdown saturates quickly.
Policies are compared on a trace with about 5,000 allocated servers and 10,000 services. The first 5% of shed comes from extra idle machines. Beyond that, shutting low-utilization servers first explodes cost: at 15% shed the aggregate score equals more than 1,000 external user-facing services suffering a shortfall equal to their mean load. Scoring once then shutting is better, but still eats through slack on many services. Re-evaluating scores after each pick keeps total cost near zero at 15%, mostly by taking Spot and well-buffered services. Scoring 5,000 servers takes 4.5-6 seconds single-threaded; re-evaluation adds 0.1-2 seconds.
| Policy | Impact at 15% shed | Notes |
| Extra idle shutdown | Covers only the first 5% | Bound by per-cluster spare buffers |
| Lowest utilization first | Very high, >1000 high-priority services at full mean-load shortfall | Server metric only |
| Impact score, one pass | Much lower, still over-cuts some services | Scores frozen at t=0 |
| Impact score, re-eval | Near zero | Marginal cost updated on overlap |
Grid operators are turning occasional shed into a condition for new megawatts. For a public cloud, that is a growth constraint, not a sustainability slide. Slasher's claim is practical: the platform has to act without tenant help; batteries and generators do not cover every scenario; software shutdown without an impact model will maim production at a 15% target that is not even extreme.
People running GPU inference clusters should read the boundary as well. LLM-specific modulation is left as future work because it needs application visibility the platform does not have. CPU frequency capping also looks inefficient at hall scale.
This is a production control skeleton plus an honest-enough SLO proxy, not a new piece of hardware.
The authors say the core is in production while some levers and scenarios are still landing, and GPU/LLM workloads are out of scope. The evaluation studies allocated-server shutdown in depth; throttling and consolidation are argued to need longer notice and are not compared on equal footing.
The impact model assumes remaining VMs absorb load and ignores short-term reroute spikes. Without app metrics, over-provisioning and true SLO-tight packing look the same. The live FFR pilot is a timeline, with no shed percentage or tenant SLO numbers. The near-zero 15% result is simulated expected shortfall, not a replay of a real outage.