Подготовка GPU-кластера к утреннему пику по Москве

Почему утром GPU не успевают

После 8:30 МСК нагрузка часто растет не плавно, а рывком. Сотрудники почти одновременно открывают рабочие чаты, CRM, внутренние ассистенты и отчеты. В это же время еще могут работать боты, расписания, ETL-задачи и переиндексация, которые не успели закончиться ночью.

В итоге кластер получает сразу два разных потока. Один требует быстрый ответ пользователю. Второй забирает много GPU-времени длинными задачами. Днем такая смесь обычно растягивается по часам, а утром бьет в один короткий интервал.

Ситуацию ухудшает холодный старт. Даже если на бумаге мощности хватает, часть пулов утром еще не готова к работе: поднимаются контейнеры, загружаются веса моделей, прогреваются кэши, восстанавливаются соединения с хранилищами и прокси. Каждая такая операция добавляет секунды. Для одного запроса это терпимо. Для очереди из сотен запросов этого уже достаточно, чтобы задержка выросла в разы.

Утренний трафик почти всегда отличается от дневного не объемом, а формой. Днем запросы приходят ровнее, и планировщик успевает перераспределять слоты между моделями. Утром много коротких, срочных и почти одновременных запросов. Они хуже переносят даже небольшой дефицит мощности, потому что задержку пользователь видит сразу.

Обычно запас теряется не из-за одной большой ошибки, а из-за нескольких мелких. Ночной batch заходит в рабочее окно на 20-30 минут. Автоскейлинг реагирует по факту, а не заранее. Популярные модели сидят в тех же пулах, что и фоновые задачи. Лимиты по параллелизму выставлены по среднему дню, а не по утреннему всплеску.

Проблема часто есть и на уровне маршрутизации. Если трафик идет через один шлюз к разным провайдерам и собственным GPU, запас нужно считать по всей цепочке, а не только по локальному кластеру. Иначе свободные карты вроде бы есть, но очередь растет в другом месте: в квотах, в сетевом канале или в пуле самой популярной модели.

Поэтому начинать стоит не с покупки новых GPU. Сначала убирают холодный старт, разводят утренний онлайн-трафик и ночной batch, а потом уже смотрят, где действительно не хватает железа.

Какие сигналы смотреть до начала дня

Если смотреть только на среднюю нагрузку за сутки, утреннюю проблему легко пропустить. Очередь может вырасти за 20-30 минут, а потом тянуться полдня. Гораздо полезнее разложить нагрузку по 15-минутным слотам и сравнить хотя бы две-три последние недели.

Такой срез быстро показывает повторяющийся рисунок. Например, с 8:30 до 9:15 МСК резко просыпается интерактивный трафик: чаты, поиск, внутренние ассистенты, проверки документов. А batch-задачи часто еще не закончились после ночи и занимают тот же GPU-пул. Если не разделить эти два потока, кажется, что железа не хватает всегда. На деле ночью его просто заняли не те задачи.

Смотрите на набор метрик, а не на одну цифру:

• входящий RPS и число активных запросов по 15-минутным слотам
• длину очереди и p95 задержки по часам
• время загрузки модели в память после простоя
• реальную занятость GPU в ночные часы

Время загрузки модели в память часто ломает утро сильнее, чем сама инференс-нагрузка. Если модель поднимается 90-120 секунд, а пул оставили холодным до 8:55, пользователи почувствуют это сразу. Особенно неприятно, когда одновременно стартуют несколько крупных моделей и кластер тратит первые минуты не на ответы, а на прогрев.

Ночные окна простоя тоже важны. Отметьте интервалы, когда GPU почти пустуют, например с 2:00 до 5:00 МСК. Это хороший кандидат для переноса части batch-задач или для раннего прогрева пулов без удара по дневному SLA. Если вы работаете через единый шлюз, разрез по маршрутам, моделям и провайдерам помогает быстрее понять, какой трафик нужно греть заранее, а какой лучше сдвинуть на ночь.

