Subaru сократил время загрузки AI-контейнеров в 60 раз с помощью Envoy Gateway

Subaru сократил время загрузки контейнера примерно с трёх часов до трёх минут. Это улучшение в 60 раз по одной операционной метрике оказалось достаточным, чтобы выиграть конкурс CNCF End User Case Study Contest на KubeCon + CloudNativeCon Japan 2026, объявленный 28 июля во время основного доклада в Йокогаме. Примечательна не награда, а исходная точка: команда AI-платформы крупнейшего автопроизводителя совсем недавно ждала три часа загрузки контейнера, прежде чем мог стартовать любой GPU-задача.

Что произошло

Cloud Native Computing Foundation назвал Subaru победителем конкурса среди конечных пользователей за работу над инфраструктурой для EyeSight следующего поколения — системы помощи водителю компании. Как сообщает PR Newswire, Рёдзи Кобаяси, DevOps-инженер отдела разработки ADAS в Subaru, представил основной доклад с подробным разбором архитектуры.

Исходное состояние, по данным источника, было проблематичным в весьма конкретном смысле. AI-образы контейнеров превышали 30 ГБ. Загрузка одного занимала примерно три часа до начала выполнения задач. Развёртывания выполнялись вручную через скрипты, а не через декларативную конфигурацию. У ML-пайплайна не было единого фреймворка оркестрации. Локальная GPU-среда, которая прекрасно справлялась с небольшими нагрузками, стала узким местом по мере роста циклов обучения и валидации моделей.

Для перестройки использовался Kubernetes плюс стек CNCF-проектов: Envoy Gateway и Gateway API с MetalLB на сетевом уровне, Argo CD и Helmfile поверх существующих Helm-чартов для GitOps-развёртывания, а также Argo Workflows для оркестрации пайплайнов. Именно работа с Envoy Gateway дала выигрыш в 60 раз по времени загрузки. GitOps решил проблему воспроизводимости. Argo Workflows решил проблему пайплайна.

Крис Анищик, CTO CNCF, охарактеризовал победу как пример того, как Kubernetes в связке с Argo, Envoy, Helm, Harbor и MetalLB решают «реальные инфраструктурные задачи, ускоряя при этом AI-инновации». Формулировка самого Кобаяси была более операционной: команда хотела, чтобы инженеры сосредоточились на точности моделей, а не на управлении инфраструктурой. Оба высказывания указывают на одно и то же. Узким местом были никогда не GPU, а всё, что вокруг них.

Техническая анатомия

Цифра «с трёх часов до трёх минут» заслуживает тщательного изучения, поскольку источник не раскрывает точный механизм внутри Envoy Gateway, который её обеспечил. Это важно, потому что ускорение в 60 раз при загрузке 30 ГБ предполагает либо кэширующий слой, либо изменение топологии fan-out, либо изменение формата образа, либо всё вместе. Пресс-релиз упоминает «оптимизацию сетевой архитектуры Kubernetes с использованием Envoy Gateway», Gateway API и MetalLB, но не называет конкретный реестр (Harbor упомянут лишь в цитате CTO CNCF) и не уточняет, применялись ли технологии lazy-pulling. Диапазон неизвестного: улучшение — это либо оптимизация сетевого пути (Envoy обрабатывает трафик загрузки эффективнее прежнего ingress), либо изменение близости реестра, либо и то и другое. В любом случае разрыв достаточно велик, чтобы практически наверняка свидетельствовать об исправлении топологии, а не о точечной настройке конфигурации.

Для понимания того, почему образы вообще весят 30 ГБ: ML-контейнеры включают CUDA-тулкиты, бинарники фреймворков (PyTorch или TensorFlow с поддержкой GPU), веса моделей, зависимости препроцессинга и нередко датасеты для валидации. Легко превысить 20 ГБ ещё до написания единой строки прикладного кода. Официальные рекомендации Docker по многоэтапной сборке и кэшированию слоёв помогают лишь до определённого предела, когда базовый слой CUDA сам по себе занимает несколько гигабайт.

Часть с GitOps на базе Argo CD и Helmfile решает другую проблему. Исходное состояние предполагало ручное выполнение скриптов. Это означает дрейф окружения, незаметное расхождение между тем, что работает, и тем, что зафиксировано в репозитории, а также отсутствие чёткого механизма отката. Наложение Argo CD поверх Helm-чартов с Helmfile как слоем композиции даёт декларативный граф того, что должно быть развёрнуто и где, с непрерывной согласованностью. Аргумент о воспроизводимости, который приводит Кобаяси, — это не маркетинг. Для обучения ML-моделей, требующего аудита (а для ADAS это абсолютно необходимо), точное знание того, какой контейнер, какая конфигурация и какая версия пайплайна породили конкретный чекпоинт модели, — это фактически уже нормативное требование, а не просто приятный бонус.

Argo Workflows отвечает за DAG-оркестрацию самого пайплайна: обработку данных, обучение, валидацию, инференс. До этого, по данным источника, сложные ML-пайплайны «не имели единого фреймворка оркестрации». Перевод: скорее всего, смесь cron-задач, bash-склейки и неформальных знаний команды.

