Представьте модель, которая умеет одновременно генерировать реалистичные изображения по текстовому описанию, сохраняя исходную картинку при локальных правках, и применять глобальные трансформации стиля. Звучит как идеальный инструмент для дизайнеров и художников — один интерфейс для всего пайплайна от идеи до финального изображения. Но есть фундаментальная проблема: эти три задачи — text-to-image генерация, локальное редактирование и глобальное стилирование — конфликтуют на уровне целевых функций. T2I вознаграждает открытое качество и следование промпту, локальное редактирование требует максимального сохранения исходного изображения, а глобальное редактирование намеренно меняет статистику стиля, цвета и композиции. До сих пор инженеры выбирали компромисс: модель, которая худо-бед справляется со всем, но не блестяще ни с чем.

Исследователи из нескольких институтов предложили DanceOPD — On-Policy Generative Field Distillation. Вместо статического объединения параметров разных моделей подход рассматривает каждую способность как velocity field: векторное поле над общим генеративным пространством состояний, определяющее направление и скорость изменения в каждой точке. Единая student-модель учится запрашивать нужное поле в нужной точке пространства в нужный момент — динамически, а не по фиксированным правилам. Отсюда «Dance» в названии: модель словно танцует между полями возможностей, выбирая для каждого сэмпла оптимальную траекторию.

Проблема: почему возможности конфликтуют

Современные диффузионные модели и flow matching модели достигли впечатляющего качества в отдельных доменах. State-of-the-art модели генерации изображений поддерживают несколько способностей: text-to-image (открытая генерация по промпту), локальное редактирование (сохранить изображение-источник, применив целевые изменения), глобальное редактирование (изменить стиль, цвет, композицию по всему изображению). Проблема в том, что эти способности «склеиваются» с трудом.

Наивное объединение приводит к коллапсу: модель либо деградирует до посредственного качества по всем направлениям, либо доминирует одна способность за счёт остальных. Предыдущие подходы пытались решать это через статическую интерполяцию параметров или настройку пропорций данных — но это всё то же компромиссное решение. Flow matching как подход уже доказал свою эффективность в генерации изображений (SD3, Z-Image и другие), но объединение нескольких capability fields в единой модели оставалось открытой задачей.

DanceOPD: три связанных выбора

Ключевая идея DanceOPD — рассматривать каждую способность генерации как velocity field: векторное поле, определяющее направление и скорость изменения в каждой точке генеративного пространства. Это превращает задачу объединения в задачу маршрутизации: студент- модель должна динамически решать три связанных вопроса для каждого сэмпла.

Какое поле запрашивать? Модель выбирает, какая способность должна «вести» данный конкретный сэмпл — это может быть T2I-поле, поле локального редактирования или поле глобальной трансформации. Выбор делается для каждого сэмпла отдельно, а не глобально для всей модели.

В какой точке пространства запрашивать? Вместо того чтобы применять выбранное поле в фиксированной точке, студент определяет оптимальную позицию в генеративном состоянии для данного запроса. Это позволяет учитывать контекст — например, при локальном редактировании запрашивать поле ближе к исходному изображению, а при генерации с нуля — дальше.

Сколько состояний запрашивать? Третий выбор — сколько различных точек в пространстве использовать для данной операции. Это определяет баланс между разнообразием и точностью результата.

Как работает обучение

DanceOPD обучает единую student-модель на замороженных capability sources — уже обученных моделях, каждая из которых экспертируется в своей области. Студент учится у замороженных источников через механизм field distillation: каждый источник предоставляет velocity field как «учителя», а студент учится воспроизводить поле в нужных точках пространства.

Ключевое отличие от стандартного knowledge distillation — on-policy аспект: студент активно участвует в выборе того, у какого учителя учиться и в какой момент. Это не статичное копирование, а динамическое взаимодействие. Модель сама решает, когда обратиться к T2I-полю, когда к полю редактирования, а когда к полю стилизации — в зависимости от конкретной задачи и контекста.

Исследователи выделяют три специфических вызова, которые возникают при таком подходе: target-field ambiguity (какое поле ведёт данный сэмпл), state-distribution mismatch (распределение состояний студента не совпадает с распределением учителя) и trajectory-query correlation (корреляция между траекторией и точкой запроса). DanceOPD адресует все три через механизм hard-routed sample-wise field matching, который сохраняет семантическую целостность при жёсткой маршрутизации между полями.

Эксперименты и результаты

Авторы оценивают DanceOPD на двух основных платформах: Z-Image для композиции разнородных capability fields в едином студенте, и SD3.5-M для настройки realism field absorption. Эксперименты организованы вокруг трёх ключевых вопросов: может ли единый студент объединять разнородные поля без коллапса в компромисс; какие стратегии маршрутизации и выбора точек оптимальны при множественной супервизии; и как основные гиперпараметры влияют на результат.

Результаты показывают конкретные улучшения. При задаче объединения T2I и редактирования DanceOPD улучшает средний показатель GEditBench на 8.1% относительно лучшего воспроизведённого OPD-базового уровня и на 8.5% относительно edit source. При этом GenEval для базовой генерации улучшается на 2.0% относительно T2I source. Особенно заметны улучшения в категориях редактирования, требующих значительных визуальных изменений: background change +21.9%, style change +21.3%, color alteration +5.5% относительно DiffusionOPD.

