Ми пропонуємо OPML (оптимістичне машинне навчання), яке може використовувати оптимістичні методи для обґрунтування моделі ШІ та навчання/тонкого налаштування систем блокчейну.
У порівнянні з ZKML, OPML може надавати недорогі та високоефективні послуги ML. Вимоги до участі в OPML низькі: тепер ми можемо запускати OPML із великими мовними моделями, такими як 7B-LLaMA (розмір моделі ~26 ГБ) на звичайному ПК без GPU.
OPML використовує гру перевірки (подібну до систем Truebit і Optimistic Rollup), щоб гарантувати децентралізацію та перевірений консенсус служб ML.
Запитувач спочатку запускає завдання служби ML.
Потім сервер виконує завдання служби ML і надсилає результат до ланцюжка.
Верифікатор перевірить результат. Припустимо, що є валідатор, який стверджує, що результат хибний. Він починає гру перевірки з сервером (двостороння угода) і намагається спростувати претензію, вказавши конкретний неправильний крок.
Нарешті, щодо смарт-контракту відбувається одноетапний арбітраж.
Однофазова гра перевірки
Однофазний протокол точного визначення працює подібно до делегування обчислень (RDoC), де передбачається, що дві або більше сторін (принаймні одна чесна сторона) виконують ту саму процедуру. Потім обидві сторони можуть поставити одна одній точні запитання, щоб визначити спірні кроки. Надішліть кроки судді з меншою обчислювальною потужністю (розумний контракт на блокчейні) для арбітражу.
В одноступінчатому OPML:
Ми створили віртуальну машину (VM) для виконання поза мережею та арбітражу в мережі. Ми гарантуємо еквівалентність віртуальних машин поза мережею та віртуальних машин у мережі, реалізованих на смарт-контрактах.
Щоб забезпечити ефективність виведення моделі штучного інтелекту у віртуальних машинах, ми реалізували спрощену бібліотеку DNN, розроблену спеціально для цієї мети, замість того, щоб покладатися на популярні фреймворки ML, такі як Tensorflow або PyTorch. Крім того, надається сценарій, який перетворює моделі Tensorflow і PyTorch у цю полегшену бібліотеку.
Використовуйте технологію крос-компіляції для компіляції коду міркування моделі штучного інтелекту в програмні інструкції віртуальної машини.
Образом віртуальної машини керують за допомогою дерева Merkle, і лише корінь Merkle буде завантажено в смарт-контракт у ланцюжку. (Корінь Merkel представляє стан віртуальної машини)
Двостороння угода допоможе знайти етап спору, який буде надіслано до арбітражного договору на блокчейні
Продуктивність: ми протестували базову модель ШІ (модель DNN за класифікацією MNIST) на ПК. Нам вдалося завершити висновок DNN протягом 2 секунд у віртуальній машині, а весь процес перевірки можна завершити протягом 2 хвилин у локальному тестовому середовищі Ethereum.
Гра з багатоетапною перевіркою
Обмеження однофазних протоколів точного визначення
Гра з одноетапною перевіркою має серйозний недолік: усі обчислення мають виконуватися всередині віртуальної машини (VM), що не дозволяє нам повністю використати потенціал прискорення GPU/TPU або паралельної обробки. Таким чином, це обмеження серйозно перешкоджає ефективності висновку великої моделі, що також узгоджується з обмеженням поточного протоколу RDoC.
Перехід на багатофазний протокол
Щоб усунути обмеження, накладені однофазним протоколом, і забезпечити, щоб OPML міг досягти рівнів продуктивності, порівнянних з рідними середовищами, ми пропонуємо розширення до багатофазного протоколу. Використовуючи цей підхід, нам потрібно лише виконувати обчислення у віртуальній машині на завершальному етапі, подібно до одноетапного протоколу. На інших етапах у нас є гнучкість для виконання обчислень для досягнення переходів між станами у рідному середовищі, використовуючи потужність ЦП, ГП, ТП і навіть паралельної обробки. Зменшуючи залежність від віртуальної машини, ми значно зменшуємо накладні витрати й, таким чином, значно покращуємо продуктивність виконання OPML, майже подібну до рідного середовища.
На малюнку нижче показана перевірочна гра, яка складається з двох етапів (k = 2). На етапі 1 процес нагадує одноетапну гру перевірки, де кожен перехід стану відповідає одній операції віртуальної машини, яка змінює стан віртуальної машини. У фазі 2 переходи між станами відповідають «великим інструкціям», які містять кілька операцій, які змінюють обчислювальний контекст.
Комітери та верифікатори спочатку використовуватимуть двосторонню угоду, щоб розпочати другу фазу перевірочної гри, щоб знайти спірні кроки у «великому порядку». Цей крок переведе до наступної фази, фази -1. Перший етап працює як одноетапна гра перевірки. Двостороння угода фази 1 допоможе знайти спірні кроки щодо операцій віртуальної машини. Цей крок буде надіслано в арбітражний договір на блокчейні.
Щоб забезпечити цілісність і безпеку переходу до наступного етапу, ми покладаємося на дерева Merkle. Ця операція складається з вилучення піддерев Merkle із етапів вищого рівня, таким чином гарантуючи безперебійне продовження процесу перевірки.
Багатоетапний OPML
У цій презентації ми пропонуємо двоетапний підхід OPML, який використовується в моделі LLaMA:
Процес обчислення машинного навчання (ML), особливо глибокої нейронної мережі (DNN), можна виразити у вигляді графіка обчислення, позначеного як G. Граф складається з різних обчислювальних вузлів, здатних зберігати проміжні результати обчислень.
Обґрунтування моделі DNN – це, по суті, процес обчислення на наведеному вище графіку обчислення. Весь графік можна розглядати як стан висновку (обчислювальний контекст у Фазі-2). У міру обчислення кожного вузла результат зберігається в цьому вузлі, таким чином переходячи граф обчислень до наступного стану.
Отже, ми можемо спочатку виконати гру перевірки на обчислювальному графіку (у фазі-2). На другому етапі перевірочної гри розрахунок вузла графа можна виконати в локальному середовищі за допомогою багатопотокового процесора або графічного процесора. Двостороння угода допоможе знайти спірний вузол, обчислення якого буде надіслано до наступної фази (фаза-1) двосторонньої угоди.
У першій фазі розділення навпіл ми перетворюємо обчислення окремого вузла в інструкції віртуальної машини (VM), подібно до того, що робиться в однофазному протоколі.
Варто зазначити, що ми очікуємо впровадження багатоетапних методів OPML (що містять більше двох етапів), коли обчислення окремого вузла в обчислювальному графі все ще є обчислювально складним. Це розширення ще більше покращить загальну ефективність і дієвість процесу перевірки.
Покращення продуктивності
Тут ми надаємо стисле обговорення та аналіз запропонованої нами багатоступеневої системи перевірки.
Припускаючи, що в графі обчислення DNN є n вузлів, кожен вузол повинен отримати m мікрокоманд VM, щоб завершити обчислення у VM. Припустимо, що коефіцієнт прискорення обчислень для кожного вузла, який використовує GPU або паралельні обчислення, дорівнює α. Цей коефіцієнт відображає прискорення, досягнуте GPU або паралельними обчисленнями, і може досягати значних значень, часто в десятки або навіть сотні разів швидше, ніж виконання віртуальної машини.
Виходячи з цих міркувань, ми робимо такі висновки:
Двоступінчастий OPML кращий за одноступінчастий OPML і реалізує прискорення обчислення в α разів. Використання багатоетапної перевірки дозволяє нам скористатися перевагами прискореної обчислювальної потужності, яку забезпечують графічні процесори або паралельна обробка, тим самим значно покращуючи загальну продуктивність.
Порівнюючи розмір дерев Merkle, ми знаходимо, що в двоступеневому OPML розмір дорівнює O(m+n), тоді як у одноступінчастому OPML розмір значно більший, ніж O(mn). Зменшення розміру дерева Merkle додатково підкреслює ефективність і масштабованість багатоетапного дизайну.
Підводячи підсумок, можна сказати, що структура багатоетапної перевірки забезпечує значне підвищення продуктивності, забезпечуючи ефективніші та швидші обчислення, особливо при використанні можливостей прискорення графічних процесорів або паралельної обробки. Крім того, зменшений розмір дерева Merkle підвищує ефективність і масштабованість системи, роблячи багатоступеневу OPML вибором для різних додатків.
Послідовність і детермінізм
В OPML забезпечення узгодженості результатів ML є критичним.
Під час власного виконання обчислень DNN, особливо на різних апаратних платформах, через характеристики чисел з плаваючою комою можуть виникати відмінності в результатах виконання. Наприклад, паралельні обчислення з використанням чисел з плаваючою комою, наприклад (a+b)+c і a+(b+c), часто дають різні результати через помилки округлення. Крім того, такі фактори, як мова програмування, версія компілятора та операційна система, можуть впливати на результати обчислення чисел з плаваючою комою, що призводить до подальших невідповідностей у результатах ML.
Щоб вирішити ці проблеми та гарантувати узгодженість OPML, ми застосували два ключові підходи:
Використання алгоритму з фіксованою комою, також відомого як технологія квантування. Ця техніка дозволяє представляти та виконувати обчислення, використовуючи фіксовану точність, а не числа з плаваючою комою. Роблячи це, ми пом’якшуємо вплив помилок округлення з плаваючою комою, що призводить до більш надійних і узгоджених результатів.
Ми використовуємо програмні бібліотеки з плаваючою комою, призначені для підтримки узгодженої функціональності на різних платформах. Ці бібліотеки забезпечують узгодженість між платформами та детермінованість результатів машинного навчання, незалежно від основного апаратного чи програмного забезпечення.
Поєднавши арифметику з фіксованою комою та програмні бібліотеки з плаваючою комою, ми створили міцну основу для послідовних і надійних результатів машинного навчання в рамках OPML. Така координація методів дозволяє нам подолати невід’ємні проблеми, пов’язані зі змінними з плаваючою комою та відмінностями платформ, зрештою підвищуючи цілісність і надійність обчислень OPML.
OPML проти ZKML
*: у поточній структурі OPML ми зосереджуємося на висновках моделей ML, що забезпечує ефективне та безпечне обчислення моделі. Однак слід підкреслити, що наш фреймворк також підтримує процес навчання, роблячи його загальним рішенням для різних завдань машинного навчання.
Зауважте, що OPML все ще розробляється. Якщо ви зацікавлені в тому, щоб стати частиною цієї захоплюючої програми та зробити внесок у проект OPML, зв’яжіться з нами.
Переглянути оригінал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
OPML: машинне навчання з оптимістичною зведеною системою
Джерело: github; компіляція: MarsBit
TL;DR
Ми пропонуємо OPML (оптимістичне машинне навчання), яке може використовувати оптимістичні методи для обґрунтування моделі ШІ та навчання/тонкого налаштування систем блокчейну.
У порівнянні з ZKML, OPML може надавати недорогі та високоефективні послуги ML. Вимоги до участі в OPML низькі: тепер ми можемо запускати OPML із великими мовними моделями, такими як 7B-LLaMA (розмір моделі ~26 ГБ) на звичайному ПК без GPU.
OPML використовує гру перевірки (подібну до систем Truebit і Optimistic Rollup), щоб гарантувати децентралізацію та перевірений консенсус служб ML.
Однофазова гра перевірки
Однофазний протокол точного визначення працює подібно до делегування обчислень (RDoC), де передбачається, що дві або більше сторін (принаймні одна чесна сторона) виконують ту саму процедуру. Потім обидві сторони можуть поставити одна одній точні запитання, щоб визначити спірні кроки. Надішліть кроки судді з меншою обчислювальною потужністю (розумний контракт на блокчейні) для арбітражу.
В одноступінчатому OPML:
Продуктивність: ми протестували базову модель ШІ (модель DNN за класифікацією MNIST) на ПК. Нам вдалося завершити висновок DNN протягом 2 секунд у віртуальній машині, а весь процес перевірки можна завершити протягом 2 хвилин у локальному тестовому середовищі Ethereum.
Гра з багатоетапною перевіркою
Обмеження однофазних протоколів точного визначення
Гра з одноетапною перевіркою має серйозний недолік: усі обчислення мають виконуватися всередині віртуальної машини (VM), що не дозволяє нам повністю використати потенціал прискорення GPU/TPU або паралельної обробки. Таким чином, це обмеження серйозно перешкоджає ефективності висновку великої моделі, що також узгоджується з обмеженням поточного протоколу RDoC.
Перехід на багатофазний протокол
Щоб усунути обмеження, накладені однофазним протоколом, і забезпечити, щоб OPML міг досягти рівнів продуктивності, порівнянних з рідними середовищами, ми пропонуємо розширення до багатофазного протоколу. Використовуючи цей підхід, нам потрібно лише виконувати обчислення у віртуальній машині на завершальному етапі, подібно до одноетапного протоколу. На інших етапах у нас є гнучкість для виконання обчислень для досягнення переходів між станами у рідному середовищі, використовуючи потужність ЦП, ГП, ТП і навіть паралельної обробки. Зменшуючи залежність від віртуальної машини, ми значно зменшуємо накладні витрати й, таким чином, значно покращуємо продуктивність виконання OPML, майже подібну до рідного середовища.
На малюнку нижче показана перевірочна гра, яка складається з двох етапів (k = 2). На етапі 1 процес нагадує одноетапну гру перевірки, де кожен перехід стану відповідає одній операції віртуальної машини, яка змінює стан віртуальної машини. У фазі 2 переходи між станами відповідають «великим інструкціям», які містять кілька операцій, які змінюють обчислювальний контекст.
Комітери та верифікатори спочатку використовуватимуть двосторонню угоду, щоб розпочати другу фазу перевірочної гри, щоб знайти спірні кроки у «великому порядку». Цей крок переведе до наступної фази, фази -1. Перший етап працює як одноетапна гра перевірки. Двостороння угода фази 1 допоможе знайти спірні кроки щодо операцій віртуальної машини. Цей крок буде надіслано в арбітражний договір на блокчейні.
Щоб забезпечити цілісність і безпеку переходу до наступного етапу, ми покладаємося на дерева Merkle. Ця операція складається з вилучення піддерев Merkle із етапів вищого рівня, таким чином гарантуючи безперебійне продовження процесу перевірки.
Багатоетапний OPML
У цій презентації ми пропонуємо двоетапний підхід OPML, який використовується в моделі LLaMA:
Варто зазначити, що ми очікуємо впровадження багатоетапних методів OPML (що містять більше двох етапів), коли обчислення окремого вузла в обчислювальному графі все ще є обчислювально складним. Це розширення ще більше покращить загальну ефективність і дієвість процесу перевірки.
Покращення продуктивності
Тут ми надаємо стисле обговорення та аналіз запропонованої нами багатоступеневої системи перевірки.
Припускаючи, що в графі обчислення DNN є n вузлів, кожен вузол повинен отримати m мікрокоманд VM, щоб завершити обчислення у VM. Припустимо, що коефіцієнт прискорення обчислень для кожного вузла, який використовує GPU або паралельні обчислення, дорівнює α. Цей коефіцієнт відображає прискорення, досягнуте GPU або паралельними обчисленнями, і може досягати значних значень, часто в десятки або навіть сотні разів швидше, ніж виконання віртуальної машини.
Виходячи з цих міркувань, ми робимо такі висновки:
Двоступінчастий OPML кращий за одноступінчастий OPML і реалізує прискорення обчислення в α разів. Використання багатоетапної перевірки дозволяє нам скористатися перевагами прискореної обчислювальної потужності, яку забезпечують графічні процесори або паралельна обробка, тим самим значно покращуючи загальну продуктивність.
Порівнюючи розмір дерев Merkle, ми знаходимо, що в двоступеневому OPML розмір дорівнює O(m+n), тоді як у одноступінчастому OPML розмір значно більший, ніж O(mn). Зменшення розміру дерева Merkle додатково підкреслює ефективність і масштабованість багатоетапного дизайну.
Підводячи підсумок, можна сказати, що структура багатоетапної перевірки забезпечує значне підвищення продуктивності, забезпечуючи ефективніші та швидші обчислення, особливо при використанні можливостей прискорення графічних процесорів або паралельної обробки. Крім того, зменшений розмір дерева Merkle підвищує ефективність і масштабованість системи, роблячи багатоступеневу OPML вибором для різних додатків.
Послідовність і детермінізм
В OPML забезпечення узгодженості результатів ML є критичним.
Під час власного виконання обчислень DNN, особливо на різних апаратних платформах, через характеристики чисел з плаваючою комою можуть виникати відмінності в результатах виконання. Наприклад, паралельні обчислення з використанням чисел з плаваючою комою, наприклад (a+b)+c і a+(b+c), часто дають різні результати через помилки округлення. Крім того, такі фактори, як мова програмування, версія компілятора та операційна система, можуть впливати на результати обчислення чисел з плаваючою комою, що призводить до подальших невідповідностей у результатах ML.
Щоб вирішити ці проблеми та гарантувати узгодженість OPML, ми застосували два ключові підходи:
Використання алгоритму з фіксованою комою, також відомого як технологія квантування. Ця техніка дозволяє представляти та виконувати обчислення, використовуючи фіксовану точність, а не числа з плаваючою комою. Роблячи це, ми пом’якшуємо вплив помилок округлення з плаваючою комою, що призводить до більш надійних і узгоджених результатів.
Ми використовуємо програмні бібліотеки з плаваючою комою, призначені для підтримки узгодженої функціональності на різних платформах. Ці бібліотеки забезпечують узгодженість між платформами та детермінованість результатів машинного навчання, незалежно від основного апаратного чи програмного забезпечення.
Поєднавши арифметику з фіксованою комою та програмні бібліотеки з плаваючою комою, ми створили міцну основу для послідовних і надійних результатів машинного навчання в рамках OPML. Така координація методів дозволяє нам подолати невід’ємні проблеми, пов’язані зі змінними з плаваючою комою та відмінностями платформ, зрештою підвищуючи цілісність і надійність обчислень OPML.
OPML проти ZKML
*: у поточній структурі OPML ми зосереджуємося на висновках моделей ML, що забезпечує ефективне та безпечне обчислення моделі. Однак слід підкреслити, що наш фреймворк також підтримує процес навчання, роблячи його загальним рішенням для різних завдань машинного навчання.
Зауважте, що OPML все ще розробляється. Якщо ви зацікавлені в тому, щоб стати частиною цієї захоплюючої програми та зробити внесок у проект OPML, зв’яжіться з нами.