SageMaker HyperPod начал заранее кэшировать модели для быстрого inference

Cold start упирался в две последовательные загрузки

AWS представила model caching для inference в Amazon SageMaker HyperPod. При обычном запуске Kubernetes pod сначала получает container image inference server из Amazon ECR, а затем загружает model weights из Amazon S3, Amazon FSx for Lustre или Hugging Face Hub. Эти операции идут последовательно и откладывают момент, когда replica способна принять первый запрос.

По данным AWS, image с vLLM или LMI может загружаться 5–7 минут, а перенос модели размером 145 GB из S3 — ещё более 20 минут. Для DeepSeek-R1 размером свыше 600 GB компания указывает ожидание от 30 минут. При scale-out та же последовательность повторяется для каждого нового pod, поэтому быстрое решение HorizontalPodAutoscaler не означает столь же быстрое появление вычислительной мощности.

Проблема особенно заметна при резком трафике: autoscaling реагирует на сигнал за секунды, но новые replicas ещё долго не обслуживают запросы. Из-за этого приходится либо держать избыточное число дорогих GPU постоянно, либо принимать длительную деградацию во время всплеска. Кэширование переносит тяжёлую загрузку из критического пути запуска в заранее управляемый этап подготовки nodes.

Weights и image оказываются на локальном NVMe заранее

Model caching предварительно размещает model weights и container images на cluster nodes до планирования рабочих pods. При старте pod читает данные с локального NVMe примерно со скоростью 7 GB/s вместо повторной загрузки через сеть. AWS заявляет, что после включения механизма pod обычно начинает обслуживать traffic за секунды, а не за десятки минут.

Такое ускорение относится к cache hit: нужная версия модели и image уже должны находиться на подходящем node. Поэтому production-метрика должна различать тёплый запуск, промах cache, время предварительного заполнения и вытеснение данных. Среднее время старта без этих разрезов может скрыть редкие, но критичные задержки именно во время аварийного масштабирования.

Локальное размещение меняет и операционную модель. Версии weights и image нужно идентифицировать неизменяемыми digest, иначе node может содержать устаревший artifact с похожим именем. После обновления модели следует доказать, что traffic получает новую версию, а старый cache либо безопасно сосуществует на период rollout, либо удаляется после подтверждения.

Скорость старта становится задачей планирования capacity

Без кэширования пять новых pods одновременно повторяют одинаковые downloads и конкурируют за network throughput. Предзагрузка устраняет эту повторяемую работу из scale-out path, но требует заранее определить, какие модели должны присутствовать на каких nodes. Если набор моделей велик, локальная ёмкость NVMe и политика размещения становятся отдельным ресурсным ограничением.

Практически cache policy следует связывать с прогнозом нагрузки и стоимостью GPU. Популярные модели можно держать готовыми постоянно, редкие — загружать по расписанию перед ожидаемым окном или принимать для них более медленный старт. Для multi-tenant cluster важны quotas: одна крупная модель не должна вытеснить несколько критичных deployments без наблюдаемого решения scheduler или оператора.

Кэш также не сокращает время инициализации самого runtime после чтения weights: создание процессов, распределение tensors между accelerators, компиляция kernels и health checks остаются частью запуска. Поэтому утверждение о секундах нужно проверять на собственной архитектуре, размере модели, типе instance и конфигурации serving stack, а не переносить как универсальную гарантию.

Проверять нужно не только benchmark, но и отказоустойчивость

AWS позиционирует функцию как способ приблизить фактическую реакцию inference fleet к скорости autoscaler. Это может снизить потребность в постоянно простаивающем запасе GPU и улучшить восстановление после перераспределения pods. Однако экономический эффект определяется частотой масштабирования, ценой предварительной загрузки, долей cache hits и объёмом локального хранилища.

Перед rollout полезен canary с измерением четырёх времён: request pod, scheduler placement, readiness и first successful inference. Отдельно следует отключить или очистить cache, чтобы увидеть fallback path. Если подготовленный node недоступен, система должна либо перейти к сетевой загрузке с понятным degraded status, либо быстро выбрать другой node, а не зависнуть между состояниями.

Model caching устраняет конкретный инфраструктурный bottleneck — повторную передачу больших artifacts перед каждым стартом. Но надёжный inference по-прежнему требует контроля целостности weights, версии image, health probes, capacity reservation и rollback. Самая важная проверка после включения функции — не единичный быстрый pod, а предсказуемое масштабирование под реальной параллельной нагрузкой и при отказе заранее подготовленного node.