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

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

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

Архитектура: три слоя системы

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

Самая сложная часть. Как смарт-контракт знает, что compute провайдер честно обучил модель, а не подсунул случайные веса?

Optimistic execution — провайдер публикует результат (gradients или веса), challenger период даёт время оспорить. Для оспаривания нужно воспроизвести вычисление. Проблема: детерминизм. GPU-вычисления недетерминированы по умолчанию из-за параллельных операций с плавающей точкой. Нужно форсировать детерминизм через cuDNN deterministic mode — это стоит 10–30% производительности.

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

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

Proof of Useful Work — гибридный подход: challenge-response система, где верификаторы выборочно проверяют части вычисления. Используется в Bittensor. Экономически эффективнее полной верификации, но имеет статистический характер.

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

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

Differential Privacy (DP) — добавление калиброванного шума к gradients перед отправкой. ε-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 gradients, результат агрегации раскрывается только при наличии кворума. SCALE-MAMBA, MP-SPDZ — зрелые библиотеки. Overhead: 10–100x по сравнению с обычной агрегацией. Применимо когда privacy критична и количество раундов обучения невелико.

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

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

Блокчейн координирует участников, не выполняет само обучение. Функции:

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

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

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

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

Bittensor: reference architecture

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

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

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

Yuma Consensus — механизм агрегации оценок от validators с учётом их веса (stake). Математически похож на PageRank. Устойчив к сговору малого числа validators.

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

Gradient Marketplace vs Federated Training

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

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

# Byzantine-robust aggregation: Trimmed Mean
# Отбрасываем β% наибольших и наименьших gradients по каждой dimension
def trimmed_mean(gradients, beta=0.1):
    n = len(gradients)
    k = int(n * beta)  # количество отбрасываемых с каждой стороны
    stacked = torch.stack(gradients)
    sorted_grads, _ = torch.sort(stacked, dim=0)
    trimmed = sorted_grads[k:n-k]
    return trimmed.mean(dim=0)

Federated Training с on-chain coordination — smart contract координирует раунды обучения, участники отправляют агрегированные gradients (не сырые), верификация качества через 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 optimistic), тем выше overhead. Для production выбор определяется стоимостью потенциального мошенничества:

• Низкая стоимость задачи → optimistic с challenger period
• Высокая стоимость → partial ZK verification или TEE

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

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

Lilypad — decentralized compute network поверх Bacalhau (distributed compute over IPFS). Поддерживает Docker-контейнеры, есть примитивы для ML jobs. Хорошая отправная точка для proof-of-concept.

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

Gensyn — специализированная сеть для децентрализованного ML training. Собственный proof system для верификации gradient descent шагов. В testnet.

Этапы разработки

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