Генерим видео с новой моделью Minimax H3

Я заметил, что тема генерации видео или картинок на ЯПе долгое время как-то не раскрыта, либо модеры затирают такие темы до того как я их замечу либо просто некому поделиться опытом с сообществом.

В этом посте я попробую раскрыть тему и посмотрим как получится. Начну с азов которые должны послужить контекстом.

Самая продвинутая и развитая программа для генерации контента с нейронками это ComfyUI. Её нужно установить себе на ПК, в идеале нам нужен Windows или Linux. На все ваши вопросы легко ответит ChatGPT, Gemini, Claude, Grok и так далее. Если вам нужна помощь в установке, поставьте себе агента Codex/Claude Code и попросите его всё установить на ПК. Он же поможет выявить проблемы и их починит. Такой себе, карманный айтишник.

Для генерации контента в приемлимые сроки и с минимальным количеством проблем по совместимости железа нам понадобится видеокарта от Nvidia с архитектурой CUDA ядер. Минимум начиная от 3000 серии, и чем выше тем быстрее генерация.
Нам нужны дифузные (diffusion) модели, а не ЛЛМ (текстовые). Например, самая известная дифузная модель для генерации картинок это Stable Diffusion, а для видео Wan 2.2.

По железу добавлю ещё пару слов, потому что дальше это всё будет иметь смысл. Кроме самой видеокарты важны три вещи: сколько в ней VRAM (видеопамяти), сколько у вас оперативки, и на чём стоит система/модели, HDD или SSD. Для мелких моделей хватит 8гб VRAM, для нормальной работы с картинками комфортно от 12-16гб, а для тяжёлых видео-моделей вроде той, о которой пойдёт речь ниже, чем больше тем лучше, 24гб уже неплохо. Оперативки желательно от 32гб, а лучше 64гб. Про диск объясню чуть позже, там будет понятно почему это важно.

Из чего состоит дифузная модель
Тут важный момент, который многих новичков сбивает с толку. Когда вы качаете "модель" для генерации, это почти никогда один файл. Обычно нужно три (а иногда четыре) отдельные части, каждая отвечает за своё:

• Сама дифузная модель, в файле .safetensors или в сжатом .gguf. Это и есть "мозг", та сеть, которая на каждом шаге пытается угадать как убрать шум из картинки/видео и приблизить его к тому что вы просили. В ComfyUI она грузится нодой Load Diffusion Model. Раньше это были архитектуры типа UNet, сейчас в топовых моделях (картиночных и видео) это трансформеры (DiT), просто более прожорливые по памяти.
• Текстовый энкодер. Он превращает ваш промпт (текст) в набор чисел (эмбеддинги), понятный дифузной модели. Раньше хватало CLIP, сейчас в тяжёлых моделях в роли энкодера иногда стоит целая ЛЛМ-ка. Грузится нодой типа CLIPLoader/DualCLIPLoader.
• VAE (Variational Autoencoder). Дифузная модель не работает с картинкой/видео напрямую в пикселях, это слишком дорого. Она работает в сжатом "латентном" пространстве. VAE это переводчик между пикселями и латентом: на входе сжимает картинку в латент (когда он нужен, например для img2img), а в конце процесса — декодирует латент обратно в pixels, то что вы в итоге видите. Для видео с озвучкой иногда стоят сразу два VAE, один для видео-кадров, второй отдельно для звуковой волны, потому что это принципиально разные данные.

Квантизация: как ужимают вес модели
Прежде чем говорить про память, нужно объяснить откуда у одной и той же модели вообще берутся файлы на 66гб и на 21гб одновременно. Ответ — квантизация. На пальцах: все веса нейросети — это просто огромный набор чисел. Формат хранения определяет, сколько байт занимает каждое такое число, и чем меньше байт — тем грубее округление, тем компактнее файл и тем меньше нужно VRAM, но и точность каждого числа падает. Основные форматы, которые вы встретите в названиях файлов:

