Krea 2: the RAW and Turbo split, and what it means for LoRA training

What Krea 2 is, and the two-checkpoint decision at its centre

Krea 2 is an image generation model trained from scratch, released by Krea AI as an open version. The repository holds inference code only: a README, a pyproject.toml, and five Python modules (autoencoder.py, encoder.py, inference.py, mmdit.py, sampling.py). There is no training loop, no dataset pipeline, and no web UI.

The design decision that shapes everything else is the split into two checkpoints. Krea 2 RAW is described in the README as a pretrained checkpoint with no distillation, so it is diverse and malleable. Krea 2 Turbo is an 8-step distilled checkpoint built for fast text-to-image. The README states the intended relationship plainly: train LoRAs on RAW, apply them on Turbo, and LoRAs trained on RAW will work well on Turbo.

That is a real architectural commitment, not marketing. A distilled model has already had its sampling trajectory compressed, which usually narrows the space a fine-tune can explore. Keeping an undistilled sibling around means the project can offer fast inference and a trainable base without pretending one checkpoint does both jobs well. The cost is that you are managing two multi-gigabyte safetensors files instead of one, and you need to understand which one a given task belongs to.

How inference actually runs: sampler, guidance and the mu shift

The entry point is inference.py, a Click CLI. A prompt is the only positional argument; everything else is a flag. The repository layout suggests the text encoder lives in encoder.py, the diffusion transformer in mmdit.py, the VAE in autoencoder.py, and the denoising loop in sampling.py. The README does not document the sampling schedule beyond the flags it exposes, so treat that mapping as inferred from filenames rather than stated.

Two flags carry most of the behaviour. --cfg is the classifier-free guidance scale, and setting it to 0 disables CFG entirely. --mu pins a constant timestep-shift value that would otherwise be derived from resolution. The defaults for --y1 (0.5) and --y2 (1.15) are the timestep-shift mu at minimum and maximum resolution, so the shift interpolates as you change --width and --height. Pinning --mu overrides that interpolation.

The two documented recipes differ in more than step count. RAW runs at 52 steps with --cfg 3.5 and is trained up to 1k resolution. Turbo runs at 8 steps with --cfg 0.0 --mu 1.15, and can generate from 1k to 2k resolution. If you copy the RAW command and only change the checkpoint name, you get a slow, over-guided Turbo image. The CFG value is the part people miss.

Resolution handling is forgiving in one direction: the README notes output dimensions are padded up to a multiple of 16 if needed. Seeds are deterministic per image, with image i using seed + i, so --num-images 4 --seed 100 gives you four reproducible outputs.

Installing Krea 2 with uv and running a first generation

The project uses uv and requires Python 3.12 or newer. From a clone of the repository, one command creates the environment and resolves dependencies:

uv sync

Dependencies include torch 2.9.0 or newer, transformers pinned at 4.57.1, safetensors, pillow, einops, diffusers and click. The pyproject.toml routes torch through an explicit PyTorch CUDA 12.8 index on Linux and Windows, so on those platforms you get a CUDA build rather than the default wheel. On macOS that source marker does not apply.

Next, download the safetensors checkpoints from Hugging Face. The README links krea/krea-2-raw and krea/krea-2-turbo, and the Setup section says to point two environment variables at the downloaded files:

export OSS_RAW=...
export OSS_TURBO=...

The flag values oss_raw and oss_turbo select which one loads. A first Turbo generation, at the settings the README recommends for that checkpoint:

uv run inference.py "a fox walking in the snow" \
    --checkpoint oss_turbo --steps 8 --cfg 0.0 --mu 1.15 --width 2048 --height 2048

You should get a single 2048x2048 PNG prefixed sample in the working directory, since --output defaults to sample and --num-images defaults to 1. For the RAW checkpoint, the README's example is 52 steps at CFG 3.5 with no --mu override, letting the resolution-derived shift apply.

If you prefer not to run it locally, the README lists ComfyUI, Fal and SGLang as supported inference platforms, and there is an API reference linked at docs.krea.ai. The repository itself ships no ComfyUI node, so the ComfyUI route means using whatever integration that project provides.

Where Krea 2 is the wrong tool

The repository is inference code, and the README is explicit that finetuning is expected to happen elsewhere: Hugging Face Diffusers, the Ostris AI toolkit, Fal's trainer, or Kohya's musubi-tuner. If you want a training script in the same tree as the sampler, this is not that project. There is no train.py, no dataset loader and no LoRA implementation in the file listing.

Quantisation is another gap. Nothing in the README or pyproject.toml mentions GGUF, int8 or any reduced-precision export, so the memory footprint is whatever the full safetensors checkpoint and a torch 2.9.0 runtime demand. Anyone searching for a GGUF build of Krea 2 will not find instructions here.

The licence boundary is the third constraint, and it is the one most likely to be misread. The repository's LICENSE.md is Apache-2.0, but the README's own FAQ says both model weights are released under a community licence with permissive use, with commercial licensing handled by contacting opensource@krea.ai. The code licence and the weights licence are different documents. If your use case is commercial, the permissive-sounding word in the FAQ is not a substitute for reading the terms at the licensing page.

Finally, resolution is bounded. RAW is trained up to 1k; Turbo covers 1k to 2k. The padding rule means odd dimensions are rounded up to a multiple of 16, which can silently change the aspect ratio you asked for.

Krea 2 against Z Image and Anima: different checkpoints, different trade-offs

Comparisons with Z Image, Z Image Turbo and Anima come up often enough to be worth addressing, but the honest answer is that the README describes only Krea 2. What can be compared is the shape of the release.

Krea 2's distinguishing choice is the paired checkpoint. You get one undistilled base and one 8-step distilled model, and the project tells you to move LoRAs from the first to the second. A single-checkpoint release has no such handoff: whatever you fine-tune is what you sample from, which removes a conversion step but also removes the option of training on a malleable base and serving from a fast one. Whether that matters depends on whether you fine-tune at all. If you only generate from prompts, the RAW checkpoint's trainability is dead weight and you are carrying an extra multi-gigabyte download.

The step counts make the practical difference concrete: 52 steps at CFG 3.5 versus 8 steps at CFG 0.0. That is roughly a six-fold gap in denoiser evaluations before you account for CFG, which doubles the batch through the network on the RAW path. On the same hardware, Turbo is the checkpoint you would use for iteration and RAW for final quality or training data.

A second axis is the inference surface. Krea 2 lists ComfyUI, Fal and SGLang as supported platforms and links a hosted API. Projects that ship only a CLI put the whole integration burden on you. This one gives you a CLI and points at three places to run it, which is a wider net but also means the repository is not the whole story.

Maintenance, upgrade cost and what the licence split implies

The last push to the default branch was on 2026-07-24. No releases are published, and the version in pyproject.toml is 0.1.0. That combination suggests a code drop accompanying a model release rather than a project with a numbered upgrade path. There is no changelog, no migration guide and no documented deprecation policy, so upgrading means diffing the tree yourself.

The dependency surface is small but has one sharp edge. transformers is pinned exactly at 4.57.1, not a range, while torch is a floor of 2.9.0 and diffusers a floor of 0.32.0. An exact pin on a fast-moving library is a deliberate stability choice, but it also means you cannot take a newer transformers without editing pyproject.toml and testing the encoder path yourself. Combined with requires-python >=3.12, the environment is narrow by design.

On licensing, the split matters more than the version number. Apache-2.0 covers the repository, which is what you would fork or vendor. The weights carry a separate community licence, and the README directs commercial enquiries to opensource@krea.ai. I am not giving legal advice: the practical point is that a permissive code licence does not automatically extend to the safetensors files, and the two are documented in different places. If you are building a product, the licensing page is the document to read, not LICENSE.md.

Editorial conclusion

Adopt Krea 2 if you want an Apache-2.0 inference repository and a base checkpoint you can fine-tune, and if you accept the community licence on the weights. Do not adopt it if you need a hosted service with an SLA, or if you want an inpainting or image-to-image tool: the README does not document either. Before you commit, verify the two Hugging Face checkpoint paths resolve, check that torch 2.9.0 installs against your CUDA driver, and read the community licence at the Krea licensing page rather than assuming Apache-2.0 covers the weights.

Frequently asked questions

Official sources

1. Issues
2. krea-ai/krea-2 on GitHub
3. License: Apache-2.0
4. Project website
5. README