Krea2 long prompts exceed reference 512-token conditioning limit and produce corrupted outputs

[Goldlionren]

Custom Node Testing

• I have tried disabling custom nodes and the issue persists (see how to disable custom nodes if you need help)

Expected Behavior

Krea2 should handle long prompts consistently with the official Krea 2 reference inference implementation, or explicitly truncate the text conditioning to the model's supported reference sequence length.

A long prompt should not silently produce a black or corrupted/noisy image while the sampler and VAE complete successfully without an exception.

Actual Behavior

Long prompts can produce deterministic black or corrupted/noisy outputs with Krea2.

The workflow completes normally:

• KSampler reaches 8/8 steps
• no Python exception is raised
• no OOM occurs
• VAE decoding completes
• the final image is black or visually corrupted

I traced the Krea2 text-conditioning sequence length and found a strong correlation with the final conditioning sequence length.

Test results using the same long prompt, workflow, model, and generation settings:

Final Krea2 conditioning sequence | Result -- | -- 49 | OK 512 | OK 513 | OK 576 | OK 640 | Black output 674 | Corrupted/noisy output

The original long prompt produces:

raw_chars=3785
token_pairs=708
template_end=34
final conditioning seq=674
conditioning shape=(1, 674, 30720)

The original ComfyUI Krea2 path therefore passes all 674 post-prefix conditioning positions to the Krea2 model.

I compared this with the official Krea 2 reference encoder. The reference implementation uses a default max_length=512 and truncates the prompt body while preserving the final 5-token template suffix.

I implemented a local diagnostic workaround that performs this truncation before Qwen3-VL text encoding.

With the same 3785-character prompt:

[KREA2-TRACE] stage=TOKENIZE batch=0 raw_chars=3785 before_tokens=708 after_tokens=546 template_end=34 seq_limit=512 truncated=True
[KREA2-TRACE] stage=PRE_STRIP token_pairs=546 out_shape=(1, 12, 546, 2560) template_end=34
[KREA2-TRACE] stage=POST_STRIP seq=512 tap_count=12 hidden=2560 seq_limit=512 over_limit=False
[KREA2-TRACE] stage=FINAL conditioning_shape=(1, 512, 30720) final_mask_shape=None

The image then generates normally.

This appears to be related to a difference between the ComfyUI Krea2 text encoder path and the official Krea 2 reference inference path.

Steps to Reproduce

Run the latest ComfyUI with all custom nodes disabled.
Load the official Comfy-Org Krea2 INT8 ConvRot checkpoint.
Use the official/basic Krea2 text-to-image workflow.
Use a sufficiently long prompt. My reproducible prompt produces 708 Qwen3-VL token pairs and 674 final Krea2 conditioning positions after the 34-token template prefix is stripped.
Generate the image.

Observed result:

final_seq=674

The sampler completes normally, but the generated image is corrupted/noisy.

I also tested controlled conditioning sequence limits using the exact same prompt and workflow:

512 -> OK
513 -> OK
576 -> OK
640 -> black image
674 -> corrupted/noisy image

The sequence length was the only intentionally changed variable.

A local workaround that truncates the token sequence before Qwen3-VL encoding, preserving the final 5 template suffix tokens and producing a final 512-position conditioning tensor, restores normal generation.

Debug Logs

Environment:

Platform: Linux
Python: 3.13.12
PyTorch: 2.11.0+xpu
Device: Intel(R) Arc(TM) Pro B60 Graphics
ComfyUI: 0.27.0 / development master
comfy-kitchen: 0.2.16
Triton: 3.7.0

Relevant original model loading path:

Found quantization metadata version 1
Detected mixed precision quantization
Using mixed precision operations
Native ops: int8_tensorwise
model weight dtype torch.bfloat16, manual cast: torch.bfloat16
model_type FLUX
Requested to load Krea2

Relevant diagnostic trace without truncation:

