# Triad: что реально означают 40 миллионов подключённых телефонов

Дата проверки источников и расчёта: **24 сентября 2026 года**.

**Потенциал — большой рынок независимых пакетных заданий. Количество установок само по себе не определяет вычислительную мощность или выручку.** Ниже 40 млн — заданное условие модели, а не оценка числа доступных телефонов в Украине и не прогноз привлечения пользователей. Все доли, мощность в ваттах и пример экономики — явно заданные допущения, которые необходимо заменить измерениями пилота.

## 1. От установок к реально продаваемой работе

Обозначения:

- `N` — зарегистрированные устройства: 40 000 000.
- `o` — доля владельцев, отдельно согласившихся предоставлять вычисления.
- `a` — средняя за сутки доля согласившихся устройств, одновременно пригодных к работе: приложение исполняется, ресурс разрешён, сеть доступна, хватает памяти, соблюдены ограничения заряда и температуры.
- `u` — доля доступной мощности, действительно занятой заданиями заказчиков. Наличие покупателей не предполагается автоматически.
- `η` — эффективность: доля затраченного времени, приходящаяся на уникальную принятую работу после обычных сбоев, повторов и проверок; скорость самого устройства учитывается отдельно.
- `ΔP` — дополнительная мощность активного устройства относительно сопоставимого состояния без Triad, измеренная на питании с учётом зарядных потерь.

```text
Доступно одновременно A = N × o × a
Реально работают W = A × u
Затрачено устройства-часов за сутки H = 24 × W
Условно полезное время Hпол = H × η
Дополнительная мощность, кВт = W × ΔP / 1000
Дополнительная энергия, кВт·ч/сутки = H × ΔP / 1000
```

| Входные допущения | Низкое участие | Среднее участие | Высокое участие |
|---|---:|---:|---:|
| Доля согласившихся `o` | 10% | 25% | 50% |
| Пригодны одновременно среди согласившихся `a` | 2% | 5% | 10% |
| Загрузка заказами `u` | 10% | 30% | 60% |
| Эффективность `η` | 50% | 65% | 75% |
| Дополнительная мощность работающего устройства `ΔP` | 2 Вт | 3 Вт | 4 Вт |

| Результат арифметики | Низкое участие | Среднее участие | Высокое участие |
|---|---:|---:|---:|
| Согласились предоставлять ресурсы | 4 000 000 | 10 000 000 | 20 000 000 |
| Доступны одновременно | 80 000 | 500 000 | 2 000 000 |
| Реально исполняют задания одновременно | 8 000 | 150 000 | 1 200 000 |
| Затраченные устройства-часы/сутки | 192 000 | 3 600 000 | 28 800 000 |
| Условно полезные устройства-часы/сутки | 96 000 | 2 340 000 | 21 600 000 |
| Дополнительная средняя мощность | 16 кВт | 450 кВт | 4 800 кВт |
| Дополнительная энергия/сутки | 384 кВт·ч | 10 800 кВт·ч | 115 200 кВт·ч |

Это **сценарии чувствительности, не прогнозы и не гарантия круглосуточной доступности**. Последние две строки не включают серверы, сеть, дополнительное потребление ожидающих устройств и возможные другие издержки. Если `u = 0`, продаваемая работа и выручка равны нулю при любом числе установок; фоновый расход при этом может оставаться.

Устройства-часы разных телефонов нельзя приравнивать к одинаковой мощности. Для конкретной услуги нужна разбивка по измеренным классам `i`:

```text
Q, принятых результатов/сутки = Σ(H_i × η_i × q_i)
q_i = измеренные результаты/час на конкретном классе устройства и версии задачи
```

`Hпол` — только учётный показатель времени; он не является FLOPS, GPU-часами или эквивалентом H100. Показатели `q_i` измерять на длительном прогоне, с указанной моделью, точностью, размером входа, температурой и лимитом ресурсов.

**Сценарий 2/3 злоумышленников считается отдельно.** Таблица не предполагает такую долю вредоносной работы. Если ровно 2/3 назначений достаются участникам, которые возвращают мусор или ничего, то при прочих равных полезный результат упадёт примерно втрое: условно полезное время станет 32 000 / 780 000 / 7 200 000 часов соответственно. Это арифметическая чувствительность при заданном распределении назначений, не гарантия против Sybil-атак и адаптивного противника. Доля аккаунтов не равна доле назначений или мощности. Полная блокировка маршрутов или координатора может остановить работу. Проверка факторизации отвергает ложные ответы, но не гарантирует доставку, честное большинство или проверку произвольной AI-задачи.

