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

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

Централізоване обучение ML-моделей має дві фундаментальні проблеми, що важко вирішити технічними патчами. Перша: дані потрібно збирати в одному місці, що створює privacy ризики та юридичні складності (GDPR, HIPAA). Друга: оператор compute інфраструктури бачить всі дані та може впливати на обучение. Федеративне обучение частково вирішує перше, не друге. Децентралізована система обучения на блокчейні вирішує обидві — ціною значної інженерної складності.

Архітектура: три шари системи

Compute Layer: верифікація вичислень

Найскладніша частина. Як смарт-контракт знає, що провайдер чесно обучив модель, а не підсунув випадкові ваги?

Оптимістичне виконання — провайдер публікує результат (градієнти або ваги), challenger період дозволяє оспорити. Для оспорювання потрібно воспроизвести вычисленням. Проблема: детерміззм. GPU-вычисленням недетерміністичні за замовчуванням з-за паралельних операцій з плавучою точкою. Потрібно форсувати детерміззм через cuDNN deterministic mode — коштує 10–30% продуктивності.

ZK-proof для ML інференсу — математично елегантно, практично дорого. EZKL дозволяє генерування ZK-proof для ONNX-моделей. Малі моделі (до 10M параметрів) — реалістично. GPT-4 — ні. Для production верифікації результатів інференсу — вже застосовується (Modulus Labs, Giza). Для верифікації обучения — поки R&D.

TEE (Trusted Execution Environment) — обучение всередину Intel SGX або AMD SEV. Remote attestation доказує що конкретний код запущен на конкретному залізі. Обмеження: SGX має обмежену захищену пам'ять (~256MB EPC), що обмежує розмір моделі. AMD SEV працює на рівні VM — більше пам'яті, менше гарантій. Marlin та деякі compute DePIN використовують TEE як pragmatic компромісс.

Proof of Useful Work — гібридний: challenge-response система, де верифікатори вибірково перевіряють частини вычисленням. Економічно ефективніше повної верифікації, статистичної природи. Використовується у Bittensor.

Data Layer: privacy-preserving обучение

Federated Learning (FL) — дані не покидають пристрої власників. Кожен учасник обучає локально, відправляє лише градієнти. Сервер агрегує (FedAvg, FedProx). Проблема: градієнти можна інвертувати для восстановлення тренувальних даних (gradient inversion attacks). Рішення — Differential Privacy.

Differential Privacy (DP) — додавання каліброваного шуму до градієнтів перед відправленням. ε-differential privacy: чим менше ε, тим краще privacy, гірше якість моделі. Практичні значення ε від 1 до 10 залежно від чутливості даних. TensorFlow Privacy та Opacus (PyTorch) — стандартні бібліотеки.

# Opacus: додавання DP до PyTorch training loop
from opacus import PrivacyEngine

privacy_engine = PrivacyEngine()
model, optimizer, train_loader = privacy_engine.make_private_with_epsilon(
    module=model,
    optimizer=optimizer,
    data_loader=train_loader,
    epochs=EPOCHS,
    target_epsilon=5.0,     # privacy budget
    target_delta=1e-5,
    max_grad_norm=1.2,      # gradient clipping
)

Secure Multi-Party Computation (MPC) для gradient aggregation — кілька серверів бачать лише зашифровані shares, результат розкривається лише при наявності кворуму. SCALE-MAMBA, MP-SPDZ — зрілі бібліотеки. Overhead: 10–100x порівняно з звичайною агрегацією. Застосовується коли privacy критична та кількість раундів обмежена.

Homomorphic Encryption (HE) — вычисленням над зашифрованими даними. Microsoft SEAL, OpenFHE. Overhead: 1000–10000x. Для обучения нейросетей — поки нереалістично у production. Для малого моделі інференсу — застосовується.

Coordination Layer: смарт-контракти та токеноміка

Блокчейн координує учасників, не виконує обучение. Функції:

Job Registry — постановка завдань обучения у черго. Клієнт публікує: датасет (IPFS/Filecoin CID), архітектура моделі, гіперпараметри, сума reward, verification scheme, deadline.