Хорошее утро выглядит просто: к 8:45 МСК очередь не растет, p95 не прыгает, а нужные модели уже сидят в памяти. Если хотя бы один из этих сигналов выбивается два-три дня подряд, это уже не случайность, а обычная операционная проблема.

Что прогреть заранее

К 9:00 МСК проблемы обычно начинаются не из-за нехватки GPU как таковой, а из-за холодного старта. Воркеры еще поднимаются, модели только грузятся в VRAM, а очередь уже растет. Поэтому пулы стоит готовить заранее, обычно в интервале 7:30-8:00 МСК.

Сначала поднимайте не весь парк, а тот объем, который почти наверняка понадобится в первый час. Если в 9:10 у вас обычно занято 40 GPU, не ждите фактической нагрузки. Поднимите заранее 32-36 и оставьте часть мощности для добора по живому трафику. Такой запас спасает, когда один привычный сервис внезапно дает вдвое больше запросов.

Дальше заранее загрузите в память модели, которые дают основную долю утренних вызовов. Это особенно заметно на крупных open-weight моделях: загрузка весов и инициализация рантайма могут занять несколько минут. Если вы работаете через эндпоинт, совместимый с OpenAI, прогрев удобно делать обычными рабочими запросами, без отдельного кода под каждую модель.

Обычно достаточно прогреть четыре вещи:

• воркеры для самых частых маршрутов
• две-три модели с плотным утренним трафиком
• prompt cache для повторяющихся системных промптов
• резервный пул под резкий рост очереди

С prompt cache многие тянут до последнего, и зря. Если утром повторяются одни и те же шаблоны, например классификация обращений, извлечение полей, короткие RAG-ответы или модерация, прогоните их до начала рабочего дня. Даже частично прогретый кэш заметно сокращает время на первых тысячах запросов.

После scale-up не смотрите только на сам факт запуска. Проверьте, сколько времени проходит от команды на подъем до состояния, когда инстанс уже принимает трафик без скачка по задержке. На бумаге можно поднять 10 GPU за минуту, а в реальности половина из них начнет работать только через 4-5 минут из-за загрузки модели, сетевого хранилища или очереди на инициализацию.

Небольшой резерв лучше держать всегда. Обычно хватает 10-15% от ожидаемой мощности на первый час. Это не роскошь, а страховка от утренних сюрпризов: новой рассылки, пересчета витрин, сбоя в batch-задаче ночью или просто очень активного начала дня.

Если после прогрева первый всплеск все равно проходит тяжело, смотрите не на автоскейлер, а на время реальной готовности модели. Утром это слабое место встречается чаще всего.

Как перенести batch-окна

Batch-задачи часто бьют по кластеру не в сам пик, а за час до него. В 7:30-9:30 МСК они спорят с интерактивными запросами за те же GPU, память и очередь на запуск. Если утром пользователи ждут ответ дольше обычного, причина нередко проста: фоновая работа стартует слишком близко к началу дня.

Сначала найдите джобы, которые действительно мешают живому трафику. Не смотрите на названия в расписании. Смотрите на факты: сколько GPU они держат, как долго идут, в какие минуты дают самый высокий расход памяти и когда заканчиваются. Обычно мешают не все batch-процессы, а несколько самых тяжелых. Часто это ночной retrain, который не успевает завершиться к 8:00 МСК, массовый пересчет эмбеддингов, длинные evaluation-прогоны без жесткого срока и аналитические выгрузки, которые незаметно занимают заметную долю пула.

После этого сдвиньте тяжелые прогоны туда, где цена ошибки ниже. Самый простой вариант - завершать их ночью, до 6:00-7:00 МСК, чтобы у кластера оставался запас на прогрев и ранние запросы. Если задача не помещается в ночь, ставьте ее после 11:00 МСК, когда утренний наплыв уже спал. Худшее решение - оставить крупный batch еще на полчаса перед началом рабочего дня. Обычно именно эти полчаса и ломают SLA.