[KREA2-TRACE] stage=TOKENIZE raw_chars=3785 token_pairs=708
[KREA2-TRACE] stage=PRE_STRIP token_pairs=708 out_shape=(1, 12, 708, 2560) mask_shape=(1, 708)
[KREA2-TRACE] stage=POST_STRIP template_end=34 seq=674 tap_count=12 hidden=2560 over_512=True
[KREA2-TRACE] stage=FINAL conditioning_shape=(1, 674, 30720) final_mask_shape=None

Relevant diagnostic trace with pre-encoder reference-style truncation:

[KREA2-TRACE] stage=TOKENIZE batch=0 raw_chars=3785 before_tokens=708 after_tokens=546 template_end=34 seq_limit=512 truncated=True
[KREA2-TRACE] stage=PRE_STRIP token_pairs=546 out_shape=(1, 12, 546, 2560) template_end=34
[KREA2-TRACE] stage=POST_STRIP seq=512 tap_count=12 hidden=2560 seq_limit=512 over_limit=False
[KREA2-TRACE] stage=FINAL conditioning_shape=(1, 512, 30720) final_mask_shape=None

Other

The official Krea 2 reference encoder appears to use a default text conditioning maximum length of 512 and performs prompt-body truncation before text encoder inference while preserving the final template suffix.

In the current ComfyUI implementation, Krea2 inherits the Qwen3-VL tokenizer path and the resulting conditioning sequence is not capped to the Krea reference length before being passed to Krea2.

I am not certain whether the correct upstream fix is:

restoring a Krea2-specific 512 sequence limit in Krea2Tokenizer,
making the Qwen3-VL tokenizer max length model-configurable,
or fixing support for Krea2 conditioning sequences above the reference length.

I have a working local patch that performs reference-style pre-encoder truncation and can prepare a PR if this is the intended fix direction.

Possibly related to #14717, although that report does not currently identify prompt/conditioning sequence length as the trigger.

[coderabbitai]

🔗 Related PRs

#14713 - Fix Qwen3-VL tokenizer crash with custom embeddings [merged]

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Goldlionren]

I found a more specific reproduction and I no longer think this is primarily about prompt length alone.

New finding:
the issue appears to depend on the exact combined text+image sequence shape when running with the comfy-kitchen Triton backend on Intel XPU.

Key observation:
with the same prompt and same 1:1 workflow, simply disabling --enable-triton-backend makes the corrupted output disappear.

So the minimal flip is:

• Triton ON -> corrupted / black output
• Triton OFF -> normal output

This makes a moderation / refusal explanation very unlikely.

Additional traces:

1. 3:4 case (works, Triton ON)

• txtlen=165
• imglen=8295
• combined_len=8460
• mod256=12
• reference_pad256=244

2. 1:1 case (corrupts, Triton ON)

• txtlen=165
• imglen=8281
• combined_len=8446
• mod256=254
• reference_pad256=2

3. 1:1 case (works, Triton OFF)

• txtlen=161
• imglen=8281
• combined_len=8442
• mod256=250
• reference_pad256=6

This suggests the corruption is tied to exact tensor shape / backend selection rather than prompt semantics.

I also checked the Krea 2 reference implementation and it pads the combined text+image sequence to a multiple of 256 before the shared transformer blocks, explicitly “to stabilize compiled kernel shapes”.
The current ComfyUI Krea2 path does not appear to do this.

At this point, my current hypothesis is:

• the issue is in the comfy-kitchen Triton path on XPU for certain Krea2 combined sequence shapes, and/or
• ComfyUI is missing the Krea reference combined-sequence padding behavior that helps stabilize these shapes.

If useful, I can provide:

• the additional logs,
• the exact 1:1 workflow,
• the traces for Triton ON vs OFF,
• and a local experimental patch.

[LukeG89]

I don't know if this might help identify the cause of your problem, but the other day, while I was testing this other bug that's been giving me trouble, I discovered that the --disable-async-offload option causes the same issue on my system: black or broken images (just created a bug report for it #14812)

I’d also try checking if disabling dynamic VRAM might solve your problem: memory management is really great for speeding up loading and inference, but it seems to have weird effects on the generation process itself (for example, sometimes running the exact same workflow produces two slightly different images).

[comfyanonymous]

ComfyUI behavior has always been to pass your entire prompt to the model even if it breaks the model a bit.