PowerSlider: Exploiting Phase Asymmetry for LLM Serving under Demand Response
On the map: Efficient LLM inference and serving → Serving systems and request scheduling
Abstract (arXiv)
AI inference clusters are increasingly constrained by instantaneous power, not just energy: grid operators condition new capacity on demand response, imposing time-varying power caps. Existing LLM serving systems optimize a static energy objective or shed fixed priority tiers under load; either way, goodput collapses when the power envelope moves. An LLM pipeline is not a uniform load: compute-bound prefill loses throughput almost linearly with GPU frequency, memory-bound answer decode sustains it down to 0.57× nominal, and reasoning's thinking phase couples KV-cache capacity to scheduling -- so a cap should be steered to where each watt costs the least performance. PowerSlider does so with a new Flex SLO contract that turns bounded user slack into an optimization constraint, prefill--think--answer disaggregation exposing per-stage frequency and KV control, and a Karush--Kuhn--Tucker (KKT) online solver re-solving within 7.7 ms of every cap change, backed by a consolidated fail-safe that power-gates drained instances when DVFS bottoms out on static power. On SGLang with production traces, sys sustains 78.3% online goodput at a 30% cap reduction versus 47.6% for the best of five baselines (1.64×), holds latency-critical tails within 1.3× of nominal (baselines: 2.3--6×, up to 12×), and delivers 92% mean goodput through a replayed CAISO grid-emergency day bottoming at 0.41× (54% at the trough; every baseline below 7%).
Key facts. Cited by 2 papers in the map (data through 14 Oct 2026). Placed in Serving systems and request scheduling, one of 12 directions in Efficient LLM inference and serving. Builds on 17 of its 84 references that are in the map. First posted on arXiv 22 Aug 2026.
Builds on
17 of 84 references.
Closest ancestors · 3
Same direction, newest first
- 2024SLO-aware GPU Frequency Scaling for Energy Efficient LLM Inference Serving5 Aug
- 2024Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve4 Mar
- 2024DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving18 Jan
Other references · 14
- 2023Efficient Memory Management for Large Language Model Serving with PagedAttentioncited by 5,944
- 2021Convex optimizationcited by 2,515
- 2023SGLang: Efficient Execution of Structured Language Model Programscited by 1,141
- 2023Splitwise: Efficient generative LLM inference using phase splittingcited by 558
- 2024Magpie: Alignment Data Synthesis from Scratch by Prompting Aligned LLMs with Nothingcited by 346
- 2022Zeus: Understanding and Optimizing GPU Energy Consumption of DNN Trainingcited by 79
- 2022Carbon Explorer: A Holistic Approach for Designing Carbon Aware Datacenterscited by 32
- 2025TAPAS: Thermal- and Power-Aware Scheduling for LLM Inference in Cloud Platformscited by 29
- 2025EcoServe: Designing Carbon-Aware AI Inference Systemscited by 19
- 2025SLOs-Serve: Optimized Serving of Multi-SLO LLMscited by 19
- 2023CarbonScaler: Leveraging Cloud Workload Elasticity for Optimizing Carbon-Efficiencycited by 17
- 2021Let's Wait Awhile: How Temporal Workload Shifting Can Reduce Carbon Emissions in the Cloudcited by 14
Built on by
Citing papers per year: 2026: 2.
2 papers.
Similar, not cited
Close in wording, no citation either way
- 2026Position: LLM Serving Needs Mathematical Optimization and Algorithmic Foundations, Not Just Heuristics
- 2026Phase-Decoupled, Model-Calibrated Power Control for Disaggregated LLM Serving
- 2026PALS: Power-Aware LLM Serving for Mixture-of-Experts Models
- 2024Offline Energy-Optimal LLM Serving: Workload-Based Energy Models for LLM Inference on Heterogeneous Systems
- 2026Understanding Efficiency: Quantization, Batching, and Serving Strategies in LLM Energy Use
- 2026PowerAtlas: Towards Electricity-Computing Co-Scheduling for Power Systems
- 2025DynaServe: Unified and Elastic Execution for Dynamic Disaggregated LLM Serving
- 2026Position: LLM Inference Should Be Evaluated as Energy-to-Token Production