Визначте одиницю роботи, яку можна відокремити
Опишіть, що становить прийнятий результат: зображення, оброблений документ, набір симуляцій або кінцевий стан навчання. Потім запитайте, чи можна обчислити одиницю, не чекаючи на інші. Два документи можуть бути незалежними під час обробки, а потім залежати від спільного етапу побудови індексу. Цей поділ має описувати другий етап, а не забувати про нього в обіцянці паралелізму.
Розрізняйте обчислювальну та бізнесову незалежність. Результат може бути створений без технічного обміну й залишатися непридатним до затвердження всього пакета. Тож назвіть одиницю обчислення, одиницю доставки та правило складання. Цей спільний словник запобігає ситуації, коли закупівлі рахують карти, тоді як прикладна команда рахує екземпляри чи фрагменти однієї моделі.
Вибір між незалежними завданнями та тісною співпрацею
Для незалежних завдань кожен процес отримує власні вхідні дані та створює ідентифікований результат. Інша карта може виконувати інше завдання без синхронізації на кожному етапі. Цей режим цікавий, коли мета стосується обсягу, завершеного за певний проміжок часу. Він не прискорює автоматично окреме завдання, і ще належить перевірити конкуренцію за дані, сховище чи ліцензії.
Для спільної роботи пристрої обмінюються даними або очікують на проміжний результат. Програма має керувати цим розподілом. Посібник CUDA пояснює, що використання кількох GPU передбачає контексти, розподіл даних, запуски та комунікації. Це властивості програмного шляху та спостережуваної системи; назва карти з каталогу не доводить, що цей шлях уже існує.
| Питання | Незалежні завдання | Спільна робота |
|---|---|---|
| Що отримує карта? | Окреме повне завдання | Частину або копію роботи |
| Що потрібно координувати? | Призначення вхідних даних і збір результатів | Обміни, порядок і синхронізації |
| Яку вигоду перевірити? | Кількість прийнятих результатів за проміжок часу | Ідентичний результат з адаптованим часом або потужністю |
| Який збій передбачити? | Окреме завдання або публікацію | Вплив недоступного учасника на групу |
Не плутайте реплікацію з розподілом пам'яті
Кілька копій моделі не означають, що її параметри розділені між картами. PyTorch DistributedDataParallel синхронізує градієнти між процесами, які навчають свої локальні моделі. Тому цей підхід не дає змоги лише за його назвою зробити висновок, що модель, завелика для однієї карти, поміститься на кількох. Механізм розподілу потребує власної документації та власної перевірки.
Пам'ять кожної карти має покривати те, що програмне забезпечення фактично туди розміщує: дані, стан моделі, тимчасові простори та можливі обміни. Пік може змінюватися залежно від налаштувань і фази обробки. Фіксуйте його для кожного пристрою. Сума номінальних ємностей приховує дисбаланс, коли одній карті бракує пам'яті, тоді як інші зберігають запас. Загальної ємності пакета недостатньо, щоб прийняти сценарій.
Вигаданий приклад: розподіл восьми незалежних конверсій
Вигадана команда «Індекс видань» готує вісім конверсій документів. У її робочій гіпотезі кожна конверсія займає карту протягом дванадцяти хвилин, включно із завантаженням і виведенням. Завдання вміщується на карті самостійно, і жодного обміну не потрібно до фінального складання. Ці тривалості слугують лише для побудови міркування: вони не описують жодного виконання чи продуктивності GPU, запропонованої Capordia.
З однією картою вісім послідовних завдань становлять 8 × 12 = 96 хвилин. З двома картами та рівномірним розподілом по чотири завдання на кожну паралелізована частина теоретично становить 48 хвилин. Якщо фінальне складання вимагає десяти хвилин на окремому вузлі, повний шлях становить відповідно 106 або 58 хвилин, без урахування очікування перед запуском. Цей розрахунок припускає, що обидві карти не сповільнюють взаємне завантаження.
| Організація | Паралелізована частина | Складання | Розрахункова тривалість |
|---|---|---|---|
| Одна карта, вісім завдань | 96 хв | 10 хв | 106 хв |
| Дві карти, по чотири завдання кожна | 48 хв | 10 хв | 58 хв |
Виявити те, що може звести нанівець цей теоретичний виграш
У тому самому прикладі документи можуть бути неоднакового розміру. Якщо призначити чотири найдовші на одну карту, інша чекатиме наприкінці. Розподіл у міру настання доступності може поліпшити баланс, але він вимагає надійного механізму призначення та політики допуску. Посібник із черги розглядає цю організацію; цей розрахунок не засвідчує, що її вже впроваджено.
Сховище також може стати домінантним спільним ресурсом. Два процеси, які читають ті самі дані або одночасно записують великі результати, не обов'язково мають подвоєну пропускну здатність. Перевіряйте також обмеження щодо паралелізму в інструментах і ліцензіях. Якщо непаралелізована частина зростає, перерахуйте весь графік. Час, заощаджений на одній фазі, не повинен приховувати затримку, додану деінде.
Для розподіленої роботи отримати реальну топологію
Запитайте, які карти видимі, як вони взаємодіють і які ресурси хоста спільно використовують їхні процеси. Перевірте пристрої, доступні із середовища, яке використовується, а не лише з консолі адміністратора. CUDA зазначає, що доступ до пам'яті іншого GPU залежить, зокрема, від топології та можливостей системи. Підтримка функції моделлю не доводить наявності очікуваного зв'язку на машині.
Зберігайте просту схему руху даних: вхід, відповідна карта або процес, обміни, фінальне збирання та вихід. Для кожної стрілки визначте, чи перетинає вона пам'ять хоста, зв'язок між GPU або мережу. Цей огляд слугує для вибору контрольних перевірок під час приймання. Він не нав'язує певної технології та не перетворює запит на кілька GPU в обіцянку конкретної топології.
Порівняти дві організації, не змінюючи очікуваного результату
Підготуйте невеликий репрезентативний корпус і виконайте на вашій дозволеній цільовій системі еталонну організацію, а потім кандидатну організацію. Збережіть версії, налаштування, очікувану якість і правила складання. Порівняйте час до прийнятного результату, пікову пам'ять кожної карти, помилки та споживання спільних ресурсів. Відокремлюйте спостереження від оцінок; запропонована команда не дорівнює вже отриманому результату.
Зокрема перевірте, що кількість прийнятих виходів залишається тією самою і що жоден вхід не пропущено. Для обчислення, чутливого до порядку операцій, виберіть обґрунтований допуск, а не довільну рівність. Організація, яка завершується швидше з іншою якістю, відповідає на іншу задачу. Збережіть також випадок, коли розподіл невигідний: ця межа пояснює вибір краще, ніж рейтинг карт без спільного навантаження.
Перетворити вибір на потрібну потужність
Зрештою запишіть кількість одночасних завдань, потрібні для кожного карти та обов'язкові умови. Завдання, розподілене на дві карти, і два завдання на одній карті — це дві різні організації, навіть якщо загальна кількість карт однакова. Обрана конфігурація має уможливлювати потрібну організацію; не виходьте із номінальної загальної кількості, щоб потім вигадати їй застосування.
Каталог наводить лоти карт. Лот B200 містить два GPU по 180 ГБ кожен; такий склад не гарантує, що програмне забезпечення використає їх як єдину пам'ять. Наступний крок — узгодити потребу з лотом, а потім прийняти саме ті властивості, які справді потрібні. Графік, вартість і рішення залишаються попередніми, доки не перевірено вирішальні умови.
Запитання для ухвалення рішення
Чи завжди два GPU швидші за один?
Ні. Виграш залежить від частки, яку можна розпаралелити, обмінів і спільних ресурсів. Для окремого завдання, яке не розподіляється, друга карта може залишитися невикористаною. Порівнюйте час до однакового прийнятного результату за явно визначеним протоколом.
Чи подвоює лот із двох карт доступну пам'ять для моєї програми?
Не автоматично. Кожен пристрій має власну пам'ять, і програма повинна розподіляти свій стан або дані. Реплікація моделі, навпаки, може дублювати значну частину цього стану. Перевірте програмний механізм і пікове значення на карту.
Коли починати з незалежних завдань?
Коли кожну одиницю можна обчислити окремо і мета — завершити більше одиниць. Усе ж потрібно перевірити розподіл, балансування навантаження та фінальне складання, не припускаючи, що сховище й ліцензії зростають автоматично.