Subaru скоротила час завантаження AI-контейнерів у 60 разів завдяки Envoy Gateway

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

Що сталося

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

Попередній стан, за словами джерела, мав цілком конкретні проблеми. 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-платформами, де ніхто нещодавно не вимірював вартість холодного старту. Таких чимало. Якщо ваші дата-сайентисти скаржаться, що «кластер повільний», а ваша platform-команда у відповідь показує дашборди завантаження GPU, є всі шанси, що реальний біль — це затримка завантаження образів, запуск sidecar-контейнерів або час монтування PVC, і жоден із цих показників не відображається у GPU-метриках.

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

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

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

Практичний план для інженерних команд

Починайте з вимірювань, а не з інструментів. Фіксуйте затримку завантаження контейнерів, розподіл розмірів образів і час від запуску завдання до першої GPU-операції у ваших ML-кластерах. Якщо ви ще не експортуєте ці метрики, підключіть колектори OpenTelemetry до своїх node-агентів цього тижня. Ви не зможете заявити про покращення у 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», не вимірюючи затримку завантаження та час запуску завдань, ви діагностуєте не те вузьке місце.