# Triad: от добровольной сети к вычислительному бизнесу

Анализ кода и план реализации · 1 октября 2026 года.

**Предлагаемый продукт: управляемая сеть для пакетных AI-задач на простаивающих GPU, с бесплатной квотой полезного AI для сообщества.** Украина — первый рынок и сообщество запуска; дальнейший рынок международный. Утверждение «крупнейший стартап» нельзя обеспечить архитектурой: нужны повторные покупки, выгодная себестоимость, удержание участников и капитал.

## Что действительно есть в коде

| Основа | Найдено | Ограничение |
|---|---|---|
| Публичный сайт | Worker, D1, интерфейс ресурсов, сообщество, проекты | Не национальный кластер |
| Вычисления браузера | Один CPU Worker, контрольная факторизация, аренда и точная проверка | До 12 участников на временную группу; фиксированные ответы кешируются; платить за этот тест нельзя |
| GPU и RAM | Локальный WebGPU-тест, выделение 16–64 МиБ | Не распределённый GPU-runtime; память принадлежит конкретному узлу |
| Хранение | Шифрование, RS(9,3), небольшие файлы, ручное восстановление | Отдельный эксперимент, ещё не промышленное object storage |
| AI на Mac | Qwen3-32B-MLX-4bit, закреплённые веса, локальный HTTP API, LoRA и исследовательские циклы | До этой доработки не соединён с сайтом; локальные отчёты не доказывают превосходство модели |
| Новая реализация | Постоянная очередь AI, нативный исходящий агент, квоты, отмена, отзыв узлов, учёт принятых результатов | Одобренные операторы, один runtime и одна версия модели; платежи и training-сеть не включены |

Исходный локальный AI-код и сохранённые веса находятся в отдельном существующем checkout `triad-mesh/ai` и `.local/ai`. Они не копируются в публичный архив сайта. Новое подключение обращается к его loopback API.

## Что можно объединять

**Объединяется очередь работы, а не физическая память.** Каждое задание должно помещаться на одном узле либо в заранее проверенной группе близких GPU. RAM — ограничение размещения, VRAM — ограничение модели, CPU/GPU — отдельные классы исполнителей. Нельзя продавать сумму телефонных TOPS как эквивалент серверных GPU.

Подходящие начальные задачи: асинхронная обработка публичного или специально обезличенного текста, генерация исследовательских ответов, оценка моделей, некоторые симуляции и независимые пакетные преобразования. Для первого оплачиваемого пилота рекомендую пакетный AI-inference по явно согласованным нечувствительным данным. Конкретный workload выбирается по контракту с первым покупателем и сравнительному запуску.

