Krea-2

Krea-2 is a ~12B single-stream diffusion-transformer text-to-image family. InvokeAI supports both published checkpoints:

• Krea-2-Turbo — distilled for fast, low-step generation. Runs at 8 steps with CFG disabled (CFG Scale 1.0). This is the recommended checkpoint for everyday use.
• Krea-2-Raw — the undistilled base checkpoint. Runs at more steps (~28) with CFG enabled (CFG Scale ~5.5, equivalent to the reference pipeline’s guidance 4.5) and supports negative prompts. It is primarily intended as a base for finetuning / LoRA training, but full inference is supported.

The variant is detected automatically on install, and selecting a Krea-2 model sets sensible defaults (steps, CFG, 1024×1024) for that variant.

Image size and the noise schedule

Raw puts more of its steps at high noise the larger the image, up to the area of 1280×1280 (about 1.6 megapixels). Larger images keep that schedule, which is also the one Turbo always uses. Without the limit, a 2048×2048 Raw image would spend about half of its steps above 90% noise, and a 4096×4096 one all of them. To sample with a different schedule, set Shift on the Denoise - Krea-2 node in a workflow.

License

Krea-2 Turbo and Raw are released under the Krea 2 Community License. Commercial use of the model and its images is allowed only for companies with less than $1M in annual revenue; above that, an Enterprise license is needed. Redistributed copies must add “Krea” to the model name. The full Diffusers repositories are gated: accept the license on the model’s HuggingFace page and add your HuggingFace token under API Keys in the Model Manager. The quantized GGUF, NVFP4, fp8 and int8 copies are not gated, but the same license applies.

This is a summary, not legal advice. Read the full license on the model’s HuggingFace page before using a model commercially.

Hardware

Krea-2 is a large model. See the System Requirements table for details. In short, on a 24 GB card enable FP8 in the model’s Default Settings to fit 1024² (with a LoRA). For lower VRAM, use a smaller transformer build:

Transformer build	Transformer size	Notes
NVFP4 (starter model)	≈ 7.2 GiB	stays packed, unpacked per layer on any GPU
GGUF Q4_K_M (starter model)	≈ 7 GB	stays packed, unpacked per layer
GGUF Q8_0 (starter model)	≈ 13 GB	near-full quality
int8 (int8_convrot, starter model)	≈ 12.6 GiB	stays int8 on every device, no FP8 setting needed
int4 (convrot_w4a4, int4_tensorwise)	≈ 6.4–9.6 GiB	stays packed on every device; most builds keep some layers int8, which sets the size
GGUF Q8_CR (ComfyUI-GGUF)	≈ 12.8 GiB	the same int8 inside a .gguf, stays int8 on every device
GGUF Q4_CR (ComfyUI-GGUF)	≈ 7.0 GiB	the same int4 inside a .gguf
fp8 / fp8_scaled (starter model)	≈ 12.2 GiB	with FP8 Storage (switched on at install) or fp8_compute
MXFP8	≈ 24 GB	unpacked to BF16 at load; prefer the fp8, NVFP4 or GGUF build

The Qwen3-VL encoder and the small VAE come on top of these sizes. The encoder takes about 8.5 GB as bf16 (the starter bundle’s encoder), about half that as fp8, and about 2.8 GB as a Q4_K_M GGUF Qwen3-VL encoder.

Installing

The easiest path is the Krea 2 bundle in the Model Manager. It installs Krea-2 Turbo and Raw as Diffusers pipelines, the Turbo GGUF Q4_K_M, GGUF Q8_0 and NVFP4 transformers, and the standalone Qwen-Image VAE and Qwen3-VL 4B encoder those transformers need. Raw single-file builds are individual starter models.

Krea-2 needs three components:

Component	Diffusers install	GGUF / single-file install
Transformer	bundled in the pipeline	the .gguf / single-file checkpoint (GGUF, fp8, int8, int4, NVFP4, MXFP8)
VAE (Qwen-Image)	bundled	installed separately
Text encoder (Qwen3-VL)	bundled	installed separately

• Diffusers (e.g. krea/Krea-2-Turbo, krea/Krea-2-Raw): a single ~26 GB install that bundles the VAE and text encoder. Nothing else is required.
• GGUF / single-file: the checkpoint ships only the transformer. You must also install a standalone Qwen-Image VAE and a Qwen3-VL encoder (both included in the Krea 2 bundle). Comfy-Org’s fp8 and int8 builds, Krea-2 Turbo (fp8) (~13.1 GB) and Krea-2 Turbo (int8) (~13.5 GB), are individual starter models that install both as dependencies, as are Raw’s counterparts Krea-2 Raw (fp8) (~13.1 GB), Krea-2 Raw (int8) (~13.5 GB), Krea-2 Raw (Q4_K_M GGUF) (~7.5 GB), Krea-2 Raw (Q8_0 GGUF) (~13.7 GB) and Krea-2 Raw (NVFP4) (~8.8 GB). The Raw GGUF and NVFP4 files are community builds, by vantagewithai and rockerBOO. Raw is undistilled, so these run at about 28 steps with CFG.