## 2. Почему телефон не равен серверной видеокарте

Пиковые TOPS разных производителей, точности и наборов операций нельзя просто складывать и переводить в H100. Приложению доступны определённые ускорители и операции, часть графа может перейти на CPU; Google предупреждает, что смешанное GPU/CPU исполнение иногда оказывается медленнее исполнения целиком на CPU. [LiteRT GPU delegates](https://developers.google.com/edge/litert/performance/gpu)

Длительная скорость ограничена нагревом: Android прямо указывает, что высокий уровень производительности сохраняется лишь ограниченное время до thermal throttling. Поэтому короткий стартовый тест не является обещанием производительности на час. [Android Thermal API](https://developer.android.com/games/optimize/adpf/thermal)

RAM телефонов физически раздельна. Общая сумма памяти не создаёт единый быстрый пул: конкретный исполнитель должен вместить модель, рабочие тензоры и входные данные с запасом для ОС. Передача промежуточных активаций и синхронизация через мобильный интернет могут уничтожить выгоду объединения. Архитектурный вывод: сначала независимые задания, помещающиеся на одном устройстве; обучение большой общей LLM не выбирать первым продуктом.

Core ML позволяет выбирать CPU/GPU/Neural Engine, но конкретный путь зависит от модели и платформы; для фонового использования Apple отдельно предлагает учитывать режим CPU-only. [Apple MLComputeUnits](https://developer.apple.com/documentation/coreml/mlcomputeunits)

## 3. Фон, батарея и реальное участие

На iOS система определяет время запуска `BGProcessingTask`; продолжение работы после ухода в фон ограничено и требует обработки завершения. Это не API постоянной аренды телефона. [Apple: Choosing Background Strategies](https://developer.apple.com/documentation/BackgroundTasks/choosing-background-strategies-for-your-app)

Android Doze ограничивает CPU/сеть и откладывает задания; лимиты зависят от состояния приложения и версии ОС. Даже обычные задания активного приложения имеют ограничения в новых версиях, поэтому рассчитывать на бесконечный `WorkManager` нельзя. [Doze and App Standby](https://developer.android.com/training/monitoring-device-state/doze-standby), [Power management resource limits](https://developer.android.com/topic/performance/power/power-details)

Браузер может замораживать и выгружать страницы. Для текущего браузерного пилота учитывать **только добровольное участие с открытой вкладкой**, с кнопкой остановки; фон и заблокированный экран проверять как сценарий потери исполнителя. [Chrome Page Lifecycle](https://developer.chrome.com/docs/web-platform/page-lifecycle-api)

Рекомендуемая политика продукта: отдельное согласие; ограничение CPU/памяти/трафика; пауза при взаимодействии владельца и ухудшении теплового состояния; в нативном клиенте — режим «на зарядке и в разрешённой сети». Не требовать отключать системную защиту батареи. У браузера нет универсального доступа к состоянию зарядки и температуре: показывать проверяемые условия, не имитировать такие датчики.

## 4. Как распределять и что продавать

Сделать каталог разрешённых версионируемых вычислительных модулей. Задание содержит тип, версию, вход, лимиты и дедлайн, а не произвольный исполняемый код. Очередь назначает короткую аренду одному подходящему исполнителю; при пропаже устройства аренда истекает, задача возвращается в очередь. Уникальный `jobId` и идемпотентное принятие исключают двойную оплату. Большие задачи разбиваются на независимые части; классы устройств отбираются по реальному бенчмарку и памяти.

Первая продаваемая услуга — одна пакетная операция с небольшими входами, допускающая повторы и задержку: например, извлечение признаков из публичных изображений или классификация открытых текстов фиксированной небольшой моделью. Для CPU/WASM подойдут независимые преобразования и вычислительные пакеты с проверяемым результатом. Это кандидаты на эксперименты, не доказанный спрос. Малый inference через нативный Core ML/LiteRT запускать только на поддержанных и измеренных классах устройств. Десктопные GPU выделить в отдельный пул со своими ценой и SLA.

Клиент покупает **1 000 принятых результатов определённого качества за согласованный срок**, а не неопределённые «телефонные мощности». Сначала очередь batch с честным дедлайном. Жёсткий интерактивный SLA требует резервной мощности и отдельной цены.

Проверка результата должна соответствовать задаче. Факторизация проверяется дешёвым умножением. Для произвольной модели inference такого универсального дешёвого проверяющего в текущем прототипе нет. Простое большинство повторных запусков не защищает при 2/3 сговорившихся исполнителей. Пока нет соответствующего проверяющего/доказательства, критические вычисления выполнять на доверенном пуле, а выборочные контрольные задания считать обнаружением части нарушений, не абсолютной гарантией.

## 5. Цена и выплаты

Конкурентный ориентир на дату проверки: официальный Salad указывает **$0.005/vCPU-час плюс $0.001/ГБ RAM-час** для CPU-only и отдельные GPU-классы **от $0.015/GPU-час** на минимальном приоритете. Это цены конкретного предложения и доступности, не стоимость сопоставимого телефонного часа. Проверять их на той же задаче по цене принятого результата. [Salad Pricing](https://salad.com/pricing/)

Golem разделяет назначаемую провайдером оплату запуска, времени среды и выделенных CPU-потоков. Числа в документации — пример конфигурации, не рыночная котировка, поэтому курс GLM и «среднюю цену сети» здесь не подставляем. [Golem provider configuration](https://docs.golem.network/docs/providers/configuration/general)

```text
Себестоимость результата =
  выплаты всем необходимым исполнителям и проверяющим
  + серверы/передача/хранение
  + стоимость повторов, брака и резервной мощности
  + переменные расходы поддержки и расчётов

Цена результата при целевой валовой марже m = Себестоимость / (1 − m)
Выплата владельцу = заранее объявленный тариф × уникальная принятая работа
```

Платить за проверенный результат, а не за присланные исполнителем секунды CPU: их можно подделать. В таблице устройства-часы нужны для планирования себестоимости, а не как доверенное основание выплаты. Формулы не учитывают налоги и постоянные затраты бизнеса; остаток после переменных затрат не равен чистой прибыли.

**Только иллюстрация, не предлагаемый тариф:** 1 000 полезных результатов требуют по 20 секунд на выбранном классе устройств; коэффициент дополнительных исполнений 1.2. Всего 6.667 устройства-часа. При условной выплате, эквивалентной $0.03 за час такого полезного труда, бюджет исполнителей — $0.20. Если передача стоит $0.08, проверка $0.12, прочие переменные расходы $0.10, себестоимость пакета — $0.50. Цена $1 даёт $0.50 вклада в покрытие постоянных затрат. Эти входные числа придуманы для демонстрации формулы; реальная конкурентоспособность не установлена. При 3 Вт дополнительной мощности телефоны затратят 0.02 кВт·ч на пакет; при условных $0.20/кВт·ч — $0.004 электричества. Износ, неудобство и серверная энергия в это число не входят. При реальных двух оплаченных часах в день ставка $0.03/час дала бы владельцу лишь $1.80 за 30 дней: массовое обещание существенного заработка пока ничем не подтверждено.

## 6. Безопасность данных и следующий эксперимент

WASM с ограниченными импортами и бюджетом ресурсов помогает изолировать задание от телефона; Worker отделяет вычисление от интерфейса, но сам по себе не является полной границей безопасности. **Это не скрывает данные заказчика от владельца устройства**, где они обрабатываются. TLS защищает передачу, а не память чужого компьютера. Разделение данных на части само по себе тоже не обеспечивает конфиденциальность. Пилот выполнять на открытых/синтетических данных; секретные данные и закрытые модели направлять только в отдельно спроектированную доверенную среду. Не обещать защиту от враждебного хозяина телефона без подходящей доказанной технологии и проверки всей цепочки доверия. [Модель безопасности WebAssembly](https://webassembly.org/docs/security/)

До масштабирования провести пилот на 30–100 устройствах нескольких классов и одной реальной клиентской задаче. Измерять 20–30 минут устойчивой скорости, память, завершение после сворачивания, расход относительно baseline, трафик, долю повторов, качество, стоимость проверки и фактически оплаченную клиентом цену. Затем расширить число участников и длительность. Критерий решения — повторный заказ и положительная маржа при приемлемой нагрузке на владельца. Результаты арифметики воспроизводятся скриптом `capacity-model.mjs`; текущий factoring kernel демонстрирует распределение и проверку работы, но не является коммерческим товаром.