• fp32 — 4 байта на вес, "полная" точность. В релизах современных моделей почти не встречается, слишком жирно, упоминаю только для отсчёта.
• fp16 / bf16 — 2 байта на вес, "половинная" точность. Это де-факто стандартная точность, в которой сегодня выпускают большинство моделей, её и считают эталоном "полного качества" когда сравнивают более сжатые версии. bf16 отличается от fp16 тем, как распределены биты внутри числа (шире диапазон значений, меньше шанс переполнения), но по размеру они одинаковые.
• fp8 — 1 байт на вес, урезанная версия той же идеи с плавающей точкой. Уже вдвое легче fp16/bf16. Аппаратно быстро считается на видеокартах Ada и новее (RTX 40-й серии и выше), на более старых картах либо не работает, либо считается медленнее чем могла бы.
• int8 — тоже 1 байт на вес, но число хранится не как "дробное", а как целое, с отдельным коэффициентом масштаба на блок весов, который при вычислениях разворачивает целые числа обратно в приблизительно исходный диапазон. По размеру то же самое что fp8, но математика другая, и на разных картах ведёт себя по-разному.
• int8 convrot — это доработанный int8. Перед тем как округлить веса до целых чисел, их (и активации) "поворачивают" специальным преобразованием (по сути вариант техники QuaRot/Hadamard-поворота), которое размазывает резкие выбросы в весах, из-за которых обычный int8 обычно и теряет в качестве. Вес файла тот же, 1 байт на число, а результат по качеству заметно ближе к bf16, чем у обычного int8, и вдобавок это хорошо работает даже на старых картах вроде RTX 30-й серии, где fp8 аппаратно не ускоряется. Именно поэтому у современных моделей (в том числе у MiniMax H3 ниже) основной "безопасный" вариант — это именно int8_convrot.
• nvfp4 — 4-битная плавающая точка, то есть пол-байта на вес. Ещё вдвое легче int8/fp8. Требует видеокарту с архитектурой Blackwell (RTX 50-й серии, B200) чтобы реально считаться быстро, на более старых картах формат просто эмулируется — место на диске и в VRAM вы экономите, а вот прироста скорости не будет. Чтобы 4 бита не превращались в кашу, такие веса обычно дополнительно калибруют методом AWQ (activation-aware weight quantization) — грубо говоря, алгоритм смотрит какие веса на практике сильнее влияют на результат, и округляет их бережнее, а остальные — как получится.

Отдельно от квантизации стоит упомянутая раньше "обрезка" (pruning) — это не про округление чисел, а про то, что какой-то кусок параметров целиком выкидывается и заменяется чем-то более компактным (как в примере с H3 ниже, где часть весов заменили таблицей поиска). Обрезку и квантизацию комбинируют, отсюда и названия файлов вида pruned_int8_convrot — сначала обрезали, потом ещё и заквантовали то, что осталось.

Если совсем на пальцах: каждый шаг вниз по битности примерно вдвое уменьшает размер файла (bf16 → fp8/int8 — минус половина, int8 → nvfp4 — минус ещё половина), это чуть дальше будет видно на реальных цифрах MiniMax H3. С качеством падение не такое линейное: спуск с bf16 на fp8/int8 современные методы делают почти незаметным глазом, а вот с int8 на 4 бита разница уже более ощутима, особенно если модель квантуют не с оригинала, а поверх уже квантованной версии (так называемое "двойное квантование" — например nvfp4, сделанный из int8, а не из исходного bf16, ошибки округления складываются). Практический вывод: fp8 берите если у вас RTX 40/50, nvfp4 — только если у вас именно RTX 50-й серии и хочется максимальной экономии VRAM, а если не уверены в своей видеокарте или она старше — int8_convrot почти всегда безопасный выбор по умолчанию.

Как это всё лезет в память
Вот тут начинается самое интересное и самое частое место где люди упираются лбом в стену. У вас есть три (или четыре) файла, и все их нужно куда-то загрузить чтобы генерация пошла.

