5 порад для навчання мульти-GPU з Keras

• Січень 21, 2018
• Василіс Врініотис
• . 1 коментар

Глибоке навчання (улюблене модне слово кінця 2010-х років разом із блокчейном/біткойном та наукою про дані/машинним навчанням) дозволило нам робити деякі дійсно круті речі за останні кілька років. Крім прогресу в алгоритмах (які, за загальним визнанням, засновані на ідеях, уже відомих з 1990-х років, або «ера інтелекту даних»), основні причини його успіху можна віднести до наявності великих безкоштовних наборів даних, впровадження бібліотек з відкритим кодом і використання графічних процесорів. У цій публікації в блозі я зосереджуся на двох останніх і поділюся з вами деякими порадами, які я навчився нелегким шляхом.

Чому TensorFlow & Keras?

TensorFlow – це дуже популярна бібліотека глибокого навчання, розроблена Google, яка дозволяє швидко створювати прототип складних мереж. Він має безліч цікавих функцій, таких як автоматичне диференціювання (що позбавляє вас від оцінки/кодування градієнтів функцій витрат) і підтримка графічного процесора (що дозволяє легко отримати 200-кратне підвищення швидкості за допомогою пристойного обладнання). Крім того, він пропонує інтерфейс Python, що означає, що ви можете швидко створювати прототип без необхідності писати код C або CUDA. Правда, є багато інших фреймворків, які можна використовувати замість TensorFlow, таких як Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK тощо, але все зводиться до вашого варіанту використання та ваших особистих уподобань.

Але чому Керас? Для мене використання безпосередньо TF схоже на машинне навчання за допомогою Numpy. Так, це можливо, і час від часу вам доведеться це робити (особливо якщо ви пишете власні шари/функції втрат), але чи справді ви хочете писати код, який описує складні мережі як серію векторних операцій (так, я знаю в TF є методи вищого рівня, але вони не такі круті, як Keras)? А що робити, якщо ви хочете перейти до іншої бібліотеки? Ну тоді вам, ймовірно, доведеться переписати код, що нудно. Та та тааа, Керас на допомогу! Keras дозволяє описувати свої мережі за допомогою концепцій високого рівня та писати код, який не залежить від серверної частини, що означає, що ви можете запускати мережі в різних бібліотеках глибокого навчання. Мало що мені подобається в Keras, так це те, що він добре написаний, має об’єктно-орієнтовану архітектуру, його легко зробити, і він має дружню спільноту. Якщо вам подобається, скажіть спасибі Франсуа Шолле для його розробки та відкритого вихідного коду.

Поради та підказки щодо навчання на кількох GPU

Без зайвих розмов, давайте перейдемо до кількох порад про те, як максимально використати навчання GPU на Keras, а також до кількох нюансів, які ви повинні мати на увазі:

1. Навчання на кількох GPU не є автоматичним

Навчання моделей на графічному процесорі за допомогою Keras & Tensorflow проходить без проблем. Якщо у вас є карта NVIDIA і ви встановили CUDA, бібліотеки автоматично виявлять її та використовуватимуть для навчання. Так кльово! Але що, якщо ви розпещений нахабник і у вас є кілька графічних процесорів? На жаль, вам доведеться трохи попрацювати, щоб отримати навчання з кількома графічними процесорами.

Існує кілька способів розпаралелювання мережі залежно від того, чого ви хочете досягти, але два основні підходи — це моделювання та розпаралелювання даних. Перший може допомогти вам, якщо ваша модель занадто складна, щоб поміститися в один GPU, тоді як другий допомагає, коли ви хочете прискорити виконання. Зазвичай, коли люди говорять про навчання з кількома графічними процесорами, вони мають на увазі останнє. Раніше цього було важче досягти, але, на щастя, Keras нещодавно включив утиліту під назвою mutli_gpu_model що спрощує паралельне навчання/прогнозування (наразі доступно лише з сервером TF). Основна ідея полягає в тому, що ви передаєте свою модель через метод, і вона копіюється на різні графічні процесори. Початковий вхід розбивається на фрагменти, які надходять до різних графічних процесорів, а потім вони об’єднуються як єдиний вихід. Цей метод можна використовувати для досягнення паралельного навчання та прогнозування, однак слід пам’ятати, що для навчання він не масштабується лінійно з кількістю графічних процесорів через необхідну синхронізацію.

