Y7 Krea 2 Raw Sampling Shift

ComfyUI has shipped native Krea 2 support since 0.25.0, so a plain UNETLoader + CLIPLoader (type: krea2) + Qwen-Image VAE setup runs the model with no custom nodes at all. But ComfyUI loads every Krea 2 checkpoint with a fixed sampling shift of 1.15 - and that number is Turbo's. Turbo is the TDM-distilled one: 8 steps, cfg 1, mu 1.15 quoted right in the model's own settings. Raw is the undistilled base with no aesthetic finetune, meant to run at ~52 steps and cfg 3.5, and it does not want a fixed 1.15 at every resolution.

Krea's own Raw schedule is resolution-dependent: shift 0.5 at 256×256, climbing to 1.15 at 1280×1280. Y7 Krea 2 Raw Sampling Shift is the small node that applies it.

Why shift matters at all

On a flow-matching model, shift reshapes the sigma schedule without changing how many steps you asked for. Raise it and the run spends more of its steps up in the noisy end, arranging the picture. Lower it and more steps land in the clean end, finishing the picture. It's the flow-matching replacement for the scheduler fiddling people did on SDXL, which is why it's the knob that actually pays now.

So the logic of Krea's Raw curve is: at small resolutions there are fewer image tokens to work with, so you want less time spent arranging and more time finishing. At 1280 and up, the model has room, and 1.15 is right.

How it works

The node converts width × height into an image-token count - dimensions rounded up to 16, then divided by 256 for the 8×8 patch and 2×2 downsample - and interpolates linearly between 256 tokens (shift 0.5) and 6400 tokens (shift 1.15). It then builds a flow-matching model-sampling object with that shift and patches it onto a clone of your model, which you get back out. That's the whole trick: it isn't a sampler and it doesn't touch your latent, it just tells the sampler a different sigma curve to walk.

The numbers it produces, if you're curious:

| resolution | raw_dynamic shift | | --- | --- | | 512×512 | 0.58 | | 768×768 | 0.72 | | 1024×1024 | 0.91 | | 1280×1280 | 1.15 |

Inputs and outputs

model is the only connection, and the only output is MODEL - the same model with a different sigma curve. Put it between your loader and the sampler, typically on the stage1_model chain of the Krea 2 Two- or Three-Stage Sampler. Deliberately: the Turbo model needs no patch, and stacking this on Turbo is just moving a number that was already right.

sampling_mode is the only real decision. raw_dynamic (the default) uses the resolution curve above. manual uses manual_shift (advanced, default 1.15) and ignores width and height entirely - that's your taste knob if you want a fixed 0.9 everywhere, or want to test above the documented range.

width and height default to 1024 and are only read by raw_dynamic. This is the thing to get right: they're widgets, not the latent. The node can't see what you're actually sampling, so wire base_width / base_height in from Y7 Dual Resolution Selector (they're INTs, they connect) if you're not generating at 1024×1024. Leaving them at 1024 while sampling at 512² means you asked for 0.91 where the schedule calls for 0.58 - and at small base resolutions that mismatch is bigger than the entire effect you came for.

One honest caveat: the curve has no upper clamp. Sample at 1456×1456 and it extrapolates to ~1.35, well past the 1280 the schedule was defined at. If your stage 1 is a big latent, manual at 1.15 is the more predictable choice.

Install

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/yushan777/ComfyUI-Y7Nodes
pip install -r ComfyUI-Y7Nodes/requirements.txt

Or ComfyUI Manager → Custom Nodes Manager → search Y7 → Install → restart. The pack's two pip dependencies are color-matcher and opencv-python-headless, both for other nodes in the pack; this one needs nothing beyond what ComfyUI already ships. Written in the newer V3 node API, so an old ComfyUI won't list it at all.

Where people get burned

"It did nothing." It's a passthrough node - no preview, no visible change. The one clue is in the console log, which prints the mode and the shift it applied to eight decimal places. If that line isn't there, the node isn't running.

You're using a third-party scheduler. Some samplers and schedulers - the res4lyf family, bong_tangent in particular - apply their own sigma shift and ignore the one coming from the model. Set shift, see zero effect, conclude shift is broken: that's the classic. Swap to a stock scheduler (beta, simple, sgm_uniform) before you conclude anything.

The handoff sigma error. If you patch stage 1's shift and leave stage 2 loading at ComfyUI's default, the two sigma schedules disagree and the two-stage sampler can throw "The handoff sigma is outside the stage 2 schedule". Either give both models compatible sampling settings, or set manual_shift to 1.15 so nothing moves at all.

Patching after the LoRA, not before. The shift lives on the model object; a LoraLoaderModelOnly after this node passes the patched model sampling through fine, but a loader chain that rebuilds the model will drop it. Keep the patch last in the chain.