ComfyUI умный, он умеет offload, то есть если всё не помещается в VRAM видеокарты, он часть весов оставит в видеокарте, а остальное скинет в обычную оперативку. Если и оперативки не хватит — начнёт использовать файл подкачки (swap) на диске. Работать это будет, но чем дальше веса от видеокарты, тем медленнее генерация, диск на порядок медленнее оперативки, а оперативка на порядок медленнее VRAM.

Поэтому раскладку по памяти нужно прикидывать на глаз до того как вы что-то скачали, а не после. Условный пример: дифузная модель весит 22гб, энкодер ещё 10гб, VAE 1гб, итого 33гб. Если у вас видеокарта на 8гб, то программа заполнит эти 8гб под завязку, оставшиеся ~25гб из этих 33 уйдут в оперативку, а если оперативки тоже не хватает (например у вас 16гб и она уже занята системой и самим ComfyUI) — то, что не влезло, поедет в swap на диск. Отсюда и совет: либо берите модели, которые целиком укладываются в VRAM+RAM с запасом, либо ставьте быстрый NVMe SSD, потому что на HDD такая генерация будет по ощущениям как в 2010-х по диалапу.

Пример на реальной модели, для тех кто любит цифры
Возьмём модель из этого поста, MiniMax H3, как раз на ней видно, зачем вообще существуют все эти квантованные версии. Полный вес модели в bf16 (дифузионка + энкодер + оба VAE) — 123.6гб суммарно. Ни на одной домашней видеокарте это целиком не поместится, речь чисто о суммарном весе файлов. Разработчики сами понимали, что так никто не запустит модель локально, поэтому выкатили обрезанные (pruned) и квантованные версии: у диффузионной части выкинули часть служебных "модуляционных" весов (это примерно 40% параметров) и заменили таблицей поиска без потери качества, получилось 21гб вместо 66.3гб в bf16. Энкодер (это по сути полновесная ЛЛМ-ка на 32 млрд параметров) в самом лёгком варианте квантован в NVFP4 до 15.7гб вместо изначальных ~64гб. Видео-VAE весит 5.2гб, аудио-VAE всего 0.6гб. Сложите это всё — 21+15.7+5.2+0.6 — и получите те самые ~42.5гб, которые разработчики заявляют как минимальный набор, дающий уменьшение на 66% от полного веса. Даже это не влезет целиком в одну видеокарту на 24гб, но с offload'ом в оперативку это уже реально гонять даже на условной 3060, просто медленнее.

Как читать воркфлоу в ComfyUI
ComfyUI по сути — это визуальный конструктор из процедур (нод), соединённых стрелками, и читать его нужно слева направо:

• Загрузка. Слева всегда ноды типа Load Diffusion Model, CLIPLoader/DualCLIPLoader, Load VAE, возможно Load LoRA — сюда вы подключаете скачанные файлы.
• Входной контент. Если это не чистый текст-в-видео — сюда идут LoadImage, LoadVideo, LoadAudio, в зависимости что вы подаёте на вход.
• Предобработка. Часто входную картинку/видео нужно подрезать, уменьшить разрешение, привести к нужному соотношению сторон — этим занимаются ноды масштабирования перед тем как контент уйдёт дальше.
• Промпт. Текст из CLIPTextEncode (или аналога) превращается в эмбеддинги и идёт как условие (conditioning) на сэмплер.
• Сэмплирование. Основной этап, нода KSampler (или её аналоги) гоняет дифузионную модель N шагов, постепенно убирая шум по вашему промпту.
• Декодирование. VAEDecode переводит получившийся латент обратно в пиксели/аудио-волну.
• Финал. Либо сборка кадров в видеофайл (SaveVideo/VideoCombine), либо перед этим ещё апскейл картинок/видео, если хотите более высокое разрешение на выходе.

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