Длинные прогоны лучше делить на небольшие пачки. Тогда scheduler сможет вставлять между ними интерактивные запросы, а команда не будет ждать конца одного шестичасового монолита. На практике удобнее запустить 12 задач по 20 минут, чем одну на 4 часа: проще прервать, проще перенести, проще понять, где узкое место.

Фоновым задачам задайте жесткий потолок по GPU. Например, не больше 20-30% пула в утреннее окно. Даже если batch отстает, он не должен съедать весь запас. Если часть нагрузки идет через внешний шлюз, а часть живет на своих GPU, такой лимит особенно полезен: поведение продакшена становится заметно предсказуемее.

И еще одно. О новом окне нужно договориться заранее с продуктом и аналитикой. Иначе одна команда перенесет выгрузку на 10:45, другая поставит evaluation на 11:00, и очередь вернется в том же виде. Нормальное расписание знают все: кто запускает задачу, до какого времени она должна завершиться и что можно отложить, если утро снова получилось плотным.

План подготовки мощности на утро

Подготовка к утреннему пику лучше работает как короткий регламент по времени, а не как ручная проверка по настроению. Если команда в Москве начинает нагружать систему между 8:30 и 10:00 МСК, считать нужно от этого окна назад. Иначе вы поднимаете модели тогда, когда очередь уже пошла вверх.

За день до пика

Вечером смотрите не только на среднюю нагрузку, но и на события, которые могут резко изменить утро: релизы, массовые рассылки, новые интеграции, запуск оценки промптов, перенос batch-задач с ночи на ранние часы. Если продуктовая команда выкатывает новую функцию с LLM, это уже повод держать запас, даже если вчера график был спокойным.

Обычно достаточно сверить три вещи:

• прогноз по заявкам на утро
• список релизов и тяжелых джобов
• готовность резерва с нужными образами и моделями

Так становится понятно, где нужен запас по VRAM, а где хватит обычного пула.

Последний час перед стартом

За 60 минут до ожидаемого роста трафика включите прогрев пулов и заранее загрузите модели, которые обычно получают первые запросы. Холодный старт в 9:02 МСК почти всегда обходится дороже, чем лишние 20-30 минут работы пары узлов без полной загрузки.

За 30 минут поднимите резервную емкость. Не весь резерв сразу, а только ту часть, которую можно быстро отдать под очередь. Это особенно полезно, если пользователи приходят через один эндпоинт, а внутри у вас несколько маршрутов и провайдеров: для клиента ответ должен оставаться ровным, даже если внутри меняется путь запроса.

За 10 минут переходите от прогноза к фактам. Смотрите длину очереди, ошибки загрузки моделей, свободную память на узлах, время ответа первого токена и скорость запуска новых инстансов. Если хотя бы один из этих показателей уже уходит в плохую зону, лучше добавить емкость сразу.

После старта не держитесь за вечерний план, если реальный трафик пошел иначе. Первые 15-20 минут быстро показывают, хватило ли мощности. Если очередь короткая, часть резерва можно снять. Если пользователи внезапно ушли в тяжелые модели, добавляйте узлы сразу, пока задержка не разошлась по всей системе.

Пример обычного рабочего утра

Обычное утро ломается не в 9:00, а заметно раньше. Проблема начинается в момент, когда ночные задачи еще едят GPU, а люди уже идут в чаты, поиск и внутренние сценарии с ассистентами.

Представьте ритейл-команду, которая ночью и ранним утром обновляет каталог. В 7:30 пайплайн запускает эмбеддинги новых карточек, пересчет описаний и индексацию. Для batch-задач это удобное время: пользователей мало, и можно занять почти весь пул.

До 8:45 все выглядит спокойно. Графики ровные, ошибок нет, средняя задержка держится в норме. Но в этот момент сотрудники начинают рабочий день: открывают внутреннего помощника, задают вопросы по документам, ищут товары, сверяют остатки и цены. Нагрузка меняется за 10-15 минут, и профиль запросов уже другой. Batch просит длинные непрерывные слоты, а чат ждет быстрый ответ почти сразу.

