Сколько VRAM нужно для Stable Diffusion, SDXL и Flux

С языковыми моделями расчёт памяти привычный: берёте число параметров, умножаете на байты формата, добавляете KV-кеш. С диффузионными моделями та же арифметика даёт заниженный ответ, и CUDA out of memory прилетает на карте, которая по расчёту должна была справиться.

Причина в том, что за словом «модель» здесь скрывается связка из трёх компонентов разного размера. У FLUX.1 текстовый энкодер весит больше, чем весь пайплайн SDXL.

Ниже — размеры весов по опубликованным файлам, разбор того, что добавляет разрешение, и приёмы, которые снижают пик до имеющейся карты.

Диффузионный пайплайн — это три модели, а не одна

Память при генерации изображения делят между собой четыре потребителя:

1. Денойзер. UNet у Stable Diffusion и SDXL, диффузионный трансформер (DiT) у SD 3.5 и Flux. Работает на каждом шаге сэмплирования, поэтому находится в VRAM дольше всех.
2. Текстовый энкодер. Отрабатывает один раз в начале, но грузится вместе с остальным пайплайном. У Flux это T5-XXL, у FLUX.2 — Mistral-3 на 24 миллиарда параметров.
3. VAE. Декодер латентов в пиксели. Сам по себе маленький, но на этапе декодирования даёт заметный пик по активациям.
4. Активации. Промежуточные тензоры, размер которых зависит от разрешения и числа изображений в батче.

Разница с LLM принципиальная. Там весь расход определяется одной моделью, здесь — суммой трёх, и самый крупный компонент не всегда денойзер. У FLUX.2 [klein] 4B текстовый энкодер Qwen3-4B занимает 8.05 ГБ против 7.75 ГБ у самого трансформера (карточка модели на Hugging Face).

Сколько весят сами модели

Таблица собрана по размерам файлов в официальных репозиториях Hugging Face, снятым 19 августа 2026 года. Колонка «Веса bf16/fp16» — сумма денойзера, текстовых энкодеров и VAE в том формате, в котором их выкладывает автор модели.

Модель	Параметры денойзера	Файл денойзера	Текстовые энкодеры	Веса bf16/fp16 целиком
SD 1.5	0.86 млрд	1.72 ГБ	0.25 ГБ	2.14 ГБ
SDXL base 1.0	2.57 млрд	5.14 ГБ	1.64 ГБ	6.95 ГБ
SD 3.5 Large	8.15 млрд	16.30 ГБ	11.43 ГБ	27.9 ГБ
FLUX.1 [dev]	11.9 млрд	23.80 ГБ	9.77 ГБ	33.7 ГБ
FLUX.2 [klein] 4B	3.88 млрд	7.75 ГБ	8.05 ГБ	16.0 ГБ
FLUX.2 [klein] 9B	9.08 млрд	18.16 ГБ	16.38 ГБ	34.7 ГБ
FLUX.2 [dev]	32.2 млрд	64.45 ГБ	48.02 ГБ	113 ГБ

Источники размеров: репозитории FLUX.1-dev, FLUX.2-klein-4B, stable-diffusion-xl-base-1.0, stable-diffusion-v1-5 и stable-diffusion-3.5-large. У SD 1.5 и SDXL взяты варианты .fp16.safetensors.

Три вывода из таблицы.

Веса — это ещё не требование к карте. Stability AI в анонсе SDXL 1.0 пишет: «SDXL 1.0 should work effectively on consumer GPUs with 8GB VRAM». Веса занимают 6.95 ГБ, остаток уходит на активации и рабочие буферы. Запас между размером весов и объёмом карты нужен всегда.

Ансамбль с refiner удваивает счёт. По тому же анонсу base — это 3.5 млрд параметров, а вся связка base + refiner — 6.6 млрд. При двух байтах на параметр обе модели одновременно в памяти дают около 13 ГБ. В статье о SDXL refiner описан как отдельная модель для финальных шагов денойзинга, и держать её резидентной необязательно.

Рост требований между поколениями нелинейный. От SDXL к FLUX.1 — в 4.8 раза по весам, от FLUX.1 к FLUX.2 [dev] — ещё в 3.4 раза. Причём у FLUX.2 [dev] почти половина объёма приходится не на генератор изображений, а на текстовый энкодер Mistral-3 24B.