• CFG (classifier-free guidance) — насколько жёстко модель следует вашему промпту. Слишком низкий — модель промпт почти игнорирует, слишком высокий — начинаются пересвеченные артефакты и "перегрев" картинки.
• Steps — количество шагов очистки от шума. Больше шагов — чище результат, но после определённого числа выигрыш почти не заметен, а генерация просто дольше.
• Sampler/scheduler — конкретный алгоритм, которым модель идёт от шума к результату, и то, как меняется шаг между итерациями. Разные пары sampler/scheduler дают разную скорость и слегка разный характер картинки, тут нет единственно правильного варианта, обычно смотрят что рекомендует автор модели.
• Seed — зерно генератора случайности. Тот же сид + те же настройки = тот же результат, это удобно чтобы сравнивать, как влияет изменение одного параметра, при прочих равных.
• Denoising strength — актуально когда на входе уже есть картинка/видео (img2img/vid2vid-подобные сценарии). Отвечает за то, сколько от исходника остаётся, а сколько модель пересоздаёт с нуля. 1.0 — почти чистая генерация из шума, низкие значения — бережно сохраняют структуру исходника.

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

• T2V (text-to-video) — на входе только текстовый промпт, на выходе видео с нуля.
• I2V (image-to-video) — на входе картинка (плюс промпт), на выходе видео, которое "оживляет" эту картинку.
• V2V (video-to-video) — на входе готовое видео (плюс промпт), на выходе переработанное видео: смена стиля, замена объекта, перенос движения на другого персонажа и т.п.
• First-Last-Frame to Video (FLF2V) — на входе две картинки, стартовый и финальный кадр (можно и только один из них), на выходе видео, где модель сама придумывает движение между ними.
• Reference-to-Video (R2V/Ref2V) — на входе пачка референсов: картинки, видео, аудио, плюс текст описывающий что откуда брать (личность персонажа из одной картинки, движение камеры из видео, голос из аудио). На выходе видео, которое совмещает всё это по вашему описанию.

Собственно MiniMax H3
Вот тут переходим к главному, ради чего я всё это затевал. MiniMax только что (3 августа) выложила в открытый доступ веса своей новой модели H3 (она же Hailuo H3), и в ComfyUI её добавили day-0, то есть сразу в день релиза.

Что в ней особенного:

• Это не просто видео-модель, а омни-модальная: одна и та же сеть понимает на входе текст, картинки, видео и аудио вперемешку, и может выдавать видео сразу со звуком, встроенным в тот же проход генерации, а не "приклеенным" отдельно. Звук честно стерео, 32кГц.
• Разрешение до 2К, до 15 секунд на клип, 24 кадра в секунду.
• Под капотом — трансформер на 33 млрд параметров (у ComfyOrg он называется H3-Omni-Transformer), а в роли текстового энкодера не мелкий CLIP, а полновесная vision-language модель Qwen3-VL на 32 млрд параметров — что как раз лишний повод понять, зачем эта штука занимает десятки гигабайт.
• Официально открыли две "заточки" модели: fl2va (для T2V/I2V/first-last-frame) и ref2va (для референсной генерации). Это разные файлы диффузионной модели, они не взаимозаменяемы, под T2V/I2V берёте fl2va, под референсы — ref2va.

Файлы (кладутся в ComfyUI/models/diffusion_models, /text_encoders, /vae соответственно) и их реальные размеры, чтобы вы сразу прикинули, влезет ли это в ваше железо:

• Диффузионная модель (fl2va или ref2va): bf16 — 66.3гб, int8_convrot — 34гб, pruned_int8_convrot — 21гб. Есть и неофициальные community-сборки в .gguf, от Q3_K_M (14.2гб) до Q8_0 (35.2гб).
• Текстовый энкодер (Qwen3-VL-32B): int8_convrot — 27.1гб, nvfp4_awq — 15.7гб (NVFP4 хорошо ускоряется только на видеокартах Blackwell, то есть 50-й серии, на более старых картах он просто эмулируется, без прироста скорости).
• Видео-VAE — 5.2гб, аудио-VAE — 0.6гб.

