Foresight Ventures: раціональний погляд на децентралізовані обчислювальні мережі

Сцена децентралізованої обчислювальної потужності величезна, але де проблеми?

Автор: Ян Сю, Foresight Ventures

TL;DR

• Наразі існує два основних напрямки поєднання AI + Crypto: розподілена обчислювальна потужність і ZKML; щодо ZKML, будь ласка, зверніться до моєї попередньої статті. Ця стаття проаналізує та обміркує децентралізовану розподілену обчислювальну мережу. *З огляду на тенденцію розвитку великомасштабних моделей штучного інтелекту, ресурси обчислювальної потужності стануть великим полем битви в наступному десятилітті, а також найважливішою річчю для людського суспільства в майбутньому, і вони залишаться не тільки в комерційних цілях. конкуренції, але також стане грою стратегічних ресурсів великих держав. У майбутньому інвестиції у високопродуктивну обчислювальну інфраструктуру та резерви обчислювальної потужності зростатимуть експоненціально.
• Децентралізована розподілена обчислювальна мережа має найбільший попит на навчання великої моделі ШІ, але вона також стикається з найбільшими проблемами та технічними вузькими місцями. Включно з необхідністю складної синхронізації даних і проблемами оптимізації мережі. Крім того, конфіденційність і безпека даних також є важливими обмеженнями. Хоча деякі існуючі методи можуть забезпечити попередні рішення, вони все ще не застосовуються у великомасштабних розподілених навчальних завданнях через величезні обчислювальні та комунікаційні витрати.
• Децентралізована розподілена обчислювальна потужна мережа має кращі шанси приземлитися в модельних міркуваннях, і вона може передбачити, що майбутній додатковий простір також є достатньо великим. Але він також стикається з такими проблемами, як затримка зв’язку, конфіденційність даних і безпека моделі. Порівняно з навчанням моделі логічний висновок має нижчу обчислювальну складність і взаємодію з даними, і він більше підходить для розподілених середовищ.
• Через кейси двох стартап-компаній, Together і Gensyn.ai, з точки зору оптимізації технологій і дизайну рівня стимулів, проілюстровано загальний напрямок досліджень і конкретні ідеї децентралізованої розподіленої обчислювальної мережі.

1. Розподілена обчислювальна потужність — навчання великої моделі

Ми обговорюємо застосування розподілених обчислювальних потужностей у навчанні та загалом зосереджуємося на навчанні великих мовних моделей. Основна причина полягає в тому, що навчання малих моделей не потребує великої обчислювальної потужності. Щоб забезпечити конфіденційність розподілених даних і купу проектів Проблема невигідна, краще вирішувати напряму централізовано. Велика мовна модель має величезний попит на обчислювальну потужність, і зараз вона знаходиться на початковій стадії вибуху. З 2012 по 2018 рік попит на обчислення ШІ подвоюватиметься приблизно кожні 4 місяці. Судячи з того, що наступні 5-8 років будуть все ще є величезний додатковий попит.

Хоча існують величезні можливості, проблеми також потрібно чітко бачити. Всі знають, що сцена величезна, але де конкретні виклики? Хто може націлитися на ці проблеми замість того, щоб сліпо входити в гру, є основою оцінки чудових проектів цього треку.

• *