Разрешение: где расход не зависит от весов

Активации — единственная статья расхода, которую не видно в размере файлов. Она определяется числом токенов, с которым работает денойзер.

VAE сжимает изображение в 8 раз по каждой стороне. Изображение 1024×1024 превращается в латент 128×128. Штатное разрешение задано в конфигурации UNet полем sample_size: у SD 1.5 это 64, то есть 512×512, у SDXL — 128, то есть 1024×1024.

Дальше работает квадратичная зависимость. Удвоение стороны изображения даёт вчетверо больше токенов, а матрица внимания растёт как квадрат от их числа, то есть в 16 раз. Поэтому генерация 2048×2048 на карте, которая спокойно тянет 1024×1024, падает по памяти — веса те же, активации другие.

Второй пик приходится на декодирование VAE. В документации diffusers по снижению расхода памяти прямо сказано: при генерации четырёх изображений за раз декодирование увеличивает пик активаций вчетверо. Оба штатных приёма против этого — там же:

pipeline.enable_vae_slicing()  # декодировать изображения батча по одному
pipeline.enable_vae_tiling()   # декодировать одно изображение плитками

Тайлинг отключается автоматически ниже заданного порога разрешения — для VAE в StableDiffusionPipeline это 512×512. На больших разрешениях он снимает пик почти целиком, ценой возможной разницы тона между плитками.

Flux: почему он выпадает из общего ряда

FLUX.1 [dev] — трансформер на 11.9 миллиарда параметров, файл flux1-dev.safetensors занимает 23.80 ГБ. К нему добавляются T5-XXL на 9.52 ГБ, CLIP-L на 0.25 ГБ и VAE на 0.17 ГБ. Итого 33.7 ГБ, то есть карта на 24 ГБ не подходит даже под одни веса.

Документация diffusers оценивает загрузку всех компонентов пайплайна примерно в 50 ГБ RAM или VRAM и предлагает два обходных пути: квантование до fp8 для работы в пределах 16 ГБ и последовательный офлоад для диапазона от 4 до 32 ГБ.

Практический набор вариантов для FLUX.1 [dev]:

Вариант	Файлы	Объём весов	Куда помещается
bf16, всё в VRAM	flux1-dev.safetensors + t5xxl_fp16	33.7 ГБ	48 ГБ
fp8, один файл	flux1-dev-fp8.safetensors	17.25 ГБ	24 ГБ
GGUF Q4_K_S + T5 Q5_K_M	flux1-dev-Q4_K_S.gguf + t5-v1_1-xxl-encoder-Q5_K_M	10.6 ГБ	16 ГБ
GGUF Q2_K + T5 Q3_K_S	flux1-dev-Q2_K.gguf + t5-v1_1-xxl-encoder-Q3_K_S	6.6 ГБ	12 ГБ

Размеры сверены с репозиториями Comfy-Org/flux1-dev, city96/FLUX.1-dev-gguf и city96/t5-v1_1-xxl-encoder-gguf 19 августа 2026 года. Колонка «Куда помещается» учитывает запас на активации и рабочие буферы, замеров под конкретное разрешение не заменяет.

Практический запуск этих файлов, включая раскладку по каталогам и доступ к интерфейсу снаружи, разобран в гайде по ComfyUI на арендованном GPU.

За fp8 приходится платить качеством. В официальных примерах ComfyUI сказано: «Note that fp8 degrades the quality a bit so if you have the resources the official full 16 bit version is recommended». Там же — рекомендация по энкодеру: t5xxl_fp16 брать при наличии более 32 ГБ оперативной памяти, иначе переходить на t5xxl_fp8_e4m3fn_scaled.

FLUX.2 [dev]: 113 ГБ весов

Здесь разрыв с потребительским железом становится качественным. Трансформер на 32.2 миллиарда параметров занимает 64.45 ГБ, текстовый энкодер Mistral-3 24B — ещё 48.02 ГБ.

Команда diffusers в разборе поддержки FLUX.2 приводит собственные замеры: без офлоада инференс требует больше 80 ГБ VRAM, с CPU-офлоадом на H100 — около 62 ГБ. Дальше идут компромиссы:

