Тёплый пул моделей: как рассчитать запас на пиковые часы

Где теряются деньги на пике

Самая частая ошибка - смотреть на среднюю загрузку GPU за день и думать, что запаса уже хватает. Среднее значение почти всегда успокаивает зря. Если с 10:00 до 16:00 карты заняты на 45%, это не значит, что в 11:20 система спокойно переживёт всплеск в три раза выше нормы.

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

Обычно деньги уходят в четырёх местах. Команда держит слишком маленький запас и теряет запросы в самый дорогой час. Система поднимает модели слишком поздно, и холодный старт добавляет лишние секунды. Очередь растёт, пользователи отправляют запрос повторно, и нагрузка только усиливается. Или, наоборот, команда закладывает слишком большой резерв и часами платит за почти пустые GPU.

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

Лишний запас бьёт тише, но не слабее. Допустим, команда держит тёплый пул моделей под редкий пик, который случается раз в неделю и длится 10 минут. Всё остальное время часть карт простаивает, а счёт за инфраструктуру идёт каждый час. Это особенно заметно, когда трафик неровный по сменам, дням недели или регионам.

На пике бизнес почти всегда платит либо за ожидание клиентов, либо за пустой резерв. Полностью убрать риск не получится. Задача проще: держать такой запас, который переживёт обычный всплеск без длинной очереди и не превратит спокойные часы в дорогой простой.

Что влияет на размер запаса

Размер запаса ломается не на среднем трафике, а в тот момент, когда одновременно сходятся очередь, длинные ответы и тяжёлая модель. Одни и те же 300 запросов в час могут пройти спокойно или забить GPU, если половина из них пришла за две минуты.

Первый фактор - одновременность. Если в пик у вас обычно 8 активных диалогов, это один запас. Если таких диалогов 30, а часть пользователей ждёт ответ в реальном времени, резерв нужен совсем другой. Поэтому полезно считать не только запросы в час, но и то, сколько запросов система обрабатывает одновременно.

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

Третий фактор - длина ответа. Короткий ответ на 80 токенов проходит почти незаметно. Ответ на 1200 токенов дольше занимает генерацию, и очередь растёт даже при том же входящем потоке. Если команда разрешает длинные ответы всем сценариям подряд, запас почти всегда приходится держать выше.

Есть и простая продуктовая граница: какую задержку вы готовы терпеть. Для внутреннего помощника 6-8 секунд иногда нормальны. Для чата оператора или голосового сценария - уже нет. Чем строже целевая задержка, тем больше нужен тёплый пул, потому что вы не можете просто "переждать" всплеск в очереди.

Отдельно считают время на прогрев и выгрузку. Если модель грузится 60-90 секунд, она не спасёт короткий всплеск на 3 минуты. Если вы держите её в памяти ещё 10 минут после спада, GPU начинают простаивать. Именно здесь часто и прячется лишний расход.

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

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

Какие данные собрать перед расчётом

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

Сначала соберите ряд по входящим запросам: сколько пришло в каждую минуту, как поток менялся в течение смены и где были резкие всплески. Потом посчитайте P95 и P99. Эти метрики показывают не обычную минуту, а верхние 5% и 1% нагрузки, где запас мощности обычно и заканчивается.

Если смотреть только на среднее, расчёт почти всегда получится слишком спокойным. За день у вас может выходить 20 запросов в минуту, а в 11:30 их станет 75. Для GPU это уже не небольшое отклонение, а совсем другой режим работы.

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

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

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

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

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

Как посчитать тёплый пул по шагам

Тёплый пул лучше считать не от числа GPU, а от времени ответа, которое вы готовы дать пользователю. Один и тот же запас может быть достаточным для короткой проверки текста и слишком маленьким для чата с длинной генерацией. Поэтому сначала задайте целевую задержку для каждого сценария. Например, до 2 секунд для извлечения полей из документа и до 8 секунд для ответа в рабочем чате.

Дальше считайте в одном порядке, без догадок.

