LTX-2.5 на 22 млрд параметров заработала на RTX 3080 с 10 ГБ, но тратит 5 минут на план

Автор исследования на Хабре запустил локально видеомодель LTX-2.5 на 22 млрд параметров на видеокарте RTX 3080 с 10 ГБ памяти. Только трансформер весит 39 ГБ, ещё 24,5 ГБ занимает текстовый энкодер Gemma. Модель работает под Windows и встроена в конвейер вертикальных роликов из 6–8 планов. Но за малый объём видеопамяти пришлось заплатить оперативной памятью, временем загрузки и возней с окружением.

Задача у автора прикладная, и на одном компьютере по очереди работает целая цепочка моделей. Gemma через llama.cpp помогает со сценарием, FLUX.2 [klein] рисует кадры с постоянным лицом героя, LTX-2.5 оживляет эти кадры. Затем голос делает Qwen3-TTS, музыку — ACE-Step, а монтаж выполняет ffmpeg. LTX получает готовую картинку и превращает её в короткий видеоплан.

Как 39 ГБ весов проходят через 10 ГБ видеопамяти

Автор использует distilled-версию LTX-2.5, где видео собирается в два этапа. Сначала идут 8 шагов денойзинга в низком разрешении (около 1,4 с на шаг). Затем латентный апскейлер увеличивает результат в два раза, и ещё 3 шага выполняются в полном разрешении 576×1024 (около 5 с на шаг). Эти тайминги автор называет предварительными наблюдениями, а не воспроизводимым бенчмарком.

В штатном пайплайне Lightricks/LTX-2 для этого хватает двух ключей. Параметр --quantization fp8-cast хранит веса в bf16, а при загрузке на GPU приводит их к fp8: памяти нужно вдвое меньше, отдельный fp8-чекпоинт не требуется. Параметр --offload cpu включает потоковый режим: блоки трансформера лежат в оперативной памяти и подаются на видеокарту по очереди. Для длинных планов понадобилась ещё переменная PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True, иначе из-за фрагментации памяти случались OOM.

Память при этом не исчезает, а переезжает с видеокарты в RAM. По оценке автора, для такой схемы нужно минимум 32 ГБ оперативной памяти (лучше 64) и файл подкачки от 32 ГБ. Поэтому фразы «запускается на 10 ГБ» для описания требований недостаточно.

Две грабли: safetensors под

Windows и выгрузка, которая не выгружает

Первый запуск закончился access violation при открытии весов, без внятного сообщения. В окружении автора библиотека safetensors пыталась целиком отобразить в память файлы больше примерно 2 ГБ и падала. Обход — подмена safe_open: заголовок файла разбирается вручную, а тензоры отдаются как представления поверх read-only np.memmap. Интерфейс остаётся прежним, поэтому пайплайн LTX ничего не замечает, и отдельная копия весов не расходует commit-память. Патч подключается без правки чужого кода: файл лежит в site-packages, а .pth-файл с import ltx_sft_patch подменяет модуль при старте интерпретатора.

Вторая проблема возникла при совместной работе моделей. Сначала каждая жила в постоянном процессе-воркере, и после работы её выгружали вызовом unload. В схеме с CPU-offload часть видеопамяти и закреплённой RAM после этого оставалась занятой, и следующая модель не помещалась. Надёжным решением стало завершать процесс целиком. Теперь каждая модель работает в своём процессе и своём venv, а у LTX отдельный процесс запускается на каждый план. Побочная выгода: моделям нужны несовместимые версии torch и diffusers, а изолированные окружения не дают им мешать друг другу.

Где на самом деле уходит время

Перезапуски имеют цену. По предварительным замерам, на один план уходит около пяти минут, а сам денойзинг занимает примерно 25 секунд. Это согласуется с арифметикой шагов: 8 по 1,4 с плюс 3 по 5 с дают около 26 секунд. Остальное время тратится на чтение и подготовку примерно 65 ГБ весов трансформера и Gemma-энкодера, причём заново для каждого плана.

Вывод для тех, кто собирает похожий конвейер: прежде чем покупать более быструю видеокарту, стоит измерить скорость загрузки весов и использование памяти. Ролик из 6 планов собирается около получаса, короткий — за несколько минут. Следующий шаг автор видит в том, чтобы держать энкодер и трансформер в памяти между планами, но этот вариант ещё предстоит проверить.

Отдельно автор делится приёмами против слабостей модели. Стартовый кадр должен показывать состояние до действия: если дверца уже открыта, а в промпте её просят открыть, модель вынуждена выдумывать происходящее. Контакт рук с предметами лучше разносить на два плана: в первом рука тянется, после склейки дверца уже открыта, и сомнительный момент остаётся за кадром. Если важен финал движения, конечный кадр можно передать вторым --image. Для липсинка нужна другая схема: полная, не distilled-модель, distilled-LoRA и аудио-ветка a2vid_two_stage, а из результата берётся только видео, звук остаётся из озвучки.

Итог: 22B-модель на домашней карте с 10 ГБ оказалась рабочим вариантом для коротких роликов. Всё идёт локально, без облака и подписок, но ценой большого объёма RAM, долгой загрузки и ручной настройки окружения.