При локальном и глобальном редактировании модель сохраняет исходное изображение-источник с высокой точностью, одновременно применяя целевые изменения. При глобальном редактировании стиль и композиция трансформируются корректно, без артефактов. При чистой T2I генерации качество не деградирует относительно специализированных моделей. Эти результаты показывают, что routed on-policy field matching может интегрировать edit field в студента, не разрушая base generation field.

Исследователи отмечают, что выбор стратегии маршрутизации критически важен: жёсткая маршрутизация по сэмплам (hard-routed sample-wise field matching), где каждый сэмпл целиком следует за одним полем, работает лучше, чем мягкая маршрутизация с интерполяцией. Это контрастирует с интуицией, что смешивание дало бы лучшие результаты. Причина в том, что интерполяция между полями размывает семантику: модель пытается одновременно следовать двум противоречивым целям, что приводит к артефактам. Joint training, weight merging, soft teacher mixing и dense same-step supervision, напротив, возвращают способност interference — именно ту проблему, которую DanceOPD призван решить.

Ограничения

Текущая формулировка DanceOPD предполагает, что замороженные capability sources предоставляют совместимые velocity fields над общим генеративным пространством состояний. В экспериментах это условие выполнялось, потому что все источники строились на одном backbone family, общем латентном представлении и shared scheduler. Однако для произвольных моделей из разных семейств это ограничение может стать проблемой — поля могут оказаться несовместимыми для объединения в единое пространство.

Второе ограничение — вычислительная сложность. Обучение студента требует не только forward pass через каждый из замороженных источников, но и динамический выбор стратегии маршрутизации для каждого сэмпла. Это накладные расходы, которых нет при использовании одной специализированной модели. Авторы приводят анализ wall-clock стоимости в секциях приложения, отмечая, что накладные расходы масштабируются линейно с количеством capability sources. На практике это означает: при трёх-четырёх способностях overhead приемлем, но при десяти и более полях стоимость может стать критичной.

Третий нюанс — чувствительность к выбору инициализации student-модели. Как показано в экспериментах, стартовые точки в пространстве состояний существенно влияют на итоговое качество. Неудачная инициализация может привести к тому, что студент «застревает» в локальном оптимуме одного поля и не может эффективно переключаться между способностями. Исследователи рекомендуют выбирать инициализацию, близкую к центру области, покрываемой всеми capability sources.

Почему это важно

DanceOPD интересен не только как техническое решение конкретной задачи, но и как пример того, как можно мыслить о композиции возможностей в генеративных моделях. Вместо попытки «склеить» параметры разных моделей подход предлагает рассматривать способности как отдельные поля в общем пространстве — и учит студента динамически переключаться между ними. Это концептуальный сдвиг: от статичной комбинации к динамической маршрутизации.

Для практических применений это означает, что в будущем можно будет иметь одну модель, которая одинаково хорошо делает несколько вещей: генерирует изображения по описанию, редактирует их локально по инструкции и применяет глобальные стили — без необходимости переключаться между разными инструментами или мириться с компромиссным качеством. Уже сейчас подход демонстрирует, что объединение возможностей без потери качества реалистично — вопрос в правильной архитектуре маршрутизации. Архитектурный принцип DanceOPD применим не только к генерации изображений: те же идеи можно перенести на другие модальности, включая аудио и видео, где разные способности тоже конфликтуют между собой.

Часто задаваемые вопросы

Почему жёсткая маршрутизация работает лучше мягкой?

Жёсткая маршрутизация (hard routing), где каждый сэмпл целиком следует за одним capability field, работает лучше, потому что T2I, локальное редактирование и глобальное стилирование имеют противоречивые целевые функции. Мягкая интерполяция заставляет модель одновременно оптимизировать под два конфликтующих направления, что приводит к размытию семантики и артефактам. Жёсткая маршрутизация позволяет каждому сэмплу получить чёткий сигнал от одного поля, а глобальная компетентность модели достигается за счёт агрегации — каждый сэмпл решает свою задачу, но модель в целом владеет всеми способностями.

Какие модели можно объединять через DanceOPD?

Ограничение текущей реализации — необходимость совместимых velocity fields над общим генеративным пространством. На практике это означает, что источники должны использовать один backbone, латентное представление и scheduler. Однако сама архитектура не привязана к конкретным семействам моделей, и адаптация к новым семействам — вопрос инженерной работы, не фундаментального ограничения.

Насколько это вычислительно затратно?

DanceOPD требует дополнительных вычислений по сравнению с одной специализированной моделью, поскольку для каждого сэмпла студент запрашивает информацию у нескольких замороженных источников. Однако авторы отмечают, что накладные расходы масштабируются линейно с количеством capability sources и при этом значительно меньше, чем полное совместное обучение всех способностей с нуля. Для сценария с тремя-четырьмя способностями накладные расходы приемлемы для практического применения.

Итог

DanceOPD демонстрирует, что объединение разнородных возможностей генерации изображений — text-to-image, локального и глобального редактирования — в одной модели реалистично без компромисса по качеству. Ключ — в представлении каждой способности как отдельного velocity field и динамической маршрутизации между ними. Подход не идеален: ограничение на совместимость генеративных пространств, накладные расходы на маршрутизацию и чувствительность к инициализации — реальные ограничения. Но направление многообещающее — в будущем одна модель сможет заменить несколько специализированных инструментов для работы с изображениями. Архитектурный принцип — динамическое переключение между capability fields вместо статичной комбинации — применим и к другим модальностям, где разные способности конфликтуют за ресурсы и «внимание» модели.