Видеомодель на 22 млрд параметров запустили на RTX 3080 с 10 ГБ памяти

Владелец RTX 3080 с 10 ГБ видеопамяти запустил у себя видеомодель LTX-2.5 на 22 миллиарда параметров — то есть на 22 миллиарда обучаемых чисел-весов. Только трансформер, главная часть модели, занимает 39 ГБ, а текстовый энкодер Gemma добавляет ещё 24,5 ГБ. На бумаге такая связка в десятигигабайтную карту не лезет. На практике она работает, но платит за это оперативной памятью, временем и возней с окружением. Все замеры времени в материале автор называет предварительными наблюдениями, а не воспроизводимым бенчмарком.

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

Автор собирает вертикальные ролики из 6–8 планов. На одном компьютере по очереди работают несколько моделей:

• Gemma через llama.cpp помогает со сценарием; • FLUX.2 [klein] рисует кадры с одним и тем же лицом героя; • LTX-2.5 оживляет кадры; • Qwen3-TTS озвучивает; • ACE-Step делает музыку; • ffmpeg собирает монтаж.

LTX получает готовую картинку и превращает её в короткий видеоплан. Автор использует distilled-версию, то есть упрощённую и более быструю. Генерация идёт в два этапа. Сначала 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 убирает ошибки нехватки памяти из-за фрагментации на длинных планах.

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

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

Windows и память, которая не освобождается

Первый запуск вообще не дошёл до генерации. Он завершился access violation (аварийным обращением к памяти) при открытии весов, без внятного сообщения. В окружении автора причина нашлась в чтении больших файлов формата safetensors под Windows. Библиотека пыталась отобразить файл в память целиком и падала на файлах больше примерно 2 ГБ.

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

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

Пять минут на план, 25 секунд на счёт

За перезапуски процессов приходится платить. По предварительным замерам, один план занимает около пяти минут, а сам денойзинг — примерно 25 секунд, меньше 10% времени. Остальное время уходит на чтение и подготовку примерно 65 ГБ весов трансформера и энкодера Gemma. Это повторяется для каждого плана.

Выводы для тех, кто собирает похожий конвейер:

• Узкое место здесь диск и RAM, а не GPU. Прежде чем покупать более быструю видеокарту, стоит измерить скорость загрузки весов и расход памяти. • Ролик из шести планов собирается около получаса, короткий — за несколько минут. • Следующий шаг оптимизации — держать энкодер и трансформер в памяти между планами. Автор этот вариант ещё не проверял. Он вернёт проблему с освобождением памяти под другие модели.

Отдельно автор делится приёмами, как получить пригодное движение:

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

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