When you select a GGUF/single-file Krea-2 model, InvokeAI auto-selects an installed VAE and Qwen3-VL encoder if you have them. If none are installed, you’ll be prompted to pick them (in the model dropdowns) before you can generate. Selecting a Diffusers Krea-2 model clears those standalone selections and uses the bundled components.

Qwen3-VL encoder

Single-file Qwen3-VL encoders bundle only the weights. Their tokenizer and architecture config ship with InvokeAI, so these encoders load without network access. A single-file fp8 encoder is kept resident in fp8 (roughly half the VRAM of the bf16 encoder), and an nvfp4 encoder keeps its layers packed at 4 bits.

Qwen3-VL GGUF encoders

The Qwen3-VL encoder can also be a llama.cpp GGUF, for the 4B encoder Krea-2 uses and for the 8B encoder Ideogram 4 uses. A Q4_K_M 4B file is about 2.5 GB and takes about 2.8 GB of VRAM, against 8.5 GB for the bf16 safetensors encoder, so encoder and transformer fit on the GPU together. Images match the bf16 encoder closely; the remaining difference is the quantization of the encoder.

• Use a Qwen3-VL GGUF, such as the files in Qwen/Qwen3-VL-4B-Instruct-GGUF. A plain Qwen3 GGUF has the same shapes but conditions wrongly, so InvokeAI identifies the encoder from the file’s qwen3vl architecture tag and does not install a plain Qwen3 file as one.
• The mmproj-*.gguf file next to it holds the vision part and is not needed for text-to-image. It installs as its own Qwen3-VL Vision Tower model, but Krea-2 does not use it yet: without the vision part in the encoder, a GGUF encoder cannot encode the reference images of edit LoRAs. Qwen-Image-2.1 takes it for its own references.
• ComfyUI-GGUF’s Q8_CR and Q4_CR encoder files are refused at install; only the transformer loads from them.
• LoRAs with text-encoder layers still apply to a quantized encoder.

Qwen3-VL encoder starter models, none of which belong to a bundle:

Starter model	Format	Size	Used by
Qwen3-VL 4B Encoder (bf16 / fp8 / int8)	Comfy-Org single files	~8.9 / ~5.2 / ~4.9 GB	Krea-2, FLUX.3
Qwen3-VL 4B Encoder (Q4_K_M / Q8_0 GGUF)	GGUF, language tower only	~2.5 / ~4.3 GB	Krea-2, FLUX.3; text only
Qwen3-VL 8B Encoder (NVFP4)	Comfy-Org single file	~6.3 GB	Ideogram 4, Qwen-Image-2.1
Qwen3-VL 8B Encoder (Q4_K_M / Q8_0 GGUF)	GGUF, language tower only	~5.0 / ~8.7 GB	Ideogram 4, Qwen-Image-2.1; text only

The 4B and 8B encoders are not interchangeable.

Conditioning enhancers

Two optional, off-by-default toggles are available under Advanced Options (below CFG Scale). They transform the text conditioning and are especially useful for the distilled Turbo checkpoint:

• Conditioning Rebalance — per-layer weighting of the text embedding to improve prompt adherence.
• Seed Variance Enhancer — injects controlled noise into the conditioning to restore per-seed diversity (the distilled model otherwise produces near-identical images across seeds), trading some prompt adherence for variety.

Both are recorded in image metadata and can be recalled. When enabled on the canvas, the same enhancer chain is applied independently to the global prompt and each positive regional prompt before their conditionings are collected.

Multiple conditionings

In the workflow editor, the Denoise - Krea-2 node accepts one conditioning or a collection for both its positive and negative conditioning inputs. Multiple independently encoded conditionings are concatenated after padding tokens are removed.

The Prompt - Krea-2 node also accepts an optional mask. A masked conditioning applies to that image region. An unmasked negative conditioning applies to the whole image; an unmasked positive conditioning applies to the background not covered by any regional mask, or to the full image if regional masks cover all of it. Krea-2 uses restricted attention on alternating main transformer blocks, leaving the other blocks unrestricted to preserve image-wide coherence. Positive and negative regional prompts are available on the Canvas. Auto-Negative uses the region’s positive prompt as a negative outside its mask. Regional negatives and auto-negative take effect only when CFG Scale is above 1; Turbo’s default CFG 1 ignores them. In workflows, masked conditioning collections can also be supplied to the negative input when CFG is enabled. Regional reference images are not supported.

Regional prompting memory

