POWERSLIDER показывает, как dynamic power caps меняют задачу LLM serving: теперь нужно управлять не только latency и throughput, но и мгновенным power envelope. Ключ здесь не в «снижении мощности вообще», а в том, чтобы тратить каждый ватт там, где он стоит дешевле для goodput.
Современные inference-кластеры упираются уже не только в энергию, но и в мгновенные ограничения сети. Для demand response это означает конкретный runtime-контракт: кластер должен оставаться ниже time-varying power cap pmax(t) в каждый момент, а не просто экономить энергию на длинной дистанции. И здесь обычные подходы начинают ломаться. Статическая energy-оптимизация не решает динамическую задачу, а жёсткие priority tiers быстро выжигают goodput, когда cap сдвигается глубже.
Проблема в том, что LLM pipeline не является равномерной нагрузкой. Prefill phase вычислительно тяжёлый и почти линейно теряет throughput при снижении GPU frequency. Answer decode, наоборот, чаще memory-bandwidth-bound и может работать при заметно более низкой частоте без резкой просадки. Reasoning workloads добавляют ещё и thinking phase, где KV-cache становится отдельным ограничением для scheduling. Это и есть архитектурный разлом: один и тот же watt в разных стадиях стоит разную долю производительности.
Из этого следует важный trade-off. Универсальное throttling всех GPU одинаково срезает prefill там, где потери максимальны, хотя часть decode-пути могла бы отдать мощность почти безболезненно. POWERSLIDER выбирает другой путь. Он вводит Flex SLO contract и превращает bounded user slack в ограничение для оптимизации. Пользовательский смысл у этого контракта простой: часть трафика может выдержать контролируемую деградацию latency, но не бесконечно и не хаотично.
Технически решение строится вокруг Prefill–Think–Answer disaggregation. Это расширяет классическую prefill–decode схему и даёт runtime более тонкие рычаги: per-stage GPU allocation, stage-aware DVFS и KV-cache partitioning. Такой дизайн не устраняет сложность, а делает её управляемой. Вместо одной грубой ручки система получает несколько независимых контуров, между которыми можно распределять дефицит power.
Дальше начинается самое интересное. Конфигурационное пространство быстро становится слишком большим для offline profiling. В исходнике оно описано как комбинация stage, SLO class, GPU allocation, frequency, KV chunk size и model/TP setting. Поэтому POWERSLIDER использует online solver, выведенный из Karush–Kuhn–Tucker conditions. Это прагматичный выбор: не искать конфигурацию перебором, а решать релаксацию по состоянию текущего cap.
Важная деталь в том, как система принимает решение. Solver не просто снижает частоту везде. Он ранжирует stage-class группы по тому, сколько goodput теряется на каждый сэкономленный watt. В memory-bound stages частота снижает power дешевле, потому что throughput там хуже зависит от f. В compute-bound prefill картина обратная: каждое снижение frequency стоит дорого. Поэтому деградация идёт не «сверху вниз», а по стоимости потери производительности на единицу мощности.
Реализация тоже построена как инженерный компромисс между скоростью реакции и стоимостью переключений. PSOpt пересчитывает решение быстро, в пределах 7.7 ms, что позволяет реагировать на cap change в online-режиме. PSSched применяет reallocation на более медленном цикле, с drain-before-reassign, чтобы не пересчитывать KV state. Для DVFS используется vote-commit схема с периодом 50–100 ms и одним NVML call на GPU. Это не идеальная мгновенная реакция, но она согласуется с реальными ограничениями hardware interface.
Есть и отдельный механизм защиты от глубокого cap. Когда DVFS упирается в нижнюю границу и дальше срезать мощность уже почти нечем, система power-gates drained instances и consolidates load onto fewer GPUs. Это честное признание hardware floor: ниже static power уехать нельзя только частотой. Значит, runtime должен менять уже не только frequency, но и количество активных GPU.
Самая уязвимая зона таких систем — reasoning traffic. Он ломает prediction-based routing, потому что output lengths тяжело-tailed. В исходнике прямо указано, что length predictor даёт 37.1% misprediction rate после fine-tuning на reasoning traces. Для overloaded cluster это превращается в queueing cascade. POWERSLIDER обходит проблему через observation-based admission и stage isolation, а не через более «умный» прогноз длины.
Результаты показывают, что эта архитектурная ставка оправдана. На SGLang с production traces POWERSLIDER удерживает 78.3% online goodput при 30% reduction, тогда как лучший baseline — 47.6%. На replayed CAISO grid-emergency day с trough до 0.41× система держит 92% mean goodput и 54% в самой глубокой точке, тогда как все baselines падают ниже 7%. Latency tails тоже остаются ближе к nominal: LC TTFAT и TTLT удерживаются в пределах 1.3×, тогда как у baselines рост заметно хуже.
Источник информации
arXiv — крупнейший открытый репозиторий препринтов (с 1991 года, под эгидой Корнелла), где исследователи оперативно размещают рабочие версии статей; материалы общедоступны, но не проходят полное рецензирование, поэтому результаты следует считать предварительными и, по возможности, сверять с обновленными версиями или рецензируемыми журналами. arxiv.org