Глава 13 — Автоскейлинг и смягчение холодного старта

Тринадцатый пост поглавного разбора LLM Primer VI: Scaling AI Systems. Глава, объясняющая, почему дефолтный автоскейлер Kubernetes производит инциденты под LLM-трафиком, и как KEDA, Knative и CRIU складываются в исправление.

Зачем эта глава существует

Чат-ассистент качается 30× пик-к-впадине через день. Инструмент разработчика падает до нуля на выходных. Потребительский продукт едет на волне Тихий-в-Европу. Провижининг под пик тратит деньги во впадине; провижининг под впадину роняет запросы в пик. Автоскейлинг держит развёртывание в шаге с трафиком; смягчение холодного старта делает автоскейлинг — и в частности scale-to-zero — достаточно быстрым, чтобы пользователи не замечали. Глава 13 объясняет, почему стандартный Kubernetes HPA — не тот скейлер для LLM, на какие сигналы KEDA скейлит вместо него, как Knative выражает scale-to-zero и что требуется, чтобы сжать 60–180-секундный холодный старт в однозначные секунды.

Если коротко: скейлите на то, что чувствует пользователь — глубина очереди, время до первого токена, наполненность KV, — а не на то, что репортит драйвер GPU, и парьте скейлер с CRIU-warm-restore, чтобы новые реплики приходили до окончания всплеска.

13.1 HPA проваливает LLM-трафик четырьмя конкретными способами

Дефолтный HPA скейлит на утилизации CPU или GPU. Он проваливает LLM четырьмя способами. Во-первых, утилизация GPU — не тот сигнал: nvidia-smi репортит долю времени, когда работает какое-то ядро, а не то, хорошо ли упакован батч или движутся ли запросы вперёд. 95-процентно-утилизованный сервер с восемью длинными prefill в очереди за одним decode перегружен; 60-процентно-утилизованный сервер со здоровым continuous batch в порядке. Во-вторых, длительность LLM-запроса (секунды-десятки секунд) велика по сравнению с петлёй управления HPA (15 секунд), так что скейлинг отстаёт от нагрузки на целую жизнь запроса. В-третьих, единица ёмкости — не под; дизагрегированное развёртывание скейлит клики, а HPA не понимает клики. В-четвёртых, холодный старт: новый под приходит онлайн через 60–180 секунд после всплеска, который его вызвал, — либо уже перегрузил флот, либо сбросился таймаутами. Типичный режим отказа — двухминутный инцидент при удвоении трафика, за которым следует scale-down, оставляющий развёртывание недопровижиненным под следующий всплеск.

13.2 KEDA скейлит на глубину очереди, TTFT и наполненность KV

KEDA расширяет HPA CRD ScaledObject, связывающим целевую нагрузку с одним или несколькими скейлерами, переводящими внешнюю метрику в желаемое число реплик. Три сигнала важны для LLM-serving-а. Глубина очереди — самый прямой: число ожидающих запросов у движка — это профицит прибывающей работы над обслуживающей ёмкостью; vLLM экспортирует его как vllm:num_requests_waiting. Время до первого токена — конкретно p95 или p99 по скользящему окну — ловит видимую пользователю деградацию и ловит асимметричную перегрузку, которую пропускает глубина очереди (prefill насыщен, а decode в порядке — или наоборот). Наполненность KV-кэша — упреждающая; когда наполненность пересекает 80 процентов, новые реплики должны приходить онлайн до того, как существующие начнут преимптить или отклонять. Продакшен-ScaledObject обычно составляет все три, с самым агрессивным из них, побеждающим. Knative Serving ложится сверху для scale-to-zero: ниже маленького порога активации все поды удаляются; приходящие запросы держатся активатором, который бустит под по требованию, что экономически осмысленно только если холодный старт быстр.

13.3 CRIU сжимает 90-секундный холодный старт в 3–6 секунд

Холодный старт 70B раскладывается на pull образа (10–60 с), инициализацию Python (2–5 с), загрузку весов (60–120 с), инициализацию CUDA-контекста (5–15 с), захват CUDA-графов (10–30 с), прогрев KV (2–10 с) — итого 90–250 с. CRIU (Checkpoint/Restore In Userspace) снимает снапшот полностью прогретого процесса — веса загружены, CUDA-контекст поднят, графы захвачены, KV-пул выделен, health-check пройден — и восстанавливает его позже с диска за секунды. Утилита NVIDIA cuda-checkpoint (2024) расширяет CRIU на обработку GPU-состояния: пулы памяти устройства, CUDA-контекст, кэшированный PTX, захваченные графы. Прогретый vLLM-снапшот восстанавливается за 3–6 секунд с локального NVMe. DaemonSet предварительно расставляет чекпоинт на NVMe каждого узла, так что Knative может восстанавливать с локального файла, а не тянуть по сети. В сочетании с потоковым pull образа (начать тянуть до окончания pull) и ленивой загрузкой весов холодные старты меньше 5 секунд достижимы в продакшене — число, ниже которого scale-to-zero становится экономически защищаемым для пользовательских приложений.

Стоит запомнить: scale-to-zero — цена платить ничего во впадине, а холодные старты — цена scale-to-zero. Каждая секунда, срезанная с холодного старта, сдвигает точку безубыточности между «всегда прогрет» и «иногда холоден» в пользу оператора.

Что подготавливает глава 13

Главы 1–13 обошли физический стек LLM-serving-а — железо, движки, платформы, дизагрегация, скейлинг. Остальная часть книги обращается к деньгам. Глава 14 объясняет, почему токен — единица биллинга, почему вывод оценивается в два-пять раз выше ввода и как невидимые reasoning-токены оказываются в счёте. Глава 15 обходит арифметику точки безубыточности между self-host и API-провайдерами плюс строку бюджета на платформенную инженерию, которую большинство команд недооценивает. Глава 16 — каталог приёмов сокращения затрат, складывающихся мультипликативно.

Дальше — Глава 14: Экономика токенов и цены API. Почему счёт выглядит именно так, и как счётчик крутится, когда никто не смотрит.

Хочется всю картину? В книжной главе — YAML KEDA ScaledObject для LLM-скейлера с тремя сигналами, манифест Knative Revision для scale-to-zero, полный разбор анатомии холодного старта, CRIU pre-stager DaemonSet и трейс «день из жизни» автоскейленного развёртывания через суточную кривую трафика. LLM Primer VI на Amazon →