(NVIDIA NeMo Megatron Framework）

1. Загальний тренувальний процес

Візьмемо, наприклад, навчання великої моделі зі 175 мільярдами параметрів. Через величезні розміри моделі її необхідно паралельно навчати на багатьох графічних пристроях. Припустімо, що є централізований комп’ютерний зал із 100 графічним процесором і кожен пристрій має 32 ГБ пам’яті.

• Підготовка даних: по-перше, потрібен величезний набір даних, який містить різні дані, такі як Інтернет-інформація, новини, книги тощо. Ці дані необхідно попередньо обробити перед навчанням, включаючи очищення тексту, токенізацію, створення словникового запасу тощо.
• Сегментація даних: оброблені дані будуть розділені на кілька пакетів для паралельної обробки на кількох графічних процесорах. Припустімо, що вибраний розмір пакета становить 512, тобто кожен пакет містить 512 текстових послідовностей. Потім ми розбиваємо весь набір даних на пакети, утворюючи чергу пакетів.
• Передача даних між пристроями: на початку кожного етапу навчання ЦП бере пакет із черги пакетів, а потім надсилає дані цього пакета до графічного процесора через шину PCIe. Якщо припустити, що середня довжина кожної текстової послідовності становить 1024 маркери, розмір даних кожного пакету становить приблизно 512 * 1024 * 4B = 2 МБ (припускаючи, що кожен маркер представлено 4-байтовим числом з плаваючою комою одинарної точності). Цей процес передачі даних зазвичай займає лише кілька мілісекунд.
• Паралельне навчання: після того, як кожен пристрій GPU отримує дані, він починає виконувати обчислення прямого проходу та зворотного проходу та обчислює градієнт кожного параметра. Через великий масштаб моделі пам’ять одного GPU не може зберігати всі параметри, тому ми використовуємо технологію паралельної моделі, щоб розподілити параметри моделі на кількох GPU.
• Агрегація градієнта та оновлення параметрів: після завершення обчислення зворотного поширення кожен графічний процесор отримує градієнт частини параметрів. Потім ці градієнти потрібно агрегувати на всіх пристроях GPU, щоб обчислити глобальний градієнт. Для цього потрібна передача даних через мережу, і якщо припустити, що мережа 25 Гбіт/с, то для передачі 700 ГБ даних потрібно приблизно 224 секунди (припускаючи, що для кожного параметра є числа з плаваючою комою одинарної точності, тоді 175 мільярдів параметрів становлять приблизно 700 ГБ). Потім кожен GPU оновлює свої збережені параметри відповідно до глобального градієнта.
• Синхронізація: після оновлення параметрів усі пристрої GPU потрібно синхронізувати, щоб переконатися, що всі вони використовують узгоджені параметри моделі для наступного етапу навчання. Для цього також потрібна передача даних через мережу.
• Повторити кроки навчання: Повторюйте описані вище кроки, доки не буде завершено навчання всіх партій або досягнуто заданої кількості раундів навчання (епохи).

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

2. Вузьке місце комунікаційних витрат:

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

Кожен вузол повинен часто обмінюватися інформацією, щоб працювати разом, що створює накладні витрати на зв’язок. Для великих мовних моделей ця проблема особливо серйозна через велику кількість параметрів моделі. Комунікаційні витрати поділяються на такі аспекти:

• Передача даних: вузли повинні часто обмінюватися параметрами моделі та інформацією про градієнт під час навчання. Це вимагає передачі великого обсягу даних у мережі, споживаючи велику пропускну здатність мережі. Якщо умови мережі погані або відстань між обчислювальними вузлами велика, затримка передачі даних буде великою, що ще більше збільшує накладні витрати на зв’язок.
• Проблема синхронізації: під час навчання вузли повинні працювати разом, щоб забезпечити правильне навчання. Це вимагає частих операцій синхронізації між вузлами, таких як оновлення параметрів моделі, обчислення глобальних градієнтів тощо. Ці синхронні операції потребують передачі великої кількості даних у мережі та чекають, поки всі вузли завершать операцію, що спричинить багато накладних витрат на зв’язок і часу очікування.
• Накопичення та оновлення градієнта: під час процесу навчання кожен вузол повинен обчислити власний градієнт і надіслати його іншим вузлам для накопичення та оновлення. Це вимагає передачі великої кількості градієнтних даних у мережі та необхідності чекати, поки всі вузли завершать обчислення та передачу градієнтів, що також є причиною великої кількості накладних витрат на зв’язок.
• Узгодженість даних: необхідно переконатися, що параметри моделі кожного вузла узгоджені. Це вимагає частих операцій контрольної суми даних і синхронізації між вузлами, що призводить до великих накладних витрат на зв’язок.

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

Як приклад:

Децентралізована розподілена обчислювальна мережа

Модель GPT-3 має 175 мільярдів параметрів, і якщо ми представляємо ці параметри за допомогою чисел з плаваючою комою одинарної точності (4 байти на параметр), то для зберігання цих параметрів потрібно ~700 ГБ пам’яті. У розподіленому навчанні ці параметри потрібно часто передавати та оновлювати між обчислювальними вузлами.

Якщо припустити, що існує 100 обчислювальних вузлів, кожному вузлу потрібно оновити всі параметри на кожному кроці, тоді кожен крок має передати приблизно 70 ТБ (700 ГБ*100) даних. Якщо ми припустимо, що крок займає 1 с (дуже оптимістичне припущення), то 70 ТБ даних потрібно передавати щосекунди. Цей попит на пропускну здатність вже значно перевищує попит на більшість мереж і також є питанням здійсненності.

Насправді через затримки зв’язку та перевантаження мережі час передачі даних може бути набагато довшим за 1 с. Це означає, що обчислювальним вузлам може знадобитися витрачати багато часу на очікування передачі даних замість того, щоб виконувати фактичні обчислення. Це значно знизить ефективність навчання, і це зниження ефективності не можна вирішити за допомогою очікування, а різниці між здійсненним і нездійсненним, що зробить весь процес навчання нездійсненним.

Централізований комп’ютерний кабінет

Навіть у середовищі централізованої комп’ютерної кімнати навчання великих моделей все ще вимагає серйозної оптимізації зв’язку.

У середовищі централізованого комп’ютерного залу високопродуктивні обчислювальні пристрої використовуються як кластер, з’єднаний через високошвидкісну мережу для спільного використання обчислювальних завдань. Однак, навіть при навчанні моделі з надзвичайно великою кількістю параметрів у такому високошвидкісному мережевому середовищі, комунікаційні витрати все ще залишаються вузьким місцем, оскільки параметри та градієнти моделі потрібно часто передавати та оновлювати між різними обчислювальними пристроями. .

Як згадувалося на початку, припустимо, що є 100 обчислювальних вузлів, кожен сервер має пропускну здатність мережі 25 Гбіт/с. Якщо кожному серверу потрібно оновити всі параметри на кожному кроці навчання, тоді кожен крок навчання потребує передавання приблизно 700 ГБ даних, і це займає ~224 секунди. Використовуючи переваги централізованої комп’ютерної кімнати, розробники можуть оптимізувати топологію мережі всередині центру обробки даних і використовувати такі технології, як паралелізм моделей, щоб значно скоротити цей час.

Навпаки, якщо таке ж навчання виконується в розподіленому середовищі, припускаючи, що все ще є 100 обчислювальних вузлів, розподілених по всьому світу, середня пропускна здатність мережі для кожного вузла становить лише 1 Гбіт/с. У цьому випадку для передачі тих самих 700 ГБ даних потрібно ~5600 секунд, що набагато довше, ніж у централізованій комп’ютерній кімнаті. Крім того, через затримки в мережі та перевантаженість фактично необхідний час може бути довшим.

Однак, порівняно з ситуацією в розподіленій обчислювальній потужній мережі, відносно легко оптимізувати накладні витрати на зв’язок у середовищі централізованого комп’ютерного залу. Тому що в середовищі централізованої комп’ютерної кімнати обчислювальні пристрої зазвичай під’єднані до однієї високошвидкісної мережі, а пропускна здатність і затримка мережі є відносно хорошими. У розподіленій обчислювальній потужній мережі обчислювальні вузли можуть бути розподілені по всьому світу, а умови мережі можуть бути відносно поганими, що робить проблему накладних витрат на зв’язок більш серйозною.

У процесі навчання GPT-3 OpenAI використовує модельну паралельну структуру під назвою Megatron для вирішення проблеми накладних витрат на зв’язок. Megatron розподіляє параметри моделі та обробляє їх паралельно між кількома графічними процесорами, і кожен пристрій відповідає лише за збереження та оновлення частини параметрів, таким чином зменшуючи кількість параметрів, які кожен пристрій повинен обробляти, і зменшуючи накладні витрати на зв’язок. У той же час під час навчання також використовується високошвидкісна мережа взаємозв’язку, а довжина шляху зв’язку зменшується за рахунок оптимізації топології мережі.

• *

（Дані, що використовуються для навчання моделей LLM）

3. Чому розподілена обчислювальна мережа не може виконати ці оптимізації

Це можна зробити, але в порівнянні з централізованою комп’ютерною кімнатою ефект від цих оптимізацій дуже обмежений.

1. Оптимізація топології мережі: у централізованій комп’ютерній кімнаті мережеве обладнання та компонування можна безпосередньо контролювати, тому топологію мережі можна спроектувати та оптимізувати відповідно до потреб. Однак у розподіленому середовищі обчислювальні вузли розподілені в різних географічних місцях, навіть один у Китаї та один у Сполучених Штатах, і немає можливості безпосередньо контролювати мережеве з’єднання між ними. Хоча програмне забезпечення можна використовувати для оптимізації шляху передачі даних, воно не настільки ефективно, як безпосередня оптимізація апаратної мережі. У той же час через відмінності в географічному розташуванні мережеві затримки та пропускна здатність також сильно відрізняються, що ще більше обмежує ефект оптимізації топології мережі.
2. Паралелізм моделі: Паралелізм моделі – це технологія, яка поділяє параметри моделі на кілька обчислювальних вузлів і покращує швидкість навчання завдяки паралельній обробці. Однак цей метод зазвичай потребує частої передачі даних між вузлами, тому він має високі вимоги до пропускної здатності мережі та затримки. У централізованому комп’ютерному залі завдяки високій пропускній здатності мережі та низькій затримці паралелізм моделі може бути дуже ефективним. Однак у розподіленому середовищі паралелізм моделі значно обмежений через погані умови мережі.

4. Проблеми безпеки даних і конфіденційності

Майже всі посилання, пов’язані з обробкою та передачею даних, можуть впливати на безпеку та конфіденційність даних:

1. Розподіл даних: Навчальні дані потрібно розповсюдити на кожен вузол, який бере участь у обчисленні. Дані в цьому посиланні можуть бути зловмисно використані/витік на розподілених вузлах.
2. Навчання моделі: під час процесу навчання кожен вузол використовуватиме призначені йому дані для розрахунку, а потім виведе оновлення або градієнт параметрів моделі. Під час цього процесу, якщо процес обчислення вузла буде вкрадено або результат буде проаналізовано зловмисно, дані також можуть витікати.
3. Агрегація параметрів і градієнтів: вихідні дані кожного вузла потрібно агрегувати, щоб оновити глобальну модель, і зв’язок під час процесу агрегації також може призвести до витоку інформації про навчальні дані.

**Які рішення доступні для проблем конфіденційності даних? **

• Безпечне багатостороннє обчислення: SMC успішно застосовано в деяких конкретних невеликих обчислювальних завданнях. Однак у великомасштабних розподілених навчальних завданнях, через великі обчислювальні та комунікаційні витрати, він ще не отримав широкого використання.
• Диференційна конфіденційність: застосовується в деяких завданнях зі збору й аналізу даних, як-от статистика користувачів Chrome тощо. Але у великомасштабних завданнях глибокого навчання DP матиме вплив на точність моделі. У той же час розробити відповідний механізм генерації та додавання шуму є також складним завданням.
• Інтегроване навчання: застосовується в деяких навчальних завданнях моделі периферійних пристроїв, таких як передбачення словникового запасу для клавіатур Android тощо. Але в більш масштабних розподілених навчальних завданнях FL стикається з такими проблемами, як високі комунікаційні витрати та складна координація.
• Гомоморфне шифрування: воно успішно застосоване в деяких завданнях з меншою обчислювальною складністю. Однак у великомасштабних розподілених навчальних завданнях через високі обчислювальні витрати він ще не отримав широкого використання.

Резюме

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

• Чи може ZK, на який покладають великі надії, вирішити проблему конфіденційності даних у тренуванні великих моделей? *

Теоретично ZKP можна використовувати для забезпечення конфіденційності даних у розподілених обчисленнях, дозволяючи вузлу довести, що він виконував обчислення згідно з правилами, але не потрібно розкривати фактичні вхідні та вихідні дані.

Але насправді в сценарії використання ZKP для масштабної розподіленої обчислювальної потужності, яка навчає великі моделі, виникають наступні вузькі місця:

• Накладні витрати на обчислення та зв’язок: конструювання та перевірка доказів із нульовим знанням потребує багато обчислювальних ресурсів. Крім того, ZKP мають високі комунікаційні витрати через необхідність передачі самого підтвердження. Ці накладні витрати можуть стати особливо значними у випадку навчання великих моделей. Наприклад, якщо обчислення кожної міні-серії вимагає створення доказу, це може значно збільшити загальний час і вартість навчання.
• Складність протоколу ZK: розробка та впровадження протоколу ZKP, придатного для навчання великої моделі, буде дуже складним. Цей протокол повинен мати можливість обробляти великомасштабні дані та складні обчислення, а також він повинен бути здатний обробляти можливі аномальні помилки.
• Сумісність апаратного та програмного забезпечення: використання ZKP вимагає спеціальної підтримки апаратного та програмного забезпечення, яка може бути недоступна на всіх розподілених обчислювальних пристроях.

Резюме

Щоб використовувати ZKP для масштабних розподілених обчислювальних мереж для навчання великих моделей, знадобиться кілька років досліджень і розробок, а також буде потрібно більше енергії та ресурсів від академічної спільноти в цьому напрямку.

2. Розподілена обчислювальна потужність — міркування моделі

Іншим відносно великим сценарієм розподіленої обчислювальної потужності є модельне міркування. Згідно з нашим судженням про шлях розвитку великих моделей, попит на навчання моделей поступово сповільнюватиметься, оскільки великі моделі дозріватимуть після проходження високої точки. Вимоги до логічного висновку відповідно зростатимуть експоненціально зі зрілістю великих моделей і AIGC.

Порівняно з навчальними завданнями завдання логічного висновку зазвичай мають нижчу обчислювальну складність і слабшу взаємодію з даними, і вони більше підходять для розподілених середовищ.

• *

(Висновок Power LLM з NVIDIA Triton)

1. Виклик

Затримка зв’язку:

У розподіленому середовищі комунікація між вузлами є важливою. У децентралізованій розподіленій обчислювальній потужній мережі вузли можуть бути розкидані по всьому світу, тому затримка мережі може бути проблемою, особливо для завдань міркування, які вимагають відповіді в реальному часі.

Розгортання та оновлення моделі:

Модель потрібно розгорнути на кожному вузлі. Якщо модель оновлено, кожен вузол повинен оновити свою модель, що споживає багато пропускної здатності мережі та часу.

Конфіденційність даних:

Хоча завдання логічного висновку зазвичай вимагають лише вхідних даних і моделей і не потребують повернення великої кількості проміжних даних і параметрів, вхідні дані все одно можуть містити конфіденційну інформацію, таку як особиста інформація користувачів.

Безпека моделі:

У децентралізованій мережі модель потрібно розгортати на ненадійних вузлах, що призведе до витоку моделі та призведе до проблеми прав власності на модель та зловживань. Це також може викликати проблеми безпеки та конфіденційності, якщо модель використовується для обробки конфіденційних даних, вузли можуть отримати конфіденційну інформацію, аналізуючи поведінку моделі.

КЯ:

Кожен вузол у децентралізованій розподіленій обчислювальній мережі може мати різні обчислювальні можливості та ресурси, що може ускладнити гарантування продуктивності та якості завдань логічного висновку.

2. Здійсненність

Обчислювальна складність:

На етапі навчання модель потребує багаторазових ітерацій.Під час процесу навчання необхідно розрахувати пряме поширення та зворотне поширення кожного шару, включаючи обчислення функції активації, обчислення функції втрат, обчислення градієнт і оновлення ваги. Тому обчислювальна складність навчання моделі висока.

На етапі логічного висновку для обчислення прогнозу потрібен лише один прохід вперед. Наприклад, у GPT-3 вхідний текст потрібно перетворити на вектор, а потім переслати через кожен шар моделі (зазвичай шар трансформатора), і, нарешті, отримати вихідний розподіл ймовірностей, і генерувати наступне слово відповідно до цього розподілу. У GAN модель повинна генерувати зображення з вхідного вектора шуму. Ці операції включають лише пряме поширення моделі, не потребують обчислення градієнтів або оновлення параметрів і мають низьку обчислювальну складність.

Інтерактивність даних:

Під час фази висновку модель зазвичай обробляє один вхід, а не великий пакет даних під час навчання. Результат кожного висновку залежить лише від поточного входу, а не від іншого входу чи виходу, тому немає потреби у великій кількості взаємодії даних, а комунікаційний тиск менший.

Беручи як приклад генеративну модель зображення, припускаючи, що ми використовуємо GAN для створення зображень, нам потрібно лише ввести в модель вектор шуму, а потім модель згенерує відповідне зображення. У цьому процесі кожен вхід генеруватиме лише один вихід, а між виходами немає залежності, тому немає потреби у взаємодії з даними.

Беручи GPT-3 як приклад, кожне покоління наступного слова потребує лише поточного введення тексту та стану моделі, і не потребує взаємодії з іншими входами чи виходами, тому вимога до інтерактивності даних також слабка.

Резюме

Незалежно від того, чи це велика мовна модель, чи модель генеративного зображення, обчислювальна складність і інтерактивність даних завдань міркування є відносно низькими, що більше підходить для децентралізованих розподілених обчислювальних потужних мереж, тому більшість проектів, які ми зараз бачимо в одному напрямку сили.

3. Предмети

Технічний поріг і технічна широта децентралізованої розподіленої обчислювальної мережі дуже високі, і вона також вимагає підтримки апаратних ресурсів, тому зараз ми не бачили занадто багато спроб. Візьмемо Together і Gensyn.ai як приклади:

1.Разом

• *

（Червона піжама з Together）

Together — це компанія, яка зосереджується на відкритих вихідних кодах великих моделей і прагне до децентралізованих рішень для обчислювальної потужності штучного інтелекту. Вона сподівається, що будь-хто зможе отримати доступ і використовувати ШІ будь-де. Разом щойно завершили початковий раунд на суму 20 мільйонів доларів США під керівництвом Lux Capital.

Співзасновниками Together були Кріс, Персі та Се. Початковий намір полягав у тому, що для широкомасштабного навчання моделям потрібна велика кількість кластерів графічних процесорів високого класу та дорогі витрати, і ці ресурси та можливості навчання моделей також були зосереджені в кількох великі компанії.

З моєї точки зору, більш розумним підприємницьким планом для розподілених обчислювальних потужностей є:

Крок 1. Модель з відкритим кодом

Для впровадження модельних міркувань у децентралізовану розподілену обчислювальну потужну мережу необхідною умовою є те, що вузли повинні мати можливість отримати модель за низькими витратами, тобто модель, яка використовує децентралізовану обчислювальну потужну мережу, повинна мати відкритий код (якщо модель потребує ліцензії у відповідних. Якщо використовувати нижче, це збільшить складність і вартість реалізації). Наприклад, chatgpt, як модель без відкритого коду, не підходить для виконання в децентралізованій обчислювальній мережі.

Таким чином, можна припустити, що невидимий бар’єр компанії, яка надає децентралізовану обчислювальну потужну мережу, повинен мати потужні можливості розробки та обслуговування великомасштабних моделей. Власнорозроблена потужна базова модель із відкритим вихідним кодом може певною мірою позбутися залежності від сторонньої моделі з відкритим вихідним кодом і вирішити основні проблеми децентралізованої обчислювальної мережі. У той же час це більш сприятливо для доказу того, що мережа обчислювальної потужності може ефективно здійснювати навчання та міркування великих моделей.

І Разом зробили те саме. Нещодавно випущену RedPajama на основі LLaMA спільно запустили Together, Ontocord.ai, ETH DS3Lab, Stanford CRFM і Hazy Research з метою розробки серії великих мовних моделей із повністю відкритим кодом.

Крок 2. Розподілена обчислювальна потужність заснована на модельних міркуваннях

Як згадувалося у двох вищезазначених розділах, порівняно з навчанням моделі, логічний висновок моделі має нижчу обчислювальну складність і взаємодію з даними, і він більше підходить для децентралізованого розподіленого середовища.

На основі моделі з відкритим вихідним кодом дослідницько-конструкторська група Together зробила серію оновлень моделі RedPajama-INCITE-3B, наприклад, за допомогою LoRA для недорогого тонкого налаштування, завдяки чому модель працює на ЦП (особливо MacBook). Pro з процесором M2 Pro) Працює на моделі більш гладко. У той же час, незважаючи на те, що масштаб цієї моделі невеликий, її можливості перевершують інші моделі такого ж масштабу, і вона була практично застосована в правових, соціальних та інших сценаріях.

