Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Декодер видеомодели удалось ускорить без переобучения, квантования и замены весов. В препринте University of Wisconsin–Madison и Beta Infinity, который не прошёл рецензирование и приводит замеры самих авторов, декодирование ускорилось в 6,91 раза, а полная генерация — в 2,21 раза. Для команд это открывает промежуточный путь между медленным штатным выполнением и глубокой специализацией всей модели под конкретное устройство.
Как Conv3D превратили в пакетные Conv2D
Узким местом оказался декодер вариационного автоэнкодера VAE. Он восстанавливает видео из скрытого представления и многократно вызывает причинную Conv3D: операция обрабатывает пространство и время, но при этом должна учитывать буфер прошлых кадров.
Авторы не заменяли трёхмерную свёртку приближённой моделью. Они разделили её ядро по временной оси и для каждого временного среза выполнили обычную пространственную Conv2D. Подходящие кадры складываются во временный пакет, проходят через одну операцию, затем результат возвращается в исходную раскладку и суммируется.
Такое преобразование сохраняет исходные веса, пространственный шаг, отступы, расширение ядра и порядок выходных данных. Смещение добавляется один раз после суммирования, иначе результат уже не соответствовал бы исходной Conv3D.
Главная сложность связана с буфером прошлых кадров. Для каждого среза ядра среда выполнения вычисляет допустимый временной интервал, не обрабатывает позиции за его границами и сохраняет причинный порядок: будущий кадр не может повлиять на предыдущий. Ускорение появляется потому, что короткие временные интервалы объединяются в пакет и проходят через хорошо оптимизированные пространственные свёртки.
Быстрый путь включается только для пяти измерений тензора, единичного временного шага и одной группы свёртки. Остальные вызовы возвращаются к штатной Conv3D. Счётчики показывают, какой маршрут использовал каждый вызов, а строгий режим останавливает проверку при неожиданном откате.
Ускорение сохранилось на границе полной генерации
Основной сценарий проверяли на Cosmos3-Edge: от входного изображения через удаление шума до финального видео. Cosmos3-Nano использовали для подробного профилирования, а неизменённое преобразование перенесли на LingBot-World с другим декодером Wan2.1. На LingBot измеряли только декодер с синтетическими совместимыми скрытыми представлениями, поэтому этот опыт подтверждает переносимость вычислительного приёма, но не ускорение продукта целиком.
Повторные запуски декодера Cosmos3-Edge прошли полностью по быстрому пути. В кодировщике остались вызовы с другим временным шагом, поэтому утверждение об отсутствии откатов относится именно к декодеру, а не ко всему конвейеру.
Полностью специализированный TensorRT оказался ещё в 1,36 раза быстрее преобразования, однако потребовал отдельных движков для фиксированных форм тензоров и состояний среды выполнения. Более общий маршрут при этом сохранил 95,55% абсолютного сокращения задержки между штатным PyTorch и TensorRT.
Оптимизация отдельного ядра не гарантирует ускорения системы. Встроенный вариант на Triton сократил время некоторых операций по отдельности, но после интеграции замедлил декодирование с 16,01 до 66,81 секунды. Поэтому измерять нужно не только ядро, но и весь декодер с его копированием данных, буферами и синхронизацией.
Когда работа меняет планы разработки
Этот подход стоит проверить до переобучения или замены декодера, если профиль показывает, что время уходит в причинные Conv3D с короткой временной и большой пространственной размерностью. Сначала нужно собрать профиль полного запроса, затем проверить формы тензоров, параметры свёрток и все состояния временного буфера. Доля быстрого пути должна подтверждаться счётчиками, а не предполагаться по архитектуре модели.
Следующий этап — сравнение результатов на одинаковом скрытом представлении. Работа проверяет расхождения в форматах чисел BF16 и FP32, но такое совпадение не доказывает одинаковое визуальное качество или поведение робота в замкнутом контуре. Для продукта всё равно нужны собственные проверки на его видео и задачах управления.
Преобразование меняет баланс памяти и задержки. В чистом сравнении пиковое выделение памяти через CUDA составило 7,31 ГиБ против 14,57 ГиБ у TensorRT. На испытанном Jetson AGX Orin с 64 ГБ оба варианта поместились, но на устройстве вместе с декодером обычно работают восприятие, планирование и управление.
TensorRT остаётся логичным выбором для фиксированной конфигурации, где минимальная задержка важнее времени сборки и запаса памяти. Преобразование на уровне среды выполнения подходит, когда меняются длина видео и состояния буфера, а поддерживать набор заранее скомпилированных движков дорого. Эти выводы пока относятся к одному устройству, декодерам семейства Wan и реализации причинной свёртки в Diffusers; перенос на другое оборудование требует нового профиля и полного замера.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