Regional prompting builds a dense boolean attention mask whose memory grows quadratically with the combined text and image token count. Invoke reserves memory for retained masks, construction scratch space, and the dtype-sized additive attention bias created by SDPA. Whether a fused kernel (cuDNN or memory-efficient) accepts a dense mask still depends on the GPU, PyTorch build, dtype, and sequence shape. When no fused kernel is available, PyTorch falls back to math attention, which may use substantially more VRAM and can cause an out-of-memory error. Reducing image resolution or disabling regional prompting is the practical fallback. Automated CUDA coverage is skipped on unsupported hardware and cannot exercise every GPU/backend combination.

Style reference

Krea-2 can transfer the look of a reference image — palette, texture, rendering — while the prompt keeps driving the content. There is no adapter model and no LoRA: the reference’s attention keys and values are spliced into the target’s, so it works with any Krea-2 checkpoint out of the box.

In the Generate panel, add a Reference Image while a Krea-2 model is selected, pick an image (cropping it if you like), leave its Mode on Style and set Style strength. The reference applies to Generate and to every Canvas mode. In the workflow editor the same thing is the Style Reference - Krea-2 node, feeding the Style Reference input of Denoise - Krea-2.

• Style strength is the one knob you need. 1.0 is the recommended setting; the slider goes to 2.0 for a heavier effect. 0 disables the reference entirely and costs nothing.
• The remaining node inputs (block range, key/value scaling, AdaIN strengths) are for tuning and should be left at their defaults. Style strength already modulates several of them.
• The reference image and its Style strength are recorded in image metadata, so Recall All and Remix Image restore them along with the rest of the recipe.

One reference, matching size, roughly 2x runtime

• Exactly one reference image is used. The Generate panel runs one active Style reference at a time and does not combine it with Edit references.
• The reference must be encoded at the same width and height as the denoise node — its image tokens are appended to the target’s. On the canvas this is wired up for you. In the workflow editor, set the same width and height on both nodes, or the denoise node will refuse the reference.
• Every step runs one extra transformer pass for the reference, so generation takes roughly twice as long.
• The reference’s keys and values are retained for the whole step: about 0.5 GB at 1024² and 1.7 GB at 2560×1440. At 1440p that no longer fits on a 24 GB card alongside the model.

LoRA

Krea-2 LoRAs (diffusers PEFT format) are supported and apply to both the transformer and — where the LoRA includes text-encoder layers — the Qwen3-VL encoder. On quantized builds (GGUF, int8, int4, NVFP4) the LoRA is applied alongside the packed weights rather than merged into them. LoRAs trained to edit an input image need reference images; see Edit LoRAs.

Edit LoRAs and reference images

Some Krea-2 LoRAs are trained to transform one or more input images rather than to generate from text alone. They come from ai-toolkit’s Krea-2 edit training (edit: true) and include the pose and depth “controlnet” LoRAs: you give them a pose skeleton or a depth map as a reference image, and the prompt describes the result. Such a LoRA does nothing useful without its reference images, and an ordinary Krea-2 LoRA gains nothing from them. Edit mode is not a general instruction editor: without a matching edit LoRA, prompts such as “replace the dog with a cat” are not carried out, and the model copies the reference instead. The Generate panel shows a note while Edit references are active and no LoRA is enabled in Concepts.

A reference image reaches the model twice, and both are needed:

• The text encoder looks at it. The Qwen3-VL encoder sees each reference next to the prompt. A reference above an area of about 384×384 pixels is scaled down to that area, keeping its aspect ratio; a smaller one keeps its size. A side shorter than 28 pixels is stretched to 28. The Qwen3-VL processor then works on 32-pixel cells and enlarges an image below its floor of 65,536 pixels to that floor. This needs the encoder’s vision weights. The encoder of the Krea-2 Diffusers models has them, and so do Qwen3-VL single files and folders that include the vision weights. GGUF encoders do not. An encoder without them is refused when reference images are connected.
• The transformer sees it as clean image tokens. The reference is encoded with the VAE and its tokens are added after the image being generated. They are always presented as fully denoised. An image above 1 megapixel is scaled to about 1 megapixel, keeping its aspect ratio, and both sides are then rounded to a multiple of 16 pixels, so the result can be slightly above 1 megapixel and a tiny image is enlarged to 16 pixels per side. Smaller images are otherwise not scaled up.

Both keep the image’s RGB and drop its alpha channel, as in ai-toolkit training: a transparent PNG shows the colors hidden under its transparent areas, not a background.

In the Generate panel and on the Canvas

1. Add the edit LoRA under Concepts.
2. Add the reference images, up to three. Several added at once, or added beside an active reference, start as Edit. A single first reference starts as Style; adding a second image turns it into Edit as long as its strength is still the default. For a LoRA that takes one reference, such as a pose skeleton, switch its Mode to Edit yourself. A Style reference at strength 0 is not active. The enabled references are read in card order, which is the order the LoRA’s prompt refers to (“Picture 1”, “Picture 2”, …); use the arrows on each card to reorder them.
3. Describe the result in the prompt, as the LoRA’s model card suggests, and press Invoke.