Крок 3. Розподілена обчислювальна потужність досягнута завдяки навчанню моделі

(Подолання вузьких місць у зв’язку для схеми обчислювальної мережі Decentralized Training)

У середньостроковій та довгостроковій перспективі, незважаючи на серйозні проблеми та технічні вузькі місця, це має бути найпривабливішим для задоволення вимог обчислювальної потужності для навчання великої моделі ШІ. Разом почали продумувати, як подолати вузьке місце комунікації в децентралізованому навчанні на початку його створення. Вони також опублікували відповідну статтю про NeurIPS 2022: Подолання вузьких місць у спілкуванні для децентралізованого навчання. В основному можна підсумувати наступні напрямки:

Оптимізація планування

Під час навчання в децентралізованому середовищі важливо призначати важкі для зв’язку завдання пристроям із швидшими з’єднаннями, оскільки з’єднання між вузлами мають різні затримки та пропускну здатність. Разом будує модель для опису вартості конкретної стратегії планування та краще оптимізує стратегію планування, щоб мінімізувати витрати на зв’язок і збільшити продуктивність навчання. Команда Together також виявила, що навіть з мережею в 100 разів повільніше, пропускна здатність наскрізного навчання була лише в 1,7-2,3 рази повільнішою. Тому цікаво надолужити розрив між розподіленими мережами та централізованими кластерами за допомогою оптимізації планування.