• 4-битное квантование (diffusers/FLUX.2-dev-bnb-4bit) — работает на карте с примерно 20 ГБ свободной VRAM. Веса при этом занимают 33.9 ГБ, но с офлоадом пик определяется самым крупным резидентным компонентом, а не суммой.
• Group offloading — запускается на 8 ГБ VRAM, но требует 32 ГБ свободной оперативной памяти либо флага low_cpu_mem_usage=True, снижающего это требование до 10 ГБ. Скорость падает существенно.
• Вынос текстового энкодера на удалённый эндпоинт в сочетании с NF4 даёт 18 ГБ.

FLUX.2 [klein]: обратный ход

Линейка klein существует ровно потому, что FLUX.2 [dev] не помещается в потребительское железо. В карточке 4B-версии Black Forest Labs заявляет работу «with as little as 13GB VRAM».

Официальная документация ComfyUI по klein даёт замеры на RTX 5090: дистиллированная 4B-версия — около 1.2 секунды на изображение при 8.4 ГБ VRAM, недистиллированная — около 17 секунд при 9.2 ГБ. Цифры сняты на конкретной карте с fp8-весами и на другом железе будут другими.

Отдельно стоит смотреть на лицензии, потому что они различаются внутри одного семейства. FLUX.1 [schnell] и FLUX.2 [klein] выложены под Apache 2.0, FLUX.1 [dev] и FLUX.2 [dev] — под некоммерческой лицензией Black Forest Labs.

Как уложиться в имеющуюся карту

Приёмы ниже перечислены от самых дешёвых по потерям к самым затратным по скорости. Все — из документации diffusers.

Квантование весов

Первый шаг и обычно достаточный. fp8 снижает объём вдвое, 4-битные форматы — вчетверо относительно bf16. Для FLUX.1 это разница между 48-гигабайтной картой и 24-гигабайтной.

Офлоад моделей на CPU

Два режима с разной ценой:

pipeline.enable_model_cpu_offload()       # компоненты целиком, умеренная потеря скорости
pipeline.enable_sequential_cpu_offload()  # подмодули по одному, сильное замедление

enable_model_cpu_offload держит в VRAM только работающий компонент: пока считает текстовый энкодер, денойзер лежит в оперативной памяти, и наоборот. Это то, почему 4-битный FLUX.2 с весами на 33.9 ГБ запускается на карте с 20 ГБ.

enable_sequential_cpu_offload перебрасывает отдельные подмодули и в документации помечен как «extremely slow». Берите его, когда альтернатива — не запустить вовсе.

Group offloading

Промежуточный вариант: на GPU переезжают не отдельные слои и не модели целиком, а группы слоёв.

pipeline.transformer.enable_group_offload(
    onload_device=torch.device("cuda"),
    offload_device=torch.device("cpu"),
    offload_type="leaf_level",
    use_stream=True,
)

Параметр use_stream=True перекрывает передачу данных с вычислением: следующая группа слоёв едет на карту, пока считается текущая. Требование к оперативной памяти при этом вырастает — в документации указано, что нужно вдвое больше RAM, чем весит модель.

VAE slicing и tiling

Работают только против пика на декодировании, но стоят одну строку и не трогают качество денойзинга. Включайте всегда, когда генерируете батчами или в разрешении выше штатного.

Предрасчёт эмбеддингов промпта

Если промпты известны заранее, текстовый энкодер можно прогнать отдельным процессом и передавать в пайплайн готовые prompt_embeds. Для FLUX.1 это снимает 9.52 ГБ из пикового расхода, для FLUX.2 [dev] — 48.02 ГБ.

Какую карту брать под какую модель

Таблица построена по составу каталога, а не по наличию офферов в конкретный момент: предложения по каждой модели появляются и уходят в течение суток.

