Розробка DeAI-проекту: від ідеї до деплою
«Децентралізований AI» — термін, який використовують для принципово різних речей. Одні мають на увазі децентралізований маркетплейс GPU (Akash, io.net), інші — верифіковані ML-інференси (Giza, EZKL, Modulus), треті — on-chain управління моделями через DAO. Ми, як команда з досвідом у Web3, знаємо: перед проектуванням архітектури потрібно чесно відповісти, що саме децентралізовано, навіщо і яку загрозу це усуває. Якщо відповіді немає — швидше за все, це маркетинг, а не продукт.
Реальні випадки, коли децентралізація в AI виправдана: стійкість запитів до моделі до цензури, аудитованість результатів (доведено, що модель X дала відповідь Y на вхід Z), або економіка — розподілені GPU дешевше AWS для певних навантажень. У нашій практиці були проекти, де економія сягала 60% при пікових навантаженнях.
Чому децентралізація в AI виправдана?
Децентралізація вирішує три ключові проблеми: single point of failure, цензура з боку централізованих провайдерів та несправедливий розподіл прибутку від даних. Наприклад, у фінансовому AI-аналізі стійкість до цензури критична — жоден регулятор не може заблокувати запит до моделі. Для геймінгу та NFT верифікований інференс гарантує чесність генерації контенту. Отримайте консультацію з архітектури вашого DeAI-проекту.
Верифікований інференс: zkML та OPML
Це технічно найскладніша частина DeAI. Завдання: довести, що обчислення нейромережі виконано коректно, без розкриття ваг моделі.
zkML (Zero-Knowledge ML)
EZKL — найбільш зрілий інструмент (див. документацію EZKL). Приймає модель у форматі ONNX, генерує Halo2 circuit. Обмеження реальні: на сьогодні це моделі до ~10M параметрів, і тільки прямі обчислення (inference), не навчання.
# Конвертація моделі ezkl gen-settings -M model.onnx ezkl calibrate-settings -M model.onnx -D input.json ezkl compile-circuit -M model.onnx -S settings.json ezkl gen-witness -D input.json -M model.compiled ezkl prove --witness witness.json --compiled-circuit model.compiled ezkl verify --proof proof.json --vk vk.key Proof generation для невеликої моделі (~1M параметрів) займає 30–120 секунд на сучасному CPU. На GPU — у 5–10 разів швидше. Це реальна цифра для планування UX: користувач не чекатиме 2 хвилини на кожен запит.
Giza будує більш високорівневий стек поверх Starknet: моделі компілюються в Cairo, докази верифікуються on-chain. Використовується для agent frameworks з верифікованими кроками.
Modulus (раніше Daniel Kang et al.) пропонує підхід через optimistic execution з fraud proof — компроміс між швидкістю та гарантіями.
OPML (Optimistic ML)
ORA Protocol реалізує optimistic підхід: результат інференсу публікується on-chain, є вікно для challenge. Challenger запускає ту ж модель, порівнює результат. При розбіжності — on-chain dispute resolution. Це дешевше zkML у 100 разів, але вимагає економічно забезпечених валідаторів.
| Характеристика | zkML (EZKL) | OPML (ORA) |
|---|---|---|
| Час доказу | 30-120 сек (CPU) | ~1-2 сек (публікація) |
| Вартість on-chain | Висока (верифікація ~200k gas) | Низька (~50k gas) |
| Безпека | Математична гарантія | Економічна (fraud proof) |
| Розмір моделі | До 10M параметрів | Обмежено лише challenge window |
Як вибрати між zkML та OPML?
Якщо для вашого проекту критична математична гарантія коректності — обирайте zkML. Якщо важливіші швидкість та низька вартість — OPML. Для гібридних сценаріїв можна комбінувати: централізований інференс з періодичним zkML-аудитом.
Децентралізовані обчислення: оркестрація GPU
Якщо проект не вимагає верифікованості кожного запиту, але потрібна децентралізована інфраструктура — працюємо через compute marketplaces.
Akash Network (Cosmos-based) — оренда GPU через on-chain SDL маніфести:
# deployment.yaml для LLM інференсу version: "2.0" services: llm: image: ollama/ollama:latest resources: gpu: units: 1 attributes: vendor: nvidia: - model: rtx3090 env: - OLLAMA_MODEL=llama3.1:8b io.net спеціалізується на батч-інференсі та навчанні, агрегує GPU з датацентрів та майнінг-ферм.
Bittensor — інший підхід: miners змагаються в якості відповідей, validators оцінюють, TAO-токен розподіляється за вагами. Для інтеграції потрібно зрозуміти subnet модель: кожен subnet — окремий ринок з конкретним завданням (text, images, фінансові дані).
Вибір залежить від пріоритетів:
| Платформа | Тип | Основне завдання | Вартість |
|---|---|---|---|
| Akash | Compute marketplace | Оренда GPU | У 2-3 рази нижче хмарних |
| io.net | Compute marketplace | Батч-інференс | На 40-60% дешевше AWS |
| Bittensor | Мережа зі стимулами | Якісний інференс | Комісія 1-5% |
Кроки з розгортання zkML-пайплайну
- Експорт моделі в ONNX.
- Калібрування налаштувань EZKL.
- Компіляція схеми.
- Генерація доказу для тестового входу.
- Верифікація on-chain.
On-chain управління моделями
Децентралізоване управління ML-моделями через DAO — нішевий, але зростаючий паттерн. Типова схема:
- Модель зберігається в IPFS/Arweave, CID публікується on-chain
- Governance голосує за апгрейд: новий CID + changelog
- Smart contract зберігає реєстр версій з їх audit статусом
- Treasury фінансує навчання через grants
struct ModelVersion { bytes32 cid; // IPFS CID в bytes32 uint256 timestamp; uint256 votesPassed; bool audited; address auditor; } mapping(uint256 => ModelVersion) public versions; uint256 public activeVersion; Архітектурні компоненти DeAI-проекту
Реалістичний DeAI-проект складається з декількох шарів:
- Data layer — звідки беруться дані для навчання/інференсу. Ocean Protocol надає маркетплейс датасетів з access control через ERC-20 datatokens. Важливо: дані можуть продаватися без розкриття — Compute-to-Data паттерн, обчислення виконуються поруч з даними.
- Compute layer — Akash/io.net для сирих GPU, або спеціалізовані мережі на кшталт Ritual (на базі Infernet).
- Inference layer — zkML для високих гарантій, OPML для економії, або просто API з децентралізованим доступом.
- Application layer — смарт-контракти, які споживають результати інференсу. Тут працюють оракули типу Chainlink Functions або Ritual's on-chain AI calls.
Практичні складнощі
Детермінізм — головна проблема. Floating-point операції в нейромережах не детерміновані на різному залізі. Для fraud-proof систем це критично. Рішення: фіксована арифметика, конкретні версії CUDA, або zkML де детермінізм вбудований в доказ.
Latency vs. decentralization trade-off: zkML доказ = хвилини, centralized inference = мілісекунди. Для більшості користувацьких застосунків це неприйнятно. Реалістична відповідь: hybrid — централізований inference з periodic zkML audit, або OPML з достатнім challenge window.
Token economics для compute marketplace: потрібно уникнути race-to-bottom на якість при мінімізації ціни. Bittensor вирішує це через scoring validators; альтернатива — reputation staking, де погані провайдери втрачають stake.
Що входить в розробку DeAI під ключ
Ми пропонуємо повний цикл: від аудиту ідеї до деплою в mainnet.
- Аналітика: визначення необхідного рівня децентралізації, вибір стеку, побудова токеноміки.
- Проектування: архітектура смарт-контрактів, інтеграція zkML/OPML, налаштування compute marketplace.
- Розробка: написання та аудит смарт-контрактів, конвеєри ML, верифікатори.
- Тестування: unit-тести, інтеграція з Tenderly, fuzzing (Echidna), бойові випробування.
- Деплой та підтримка: розгортання на L2, моніторинг, документація, навчання команди.
Зв'яжіться з нами для оцінки вашого проекту. Ми допоможемо спроектувати архітектуру та реалізувати DeAI-рішення під ключ з мінімальними ризиками.