Прогноз: если заявленная архитектура выдержит испытание продакшеном, в течение следующих двух кварталов мы должны увидеть существенный рост частоты итераций модели у Subaru (количество завершённых обучающих запусков в неделю). Только экономия на времени загрузки освобождает примерно 2 часа 57 минут при каждом старте задачи. На кластере, выполняющем десятки задач в день, это накапливается очень быстро.

Кто оказывается в проигрыше

Больше всего под удар этого кейса попадают команды, управляющие ML-платформами, где никто давно не измерял стоимость холодного старта. Таких команд немало. Если ваши датасаентисты жалуются, что «кластер медленный», а платформенная команда в ответ показывает дашборды утилизации GPU, — вероятнее всего, реальная боль кроется в задержке загрузки образов, запуске sidecar-контейнеров или времени монтирования PVC, и ни один из этих параметров не отображается в GPU-метриках.

Команды в автомобильной и промышленной ML-сфере оказываются в особенно неудобном положении. Нагрузки ADAS, робототехники и промышленного контроля качества имеют тот же профиль, что и у Subaru: крупные образы (CUDA плюс проприетарные CV-стеки), локальные GPU-кластеры (требования к гравитации данных и задержкам не позволяют переходить в публичное облако) и жёсткие требования к воспроизводимости. Любой конкурент, всё ещё запускающий ручные скрипты развёртывания на локальных GPU, теперь очевидно отстаёт по операционному инструментарию. Награда CNCF придаёт подходу Subaru статус неформальной эталонной архитектуры в закупочных переговорах на ближайшие 12 месяцев.

Команды в fintech и iGaming-платформах менее непосредственно затронуты, но должны обратить внимание на GitOps-часть. Паттерн наложения Argo CD и Helmfile поверх существующих Helm-чартов (вместо полного отказа от Helm) — это низкорисковый путь миграции, который многие команды до сих пор не использовали. Если ваши продакшен-деплои всё ещё предполагают запуск скрипта с чьего-то ноутбука, вы находитесь на неправильной стороне этого тренда.

Неизвестное, которое стоит отметить: источник не раскрывает ни размер кластера, ни количество GPU, ни стоимость миграции, ни её продолжительность. Без этих цифр ROI не поддаётся количественной оценке извне. Разумная верхняя граница: проект занял несколько инженерных кварталов, поскольку внедрение Envoy Gateway, Argo CD, Helmfile и Argo Workflows в интегрированном виде на существующем локальном GPU-кластере — это не задача на два спринта. Любой CTO, рассчитывающий повторить это за месяц, будет разочарован.

План действий для инженерных команд

Начните с измерений, а не с выбора инструментов. Инструментируйте задержку загрузки контейнеров, распределение размеров образов и время от старта задачи до первой операции с GPU на всех ML-кластерах. Если вы ещё не экспортируете эти метрики, подключите OpenTelemetry-коллекторы к агентам узлов на этой неделе. Нельзя утверждать об улучшении в 60 раз по тому, что не было измерено изначально.

Честно проверьте размер образов. Если ваши обучающие образы превышают 20 ГБ, разделите их: базовые слои CUDA и фреймворков в редко меняющийся родительский образ, код приложения и конфигурации в лёгкий дочерний образ. Это базовая гигиена, которую большинство ML-команд игнорируют, потому что «на моём ноутбуке всё работает».

На уровне развёртывания, если вы всё ещё запускаете скрипты, переходите к GitOps поэтапно. Argo CD поверх существующих Helm-чартов — путь с наименьшим трением. Helmfile как слой композиции — следующий шаг. Вам не нужно ничего переписывать, чтобы получить выигрыш в воспроизводимости: достаточно поставить цикл согласования перед тем, что у вас уже есть.

Для оркестрации пайплайнов Argo Workflows — один из нескольких вариантов (Kubeflow Pipelines, Flyte, Dagster). Конкретный выбор менее важен, чем принятие одного инструмента и стандартизация на нём. Фрагментированная оркестрация между командами — большая проблема, чем выбор «неправильного» инструмента.

Проверяемый прогноз: любая команда, которая инструментирует задержку загрузки и размер образов в этом квартале, найдёт хотя бы одну нагрузку, где улучшение в 10 раз достижимо за выходные. Если окажется, что ваша исходная точка уже хороша — поздравляем, вы уже опережаете стартовую позицию Subaru.

Ключевые выводы

• Subaru сократил время загрузки AI-контейнеров примерно с трёх часов до трёх минут — улучшение в 60 раз — за счёт оптимизации сетевой инфраструктуры Kubernetes с помощью Envoy Gateway, Gateway API и MetalLB.
• Исходное состояние (образы 30+ ГБ, ручные скрипты развёртывания, отсутствие единой оркестрации пайплайна) встречается в ML-платформах чаще, чем готовы признать большинство CTO.
• GitOps-миграция использовала Argo CD и Helmfile поверх существующих Helm-чартов — низкорисковый паттерн, который стоит взять на вооружение любой команде, всё ещё запускающей скрипты развёртывания.
• Источник не раскрывает размер кластера, стоимость и сроки миграции, поэтому ROI не поддаётся внешней оценке; реалистичная нижняя граница — несколько инженерных кварталов.
• Если ваша ML-команда винит «медленные GPU», не измеряя задержку загрузки и время старта задач, вы диагностируете не то узкое место.