Оптимізація стиснення зв’язку

Together пропонує стиснення зв’язку для прямих активацій і зворотних градієнтів, а також представляє алгоритм AQ-SGD, який надає суворі гарантії стохастичного сходження градієнта. AQ-SGD здатний точно налаштовувати великі базові моделі в повільних мережах (наприклад, 500 Мбіт/с), лише на 31% повільніше, ніж наскрізне навчання в централізованих мережах (наприклад, 10 Гбіт/с) без стиснення. Крім того, AQ-SGD можна поєднувати з найсучаснішими методами градієнтного стиснення, такими як QuantizedAdam, щоб досягти наскрізного прискорення на 10%.

Резюме проекту

Конфігурація команди Together є всебічною, члени мають дуже сильну академічну освіту, починаючи від розробки великих моделей, хмарних обчислень і закінчуючи оптимізацією апаратного забезпечення, підтримуються експертами галузі. І Together продемонстрував довгострокову та терплячу позицію в плануванні шляху, від розробки великих моделей з відкритим вихідним кодом до тестування неактивних обчислювальних потужностей (таких як mac) у розподіленій обчислювальній потужності мережі з використанням модельних міркувань, а потім до розподілених обчислювальних потужностей у великому макеті на модельному навчанні. — Таке відчуття скупчення та тонкого волосся :)

