Чому Docker для AI/ML ламається на GPU і великих моделях
Найчастішу відмову видно вже на першому запуску в замовника: у нас контейнер отримує доступ до GPU, на його стенді — ні.
Причина зазвичай не в коді, а в розбіжності драйвера на хості та бібліотек усередині образу: середовище виконання не прокидає пристрій, і модель непомітно переходить на процесор. Така невідтворювана збірка коштує днів листування та перевстановлень.
Друга лінія — проблеми контейнеризації GPU через конфлікт версій драйверів і обчислювальних бібліотек. Образ, зібраний поверх свіжої гілки CUDA, не стартує на хості зі старим драйвером, а його оновлення ламає вже працюючий контейнер.
Поки залежності не зафіксовані, кожен стенд живе своїм життям, і «у мене працює» перестає щось значити.
Важкі образи моделей погіршують картину. Базовий шар з повним набором бібліотек, ваги, кеш пакетів та інструменти збірки залишаються у фінальному артефакті — образ розростається, довго розгортається на новому вузлі та роздуває реєстр. Кожен експеримент додає ще одну таку збірку, і видалити її без наслідків уже страшно.
Далі — ручна збірка під кожну модель. Свій Dockerfile на кожну архітектуру, залежності ставляться руками, кроки відтворюються з пам'яті інженера.
Передача проєкту перетворюється на переказ, а не на передачу артефактів: у підрядника й у замовника виходять різні середовища при одному й тому самому коді.
У сумі це не дрібні незручності, а прямі втрати часу на кожному запуску й оновленні. Нижче розбираємо, як ці відмови закриваються в Docker для AI/ML — на рівні збірки образів, фіксації залежностей і доступу до прискорювачів.
Що дає оптимізація образів і GPU-прискорення в роботі
Образ з моделлю обростає залежностями швидше, ніж код: файли ваг, бібліотеки прискорення, системні пакети. Поки все лежить в одному шарі, будь-яка правка перезбирає його цілком — час збірки образу зростає з кожною ітерацією, а реєстр пухне.
Розділення на шари та кеш для рідко змінюваних частин дають збірку за хвилини замість десятків хвилин.
GPU-прискорення в контейнерах тримається на трьох речах: прокидання пристроїв, сумісний рантайм і зафіксовані версії драйверів.
Ми виносимо їх у базовий шар і не даємо оновлюватися довільно — контейнер бачить прискорювач однаково на всіх стендах, від розробки до промислового контуру. Для зв'язки з NVIDIA прокидання винесено окремим шаром: зміна драйвера не ламає збірку цілком.
Відтворюваність запуску — похідна від того ж порядку. Оптимізація docker образу включає фіксацію версій бібліотек, контроль базових образів і розкладку залежностей так, щоб важкі ваги кешувалися окремо від коду. Образ, зібраний учора, піднімається сьогодні без «розбіжності середовищ».
Підсумок вимірюваний: час збірки скорочується в рази, розмір образу моделі падає без втрати функціональності, частка успішних запусків зростає, а клас відмов через незбіг версій зникає з підтримки.
Збірка Docker для AI/ML: порівняння підходів і режимів
Збірка образу під AI-навантаження відрізняється від звичайного сервісу: всередину потрапляють GPU-бібліотеки, драйверні прив'язки та ваги моделей, а база й порядок шарів задають, скільки триває перезбірка і як часто падає запуск на прискорювачі. На практиці обирають між чотирма схемами — і в кожної є ціна.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Єдиний базовий образ | Кілька моделей на спільному стеку, важлива економія місця на нодах | Роздувається: залежності всіх задач лежать в одному шарі, будь-яке оновлення перезбирає все |
| Окремий образ на модель | Моделі живуть своїм циклом і вимагають різних версій бібліотек | Зростає число артефактів і час на обслуговування, реєстр без політики зберігання швидко забивається |
| Шарувата надбудова | Базовий стек стабільний, змінюються ваги й код виводу моделі | Шари потрібно впорядковувати від рідких до частих, інакше кеш не перевикористовується і збірка знову тягне все |
| Готовий сторонній образ | Потрібно за години перевірити гіпотезу, а не будувати середовище | Непрозорий склад, зайві залежності в шарах, складніше пройти перевірку на уразливості та відтворити збірку |
Зверху на вибір накладаються обмеження самого контейнерного запуску: доступ до прискорювача через прокидання пристроїв, незбіг версії драйвера на хості та в образі, розмір ваг моделі в шарі й заборона на дозавантаження з мережі в закритому контурі.
Тому схему підбирають не за «чистотою» рішення, а під те, як часто змінюються моделі та наскільки суворі вимоги до відтворюваності. Опишіть задачу — повернемося з оцінкою та планом.
Порядок впровадження: від аудиту стенда до передачі
Порядок робіт будуємо так, щоб робочий стенд не змінювався наосліп: спочатку фіксуємо поточний стан, потім збираємо схему контейнерів і тільки після цього переносимо навантаження.
Кожен етап закінчується артефактом, який можна перевірити — без нього до наступного кроку не переходимо, тому розбіжність «у мене працює» і «на сервері падає» випливає на етапі налаштування, а не в день запуску.
- Аудит стенда. Інвентаризуємо сервери, моделі прискорювачів, версії драйверів і бібліотек, склад залежностей кожної моделі. На виході — карта: що вже розгортається в контейнерах, що живе на хості й що конфліктує між собою.
- Схема контейнерів. Визначаємо число образів, базовий шар, порядок шарів з урахуванням кешу та правила тегування. Важкі ваги моделей виносимо за образ — образ перестає важити гігабайти й перезбирається за хвилини, а не десятки хвилин.
- Доступ до прискорювачів. Налаштовуємо прокидання пристроїв, права користувача всередині контейнера та ізоляцію між сервісами. Перевіряємо, що при перезапуску хоста контейнер піднімається сам і бачить прискорювач без ручних команд.
- Перевірка на навантаженні. Проганяємо реальні сценарії інференсу й навчання: паралельні запити, пікові черги, поведінку при нестачі пам'яті. Дивимося не середні, а найгірші часи відгуку.
- Регламент оновлення. Фіксуємо політику версій, зберігання останніх збірок і порядок відкату на попередню. Оновлення перестає бути подією з ризиком — стає рутинною операцією.
- Передача в експлуатацію. Віддаємо документацію зі збірки та запуску, проводимо навчання команди, розбираємо типові відмови. Далі супровід іде за нашим регламентом або силами ваших інженерів.
Конфігурації, схеми та регламенти, які ви отримуєте
Робота закінчується не запущеним контейнером, а комплектом артефактів, за яким ваша команда зможе збирати, оновлювати й відкочувати середовище без нашої участі. Нижче — що саме залишається у вас після здачі.
- Карта образів: який образ під яку задачу — навчання, вивід, підготовка даних, — що лежить у спільному базовому шарі, де починається прикладний і які залежності закріплені жорстко.
- Схема розміщення прискорювачів: які вузли віддають прискорювачі, як вони діляться між задачами, де впирається по пам'яті, і як налаштовано прокидання пристроїв усередину контейнера.
- Політики доступу до реєстру: ролі та права, хто публікує і хто тільки читає, строк життя ключів, правила зберігання останніх тегів і заборона перезапису вже випущеного.
- Регламент оновлення образів: періодичність перезбірки базового шару, порядок перевірки перед публікацією, умови та процедура відкату на попередній тег.
- Документація збірки: файли збірки з коментарями, перелік залежностей, обґрунтування багатоетапної збірки та того, що свідомо залишено поза образом.
- Інструкція для експлуатації: запуск і зупинка, перевірка доступності прискорювачів, збір логів і метрик, розбір типових збоїв і порядок дій при них.
- Схема контурів: чим відрізняються стенд розробки, тестове й робоче середовища, що переноситься між ними, а що задається окремо.
Комплект супроводжуємо розбором з вашою командою — щоб рішення далі приймалися за документами, а не з пам'яті конкретного інженера.
Кейс: час збірки скоротився, відмови GPU зникли
Проєкт — навчання й розгортання моделей на кількох вузлах з прискорювачами, кілька команд і спільний парк серверів. Середовище під задачу збирали руками: доставка залежностей, перевірка сумісності, запуск. Нижче — чого це коштувало до впровадження і що змінилося після переходу на єдину схему образів.
Що було
З приблизно сорока збірок на місяць половина відтворювалася з розбіжностями: локально модель сходилася, на сервері падала на імпорті бібліотек. Контейнери на Docker збирали вручну й зберігали поза спільним реєстром — кожен вузол жив зі своїм набором залежностей.
Окрема стаття втрат — відмови GPU: драйвер на вузлі не збігався з очікуваннями образу, і задача вмирала на старті, вже зайнявши чергу на навчання.
Що змінили і що стало
Ми звели середовища до одного базового образу з фіксованим набором бібліотек і шарів: прикладні образи успадковуються від нього й відрізняються тільки кодом і налаштуваннями.
Перевірку сумісності з драйвером перенесено в крок збірки — незбіг виявляється до постановки задачі в чергу, а не в її середині.
Збірка займає хвилини замість годин, відтворюваність запусків близька до повної, відмови GPU на старті зведені до поодиноких випадків. Реєстр не розростається: політика зберігання тримає обмежену кількість шарів на тег, а відкат до попереднього образу — одна команда.
Чим відрізняється спільний базовий образ від образу під одну модель?
Спільний базовий образ — це одне середовище з середовищем виконання, бібліотеками для обчислень на прискорювачах і спільними утилітами, поверх якого ставиться кожна модель. Образ під модель — окрема збірка з рівно тим набором залежностей, який потрібен одній моделі. Різниця проявляється там, де команда платить: часом збірки або ризиком конфлікту залежностей.
Перший виграє на перевикористанні шарів. Шар із системними бібліотеками й драйверами збирається один раз і далі береться з кешу для всіх моделей — перезбірка після правки коду йде хвилини замість десятків хвилин. Один набір перевірок і один сценарій розгортання замість кількох.
Зворотний бік — конфлікт залежностей. Коли одній моделі потрібна новіша гілка бібліотеки, розв'язання версій ламає середовище сусідньої: модель, яка вчора відповідала коректно, падає на старті або змінює результат, а причина лежить у спільному шарі. Відкат теж спільний — повертаючи одну модель, ви тягнете назад середовище для всіх.
Окремий образ окупається, коли модель змінюється часто, а залежності жорстко зафіксовані. Код і ваги лежать у верхньому шарі, базовий залишається з кешу, відкат точковий: підміна тега повертає попередню версію, не зачіпаючи сусідні сервіси. Ціна — розмір реєстру та число складальних сценаріїв.
Вибір стратегії збірки зводиться до двох питань: як часто оновлюється модель і наскільки розходяться її вимоги з іншими.
При рідких оновленнях і спільному стеку достатньо одного базового образу; при частих розгортаннях і розбіжностях беруть тонкий базовий шар з драйверами й надбудовують над ним образ під модель — перевикористання шарів зберігається, а конфлікт залежностей залишається всередині одного шару.
Обмеження, сумісність і часті технічні сумніви
Контейнер вирівнює середовище застосунку, але не скасовує шар під ним: доступ до прискорювача, версія драйвера на вузлі та вимоги ядра залишаються поза межами образу.
Отже, парк машин доводиться тримати в узгодженій версії драйвера — інакше один і той самий образ на частині вузлів просто не побачить пристрій. Матрицю сумісності фіксуємо заздалегідь і перевіряємо на пілотному вузлі, а не в день розгортання.
Частина речей не уніфікується в принципі: розподіл пам'яті між процесами, реальна пропускна здатність під конкретною моделлю, поведінка при нестачі пам'яті. Тут залишається ручна перевірка на бойовому профілі навантаження — синтетика показує тільки стелю, а не робочий режим.
І є межа застосовності: там, де потрібен прямий доступ до обладнання або навчання на кількох вузлах зі спільною шиною, частина чесно залишається на залізній машині.
У нас моделі вже працюють поза контейнером — переносити все заново?
Ні. Переносимо по кроках: спочатку середовище — залежності, ваги, точка входу, потім звірка результату на однакових входах, і тільки після цього перемикаємо трафік. Старий запуск залишається доступним для відкату, поки новий не пройде повний цикл навантаження.
Що робити, якщо вузли зібрані на різних драйверах?
Образ збираємо під наймолодшу узгоджену версію — NVIDIA тримає зворотну сумісність усередині мажорної гілки. Де вузол відстає, драйвер підтягують до спільної гілки; якщо це неможливо, вузол виводимо з пулу під цю задачу, а не латаємо образ.
Обговоримо задачу: стенд, моделі та вимоги до запуску
Обговоримо задачу предметно: щоб оцінка робіт спиралася на факти, а не на здогадки, почнемо з вхідних даних по стенду та моделях. Достатньо надіслати те, що вже є під рукою.
За цими даними видно, де вузьке місце — збірка, розмір образу, сумісність драйверів або відтворюваність на іншому вузлі.
Що допомагає порахувати роботи точно:
- склад моделей і режим запуску: навчання, донавчання або тільки вивід;
- параметри стенда: тип і число прискорювачів, доступність драйверів і середовища виконання;
- поточна збірка Docker-образів і скарги: час, розмір, відмінності між вузлами;
- реєстр образів: де зберігається, у кого доступ, як чистяться старі версії;
- середовище запуску: один сервер, хмара, кластер, оркестратор;
- робота з даними й томами: набори даних, локальні копії ваг, артефакти навчання;
- обмеження: закритий контур, політики безпеки, регламент оновлень.
Першу розмову веде інженер, який потім буде робити роботу, — без переказу через посередників. Розбираємо схему запуску, спірні місця та вже прийняті рішення, після чого фіксуємо, що беремо в першу чергу.
Повернемося з оцінкою та планом впровадження: етапи, строки, відповідальні, точки перевірки та порядок відкату на попередній образ. Наступний крок — опишіть задачу й надішліть вхідні дані по стенду, решту уточнимо на зв'язку.
