Євген Пономарьов про Fluence: Піонерство у безхмарних обчисленнях та децентралізованій інфраструктурі

Децентралізовані обчислення вийшли на передній план, оскільки індустрії вимагають більшої гнучкості та автономії, що виходить за межі традиційних хмарних гігантів. Fluence, співзаснована Євгеном Пономарьовим, сміливо кидає виклик домінуванню AWS, Azure та Google Cloud своєю концепцією “безхмарних обчислень” — агрегування глобальної обчислювальної потужності через відкриту, децентралізовану мережу.

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

Визначення безхмарних обчислень та ринкових прогалин

У Fluence ми працюємо в сфері децентралізованих обчислень. Ми створили те, що називаємо “безхмарною” платформою — термін, який ми використовуємо для опису нашої альтернативи традиційним хмарним провайдерам, таким як AWS, Azure або Google Cloud. По суті, це децентралізована фізична інфраструктурна мережа (DePIN), яка надає розробникам і компаніям доступ до обчислювальних ресурсів без залежності від централізованих хмарних сервісів.

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

Індустрії, випадки використання та фокус на Web3

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

Люди запускають ці вузли в хмарі, на “голому металі” або навіть на персональних комп’ютерах. Те, що ми пропонуємо, — це надійна альтернатива традиційній хмарній інфраструктурі для запуску цих робочих навантажень. Зокрема, оператори вузлів є критично важливим сегментом ринку для нас у межах екосистеми Web3.

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

Відмінність Fluence у просторі DePIN

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

Для нас мета полягає в наданні обчислювальних ресурсів. Але коли ви надаєте обчислення, є також компонент зберігання — деталі, які ви упаковуєте в різні хмарні сервіси. Наш основний напрямок, однак, полягає в тому, щоб залучити обчислювальну інфраструктуру, оскільки ми бачимо величезний і зростаючий попит, особливо з підйомом ШІ, на обчислювальні ресурси.

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

Виклики у створенні децентралізованої оркестрації

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

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

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

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

Токеноміка FLT та мережеві стимули

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

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

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

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

Реакція розробників та підприємств на децентралізовані обчислення

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

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

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

Звичайно, завжди є аргумент, що це нова платформа — це стартап — тому потрібен певний рівень довіри.

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

Це все частина типового процесу онбордингу.

Структура витрат та переваги ціноутворення

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

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

Наш підхід відрізняється: ми пропонуємо бездозвільний протокол, керований ончейн децентралізованою автономною організацією (DAO). Ми не беремо жодних комісій. Економіка базується виключно на стороні провайдера з розумними — не надмірними — маржами.

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

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

Партнерства Web3 та ШІ для децентралізованої архітектури

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

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

Підтримка робочих навантажень ШІ/LLM та дорожня карта GPU

Зараз ми зосереджені лише на серверах з процесорами, які не підходять для інференсу або навчання ШІ. Однак ми плануємо незабаром додати графічні процесори (GPU).

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

По суті, для підключення LLMs і підтримки випадків використання інференсу все, що вам дійсно потрібно, це доступ до потужностей GPU і, бажано, деякі додаткові UX-шари для спрощення досвіду розробника. Це вже є в нашій дорожній карті.

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

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

Отже, вам завжди потрібні як сервери з процесорами, так і сервери з GPU, щоб повністю підтримувати такі типи застосувань.

Управління DAO та Залучення Спільноти

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

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

Ми дотримуємося моделі, де комітет з управління обирається спільнотою кожні один-два роки.

Загалом, ця модель є досить стандартною — в ній немає нічого особливо нового або незвичайного. Це типова модель DAO у Web3, де голосування здійснюється на основі кількості токенів, які люди тримають.

Децентралізація для підприємств: угоди про рівень обслуговування, сертифікація та фіат

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

По-друге, їм потрібно, щоб провайдери мали відповідні сертифікати — стандарти безпеки та відповідності, такі як SOC 2 або ISO 27001. Більшість наших провайдерів вже мають ці сертифікати, і ми наразі зосереджені на роботі переважно з постачальниками апаратного забезпечення, які відповідають цим стандартам.

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

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

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

Все буде записано в смартконтракті з чіткими правилами: наприклад, якщо провайдер не виконає 99% SLA, він буде зобов’язаний повернути частину платежу клієнту.

Що стосується фіатних платежів, тут є певні обмеження, про які ми знаємо.

Якщо підприємства хочуть платити у фіаті, ми приймаємо це. Потім ми конвертуємо фіат у стейблкоїни і фінансуємо відповідні смартконтракти.

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

Неминучість децентралізованої хмари та майбутнє Fluence

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

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

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

Їхні моделі передбачають вимоги KYC, бар’єри кредитних карток та основний обов’язок обслуговувати акціонерів. На противагу цьому, ми пропонуємо альтернативу: модель інфраструктури, керовану децентралізованою автономною організацією (DAO), без дозволів.

Завершальні думки

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

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