Если пулы еще холодные, просадка приходит к 9:05. Часть GPU занята ранним batch, часть только поднимается, кэши пустые, и очередь быстро растет. Пользователь видит это как "помощник думает слишком долго", а команда видит всплеск p95, повторные запросы и нервные сообщения в рабочем чате.

Обычно в такой момент начинают ручные правки. Кто-то режет batch-конкурентность, кто-то перебрасывает трафик, кто-то срочно добавляет резерв. Это помогает один раз, но каждое утро превращается в маленький пожар.

Гораздо спокойнее работает другой вариант. Команда переносит batch-окно на 6:00, когда спрос со стороны людей еще почти нулевой. К 8:30 тяжелая часть эмбеддинга уже заканчивается, а часть мощности остается под чат и поиск.

После такого сдвига утро меняется заметно. В 8:45 интерактивные запросы входят в уже прогретый пул, а не в пустую систему. В 9:05 очередь не исчезает совсем, но растет медленнее и уже не срывает SLA из-за лишних минут batch-работы.

Через неделю эффект виден и без сложной аналитики. У команды меньше срочных переключений руками, дежурный инженер не начинает день с аварийных сообщений, а пользователи просто получают ответы без пауз на старте.

Ошибки, которые ломают старт дня

Утренний пик редко срывается из-за одной большой аварии. Чаще его ломают обычные решения, которые выглядят разумно ночью, но плохо работают в 8:50 по Москве, когда интерактивный трафик резко растет.

Первая ошибка - греть весь кластер вместо тех пулов, которые примут живые запросы. Это тратит память и GPU-время на модели, которые утром почти не нужны. Если основной поток идет в чат-модели и эмбеддинги, нет смысла заранее поднимать редкие batch-пулы для OCR или офлайн-классификации. Хуже того, общий прогрев иногда мешает нужным моделям закрепиться в памяти. В результате кластер вроде бы "готов", а первая волна запросов все равно упирается в cold start.

Вторая ошибка - верить средней загрузке. Если смотреть только на цифру за час, можно увидеть спокойные 55% и решить, что запас есть. Но утром важны короткие всплески: что происходит с p95, p99, latency и длиной очереди в течение первых 5-10 минут после начала рабочего дня. Одна короткая перегрузка бьет сильнее, чем ровная высокая нагрузка ночью.

Третья ошибка - поднимать мощность за пять минут до пика. Нужные инстансы к этому моменту должны уже пройти инициализацию, модель должна загрузиться в память, а роутер должен начать слать на нее трафик. Если вы ждете роста очереди и только потом масштабируетесь, вы уже опоздали.

Тот же промах бывает с batch-задачами. Если оставить их без лимитов до 10:00 МСК, они съедят свободные слоты именно тогда, когда людям нужен быстрый ответ. Ночной batch лучше либо завершать раньше, либо жестко ограничивать по concurrency, либо переносить окно так, чтобы к 8:45 он уже не спорил за те же GPU.

Есть и менее заметная ошибка: команда подняла нужное число GPU, но не проверила, что модели все еще в памяти. Ночью могли пройти другие задачи, автоскейлинг мог пересобрать узлы, а eviction мог выгрузить крупные веса. На бумаге мощность есть, по факту первый запрос снова платит за загрузку модели.

Если свести это к короткому правилу, то утром нужно греть только горячие пулы, заранее душить batch, смотреть на короткие пики вместо средней линии и проверять, что нужные модели действительно готовы к трафику.

Короткая проверка перед 9:00 МСК

К 8:45 команда уже должна понимать, выдержит ли кластер первый час без спешных ручных действий. Сам пик редко ломает систему сам по себе. Обычно ее добивает мелочь: холодная модель, забытый batch-процесс или дашборд, где метрики разбросаны по разным экранам.

