# Serverless GPU или постоянная реплика: как выбрать режим инференса

Как сравнивать запуск по запросу и постоянно готовую модель: холодный старт, интервалы простоя, минимальная ёмкость и полный пользовательский цикл.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/serverless-vs-always-on-inference/
Language: ru

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

## Уточните значение serverless

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

Например, [Cloud Run документирует GPU для сервисов](https://cloud.google.com/run/docs/configuring/services/gpu), а [минимальное число экземпляров](https://cloud.google.com/run/docs/configuring/min-instances) рассматривается отдельно как настройка готовности. Нельзя переносить условия такого продукта на любое предложение с похожим названием.

Постоянная реплика тоже может работать в управляемой среде. Ключевой вопрос здесь — какая часть ресурса остаётся готовой между запросами и кто организует её эксплуатацию.

## Постройте календарь нагрузки

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

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

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

## Измерьте весь холодный старт

Время включает предоставление ресурса, получение артефактов, подготовку окружения и готовность модели. Не сравнивайте его только с длительностью создания процесса или контейнера.

Отдельно запишите, где хранятся веса и сохраняется ли локальная копия. Диск, RAM и VRAM выполняют разные роли; большой объём одного ресурса не отменяет остальные этапы.

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

## Сравните затраты готовности

Для постоянного режима учитывайте ожидание, хранение и обслуживание. Для запуска по требованию — повторные старты, ограничения предоставления и время восстановления. Тарифы и правила начисления берите из актуального предложения, а не из общего представления о serverless.

Можно проверить смешанную схему с базовой готовой мощностью и дополнительным запуском.

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

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

## Практические выводы

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

Сначала полезно изучить [автомасштабирование и холодный старт](/ru/journal/autoscaling-gpu-cold-start/), [NVMe для моделей](/ru/journal/nvme-for-model-serving/) и [планирование ёмкости](/ru/journal/inference-capacity-planning/).