Однак наразі ми не бачили надто багато результатів досліджень Together на рівні стимулювання. Я вважаю, що це так само важливо, як дослідження та розробки технологій, і це ключовий фактор для забезпечення розвитку децентралізованої обчислювальної мережі.

2.Review.ai

• *

(Review.ai)

З технічного шляху Together ми можемо приблизно зрозуміти процес впровадження децентралізованої обчислювальної мережі в навчанні та міркуванні моделі, а також відповідні пріоритети досліджень і розробок.

Ще один важливий момент, який не можна ігнорувати, це дизайн рівня стимулювання/алгоритму консенсусу обчислювальної потужної мережі.Наприклад, чудова мережа повинна мати:

1. Переконайтеся, що переваги достатньо привабливі;
2. Забезпечте, щоб кожен майнер отримував переваги, на які він заслуговує, включаючи захист від шахрайства та більшу оплату за більше роботи;
3. Переконайтеся, що завдання прямо та розумно заплановані та розподілені на різних вузлах, і не буде великої кількості неактивних вузлів або переповненості деяких вузлів;
4. Алгоритм заохочення є простим та ефективним і не призведе до надмірного навантаження на систему та затримок;

……

Подивіться, як це робить Gensyn.ai:

• Стати вузлом

Перш за все, розв’язувачі в мережі обчислювальних потужностей конкурують за право обробляти завдання, подані користувачами, через ставки, і відповідно до масштабу завдання та ризику бути визнаним обманом розв’язувач повинен закласти певну суму.