1. Возьмите самый тяжёлый час за последние 2-4 недели и посчитайте не только запросы в минуту, но и токены. Для LLM это честнее: 80 коротких запросов и 80 длинных диалогов нагружают GPU совершенно по-разному.
2. Переведите токены в пропускную способность одной копии модели. Если одна копия стабильно выдаёт 35 токенов в секунду при нужном контексте, а в пике сервису нужно 90 токенов в секунду, запас должен покрывать минимум три тёплые копии.
3. Добавьте резерв на длинные ответы и хвосты. Среднее значение здесь обманывает чаще всего. Если 10-15% запросов идут с большим контекстом или просят длинную генерацию, сверху обычно нужен запас ещё 20-30%, иначе очередь начнёт расти в самый неудобный момент.
4. Учтите прогрев при смене модели. Загрузка весов, подготовка памяти и запуск нового процесса могут занять от секунд до минут. Если модель нельзя поднять быстро, держите хотя бы одну копию заранее, даже если она нужна не каждый час.
5. Проверьте расчёт на самом тяжёлом часе недели. Смотрите не на средний день, а на тот отрезок, где у вас одновременно высокий входящий поток и самые длинные ответы. Нормальный результат выглядит просто: очередь не растёт дольше нескольких минут подряд, а P95 задержки остаётся в заданном пределе.

Короткий пример. Если в понедельник с 10:00 до 11:00 команда получает 120 запросов в минуту, и половина из них уходит в длинный чат, считать по средней длине ответа опасно. Лучше взять этот час целиком и проверить запас именно на нём. В таких окнах обычно и видно, где GPU будут простаивать, а где их уже не хватает.

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

Как отличить нормальный пик от шума

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

Нормальный пик повторяется. У него есть понятное время, похожая длительность и близкий объём. Шум выглядит иначе: один резкий скачок, потом тишина, или всплеск после рассылки, отчётного дня, релиза или сбоя в соседнем сервисе.

Сравнивайте не лучший и худший день, а 20-30 похожих дней подряд. Смотрите нагрузку по коротким окнам, например по 15 минут. Если в один и тот же час медиана и 90-й процентиль стабильно растут, это рабочий пик. Если вверх улетает только максимум, а обычный уровень почти не меняется, это шум.

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

Здесь помогает простое правило: запас держат под всплески, которые случаются несколько раз в неделю. Дни с маркетинговыми кампаниями и инцидентами помечают отдельно. Очередь включают, если ожидание вышло за ваш порог, например за 2-3 секунды. Редкую модель заранее не прогревают, если её вызывают пару раз в день.

Порог очереди лучше ставить не по ощущениям, а по цене ожидания. Если всплеск длится 5 минут, а прогрев новой копии модели занимает почти столько же, очередь часто дешевле. Если очередь растёт 20-30 минут и уже бьёт по SLA, запас действительно нужен.

С редкими моделями правило ещё жёстче. Их не стоит держать в памяти весь день ради одного отдела или редкого сценария. Частую модель оставляют тёплой, а редкую загружают по расписанию, по первому запросу или отправляют на внешний маршрут. В схеме с AI Router это удобно: постоянный трафик можно вести через предсказуемый тёплый пул, а редкие всплески не оплачивать простаивающими GPU.

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

Пример расчёта для рабочей смены

У банка чат поддержки сильнее всего загружен с 12:00 до 14:00, когда клиенты проверяют переводы, лимиты и блокировки карт. Простые вопросы команда отправляет в лёгкую модель, а спорные случаи с длинной историей диалога и документами - в тяжёлую.

Для расчёта команда не берёт самый высокий всплеск за месяц. Такой максимум часто связан с рассылкой, сбоем в мобильном приложении или разовой акцией. Для тёплого пула полезнее смотреть на пик обычной рабочей смены, например на 95-й перцентиль по пятиминутным окнам за последние недели.

Допустим, рабочий пик в обед равен 30 запросам в минуту. Из них 83% идут в лёгкую модель, 17% - в тяжёлую. На текущих настройках одна тёплая копия лёгкой модели держит 12 запросов в минуту, а тяжёлая - 3.

Лёгкая модель: 30 x 0,83 = 24,9 -> 24,9 / 12 = 2,1 -> нужно 3 копии
Тяжёлая модель: 30 x 0,17 = 5,1 -> 5,1 / 3 = 1,7 -> нужно 2 копии

Получается тёплый пул из 5 копий моделей на обеденный пик. Если лёгкая модель занимает 1 GPU, а тяжёлая 2 GPU, общий запас составит 7 GPU. Это уже намного точнее, чем расчёт с резервом под любой редкий всплеск.

Теперь сравним с месячным максимумом. В один из дней банк получил скачок до 44 запросов в минуту, но он длился меньше минуты после ошибки в приложении. Если ориентироваться на этот максимум, придётся держать уже 4 лёгкие и 3 тяжёлые копии. Две лишние копии будут простаивать почти каждый день.

Короткая очередь на 30-60 секунд обычно снимает эту проблему. Она сглаживает резкий скачок, пока часть сессий успевает завершиться, и позволяет не покупать резерв под каждую шумную минуту. Поэтому для рабочей смены разумнее держать 3 лёгкие и 2 тяжёлые копии, а не раздувать пул до месячного рекорда.

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

