Amazon показала, как сократить pull контейнерных образов в EKS с 1 минуты 52,876 секунды до 45,121 секунды на 10-гигабайтном образе vLLM. Для команд, которые запускают AI- и ML-нагрузки в Kubernetes, это уже не косметическая оптимизация, а способ убрать один из самых неприятных тормозов в деплое и автоскейлинге, сообщает The New Stack.
Речь идет о режиме SOCI Parallel Pull для Amazon EKS. Проблема, которую он решает, давно знакома платформенным командам: контейнерный образ перестал быть «пакетом на пару сотен мегабайт». В AI-сценариях в образ обычно упакованы тяжелые библиотеки, CUDA-зависимости, SDK, а иногда и дополнительные данные с модельными артефактами. В результате подготовка контейнера перед стартом съедает львиную долю времени. По данным AWS, на новых или масштабируемых ворклоадах загрузка и подготовка образа может занимать более 75% общего времени старта.
Новый подход не пытается «магически» уменьшить сами образы. Вместо этого AWS ускоряет обе самые медленные стадии: скачивание слоев и их распаковку. SOCI Parallel Pull разбивает крупные слои на части и качает их параллельно через несколько HTTP range-запросов, а затем распаковывает несколько слоев одновременно, а не строго по одному. На современных инстансах с нормальной сетью и несколькими CPU-ядрами это выглядит логично: стандартный процесс pull долгое время просто недоиспользовал доступные ресурсы узла.
В качестве демонстрации AWS использовала образ Amazon Deep Learning Container с vLLM размером около 10 ГБ и инстанс m6i.8xlarge. В базовой конфигурации containerd pod получил образ за 1 минуту 52,876 секунды. С включенным SOCI Parallel Pull тот же образ был загружен за 45,121 секунды. Если убрать маркетинговую мишуру и смотреть на голые числа, речь идет примерно об ускорении в 2,5 раза. Для одиночного запуска это просто приятно. Для кластера, который должен быстро поднимать новые GPU-воркеры под всплеск нагрузки, разница уже вполне прикладная.
Отдельно важно, что AWS не продвигает этот режим как универсальную замену lazy loading. У SOCI уже был сценарий, в котором контейнер стартует, не дожидаясь полной загрузки образа. Но для AI-нагрузок это часто не идеальный путь: такие контейнеры обычно почти сразу тянут большие библиотеки и зависимости, так что полный download все равно становится неизбежным. Поэтому ставка здесь сделана не на отсрочку загрузки, а на то, чтобы выполнить ее максимально быстро и заранее. Для inference-сервисов, batch-задач и любых workload’ов с предсказуемым набором зависимостей такой вариант часто практичнее.
Есть и оборотная сторона. Быстрый pull контейнерных образов покупается не бесплатно: режим активнее расходует сеть, CPU и дисковую подсистему. AWS прямо пишет, что для хорошего результата нужна производительная конфигурация хранения, а само решение пишет данные напрямую на диск, чтобы не раздувать потребление памяти. Иными словами, если команда попытается включить эту механику на слабых нодах с узким EBS или без нормального сетевого запаса, эффект может оказаться заметно скромнее, чем в демонстрации. Это не серебряная пуля, а инженерный компромисс: меньше времени на старт в обмен на более агрессивное использование железа.
Практический смысл для русскоязычных команд довольно прямой. Если у вас EKS используется под LLM inference, RAG-сервисы, MLOps-пайплайны или внутренние GPU-платформы, узким местом часто оказывается не Kubernetes как таковой, а именно доставка тяжелого образа на новую ноду. В такой ситуации ускорение pull контейнерных образов снижает cold start, помогает быстрее отрабатывать автоскейлинг и уменьшает соблазн держать лишние дорогие GPU-инстансы просто «наготове». Для бизнеса это уже разговор не только про секунды, но и про плотность использования инфраструктуры.
Еще одна деталь: AWS выводит SOCI Parallel Pull из разряда лабораторных экспериментов ближе к штатной эксплуатации. В последних EKS-оптимизированных AMI для Amazon Linux 2023 и Bottlerocket поддержка встроена из коробки, а в документации отдельно разбираются параметры настройки вроде количества параллельных загрузок на образ и числа параллельных распаковок. То есть речь идет не о разовой демке для конференции, а о вполне оформленном способе тюнинга EKS под тяжелые контейнеры.
На фоне бума генеративного ИИ это выглядит как важный сдвиг в самой философии контейнеров. Несколько лет индустрия учила команды делать образы как можно меньше. Теперь реальность другая: в части AI-сценариев образ все равно будет огромным, и задача смещается с «уменьшить любой ценой» на «доставить и подготовить без мучений». В этом смысле EKS просто первым довольно честно признает новую норму. Если тренд сохранится, конкуренция между Kubernetes-платформами все чаще будет идти не вокруг абстрактного удобства, а вокруг того, кто быстрее переварит 10, 20 или 30 ГБ контейнерной реальности. Подробности и цифры эксперимента можно посмотреть в материале .