• підтвердити

Розв’язувач генерує кілька контрольних точок під час оновлення параметрів (щоб забезпечити прозорість і відстежуваність роботи), а також періодично генерує докази криптографічного обґрунтування (доказ виконання роботи) щодо завдань;

Коли розв’язувач завершить роботу та згенерує частину результатів обчислень, протокол вибере перевіряльник, який також внесе певну суму (щоб гарантувати, що перевіряльник виконує перевірку чесно), і вирішить, яка частина обчислень результати необхідно перевірити відповідно до наведених вище доказів.

• Якщо розв’язувач і верифікатор розходяться

Через деревовидну структуру даних Merkle можна визначити точне місце, де результати обчислень відрізняються. Вся операція перевірки буде проходити по ланцюжку, а шахраї будуть вираховуватися із закладеної суми.

Резюме проекту

Конструкція алгоритму стимулювання та перевірки дозволяє Gensyn.ai не відтворювати всі результати всього обчислювального завдання під час процесу перевірки, а лише копіювати та перевіряти частину результатів відповідно до наданого доказу, що значно покращує ефективність перевірки. У той же час вузли повинні зберігати лише частину результатів обчислень, що також зменшує споживання місця для зберігання та обчислювальних ресурсів. Крім того, потенційні шахрайські вузли не можуть передбачити, які частини будуть обрані для перевірки, тому це також зменшує ризик шахрайства;