Сначала проверьте запас мощности на ближайшие 60 минут. Лучше считать не по средней загрузке, а по сценарию с запасом: одна нода недоступна, входящий трафик выше обычного на 20%, часть запросов уходит в более тяжелую модель. Если после такого расчета свободных GPU почти не остается, очередь появится раньше, чем это станет видно в жалобах пользователей.

Потом проверьте готовность самых частых моделей. Если утром 70% запросов идут в две-три модели, их веса должны уже лежать в памяти или на заранее поднятых инстансах. Холодная загрузка в 9:02 легко съедает несколько минут и сразу портит p95. То же касается токенизаторов, prompt cache и шаблонов, которые сервис использует каждый день.

Короткий чек-лист перед стартом обычно выглядит так:

• хватает ли GPU с запасом хотя бы на первый час
• подняты ли частые модели и не ушли ли их веса в выгрузку ночью
• вынесены ли batch-задачи из окна 8:30-10:00 МСК
• видны ли очередь, p95 и ошибки в одном дашборде
• знает ли дежурный, какой шаг делать первым при росте нагрузки

Batch-задачи ломают старт дня тише всех. Ночью они кажутся безобидными, а утром забирают память, PCIe и слоты на инференс. Если переносить их некуда, задайте им жесткий лимит по GPU или поставьте паузу до окончания первого пика.

Один экран с очередью, p95 и ошибками экономит минуты. Если вы используете общий шлюз вместе с собственным кластером, в этом же окне стоит видеть и локальные пулы, и маршруты во внешние модели. Иначе очередь копится в одном слое, а команда ищет причину в другом.

У дежурного должен быть короткий порядок действий: подключить резервный пул, отключить холодный маршрут, прижать batch и проверить, не вырос ли размер ответов. Если этот порядок приходится вспоминать в 9:07, утренняя проверка уже не сработала.

Что сделать после первой недели

Через неделю у вас уже есть не догадки, а цифры. На этом этапе ручная настройка "на глаз" только мешает. Сведите план и факт в одну таблицу, чтобы видеть, где вы промахнулись по времени, объему и запасу мощности.

Обычно хватает пяти колонок: время по МСК, ожидаемая нагрузка, реальная нагрузка, число прогретых GPU и средняя задержка на старте. Можно добавить еще одну колонку с причиной отклонения. Через несколько дней станет видно, что обычный вторник и утро после ночного релиза ведут себя как два разных режима.

Из-за этого правила прогрева лучше разделить. Для будней подойдет один сценарий с плавным подъемом пула до 8:30-8:45 МСК. Для дней релиза нужен другой: раньше поднять тяжелые инстансы, дольше держать запас и позже отпускать емкость. Один общий шаблон почти всегда дает либо лишние расходы, либо очередь в первые 20 минут.

Полезно развести и сами маршруты. Легкие модели для коротких запросов, классификации и простых чат-задач не должны стоять в одной очереди с тяжелыми моделями для длинной генерации. Когда все идет через общий пул, несколько тяжелых запросов легко портят старт всему утру. Разделение маршрутов обычно дает более ровную задержку без роста общего числа GPU.

Если команде нужен один эндпоинт, совместимый с OpenAI, внутри РФ, можно посмотреть на RU LLM. Сервис маршрутизирует запросы к 500+ моделям через единый API, поддерживает data residency и хостит часть open-weight моделей на собственной GPU-инфраструктуре в российских ЦОДах. Для части команд это удобный способ разделить маршруты по типу модели и не менять SDK, код и промпты.

После первой недели полезно проверить не только скорость, но и рабочий режим вокруг данных и расходов:

• где хранятся логи и бэкапы утренних запросов
• как маскирование PII влияет на первые миллисекунды ответа
• хватает ли аудит-трейлов для внутренних проверок
• удобно ли команде разбирать утренние расходы в рублях
• не меняется ли поведение пула из-за требований data residency

Если после этого у вас осталась одна главная проблема, начните с нее. Например, сократите batch-окно на 15 минут или вынесите одну тяжелую модель в отдельный пул. Такой точечный шаг почти всегда полезнее, чем большая перестройка всего кластера.