Predictive autoscaling for GPU workloads in Kubernetes reduces the gap between traffic spikes and GPU provisioning. In this case, the system failed because reactive scaling was always late.
Система уперлась не в баг, а в физику инфраструктуры. Критический сервис падал под нагрузкой, а не просто деградировал: пользователи видели 15–20% ошибок, а Kubernetes уже пытался догонять всплеск через reactive autoscaling. Для CPU-сервисов такая задержка часто терпима. Для GPU-нод она становится проблемой, потому что подъем capacity занимает минуты: загрузка firmware, инициализация драйверов, подготовка CUDA.
Проблема была в несоответствии между характером нагрузки и скоростью provisioning. HPA реагировал только после появления спроса. Но к этому моменту spike уже наносил ущерб. В такой схеме autoscaling работает как постфактум-реакция, а не как механизм защиты от инцидента. Для GPU workloads это слишком поздно.
Команда выбрала predictive autoscaling for GPU workloads в Kubernetes как прагматичный ответ на этот разрыв. Идея была простой: если система уже собирает достаточно сигналов, можно попытаться предсказать всплеск заранее. Здесь использовались данные Prometheus: CPU, memory, latency, RPS и NVIDIA GPU utilization. История за неделю уже лежала в хранилище, поэтому вопрос был не в наличии данных, а в том, достаточно ли хорошо можно спрогнозировать demand, чтобы capacity успела прогреться к моменту пика.
Архитектуру собрали из трех частей: Predict, Provision, Absorb. Контроллер запускается каждые 60 секунд, берет час истории метрик, делает inference через модель и, если видит рост спроса, начинает постепенное масштабирование. Цель была не в идеальном прогнозе, а в достаточно раннем сигнале. Если всплеск ожидается за 10 минут, у GPU-кластера есть шанс успеть подготовиться до того, как трафик ударит в систему.
В качестве предиктора выбрали Bi-LSTM. Это 2-layer LSTM с 64 и 32 units. Выбор был осознанным, но не теоретически “идеальным”. В данных были micro-bursts, recovery valleys и аномальные плато. Простые линейные подходы хуже справлялись с такой динамикой. Bi-LSTM показал себя лучше именно на этом типе паттернов. Модель переобучают раз в неделю, а в проде она работает только в режиме inference. Внутри controller binary используется TensorFlow Lite, без внешней ML-platform и без отдельного model serving layer.
Этот выбор принес понятный trade-off. Точность стала выше, но training занял больше времени, а объяснимость снизилась. Команда прямо отмечает, что модель сложнее интерпретировать, чем ARIMA. Для autoscaling это допустимый компромисс, если система стабильно попадает в нужный диапазон решений. Здесь важна не абсолютная точность, а полезность прогноза в операционном окне.
Чтобы не зависеть только от модели, добавили burst detector. Он работает параллельно и служит heuristic safety net. Если реальные значения начинают заметно превышать прогноз с учетом confidence interval, detector ускоряет scale-out. Это не вторая ML-модель, а аварийный слой защиты. Его задача проста: признать, что модель не видит часть будущего, и заставить систему реагировать агрессивнее.
Отдельный урок был связан со стабильностью scaling. Если попросить Kubernetes поднимать 100 pods per second, cluster быстро упрется в scheduler, image pulls, sidecars и etcd. Поэтому scaler ограничили до 20 pods per minute. Это выглядит медленно только на бумаге. На практике такой rate limiting помогает держать target utilization на уровне 70%, оставляя headroom под настоящий пик. Иначе система рискует получить cascading failures вместо помощи.
Проверка началась с shadow mode. Предсказания считались, но ничего не менялось в проде. За это время собрали более 500 часов shadow data. Затем провели проверку в controlled dev environment. По описанию авторов, 23 из 23 validation checks прошли успешно, без cascading failures и oscillations. В тестах похожие spike patterns были пойманы примерно за 11 минут до пика, что указывает на полезный запас времени для GPU provisioning. Метрики production-эффекта в статье не приведены, поэтому результат стоит читать как сильную валидацию подхода, а не как опубликованный SLA-выигрыш.
Авторы отдельно отмечают, что архитектура CNCF-native. Она не требует proprietary extensions. Достаточно Kubernetes и Prometheus. Это важный эксплуатационный плюс: меньше новых зависимостей, меньше vendor lock-in, меньше поверхностей отказа. Но и здесь есть цена. Такой подход требует дисциплины в наблюдаемости, регулярной валидации и готовности мириться с тем, что модель не всегда объясняет свои решения.
Из их собственных выводов видно, где лежат следующие шаги. Во-первых, более простые модели вроде ARIMA стоило бы сравнивать дольше, потому что иногда они дают 80% результата при меньшей сложности. Во-вторых, retraining раз в неделю может быть недостаточным, если traffic pattern меняется после feature launch или другого резкого события. В-третьих, для операторов нужна лучшая explainability, возможно через связку LSTM и SHAP. И наконец, rollout лучше делать поэтапно: shadow, capped scale и только потом full scale.
В итоге это не история про “умный” autoscaling ради ML. Это инженерный ответ на конкретный operational gap. Когда provisioning медленнее spike, реактивная схема начинает проигрывать по определению. Predictive autoscaling for GPU workloads в Kubernetes не обещает идеальный прогноз. Он дает системе время. А для GPU-инфраструктуры именно время часто и есть недостающий ресурс.