В этом материале
Сравнивайте готовность и расходы во всём цикле. Запуск по запросу и постоянная реплика решают разные задачи; слово serverless не отменяет загрузку модели, квоты и ограничения продукта.
Если пользователи обращаются редко, держать модель постоянно готовой может казаться избыточным. Если поток регулярный и интерактивный, ожидание запуска может мешать работе. Между этими вариантами нет универсального победителя: для владельца GPU и финансового партнёра важны расписание, требования к ответу и устройство конкретного сервиса.
Уточните значение serverless
Serverless описывает способ предоставления и управления ресурсом, а не отсутствие вычислительной инфраструктуры. Поддержка GPU, регионов и способов запуска определяется выбранным продуктом.
Например, Cloud Run документирует GPU для сервисов, а минимальное число экземпляров рассматривается отдельно как настройка готовности. Нельзя переносить условия такого продукта на любое предложение с похожим названием.
Постоянная реплика тоже может работать в управляемой среде. Ключевой вопрос здесь — какая часть ресурса остаётся готовой между запросами и кто организует её эксплуатацию.
Постройте календарь нагрузки
Разделите редкие одиночные обращения, рабочие сессии и длительный поток. Для каждого отметьте допустимое ожидание и возможность поставить задачу в очередь. Среднее число запросов за месяц скрывает эти различия.
В условном пилоте проверьте первый запрос после долгого перерыва, несколько обращений подряд и пик после простоя. Это покажет влияние запуска лучше, чем повторение короткого теста на уже прогретой системе.
Если подтверждённой истории нет, обозначьте календарь как гипотезу. Пилот должен уточнить её, а не доказать заранее выбранный режим.
Измерьте весь холодный старт
Время включает предоставление ресурса, получение артефактов, подготовку окружения и готовность модели. Не сравнивайте его только с длительностью создания процесса или контейнера.
Отдельно запишите, где хранятся веса и сохраняется ли локальная копия. Диск, RAM и VRAM выполняют разные роли; большой объём одного ресурса не отменяет остальные этапы.
Для пользователя важен момент пригодного результата. Если приложение обещает интерактивный ответ, проверка должна включать ожидание первого обращения после реального простоя.
Сравните затраты готовности
Для постоянного режима учитывайте ожидание, хранение и обслуживание. Для запуска по требованию — повторные старты, ограничения предоставления и время восстановления. Тарифы и правила начисления берите из актуального предложения, а не из общего представления о serverless.
Можно проверить смешанную схему с базовой готовой мощностью и дополнительным запуском.
Финансовому партнёру покажите несколько календарей и измеренные границы. Так обсуждение бюджета становится сравнением сценариев, а не обещанием, что один режим всегда дешевле.
Проверьте также повторный запрос сразу после неудачного старта. Пользовательский цикл может включать повторную попытку, и её задержка должна быть понятной. Без такого случая лучший прогретый результат не объясняет удобство сервиса после обычного сбоя подготовки среды.
Практические выводы
Свободный сервер с предсказуемым расписанием может обсуждаться как часть будущей схемы. Его роль определяют после оценки времени запуска, стабильности и условий владельца.
Сначала полезно изучить автомасштабирование и холодный старт, NVMe для моделей и планирование ёмкости.