Японский автор собрал на M1 Max четырёхкадровый комикс с читаемыми японскими репликами. Самая быстрая проверенная конфигурация справилась за 4,4 минуты, пиковое потребление памяти составило 11,1 ГБ. Это тест MOSS-Image: в промпте можно задать содержание картинки и расположение элементов.
Занятная деталь: OpenMOSS указывает английский и китайский как языки текста на изображениях. Автор теста получил корректные японские реплики во всех четырёх кадрах. Результат пока подтверждает один тест. Для комиксов, постеров и обложек уже интересно само управление текстом и его местом в кадре.
MOSS-Image раскладывает комикс по кадрам и репликам
Команда OpenMOSS выпустила MOSS-Image 16 октября 2026 года. В техническом отчёте модель описана как система с открытыми весами на 5 млрд параметров. Она рассчитана на изображения с длинным текстом и сложной композицией. Для кадра можно описать общую сцену, объекты, текстовые блоки и их положение.
В тесте автор использовал scene JSON — структурированное описание кадра. Общие свойства персонажа задаются один раз. Затем отдельно описываются события в каждом из четырёх кадров, реплики и области для их размещения. Например, bbox задаёт границы элемента; координаты отсчитываются от центра холста. У изображения 640 × 2560 вертикальная область простирается от −1280 до 1280 пикселей, горизонтальная — от −320 до 320.
События автор советует описывать по-английски, а японские реплики вписывать в текстовое поле как есть. В тесте использовали вертикальный холст 640 × 2560 с пропорцией 1:4. Японский текст получился без заметно сломанных кандзи и каны, а персонаж сохранял сходство во всех четырёх кадрах.
«Когда результат появился, я правда удивился», — пишет автор японского материала о читаемых репликах. Его имя в предоставленном тексте не указано. Результат относится к одному тесту на одной машине. Модель может иначе справиться с другими сценами и языками.
Четыре способа запуска дают разную скорость и расход памяти
Все варианты сравнивали на Mac с M1 Max и 64 ГБ памяти. Для одиночной картинки использовали холст 1024 × 1024 и 30 шагов, для комикса — 640 × 2560. Здесь важно различать пиковое потребление памяти и размер весов модели: для ComfyUI в исходном тесте указан именно размер модели.
| Способ | Одиночное изображение, 1024², 30 шагов | 4-кома, 640 × 2560 | Память |
|---|---|---|---|
| mflux 0.24.0 из PyPI | около 8,7 минуты | ошибка: чёрное изображение | пик 22,5 ГБ |
| mflux main из GitHub | около 8,7 минуты | успех, около 16,5 минуты | пик 29,6 ГБ |
| felix版 turbo | нет данных | успех, около 4,4 минуты | пик 11,1 ГБ |
| ComfyUI, bf16 | около 11 минут | успех, около 21 минуты | модель занимает около 28 ГБ |
В этом сравнении быстрее и экономнее оказался felix版 turbo. По оценке автора, он подойдёт для Mac с 16–24 ГБ памяти. Это оценка по одному тесту, а не гарантия для любой конфигурации. mflux main потребовал больше ресурсов: для генерации четырёх кадров автор рекомендует от 48 ГБ. Качество mflux и ComfyUI он оценил как почти одинаковое.
- Если важны скорость и низкое потребление памяти, в тесте выиграл felix版 turbo: около 4,4 минуты и 11,1 ГБ.
- Для работы с LoRA автор выбирает свежую версию mflux из GitHub.
- ComfyUI тоже справился, но генерация заняла около 21 минуты, а модели требовалось около 28 ГБ.
- Перед длинной серией стоит проверить одиночную картинку: первая загрузка модели вместе с весами заняла у автора около 34 минут.
Автор также повторил официальный пример на восемь кадров размером 512 × 4096 через mflux. Композиция и реплики в целом совпали с примером, но генерация заняла около 40 минут — примерно по 48 секунд на шаг. Для короткого комикса это терпимо. На серии вариантов время уже заметно.
Чёрный кадр в mflux 0.24.0 оказался ошибкой энкодера
Пакет mflux 0.24.0 из PyPI в тесте выдавал чёрное изображение на длинном запросе для четырёхкадровой сцены. По словам автора, сбой появлялся на промптах примерно от 350 токенов. В issue на GitHub другой участник описал похожую проблему с запросами длиннее примерно 500 токенов. Порог зависит от запроса и обработки шаблона.
Судя по описанию issue и исправления, в текстовом энкодере Qwen3.5 появлялось значение NaN — после него вычисления не могли продолжаться. На длинных последовательностях вычисления в float32 теряли точность. Генератор получал некорректные данные и создавал чёрный кадр.
Исправление внесли в PR #939: для обработки последовательности заменили нестабильный способ вычислений. Pull request приняли 27 октября 2026 года. Исправление уже было в версии на GitHub, но ещё не попало в опубликованный пакет mflux 0.24.0. Поэтому автор японского теста установил mflux из ветки main.
Если MOSS-Image на Mac выдаёт чёрный кадр на длинном описании, сначала проверьте версию mflux и наличие исправления. Переписывать весь запрос сразу не обязательно. Установка из main отличается от установки стабильного релиза. В исходном тесте автор ожидал, что будущая версия 0.24.1 или новее обойдётся без этого обходного пути. Это было ожидание на момент публикации, а не подтверждение текущего состояния пакета.
Для серии кадров JSON помогает управлять композицией
MOSS-Image интересна креаторам управлением композицией. В структурированном описании можно заранее задать положение реплик и разделение кадров, а также попросить модель сохранять персонажа от кадра к кадру. Такой подход пригодится для комикса, раскадровки, карточки товара или обложки, где тексту отведено конкретное место.
Я бы начал с одного кадра и короткой надписи. Потом добавил бы несколько текстовых блоков и перешёл к длинному вертикальному холсту. Так проще понять, что именно сбоит: японский текст, геометрия bbox или длинный запрос целиком. Если реплика исчезает или пузырь съезжает, автор советует не оставлять поле текста пустым. В его тесте при пустых репликах расположение пузырей становилось нестабильным, а в двух нижних кадрах они пропали.
В доступном фрагменте японской публикации нет самого JSON и команд установки. Воспроизвести точный рецепт по этому описанию не получится. Логика сборки понятна: общая характеристика персонажа, действие для каждого кадра, текстовые блоки, координаты и список ограничений. Для повторяемого дизайна это удобнее, чем каждый раз заново описывать расположение элементов словами.
Японский текст пока нужно перепроверять
В исходной статье сказано, что среди официально заявленных языков текста на изображениях есть английский и китайский, но нет японского. Успешная генерация японских реплик — заметный результат одного теста. Сам автор пишет, что иногда появляются странные кандзи, и советует в таких случаях перегенерировать изображение.
Есть и ограничения по железу и времени. Первый запуск с загрузкой модели занял у автора около 34 минут. Четыре кадра генерировались от 4,4 до примерно 21 минуты в зависимости от метода, а на восемь кадров ушло около 40 минут.
В исходнике есть платная часть про NSFW-сценарии и LoRA, но доступный фрагмент не содержит сравнительных результатов. По нему нельзя оценить, насколько LoRA улучшает генерацию и какие настройки проверял автор. Цена доступа к платной части тоже не указана.
Для визуального автора у MOSS-Image уже есть практичный плюс: модель помогает управлять изображёнными элементами и их расположением. Японский текст я бы пока считал перспективным бонусом, а JSON-layout — проверяемым преимуществом для повторяемых композиций. Четыре кадра получились быстро. Стабильность букв в серии ещё нужно проверить.
Примеры моих генераций фото и видео
Источники
MOSS-Image: официальный материал OpenMOSS о тексте и компоновке
Issue #920: сбой текстового энкодера на длинных промптах в mflux
Pull Request #939: исправление NaN в энкодере Qwen3.5
MOSS-Image и FLUX 3: сравнение управления композицией
Источникnote.com
