# 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. :::note[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](/start-here/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](#qwen3-vl-gguf-encoders). ## 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. :::note[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](#edit-loras-and-reference-images). [Qwen-Image-2.1](/users-guide/models/local-models/qwen-image-2-1/#reference-images) 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. :::caution[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. :::caution[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). ## 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](#qwen3-vl-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](#qwen3-vl-gguf-encoders). 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](#reference-kv-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. :::caution[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`](/configuration/invokeai-yaml/#attention-kernel) 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](/configuration/optimization/sage-attention/) 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.