VRAM	Карты в каталоге	Что помещается без офлоада
16 ГБ	RTX A4000, V100 16GB	SD 1.5, SDXL, FLUX.1 [dev] в GGUF Q4
24 ГБ	A30, RTX A5000	то же плюс FLUX.1 [dev] в fp8 и FLUX.2 [klein] 4B
32–40 ГБ	RTX PRO 4500, V100 32GB, A100 40GB	то же плюс SD 3.5 Large с энкодером T5 в fp8
48 ГБ	RTX A6000, RTX 6000 Ada, L40, L40S	FLUX.1 [dev] в bf16, FLUX.2 [klein] 9B, FLUX.2 [dev] в 4 битах
80–96 ГБ	A100 80GB, H100 80GB, RTX PRO 6000	то же с батчем и разрешением выше штатного
141 ГБ и выше	H200 141GB, B200, B300, GB300	FLUX.2 [dev] целиком в bf16

Цены зависят от провайдера и двигаются в течение суток, поэтому приводим их отдельно от таблицы и с датой. Минимальные предложения за один GPU на 19 августа 2026 года: A30 — 52.68 ₽/час, RTX A6000 — 82.79 ₽/час, RTX 6000 Ada — 118.92 ₽/час, L40 — 129.45 ₽/час, L40S — 132.46 ₽/час, RTX PRO 4500 — 138.49 ₽/час, A100 80GB — 197.41 ₽/час, RTX PRO 6000 — 329.66 ₽/час, H100 80GB — 365.57 ₽/час.

Одно наблюдение из этого списка, которое стоит проверить перед оплатой: RTX PRO 4500 на 32 ГБ дороже RTX A6000 на 48 ГБ — 138.49 против 82.79 ₽ за час. Если решает объём памяти, а не поколение архитектуры, 48 ГБ обходятся дешевле 32 ГБ.

Полностью в bf16 FLUX.2 [dev] требует 113 ГБ только под веса. Это уровень H200 на 141 ГБ и карт поколения Blackwell — B200, B300, GB300; в каталоге они есть. Под генерацию изображений такой запас нужен редко: 4-битная сборка от команды diffusers, по их же замерам, работает примерно на 20 ГБ свободной VRAM. Полные веса имеет смысл брать, когда важна точность вывода без потерь от квантования.

Соотношение объёма памяти и пропускной способности между потребительскими и серверными картами разобрано в сравнении A100 и RTX 4090, а расчёт того, когда аренда выгоднее покупки, — в материале про TCO.

Чек-лист при OOM

Порядок действий, от самого дешёвого к самому затратному:

1. Снизьте разрешение до штатного. 1024×1024 для SDXL и Flux, 512×512 для SD 1.5. Активации падают вчетверо на каждое удвоение стороны.
2. Поставьте батч в единицу. Пик при декодировании VAE пропорционален числу изображений.
3. Включите VAE slicing и tiling. Одна строка, качество денойзинга не страдает.
4. Перейдите на fp8 или GGUF. Для FLUX.1 разница между 33.7 и 17.25 ГБ, дальше — до 10.6 ГБ.
5. Добавьте enable_model_cpu_offload. Пик станет равен самому крупному компоненту вместо их суммы.
6. Вынесите текстовый энкодер. Предрасчёт prompt_embeds отдельным процессом или удалённым эндпоинтом.
7. Переходите на enable_sequential_cpu_offload или group offloading. Запустится почти всегда, скорость упадёт кратно.

Измерять результат стоит не на глаз. В примерах документации diffusers для этого используется одна строка после генерации:

print(f"Max memory reserved: {torch.cuda.max_memory_allocated() / 1024**3:.2f} GB")

Что в итоге

Для SD 1.5 и SDXL вопрос закрыт: 8 ГБ по официальному минимуму Stability AI, 24 ГБ с запасом под батчи и высокие разрешения. Эти модели давно перестали быть проблемой для железа.

Flux разделил задачу надвое. FLUX.1 [dev] в fp8 живёт на 24 ГБ, в bf16 требует 48 ГБ, и здесь выбор карты определяется тем, готовы ли вы к потере качества от квантования. FLUX.2 [dev] со своими 113 ГБ весов на одну карту не рассчитан вовсе: его штатный режим — 4 бита с офлоадом, а не подбор железа под полные веса.

Если задача разовая — прогнать датасет, сравнить модели, проверить гипотезу, — аренда карты нужного объёма на несколько часов обходится дешевле апгрейда домашней сборки. Общая механика расхода памяти при обучении, включая LoRA и checkpointing, разобрана в справочнике по VRAM для обучения; механика квантования, общая с языковыми моделями, — в гайде по DeepSeek-R1.