20 июля автор AI Doomsday Toolbox v0.948 показал экспериментальный запуск stable diffusion через несколько Android-устройств в одной сети. Замысел не в том, чтобы три телефона обогнали GPU-станцию. Он гораздо приземлённее: попытаться запустить модель, которая не помещается в памяти одного устройства.
Это важное различие для любого, кто уже упёрся не в желание генерировать, а в границу доступного железа. Кластер из телефонов может расширить суммарную ёмкость, но расплачивается за это задержкой, координацией и риском сбоев. Поэтому правильный вопрос звучит не «станет ли быстрее?», а «даст ли схема возможность запустить нужную модель и останется ли она пригодной для моей задачи?»
Платите в рублях за AI-модели без наценки на токены через provod.ai
Что автор предлагает распределить
В описанной схеме text encoder и VAE остаются на одном устройстве, а diffusion model делится между тремя машинами. Это не независимый тест производительности и не обещание готового режима для всех сценариев. Сам автор прямо называет функцию экспериментальной и объясняет компромисс: более крупные модели становятся доступнее ценой скорости.
У проекта уже заявлены master/worker-потоки, локальная генерация изображений и видео через Stable Diffusion, а также позиционирование нескольких Android-устройств как объединённого ресурса RAM и вычислений. На странице Google Play, обновлённой 13 июля, перечислены SD 1.5, SDXL, FLUX, LoRA и VAE. Но публикация от 20 июля отдельно предупреждала, что v0.948 ещё ожидала одобрения для Play. Значит, нельзя подменять описание платформы утверждением, будто именно эта сборка уже распространялась через магазин.
Здесь покупают не скорость, а возможность
Интуиция «больше устройств значит быстрее» в этом случае обманчива. У распределённой схемы появляется работа, которой нет в запуске на одном устройстве: узлы должны согласованно выполнять свои части, передавать данные и переживать выпадение участника. Авторская формулировка о жертве скоростью здесь важнее любого воображаемого выигрыша.
Именно поэтому эксперимент стоит оценивать в двух разных координатах:
| Вопрос | Одиночный телефон | Кластер из двух или трёх устройств |
|---|---|---|
| Помещается ли нужная модель | Может не поместиться | Может появиться шанс разместить её частями |
| Время до результата | Меньше координационных издержек | Автор ожидает жертву скоростью |
| Сложность запуска | Один контур отказа | Сеть, master/worker и повторные попытки |
| Ценность | Быстрый локальный опыт с тем, что уже работает | Проверка границы доступной ёмкости |
В этом и состоит поворот. Если задача уже решается на одном устройстве, подключение ещё двух телефонов может только добавить трения. Кластер становится осмысленным, когда ограничение известно: выбранная модель не проходит по памяти одиночного телефона, а локальный запуск всё ещё важнее, чем минимальная задержка.
Начинать нужно не с большой модели
Самый полезный первый шаг здесь не «собрать три устройства и сразу загрузить максимум». Это canary, который отделяет проблему памяти от проблем сети и распределения.
- Запустите на одном телефоне известную небольшую модель.
- Зафиксируйте prompt, seed и число шагов.
- Повторите ту же задачу на двух, затем на трёх устройствах.
- Для каждого прогона отметьте, поместилась ли модель в память, сколько занял весь путь до результата, были ли отказы и повторы, совпадает ли выход с ожидаемым по заданным параметрам.
- Только после этого пробуйте модель, ради которой и понадобилось распределение.
Такой тест не докажет, что кластер «быстрее». Зато он даст решение, которого обычно не хватает в первых демонстрациях: является ли ограничением именно memory fit и покупаете ли вы за дополнительную сложность реально нужную ёмкость.
Полезно заранее определить стоп-условие. Если второй или третий узел регулярно требует повторных запусков, а нужная модель всё равно не даёт приемлемого цикла работы, эксперимент выполнил свою роль: он показал границу схемы. Неудачный canary здесь не провал, а способ не превратить несколько телефонов в бесконечный проект по обслуживанию инфраструктуры.
Где возникает практический риск
В локальной сети можно контролировать топологию и состав устройств, но с ростом числа участников растёт число точек отказа. Потеря соединения, несовместимость конкретного набора устройств или сбой одного worker способны сорвать весь запуск либо потребовать повтора. Поэтому результат стоит считать end-to-end: от отправки задания до готового изображения, а не по отдельной части pipeline.
Есть и простой предел безопасности: worker-сервисы не стоит открывать в публичную сеть. Эксперимент имеет смысл держать внутри доверенного локального контура, где понятно, какие устройства участвуют и кто ими управляет.
Сильное возражение против phone cluster тоже честно. Если цель заключается в регулярной генерации с коротким временем ожидания, а локальная автономность не является требованием, GPU или облачный сервис почти наверняка окажутся более прямым путём. Телефонный кластер не становится заменой рабочей станции только потому, что суммирует несколько устройств.
Для задач, где важнее использовать готовые модели, чем поддерживать собственную распределённую схему, provod.ai предлагает другой operating model: hosted-модели без оркестрации телефонов. Это не инфраструктура Stable Diffusion и не способ превратить устройства в кластер, а выбор в пользу меньшего количества локальных операций.
Когда эксперимент оправдан
Пробовать распределённый запуск стоит, если одновременно верны три условия: нужная модель не помещается на одном Android-устройстве, локальная работа ценна для вашего сценария, а дополнительное время ожидания допустимо. Например, как проверка доступной ёмкости на уже имеющихся устройствах или как автономный технический эксперимент.
Не стоит начинать с него, если важнее предсказуемое время генерации, потоковая работа или простота поддержки. Тогда ценность кластера исчезает: он решает capacity problem, которого в вашем случае может не быть.
Что для вашей задачи дороже: возможность локально вместить более крупную модель с непредсказуемой задержкой или отказ от этой автономности ради другого operating model и меньшей локальной оркестрации?
provod.ai — один контур от первого теста до рабочего продукта
Проверьте гипотезу в интерфейсе, а затем перенесите её в API: команда сохраняет выбранную модель, общий баланс и доступы, не начиная интеграцию и закупку заново перед запуском.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Тестовые и боевые запросы оплачиваются по одной прозрачной логике: официальная цена модели 1:1, без собственной маржи provod.ai.
Доведите AI-сценарий до production: форма регистрации · цены на модели · защита данных по 152-ФЗ · API и интеграции