Amazon Web Services представила функцию кэширования моделей для Amazon SageMaker HyperPod — сервиса для развёртывания и обслуживания больших языковых моделей. Нововведение устраняет задержку между запросом на запуск пода и моментом, когда он готов принимать трафик. Раньше этот интервал определялся двумя последовательными загрузками: контейнерного образа сервера вывода из Amazon Elastic Container Registry (ECR) и весов модели из хранилища — Amazon S3, Amazon FSx for Lustre или HuggingFace Hub.
Проблема холодного старта особенно остра для крупных моделей. Для модели DeepSeek-R1 объёмом более 600 ГБ загрузка весов занимает 30 минут и больше. Контейнерные образы серверов вывода, таких как vLLM или LMI, весят несколько гигабайт и скачиваются 5–7 минут. При автомасштабировании каждый новый под проходит этот цикл заново. Если HorizontalPodAutoscaler запрашивает пять подов, все пять независимо скачивают образ и веса. Политика масштабирования может сработать за секунды, но фактическое время до обслуживания дополнительного трафика составляет 25–30+ минут.
| Компонент | Что кэшируется | Экономия времени |
|---|---|---|
| Кэш весов | Веса модели на NVMe | С 20–30+ минут до секунд |
| Кэш образов | Контейнер сервера вывода | 5–7 минут |
Кэширование моделей решает проблему, предзагружая данные на узлы до планирования подов. Функция включает две независимые возможности. Кэш весов скачивает веса модели на локальные NVMe-накопители каждого узла заранее. После завершения загрузки оператор помечает узел как cache-ready и только затем создаёт развёртывание вывода. При запуске под читает данные с локального NVMe со скоростью около 7 ГБ/с вместо сетевой загрузки. Кэш сохраняется между перезапусками подов на том же узле. При масштабировании новые поды, попадающие на узлы с уже закэшированными весами, стартуют мгновенно.
Для модели DeepSeek-R1 объёмом 600+ ГБ холодный старт занимает 30+ минут, после кэширования — секунды.
Кэш образов предварительно загружает контейнер сервера вывода на узлы через DaemonSet, избавляя от ожидания ECR. В отличие от кэша весов, он не блокирует создание развёртывания. Если под запускается до завершения кэширования образа на узле, он скачивает образ из ECR обычным способом. Несколько развёртываний с одинаковым образом используют один кэш; оператор отслеживает ссылки и удаляет кэш только тогда, когда на него не остаётся ссылок.
Обе функции используют предпочтительное планирование, а не обязательное. Поды предпочитают узлы с кэшированными данными, но не блокируются, если такого узла нет. Это важно при быстром масштабировании, когда число новых подов превышает количество узлов с прогретым кэшем. В таком случае часть подов стартует по старой схеме, но остальные получают ускорение.
Для команд, развёртывающих крупные модели в production, кэширование меняет экономику автомасштабирования. Раньше реакция на всплеск трафика упиралась в пропускную способность сети до хранилища. Теперь узлы с NVMe-кэшем снимают это ограничение. Функция доступна для InferenceEndpointConfig и JumpStartModel, включается добавлением modelCacheConfig с параметрами weightsCache или imageCache. Это не первое решение для ускорения загрузки моделей в облаках, но в экосистеме SageMaker оно встроено в оператор HyperPod и не требует внешних инструментов.
