dumai
ИИarXiv cs.LG

GF-DiT динамически перераспределяет GPU-параллелизм для диффузионных трансформеров

Препринт, ещё не рецензирован · ранние данные

Кратко

Авторы предлагают runtime для обслуживания diffusion transformer, который меняет схему параллелизма для разных запросов и этапов выполнения. В оценке на vLLM-Omni на изображениях и видео система работала быстрее и с меньшей задержкой, чем фиксированная статическая схема.

Зачем это знать?

Это может быть полезно для понимания того, как ускорять серверы генеративных моделей без жесткой привязки к одной конфигурации. Но выводы основаны на препринте и конкретных бенчмарках, поэтому их нельзя автоматически переносить на любые модели и GPU-серверы.

Разбор

Авторы посмотрели на проблему не как на «как бы побыстрее запустить модель», а как на задачу планирования ресурсов в реальном времени. Идея простая: у разных запросов на генерацию картинок и видео нагрузка меняется по ходу работы, поэтому одна и та же схема распределения GPU не обязана быть удачной на всём пути выполнения. Чтобы проверить это, они встроили GF-DiT в серверный стек vLLM-Omni и дали ему возможность перестраивать, как именно несколько GPU делят между запросами работу на разных этапах.

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

В оценке они сравнили GF-DiT с фиксированной статической схемой на реальных задачах генерации изображений и видео. Результат не сводится просто к «стало быстрее»: система лучше переживала смешанную нагрузку и всплески коротких запросов, где старый подход особенно проседал. Кроме того, у неё заметно снизились нарушения сервисных обещаний — то есть меньше запросов выходили за допустимое время ожидания. Ещё один важный момент: авторы специально подбирали нагрузки так, чтобы сравнение шло не в одной удобной точке, а при похожем давлении на сервер, поэтому выигрыш выглядит именно как свойство самого подхода, а не как удачно выбранный тест.

Ключевые цифры

6.01×На некоторых сценариях система обрабатывала запросы более чем в шесть раз быстрее, чем статическая схема.
95%Средняя задержка в лучших случаях падала почти до нуля по сравнению с базовым вариантом.
90%Нарушений обещанного времени ответа становилось примерно в десять раз меньше.
778 ms → 60 μsПерестройка групп GPU ускорилась с почти секунды до долей миллисекунды, так что переключаться стало почти мгновенно.

Можно ли доверять

Это препринт на arXiv, значит, другие учёные его ещё не прошли формальную проверку. Проверяли систему на одном 4-GPU сервере H20 и одном 8-GPU сервере A100, на двух конкретных моделях для видео и изображений, так что результат убедителен, но пока привязан к этим условиям. С другой стороны, авторы сравнили подход сразу на нескольких сценариях нагрузки, а не на одном удобном тесте, поэтому работа выглядит достаточно серьёзно.

  • Preprint / arXiv paper, not peer reviewed.
  • Results come from a serving-system benchmark on specific models and GPU servers, so generality beyond those setups is uncertain.
  • Latency results are for completed requests only, and policies with failures may look better than they are.

Пересказано ИИ по научной статье. Это научпоп, а не совет врача. Как это устроено

Источник и детали
ЖурналarXiv (cs.LG)
Дата публикации у нас12 июня 2026 г.
Дата источника11 июня 2026 г.
ОригиналОткрыть
АвторыXinwei Qiang, Yifan Hu, Shixuan Sun, Jing Yang, Han Zhao, Chen Chen, Yu Feng, Jingwen Leng, Minyi Guo