2. Зверніть увагу на розмір партії

Коли ви виконуєте навчання з кількома графічними процесорами, зверніть увагу на розмір пакету, оскільки він багаторазово впливає на швидкість/пам’ять, конвергенцію вашої моделі, і якщо ви не будете обережні, ви можете пошкодити ваги моделі!

Швидкість/пам'ять: Очевидно, що більша партія, тим швидше навчання/прогнозування. Це пов’язано з тим, що існують накладні витрати на введення та вилучення даних із графічних процесорів, тому невеликі пакети мають більше накладних витрат. З іншого боку, чим більше пакет, тим більше пам’яті вам потрібно в GPU. Особливо під час навчання вхідні дані кожного шару зберігаються в пам’яті, оскільки вони потрібні на етапі зворотного поширення, тому занадто велике збільшення розміру пакету може призвести до помилок браку пам’яті.

Конвергенція: Якщо ви використовуєте Stochastic Gradient Decent (SGD) або деякі з його варіантів для навчання моделі, ви повинні мати на увазі, що розмір пакету може вплинути на здатність вашої мережі зближуватися та узагальнювати. Типові розміри пакетів для багатьох проблем комп’ютерного зору становлять від 32 до 512 прикладів. Як Кескар та ін сказав: «На практиці було помічено, що при використанні більшої партії (ніж 512) спостерігається погіршення якості моделі, що вимірюється її здатністю до узагальнення». Зауважте, що інші оптимізатори мають різні властивості, і спеціалізовані методи розподіленої оптимізації можуть допомогти вирішити цю проблему. Якщо вас цікавлять математичні деталі, рекомендую прочитати тезу Джоері Германса “Про масштабоване глибоке навчання та паралельний градієнтний спуск".

Пошкодження ваги: Це неприємна технічна деталь, яка може призвести до руйнівних наслідків. Коли ви проводите навчання з кількома графічними процесорами, важливо наповнювати всі графічні процесори даними. Може статися, що останній пакет вашої епохи містить менше даних, ніж визначено (оскільки розмір вашого набору даних не можна точно розділити на розмір вашого пакету). Це може призвести до того, що деякі графічні процесори не отримають жодних даних під час останнього кроку. На жаль, деякі шари Keras, зокрема шар пакетної нормалізації, не можуть впоратися з цим, що призводить до того, що значення nan з’являються у вагових коефіцієнтах (побіжне середнє та дисперсія в шарі BN). Щоб зробити речі ще більш неприємними, ми не будемо спостерігати проблему під час навчання (у той час як фаза навчання дорівнює 1), оскільки конкретний рівень використовує середнє/дисперсію пакету в оцінках. Тим не менш, під час передбачення (фаза навчання встановлено на 0) використовується поточне середнє/дисперсія, яка в нашому випадку може стати nan, що призводить до поганих результатів. Тож зробіть собі послугу та завжди переконайтеся, що розмір вашої партії фіксований, коли ви проводите навчання з кількома графічними процесорами. Двома простими способами досягти цього є або відхилення пакетів, які не відповідають попередньо визначеному розміру, або повторення записів у пакеті, доки ви не досягнете попередньо визначеного розміру. І останнє, але не менш важливо, майте на увазі, що в установці з кількома графічними процесорами розмір пакету має бути кратним кількості доступних графічних процесорів у вашій системі.

3. Голодування даних графічного процесора, або процесори, не встигають за графічними процесорами