Staking та Slashing — compute провайдери стейкають токени. Верифікація провалена → slashing. Створює фінансовий стимул до честного поведінки.

Payment Escrow — клієнт депонує оплату при створенні завдання. Авто-release по виконанні та прохідженні верифікації.

Result Attestation — кілька незалежних валідаторів аттестуют результат. Threshold signature (наприклад, 5 з 9) для фіналізації.

Bittensor: reference архітектура

Bittensor — найбільш зрілий приклад децентралізованого ML маркетплейса. Варто вивчити архітектурні рішення:

Subnet модель — кожен subnet це окремий ринок для конкретного типу ML завдань (text generation, image, embeddings, тощо). Subnet owner визначає механізм верифікації. Це правильна абстракція: немає універсального способу верифікувати всі типи ML роботи.

Validator-Miner розділення — miners виконують інференс/обучение, validators оцінюють якість. Validators стейкают TAO та можуть бути покарані за неправильні оцінки. Miner ranking на основі EMA оцінок від validators.

Yuma Consensus — механізм агрегації оцінок від validators з урахуванням їх ваги (stake). Математично схожо на PageRank. Стійкий до змови малої кількості validators.

Критика Bittensor: слаба верифікація інференсу — validator бачить лише output, не процес. Імітація гарного output без реального вычисленням можлива якщо завдання добре передбачуємо. Для серйозних завдань потрібна більш строга верифікація.

Gradient Marketplace vs Federated Training

Два архітектурні паттерни для на-блокчейні координації:

Gradient Marketplace — учасники обучають локально, продають градієнти. Агрегатор купує градієнти, застосовує до глобальної моделі. Переваги: немає єдиної точки збору даних. Проблема: gradient poisoning атаки — зловмисник відправляє спеціально crafted градієнти для backdoor injection. Захист: Byzantine-robust агрегація (Krum, Trimmed Mean, FLTrust).

Federated Training з on-chain координацією — контракт координує раунди обучения, учасники відправляють агреговані градієнти (не сирі), верифікація якості через held-out validation set. Більш структурований процес, застосовний до конкретних бізнес-завдань.

Практичні обмеження та trade-offs

Детерміззм вычислень — критичне вимога для on-chain верифікації. Що порушує детерміззм:

• cuDNN non-deterministic алгоритми (особливо atomicAdd у reduction операціях)
• Multi-GPU training без explicit synchronization
• Деякі операції трансформерів при mixed precision

Рішення: torch.use_deterministic_algorithms(True) + CUBLAS_WORKSPACE_CONFIG=:4096:8. Overhead 15–30%.

Latency vs Security trade-off — чим строже верифікація (full ZK-proof vs оптимістичний), тим вище overhead. Production вибір визначається вартістю мошенництва: низька вартість → оптимістичний з challenger period, висока вартість → частична ZK верифікація або TEE.

On-chain vs Off-chain дані — сирі тренувальні дані не пишемо у блокчейн. Лише хеші (Merkle root датасету), proof участі, агреговані результати. Дані у Filecoin/Arweave з CID у контракті.

Інфраструктура розробки

Lilypad — decentralized compute network поверх Bacalhau (розподілені вичисленням над IPFS). Підтримує Docker-контейнери, має ML-специфічні примітиви. Хорошая відправна точка для proof-of-concept.

Akash Network — decentralized cloud для Kubernetes workloads. Можна деплоїти training jobs як звичайні Kubernetes pods. Немає вбудованої ML-специфічної верифікації — потрібно надстраховувати.

Gensyn — спеціалізована мережа для децентралізованого ML обучения. Власна proof система для верифікації gradient descent кроків. У testnet.

Етапи розробки

Повний цикл — 8–14 місяців. Більшість проектів у цьому просторі або жертвують децентралізацією (централізований aggregation server), або верифікацією (немає способу впіймати нечесного провайдера), або приватністю (дані все рівно збираються централізовано). Честна система без компромісів — складна R&D задача.