Цей метод перевірки відмінностей і виявлення шахраїв також може швидко знаходити помилки в процесі обчислення без порівняння результатів обчислення в цілому (починаючи з кореневого вузла дерева Merkle і переходячи вниз крок за кроком).Дуже ефективний для великомасштабних обчислювальних завдань.

Коротше кажучи, мета дизайну рівня стимулювання/перевірки Gensyn.ai: проста та ефективна. Однак наразі це обмежено теоретичним рівнем, а конкретна реалізація може зіткнутися з такими проблемами:

• В економічній моделі, як встановити відповідні параметри, щоб вона могла ефективно запобігати шахрайству, не встановлюючи занадто високий поріг для учасників.
• З точки зору технічної реалізації, як сформулювати ефективне періодичне доказ міркування шифрування також є складним питанням, яке вимагає передових знань криптографії.
• З точки зору розподілу завдань, як вибрати та призначити завдання різним розв’язувачам за допомогою обчислювальної потужної мережі, також потрібна підтримка розумного алгоритму планування. Очевидно, залишається відкритим питання з точки зору ефективності та можливості розподіляти завдання лише відповідно до механізм ставок, наприклад обчислювальна потужність. Потужні вузли можуть виконувати завдання більшого масштабу, але можуть не брати участь у ставках (це включає стимули за доступність вузлів), а вузли з низькою обчислювальною потужністю можуть виставляти найвищі ставки, але не підходять для складних великомасштабних обчислювальні завдання.