Зазвичай найдорожча частина під час навчання/прогнозування глибоких мереж - це оцінка, яка відбувається на GPU. Дані попередньо обробляються в ЦП у фоновому режимі і періодично надходять на графічні процесори. Проте не варто недооцінювати, наскільки швидкі графічні процесори; може статися так, що якщо ваша мережа занадто дрібна або етап попередньої обробки занадто складний, то ваші ЦП не зможуть встигати за вашими графічними процесорами або, іншими словами, вони не надають їм дані достатньо швидко. Це може призвести до низького використання графічного процесора, що призводить до втрати грошей/ресурсів.

Keras зазвичай виконує оцінки пакетів паралельно, проте завдяки GIL (Global Interpreter Lock) Python ви не можете досягти справжньої багатопотокової роботи в Python. Для цього є два рішення: або використовуйте кілька процесів (зверніть увагу, що в цьому є багато проблем, які я не збираюся тут висвітлювати), або спростіть крок попередньої обробки. Раніше я надсилав запит на витягування до Keras, щоб зменшити непотрібне навантаження, яке ми робимо на центральні процесори під час попередньої обробки зображення, тому більшість користувачів не повинні постраждати від використання стандартних генераторів. Якщо у вас є власні генератори, спробуйте просувати якомога більше логіки в бібліотеки C, такі як Numpy, тому що деякі з цих методів насправді звільнити GIL це означає, що ви можете збільшити ступінь паралелізації. Хороший спосіб визначити, чи не вистачає даних графічного процесора, — стежити за використанням графічного процесора, але попереджайте, що це не єдина причина для цього (синхронізація, яка відбувається під час навчання на кількох графічних процесорах, також винна у низькому використанні ). Зазвичай нестачу даних GPU можна виявити, спостерігаючи сплески графічного процесора з наступними довгими паузами без використання. У минулому я створював розширення для Dstat з відкритим кодом, яке може допомогти вам виміряти використання графічного процесора, тому подивіться на оригінальний блог.

4. Збереження ваших паралельних моделей

Скажімо, ви використовували метод mutli_gpu_model для розпаралелювання моделі, навчання закінчилося, і тепер ви хочете зберегти її ваги. Погана новина полягає в тому, що ви не можете просто викликати save() для цього. Наразі у Keras є обмеження, яке вам не дозволяє зберегти паралельну модель. Є 2 способи обійти це: або викличте save() за посиланням на вихідну модель (ваги будуть оновлюватися автоматично), або вам потрібно серіалізувати модель, вирізавши розпаралельну версію та очистивши всі непотрібні з’єднання. Перший варіант набагато простіше, але в майбутньому я планую відкрити метод serialize(), який виконує останній.

5. Підрахунок доступних графічних процесорів має неприємний побічний ефект

На жаль, на даний момент існує неприємний побічний ефект для методу tensorflow.python.client.device_lib.list_local_devices(), який викликає створення нового сеансу TensorFlow та ініціалізацію всіх доступних графічних процесорів у системі. Це може призвести до неочікуваних результатів, таких як перегляд більше графічних процесорів, ніж зазначено, або передчасна ініціалізація нових сеансів (ви можете ознайомитися з усіма подробицями про це тягнути-запит). Щоб уникнути подібних сюрпризів, радимо замість цього використовувати метод Keras K.get_session().list_devices(), який поверне всі зареєстровані на даний момент графічні процесори в сеансі. І останнє, але не менш важливе, майте на увазі, що виклик методу list_devices() чомусь дорогий, тому, якщо вас цікавить кількість доступних графічних процесорів, викличте метод один раз і збережіть їх кількість у локальній змінній.

Це воно! Сподіваюся, ви знайшли цей список корисним. Якщо ви знайшли інші проблеми або поради щодо навчання GPU на Keras, поділіться ними нижче в коментарях. 🙂