Собираете самый лёгкий набор (pruned диффузионка + nvfp4 энкодер + оба VAE) — выходит примерно 42.5гб суммарно, именно эта цифра и заявлена авторами как минимальный вариант. По их словам, с учётом offload'а это тянет даже RTX 3060, просто не быстро. Готовые шаблоны воркфлоу лежат прямо в Template Library ComfyUI (нужна версия 0.30.0+), ищите по названию "MiniMax H3", там сразу три: T2V, I2V, R2V.

Отдельные ноды под капотом: MiniMaxH3ImageToVideo (она же покрывает и first/last-frame) и MiniMaxH3ReferenceToVideo. Для референсной генерации можно подать до 9 картинок, до 3 видео-референсов и до 3 аудио-референсов, и в промпте ссылаться на них тэгами вида <Picture 1>, <Video 1>, <Audio 1>, явно расписывая что откуда брать (личность, стиль, движение, камера, голос) — модель эксплицитные назначения понимает ощутимо лучше чем общие фразы. Для R2V разработчики советуют sampler res_multistep со scheduler beta или normal, simple там работает заметно хуже. Разрешение и длительность не абсолютно свободные: родной холст — короткая сторона 768px, кратно 32, и длительность привязана к сетке 17 кадров + 5 при 24fps, за это в шаблонах отвечает нода Resolution Selector.

LoRA — как учить модель новым штукам
Отдельная большая тема — LoRA (Low-Rank Adaptation). Скачивать и дообучать заново всю модель на 30+ гигабайт под каждого нового персонажа или стиль — не вариант. LoRA — это маленькая "заплатка" весов (обычно десятки-сотни мегабайт, не гигабайты), которую обучают отдельно на небольшом наборе изображений/видео, а затем накладывают поверх замороженной базовой модели. Так учат конкретных персонажей, художественные стили, позы, объекты — что угодно, на чём наберётся десяток-другой примеров.

Готовые LoRA под самые разные модели ищутся на civitai.com (обычный SFW-каталог), а всё что 18+ переехало на отдельный домен civitai.red (это тот же civitai, просто с апреля 2026 они разделили сайт на два фронта: .com только safe-for-work, .red — общий каталог, включая NSFW, нужен аккаунт с подтверждённым возрастом).

Подключается LoRA в воркфлоу максимально просто: берёте выход ноды Load Diffusion Model и вместо того чтобы тянуть его прямиком на сэмплер, пропускаете через ноду Load LoRA (LoraLoaderModelOnly), там же выбираете файл LoRA и её вес (силу применения), а уже выход этой ноды идёт дальше на KSampler. Можно цеплять несколько LoRA цепочкой одну за другой.

По MiniMax H3 отдельно скажу — модель вышла буквально вот только что, поэтому готовых LoRA под неё в природе почти нет, зато тренировка уже подъехала: Ostris AI Toolkit через пару дней после релиза добавил поддержку обучения LoRA под H3 (пока только для T2V/I2V, referenced-режим на подходе). Так что каталоги на civitai по этой модели будут расти прямо на глазах в ближайшие недели, в отличие от того же Wan, где выбор уже сейчас на тысячи LoRA.

Примеры
Ну и по традиции — примеры, чтобы не только слова, но и результат. Воркфлоу под каждый пример беру из стандартных шаблонов ComfyUI (T2V/I2V/R2V), просто меняю промпт и референсы.
(не разобрался как прикрепить сюда входное изображение, но по сути видео начинает первый кадр с этого изображения)

Код

For the target video, at 0.00 seconds into the target video, <Picture 1> (from [Shot 1]) is fully referenced. integrated_multimodal_description: Женщина (S1) стоит в кухне в розовом халате на голое тело. Она медленно растёгивает халат оголяя тело и грудь, расставляет ноги пошире, нагибается в камеру, её лицо приближается к камере, её грудь видна внизу кадра и она говорит: <d>[Russian] я сосу как пылесос</d>. overall_soundscape: quite kitchen room. non_diegetic_music: soft sexual intimate music.

Это сообщение отредактировал 1nflame - 3 авг 2026 в 22:28