Неподходящий старт: единая VM с RAM всех телефонов, синхронное обучение крупнейшей модели через миллионы домашних подключений, чувствительные корпоративные запросы на неизвестных компьютерах, обещание непрерывной фоновой работы браузера. Специализированное распределение слоёв LLM возможно: Petals показывает такой подход, однако это отдельный протокол, требования к узлам и ограничения доверия, а не свойство любого сайта. [Petals](https://github.com/bigscience-workshop/petals), [исследование](https://arxiv.org/abs/2312.08361).

Датacenter GPU используют очень быстрые межсоединения; например, NVIDIA описывает NVLink до 900 GB/s у H100. Домашняя сеть не заменяет эту связь. Передача 1 GB по идеальному каналу 1 Gbit/s занимает минимум 8 секунд без протокольных потерь. [NVIDIA H100](https://www.nvidia.com/en-sg/data-center/h100/).

## Роли устройств и архитектура

1. **Браузер и телефоны:** участие по согласию, короткие ограниченные задачи, локальный AI подходящего размера. Браузер может быть заморожен или выгружен. На iOS нативные продолженные задачи стартуют по действию пользователя, а GPU в фоне требует поддержки устройства и entitlement. Android имеет собственные ограничения и квоты. Не закладывать телефоны в обязательную SLA. [Chrome](https://developer.chrome.com/docs/web-platform/page-lifecycle-api), [Apple](https://developer.apple.com/documentation/BackgroundTasks/performing-long-running-tasks-on-ios-and-ipados), [Android](https://developer.android.com/develop/background-work/background-tasks/persistent/how-to/long-running).
2. **Компьютеры добровольцев:** подписанный установленный агент, лимиты нагрузки, сети и времени, пауза при пользовательской работе, разрешённый набор заданий. В текущем выпуске есть ограниченный агент подключения уже работающего MLX-сервера; системная упаковка и аппаратные ограничения — следующий этап.
3. **Одобренные постоянные GPU-операторы:** обслуживают пользовательский AI и контрактные данные. Для пилота — известные операторы, доступ по отзываемым токенам, закреплённая модель. TLS защищает передачу, но оператор всё равно видит запрос; доверие и договоры важны.
4. **Обучающее ядро:** устойчивые совместимые GPU-группы с быстрыми соединениями. Массовая сеть подготавливает данные и независимые rollouts; ядро обновляет веса. Собственные новые checkpoint и независимая оценка обязательны для заявления об улучшении AI.
5. **Контур управления:** идентичность, допуск операторов, модели и их хеши, очередь, leases, heartbeat, deadline, повторная выдача, отмена, идемпотентное принятие. Передаваемое задание — данные, а не произвольный исполняемый код.

В текущем пилоте очередь хранится отдельными строками D1, а не одним JSON всей сети. Атомарная выдача исключает двойную действующую аренду; lease-token отвергает запоздалые ответы старого исполнителя. Доставка — at-least-once, окончательное принятие идемпотентно. Повторное физическое вычисление возможно и должно входить в себестоимость.

**Проверка ответа AI:** сейчас проверяются версия модели, формат, лимиты и авторизация одобренного оператора. Это не математическое доказательство правильности inference и не защита от сговора большинства. Для открытых недоверенных GPU нужны предметная стратегия проверки, независимые контрольные задания, выборочное повторное выполнение, репутация и измеренный процент брака. Не начислять деньги на основе непроверенной скорости, токенов или заявления о наличии GPU.

## Почему 40 миллионов не являются расчётом мощности

40 млн — желаемый сценарий регистраций, не подтверждённое сообщество и не число одновременно работающих украинских устройств. Один человек может иметь несколько устройств; телефон не обязательно имеет подходящие GPU, память и runtime.

Для ОДНОГО измеренного класса устройств:

```
Доступные совместимые узлы = регистрации × opt-in × совместимость × доступность
Продуктивные эталонные GPU-часы/месяц =
    доступные узлы × 730 × загрузка платными задачами ×
    относительная скорость на одинаковом workload × доля уникальной принятой работы
```

Совместимость означает успешный запуск выбранной версии модели, а не просто WebGPU=yes. Все коэффициенты до пилота — гипотезы. Разные GPU считаются отдельно; одинаковый precision, модель, размер пакета, контекст и качество фиксируются в сравнении.

Иллюстрация: при 40 млн регистраций, 20% opt-in, 1% совместимых компьютеров и 25% их одновременной доступности получается 20 000 доступных узлов. При 30% оплачиваемой загрузки работают в среднем 6 000. Это всё ещё не 6 000 H100: нужна измеренная относительная скорость. При нулевом спросе платная выручка равна нулю.

Массовая загрузка весов сама имеет цену: текущая локальная модель занимает около 17,42 GB; 10 000 первичных загрузок означают около 174,2 TB исходящего трафика до повторных скачиваний и обновлений. Нужны кеши, версионирование и лимиты, не загрузка полной модели каждому телефону.

## Экономика, бесплатный AI и масштаб бизнеса

```
Выручка = принятые оплаченные единицы работы × цена
Вклад в покрытие постоянных расходов = выручка − выплаты операторам −
    сеть/хранение − проверка/повторы − обслуживание − комиссии
Свободный бюджет AI = выделенная часть положительного вклада + спонсорский бюджет
```

Бесплатный AI — базовая квота, а не бесконечная генерация. Квота не должна зависеть от обязательной отдачи ресурсов: добровольность сохраняется. Текущий пилот: до 5 коротких запросов в сутки на вошедшего пользователя, максимум 256 выходных токенов, максимум 2 незавершённых запроса. Это защитные пределы пилота, не рассчитанный тариф. До запуска широкой аудитории отдельно измерить стоимость бесплатных пользователей и закрепить месячный бюджет.

Пример масштаба, **не прогноз и не тариф**: 1 млн оплаченных эталонных GPU-часов в месяц по $0,50 даёт $500 000 оборота в месяц. Если выплаты 70%, платформе остаётся $150 000 до всех остальных расходов. $1 млрд годового оборота по той же условной цене требует примерно 166,7 млн оплаченных GPU-часов в месяц — около 228 311 постоянно загруженных эталонных GPU при 730 часах. При комиссии 30% годовая выручка платформы будет $300 млн до издержек, если она учитывает только комиссию; признание выручки отдельно согласовать с бухгалтером. Устанавливать цену через полную себестоимость и сравнительный контракт, а не через сумму ядер.

Конкуренты уже объединяют чужие ресурсы: BOINC — добровольные вычисления, Golem — пакетные задачи, Vast.ai — GPU-маркетплейс. Поэтому само «объединение устройств» не даёт уникального преимущества. [BOINC](https://boinc.berkeley.edu/trac/wiki/ProjectMain), [Golem](https://docs.golem.network/docs/creators/python/guides/task-model), [Vast.ai](https://github.com/vast-ai/docs/blob/main/guides/pricing.mdx).

Проверяемая гипотеза преимущества Triad: простое подключение GPU + выполнение конкретного AI-workload + воспроизводимые результаты + предсказуемая цена и поддержка + полезный украинский AI для сообщества. Комьюнити снижает стоимость привлечения только если измерены установка, согласие, доступность и удержание. Национальная идентичность не доказывает спрос компаний.

Не запускать одновременно облако, мессенджер, токен, storage, суперкомпьютер и новую foundation-model как один коммерческий продукт. Имеющиеся экспериментальные функции сохраняются; основной инженерный и коммерческий фокус — одна очередь и один оплачиваемый workload. TNIX и финансовые обещания до работающего учёта и правил не нужны.

## Приёмка серьёзного пилота

| Ступень | Измерения и критерии перехода |
|---|---|
| Сквозная интеграция | Реальный сайт → D1 → исходящий агент → закреплённая модель → ответ; отмена, повтор запроса, рестарт и отзыв токена; никаких демонстрационных ответов в режиме Live |
| 10–30 независимых узлов | Минимум 3 оператора и 2 сети; 7 дней; 1 000 заранее определённых коротких запросов; ≥99% полученных ответов до 10 минут; качество отдельно; инъекции сбоев отдельно от обычного трафика |
| 100–300 одобренных узлов | 30 дней; два оплачиваемых заказчика одной категории; стоимость одинакового задания хотя бы на 20% ниже выбранной альтернативы с сопоставимыми условиями; положительный вклад после выплат, повторов и проверки |
| 1 000+ узлов | Новый диспетчер с шардированием и доставкой событий; тест отказа целого шарда; независимая проверка доверия/секретов; не увеличивать пределы текущего D1-пилота только настройкой |
| Массовая сеть | Упакованные агенты Windows/Linux/macOS, безопасные обновления и откат, реальные аппаратные лимиты; мобильный runtime отдельно; защита от Sybil, выплаты и договоры; постепенные измеренные ступени |

Это критерии проектирования, не уже достигнутые показатели. Пилотный код ограничен 300 зарегистрированными узлами и 1 000 незавершёнными заданиями. Локальные тесты не доказывают производительность облака и не являются испытанием на 300 физических GPU.

## Как масштабировать после пилота

Сохранить версию workload и модельную идентичность; назначить каждому tenant/пулу один authoritative shard. Разнести admission, каталог узлов, очередь, результаты и учёт. Перенести объёмные данные/checkpoint в object storage; в базе держать манифесты. Для больших очередей — партиционированный брокер, региональные диспетчеры, идемпотентные потребители, fencing и лимиты tenant. Быстрая связь нужна внутри training-группы, география подбирается по измерениям.

Убрать polling браузеров через доставку событий; не держать 40 млн постоянных соединений в одном процессе или одну глобальную очередь. Один D1 имеет ограничения размера и последовательного исполнения запросов; нормализация таблиц полезна, но не снимает эти пределы. Не обещать production SLA до нагрузки в реальной инфраструктуре. [D1 limits](https://developers.cloudflare.com/d1/platform/limits/).

До обучения собственного большого AI: выбрать одну полезную способность, закрепить лицензию базы и данных, отделить training/validation/final, заранее зафиксировать метрики, хранить исходную модель и откат. Оценивать смысловую правильность отдельно от формата и training loss. Масштабировать обучение только после улучшения на новых независимых задачах. Чаты сообщества и личные запросы не превращаются в датасет автоматически.

## Следующие действия команды

Подключить известных GPU-операторов, провести стенд отказов на реальных машинах, договориться с первым покупателем о workload и сроках, измерить себестоимость. Назначить ответственных за runtime/агент, диспетчер, ML-оценку, продукт и коммерческий пилот. Собрать недельные метрики: успешные задания, задержка очереди, p50/p95 выполнения, повторы, стоимость уникального результата, ежедневные доступные GPU, удержание операторов и пользователей, бесплатный бюджет. Решение о следующей ступени принять по этим данным.