По-четверте, трохи подумати про майбутнє

Питання про те, кому потрібна децентралізована обчислювальна мережа, не перевірено. Застосування неактивної обчислювальної потужності для навчання великомасштабних моделей, яке вимагає величезних ресурсів обчислювальної потужності, очевидно, є найбільш розумним і найбільш творчим простором. Але насправді такі вузькі місця, як спілкування та конфіденційність, змушують нас переглянути:

Чи справді є надія на децентралізоване навчання великих моделей?

Якщо ви вискочите з цього консенсусу, «найрозумнішого сценарію посадки», те, чи застосовувати децентралізовану обчислювальну потужність для навчання невеликих моделей штучного інтелекту, також буде великим сценарієм. З технічної точки зору поточні обмежувальні фактори були усунені через розмір і архітектуру моделі. У той же час, з точки зору ринку, ми завжди вважали, що навчання великих моделей буде величезним тепер у майбутнє, але ринок маленьких моделей штучного інтелекту більше не привабливий?

Я так не думаю. Порівняно з великими моделями малі моделі штучного інтелекту легше розгортати та керувати ними, вони ефективніші з точки зору швидкості обробки та використання пам’яті.У великій кількості прикладних сценаріїв користувачам або компаніям не потрібні загальніші можливості міркування великої мови моделі, але зосередьтеся лише на дуже детальному прогнозі. Тому малі моделі штучного інтелекту все ще є більш життєздатним варіантом у більшості сценаріїв, і їх не слід передчасно відкидати в хвилі великих моделей fomo.

Довідка