To make a control image from a photo, put the photo on the Canvas as a raster layer and filter it with DW Openpose (pose skeleton) or Depth Anything (depth map). Then right-click the canvas and choose Create From BBox › New Global Reference Image, or save the result to the Gallery and choose Use as Reference Image from the image’s right-click menu. Hide or delete the filtered layer afterwards if it should not be part of the canvas image. On the Canvas the Edit references apply to every mode, including image-to-image and inpainting.

With CFG above 1 the negative prompt reads the same references. Invoke stays disabled, and says why, while Edit references are combined with a Style reference or with a GGUF Qwen3-VL encoder. A Canvas Invoke with enabled regional guidance layers stops with a message instead, since Edit references cannot be combined with regional prompts. Reference K/V cache under Advanced sets the K/V cache below; it can be switched only while Edit references are active and a LoRA is enabled in Concepts, and is not sent otherwise. The references and, when it was sent, the K/V cache setting are recorded in image metadata, so Recall All and Remix Image restore them.

In the workflow editor

1. For each reference, an Image to Latents - Qwen Image node (qwen_image_i2l) with Reference (reference) enabled and width and height left unset. It applies the transformer sizing above.
2. The same images, in the same order, on the Reference Images input (krea2_text_encoder.reference_images) of each Prompt - Krea-2 node: the positive prompt’s, and the negative prompt’s when a step between Denoising Start and Denoising End has CFG above 1. Each of the two is a single prompt node, not a collection of several.
3. The latents from step 1, in the same order, on the Reference Latents input (krea2_denoise.reference_latents) of Denoise - Krea-2. With CFG, both the conditional and the unconditional pass see the references.
4. The edit LoRA on the transformer, as for any other LoRA.

Reference K/V cache

Edit LoRAs come in two kinds, and the Reference K/V Cache input (krea2_denoise.reference_kv_cache) of Denoise - Krea-2 has to match how the LoRA was trained. In the Generate panel it is Reference K/V cache under Advanced:

• Off (the default) is for normal edit LoRAs, such as the depth LoRAs. The references join every transformer pass, and everything attends to everything.
• On is for LoRAs trained with ai-toolkit’s kv_cache option, such as the thedeoxen Krea-2 pose ControlNet LoRA. They were trained with reference images that only attend to each other. The references then run through the transformer once per generation, at the start, and every step reuses what they computed, so generation is faster than with the cache off.

Nothing in a LoRA file says which kind it is. Use what its model card says. Dark blotches or extra figures with reference images can mean the LoRA was trained with isolated references: turn the cache on.

Limits

• At most 3 reference images. Both the prompt node and the denoise node refuse more, and the Generate panel accepts three.
• The denoise node refuses a prompt that was encoded with a different number of reference images than it has reference latents: the positive prompt, and the negative prompt when a step between Denoising Start and Denoising End has CFG above 1. Only the number is checked, not which images or their order, so give the prompt and the denoise node the same images in the same order.
• With references, each of those prompts must be a single prompt. The denoise node refuses a collection of several, because each would add the reference images to the text again.
• With the K/V cache off, every reference adds about 4096 tokens per megapixel to every transformer pass. A 1 megapixel reference doubles the image sequence of a 1024² generation, so each step takes at least twice as long and needs more VRAM. The memory reserved for the transformer accounts for the extra tokens.
• With the reference K/V cache on, the references are not in the per-step passes, but what they computed stays in memory for the whole generation: about 0.7 GB per 1 megapixel reference. The reserved memory accounts for it.
• References cannot be combined with Style reference or with regional (masked) prompts. The denoise node refuses either combination before it loads the model.
• Image-to-image and inpainting work as usual: they act only on the image being generated, not on the references.

Attention backend

Krea-2 uses InvokeAI’s attention kernel order, the same as every other model: Flash Attention where the PyTorch build has it, then cuDNN, then memory-efficient attention, unless attention_backend ranks another kernel first. A pinned kernel applies to Krea-2 as well: where it does not take Krea-2’s grouped-query heads as they are — memory-efficient attention does not — InvokeAI expands them so that it can. With attention_backend: sage, its unmasked attention runs on SageAttention instead. For benchmarking or support questions you can force one kernel with the environment variable INVOKE_KREA2_SDPA_BACKEND: flash, cudnn, efficient or math, or default for InvokeAI’s order. A forced kernel that the GPU or build does not support raises an error instead of quietly falling back, and an unknown value stops InvokeAI at startup.

Any value, default included, also turns on per-step timing in the log, which synchronizes the GPU after every step and slows generation slightly, and keeps SageAttention off. Unset the variable for normal use.