Krea 2 ComfyUI Workflow: RAW, Turbo, LoRA
Krea 2 ComfyUI workflow guide for Raw, Turbo, LoRA files, FP8 variants, GGUF options, and reproducible image pipelines.
Hey, I’m Dora. I do not treat a Krea 2 ComfyUI graph as “download model, press Queue.” The fragile part is not the prompt. It is the file contract: RAW versus Turbo, diffusion model versus text encoder, VAE location, and whether the LoRA was trained for the path I am actually running. Checked on July 21, 2026, this note is about local ComfyUI setup only. API access, hosted production, provider quotas, and web app routing belong in a separate article. Different failure surface.
The short version: train or adapt on RAW, run most repeatable inference on Turbo, keep LoRAs in their own lane, and do not mix safetensors, GGUF, and quantized variants without labeling the graph. That sounds basic. It is also where most broken canvases start.
How Krea 2 Fits Into ComfyUI
Krea’s open-source release splits the model family into two checkpoints. The Krea 2 Open-Source page describes RAW as the malleable checkpoint for fine-tuning, post-training, and LoRA training, while Turbo is the distilled checkpoint for fast text-to-image inference. Krea also says Turbo is built around 8-step generation.
That gives the ComfyUI graph a simple job boundary. RAW is the adaptation surface. Turbo is the fast inference surface. A Krea 2 workflow gets unstable when those jobs blur and someone starts swapping files because the names look related.
Raw, Turbo, diffusion files, text encoders, and VAE placement
The first thing I check is not the sampler. I check folders.
The current ComfyUI Krea 2 guide points local users to a split setup: a diffusion model, a Qwen3VL text encoder, and a Qwen Image VAE. In the standard Turbo example, the diffusion model is krea2_turbo_fp8_scaled.safetensors, the text encoder is qwen3vl_4b_fp8_scaled.safetensors, and the VAE is qwen_image_vae.safetensors.
The placement is boring, which is why it gets skipped. Diffusion files belong in ComfyUI/models/diffusion_models/. Text encoders belong in ComfyUI/models/text_encoders/. VAE files belong in ComfyUI/models/vae/. If one of those lands in a familiar but wrong folder, the graph may still load far enough to waste your time.
The Comfy-Org/Krea-2 model card currently lists ComfyUI-ready diffusion files for RAW and Turbo, including BF16, FP8, INT8, MXFP8, and NVFP4 variants. I keep the exact filename in the graph note. Not “Turbo FP8.” The full name. krea2_turbo_fp8_scaled.safetensors and krea2_turbo_mxfp8.safetensors are different decisions.
Where LoRA files belong in the workflow
Krea’s own instruction is unusually clean: train LoRAs on RAW, apply them on Turbo. The official Krea 2 GitHub repository repeats that pairing and frames RAW as the base checkpoint for LoRA training.
In ComfyUI, LoRA files go under ComfyUI/models/loras/. Current Comfy-Org examples include style files such as krea2_darkbrush.safetensors, krea2_dotmatrix.safetensors, krea2_kidsdrawing.safetensors, krea2_neondrip.safetensors, krea2_rainywindow.safetensors, krea2_retroanime.safetensors, krea2_softwatercolor.safetensors, krea2_sunsetblur.safetensors, krea2_vintagetarot.safetensors, and krea2_turbo_lora_rank_64_bf16.safetensors.
A Krea 2 LoRA is not just a visual seasoning. It is a dependency. I track the LoRA source, trigger word, strength, base model assumption, and approval status beside the graph. If the LoRA came from a community repo, I do not assume its license follows the base model. That is where “it rendered fine” becomes a bad compliance argument.
Choosing the Right ComfyUI Path
The practical choice is not “which checkpoint is better.” It is whether the graph is allowed to move.
An experiment graph can change node packs, LoRA strength, resolution, seed policy, sampler settings, and quantized files. A production graph should not move that much. Once a canvas is used for assets that other people review, I want fewer degrees of freedom. One fewer switch. Sounds small. Adds up fast.
Raw for adaptation experiments
RAW is where I put adaptation experiments: LoRA training tests, style-transfer probes, subject tuning, prompt behavior checks, and post-training research. The reason is not romance about base models. RAW is less compressed by distillation, so it gives more room to push behavior before running the adapted result through Turbo.
I do not use RAW as my default final-image path. The Comfy docs describe RAW as full-step sampling, while Turbo is the 8-step route. More steps can be useful when I am measuring control, variation, or training response. It is not what I want when I need to generate many candidates and compare them quickly.
For RAW tests, I keep a separate staging graph. It records the base checkpoint, LoRA or adapter source, trigger words, seed range, prompt pattern, ComfyUI version, and any custom-node changes. This is not ceremony. It is how I avoid opening a graph two weeks later and wondering why last week’s result cannot be reproduced.
Turbo for faster inference workflows
Turbo is the path I use when the output loop matters. The official workflow template centers on a Turbo text-to-image subgraph with model loading, prompt handling, sampling, optional style LoRA, and VAE decode. The default shape is meant to get an image out without turning every run into a graph-design session.
This is where Krea 2 fp8 is the normal first stop for many local users. The Comfy docs call out krea2_turbo_fp8_scaled.safetensors as the recommended diffusion model for most local setups, with BF16, NVFP4, and MXFP8 variants available for other hardware profiles.
I keep Turbo graphs narrower than RAW graphs. One graph for plain Turbo. One graph for approved style LoRAs. One graph for quantization tests. If everything lives in one canvas, the canvas becomes a junk drawer. Found the pattern on the third try.
File Format and Quantization Choices
Quantization is not a personality test. It is a constraint tradeoff.
BF16, FP8, INT8, NVFP4, and GGUF tradeoffs
BF16 is the reference path when the machine can handle it. I use it to check whether a visual difference is caused by the prompt, the LoRA, or the quantized model. If BF16 is too heavy for the machine, that answer is not helpful in daily work, but it is still useful as a baseline.
FP8 is the practical middle for standard ComfyUI inference. It usually gives a better balance between memory and quality than jumping straight to more aggressive formats. I still compare it against BF16 when the project depends on fine texture, typography-like shapes, or face consistency.
INT8, NVFP4, and MXFP8 need their own validation pass. I do not treat “it loads” as “it is approved.” I run the same prompt set, same seed policy, and same LoRA settings. Then I compare edge detail, style strength, prompt adherence, and whether the model starts smoothing away the exact thing the LoRA was supposed to preserve.
Krea 2 gguf belongs in a separate graph family. The community Krea 2 GGUF repository lists Raw and Turbo GGUF files such as krea2_raw_bf16-Q5_1.gguf and krea2_turbo_bf16-Q5_1.gguf, and it notes that GGUF support depends on loader support for the krea2 architecture. That means I do not mix a GGUF loader graph with a standard safetensors graph and pretend they are the same pipeline.
| Format | Best use in my workflow | What I check before keeping it |
|---|---|---|
| BF16 | Reference quality and comparison runs | Whether memory/offload cost is acceptable |
| FP8 | Regular Turbo inference | Exact scaled filename and visual parity |
| INT8 | Lower-memory safetensors testing | Prompt drift and fine-detail loss |
| NVFP4 / MXFP8 | Hardware-specific experiments | Loader support and repeatability |
| GGUF | Low-VRAM or offload-oriented tests | Custom loader compatibility |
Common file placement and version mismatch failures
The most common failure is a file in the wrong folder. The second is a graph looking for a filename that almost matches the file on disk. The third is a node pack update changing loader behavior while the old workflow JSON stays in circulation.
Comfy’s Krea guide tells users to update ComfyUI and notes that missing nodes can come from outdated builds or failed imports. The main ComfyUI repository also describes a release rhythm where core, desktop, and frontend updates do not always land at the same time. This conclusion has an expiration date because model support moves fast.
My rule is simple. When a downloaded workflow changes, I treat it as a new dependency version. I record the workflow JSON date, model filenames, text encoder, VAE, node pack version, and one known-good seed. If a graph must survive client work, it gets pinned before it gets trusted.
FAQ
What should be checked when a downloaded node pack changes?
Check the loader node name, input sockets, sampler defaults, LoRA node behavior, prompt-enhancement toggle, and any workflow note that mentions model downloads. Then run one locked prompt with a known seed. If the same graph now needs a different loader or ignores a previous LoRA toggle, the change is functional, not cosmetic.
This is especially important for ComfyUI Krea 2 workflows because support can depend on current model-detection logic. A node pack can be correct and still be too old for the file you downloaded.
When should staging and production ComfyUI graphs be separated?
Separate them when outputs leave your own notebook. Client assets, paid campaigns, team templates, brand style tests, and reusable batches should not share the same graph with experimental GGUF files or unapproved LoRAs.
My staging graph is allowed to break. My production graph is allowed to be boring. Different job.
Who approves community LoRA use in commercial assets?
The person wiring the graph does not approve commercial use. The approver is whoever owns the commercial risk: brand lead, legal reviewer, client owner, studio producer, or internal compliance owner.
Krea’s Community License includes commercial-use conditions, revenue thresholds, content-filter requirements, and output responsibility. Community LoRAs can add another license layer. I check the base model license, the LoRA license, the source of training material if disclosed, and whether the final asset needs AI disclosure.
That is the Krea 2 ComfyUI boundary I would keep: RAW for adaptation, Turbo for repeatable inference, LoRA files tracked like dependencies, and quantized files treated as separate graph versions. It works. More importantly, it fails in ways I can debug.
Previous posts:
