# Triad: распределённая сеть для улучшения собственной AI-модели

Дата исследования: 25 сентября 2026 года.

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

Это проектная схема и воспроизводимый сценарный расчёт. Новая модель, обучающая сеть и измеренная производительность в этой работе не созданы. Сценарий 40 млн — выбранный владельцем масштаб устройств, не оценка населения, достижимой аудитории или рекламный прогноз.

## 1. Технический выбор

Предлагаю три взаимосвязанные части:

1. **Triad Compute:** установка на устройства, измерение возможностей, выдача заданий, проверка результата, учёт полезной работы и ограничения владельца.
2. **Triad Research:** наборы обучающих задач, среды проверки, распределённая генерация решений, обновление весов, оценка и публикация моделей.
3. **Triad AI:** пользовательское приложение; быстрые модели для повседневных задач и более дорогой режим сложных задач, с понятной бесплатной квотой.

Вычисления, которые даёт массовая сеть, направляются прежде всего на масштабирование поиска решений в обучении. Это часть обучения, даже когда отдельное устройство генерирует ответ, а градиент рассчитывается на другом узле. Изменённые веса и отчёт обучения являются обязательным результатом; маршрутизация к чужому API этого не заменяет.

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

## 2. Какие модели использовать

Фиксируем роли, чтобы небольшой модели не приписывать возможности флагмана, а крупную не требовать от каждого смартфона.

| Роль | Предложенный выбор | Основание и следующее действие |
|---|---|---|
| Первый проверяемый цикл обучения | Qwen3-4B-Instruct-2507, затем модель класса 8B | Для 4B есть пример LoRA RL в prime-rl. Проверить всю цепочку, отключения узлов, контрольный запуск и улучшение от новых весов. |
| Рабочая модель для массовых компьютеров | Qwen3.6-35B-A3B как основной кандидат; Qwen3-30B-A3B как контроль с опубликованным RL-примером | У Qwen3.6 35B общих и 3B активных параметров, Apache 2.0. Выбор обусловлен размером и доступностью, не заявлением, что это лучший AI мира. Поддержку обучения конкретной версии проверить отдельно от поддержки запуска. |
| Крупная модель Triad | DeepSeek-V4.1-Flash — первый кандидат; GLM-5.3 — конкурент в сравнительном испытании | У DeepSeek открытые веса MIT и мультимодальность. Для GLM-5.3 prime-rl описывает крупномасштабный training-путь; проверить условия собственной лицензии и практический выигрыш. Выбор победителя — после одинаковых тестов и проверки стоимости улучшения. |
| Ещё один сильный кандидат для сравнения | Kimi K3 | 2.8T общих параметров и отдельная лицензия. Гораздо более тяжёлая инфраструктура; не назначать его основной моделью до проверки выигрыша относительно затрат. |
| Малые устройства | Небольшая локальная модель, отобранная по реальному профилю телефона | Локальный AI, ограниченные задания подготовки и оценки; никакого предположения, что смартфон исполняет полную крупную policy-модель. |

Первичные источники: [prime-rl и примеры](https://github.com/PrimeIntellect-ai/prime-rl), [Qwen3.6](https://huggingface.co/Qwen/Qwen3.6-35B-A3B), [DeepSeek-V4.1-Flash](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash), [GLM-5.3](https://huggingface.co/zai-org/GLM-5.3), [Kimi K3](https://huggingface.co/moonshotai/Kimi-K3).

Указанные веса проверены по карточкам разработчиков. Локальных сравнительных запусков этих моделей здесь не было. Для исполнения закрепить revision весов, токенизатора, кода, лицензии, численной точности и контекста. Рекламные таблицы разных разработчиков не являются сопоставимым независимым рейтингом.

## 3. Как собственно улучшать модель

### Обучающие среды

Сформировать версионированную библиотеку задач: программирование с исполняемыми тестами, математика с проверяемым ответом, выполнение рабочих процессов в изолированных приложениях, поиск по документам с проверяемыми источниками. Затем расширять на украинский язык, визуальное понимание и другие области. Сложность подбирать по текущим слабым местам модели, чтобы собирать информативные попытки.

Источники: разрешённые для такого использования наборы, задачи партнёров, собственные симуляторы и синтетические вариации с независимым проверяющим механизмом. Отделять данные для обучения от закрытых тестов по семействам задач и времени. Частные диалоги не становятся обучающими данными автоматически.

### Цикл версии модели

1. Зафиксировать policy и выдавать исполнителям задания с идентификаторами модели, адаптера, среды, sampling-настроек и срока действия.
2. Генерировать группы попыток решения. Для первой конфигурации исследовать группы по 8 попыток на задачу; это параметр эксперимента, не стандарт качества.
3. Проверять происхождение/целостность и отдельно оценивать результат исполнения. **Неправильное решение может быть допустимой обучающей попыткой с нулевой наградой.** Отклонять подделки, дубликаты, неподдержанную версию, повреждённые или слишком устаревшие результаты.
4. Начать с поддержанного GRPO-подобного метода в prime-rl; сравнить его текущие асинхронные алгоритмы на контрольных запусках. Измерять расхождение rollout/trainer, возраст policy и эффективный размер выборки; ограничивать устаревание.
5. Сначала обновлять адаптеры поверх фиксированной основы. Это снижает объём распространяемых обновлений. Если качество выходит на плато, проверять частичное/полное обновление весов на подходящем ядре. Не переносить результат небольшого LoRA-эксперимента автоматически на полный флагман.
6. Контрольные тесты, сравнение с базовой моделью, проверка потери прежних навыков, выпуск и возможность отката.
7. Передавать проверенные новые способности в более компактные модели, которые увеличивают охват бесплатного продукта.

Для существенного расширения знаний предусмотреть отдельную программу продолженного предобучения на качественном корпусе и отдельных группах GPU. Её бюджет считать отдельно от RL и сравнивать прирост с альтернативами.

### Как малые модели помогают большой

Малые модели могут искать варианты решений, генерировать тесты и кандидатов данных. Проверенные результаты идут в curated SFT/distillation или другие явно выбранные методы. Их ответы **не считать on-policy rollouts большой модели**. Для RL конкретного флагмана нужны исполнители, способные запускать именно эту policy и её разрешённую версию. Это отдельный реестр мощности.

### Исследовательская база

INTELLECT-2 демонстрирует глобально распределённое RL модели 32B с раздельными исполнителями, проверкой и распространением весов. Он подтверждает подход, а не универсальное мировое лидерство. В работе также описаны затраты обмена: передача 62 GB весов в среднем занимала 14 минут. [Полный отчёт](https://arxiv.org/html/2505.07291v1).

INTELLECT-3 описывает RL для MoE 106B/12B active и открытый набор компонентов обучения. [Отчёт](https://arxiv.org/abs/2512.16144). Streaming DiLoCo — кандидат для дальнейших экспериментов между устойчивыми группами обучающих узлов, не готовый способ сложить произвольную память телефонов. [Исследование](https://arxiv.org/abs/2501.18512).

## 4. Роли устройств

| Класс | Основная роль | Условие включения |
|---|---|---|
| Телефоны | Локальный AI; небольшие задания подготовки, оценки и обработки открытых данных; добровольная обратная связь | Проверенный runtime, память, температура, питание, разрешение владельца и поддержка ОС. В основной расчёт больших GPU-rollouts их вклад заранее не включён. |
| CPU-компьютеры | Изолированное выполнение тестов, подготовка данных, дедупликация, оркестрация сред | Измеренная скорость конкретного задания; бюджет RAM/диска/сети |
| GPU-компьютеры | Генерация обучающих попыток для помещающейся модели; отдельные эксперименты с адаптерами | Прохождение теста конкретной модели, контекста, precision и проверки результата |
| Рабочие станции и GPU-серверы | Rollouts крупных моделей, обновление весов, оценка | Согласованная топология, память, связь и длительная доступность |
| Надёжные серверы/партнёрские площадки | Проверка, registry моделей, очередь, резервирование, приватное обслуживание | Управляемая конфигурация и ограничения доступа |

GPU в prime-rl сейчас — NVIDIA; поддержка других платформ в агенте Triad потребует отдельного адаптера и проверки численной совместимости. Apple разрешает определённые продолженные фоновые задачи, включая GPU при поддержке устройства и entitlement; планировщик может отложить или прервать работу. Это не основание обещать постоянную ночную работу любого iPhone. [Документация Apple](https://developer.apple.com/documentation/BackgroundTasks/performing-long-running-tasks-on-ios-and-ipados).

## 5. Сколько устройств: воспроизводимый сценарий

Считать отдельно регистрацию, пригодный узел и фактическую принятую работу. Единица этого сценария — попытка решения заданной policy-моделью с 4096 выходными токенами. Это не универсальная единица интеллекта и не эквивалент H100.

**Допущения, которые предстоит измерить:**

- 2% зарегистрированных устройств становятся удержанными, совместимыми исполнителями выбранной малой/средней модели; один такой исполнитель на регистрацию.
- 8 запланированных часов в сутки, 75% доступности внутри этого окна.
- 20 выходных токенов/сек во время генерации. Это не замер RTX, Mac или телефона.
- 60% полезного времени после prefill, инструментов, загрузок, ожидания и накладных расходов; не вычитать эти потери повторно при end-to-end измерении.
- 50% ресурса на исследовательские rollouts, 30% на бесплатное обслуживание, 20% на коммерческие задания. Разделение — сценарий, не подтверждённая бизнес-модель.
- 80% результатов допустимы по версии, целостности, уникальности и правилам формирования групп. Это не доля правильных ответов.

`Допустимые попытки/узел/сутки = 8 × 3600 × 0.75 × 20 × 0.60 × 0.50 × 0.80 / 4096 = 25.3125`.

| Регистраций устройств | Пригодных исполнителей, при 2% | Потенциальная поставка попыток/сутки |
|---:|---:|---:|
| 100 000 | 2 000 | 50 625 |
| 1 000 000 | 20 000 | 506 250 |
| 10 000 000 | 200 000 | 5 062 500 |
| 40 000 000 | 800 000 | 20 250 000 |

Это условная способность поставлять обучающие попытки для одной согласованной модели. Реальная сквозная скорость — минимум из поставки, проверяющих серверов, передачи и потребления обучающим ядром. Последние три скорости пока не измерены; в расчётном JSON итог сети оставлен `null`. При смене модели вся калибровка пересчитывается. Нельзя отнести эту таблицу к полному DeepSeek-V4.1.

При 40 млн и пригодности 0.5% получается 200 тыс. исполнителей и 5.0625 млн попыток/сутки; при 5% — 2 млн и 50.625 млн. Эти доли — анализ чувствительности, а не статистика устройств Украины.

### Цели набора на цикл 30 дней

| Выбранный исследовательский объём | Нужно пригодных исполнителей | Регистраций с нуля при 2% |
|---:|---:|---:|
| 1 млн попыток | 1 317 | 65 850 |
| 10 млн попыток | 13 169 | 658 450 |
| 100 млн попыток | 131 688 | 6 584 400 |

Это цели объёма экспериментов, не доказанные требования к победе над мировыми моделями. Полная сеть предполагается набранной к началу периода. Если обучающее ядро не потребляет этот поток, набирать дополнительные исполнители только для этой очереди экономически бессмысленно: масштабировать соответствующее ограничение или направлять ресурс на другие задания.

**Фактическая нехватка:** `max(0, нужные пригодные узлы − подтверждённые пригодные узлы текущей сети)`. Текущий мировой реестр Triad и training-бенчмарк отсутствуют; фактическая величина пока неизвестна.

## 6. Сколько мощных GPU нужно ядру

Для бюджета полного обновления всех весов можно начать с грубой бухгалтерии mixed-precision Adam: 2 байта весов + 2 байта градиента + 4 байта master weights + 8 байт двух моментов = 16 байт на параметр. Это не фактический расход выбранного фреймворка; иной optimizer, precision, offload или LoRA меняют его.

Если условно считать доступными 64 из 80 GB каждой GPU для этих состояний:

| Общих параметров | Состояния обучения, decimal GB | Нижняя граница по памяти, GPU 80 GB |
|---:|---:|---:|
| 8B | 128 | 2 |
| 35B | 560 | 9 |
| 106B | 1696 | 27 |
| Условная архитектура 700B | 11 200 | 175 |

Это только memory floor. Активные параметры MoE не заменяют общие в этой оценке. Активации, reference policy, rollout-копии, буферы связи, checkpoint и желаемая скорость требуют отдельного расчёта. 700B — иллюстративный класс, а не точный размер нового DeepSeek.

Для первого пилота предлагаю запросить **одну группу из 8 GPU класса 80 GB** для модели 4–8B, включая эксперименты и проверку. Это инженерная комплектация для испытаний, не обещание конкретного throughput. Большой флагман — самостоятельный кластерный проект; утверждать его конфигурацию после memory map и измерения шага обучения. Число мощных GPU определяется и тем, чтобы ядро успевало использовать поток участников.

Для 35B-модели идеальная нижняя оценка одних 4-bit весов — 17.5 GB, BF16 — 70 GB. Metadata, vision, cache и runtime добавляются. Поэтому «24 GB видеокарта подходит» устанавливать только для заданного контекста и проверенного режима. Поддержка inference не означает, что там помещается training.

## 7. Протокол и масштабирование сети

**Агент:** нативный процесс с ограничением мощности, памяти, трафика, расписанием, остановкой и подписанными обновлениями. Первый backend — NVIDIA/Linux; Windows и Apple Silicon отдельными проверяемыми этапами. Браузер — знакомство и ограниченные задания, а не обещание постоянного GPU-сервера.

**Control plane:** API авторизации, региональные реестры, очередь с lease/heartbeat, диспетчер по модели/памяти/контексту, учёт принятых результатов. Разделить длительный lease задачи и частый heartbeat. Потерянное задание переотправляется с идемпотентным зачётом. Не хранить мир в одной JSON-записи комнаты.

**Data plane:** объекты с hash, региональные кэши, подписанные manifest, возобновляемая загрузка и ограничения трафика. Не пересылать веса через очередь. Модель и адаптер кэшируются отдельно. Проверяемая P2P-раздача может уменьшить нагрузку на исходный сервер, но не убирает трафик получателей.

**Версии:** model/tokenizer/runtime/environment hash, policy_version, precision, context, timestamp и подпись результата. Для RL ограничивать возраст policy и численное расхождение; квантованные и BF16 исполнители не смешиваются без проверенной коррекции. [Исследование mismatch и importance sampling](https://arxiv.org/abs/2605.13907).

**Доверие:** регистрация устройства не доказывает реальную мощность. Проверка результатов, случайные контрольные задания, воспроизводимые серверные проверки, лимиты новых узлов, выборочная повторная обработка и мониторинг сговора. TOPLOC — кандидат для поддержанных режимов inference, не универсальное доказательство любых градиентов. [Первичный источник](https://www.primeintellect.ai/blog/toploc).

**Исполнение:** только разрешённые и ограниченные среды, без доступа к личным файлам/ключам владельца и произвольного сетевого выхода. Непроверенный код исполняется в подходящей изоляции. Приватные пользовательские запросы идут локально или на доверенные узлы; шифрование канала не скрывает открытый текст от устройства, которое его обрабатывает.

### Нагрузка, которую нельзя пропустить

- 800 тыс. узлов × 17.5 GB первичных весов = 14 PB суммарной доставки получателям (decimal units).
- Условное обновление адаптера 0.1 GB каждый час: 800 тыс. × 0.1 × 24 = 1.92 PB/сутки. Это пример размера, реальный adapter payload нужно измерять.
- Частота обновлений согласуется с допустимым возрастом policy; нельзя снижать трафик, незаметно принимая бесконечно старые rollouts.
- 20.25 млн попыток по условным 32 KB = 648 GB/сутки сырых результатов; логи, тесты, изображения и реплики добавляются.
- 800 тыс. узлов с heartbeat раз в минуту дают примерно 13 333 запросов/сек в среднем; пики и повторные подключения требуют запаса. При активных 40 млн это уже примерно 666 667/сек. Не опрашивать офлайн-устройства как активные.

Эти расчёты — аргумент за региональные сервисы, адаптеры, фиксированные окна и контроль очередей.

## 8. Бесплатный продукт и экономика

Продуктовая гипотеза: один удобный AI для учёбы, работы с документами, программирования и повседневных вопросов. Самая сильная доступная версия — в режиме сложных задач с квотой; быстрые ответы маршрутизируются на компактную версию при сохранении понятного качества.

Каждому — базовый бесплатный доступ в пределах устойчивой квоты. За принятую полезную работу — дополнительные вычислительные кредиты, приоритет или квота. Участие добровольное, правила видны. Старый телефон не исключает человека из продукта; его дополнительный вычислительный вклад может быть мал. Цена кредита основана на полезной работе и стоимости обслуживания, не на заявленных TFLOPS и не на росте цены токена.

Платящие клиенты: API с договорённым качеством обслуживания, изолированные корпоративные узлы, пакетные вычисления и специализированные решения. Гарантированную задержку обслуживают соответствующие стабильные узлы. Оплачиваемые задачи, бесплатные запросы и обучение имеют раздельные очереди и бюджеты. Их нельзя обещать на одной и той же мощности одновременно.

Проверяемая экономика за период:

`Доход B2B + бюджет партнёров >= ядро GPU + сеть/хранение + проверки/оркестрация + бесплатное обслуживание + команда + привлечение + резерв`.

Электричество и износ устройств несут участники в согласованных пределах; для проекта это вклад, для общества он не бесплатен. Квоты и стимулы должны сохранять смысл для владельца устройства.

Массовая реклама после проверки удержания и себестоимости. Сначала привлечение подходящих GPU-владельцев, университетов, сообществ разработчиков и партнёрских площадок. Отдельная воронка для массовых пользователей и отдельная — для вычислителей. `Цена полезного узла = расходы канала / удержанные проверенные узлы`. Выборка должна различать модели устройств; нельзя переносить конверсию геймерского сообщества на всю страну.

## 9. За счёт чего можно построить преимущество

Сами открытые веса доступны конкурентам. Преимущество Triad предлагаю строить на сочетании:

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

Цель «лучше мировых лидеров» переводится в согласованный независимый набор тестов, закрытые реальные задания и сравнение с актуальными версиями конкурентов на дату выпуска. Публиковать отдельно результаты собственных весов, результат всей системы с инструментами и затраты на ответ. Множество параллельных попыток не выдавать за результат одной попытки.

Ни одно имеющееся исследование не устанавливает число телефонов, гарантирующее это лидерство. План выше создаёт инженерную и исследовательскую основу для попытки его достичь; рекламный масштаб не заменяет результаты обучения. [Пример независимой методики сравнения](https://artificialanalysis.ai/methodology/intelligence-benchmarking).

## 10. Что менять в существующем Triad

По локальному коду `triad-mesh` подтверждены: комната до 12 участников, lease 15 секунд, фиксированные арифметические задания, WebGPU-тест вектора из 4096 элементов, выделение RAM 16/32/64 MiB. Это полезный прототип подключения, выдачи и проверки ограниченной работы. Глобального реестра обучающих устройств, модельного runtime и конвейера изменения весов в нём нет.

Нужно добавить отдельные компоненты, сохранив интерфейс входа и управления вкладом:

1. `node-agent`: согласие, ключ устройства, telemetry, model runtime, кэш, лимиты.
2. `node-registry`: capabilities, совместимость, профиль задания, последние проверенные замеры, доступность.
3. `scheduler`: policy-aware очереди, lease, retries, регионы, backpressure, deduplication.
4. `artifact-registry`: модели, адаптеры, данные и подписи версий.
5. `verifier-service`: изолированные среды, проверка попыток, аудит, метрики.
6. `training-controller`: prime-rl, контрольные запуски, checkpoints, rollout admission, оценка.
7. `contribution-ledger`: однократный зачёт подтверждённой работы и бюджет пользовательской квоты.
8. `capacity-api`: отдельные данные «зарегистрировано», «подходит», «в работе», «принято», «осталось до выбранного эксперимента».

Крупные тексты/траектории хранить в object storage с ссылкой из метаданных. API управления, очередь и хранилище должны масштабироваться отдельно. Конкретный managed/cloud/self-hosted поставщик выбирается по измеренной нагрузке и бюджету; это ещё не production-развёртывание.

## 11. Последовательность реализации и критерии

Сроки ниже — ориентиры для команды, имеющей доступ к GPU; не обещание календарного завершения одним агентом без инфраструктуры.

| Этап | Масштаб / ориентир | Проверяемый результат |
|---|---|---|
| Лабораторный цикл | 1–2 недели; 3–10 исполнителей и доступное ядро | Задание → результат → проверка → изменение весов → оценка; checkpoint до/после; все ресурсы ограничены |
| Пилот сети | следующие 4–6 недель; 100–300 GPU-исполнителей, условно 8×80 GB ядро для 4–8B | Сравнение с контрольным запуском, работа при отключениях, измеренные скорость/трафик/возраст policy/стоимость/удержание |
| Первый открытый цикл | после прохождения пилота; примерно 1 300 совместимых исполнителей в базовом сценарии | Объём порядка 1 млн допустимых попыток за 30 дней при подтверждении коэффициентов и достаточном ядре |
| Масштабирование | 10 тыс., 100 тыс., затем более совместимых исполнителей | Каждая ступень подтверждает стоимость и качество; ядро, проверка и сеть растут вместе с поставкой |
| Флагман | отдельный выбор модели и доступ к соответствующим группам GPU | Независимые результаты собственных весов против актуальных лидеров, экономически обеспеченный доступ |

Для старта нужен состав функций: руководитель ML-исследований, инженер обучения, инженер GPU/runtime, два инженера распределённой системы/клиента, инженер продукта и специалист по качеству данных/оценке. Часть ролей совмещается в пилоте; крупное обучение потребует расширения.

Переход к рекламному масштабированию разрешает не красивый счётчик, а измеренный эксперимент: сеть даёт полезные данные, модель улучшается на закрытых задачах, ядро успевает учиться, затраты и удержание приемлемы.

## 12. Что показать SoftServe

Техническая демонстрация из четырёх шагов:

1. Несколько реальных устройств подключаются; отображается профиль конкретной модели и доступный ресурс.
2. Они выполняют разные обучающие задания; один участник отключается, задание корректно переназначается.
3. На обучающем узле создаётся новый adapter/checkpoint из проверенных результатов; артефакт и run-id сохраняются.
4. Сравнение исходной и новой версии на заранее отделённых задачах; рядом число дополнительных узлов для следующего заранее определённого эксперимента.

Для самой встречи: прототип текущей сети + эта схема + сценарный расчёт, явно отделённые от ещё не выполненного обучения. Конкретное предложение партнёру: совместный пилот распределённого RL с выделенным инженерным участием и одной группой GPU, затем решение о масштабировании на основании результатов. Сообщения партнёрам в рамках этой работы не отправлялись.

## Приложенные расчёты

- `capacity.py` — стандартная библиотека Python, сценарии и самопроверки, без загрузки моделей и сетевых запросов.
- `capacity-scenarios.json` — результаты. Поля качества и неизвестной сквозной скорости намеренно не заполнены вымышленными значениями.
- Запуск: `python3 capacity.py`. Проверены нулевой вклад, недостижимая цель, уже достигнутая цель, пределы долей, распределение ресурсов и ограничение скорости самым медленным звеном.

Ранее составленный расчёт часов полного обучения DeepSeek-V3 относится к историческому ориентиру pretraining и не используется как требование для предложенного здесь дообучения готовой модели.


## 13. Сообщество и мессенджер

Продуктовая связь: полезный AI привлекает людей; группы помогают обсуждать способы применения; проекты собирают участников и добровольные устройства; подтверждённые результаты дают материал для улучшения системы. Сообщество имеет самостоятельную ценность даже для человека, который пока не предоставляет GPU.

В первой реализации добавлены публичный каталог проектов и групп, профиль участника, история обсуждений, ответы на сообщения, реакции, личные диалоги участников общей группы, базовая модерация владельцем группы, архивирование и реестр профилей устройств проекта. Данные сохраняются в отдельных таблицах D1. Вход — через аккаунт ChatGPT средствами платформы Sites. Личные диалоги закрыты для остальных пользователей, но их содержимое хранится на сервере без сквозного шифрования; прежний экспериментальный зашифрованный канал остаётся отдельным.

Добавление устройства здесь фиксирует профиль и локальную проверку WebGPU. Это ещё не постоянный нативный агент, не подтверждённая training-мощность и не выполнение модельных заданий. Реальный CPU-кластер предыдущего прототипа доступен отдельным переходом. Привязка идентичности его узла к устойчивому профилю проекта и учёт проверенных модельных заданий входят в следующий технический этап.

Для массовой версии: полноценные push-уведомления, управление несколькими устройствами аккаунта, восстановление доступа, блокировка/жалобы и модерация, поиск, масштабируемая доставка событий, файлы, защищённый обмен ключами и независимо проверенное E2EE. Для E2EE использовать проверенный протокол и библиотеки с управлением ключами на нескольких устройствах; не развивать самодельную криптографию пилота в массовый мессенджер.

История общения, реакций и личных сообщений не должна автоматически попадать в обучение. Отдельное явное согласие и выбранные пользователем данные нужны для каждого механизма улучшения на пользовательском контенте.