Кратко

  • Объявленные AWS 11 сентября кэши весов моделей и образов контейнеров включаются независимо друг от друга; по умолчанию оба отключены.
  • Веса хранятся локально на узле. Планировщик предпочитает подготовленные узлы, но может выбрать другой, которому придётся обращаться к исходному хранилищу.

Для сервиса инференса выделенная вычислительная мощность и готовность отвечать на запросы — не одно и то же. Новая реплика сначала может потратить время на скачивание контейнера и десятков гигабайт весов. Новый механизм кэширования в Amazon SageMaker HyperPod позволяет повторно использовать эту подготовку. Экономический смысл функции определяется тем, как часто следующая реплика оказывается там, где нужные файлы уже есть.

В объявлении от 11 сентября AWS разделяет два механизма. Кэш весов сохраняет файлы модели на локальном NVMe-накопителе узла, сокращая повторные передачи из Amazon S3 или Amazon FSx. Кэш образов заранее скачивает контейнер инференса, чтобы при последующем запуске на подготовленном узле не получать его заново из реестра. Пользователь может включить любой из этих механизмов либо оба.

AWS сообщает примерно о 60-процентном ускорении масштабирования в тестах моделей размером от 57 до 145 ГБ. Отдельно компания указывает сокращение времени скачивания образа на 97%, то есть более чем на две минуты на этой стадии. У показателей разные основания для сравнения. Складывать проценты или считать их гарантированным снижением задержки пользовательского ответа либо расходов клиента нельзя. Независимый нагрузочный тест для этой статьи не проводился.

У кэша весов есть аппаратное условие: локальный NVMe должен быть доступен по настроенному пути и иметь достаточно свободного места. Инстансы, использующие только EBS, для него не подходят. При неподходящем локальном хранилище загрузка весов может продолжаться из удалённого источника. Включённый параметр сам по себе ещё не означает, что локальная копия готова. Наличие образа контейнера тоже не подтверждает готовность весов.

Оператор заранее подготавливает узлы, отвечающие ограничениям размещения конкретного развёртывания, и помечает их готовность. Затем он использует предпочтительную привязку к таким узлам. По общей документации Kubernetes это именно предпочтение при планировании, которое действует наряду с другими требованиями, а не безусловный запрет альтернативного размещения. Эта ссылка поясняет принцип; она не устанавливает версию Kubernetes, используемую HyperPod.

Если реплика попадает на узел без подходящей локальной копии весов, файлы загружаются из исходного S3 или FSx. Такой запасной путь позволяет не делать тёплый кэш обязательным условием запуска. Однако зависимость от доступности источника остаётся. В руководстве AWS прямо рассматриваются ошибки скачивания и недоступность исходного хранилища.

При замене узла его приходится подготавливать заново. В описанном AWS сценарии уже подготовленные узлы в это время продолжают обслуживать запросы. Это не гарантия достаточного запаса вычислительных ресурсов при любом скачке нагрузки. Файлы на диске, модель в памяти GPU и реплика, реально принимающая запросы, обозначают разные состояния готовности.

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

По заявлению AWS, функция общедоступна во всех регионах, где предлагается HyperPod. Но географическая доступность возможности ничего не говорит о частоте повторного использования подготовленных узлов. Именно эта частота определяет, превращается ли ускоренная подготовка в устойчивое преимущество для конкретной службы.

Источники