Ошибки, из-за которых GPU простаивают

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

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

Ещё одна частая проблема - смешивать batch-задачи и чат в одном пуле. У них разный ритм. Чату нужна низкая задержка и короткая очередь, а batch спокойно переваривает большие объёмы в фоне. Если посадить их на одни и те же GPU, ночная пакетная обработка займёт память и слот декодирования, а дневной чат встанет. В ответ команда добавляет ещё карты, хотя ей нужно было просто развести трафик.

Многие считают только число запросов в минуту и пропускают длину ответа. Это ловушка. Сто коротких ответов и сто длинных отчётов нагружают пул совсем по-разному. Если пользователи днём чаще просят сжатые ответы, а вечером запускают длинные генерации, средний RPS почти не меняется, а время на GPU растёт заметно.

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

Отдельно по бюджету бьёт одинаковый прогрев для всех моделей. Частые модели стоит держать тёплыми почти всегда. Редкие - только по расписанию, по сигналу от маршрутизатора или после первых запросов. Если прогревать редкую модель так же, как основную, она будет занимать память часами ради нескольких обращений в день.

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

Быстрые проверки перед запуском

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

Сначала проверьте горизонт данных. Если у вас есть история хотя бы за 2-4 недели, уже видны повторы: утренний старт смены, обеденный всплеск, вечерний спад, дни с отчётностью или массовыми рассылками. По двум-трём дням легко принять случайный шум за норму и купить лишний запас.

Потом посмотрите на задержку по каждой модели отдельно. Среднее значение и здесь часто усыпляет бдительность. Для запуска полезнее знать P95: именно он показывает, что увидит заметная часть пользователей в напряжённый час. Если одна модель держит ответ за 1,2 секунды, а другая уходит к 4-5 секундам, общий пул нельзя считать так, будто они одинаковые.

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

Перед запуском достаточно сверить пять вещей:

• хватает ли истории трафика хотя бы на 2-4 недели;
• есть ли P95 по задержке для каждой модели, а не только средние цифры;
• выставлены ли лимиты очереди по количеству запросов и по времени ожидания;
• знает ли команда, что отключать первым при перегрузе;
• назначен ли момент пересмотра пула после роста трафика.

Последний пункт часто пропускают. Трафик вырос на 20-30%, а пул оставили прежним, потому что "пока держится". Это дорогая привычка: сначала вы ловите хвосты по задержке, потом в спешке добавляете лишние GPU с запасом поверх страха.

Если вы работаете через AI Router, часть этой проверки можно пройти быстрее: взять данные из аудит-логов, посмотреть rate limits по ключам и отделить реальный рост от всплеска одного клиента. После такой сверки тёплый пул обычно выглядит скромнее, но работает спокойнее.

Что делать дальше

После расчёта не бронируйте весь запас сразу. Лучше взять одну группу моделей с похожей нагрузкой, например чат для операторов или внутренний помощник для сотрудников. На таком пилоте быстрее видно, где оценка дала сбой: в длине ответов, в числе одновременных запросов или во времени разогрева.

Смотрите не только на загрузку GPU, но и на цену ожидания. Иногда очередь в 2-5 секунд стоит меньше, чем ещё один постоянно тёплый инстанс, который полсмены простаивает. Если задержка не ломает сценарий, небольшой буфер часто выгоднее лишнего резерва.

На старте достаточно четырёх шагов: запустить пилот на 2-4 недели и включить логи по входящим запросам, времени ответа и длине генерации; отдельно посчитать стоимость резерва и стоимость короткой очереди в пиковые часы; разделить сценарии, которые лучше держать локально, и сценарии, которые проще отправлять через внешнюю маршрутизацию; через месяц пересчитать пул по новым логам, а не по первой оценке.

Такое разделение быстро убирает лишние траты. Локальный хостинг обычно нужен там, где важны низкая задержка, предсказуемая цена и свой контур хранения. Внешняя маршрутизация лучше подходит для редких, дорогих или сезонных моделей, которые нет смысла держать тёплыми весь день.

Если у команды есть требование хранить данные в Казахстане, пилот можно проверить через AI Router на airouter.kz. У сервиса один OpenAI-совместимый endpoint, данные можно хранить внутри страны, а для продакшена доступны аудит-логи, маскирование PII и лимиты на уровне ключа. Это удобный способ прогнать реальные запросы без смены SDK и кода, а потом решить, какие модели оставлять на своей инфраструктуре, а какие отправлять через шлюз.

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