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